软件测试第四章-缺陷管理【重点】

1.1 软件缺陷简介

• 缺陷不等于bug，bug只是缺陷中很小的一部分而已
• 什么是缺陷：只要让测试人员感觉不爽，那么这个就是缺陷

软件缺陷判定标准

• 软件未能达到需求规格中的要求
• 软件的功能超出规格书中的要求
• 软件出现了规格书中未明确指定，但是不应该出现的错误

软件缺陷产生的原因【缺陷只能减少，不能完全避免】

• 对于需求文档等文件解释，理解错误
• 设计文档本身有错误
• 程序代码错误
• 硬件和软件系统有错

软件缺陷的类型

1.功能错误：软件没有达到需求文档的功能要求，或者功能异常

2.界面错误：软件功能正常，但是界面不好看或没有达到规格说明中的要求

3.兼容性错误：软件和系统中的其他的程序冲突，导致软件无法运行

4.易用性错误：软件用起来不好用

5.改进建议：改了更好，不改也不影响使用

---

1.2 提交缺陷注意事项               

可重现：

发现缺陷可以在开发的电脑上再次出现

唯一性：

每个缺陷有一个唯一的编号，也就是缺陷的 ID

缺陷报告每行是一个缺陷

规范性：

提交的缺陷需要符合公司定制的规范

缺陷报告的规范

ID ：

标题：

重现步骤

期望结果

实际结果

---

1.3  处理缺陷的流程   

        

 

---

1.4缺陷相关概念

缺陷状态

new：测试人员提交新 bug ，这个 bug 状态是新建

open ：处理 bug 的开发，打开测试提交的哪个 bug ，这个状态是打开

fifix ：开发已经将 bug 处理完成，这个状态 fifix 、 fifixed

close ：将处理完成的 bug 关闭掉，这个状态的 bug 就是 close 、 closed

reopen ：开发处理过，但是回归测试没有通过的 bug ，状态就是 repoen

reject ：开发拒绝处理 bug

postpone ：不是紧急 bug ，不需要马上处理，延后处理

结合状态写工作流程：

流程 1 ：确认 bug 处理

• 70-80%
• 测试【 new 】 => 开发【 open 】 => 开发【 fifix 】 => 测试【 close 】

流程 2 ：开发处理 bug 后，但是未通过回归测试

• 10-20%
• 测试【 new 】 => 开发【 open 】 => 开发【 fifix 】 => 测试【 reopen 】

流程 3 ：延后处理

• 10%
• 测试【 new 】 => 开发【 open 】 => 开发【 postpone 】

流程 4 ：拒绝处理

• 5%
• 测试【 new 】 => 开发【 open 】 => 开发【 reject 】

缺陷的严重等级

• critical，致命，5：系统级别的故障，例如系统宕机。
• major，非常高，4：严重的bug，系统可以运行，但是核心业务受影响。
• medium，中等，3
• minor，低，2
• tiny，非常低，1

缺陷的优先级

• 等级5：紧急的
• 等级4：非常高
• 等级3：高
• 等级2：中
• 等级1：低

补充内容：公司的基本组成

• 产品部门：产品经理
• 研发部门：程序员、项目经理
• 测试部门：测试

产品经理：

• 对接客户，将客户的需求整理成文档
• 对接开发/项目经理，讨论项目实现的细节【编程语言，数据库，编码，服务器】

项目经理：

• 将讨论的结果整理成项目文档
• 对接开发/项目经理，讨论项目实现的细节【编程语言，数据库，编码，服务器...】
• 最后将各个程序员开发的模块合并起来

程序员：

• 写代码

测试：

• 测试代码

---