自动化工具 关于遍历测试的想法交流

王稀饭 · 2021年10月13日 · 最后由 王稀饭 回复于 2021年10月15日 · 807 次阅读

遍历测试,关注得最多的是测试覆盖率这个指标。覆盖率可以看细粒度的代码行、方法覆盖率,也可以看粗粒度是 app 页面覆盖率 (Android Activity、iOS VC 覆盖率),下文以页面覆盖率展开讨论。

市面上的遍历测试工具(各种 monkey 变式、UI 自动化也能勉强算上)会有覆盖率天花板,总有部分页面不能单纯靠工具自动跑就能覆盖到,下面希望跟他家一起交流。本文不讨论提升测试覆盖率对最终测试效果的影响,这个要 case by case 来讨论。

遍历测试难以覆盖的情况

一、需要满足前置条件

  1. 前置打开某种开关才会进入的页面。常见于灰度打开的实验性功能,需要后台下发配置开关来打开
  2. 前置完成特定业务操作才进入的页面。比如要完成某种手势操作才能进一步测试的功能(手势解锁),或需要跟其他业务逻辑联动的功能(在线教育,同时控制学生端和老师端做问答交互)
  3. 前置准备特定测试数据才能进入的页面。比如 Feed 流业务,只有某种文章类型才会进入特定页面

二、天然测试限制

天然测试路径过深导致难以遍历到达的限制。

三、线下新增页面

线下开发需求而新增的页面(常见各种活动运营的页面),这些页面是全新的、首次出现的,没有任何的相关历史信息可用。

测试覆盖应该优先覆盖什么

在探讨如何去覆盖这些通过直接遍历难以覆盖的页面之前,还有必要弄清楚到底什么页面才更加需要线下测试覆盖,或者说应该优先测试哪些页面,为此分为下面 3 种:

  • 线上用户覆盖的页面:线上用户能访问覆盖的页面,线下当然需要做测试投入。用户访问量越大就越应该重视
  • 线下新增但未上线的页面:新需求引入的新页面,此时还未上线,线下测试必须关注
  • 部分废弃无用的页面:无要投入资源测试

一些测试手段

目前公司内部在用的有两种,均是建设迭代的状态,分别是:

  • 基于静态分析、覆盖率数据、页面寻路算法的定向测试:简单来说,基于代码静态分析可以拿到 方法->类->所属 Activity 的映射关系,最后利用覆盖率,可以确定某个测试路径是否能达到该 Activity,从而构成 Activity 维度的定向测试(是的,现在不支持 iOS)。优点是定向测试相对自然,定向到某个页面的测试效果每次都可能不一样;缺点是定向成功率无法保证,得看算法的先进性和训练数据的充足程度
  • 基于 schema 跳转的定向测试:优点是保证 100% 的跳转成功率;缺点是并非所有页面都有 schema 跳转,同时 schema 本身就带着参数,固定 schema 就等于固定了拉起页面的参数,使测试缺少数据输入上的变化,还要考虑如何收集 schema 以上两者均可在代码合入时根据代码修改,实现定向测试。

结尾

一般使用上述两种互相补充的定向测试手段,测试覆盖率在常规遍历测试之外还能有一些提升。再往上,就需要十分细化的能力支持了。比如在最前面抛出来的三种满足前置条件的问题,每个单拎出来都不好解决。吧友们如果对类似的建设经验,或在遍历测试的覆盖率提升上有所投入和了解,欢迎一起讨论~

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 8 条回复 时间 点赞

这两个手段以前都用过。基于 schema 会好用一点,而且参数其实也不会太复杂。

恒温 回复

schema 我们是在测试和线上去收集的,schema 本身倒没问题都能用。比较局限的是,一条 schema 就代表跳转到页面所带的参数是固定的,除非针对一个页面收集了很多不同参数的 schema,否则测试参数输入就会比较少,质量说服力就会降低了

说一个思路:既然 app 太复杂,覆盖不完全,可以降低 app 的复杂度。在某些 app 功能相对独立的场景适用,把不同的功能模块分开打包测试,比较容易能完全覆盖。

rihkddd 回复

这个意思是,把 app 的独立功能模块抽取出去单独测试这样?能举个例子感受一下吗?感觉这个是一个不错的思路,但本身如何识别功能独立也是一个很难的问题,尤其是在几百万行代码的项目中。

感觉楼主提到的难点,只有 UI 自动化能解决,monkey 很难解决。
而 UI 自动化又维护太累,想遍历每一个角落耗力就更大了。
目前用的字节的 fastbot,据说是阉割版,效果是有,但是感觉有限,发现的 bug 不多

秦岭 回复

是的,开放出来的 fastbot-android(只是开放并没开源),阉割得比较厉害,是内部测试能力整体表现最弱的版本。
另外fastbot-ios已经是正式开源了,应该是市面能找到的 top 工具之一,作为受益方给他们自来水一下。

回到整体,UI 自动化是真的累,而且要做到全覆盖真的不理性,也可以考虑 UI 自动化 +monkey,如果能使用 UI 自动化先定向走都一个路径,结合客户端一些页面操作的限制能力保证测试场景不会跳出,这个时候用 monkey 去遍历也是一个点。但这个思路依然无法完全解决上述的问题,只是算是手段之一,增加一下工具箱或者弹药箱的感觉。

王稀饭 回复

举个例子,比如微信,可以聊天、朋友圈当做两个功能,拆分开。确实依赖于 app 的业务形式,有些比较适合,拆分相对来说是个低频操作,可以结合构建系统实现自动打包拆分包。

rihkddd 回复

Get ~

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册