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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。