千峰软件测试学习营 第八章

缺陷和缺陷报告

一 缺陷的基本概述

• 缺陷的定义- 软件未实现产品说明书要求的功能- 软件出现了产品说明书指明不应该出现的功能- 软件实现了产品说明书中未提到的功能- 软件未实现产品说明书虽未明确提及但应该实现的目标- 软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户认为不好

注意：需求分析、设计阶段，文档类型的缺陷多；集成测试阶段，一般接口类型的缺陷多；系统测试阶段，功能、界面类型的缺陷多。验收测试阶段，更多的关注性能缺陷；实施过程，可能会遇到一些软件包的缺陷。

注意：结合缺陷的影响，结合软件的具体功能（业务或者流程）

注意：优先级的衡量，一般可以根据测试测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改

二 缺陷的生命周期

1. 发现缺陷。由测试人员。开发也能知道自己哪里写错了，但不会广而告之
2. 提交缺陷。由测试人员。开发更不可能提交bug
3. 确认缺陷。一般由测试主管、或质量保证（QA）、由产品经理进行确认
4. 分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、也可能是UI、也可可能是产品经理
5. 修复缺陷。主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题
6. 验证缺陷。测试去验证缺陷有没有修复成功
7. 关闭缺陷。只能说测试人员进行。否则出了问题，测试人员一律不背锅

三 缺陷的识别

依据：需求文档、设计文档、产品原型、测试用例，都是客观的依据

​ 同行业的类似成熟软件，和开发人员沟通，跟有经验的测试人员沟通，同行业隐形需求，都是带有主主观色彩的依据

四 缺陷报告

缺陷报告的填写目的：

1. 展现缺陷的详细信息
2. 展现缺陷的影响程度和方式

由于缺陷报告的读者很多：开发、质量管理、市场人员、运维人员

所以缺陷报告要写的很直白、清晰、明了

报告编写的准则：准确、清晰、一致、简洁、完整

缺陷描述的准则：单一准确、可以再现（针对大多数的缺陷都是如此。但是由一些小部分的缺陷是难以做到<类似闪退、崩溃这种不可再现的缺陷，无需做到。针对一些可以重复出现的闪退缺陷，也要进行步骤的详细描述>）、完整统一、短小简练、特定条件、补充完善、不做评价（不对缺陷的出现的严重成都和缺陷表现出来的效果进行主观臆断）

缺陷报告本身要保证没有任何表述性的错误

测试需求和测试用例、缺陷报告的关系？

测试的基本流程：获取测试需求——编写测试计划——制定测试方案——设计和开发测试用例——执行测试——提交缺陷——测试分析和评审——测试总结——准备下一版本的测试

获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试方向和内容。例如：

1. 分析出系统的模块和组织结构
2. 分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用
3. 识别出软件的重要功能和次要功能

获取测试需求的过程中，测试人员就要哟见相应的分析成果。一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析

测试设定中需求的正、反向，和优先级。

当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计。也就是，每一个需求点，都要被测试。

因此测试的过程中，衡量需求的覆盖程度，就非常重要。使用：

需求的覆盖程度=被测试用例覆盖的需求数/需求点总数

进行计算和说明。

如果需求覆盖度<100％，那一定说明了测试的覆盖度不够。