登录注册
最新博客
最新资源下载
2016年奥斯卡文章之续传
活动主持人2018-06-12 11:50
相信大家都看过一篇世界名著《
PDCA 质量环之实践-----测试推动开发质量的改进》，
没错，作者就是本人。
很荣幸，凭借此文章，获得了当年的实践者论坛奥斯卡奖杯。
这篇文章的核心思想是：
以bug回溯的方式来推动开发自测，以提高代码质量， 并且，不断地收集晾晒数据，来检验成果。
2017年，我们也并没有消停，仍然在推动开发自测的道路上探索。
的确，又往前稳稳地迈了一步。
你是不是很好奇， 我们还能玩出什么花样来？
的确，也不是什么新花样。
新功能，QA不再测试了！
吃瓜群众： 啊？ 新功能不测试？ 那谁测啊？
鄙人： 开发呀！
吃瓜群众： 开发那么厉害呀！ 他们测试效果好吗？
鄙人： 当然好啦！ 这个可是有数据支撑的。
在自测的道路上，我们逐渐地把开发的习惯培养起来，现在可以说是高度信任了。
Plan
蓝色的数据代表，
开发自测的通过率
橙色的数据代表，
QA执行通过率
戳完了图，大家肯定得到一个结论： 两组数组相差不大。
那既然相差不大， 为什么同样的用例，我们要执行2遍呢？
就那么不放心吗？ 而你不放心的又是什么呢？
你不放心的不外乎两点：
第一，对测试用例的不放心
开发的自测用例，对于整个系统覆盖的完整度怎么样？ 够吗？
不够！
但他们只需要保障自己开发的新功能，包括正常逻辑、异常逻辑、以及和其他模块耦合的功能
也就是功能点
100%
的用例。
这部分用例，理所应当是QA提供的。
而QA的重心也必须由测试执行，切换到用例设计上
而这不恰恰是我们QA的核心价值么？
当然，QA还需要像用户那样，做场景测试，俗话说就是多个功能点串起来的测试。
除此以外，还需要保证无兼容性问题。
请相信，我们还有
回归测试、 预发布测试、 线上验证，等多重环节来保障质量的。
第二，对于线上质量的不放心
如果QA不再测试功能点，会错过些什么？
我们从jira上拉取了2个月
8个版本的bugs
对所有的bug进行了归类分析，得到以下的数据
如果不做功能点的详细测试，一些细枝末节的bug可能就会放过了。
Normal级别的bug大概只会Catch到目前的77.4%，Minor 会更低点。
但是， 那又怎么样呢？整个团队对bug的态度，难道真的是零容忍么？
如果不是，那就放下QA对自己高标准高要求的自尊吧
退一万步讲，
互联网行业区别于传统行业，不就是快么！不就是修复成本低么！
通过以上数据的分析，我们明确了两件事情
第一，开发是完全有能力做功能点全自测的
第二，QA不做功能点测试风险是较小的
We Do
我们及时地把我们的想法传递给了项目经理，和开发领导。
项目经理近一年来，见证了测试在推动代码质量方面做的努力，也深切地感受这样的实践活动对项目团队带来的收益。
本着资源不浪费的原则，决定可以一试。
开发经理有所顾虑，这也可以理解，毕竟需要让开发同学来承担质量的风险了。
但是看到我们收集的数据，有理有据。
加之觉得测试这几个女同学平时都挺有责任心，做事很靠谱，合作很愉快，人也长得极其漂亮就答应了。
上面后半部分理由是我YY的。
但是，结果就是答应了。
而我们，得用更加积极的态度，更加多维的数据统计方式向团队来证明
开发功能自测+QA场景保证，这样的方式是有效的。
我们引入了一个新的数据统计的维度----变更代码覆盖率，来提升团队的发布信心。
每周在上线前，从CR平台（杭研质量保障部自研的平台）获取到变更代码覆盖率，
然后对代码未被覆盖的部分，作以分析，查缺补漏，及时补充手工或者自动化用例。
把最终的覆盖率发给项目团队的成员。
我们有了更多的时间，来维护自动化用例，我们的核心模块，行覆盖率一直保持在85%左右
当然，我们还必须得对开发的自测质量进行持续有效的跟踪。
对每个版本的发现的缺陷进行分析，评估是否可以通过自测用例发现，如果有这种现象，则需要及时组织用例执行人员进行回溯和总结，也趁机听听开发对测试用例的反馈。
Check
上面一张图，很好的诠释了我们推动开发自测的路程
第一个阶段，推动冒烟自测，开发bug率下降的效果立竿见影
第二个阶段，推全自测，bug率也由0.6，下降到0.4以内
第三个阶段，
QA不再验收开发自测过的用例，bug率并没有明显下降，这也从另一个方面说明，开发与QA测试，无太大的差异，测试也无明显的遗漏。
但，阶段三，却能节约测试执行的时间， 使得进度节奏加快。
大家可以看下图
7、8、9月份，开发人力上升的情况，现有的测试人力，仍能游刃有余，
而且，还能保障得更多。
Action
开发新功能点测试+测试场景保障的测试策略，目前已实践4个月，仍然会继续走下去。
本文来自网易实践者社区，经作者李丹授权发布。
分享至：
