如何汇报自动化测试的成果
![如何汇报自动化测试的成果](https://static001.geekbang.org/infoq/7c/7c79065f79341f57649c4d3ea1539da6.webp)
星球里有同学问了这样一个问题:自动化测试开展了一段时间,现在需要给领导汇报成果,该怎么汇报?表面看起来这是一个技术问题,实际上这是一个向上管理问题。
那么该如何向领导汇报自动化测试创造的成果呢?我们不妨从它的源头出发,思考这几个问题:
为什么做自动化测试?
预期的目标和结果是什么?
过程中解决了哪些问题和痛点?
想清楚做自动化测试的原因,能明确做自动化测试的预期目标和评估标准,解决了团队面临的实际问题,且最终的成果没有偏离预期目标,也拿到了预期甚至超过预期的结果,那就是好的成果。
首先,为什么要做自动化测试?这个问题相信各位技术同学特别是测试同学心里都很清楚:将人力从重复性工作中解放出来,提高单位的人效比。
一般来说一个长期迭代的项目,核心业务流程和关键分支,整体不会有太大的变化,如果每次版本迭代或更新都去手动执行相关的测试用例,从性价比来说肯定是不高的。因此采用自动化执行的方式,将这些测试用例转化为机器执行,既可以提升测试用例的执行效率,也可以释放测试同学的精力在更重要的事情上面,一举两得。
至于是选择 UI 自动化测试还是接口自动化测试抑或单元自动化测试,就是具体问题具体分析的范畴。
其次,自动化测试好歹是一个软件工程实践,在落地之前肯定要明确预期的目标和度量评估标准,以便于在落地执行过程中不偏离目标,可以有效掌握工程整体的进度和实施效果。
预期目标其实很简单,提升效率,怎么算提升效率呢?要选择一个对比对象,比如相比于做自动化测试之前,测试用例执行耗时缩小了多少。以一周一个版本迭代为例,大体的研发测试节奏如下图所示:
![](https://static001.geekbang.org/infoq/2d/2da03796005feef0a19fb842666f5cac.png)
其中测试验证(执行用例)大约占整个测试过程的 50%时间,且每个版本除了执行新增的测试用例,原有的主流程和核心分支用测试用占比也不小。以我的经验来说,功能测试一般一天验证 120 条左右的测试用例,强度就已经不低了。如果能将重复性的测试用例用机器执行,在一个版本迭代中,测试就可以节省几个小时的执行用例时间,将精力放在用例设计、风险评估、工具开发和基础设施优化方面。
当然,自动化测试落地实施自然不可能这么简单,要编写和维护脚本,要解决测试数据有效性和测试环境稳定性等方面的问题,这是第三个问题要回答的内容。
第三个问题:自动化测试实施过程中解决了哪些问题和痛点?这个问题不仅是很现实的工程实践要解决的问题,也是高频的面试题。在自动化测试落地实践过程中,一般要重点解决这几个问题:
测试数据维护管理:用 Excel、配置文件还是数据库?造测试数据的能力能否为研发联调和自测赋能?
测试环境的稳定性:环境的稳定性极大的影响整体的测试效率和测试结果的准确性,但这是长期基础设施建设范畴。
测试用例精准匹配:随着业务的不断迭代,测试用例沉淀了一大堆,但也会有失效的,可以通过测试用例集来解决。
解决了这些问题,才算是自动化测试真的落地实践,达到了预期目标并拿到了好的结果。
最后,回到最初的问题,该如何向领导汇报。
首先要明白的一点是,给领导汇报的内容,最终会由领导向更高层汇报,因此抓住重点内容,适度包装很重要。其次自动化测试的内核还是提升效率,需要找到对比对象并且有明确的数据支撑成果。最后,落地过程中解决了哪些影响效率和质量的问题,是否能为团队发展提供赋能也是需要考量的因素。
如果是我来做自动化测试成果的汇报,我会从这几个维度来介绍:
1、相比于实施自动化测试之前,实施后的测试执行效率提升了 X%;
2、测试用例有效覆盖了 P0/P1/P2 场景占 X%,每版本人效提升了 X%;
3、落地过程中识别了 N 个潜在风险,解决了 X 个影响质量和效率的问题;
4、实践过程采用了新技术,提升了环境稳定性,为后续 X 项目积累了经验;
5、预期结果是 X,在 1-2-3 阶段各自达成的效果是 Y,符合或者超过预期 N%;
6、后续打算从 XYN 不同角度去优化,解决 X 问题,扩大覆盖范围,为 D 团队赋能;
其中 1 和 2 代表了提升效率,3 和 4 代表了风险预防和技术视野以及技术体系建设,5 是汇报给领导的成果和结论,6 是未来规划和赋能协作。
版权声明: 本文为 InfoQ 作者【老张】的原创文章。
原文链接:【http://xie.infoq.cn/article/316ca91dadb96035b7202a52c】。文章转载请联系作者。
评论