登录注册
最新博客
最新资源下载
项目代码质量的推进之路——BUG率一路向0
阿凡达2018-08-10 09:35
前言
在教育部门集中推动代码质量改进的工作已经半年有余了，这半年来，教育部门的所有产品线的提测质量提升很快，整体的项目质量也有较大的提升。具体体现在：Bug数量和Bug率持续下降，很多项目的bug率标准从不及格（1.5Bug/人日以上）->及格（1.5—1Bug/人日）->良好（1—0.5Bug/人日）->优秀（0.5Bug/人日以下），最终稳定在优秀级别。结果可以看出，我们取得了很大进步，项目质量有很大的提升，此时我们应该感到欣慰（付出终得回报）。结果固然喜人，但是回想项目的推进之路，也是一路坎坷，大有不堪回首之势。期间我们有过质疑、有过讨论、有过忐忑、有过争吵也有过激动、有过喜悦。可以说在推进之路上，伴随着酸甜苦辣，过程固然艰辛，但是大家一定愿意回想，因为这是我们最美好的回忆。在路上我们发现了问题、分析了问题并且通过我们的努力也解决了问题，最终实现了通向优秀的康庄大道。
我将从3个方面：以往问题回顾—妙手回春—喜报连连，说明这半年的推进之路，实现了我们项目BUG率一路向"0"的目标。
一、以往问题回顾
俗话说：“必先知致弊之因，方可言变法之利”。项目代码质量的推进之路不是天马行空、漫无目的，而是有的放矢、对症下药，才能立竿见影、事半功倍。因此我们在推进代码质量时需要总结以往版本质量差的原因。版本测试过程中记录问题、通过代码度量平台收集数据，并根据数据分析问题原因等方法，将项目中出现的问题全部暴露出来。我们需要给项目成员打好“预防针”，我们暴露问题的目的是为了最终目标-质量提升，而不是开发个人的绩效考核，我们关注的是项目质量往更优发展，而不是统计本身。通过提前告知项目成员，有利于质量的推进，减少开发童鞋的忧虑（毕竟大家对kpi很在乎的），便于开发对该措施的认可并配合。接下来我将抛出我们项目代码质量的推进之路历经6个月的问题汇总，仅供大家参考，如有遗漏可以随时联系补充，毕竟我们的目标是一致的，提升项目质量，让BUG率一路向"0"。
1.1 需求篇
1.1.1文档粒度
目前大部分项目应该都存在文档粒度较粗的问题，在参与其他项目质量总结时，往往也会听到这样的问题。我将文档粒度较粗的问题又细分为两类a)需求功能描述遗漏或描述较粗；b)功能描述出现同线上...或同什么功能。也许在我们的日常工作中经常会听到开发或QA同学这样的抱怨声：“开发同学吐槽：1.该功能同某产品线上功能，我哪知道人家线上有啥功能。2.这个功能没有交互描述，校验规则是什么？算了还是交互稿写什么就实现什么吧。3.需求没有深挖，少估时间了，用开发冒烟做开发时间吧...等等。QA额外吐槽：1.文案开发主观写的，感觉不太合适呀？算bug不，交互也不说明，确认太花时间...等等”。大家有这样的抱怨是很合理的，毕竟我们的开发时间或测试时间都是比较紧急的，很难去花费大量的时间去确定需求，特别是没有争议的需求交互（校验规则、提示文案等等）。我个人认为交互稿其实相当于建筑的设计图，好的设计图必须要详细、没有争议且需要描述细节，如果设计图有问题，那么再牛逼的建筑师和质检师也不能保证建筑的质量。
该问题对开发的影响：
开发确认交互稿，导致开发过程不流畅，且会存在需求变更的风险，缩短开发时间，影响开发进度及项目质量。
该问题对测试的影响：
提测前确认：花费大量时间进行3方同步，导致缩短接口测试、ui自动化测试及个人技术提升的时间。
提测后确认：导致测试执行过程不流畅，且会存在需求变更的风险，缩短测试执行时间，影响测试进度及项目质量。
1.1.2 需求变更
俗话说：“唯一永远不改变是不停的改变”，但是对于需求我们还是尽量避免变动。因为在迭代有限的时间内随意的变动需求，会导致项目质量生产出较多的Bug。讲过我们对数据背后原因分析，验证了这一点。我将需求变更的问题又细分为两类a)需求功能实现后的变更；b)需求变更没有及时同步到相关人员。也许在我们的日常工作中经常会听到开发或QA同学这样的吐槽声：“技术人员吐槽：功能都已经实现了，怎么还修改呢？（压缩开发时间）。测试吐槽：测过一遍了，怎么还修改，开发要好好自测哈（压缩测试时间）”或“技术同学吐槽：这个需求什么时候变得呀，原来的交互稿不是这样子的？QA吐槽：开发实现的怎么和交互稿不对应呀？都没看交互稿，这么多自测bug……等等”。这样的问题势必会导致项目质量差。
该问题对项目的影响：
提测前需求变更，导致开发过程不流畅，且会存在设计变更的风险，缩短开发时间，影响开发进度及项目质量。
提测后需求变更，影响开发新版本的流程及开发修复bug时间，影响QA的测试进度。且需求变更容易引出新的问题致使项目质量不可控。
1.2 bug篇
以往开发的工作可能是这样：
我们可以看出来，开发一直在与bug打交道，不是在写bug，就是在定位bug，不是在定位bug，就是在修复bug，这是他们可能会自嘲“在山的那边、海的那边有一群苦逼的程序员”，是呀，这样的生活是挺苦逼的。但是更苦逼的是“开发修复了一个bug，还有一个bug。又修复了一个bug，还有3个bug，无休无止呀...”
虽然bug的生产者只有一个（程序员），但是产生bug的原因有许多，下面我总结下我们项目中产生bug的原因（为妙手回春做准备）：
1.需求自身问题产生bug
2.与需求理解不一致产生的bug
3.已有功能不了解产生的bug
4.自测不仔细产生bug
5.自测思路局限产生bug
6.新人问题
7.环境问题产生的bug
8.代码重构产生的bug
9.临时介入的bug（需求描述不清、已有业务不了解等）
10.其他产品修改产生的bug或我们修改公共服务或组件产生的bug
11.复杂性系统不可避免的bug
重点分析下以下产生bug的原因：
1 临时介入的bug
项目排期过程中，总会出现前后端工作量不一致或某些开发人员空闲的场景，本着自愿浪费可耻的原则，我们会充分的安排其任务，让其体现价值。但是总结项目问题时，会发现该安排会影响项目的质量。我将临时介入问题又细分为两类a)优化小任务临时介入；b)空闲人员临时介入。也许在我们的日常工作中经常会听到开发或QA同学这样的吐槽声：“开发同学：当初时间估少了，需求jira上没有描述清楚，产生这么多bug。QA：这个优化任务开发没有自测吧，bug真多...等等”。这样的问题势必会影响项目原来的排期及项目质量，引出额外的bug。
2 代码重构产生的bug
互联网产品快速迭代，版本的排期也是非常紧。如果开发前期没有对交互稿进行深入挖掘或设计不充分等，那么开发在实现功能中就不会有很好的解决方案，最终的结果是实现了，也提测了，但是编写的代码，恐怕就不忍直视了。对于我们网易高逼格的开发大神们来说，势必是不能忍的，因此他们会在提测后“偷偷”的进行代码的重构，我们在日常测试中也会经常发现。但是这一举措产生的问题就是项目的质量较差，产生的Bug较多，Bug的收敛较慢。也许在我们的日常工作中经常会听到QA同学这样的吐槽声：“冒烟测试时该功能还是好的，怎么现在有Bug了，哎哎...虚呀Bug不收敛呀，这个功能我都测过了，你说你重构了，让我重新测，那也前的测试时间不是废了，时间不够呀...等等”。产生的风险就是项目延期或是加班加点进行测试但项目质量不能保证。
3 自测问题产生bug（自测不认真、自测思路局限）
项目质量的提升，其中较为关键的一步就是推动开发自测，我们也在坚持不懈的努力着。但是在项目中我们发现开发自测存在两个问题：a)没有自测；b）自测思路不正确。没有自测的问题及危害，应该是不言而喻的。这类开发实现的功能势必Bug多，自测型Bug多，Reopen次数多，严重会降低项目的质量。对于此类开发QA的吐槽声尤为强烈：“怎么这么多低级bug，提个jira单的时间开发就能修复3个bug了。bug修复了需要自测一下呀，大哥！反反复复验证很花费时间呀！修复一个bug产生一个bug，再修复一个bug，又产生3个bug...”，造成bug多、bug收敛慢。对于开发自测思路的问题，也会产生一些可以轻易避免的bug，大家可能听过这样的吐槽：“分页、按照不同条件搜索pageindex初始化、搜索条件下的分页等功能至少要构造符合的场景呀？不然怎么自测呢？自测不仅仅是按照冒烟用例的！”，因为自测思路或是自测不严谨，会给项目生产许多不必要的Bug，降低了项目整体的质量。
4 新人问题
“长江后浪推前浪,一代新人换旧人”，项目组中必然会注入新的血液，这也是无可避免的规律。但是在项目中往往发现新人产生Bug的概率要大于老人，难道真的是不如“老司机”。项目中新人比较突出的问题：Bug生成多、自测型Bug多、引入型及Reopen较多。项目中QA和老司机经常吐槽“老人吐槽：还是经验不足呀，很多问题还是可以避免的。QA吐槽：大哥你要按着需求实现呀，多自测呀。”由于新人因素，往往降低了项目整体的质量。
1.3 环境问题
在日常测试过程中可能经常会发现环境相关问题影响QA的测试执行，花费大量的时间去定位环境导致的问题，导致测试执行时间缩短或是bug的误产生，给测试带来许多不必要的时间开销。在问题总结中，我将环境部署问题又细分三类：a)部署分支不正确;b)服务依赖不正确;c) 部署不成功。也许在我们的日常工作中经常会听到QA同学这样的吐槽声：“环境都没部署成功，分支没有部署正确dubbo依赖都不对，开发怎么自测通过了?冒烟blocker了，半天时间又浪费了，测试时间不够呀，心慌...”。这样的问题势必会减少测试的时间，测试不充分，项目的质量得不到保障。
1.4 上线问题
以前我们的上线可能是这样的：
上线至凌晨可以细分为两类问题a)通知产品走查时间点较晚且没有确定冻结时间；b)通知其他产品线回归时间较晚且没有提前约定回归时间。首先我们剖析下产品走查的问题。日常迭代需要产品及视觉走查，这个大家都知道，但是走查时间点及冻结时间点没有提前约定或约定的不正确，可能会为项目带来一定的风险。如果和产品约定的时间点较晚且没有冻结时间点，那么带来的问题是可能临近上线还会有需求方提出的修改，由于时间紧张，技术同学没有充足的时间去思考和设计，结果往往花费大量时间后发现无法解决（带来上线延期风险）或解决该问题又引出了其他的问题，得不偿失。由于部门产品线较多，且项目微服务化，因此彼此间有较多的公共服务。这样就会导致一个产品修改公共服务，其他的产品都需要安排QA进行公共服务的测试回归。如果我们通知其他产品线回归时间较晚且没有提前约定回归时间，那么可能会带来无法上线的结果。也许在我们的日常工作中经常会听到QA同学这样的吐槽声：“我在冒烟呀，你让我回归，都不会提前通知，没时间呀！呀！”。这样如果对方没有时间回归，我们上线虽然自己产品没有问题，但可能导致其他产品功能不可用（在项目中出现过该问题），或是我们延期上线，给其他产品QA留时间回归，回归完成后再上线，但最终结果都会影响项目的进度。
二、妙手回春
2.1 妙手回春-需求篇
需求问题在任何项目组，我想都是不可避免的。因为随着系统复杂度的不断提高、产品同学的新老交替等原因，产品同学确实不太容易考虑完全。因此针对需求问题，我们通过3种措施去推动解决。
1.需求测试
1.1我们通过交互评审前需求测试
1.2我们通过开发设计时需求测试
1.3我们通过测试设计时需求测试
2.我们通过首页需求变更记录
3.我们通过需求变更时，产品同事在小分队内艾特相关开发、测试
需求测试是解决需求问题最有效的方式，因此我们一定需要在组内推动需求测试。需求测试的形式应该比较多，本文举例3种：1）jira工单的形式记录需求问题；2）wiki页面记录需求问题；3）相关人员组建小群，问题实时抛出解决，不同项目可以根据实际情况选取。
我们项目组采取的是第3种形式，优势：开发及产品同学容易接受（工作量不大）且时效性较强。需求测试需要前提条件：技术与产品达成一致，避免在交互稿中出现“同...”文案，避免低级的需求问题。
可以看出上述3种方案是环环相扣，我们首先要求交互稿提前给出，开发和测试进行需求测试，在交互评审前解决掉大部分部分问题。然后再开发设计和用例设计时，由开发和测试去推动交互稿补全，进一步解决了交互遗漏或有争议的一些点，又进一步细化了交互稿。经常在项目组会和开发或测试同学说，如果经过开发设计或用例设计后交互稿没有更新，那就说明开发或QA有问题，是不负责任的。通过2、3中方案可以解决需求变更遗漏的问题。通过上述3个方案，我们已经基本解决了需求问题。
需求问题解决了，开发过程中不需要在面对需求讨论、需求变更的问题，开发的生活应该也比较悠闲一下，生活可能是这样的。
2.2妙手回春-提高设计和开发质量篇
如何将发现bug的时间早移，是我们需要关注的事情。毕竟‘bug越早发现，修复的成本就越小’。基于该原则，我们推动了一些措施去将发现bug的时间迁移，避免提测版本产生bug或减少产生的bug数。
我们的措施如下：
1.我们通过加强开发设计评审
将设计评审纳入项目流程，在现有评审基础上，将设计评审细粒度化，补充异常场景设计。
2.我们通过加强测试用例评审
1）用例粒度细化，例如：一条用例如果含有多个场景，需要拆分成多条用例。
2）重点表字段变更体现到用例中
3）邀请相关交互、策划和开发同学以小会议的形式参加，提早发现开发或测试应与需求不一致产生的问题。
3.我们通过测试用例交叉执行
完善用例执行流程，用例交叉执行，前端注重交互、功能逻辑的实现。后端注重功能逻辑及接口异常场景的校验。
通过上述方案后，我们项目的提测质量有了较大提高，开发的工作状态也发生的质的变化。
2.3 妙手回春-减少bug产生篇
通过2.1和2.2的方案，我们已经解决了大部分bug。但是我们是比较贪心的，因为我们的目标是“0”bug，于是我们又继续“鸡蛋中挑骨头”，由推出了一些措施：
1.web测试组内部定出bug统一规范，并各自在项目组内推广标准，避免测试误提bug，造成统计数据不可信的问题。
2.对bug较多的版本，举行回顾会，展开bug回溯，分析问题并总结应对措施，并在项目中推动
会议形式进行bug回溯，并邮件形式通知相关人员：
问题分析：
Hi all，
以下为本次bug回溯总结：
背景：接入整体bug较多，bug率高；冒烟质量不合格；上线延期。
1、质量状况：
- 习题考试模块总开发人日12个人日，另计3天联调冒烟时间
- 共计发现有效bug 66个，其中前端19个，后端47个。
- 相比7月份的企业云独立考试接入37.5开发人日，98个bug，接入功能更多，改动幅度更大，bug更少，但是bug率反而上升了。
2、暴露的问题
QA：
- 冒烟质量不过关：冒烟通过率只有91%，bug阻塞冒烟进度
- bug率高：习题考试部分bug较多，后端bug占比明显过高
- bug重复出现：部分bug重新出现，没有自测完毕就提测
- 修改bug后引入新的bug：逻辑关联较多，修复逻辑没有充分考虑影响
开发：
-
开发质量需要加强，加强自测，很多bug可以有效避免；
-
设计评审时过于乐观，评估粒度比较粗，没有充分考虑到接入改动的复杂性，尤其是和课程目录关联起来；
-
开发过程中应提需求给爱多思开发，而不是自己改动代码，耗费较多时间；
-
提测匆忙，自测不够，应该坚持质量优先原则；
-
开发估时和修改bug过于乐观；
-
冒烟过程config-server挂了，合代码工具有问题，影响测试进度；
-
评审应邀请所有依赖方，充分评分其中风险点并明确复杂逻辑部分；
-
适逢爱多思版本升级，依赖的新接口需要同步升级；
-
排期设计不合理，多个模块同时开发，分期提测导致部分功能不能正常使用；提测任务间会有依赖，需要多次合代码；
分析典型bug：
| 序号 | 级别 | bug描述 | 前后端 | 备注 | |
| EDU-14859 | Normal | 【考试接入】考核页面包屑未设置 | 前端 | 自测型 | |
| EDU-14999 | Normal | 正确添加了练习或考试的课件后，关闭了考核服务，点击提交审核时，提示信息不能传达是因为考核服务没开引起的，请修复 | 后端 | reopen | |
| EDU-15028 | Normal | 【考试接入】微专业后台，获取试卷数量有误 | 后端 | reopen 2 | |
| EDU-15134 | Normal | 【考试接入】未公布考核成绩，学生考核列表可见成绩 | 后端 | reopen | |
| EDU-14894 | Major | 【考试接入】学生前台获取考核列表异常 | 后端 | 自测型 | |
| EDU-14921 | Major | 【考试接入】试卷后台没有展示学生考核结果 | 后端 | 自测型 | |
| EDU-14923 | Major | 【考试接入】试卷设置发布时间为明天，发布后学生前台可以看见并答题 | 后端 | reopen | |
| EDU-14867 | Critical | 【考试接入】所有练习考试关联章节后，不应该展示在更多栏中展示 | 后端 | 自测型 | |
| EDU-14930 | Critical | 【考试接入】试卷提交后，前后台获取答题记录失败 | 后端 | ||
| EDU-14942 | Critical | 【考试接入】微专业学生前台，考核列表返回内容为空 | 后端 | reopen | |
| EDU-15076 | Critical | 收费的课程详情页目录只展示考试练习课件，其他课件均展示不出来了 |
总结应对措施并实行：
- 开发个人自测不足，导致bug的重复产生及reopen；
- 方案：开发质量意识需要加强，自测充分后提测；坚持质量优先，有风险需要及时暴露。
- 开发排期及修复bug过于乐观，没有评估到接入的复杂性及改动的逻辑关联
- 方案：业务方接入需要充分评估工作量及改动，建议交互、开发设计都邀请爱多思开发人员参加；根据接入改动的复杂程度适当预留buffer；
- 接入的过程中，后端需要改动的地方很多，接口复用字段在转换过程中会有丢失；
- 方案：已有功能冒烟覆盖比例不够，需要覆盖所有功能及重要逻辑点；
- 前端有较多配置项，忘记配置；
- 方案：前端配置项都在代码中，复用的时候开发注意下；建议开发接入过程中多沟通。
- 交互定义不详细，开发理解不到位；
- 方案：交互详细定义接入的功能点；复用并改动的地方需要明确定义细节及逻辑，逻辑点会相互影响。
- 业务方接入改动范围较大，需要在已有的基础上兼容处理不少逻辑点
- 方案：单纯复用的地方bug少，试卷列表、试卷编辑等页面改动较大，bug也较多，建议开发注意考虑其中逻辑点，不是简单复用后修改
- 排期设计不合理，开发联调冒烟时间不充分；
- 方案：排期时需要buffer建议适当多留些，接入过程中会遇到各种不可控因素；
3 完善自动化和持续集成
部门项目产品线比较多，且项目采用微服务架构，因此后端公共服务及前端公共组件的回归在日常测试工作中比较重要，因为公共服务或公共组件的修改不太容易评估影响范围，生成的问题较多，因此需要引入自动化测试保证服务的稳定且发现问题的时效性，从大量的回归时间中解脱出来。目前项目各条线都引入了接口测试和ui自动化测试。
4 督促开发修复bug进行反思总结
大家都经历过高考吧，在高三时我们经常做的应该就是对错题进行总结，人人都有一份错题集，因为错题是我们的弱项，如果我们不对他进行深入剖析，下次遇到时我们可能还会做错。同理，bug就是开发的弱项，如果修复bug时不对bug进行深入分析、总结，那么下次遇到同类的问题有极大可能还会产生bug，如果不深入分析，可能修复不彻底，产生reopen bug或引入新的bug，问题比较严重，因此，我们通过推动开发修复bug是分析原因、列出解决方式的形式，促使开发对产生的bug进行分析，减少了 reopen bug或引入新的bug。
通过类似于错题集的形式对bug进行反思，效果是比较明显的，开发从bug死循环中解脱出来，可以用于自身技术提升或是尽早进入下个迭代的设计工作，都是比较有利的，也非常感谢项目组技术团队的支持。
5. 测试小组周会质量总结
部门项目产品线比较多，每个测试负责不同的产品线，但是大家有一个相同的梦想，就是提高产品的质量。因此，我们组内会定期举行周会，对各产品的质量情况及推动措施进行讨论。讨论流程大概有3部分： 1.该月项目中有什么问题。 2.推动过程中遇到什么阻碍质量推动的问题。 3.有什么好的解决措施，起到了什么效果。
通过分析问题、总结措施及有效的措施推广等，产品之间可以相互取长补短，共同提高质量，进而提个这个部门的质量。
6.为开发童鞋普及测试策略及规范
项目质量提升的关键方案之一，就是推动开发自测，这也是许多部门坚持不懈的方案。也有许多文章说明开发自测对项目质量的重要性，本文不多做说明。本文重点讲解如何推动开发自测，不仅要提高开发自测的积极性，还要提高开发自测思路的严谨性。我们的方案：1）对于自测型bug较多的同学，通过站会或私下交流的方式督促其改进。2）端正开发同学对待bug的意识，通过推进开发在修复bug后填写备注的方式，使其分析bug产生的原因及解决方案，通过对bug进行全面分析，避免bug reopen或引出新bug。通过此举措施开发可以对bug产生原因进行思考、反思，避免以后因类似原因产生bug。可以防止开发误更新bug的解决状态，可以降低bug率及bug reopen率。3）术业有专攻，开发同学的测试策略可能不够周全，测试同学可以通过站会或私下聊天的方式为其讲解。对于需满足特定场景的测试，开发在自测时需构造该场景（比如分页、批量上传中断再上传、按照不同条件搜索pageindex初始化、搜索条件下的分页、不同角色的可见范围、边界值、输入格式规则、同一页面不同tab间cache的使用策略、不同页面数据之间有关联，A页面数据变化，B页面应实时变化）。通过重点关注、反思总结及思维培训，可以提高开发自测的态度、积极性及严谨性，减少项目中bug的生产。
7.代码review
代码重构问题在互联网项目中应该是难以避免的存在，让人又爱又恨。爱的是代码重构使代码越来越好，恨的是如果重构的时机不当，会给项目引入过多的bug、缩短测试的时间等等。针对这一问题，我们的应对措施：开发冒烟自测前，前后端代码增加review（针对复杂功能及新人新业务由迭代负责人评估），避免提测后代码重构产生的问题。开发冒烟前重构，是为了重构后开发可以在冒烟过程中充分自测，因为代码review比较耗时，因此我们提出有迭代负责人评估，这样就可以在有限的时间，起到无限的效果，降低代码重构给项目带来的风险。
8.bugbash
邮件列出满足5w1h的bugbash原则：做什么、何时、何地、为什么、参与人及如何测试，
为了达到更好的效果，我们还做了其他额外的推动措施：
- 要提前准备好被测产品。
- 说明被测产品使用方法。比如修改Hosts文件、产品的操作步骤、测试账号的申请方式等。
- 产品未实现功能告知，避免无用功。
- 报Bug的格式、标题内容需要说明。
- 在群中实时播报Bug战况，营造竞争氛围，提升参与者的士气。
- Bug结束时，组织参与者进行Bug triage，评估Bug是否修复、何时修复。
- 组织者负责整理本次Bug bash活动的胜利成果（Bug数、Bug类型、找Bug获胜者），邮件通知参与者。
9.线上问题回溯
线上问题，测试及开发人员进行case study，分析原因并总结改进措施。
10.减少临时介入问题
临时介入问题最大的原因我归结为“临时”，这是因为这个临时，才会给正常的迭代带来许多额外的问题。但是在项目中，又不能完全拒绝临时介入，所以我们的目的是在无法避免的情况下，如何降低这一因素对项目质量的影响。针对这一问题，我们提出了以下方案：
1）建议临时介入排期中让开发全职投入，如果个别开发临时加入，需要自己保证实现的功能进行联调且冒烟自测通过后才可调往其他迭代。避免生产bug。
2）插入需求优化时需进行交互评审，开发需要全面评估（编码、设计、了解原需求、自测）等。
3）熟悉的人做熟悉的事。
4）测试需将异常情况加到冒烟用例。
5）交互策划需走查优化功能点
分析出临时的问题后，我们就要对症下药了。对于临时介入的人员，我们要求其“有始有终”，即对应方案1。对于临时介入的需求，我们要求开发需要对这些需求充分的了解，可以通过方案2,3的方式解决。但是对于临时需求测试也需要特别的注意，测试可以适当提上优化任务冒烟测试的比例，需要将优化任务异常情况加到冒烟用例。此外就是督促产品方需要走查这些优化的需求，将其和正常迭代功能一视同仁。通过以上方案，我们也降低临时介入问题对项目质量的影响。
11. 减少新人引入bug
经过验证，新人一般是项目质量bug的主要生产者，且修复bug时往往也会引入新的bug，最终导致质量差且bug收敛慢。我想大家是深有同感，如何解决新人问题也是大家争相讨论的难点。我们的灵丹妙药：1）新人需主动了解已有业务并熟悉现有项目流程，加强自测；2）测试在选择冒烟用例时可以适当为新人加大冒烟测试的比例。在工作中我们需要协同迭代负责人，督促新人了解业务，并为其讲解已有功能逻辑，使其对自己实现的需求有深刻的了解，减少bug产出的可能。冒烟自测时适当为新人增加用例比例，变向加强其自测粒度，避免bug流入后期。通过这样的措施，我们控制了新人产生的bug数，甚至有一版本，新人的bug数为0，这是很难的，也证明了我们方案的可行性，提升了项目的质量。
经过上述种种解决措施，我们的质量得到了保证，我们的生活也发生了变化：
四、妙手回春-环境篇
环境问题应该是测试过程中比较常见的问题也是比较耗时的问题，特定是在提测服务较多时，问题尤为突出。我们需要的问题应该可以分为3类：部署分支不正确、服务依赖不正确、部署失败。因此我们找到这些问题，我们就要将这些问题解决。我们通过编写自动化脚本自动检测提测服务分支的正确性、服务依赖的正确性及服务部署失败，这样在提前前我们通过脚本自动检测环境问题，保证了提测环境的正确性，减少了环境修复的时间。
五、妙手回春-提高上线效率篇
我们分析了上线的问题，因此我们就可以对症下药，妙手回春了。
•完善走查流程
提前与产品方约定走查时间，并邮件通知-约定冻结时间
•完善回归流程
迭代排期时，开发、测试需粗估是否影响其他产品，若影响需提前向其他产品给出影响范围并约定回归时间
各产品线整理回归用例集，并通过接口或ui的形式自动化， 减少回归时间。
六、额外推动措施
6.1 Bug产生的可视性
创建包含该迭代中的所有bug、未修复bug、bug所属者表格等板块，使迭代中的同学很方便的了解到版本bug产生的情况；
每日站会根据仪表盘分析开发产生bug的原因，反思总结，避免类似bug在后续版本中重复产生。
6.2 Bug修复的实效性
测试期间提醒开发同学优先提测版本的bug修复，对于bug修复慢的同学会不定时提醒，下班前给出bug修复情况，保证当天bug，当天修复
6.3 Bug暴露的及时性
提测前一天，提前介入测试，发现bug并暴露在小分队群里。通过变向帮助开发提高冒烟通过率，提高开发同学的积极性、自测的重
视度及团队的整体友好氛围，有助于产品质量的提高。督促开发将冒烟联调中的问题记录下来，并确定责任人，使其再提测前修复
6.4 重点关注
对于自测型、reopen或整体bug率较高的同学，通过站会或私下交流的方式督促其改进
6.5 总结反思
定期开展迭代回顾会，总结问题并提出解决方案；每月定时向项目组发送质量度量报告，让产品每个人了解项目的质量情况，分析版本中存在的问题并提供应对方案，在下月度推 进实施。
6.6 制定公共服务回归流程
- 排期时，由开发评估可能影响的范围；项目管理建群，协调对应的开发、业务方技术负责人、QA；
- 项目管理协调所有人开会排期，技术人员通知影响的功能点及范围，由业务方技术评估对自身业务的影响，并给到己方QA；
- 迭代负责人会给出一个预估的时间段（2d左右），保证版本稳定后留给业务方回归；
- 业务方技术搭建测试环境，QA测试环境回归完毕，在群内通知，并给出自动化接口测试结果；
- 测试环境回归完毕，预发环境各方一起回归，回归后在群内通知；
- 迭代负责人确认后，发出上线邮件 ，策划、技术、QA确认后上线，并附所有自动化结果截图。
七、喜报连连
7.1质量指标-标准
质量保障部推动cqm平台收集项目过程中的相关数据（版本时长、开发人日、测试人日、Bug数目等），并通过对数据进行统计和分析，发现和总结项目过程中的问题及原因，并提出改进措施在项目组中推动施行，以期项目质量日渐精进，越来越好。
Bug率标准
自测型Bug率标准 <5%
Reopen率标准 <5%
教育部门各端bug率趋势：
可以看出，教育产品4条产品线的bug率都有明显下降趋势，说明我们的项目质量在越变越好。
以云课堂为例进行详细分析：
云课堂bug率趋势：
云课堂自测型bug率趋势：
云课堂Reopen bug率趋势：
项目质量—开发个人Bug率趋势
由以上图表可以看出，项目整体bug率、前、后端bug率、自测型bug率和reopenbug率都有较大降低，证明我们的改进方案效果明显，我们也可以自豪的说：我们在优秀的路上，走了很久了。但是我们也要居安思危，俗话说“打江山容易，守江山难”。如何在优秀的道路上越走越近，需要我们持之以恒的执行应对方案且不断补充应对方案，需要我们大家共同的努力。
八、最后的总结
实践6个月，统计了130多个版本的数据。并通过对数据进行分析，发现和总结项目过程中的问题及产生原因，然后针对问题提出改进措施并在项目组中推动施行。通过前面的数据图表的展示，大家可以知道我们的项目质量在持续提高，项目的整体质量越来越好，说明大家的努力没有白费，付出终有回报。
结论：
•人日bug率降低
•自测型bug占比（低端bug）降低；
•Reopen次数次数降低
•项目质量提升
分享至：
