UI 自动化测试之 "织网"

[jy0529]

最近在公司项目中思考与落地 UI 自动化测试，便有以下"织网"的故事。

找出潜伏者

Bug 的生命周期大概经过出生、潜伏、发现、被杀死四个周期，而自动化测试的目标是: 提高版本上线前发现 Bug 的成功率和效率。

织网

如果把 Bug 比作 "漏网之鱼"，漏网的鱼会吃掉我们的蛋糕，为了别让蛋糕被吃光，我们来看下它是如何 "漏网"的。

1. Bug 也是人编程的产物，所以一定程度上依赖人的靠谱程度。
2. 人再靠谱，也有无法避免又合理的情况，例如：人的成长性、复杂环境、随机性等。
3. 于是有了流程: 需求评审 -> 方案设计评审 -> 任务拆分 -> 自测 -> 本地测试 -> 预发布环境测试 -> 线上回归测试。
4. 流程相当于织了一张小网，它覆盖不了大部分区域，网眼也很大，加上第2点的影响，还是有很多 "漏网之鱼"。
5. 再增加 CodeReview 流程, 此举就像 "漏网之鱼" 跳出网后遇到了一个凶神面煞的 "捕鱼大哥"将其捕获, 可这取决于 "捕鱼大哥" 的信息、时间、经验程度，更何况 "捕鱼" 这种文化要建立起来多困难。
6. "捕鱼大哥" 虽好，但还是专心织网吧。
7. 给项目添加单元测试，很好的想法，相当于把网的覆盖面增大，但项目代码耦合度太高，能够进行单测的地方不多，估计 20% 行覆盖率吧，对项目整体质量提高影响不大。
8. 什么, 耦合度太高就重构? 重构前要有测试回归吧，但现在是因为要写测试才重构，糟糕，死锁了。
9. 给项目添加接口测试和 E2E 测试，立志要把覆盖面编织得越来越大，但项目接口没有一个标准化的定义，很乱，测起来困难，且 bug 占比 80% 在前端上，E2E Cases 不稳定，重构下又要维护了。
10. 得建立 E2E 测试的 ROI 模型计算，找出 高ROI 的 cases 去做自动化，并且提高单测覆盖率。
11. 终于，覆盖率提高了，将网编织得足够大，也困住不少 "鱼"了。
12. 但是，还是有不少 "鱼" 跳出来了，都是些小鱼，看来我们的网还是不够密啊!
13. 给项目增加变异测试，通过程序将代码进行变异存活测试，统计变异存活率，继续补充未杀死的变异代码的单测， 单测有效的公式 = 行覆盖率 * 变异杀死率。
14. 至此，______。

从历史中逃脱

任何没有测试的代码，都是历史代码。