登录注册
最新博客
最新资源下载
没有秘密武器， 你还敢推开发100%自测？
活动主持人2018-06-12 17:01
Q: 听说你们项目组QA不做新功能测试了，你们是怎么做到的？
A: 我们推行开发功能全自测已经有一段时间了，这一过程并不是一蹴而就的，在去年奥斯卡奖得主的最新一篇文章
《2016年奥斯卡文章之续传》里可以看到这个事情的前因后果，大家可以清晰地看到我们的整个推进过程。
Q: 哦！那篇文章很火爆，我看过。虽然不测试新功能，但是保障维度也很多。除了传统的接口覆盖率， 还有一个
变更代码覆盖率的统计，听起来很有测试特色，能讲讲那到底是什么吗？
A：我们知道，当前线上版本是一个经过充分测试、质量较好的版本，QA测试的总是新一轮迭代里将要发布的版本，和线上版本相比，两者在本质上是代码发生了变化。这些变更代码往往隐藏着质量风险，而在手工测试后对变更代码覆盖情况进行分析是一种有效的控制质量风险的手段。
Q：能具体讲讲你们是如何应用的么？
A：杭研的CR平台可以进行变更代码覆盖率的统计，我们将几个重要模块接入了杭研CR平台。在一个迭代中，我们先进行手工测试，然后通过CR平台分析这些模块中未覆盖的变更代码，并判断其风险。
Q：那你们通过变更代码覆盖率分析后，还能发现bug么？
A：可以的，不过不是很多。在观察变更代码覆盖率分析后的一个月以后，我终于发现了第一个bug。那是新增的一个工单管理的页面，功能不复杂，测完后感觉该测试的功能点都覆盖了，然后我查看了下这个功能对应的变更代码覆盖情况，发现有个导出工单功能我没有覆盖到（妥妥的漏测呀。。。），于是我就去点击了下这个导出按钮，心想应该不会有多大问题吧，结果导出的excel内容根本对应不上！
Q：哈哈，确实能
查漏补缺啊。 这个工具想必测试负责人应该蛮喜欢的。 因为还可以跟进其他测试同学的测试执行是不是充分呢！
A：你说对了！最近手头刚好有一个bug，就帮助我检验了其他QA同学测试是否充分。
Q：哟？说来听听？
A：我们先来了解下需求和开发实现方式：
需求描述：在文本聚类审核页面根据关键词搜索查询时，会出现报错操作异常，需要优化。
开发解决方案：经排查，由于未走正确的索引，导致查询超时，因此系统报错操作异常。折中方案：当输入关键词进行查询时，查询结果的排序功能不生效，以此避免走错索引导致查询超时。
这个需求当时是另外一个QA测试并验证通过的，然而我在进行变更代码覆盖率分析时，发现该需求对应的变更代码覆盖率为0：
开发只改了一行代码，我自己在测试环境里验证了下，发现输入关键词查询时并没有报错操作异常，但查询结果的排序依然是生效的。再仔细看下代码：
原来是当keywords.size()>1时，才不会进行排序，而我测试的时候只输入了一个关键词，因此keywords.size=1，不满足keywords.size()>1。而系统没有报错的原因是因为测试环境的数据量较少，所以即使数据库索引错误也没有导致查询超时。如今我们项目组的QA团队也慢慢扩大，每个QA的能力、经验也是不同的，你可能不清楚其他QA同学到底测的怎么样。如此，
我们可以通过变更代码覆盖率，来帮助检验QA团队整体测试的充分性。
Q：哇，确实如此！在团队日益壮大的同时，如何保障整体QA团队测试的充分性需要有一些量化性的指标来帮助团队负责人进行评估判断，变更代码覆盖率确实是一个很好的指标维度呢！那么除了检验测试覆盖的全面性和测试有效性，你们还有其他收获么？
A：
我们还一眼看出了开发代码的正确性
Q：一眼？这么厉害？
A：来，看代码：
从上图代码中可以看出，可以看到右下角红框圈出的代码应该是复制代码后没有改正确，明显是与前面的判断条件不相符的。我们和开发确认后，开发表示这里的判断逻辑有点冗余，后续也会对这块代码进行重构优化。我觉得通过反馈这样的问题，也有助于提高开发的代码规范意识。
Q：哈哈，这个不错，看来以后开发同学在复制粘贴代码的时候要格外小心了。
A：不仅如此，通过变更代码覆盖率分析也提高了我们阅读代码的能力，
还可以帮助我们在前期进行精准测试
。有一次我就在测试执行前先进行代码review，然后发现了开发的一个bug呢！
Q：代码review？这一般不都是开发做的么？
A：我觉得开发做代码review和QA做代码review的角度不一样，QA做代码review更像是一种精准测试，我们找出某个需求对应的代码改动，分析代码改动部分的影响范围、实现的业务逻辑是否满足需求，以此来确定我们的测试范围，设计对应的测试用例。
Q：能举个例子么？
A：之前有这么一个需求：
需求描述：用户若在自然月1号首次配置保底消费，当月照常计费，若在除1号以外的日期首次配置保底消费，当月不计费
接到这个需求后我没有立马进行测试，而是先看了下开发改动代码的部分。通过代码review，我发现开发把首次配置保底消费的操作时间和编辑操作时间混用在一起，也就是说，如果在自然月1号首次配置保底消费后，过了一段时间再编辑它，那下个月本来要结算的保底消费就不会结算了，这可是比较严重的bug呢！然后和开发进行核对后，又衍生出了一些需求上的不明确点，经过讨论后我们共同确定了测试点，最后测试完成后变更代码覆盖率也达到了100%。
Q：听上去真是不错呢，看来你们通过变更代码覆盖率发现了不少潜在的bug呀！
A：哈哈，能发现少量的潜在的bug，不过我觉得
分析变更代码覆盖率的目的其实并不是为了发现bug，而是分析未覆盖代码的原因和风险。有些代码很难被手工测试覆盖到，比如抛出异常部分。如果未覆盖的代码风险较小，我们认为也是没问题的。
A：对了，我还想补充非常重要的一点，
变更代码覆盖率对接口测试的帮助也是非常大的。
Q：接口测试？这又是怎么一回事呢？
A：在我们项目的实践过程中，我们发现很多手工测试未覆盖的代码是由于前端操作做了限制导致无法覆盖。比如一个查询接口，开发会对其中的参数做各种各样的判断，例如像这样子的代码：
我们在页面上操作时，前端会限制一些操作，比如不允许我们输入的时间<0，因此后端接口类似这种参数校验的代码行我们无法通过手工测试覆盖，但接口测试就可以。因此我们看到这些未覆盖的代码时，可以及时补充我们的接口测试用例，有些开发的思维是很缜密的，也有助于QA完善遗漏的接口测试用例。
Q：没想到变更代码覆盖率有这么多的用处，真是一件测试利器呀！我还有一个问题，你们对变更代码覆盖率有什么评判标准么？比如变更代码覆盖率要达到多少以上才算测试通过？
A：CR平台上会给出一些评判标准，比如综合风险分、风险等级、覆盖率等级等，大家可以参考一下。至于覆盖率一定要达到多少才算测试通过，我们并没有一个具体的指标，不过几个月下来，我们每次上线前整体变更覆盖率基本能达到80%以上，但主要还是看未覆盖代码的风险程度，如果测试结束后整体变更覆盖率为60%左右，未覆盖代码的风险程度较低，我们也是能接受的。
Q：恩恩，这些评判标准确实需要因项目而异。那你们能谈谈在变更代码覆盖率分析的实践过程中，有什么值得注意的地方么？
A：一个是要对变更代码覆盖率有正确的期望，发现潜在的bug只是其中一方面，更重要的是对未覆盖的代码进行代码风险判断，并评估本次测试范围的全面性和测试执行的充分性。另一个是将它流程化，在每次版本迭代中合理预留时间，并坚持记录变更代码覆盖率分析所发现的问题，当你回过头总结时，你能愈发感受到它带来的好处。
本文来自网易实践者社区，经作者叶子授权发布。
分享至：
