为什么要建立缺陷管理流程？
在任何软件生命周期中，软件缺陷的出现几乎是不可避免的。建立一套有效的缺陷管理流程的目的是为了减少软件缺陷出现的几率，并且大幅度降低由于软件缺陷带来的负面影响。对于缺陷管理流程的投资，可以大幅度的降低由于返工/修复缺陷导致的人力，财力和时间浪费，同时提升用户的体验或者更多用户留存与产品口碑，并且可以保障产品更准时的交付。
在正式开始谈论产品缺陷管理流程建设之前，我们首先介绍下一些基本概念
软件BUG和缺陷有什么区别？
什么是BUG?
BUG最初是在软件行业的计算机用语，是指由于错误编码导致的结果。
缺陷是什么?
缺陷的英文：DEFECT，缺陷是指不符合最初定义的业务需求，其覆盖范围高于BUG,除了错误编码外其他导致不符合最初定义的业务需求问题都属于缺陷范畴。
这两个术语BUG和DEFECT在英文中有非常细微的区别，但在行业中都是需要修复的错误，因此一些测试团队并不对这两个词语做细分。
当测试人员执行测试用例时，他可能会遇到与预期结果不一致的测试结果。
测试结果中的这种不一致被称为软件缺陷。这些缺陷在不同的团队中有不同的称呼，如错误，缺陷，BUG，问题等。以下文章中，我们统一称之为 “缺陷”。
缺陷报告中常见的术语：
当向开发人员反馈缺陷时，您的缺陷报告应该包含以下信息：
-
缺陷ID：缺陷的唯一标识号
-
缺陷描述：详细描述缺陷，包括发现缺陷的模块的信息。
-
软件版本：发现缺陷的软件程序的版本号。
-
复现步骤：详细的步骤，以及开发人员可以复现缺陷的屏幕截图。
-
缺陷提交日期：提交缺陷的日期
-
相关文档：通过相关的需求、设计、架构文档并对比，能够让人更容易理解，例如产品需求文档，相关产品原型或者用例文档等
-
提交人：由谁发现的缺陷。
-
缺陷的状态：缺陷当前的修复状态，我们稍后将详细介绍
-
修复人：修复缺陷的开发人员
-
缺陷关闭日期：缺陷被关闭/解决的日期
-
缺陷等级：描述缺陷对软件程序的影响的严重程度
-
缺陷优先级：优先级与缺陷修复的紧迫性相关。严重程度优先级可以是高/中/低，这取决于缺陷修复对应用影响的紧急程度
如果没有有效的缺陷管理流程会怎么样？
其实无论团队是否有花费时间和精力创建缺陷管理流程，缺陷管理流程总归是会存在的，但这一流程并不一定有效，我见过一些团队并没有一套有效的流程，而是通过口头或者邮件的方式进行着缺陷管理，这些方式可能会导致许多问题，下面我举一个简单的实例：
如果像上述的情况一样通过口头或者简单邮件沟通进行缺陷管理，很快事情会变得十分复杂，如果你作为测试主管，想要控制和有效管理缺陷问题，您需要了解一个缺陷的生命周期以及如何建立一套有效的缺陷管理流程。
缺陷管理的流程
本部分将指导您如何将缺陷管理过程应用于项目中。管理缺陷可以分为以下步骤：
步骤1：发现BUG
在发现BUG阶段，项目团队应该尽可能在产品上线之前发现存在的BUG，当发现的BUG和开发团队的同事确认过后，将BUG的状态改成已接受状态。
在上面的情景中，测试人员发现了15个BUG：在产品发布前，测试人员发现BUG，然后报告给项目经理，然后项目经理告诉开发人员，接受或拒绝这个BUG。
再看一个情景：您的测试团队在BUGOUT网站上发现了一些问题。他们认为它们是缺陷并向开发团队报告，但存在冲突。
这时，作为测试主管你会如何做？
A）同意测试团队认为其存在缺陷
B）测试经理扮演法官的角色来决定问题是否存在缺陷
C）同意不是缺陷的开发团队
在这种情况下，测试主管应该扮演法官的角色来决定网站问题是否是一个缺陷。或者由团队商议一套冲突解决方案并按照方案执行
步骤2：BUG优先级分类
缺陷分类帮助软件开发人员对他们的任务进行优先排序。这种优先级帮助开发人员先修复那些非常关键的缺陷。BUG优先级分类可以包括以下几种：
致命：需要立即修复的缺陷
严重：它可能会对产品造成很大的损害
一般：缺陷影响产品的主要特性，这一缺陷使产品的质量降低
轻微：该缺陷对产品影响很小
下面做一个小练习，给以下缺陷按照致命、严重、一般、轻微进行分类
1.网站性能太慢
2.网站的登录功能无法正常运行
3.网站的GUI在移动设备上显示不正确
4.网站无法记住用户登录会话
5.某些链接不起作用
下面给出推荐答案：
1.严重：网站性能太慢会给用户带来极大的不便
2.致命：如果登录功能无法使用，那么就相当于把用户拒之门外
3.一般：该缺陷只是影响移动用户。
4.严重：这是一个严重的问题，因为用户可以登录但无法执行任何进一步的需要验证用户信息的行为 。
5.轻微：对于开发人员来说，这是一个简单的解决方案，用户仍然可以访问没有这些链接的站点。
步骤3：解决/修复BUG
一旦接受并分类缺陷，您可以按照以下步骤修复缺陷。
分配-排期-修复BUG-报告解决方案
分配：分配给开发人员或其他技术人员进行修复，并将状态更改为“响应”。
排期：开发者在此阶段负责。他们将根据缺陷优先级创建修复这些缺陷的计划。
修复BUG：当开发团队正在修复缺陷时，测试管理器会跟踪修复缺陷的过程，与上述计划相比较。
报告解决方案：在修复缺陷时获取开发人员的决议报告。
步骤4：验证BUG是否修复
在开发团队修复并报告缺陷之后，测试团队验证缺陷是否得到了真正的解决。
例如，在上面的场景中，当开发团队报告他们已经修复了61个缺陷时，您的团队将再次测试以验证这些缺陷是否真的修复了。
步骤5：BUG关闭
一旦一个缺陷被解决并验证，这个缺陷将被更改为关闭状态。如果没有，您已经向开发人员发出通知，再次检查缺陷。
步骤6: 数据报告
管理层有权知道缺陷状况。他们必须了解缺陷管理过程，以便在这个项目中支持您。因此，您必须向他们报告当前的缺陷情况，以便从他们那里得到反馈。
重要的缺陷KPI指标
管理学大师德鲁克说过：你无法管理那些你无法衡量的事情。缺陷管理也是一样，你需要有一些可供参考的指标，以便衡量管理效果. 您可以考虑使用以下两个简单的指标来衡量您测试团队的执行效果
缺陷拒绝率 (DEFECT REJECTION RATIO, 简称DRR)：（拒绝的缺陷数量/总测试团队报告的缺陷数量）*100%
缺陷遗漏率 (DEFECT LEAKAGE RATIO, 简称DLR)：（遗漏的缺陷数量/总的缺陷数量）*100%
下面我举一个简单的实例：
BUGOUT的测试团队在BUGOUT的一次产品升级测试中，发现了50个BUG并反馈给开发团队，其中5个经过核实并不是BUG。新版本上线后，收到与本次升级相关的问题反馈10条并确认均为BUG。
缺陷拒绝率（DRR)=5/50=10%
缺陷遗漏率（DLR)=10/(50-5+10)=18.18%
DRR和DLR的值越小，测试执行的质量越好。什么是可接受的比例范围？可以在项目目标中定义和接受此范围，也可以参考类似项目的指标。
写在最后
如果对python自动化测试、web自动化、接口自动化、移动端自动化、面试经验交流等等感兴趣的测试人，可以关注微信公众号：【程序员二黑】，获取软件测试工程师大厂面试资料！我的学习交流群： 785128166 群里有技术大牛一起交流分享~
如果文章对你有感兴趣，麻烦伸出发财小手点个赞，感谢您的支持，你的点赞是我持续更新的动力。