互联网软件缺陷规范

软件测试岗位最重要的职责之一就是提交缺陷，而缺陷的描述尽显专业度，有经验的管理者从缺陷的描述就可以看出该测试人员的业务理解能力和测试技术水平。为了质量分析需求，缺陷的分级标准清晰，以及日常管理的规范明确，结果分析会更准确的反映产品质量。

---

1. 软件缺陷（Defect）定义:

软件缺陷Defect，常常被叫做Bug，IEEE729-1983对缺陷有一个标准定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背；

关于错误、缺陷等概念对应英文叫法如下，从英文说法可以更准确理解涵义。

• 错误：Error、Mistake

• 缺陷：Defect、Bug

• 故障：Fault

• 失效：Failure

以上我们通常都会称为bug。

2. 软件缺陷的两个重要因素：严重性 & 优先级：

严重性:

• 软件缺陷对软件质量的破坏程度，即此缺陷的存在将对软件的功能和性能产生怎样的影响

• 软件缺陷严重性的判断应该从软件最终用户观点做出判断，考虑缺陷对用户使用造成的恶劣后果的严重性

优先级:

• 表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正

• 反应缺陷对产品/系统甚至市场的影响

• 通常由产品经理根据客户需求或项目优先级而定

关于缺陷严重性和优先级的定义，这里仅梳理了互联网产品软件，涉及硬件等其他行业的可参考：

2.1. 缺陷级别严重程度Severity定义：

• 致命缺陷 block：系统崩溃，停止运行，阻碍开发或测试工作继续进行

• 严重缺陷 Critical：主流程不通，影响系统基本功能

• 重要缺陷 Major：功能没有完全实现但不影响使用，功能菜单存在缺陷但不会影响系统稳定性

• 一般缺陷 Minor：界面、性能缺陷

• 细微次要缺陷 Trivial：建议类问题

2.2. 缺陷处理的优先级Priority定义：

• P0 - 非常紧急：需立即解决 asap

• P1 - 紧急：尽快解决  must fix （1天）

• P2 - 高优先级：下次发布解决  fix when time permits（3天）

• P3 - 一般优先级：后续版本解决  fix after p0,p1,p2（5天）

• P4 - 低优先级：不着急解决 preferred （<20个工作日）

3. 缺陷处理优先级矩阵：

如何平衡缺陷处理和新需求之间的优先级，一个小技巧就是对分类，首先考虑影响用户程度，非技术类由产品决策，技术类需求也需要考虑用户体验和产品商量决策。

4. 缺陷日常管理：

最重要的信息：

1. 缺陷标题
   在缺陷库中第一眼看到的是缺陷的标题，标题需简洁明了、且其他项目组成员可以不看其它各种环境信息就知道是什么缺陷。

2. 缺陷简单描述
   可以和标题相同，目的是让项目组其他成员、尤其是测试人员可以在不看重现步骤时也能重现bug，在验证bug的时候，测试人员可以展开做测试，而不仅仅局限当前步骤。

3. 缺陷重现步骤
   对一些不能100%重现的缺陷尤为重要，开发人员可以从步骤牵涉的功能及操作等分析问题所在。

4. 缺陷出现概率
   不能100%重现的缺陷，需标注缺陷出现的概率例如：>50%, <50%，不能重现

缺陷描述的注意事项：

1. 查看当前测试环境并记录

2. 记录与该缺陷相关的配置等条件

3. 记录出现缺陷时候log信息

4. 描述尽量做到每个步骤最多两个动作，一连串的操作尽量分句说明

5. 尽量用主动句型

6. 缺陷出现时候的现象一定要描述详细，不要和步骤混在一起描述

7. 缺陷出现之后若可以继续进行操作，也尽量多做几个步骤，这样更容易发现当前缺陷周围的缺陷

8. 尽量把缺陷出现时候的相关功能运行情况也都描述详细

bug统计分析

   1...

总体上来说质量的衡量：

      线下发现bug越多，线上bug越少，质量越好