根据自动化用例精准测试探索.pdfVIP

自动化用例的精准测试探索 　　 　　在当前 web 系统或 app 后端服务测试过程中， 黑盒测试 占据了大部分的测试，即便 是接口测试 ，也是基于场景的用例设计 ，这种测试方法完全依赖于测试人员的能力，经验 和业务熟悉度，而互联网行业的一大特点就是人员流动性高，这使得线上质量经常是“靠 天吃饭”。基于黑盒的测试使的项目测试在测试过程中存在以下几个问题： 　　（ 1）黑盒测试受主观人为因素影响太大：黑盒测试完全依赖测试人员的个人能力， 经验和业务熟悉度，受主观因素影响太大，不确定性太多，这是产生漏测的根本原因。 　　（2）测试覆盖面无客观数据可衡量：测试对代码覆盖程度，质量高低，没有客观数 据可衡量，完全靠人为主观介定。虽然我们可以拿到全量或增量代码覆盖率数据（增量覆 盖率一般需要运行 2 次全量用例），但对增量代码具体路径是否有覆盖，只能靠人工分析 全量覆率报告，且无法区分哪些是原有代码，哪些是 diff 代码，在代码量稍微大点的项目 中，测试排期基本上不允许这种测试方式，从而把测试人员推向黑盒测试，由于没有代码 分析支撑，黑盒测试覆盖率随着时间和用例增多，便会触达覆盖率的天花板，更多的是重 复的无效测试。 　　（3）自动化用例作用无发有效发挥：对于 web/api 或 app 后端服务系统，测试人员 对除手工测试外，尝试最多的测试手段改进就是接口自动化建设，但自动化建设很少有公 司在这个方向做的特别好，投放产出比(ROI)特别高的，其根本原因就是自动化的一个核心 指标：稳定性太差，随着项目的迭代，自动化用例积累越来越多，从几百到几千，想要这 些自动化用例以 CI 级别触发(代码提交一次即触发一次) ，用例全部通过稳定在 80%以上， 几乎都是不太可能做到的事情。自动化用例稳定性太差，不能产生收益不说，反而会成为 QA 的包袱，使他们把大量的时间花在自动化用例失败排查上面，疲于应付，又不能发现 有效的 bug，久而久之，便对自动化失去信任，甚至废弃。 　　问题分析与思路 　　产品线后端服务是基于 java 的 SSH 框架搭建的，模块数量多， 模块间基于 rpc 分步 式协议通信，模块间耦合多， 各个投放系统业务逻辑都比较复杂，且 RD 和 QA 新人都比 较多，传统黑盒测试只能通过人员堆砌和不断的加班加点来适应不断扩充的业务，这使得 项目测试质量很难保持在一个较高水平，和业界面临问题一样，也无可避免存在背景中提 到的 3 个问题。产品线的接口自动化测试用例随着迭代积累，用例数多达几千个，如果让 这些自动化用例发挥它们的效用呢？ 　　对于背景 1，2 的问题，我们可以总结为：测试覆盖面是否可以很容易客观数据衡量， 测试覆盖面是没有置信度，且在达到这个置信度的过程中有没有工具可以支持 QA 更快更 有效达成？ 对于背景 3 中的问题，当自动化用例数到千级别的量级，若 100%每次都让这 些用例全部运行通过，几乎是不可能的事情，那我们能不能减少这些用例数量呢，每次只 运行和代码变更相关的用例，将无关用例的筛选出去呢？ 　　通过对业界和公司其它产品线一些调研，我们发现有些团队也有在这些问题上做一些 探索，即精准测试，但基本上都是聚焦在第 3 个问题上，即通过用例筛选来减少用例执行 以提高升 CI 的稳定性，思路基本上相同，只是实现过程不各不相同。公司内部一些团队尝 试也是基于不同的产品特点，如 app 和前端模板，实现过程不同，这里不再赘述。我们探 索方向是，适用于后端服务模块(web 或 app 后端服务，或 api ，不局限于实现语言) ，基 于接口自动化的精准测试，并将这个概念做了扩展，不再局限于用例筛选，而是 3 个层面， 即： 　　（ 1）自动化用例筛选 　　（2）测试影响面范围评估 　　（3）增量代码覆盖率分析 　　下面具体解释一下这 3 个层面的含义。 　　我们方案/设想：基于自动化用例和覆盖率信息，获取单个自动化用例对应代码覆盖路 径信息，并建立相应的映射库（知识库），做为数据源。 　　基于获取的映射库信息及系统提供的附加能力，支持以下 3 个基本场景: 　　（ 1）自动化用例筛选： 在生成用例和代码覆盖路径映射库信息后，当 RD 提测时， 可以根据代码 diff 计算出变更的方法列表(新增/修改/删除) ,用方法列表反查映射库，便可 以筛选出与变更代码相关联自动化用例，与 CI 相结合，达到精简用例，减少执行时间， 同时减少不必要的用例执行，进而提升 CI 稳定性，减少 CI 维护排查代价。 　　（2）测试范围评估：与场景 1 相似，在 RD 提交代码代码后，