腾讯移动品质中心TMQ [腾讯 TMQ] 管家 12 大版本质量把控秘籍
作者： linglingxue
六脉神剑秘籍
说起一年一度的管家大版本，那可是一个浩大的工程，管家各大中心都会参与，变更代码线多，版本稳定期久，对各个中心正常的单周迭代需求合入影响大，这质量把控起来想想都有点头大啊。
今年的管家 12 版本也不例外，而且 pm 用倒推时间的方法，掐头去尾，留给研发的时间只有一个月！打磨期一个月！开发测试都震惊了！各种抗议无效后，只好想尽一切办法努力达标了。
过程的艰辛先略过不表，最后的结局还是令人满意的。研发如期完成，测试第一次承担的打磨率质量指标超过预期！咱的表面很平静，内心贼激动！这说明咱今儿的质量把控手段还挺有效的嘛。
故呕心沥血提炼出六脉神剑秘籍如下，特此发帖共邀天下武林豪杰品鉴。
一脉：需求技术评审
先有 onepage 评审，一句话需求，再加一张视觉稿，看起来很美很简单，各路大神没有太多意见；
详细需求评审来了，会议室炸开了锅，怎么这么多逻辑，一个月怎么可能，再给我一个月也完成不了啊；
拉上各方老大一起评审，经过激烈 pk 后，逻辑能移到后台的咱就移到后台，能简化的咱就简单点，终于 pk 到产品、客户端开发、后台开发、测试、运营同学都点头同意。
心里有了底，咱就出计划吧。开发计划先出，测试 MM 看了开始软磨硬泡：
- 开发 GG，你看这个数据上报干嘛要放到后面才提测，最好和业务一起提测比较好，不然我们测一次上报，相当于多回归一次功能啊！
- 开发 GG，你看这个需求提测日期能否拆一下，这几个需求分批提测比较好啊，都同一天提测，没有那么多人同时开测啊。。。
- 开发 GG 勉为其难优化下计划，测试 MM 把测试计划一合并，一份各方基本满意的计划终于出炉了，项目正式开工喽！
每日一会走起！质量日报发起！
本篇招式：
招式 1：在需求和技术方案评审时，测试建议和支持变更较少的方案，以缩小新需求改动的影响范围，降低质量风险；
招式 2：优化开发计划，控制分批提测，关联需求合并提测，以缩短测试独占时长；
二脉、基线控制
去年打磨率居高不下的原因有哪些呢？分析出一个很大的原因就是开局就错了，从一个不稳定的版本上拉了开发线，结果外发后改的大部分 crash 都是历史遗留问题！这种错误今年一定要规避！再说咱都要开工了，第一件事不就是拉代码线么，这个线怎么拉，看来要好好讲究一番。
于是一拨人开始了轰轰烈烈的拉代码会议评审，大家各怀鬼胎但又目标一致，pm 希望不要封线太久，开发希望合线简单点，测试希望线变更尽量少点，大家的目标都是版本外发后 crash 率不要太高。
各种拉线建议提出，最后终于取得一致意见，没有稳定线咱就等稳定后多合一次！测试自然也要多一次回归，于是大家都把计划改吧改吧，重新打印出来，贴在日会的白板上，日日审核。
本篇招式：
招式 3：基线控制，从外发稳定版本拉线，作为基础版本，确保从稳定线上合入新需求，规避历史不稳定需求对打磨率的影响；
三脉、版本变更控制
版本变更控制贯穿整个开发实现过程，所谓知己知彼百战不殆，咱也把各种变更来源总结了下，见下图：
知道了来源那就好办了，监控每个变更，分析变更的影响，然后采取测试策略保证之。
本篇招式：
招式 4：版本变更控制。开发合入变更分析，确保没有错合、多合、漏合，确保耦合影响得到分析，确保冲突得到正确处理；
四脉、测试策略和手段
测试策略和手段老多了，咱也提炼总结了一把关键招式，在研发阶段的分布情况如下：
干巴巴一张图实在难以倾诉完咱满腹的言论，接下来再流水账方式展示一下各个招式在管家 12 中的应用情况。
4.1、开发阶段
开发 GG 吭哧吭哧的在那码代码，测试们也不闲着，测分文档先写了，黑盒和灰盒的测试点先写了，想一想还有什么要准备的，赶紧提前准备了。
比如各种 bvt/冒烟、代码扫描的自动化，从拉线开始咱就搞起来；
那
个 mttf 自动化机器好几台机器都挂了，务必要在开发提测前全部维护好；
性能自动化，也要全部搞起来；
那个精准后台，也要赶紧提前熟悉下，等开发提测的时候，咱就是熟练工了
。。。。。。
4.2、提测阶段
开发 GG 开始提测第一批代码了，框架代码出来了！测试 MM 赶紧开始写代码测分，为了精确的测试策略，为了尽量短的测试独占时长，还是看代码心里踏实点。
终于第一个需求提测了，测试同学全面转起来，合作伙伴开始执行写好的用例，测分同学继续深入分析代码，精准咱的测分，把控咱的质量。Bug 提起来，变更监控起来！
哎哟，产品同学你这个需求之前怎么没说过啊，现在提出来，好大的进度风险！产品同学磨嘴皮，这个必须做啊，之前我提到过，只是没有和大家深入说啊。。。
开发和测试无语，腹诽并口头抱怨之后，表示这一部分加班加点还是可以在计划时间内完成的，另外一部分也没那么着急吧，延期一下吧。
4.3、测试阶段
每日晨会的 pk，每日无数的沟通，怎么会有那么多需要协调和推动的事情！
需求提测了 bug 趋势必须是高峰啊——赶紧盯紧点测试进度、
bug 修复趋势怎么高峰还没来——又要去催开发改 bug 了、
自动化失败了—— 一堆机器要维护、
需求细节理解不一致了——赶紧拉人确认吧、
计划提测的需求怎么还没提测——进度有风险了、
产品走查完了没——界面好像不太好看啊、
Crash 各个中心都有啊——要推其他中心去改了
。。。。。
4.4、稳定性专项
除了日常的版本质量和进度风险把控，横亘在咱心头的质量标准，还有一个打磨率啊，除了拉线，咱也得在版本外发前，想尽一切办法，发现一切能发现的 crash，解决一切发现的 crash。
首先，手工挂 app 测试必须上；稳定性自动化不用说，跑起来；嘿嘿，咱还有个秘密武器，上半年总结了一些稳定性代码规则，自动化实现了，白盒测试起来，发现问题一律提单，一个问题一个单！
好嘛，一波一波的稳定性 bug 提起来了，不解决可不行啊！拉群，不管是哪个中心的问题，一律推动起来，在某某日期前务必解决了啊，没动静的话，咱就把开发老大也拉进来，效果果然显著。最后所有稳定性问题，能解决的全部解决掉，实在不能解决的也全部有了结论。
。。。。。。
本篇招式：
招式 5：持续集成和持续验证在拉线后立即接入，以及时发现风险问题；
招式 6：变更代码进行测分，精准测试策略，以提升测试质量，提升测试效率；
招式 7：稳定性手工、自动化、白盒测试全方位测试，发现问题解决率推动 100%，以最大程度的提升版本的稳定性，降低打磨率；
招式 8：性能、兼容性等测试纬度，专项专人推动，以全面保障质量；
招式 9：质量日报，多维度展示当前版本质量和进度，并分析预警，及时协调推动解决，以最大程度确保风险得到控制，进度无延期；
五脉、线上质量监控
一个月嗖的飞走了,按照严格的质量标准来说，还没完全达标，但也没有对用户影响较大的遗留 bug，大家评估一下觉得可以按时支线外发几天看看，测试表示同意，不过咱的职责就是给大家报告版本质量和风险的，所以就老老实实的报告说质量不达标！
支线外发时间内，挺安静，crash 没超标，也没啥严重用户反馈，开发和测试心中暗喜。于是原定计划不变，8 月初按期开始外发大版本喽！
打磨率啊，心肝颤。第一个外发版本 crash 一下子就超标了，版本立即停量，早就潜伏好的开发 GG 快速定位到原因，赶紧修复完，发新版本！
小心肝继续颤，嘿，crash 情况正常啊，还挺低。稍稍放心，继续观察，crash 一直处于低位！传说的打磨就要完成了？
达标了！而且只有一个打磨版本！高兴的小火苗刚燃起来，就被老大告知不要高兴的太早，这个打磨率是要看一个月的数据，在这一个月内还有几个计划内的大需求要合呢。我去，这打磨率真折腾人。
本篇招式 ：
招式 10：支线外发和主线打磨期内，实时关注用户反馈和 crash 率，高优先级推动解决 top 问题，以降低打磨率；
六脉、合入控制
于是 8 月一个月都在密切跟进每个合入的内容，搞的我都像 pm 了，开发跑过来问我，我这个需求能不能合啊，怎么合啊。我说，对不起，非严重用户反馈和 crash 不能合，非计划内需求不能合。开发苦着脸走了。
漫长的 8 月终于结束了，crash 率一直没有超标！心里的大石头终于落了地。真不赖！咱能控制的能整改的看起来都奏效了，心底一阵雀跃，彻底一放松，好嘛，这个大版本事情终于告一段落，终于可以做其他事情了，还有好多重要但不紧急的事情要做啊。
本篇招式：
招式 11：打磨期内，控制非计划内需求、非严重用户反馈和 crash 的合入，以控制版本变更风险；
结尾篇：
天下武功唯快不破，身处互联网行业，快速发版的节奏，对测试独占时长提出了愈来愈高的要求。如何兼顾质量和效率，是一个互联网测试人摆不脱的命题。
罗哩罗嗦说了这么多，也不知道这秘籍是否令您心动。如果您有一丝功力见长，那这篇文章就算没白发。要是您练了之后功力大增，想来也不会危害四方，多半会造福天下，咱也算修了一份功德，善哉善哉。
本章完~
原文链接：enter link description here
TMQ（腾讯移动品质中心）是腾讯最早专注在移动 APP 测试的团队
我们专注于移动测试技术精华，饱含腾讯多款亿级 APP 的品质秘密，文章皆独家原创，我们不谈虚的，只谈干货！
扫码关注我们
