遍历测试，关注得最多的是测试覆盖率这个指标。覆盖率可以看细粒度的代码行、方法覆盖率，也可以看粗粒度是 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 以上两者均可在代码合入时根据代码修改，实现定向测试。

结尾

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