缺陷年龄分析

讲述缺陷的年龄。...



前言

 在测试过程中，大家是不是遇到过下面这些场景：

①这个bug，是因为开发实现变更了，导致XXX地方出问题了；

②这个bug，完全是因为需求没有考虑完全，开发按照自己的想法实现导致的；

③这个bug，是因为开发的框架设计有问题，导致有这么多坑出现。

不同阶段引入的bug，对项目质量、项目进度都有不同程度的影响，所以在此，我们引入一个概念：缺陷年龄。

 缺陷年龄，顾名思义，缺陷引入的时间。具体分类见下：

缺陷年龄

描述

继承或历史遗留

属于历史版本、继承版本或是移植代码中的问题，非新开发的问题

需求阶段引入

缺陷是在产品需求设计阶段引入的，主要包括如下情况：

①“需求不清”的问题

②“需求错误”的问题

③“系统整体设计”的问题

设计阶段引入

缺陷是在产品设计阶段引入的问题，主要包括如下情况：

①“功能和功能之间接口”的问题

②“功能交互”的问题

③“边界值设计”方面的问题

④“流程、逻辑设计相关”的问题

⑤“算法设计”方面的问题

编码阶段引入

缺陷是在编码阶段引入的问题，主要包括如下情况：

①“流程、逻辑实现相关”的问题

②“算法实现相关”的问题

③“编程规范相关”的问题

④“模块和模块之间接口”的问题

新需求或变更引入

缺陷是因为新需求、需变变更或设计变更引入的问题

缺陷修复引入

缺陷是因为修改缺陷时引入的问题，如开发虽然成功修复了一个缺陷，但修改又引入了新的缺陷

在此不多做赘述，小编是通过在Cynthia系统的bug表单中添加“缺陷年龄”的字段，在报bug时候各个模块负责人进行填写。下图是Cynthia系统缺陷表单示意图：

我们通过系统的记录，对缺陷年龄进行统计分析，形成量化指标。

理想的情况，缺陷应该在缺陷引入的阶段就被及时发现并修复。比如需求阶段引入的缺陷，应该在需求评审阶段就及时发现并修改；框架设计上的问题，应该在开发实现评审阶段就及时发现并修改。

但实际的情况，每个阶段，都会有一些缺陷“逃逸”到下一阶段，甚至下下阶段，最终都需要在测试环节来发现。

缺陷年龄

可能原因

解决方案（仅供参考）

继承或历史遗留

①每个版本对历史缺陷的修复不够及时和充分

②产品本身具有历史遗留问题（可能是需求/设计/编码上的问题）

①评估缺陷优先级，决定是否要单独发版修复，或者更新到最新版本修复

②对遗留问题形成固定处理流程，比如每三个版本更新一次，评估优先级后进行关闭或者修复

需求阶段引入

①产品需求质量不高

②产品方案设计的质量不高

①加强需求评审

②在产品方案设计时测试和开发参与评审

③引入用户评价

④公司内部调研功能可行性及体验上的问题

⑤增加产品验收环节

设计阶段引入

①增加开发实现讲解、实现框架评审环节

编码阶段引入

①加强代码Review流程

②增加单元测试力度

③增加开发自测流程

新需求或变更引入

①需求变更多

②新需求质量不高

③新的产品设计质量不高

①同“需求阶段引入”解决方案

②分析缺陷原因，考虑增加探索测试、或补充测试场景等方案

缺陷修复引入

①开发修复缺陷的质量不高

①增加回归测试力度

②增加代码review力度

③测试范围确认环节增加交叉确认步骤

④增加修复缺陷后的自测环节

⑤增加自动化回归测试

缺陷分析是一项需要长久坚持的事情，在较长的数据统计和分析过程中，指标化的体现项目整体质量数据，进而有的放矢的提升各个环节的质量。

欢迎关注搜狗测试其他系列文章：

探索式测试：超模测试法

探索式测试：配角测试法

探索式测试：反叛测试法和强迫症测试法

探索式测试：取消测试法

探索式测试：测一送一法

探索式测试：地标测试法

探索式测试：深巷测试法

探索式测试：快递测试法
探索式测试：极限测试法

探索式测试：通宵测试法

探索性测试：遍历测试法

探索式测试：收藏家测试法

    关注 搜狗测试