• 我这句是针对你前面的 搞测试自动化,写代码、coding 测试用例是最正确的姿势 才特意补充的。

    你这句话我的理解是,只要不是用写代码、coding 的姿势搞测试自动化,就不是好方法,死路一条。
    我想表达的是:就算用的不是写代码或者 coding 的姿势搞自动化,只要能有效果提高效率的就是好方法。

    直白点说就是,我不认同你的观点。

  • 才看到正文补充的第一次执行报错。。。

    你把 node_modules 文件夹整个删掉,让它从零开始重新下载吧。你第一次报错意思就是有个库需要从 github 下载源码,但你的网络环境让它死活下载不下来。。。

  • 写代码最灵活,也最容易接触底层,了解更全面。可以理解为是最正统的方式。

    但不代表每个人都必须要这么高的灵活度和深入度,对企业或者公司来说,招少数人写平台或框架,多数人直接基于这块写用例,性价比更高。现在行业还没完全提高到随便一个测试人员都能直接 coding 写自动化用例的水平,会 coding 和不会 coding 还是有成本差异的。

    个人观点:正统方向要有,但也不能一刀切。只要能帮助团队提高效率的,都是好框架。好框架不等于需要百年长青、面面俱到,能解决当下问题就很足够了。

    PS:就算 coding ,也要有相对统一的规范才好协作的。开发有各种比较明确具体的分层架构(MVC、MVVC 等),而且都是业内相对通用,换家公司还能继续用的。但测试这块目前太少了,基本都是各家自己定,而且内部还不一定能全员都理解和用对。缺少统一架构的 coding ,维护起来比天然就能统一写法的平台或框架,更痛苦呀。

  • 接口自动化实践记录 at May 13, 2021

    整个实践挺完整的,不错,特别是考虑到了用例依赖这个点,对流程类用例挺有用的。提个小建议,后续这类记录除了结果,可以加入一些背景以及思考,背景便于别人了解前因,思考便于自己发现不足,下一次做的更好。

    好奇问下,用 yml 这种方式,用例编写及维护体验如何?

    个人感觉相比 excel ,好处是可以支持更灵活的结构,对版本管理也更友好(excel 是二进制文件,不好看出每次改动 diff),缺点是批量处理时相对没 excel 方便,然后各种缩进容易踩坑。但实际项目只用过 yml 来做配置,没试过用 yml 写用例,想了解下实际写起来感觉如何?

  • 请说出你的故事~

    主要还是 wda 得另外弄开发者证书会麻烦点吧,不过目前好像没见到其他可以绕过这块的解决方案。

  • 找运维拿线上正式的 ssl 证书,加到 filddle 里面。

  • 测试 at May 13, 2021

    慢慢积累就好,非专职性能的一般不会要求太深入,掌握大概思路就好。具体技巧工具用到了再去学就行。

  • npm 有配置过国内镜像么?看报错是有的依赖没找到。

  • 附上:
    1、你的具体测试代码,最好是调整为能复现问题的最简单代码,工程代码各种封装,别人会看不懂。
    2、appium 日志
    3、被测应用的在出问题时的界面情况截图
    4、可以的话,被测应用的日志最好也给下。一般界面卡主就是主线程有阻塞了,阻塞久了会直接 ANR 的。

  • 测试 at May 13, 2021

    测试也可以深入代码呀,如果是专业的性能测试人员或团队,这个算是基本要求了。如果只是兼职的,倒不会要求这么高,但有这块能力别人会更认可你。

    我理解面试官其实是想看你寻根究底到什么程度吧,虽然说有经验的开发会更专业,但测试也掌握这方面的一些技巧,才能更有话语权,也避免被有些不大了解性能的开发带偏。而且性能除了可能是代码问题,也很可能是配置问题,各种框架中间件操作系统,如果都直接用默认配置,也会很容易产生性能瓶颈。

  • 目前使用了一个笨办法,就是批量断言完之后,打标签,如果是 false,就自己 raise 一个异常让 HTMLTestRunner 监听

    这个就是正统方法呀,为啥会是个笨方法呢?捕获异常不用依赖任何其他模块,监听 logging.error 还得加上日志模块的依赖,从框架设计角度,捕获异常通用性明显更强也更简单。而且从使用者角度,谁能想到只是打个 error 日志记录下,还能引起用例记录为 fail 呢?

    你先描述下你的场景吧,感觉是你对这个使用场景中的用例 fail 判定还有可以改进的地方。

  • 如果是流水线的插件的话,那原有流水线的编译和这个增加覆盖率的编译,可能会引起重复。

    建议是直接扩展现有流水线上的编译插件或函数,直接增加是否内置覆盖率统计的开关。至于开关打开后具体插入什么参数,那就根据具体语言和编译器来进行对应设定了。不过一般不同语言整个流水线各个步骤都会有差异,一般 devops 平台都会直接用项目类型来直接区分语言的吧。

  • 对测试框架来说,对一个用例的执行判定是这样的逻辑(具体 fail 和 skip 的异常类可能名字不完全一样,但基本原理都是捕获指定类型的异常):
    1、没有任何异常抛出——success
    2、抛出 AssertError 类型的异常——fail
    3、抛出其他类型的异常——error
    4、抛出 SkipException 类型的异常——skip

    没执行到断言就结束且没有产生异常==没有断言==没有异常==success

    PS:你贴的那段错误代码,所有异常都被捕获了,捕获完也只是打个日志,没有继续向外抛出。测试框架是用例的外面一层,你不给他异常,他只能认为没有异常。

  • 建议买本书或者上极客时间这类网站找个性能测试课程,系统地学吧。

    PS:建议先从不直接伸手开始,直接抛问题而不提自己做过什么尝试和思考,不是学习应有的态度。

  • 个人意见:
    要掌握的中间件:主要是被测系统会用到的,其它暂时用不到的了解下即可。从行业通用角度,消息队列类(RabbitMQ、Kafka)、缓存类(redis)、定时任务类(xxl-job)、注册中心类(zookeeper、eureka)应该会比较常见。

    1、知道是干嘛的
    2、知道大概原理以及优缺点
    3、掌握相关的操作工具技巧(如 redis 的 RDM )
    4、知道一下几种典型的用法(面试可能会问到)

  • 点击动作,如果失败的话,应该会抛出异常的。你上面这个场景,无法操作的表现是可以正常调用点击事件,且没有出现任何异常?

  • 最简单的办法,可以加上无法操作时(应该有对应的异常类),也进入异常弹窗处理流程,检测有没有弹窗,有就关掉?

  • 可以看下 Pytest 的并行是否满足?

    不过多设备的话,不同设备用不同 driver ,这个还是得小改造下用例里获取 driver 的方法的。用 appium 并行 搜索了下,找到几篇应该有借鉴意义的文章:
    http://testerhome.com/topics/1944
    http://testerhome.com/topics/12331

    你也可以自己搜索下,这块社区以前有不少同学分享过。

  • 感觉这个思路怪怪的,你这里的并发是多用例并行执行还是啥?

    如果是多用例并行执行,那每个用例自己管理自己的 driver 就好,用不着搞个 devices_start_sync 来做。框架只需要起几个固定线程,线程一空闲就去全局的待执行用例列表拉用例执行就好。

    如果是镜像执行(用例里每一个操作每个 driver 都操作一遍),那应该在 driver 外层封装一个类,用例用这个类,类里面的方法都会自动遍历内部持有的所有 driver 每个执行一遍。

    不过这种比较少见,而且也很难处理中间单个设备出现的异常引起的问题。所以更多见到的情况是保障每个设备都有执行过全量用例就行。实现上是多用例并行执行的基础上,把待执行用例列表从一个公共列表,变为每个线程都有一个独立的列表就好了。

    PS:这两种模式的并行执行用例,都比较常见,印象中 pytest 有自带这方面的功能。如果要省力,可以考虑看看 pytest 自带的功能是否满足

  • 我经历过的情况是,有时候 leader 其实没太认真想过这个问题,基本都是实际在项目中用了,才知道自己想要什么,然后再调整具体展示的指标数据。

    所以一开始一般都是给统计起来最简单的数据(用例总数、总通过率什么的),后面再根据需求增加统计指标。

  • 先根据业务看 pageB 是否可以随时直接跳转,有些界面依赖上一级界面或操作的数据,不一定能这么操作。

    如果确认可以直接跳转,web 的话可以直接用 url 跳转,app 可以用 deeplink 或者手动启动指定 activity(android)等方式。

  • 针对这个场景而言,这个设计有一些问题:

    1、需求 1 看起来还比较正常。虽然返回 pageB 有点怪怪的,但实际上如果确实简便一些倒问题不大。
    2、需求 2 本身有问题,怎么确保不在 B 页面就一定在 A 页面 ?如果用户实例化 B 页面只是为了判定当前是否在 B 页面,而非跳转到 B 页面呢?这个绑定太死了。

    如果针对单纯技术而言,这个应该就是引起循环依赖了。解决也很简单,
    1、抽离相互依赖的部分到一个第三方类里( a->b,b->a 变为 a->c,b->c )
    2、干掉其中一个方向的依赖(比如 PageA 就别返回 PageB 了)
    3、引入依赖的时机从全局改为局部(比如 pageA 里面只有 goPageB 方法里才特别加上 import pageB )
    第三种可能比较适合,不过治标不治本。

    核心还是设计问题,为了一个特定场景的简便,把每个类的边界搞得很模糊,想把这些类变成 “万能类” 是很危险的。跨类的操作尽量还是放到用例层级,而非 page 级别吧,虽然写起来代码稍微多一点,但逻辑清晰很多。组合才是最灵活的。

  • 我指的不是技术层面怎么采集数据,而是业务层面怎么样的数据才能起到比较有效的度量效果。

    这块一般需要和 leader 或者需要用到这些数据的各个业务团队的同学沟通吧?

  • 不知道。。。

    从 MDN 看,应该是从 63 版本后支持的: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/webdriver

    也查了下 https://github.com/chromium/chromium 上的 issue ,没搜到相关的问题。建议你如果确认有问题,可以给官方提个 issue,让官方答复你?