[修复bug导致的bug]项目代码质量的推进之路——BUG率一路向0

1.3 自然环境难题

在日常生活试验过程中可能将时常会辨认出自然环境相关难题负面影响QA的试验继续执行，耗费大批的天数去功能定位自然环境引致的难题，引致试验继续执行天数延长或者bug的误产生，给试验增添许多无谓的天数开支。在难题归纳中，我将自然环境布署难题又行业龙头四类：a)布署组成部分不恰当;b)服务倚赖不恰当;c) 布署不获得成功。或许在他们的日常生活组织工作中时常会听见QA老师这种的聊著声：自然环境都没布署获得成功，组成部分没布署恰当dubbo倚赖都不对，开发怎么禁绝透过了?着火blocker了，半天天数又节约了，试验天数不够呀，勒皮伊...。这种的难题势必减少试验的天数，试验不充分，工程项目的产品质量不能获得保障。

1.4 上架难题

以前他们的上架可能将是这种的：

上架至下午可以行业龙头为三类难题a)通告商品走查天数点较早且没确定注销天数；b)通告其它商品线重回天数较早且没提早签订合同重回天数。首先他们探究下商品走查的难题。日常生活插值须要商品及听觉走查，这个大家都知道，但是走查天数点及注销天数点没提早签订合同或签订合同的不恰当，可能将会为工程项目增添一定的信用风险。假如和商品签订合同的天数点较早且没注销天数点，所以增添的难题是可能将时值上架还会有市场卢瓦松提出的修正，虽然天数紧张，技术老师没充裕的天数去思索和设计，结论往往耗费大批天数后辨认出难以化解（增添上架延后信用风险）或化解该难题又带出了其它的难题，反过来。虽然部门商品线非常多，且工程项目微技术化，因而彼此之间有非常多的基本保障。这种就会引致一个商品修正基本保障，其它的商品都须要安排QA进行基本保障的试验重回。假如他们通告其它商品线重回天数较早且没提早签订合同重回天数，所以可能将会增添难以上架的结论。或许在他们的日常生活组织工作中时常会听见QA老师这种的聊著声：我在着火呀，你让我重回，都不会提早通告，没天数呀！呀！。这种假如对方没天数重回，他们上架虽然自己商品没难题，但可能将引致其它商品功能不可用（在工程项目中出现过该难题），或者他们延后上架，给其它商品QA留天数重回，重回完成后再上架，但最终结论单厢负面影响工程项目的工程进度。

二、Alzonne

2.1 Alzonne-市场需求篇

市场需求难题在任何工程认证组织工作，我想都是无可避免的。因为随着系统维数的不断提高、商品老师的当新等原因，商品老师确实不太容易考虑完全。因而针对市场需求难题，他们透过3种措施去推动化解。

1.市场需求试验

1.1他们透过可视化评审委员前市场需求试验

1.2他们透过开发设计时市场需求试验

1.3他们透过试验设计时市场需求试验

2.他们透过首页市场需求变更记录

3.他们透过市场需求变更时，商品同事在小分队内艾特相关开发、试验

市场需求试验是化解市场需求难题最有效的方式，因而他们一定须要在组内推动市场需求试验。市场需求试验的形式应该比非常多，本文举例3种：1）jira工单的形式记录市场需求难题；2）wiki页面记录市场需求难题；3）相关人员组建小群，难题实时抛出化解，不同工程项目可以根据实际情况选取。

他们工程认证组织工作采取的是第3种形式，优势：开发及商品老师容易接受（组织工作量不大）且时效性较强。市场需求试验须要前提条件：技术与商品达成一致，避免在可视化稿中出现同...文案，避免低级的市场需求难题。

可以看出上述3种方案是环环相扣，他们首先要求可视化稿提早给出，开发和试验进行市场需求试验，在可视化评审委员前化解掉大部分部分难题。然后再开发设计和用例设计时，由开发和试验去推动可视化稿补全，进一步化解了可视化遗漏或有争议的一些点，又进一步细化了可视化稿。时常在工程认证组织工作会和开发或试验老师说，假如经过开发设计或用例设计后可视化稿没更新，那就说明开发或QA有难题，是不负责任的。透过2、3中方案可以化解市场需求变更遗漏的难题。透过上述3个方案，他们已经基本化解了市场需求难题。

市场需求难题化解了，开发过程中不须要在面对市场需求讨论、市场需求变更的难题，开发的生活应该也比较悠闲一下，生活可能将是这种的。

2.2Alzonne-提高设计和开发产品质量篇

如何将辨认出bug的天数早移，是他们须要关注的事情。毕竟‘bug越早辨认出，复原的成本就越小’。基于该原则，他们推动了一些措施去将辨认出bug的天数迁移，避免提测版本产生bug或减少产生的bug数。

他们的措施如下：

1.他们透过加强开发设计评审委员

将设计评审委员纳入工程项目流程，在现有评审委员基础上，将设计评审委员细粒度化，补充异常场景设计。

2.他们透过加强试验用例评审委员

1）用例粒度细化，例如：一条用例假如含有多个场景，须要拆分成多条用例。

2）重点表字段变更体现到用例中

3）邀请相关可视化、策划和开发老师以小会议的形式参加，提早辨认出开发或试验应与市场需求不一致产生的难题。

3.他们透过试验用例交叉继续执行

完善用例继续执行流程，用例交叉继续执行，前端注重可视化、功能逻辑的实现。后端注重功能逻辑及接口异常场景的校验。

透过上述方案后，他们工程项目的提测产品质量有了较大提高，开发的组织工作状态也发生的质的变化。

2.3 Alzonne-减少bug产生篇

透过2.1和2.2的方案，他们已经化解了大部分bug。但是他们是比较贪心的，因为他们的目标是0bug，于是他们又继续鸡蛋中挑骨头，由推出了一些措施：

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建议适当多留些，接入过程中会遇到各种不可控因素；