一、前言
从单个有价值的bug入手，追踪和分析bug产生的本质原因，在此基础上对产品各个角色、以及项目流程做改善和优化。
二、背景
在行业平台试点EP，已经三个迭代了，节奏慢慢脱离了”兵荒马乱”的时代，腾出手对这三个迭代进行了一次BUG分析， 尝试看看BUG的原因都是什么，怎么能让BUG少一点，代码更可靠一点，集成测试时间短一点，上线时间趋于确定一点，团队 更有信息一点。 许是没有理论基础，搜索关键词不对，在内网没有找到系统成型的分析方法，索性把自己脑袋的实践和想法，沉淀下来。 而后周会的时候有人提到了”ODC”，也对应查到了”T-RCA缺陷根因分析法”，因此本文将从已经存在的ODC理论、T-RCA出发 然后补充在行业平台实践方式，最后思考之后如何结合开展。
三、ODC正交缺陷分类法
正交缺陷分类法，Orthogonal Defect Classification（简称ODC）是一种缺陷分析方法，由IBM在1992年提出。 它通过给每个缺陷添加一些额外的属性，利用对这些属性的归纳和分析，来反映出产品的设计、代码质量、测试水平等 各方面的问题。从而得到一些解决办法来进行改进。
1. 几种常见的缺陷分类方法
1.1 按照严重程度
一般而言，会分为：致命、严重、一般、建议、提示，按照这种方式，我们可以知道：
- 工作的优先级
- 项目的进展状态
- 产品的质量
1.2 按照component/module分类
按照每个项目涉及到的模块进行分类，可以知道代码出现问题较多的部分。
2. ODC
ODC 的工作流程分为四部分：”缺陷分类”，”校验已被分类的缺陷”，”评估数据”以及”采取行动来改进工作”。
2.1 缺陷分类
分类，是 ODC 工作流程中的第一步，即需要测试和开发人员分别对每一个缺陷填写 ODC 属性。 对于团队成员来说，正确的了解每个属性的值尤为重要，这样才能保证他们在分类时尽量选择正确的选项。 不同的缺陷管理工具支持程度不一样，因此在建立流程的同时也需要对缺陷分类以及必填等作出一定的配置。
ODC方法定义了八个正交的缺陷属性用于对缺陷的分类。 
其中，有三个是测试人员在新建缺陷时候填写的，有5个是开发人员在解决完bug之后填写的，如下： |发现/关闭|属性| |:-:|:-:| |Opener Section|Activity（活动），Trigger（触发），Impact（影响）| |Closer Section|Target（目标），Type（类型），Qualifier（界定），Age（阶段），Source（来源）|
具体说明如下：
- Activity：表示在做哪种测试时发现的缺陷。比如：UT( 单元测试 )、FVT（功能测试），SVT（系统测试）等；
- Trigger；表示采取哪种方式触发的该缺陷，不同的 activity 对应不同的 trigger 类型；
- Impact：表示该缺陷的发生会对客户造成的影响；
- Target：表示开发人员为了修复这个缺陷，需要在哪方面做修改。比如可以修改的方面包括：产品设计、相应的代码和文档等；
- Defect Type：缺陷类型；
- Qualifier：表示该缺陷是由于丢失相关代码、还是代码不正确造成的。或者是由于第三方提供的代码造成的；
- Source：表示该缺陷的来源是由于内部编写的代码引起的问题，还是由外包公司提供的代码引起的等；
- Age：表示该缺陷是由新代码产生的还是由于修改其它缺陷而引发的，或是在上一个发布版本中就已经有的问题等；
建议：
ODC信息的缺失，会导致分析的不准确，因此建议在配置缺陷管理工具用支持ODC时，加上对有关联关系属性的限制， 并对必填的ODC属性进行强制填写的校验，强制每个人必须填写，否则无法提交成功。 从而在工具的层面上，保证 ODC 数据输入的完整性和正确性。
2.2 校验阶段
在第一步中，测试人员和开发人员已经填写了 ODC 数据。那么接下来就需要对这些数据进行校验。 因为填写不正确的 ODC 数据会导致后面的评估和行动两个流程步骤没有意义。
建议：
- 增加一个ODC校验字段，标记是否校验过，或者不计入ODC统计
- 定期组织专门的人，review所有的缺陷，进行校验
2.3 评估阶段
根据 ODC 的不同属性进行分类统计，可得出不同方面的结论。以此来反映测试、开发或产品设计方面的问题，指出潜在的改进的机会。 几种典型的评估方法如下：
2.3.1 对测试工作的评估
用不同的 ODC 属性的组合，可以从多方面来评估测试工作的完成情况:
- 利用测试阶段和 activity 属性来评估是否应在某一测试阶段中发现的缺陷却被在下一测试阶段中才发现；
- 利用 activity 和 trigger 属性来评估是否每个 activity 都使用了足够多的与之对应的 trigger 来发现缺陷；
- 利用时间和 trigger 属性来评估是否随着时间的推移测试变得更加复杂等。下面就利用第一种评估方法来进行举例。 例如：
由图，该项目在系统测试阶段，有近一半缺陷的 activity 是功能测试。这说明本应该在功能测试阶段发现的缺陷， 却被遗留到了系统测试阶段才得以发现。可见功能测试阶段的测试工作做得不够全面。
2.3.2 对产品稳定性的评估
随着项目的进展，定期统计 qualifier 属性的变化趋势，以此来评估产品是否变得更加完善； 或者定期统计 impact 属性的变化趋势，以此来评估影响产品功能性和可靠性的缺陷是否在减少。
例如： 
qualifier一般分为：missing（代码缺失），incorrect（代码不正确）和extraneous（外来的）。 对于一个逐渐趋向于稳定的产品来说，Qualifier 为 missing 的缺陷应该逐渐减少。因为任何未经测试过的新代码的加入， 都会增加潜在的风险。
不能只笼统的看表面所反映的数据，missing 所占的百分比是多少，incorrect 占多少。还应该看到更深层的内容， 比如那些 missing 的缺陷到底属于哪个 defect type? 又是发生在哪些 component? 这样才能够发现真正的风险在哪里，以此判断产品是否稳定。而不仅仅只是看到有多少百分比的缺陷的 Qualifier 是 missing；
2.3.3 对产品设计和代码的评估
target表示开发人员为了修复这个缺陷，需要在哪方面做修改。比如可以修改的方面包括：design/code、build、 information、language 等。为了评估产品在设计和代码方面的完成情况，我们可以分析 target 是 design/code 的缺陷，利用其对应的 defect type 和 qualifier 属性来发现产品在需求、设计和代码阶段的不足， 以及在哪个薄弱环节更容易引入缺陷。
作为一个开发人员我发现的问题如果按类型（type）分类可能是由如下几种可能：
- 1) 没有正确的初始化 （Init）
- 2) 代码没有正确的check-in （Chk）
- 3) 算法问题 （Alg）
- 4) 功能性的错误，可能是模块内的功能没有被正确实现，也可能是模块与模块之间相联系的部分没有被正确实现。（Fnct Cls）
- 5) 有可能是有关时间的错误 （Time）
- 6) 界面相关的错误 （Intf）
- 7) 代码之间相关联的错误，例如错误的继承关系 （Rel’n）
例如： 
- algorithm/method的缺陷里，missing 和 incorrect 的比例及缺陷数量都很高，说明产品的低层次的细节设计描述不完整， 同时没有被开发人员很好的理解；
- assignment-initialization和checking 的缺陷，incorrect比例相对来说比较高，这反映了代码编写上还存在欠缺；
- interface/O-O messages、relationship 和 timing/serialization 等的缺陷，incorrect 和 missing的数量 都比较少，这说明产品在高层次的设计上和需求分析、理解上都还做得不错。
2.4 行动阶段
找到问题所在之后，就是落实解决了。根据评估过程中反映出的不同问题，按照优先级，并针对性的提出action， 并归属到owner身上，给出解决时间进行check。
建议：
- 测试和开发团队应该参与到这个过程中，因为他们才是最终行动的实施者；
- 所识别的行动应该是可行的，不是泛泛而谈的，不要笼统的指出对产品有什么改进行动，最好是能针对某个组件或是模块，采取行动；；
- 利用在评估阶段生成的各种评估图一起分析、衡量出改进的行动方案，不要单凭某一个评估图来做决定；
- 要采取的行动应该是可以衡量的，可以验收的，这样可以看出是否该行动对产品有积极的影响。
3. 小结
ODC，说到底是一种缺陷分类方法，通过它的工作流程及各阶段的工作重点，可以有条不紊并快速的获取问题信息，来帮助后面 找到正确的解决方案。实践中，可以以ODC工作流程为指导思想，然后结合项目特色，进行重点关注项的分析。
四、T-RCA
T-RCA缺陷根因分析法（T-RCA，Test Root Cause Analysis），主要目的是基于缺陷的过程改进 （开发的改进、测试的改进、组织的改进），通过问10个问题来对Bug进行根因分析，看似很简单，实则重在引导和交流。
1. 10w
从右边开始：
- 1w：这个问题是什么？有什么影响？
- 2w：为什么会出现这个问题？什么场景下会出现这个问题？
- 3w：这个问题是在哪个阶段发现的？
- 4w：缺陷是在哪个阶段引入的？
- 5w：为什么会在这个阶段引入问题？
- 6w：（hoW）如何避免引入这个问题？
- 7w：应该在哪个阶段发现这个问题？
- 8w：为什么没有在这个阶段发现这个问题？
- 9w：（hoW）如何才能在这个阶段发现这个问题？
- 10w：（hoW）如何改进基于风险测试的过程，提取预估到这样的产品风险？
2. 注意事项
- 分析所有的缺陷，包括review类的缺陷，但可以不包括测试用例类的检视缺陷。
- 分析所有阶段发现的缺陷，包括review阶段、UT、IT、ST、AT等阶段。
- 根据缺陷级别的不同，缺陷根因分析的深度可以不同。
- 对于那些无法重现的问题，还可以分析为什么无法重现，在提高可测试性方面可以有哪些改进。
3. 小结
T-RCA，是针对某个具体的问题，穿透表面现象，进行刨根问底的分析，这种分析方法很有价值，但是并不是每个BUG都要进行 如此重量的寻因。所以此方法，可以用来分析线上故障或者严重致命等级的缺陷。
四、行业平台的实践
正如ODC里分类阶段提到的，前置条件是很重要的。在行业平台里，首先定义BUG单的相关属性，比如缺陷类型、缺陷原因、 缺陷重现程度、严重级别、解决方法、版本、迭代等。然后辅助以BUG的工作流程进行限制，最后规范《BUG提单规范》进行 组内对齐拉通。
1. BUG的ODC属性
1.1 缺陷类型
| 序号 | 缺陷类型名称 | 描述 |
|---|---|---|
| 1 | 功能缺陷 | 功能失效或者功能没有按照用户需求实现。 |
| 2 | 性能缺陷 | 性能导致用户体验差或不满足系统并发容量规格。 |
| 3 | 可靠性缺陷 | 包括故障出现无法检测，故障导致业务中断，故障出现后无法恢复等。 |
| 4 | 用户体验缺陷 | 包括可用性，业务响应时间，易用性，易学性，友好性。 |
| 5 | 安全缺陷 | 不满足公司的IT安全规范或不满足用户特定的安全需求 和系统本身的安全设计。 |
| 6 | 兼容性缺陷 | 在用户使用需求的范围内出现的不兼容问题， 包括浏览器，分辨率，文档，硬件兼容等。 |
| 7 | 可服务性缺陷 | 包括可安装性和可维护性。如按照指导书无法完成安装或升级， 安装或升级失败无法回退，升级导致数据丢失，日常维护无健康检查手段，出现故障无日志，工具等定位手段。 |
1.2 缺陷原因
按照缺陷引入主要原因的维度划分,缺陷包括以下类型：
| 序号 | 缺陷原因 | 描述 |
|---|---|---|
| 1 | 需求缺陷 | 由于需求的问题引起的缺陷，如需求遗漏，需求描述不清晰。 |
| 2 | 架构缺陷 | 由于构架的问题引起的缺陷，如架构不合理，架构性能不满足。 |
| 3 | 设计缺陷 | 由于设计的问题引起的缺陷，如UI设计、流程设计不符合需求， 接口设计错误，设计描述不清晰导致开发错误。 |
| 4 | 编码缺陷 | 由于开发编码的问题引起的缺陷，如开发没有按照设计实现， 编码没有按照编码规范导致低级问题，单测试和开发自验遗漏， 合入新代码造成已测试过的旧功能出现问题。 |
| 5 | 测试缺陷 | 由于测试的问题引起的缺陷，如集成测试和系统测试的测试场景 遗漏，测试因子遗漏等导致的测试用例遗漏，或测试因子取值错误导致的 测试用例错误，还有测试执行遗漏或没有按照用例执行。 |
| 6 | 集成缺陷 | 由于集成发布的问题引起的缺陷，如发布打包错误。 |
编码缺陷，在跟开发沟通之后，细化成为了：
- 配置问题
- 逻辑问题
- 联调问题
- UI问题
- 兼容性问题
1.3 缺陷重现程度
按照缺陷重现的概率，划分为以下4个级别：
| 序号 | 缺陷重现程度 | 描述 |
|---|---|---|
| 1 | 必然重现 | 在满足指定条件下，缺陷必然出现。 |
| 2 | 有条件概率重现 | 在满足指定条件下，缺陷概率性出现。 |
| 3 | 无条件概率重现 | 没有特定的条件，缺陷概率性出现。 |
| 4 | 无法重现 | 只出现过一次，缺陷暂时无法在任何条件下重现。 |
1.4 缺陷严重级别
目前设置了5个等级：致命、严重、一般、提示、建议
1.5 缺陷解决方法
关闭缺陷的时候，选择具体怎么解决的此缺陷：
| 序号 | 解决方法 | 描述 |
|---|---|---|
| 1 | 空 | 新创建的缺陷，还没有处理，还没有定解决方法，此时为空。 |
| 2 | 无需解决 | 确认是缺陷，但经过PM评估觉得没必要解决，并且以后也不会解决，此时选择无需解决。 |
| 3 | 延期解决 | 确认是缺陷，但经过PM评估在后续版本再解决，当前版本不解决，此时选择延期解决。 |
| 4 | 无法重现 | 从问题现象看是缺陷，但目前无法重现，此时选择无法重现。 |
| 5 | 外部原因 | 此问题不是本系统的问题，是由其他系统引起的问题，此时选择外部原因。 |
| 6 | 重复 | 此问题是重复问题，以前已经提过缺陷单，此时选择重复。 |
| 7 | 设计如此 | 确认为非缺陷，就是这么设计的，且已与客户沟通达成一致，此时选择设计如此。 |
| 8 | 问题描述不准确 | 此问题描述不准确，无法判断是否缺陷，此时选择问题描述不准确。 |
| 9 | 挂起 | 确认是缺陷且需要解决，但目前暂时没有解决办法，此时选择挂起。 |
| 10 | 需求变更 | 此问题是由于需求变更引起，此时选择需求变更。 |
| 11 | 已修改 | 此问题已修改解决，此时选择已修改。 |
| 12 | 已转需求 | 此问题已转为需求，此时选择已转需求。 |
1.6 发现版本
BUG很有可能是在测试摸一个功能点，比如”多轮冷启动1.1”时候发现，但是修复以及上线，可能不是在改发现版本里。 因此有必要区分一下具体在哪里发现此缺陷。
1.7 迭代
为了更好的规划任务，每次在迭代的IPM会议时候，把上个迭代的遗留的BUG，迭代更新为本迭代，以进入本迭代的任务事项中。
2. BUG提单内容
除了上述必填的ODC属性外，BUG提单的主要内容，需要填写充分，以便开发迅速定位问题。
一般来说，会有：
- 页面地址（开发、测试、灰度、正式环境）
- 测试账户
- 操作步骤
- 缺陷描述
- 问题截图
- 预期结果
- 复现次数
根据开发的需要，可能还需要
- 问题发生时间
- Request ID或者Trace ID
3. BUG工作流
TAPD上，BUG系统默认的工作流如下： 
工作流体现的是BUG的生命周期，其中处理人和状态尤为重要。在review bug list的时候，严格以处理人为owner，询问其进度等。 为了更好的实践上述的属性填写，在流程中添加一些限制，十分必要。
比如：
- 处理人是必填
- 从「接受/处理」到「已解决」时候，「问题产生原因」是必填的
- 到「挂起」的时候，评论是必填的
- 到「已关闭」的时候，「解决办法」是必填的
4. 相关人员
BUG单据里面，涉及到创建人、当前处理人，开发人员，测试人员，抄送人员等，如果职责不分清楚，最后BUG很可能就无法追溯了。 那么在每一个阶段，有谁处理单据，最后又是谁来验收呢？
4.1 处理
- 开发负责人进行预判开发处理人 如果知道具体的开发同学，本步骤跳过
- 开发处理人 如果涉及到多个开发，注意扭转处理（及时关注自己名下的bug）
- 测试同学 开发拒绝、已经解决，直接扭转到测试同学
- 挂起 挂起的时候，需要引入产品、测试进行确认，方能挂起。
4.2 验收
原则是who提单，who验收。
- Bug转了需求的，属于需求层面，按照常规流程就可以。
- 线上bug的，产品提单，产品验收。（如果需要引入测试，再单独进行测试规划。）
- 设计提单，设计判断验收为准。
5. BUG跟踪
-
Daily 在上述工作流和属性都设置好之后，最重要的是BUG单据的跟踪。有必要在每天早上都会本迭代的bug列表进行核对，及时确认其状态。
-
Bug Review 每次集成测试之后，总会出来一波BUG，这个时候也临近上线的时间点。有必要拉齐相应的开发、产品和测试，对剩下的Bug快速对齐， 根据BUG严重程度，确定该BUG是否要解，能否在本迭代解决完，如果不解决，是否影响本次发布，是否安排在下个迭代进行解决， 或者因为需求设计问题转为需求进行跟踪。
6. BUG分析
以每个迭代为粒度，对本迭代的BUG，整体进行分析，主要分析发生问题比较多的模块，发生的阶段，产生的原因。
- 如果是一些逻辑问题，是否可以通过单测或者Code Review来解决
- 如果是一些UI问题，是否可以前期通过设计走查发现
- 如果是界面不同地方风格不一致，是否可以引入产品和设计出具统一规则
- 如果是反复出现的问题，是否是架构设计问题，是否需要需求评审钱引入架构评审
- 如果是原因不清晰，开发人员需要在评论里添加上具体原因，否则测试人员直接打回