1 缺陷的基本概述
1.1 缺陷的定义
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指明不应该出现的功能
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提及但应该实现的功能
- 软件难以理解、不易使用、运行缓慢或最终用户认为不好
1.2 缺陷的属性
| 属性名称 | 描述 |
|---|---|
| 缺陷类型（Type） | 根据缺陷的自然属性划分的缺陷种类 |
| 缺陷严重程度（Severity） | 指因缺陷引起的故障对软件产品的影响程度 |
| 缺陷优先级（Priority） | 指缺陷必须被修复的紧急程度 |
| 缺陷状态（Status） | 指缺陷通过一个跟踪修复过程的进展情况 |
| 缺陷起源（Origin） | 指缺陷引起的故障或事件第一次被检测的阶段 |
| 缺陷来源（source） | 指缺陷的起因 |
| 缺陷根源（Root Cause） | 指发生错误的根本因素 |
缺陷类型
| 缺陷类型 | 描述 |
|---|---|
| 功能 | 影响了各种系统功能、逻辑的缺陷 |
| 用户界面 | 影响了 用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷 |
| 文档 | 影响发布和维护，包括注释、用户手册、设计文档 |
| 软件包 | 由于软件配置库、变更管理或版本控制引起的错误 |
| 性能 | 不满足系统可测量的属性值，如执行时间、事务处理速率等 |
| 系统/模块接口 | 与其他组件、模块或设备驱动程调用函控制块或参数列表等不匹配、冲突 |
注意：
需求分析、设计阶段，文档类型的缺陷多；
集成测试阶段，一般接口类型的缺陷多；
系统测试阶段，功能、界面类型的缺陷多；
验收阶段，更多关注性能缺陷；
实施过程中，可能会遇到一些软件包的缺陷。
缺陷的严重程度
| 缺陷严重等级 | 描述 |
|---|---|
| 致命（Fatal） | 系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机，或者危及人身安全 |
| 严重（Critical） | 系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显影响 |
| 一般（Major） | 系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题 |
| 较小（Minor） | 是操作者不方便或遇到麻烦，但不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 |
缺陷严重程度是对软件的影响。
注意： 分类结合缺陷的影响、软件的具体功能（业务或流程）
缺陷的优先级
| 缺陷优先级 | 描述 |
|---|---|
| 立即解决（ P1级） | 缺陷导致系统几乎不能使用或测试不能继续，需立即修复 |
| 高优先级（P2级） | 缺陷严重，影响测试，需优先考虑 |
| 正常排队（P3级） | 缺陷需要正常排序等待修复 |
| 低优先级（P4级） | 缺陷可以在开发人员有时间的时候被纠正 |
缺陷的优先级很大程度取决于缺陷对测试工作的影响程度。
例如：电商系统的用户注册功能无法使用（无法登录、购买、结算、支付、下订单、物流跟踪、收货、评论等功能都无法进行），就必须立即修复；电商系统中关于用户购买流程帮助说明的网页链接点击404页面。
注意： 优先级的衡量一般可以根据测试的软件系统的全业务流程划分，软件基本功能的缺陷，优先级高，且需要立即解决；软件的备选流、基本功能测试的反向测试内容，优先级低，有些甚至可改可不改。
面试题：缺陷的严重程度和优先级有什么关系？
1）二者之间没有直接关系；
2）严重的缺陷 不等于 修复优先级高；
3）即便优先级和严重程度都高，也只是偶然。
例如： QQ的帮助按钮，会经常遇到闪退的现象，严重程度很高，但优先级很低。
提交缺陷时，不能夸大或降低缺陷的严重程度或者优先级
缺陷状态
| 缺陷状态 | 描述 |
|---|---|
| 激活或打开 | 问题还没有解决，存在源代码中，确认“提交的缺陷” ，等待处理，如新报的缺陷 |
| 已修正或修复 | 已被开发人员检查 、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证 |
| 关闭或非激活 | 测试人员验证后，确认缺陷不存在之后的状态 |
| 重新打开 | 测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复 |
| 推迟 | 这个软件缺陷可以在下一个版本中解决 |
| 保留 | 由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷 |
| 不能重现 | 开发不能再现这个软件缺陷，需要测试人员检查缺陷复现的步骤 |
| 需要更多信息 | 开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等 |
| 重复 | 这个软件缺陷已经被其他的软件测试人员发现 |
| 不是缺陷 | 这个问题不是软件缺陷 |
| 需要修改软件规格说明书 | 由于软件规格说明书对软件设计的要求，必须要修改软件规格说明书 |
缺陷状态表示缺陷的处理进度。
发现缺陷是所有缺陷处理的前提条件，但是还没有进入缺陷的处理流程。
1）激活/打开（新建）：由测试人员进行标注。
2）确认：确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、质量保证（QA）或者产品经理进行确认。经确认后，有效缺陷会指派给相关人员进行处理。
3）已修复/修正：在缺陷被修复后，一般由开发人员进行。
4）关闭/非激活：经测试人员验证没问题。
5）重新打开：经测试人员验证没有被修复，需要再次打开进行修复。
6）推迟：测试要跟开发或者其他管理人员进行确认。
7）保留：一般由开发人员设定。
8）不能重现：开发按照缺陷复现步骤不能再次发现缺陷。一般如闪退、崩溃类型的缺陷，或者由于从操作系统差异、浏览器的缓存等信息，出现的问题。所以测试人员提交bug前要再三确认。
9）需要更多信息：作为测试人员 提交bug时，要尽可能的把相关文件一起提交（图片、视频）。
10）重复：一定要避免这种情况。
11）不是缺陷：一定不要出现此情况！！！
12）需要修改软件说明书：缺陷不是技术原因造成，而是由于需求、设计不明确。
缺陷起源
缺陷引起的故障或事件第一次被检测到的阶段
| 缺陷起源 | 描述 |
|---|---|
| 需求 | 在需求阶段发现的缺陷 |
| 构架 | 在系统架构设计阶段发现的缺陷 |
| 设计 | 在程序设计阶段发现的缺陷 |
| 编码 | 在编码阶段发现的缺陷 |
| 测试 | 在测试阶段发现的缺陷 |
| 用户 | 在用户使用阶段发现的缺陷 |
缺陷来源
缺陷发生的起因
| 缺陷来源 | 描述 |
|---|---|
| 需求说明书 | 需求说明书的错误或不清楚引起的问题 |
| 设计文档 | 设计文档描述不准确，和需求说明书不一致的问题 |
| 系统集成接口 | 系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷 |
| 数据流（库） | 由于数据字典、数据库中的错误引起的缺陷 |
| 程序代码 | 是编码中的问题所引起的缺陷 |
缺陷根源
缺陷发生的根本因素
| 缺陷根源 | 描述 |
|---|---|
| 测试策略 | 错误的测试范围，误解测试目标，超越测试能力等 |
| 过程、工具和方法 | 无效的需求过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等 |
| 团队/人 | 项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等 |
| 缺乏组织和通讯 | 缺乏用户参与、职责不明确，管理失败等 |
| 硬件 | 硬件配置不对、缺乏，或处理器导致算术精度丢失，内存溢出 |
| 软件 | 软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译错误，千年虫的问题等 |
| 工作环境 | 组织机构调整，预算改变，工作环境恶劣，如噪音过大 |
一般关注较多的是缺陷来源（直接原因；在测试总结阶段，关注缺陷根源。
2 缺陷的生命周期
- 发现缺陷：由测试人员去发现
- 提交缺陷：由测试人员提交
- 确认缺陷：一般由测试主管、质量保证（QA）或者产品经理进行确认
- 分配缺陷：一般由谁确认就由谁分配。分配的对象可以是开发、UI、产品经理
- 修复缺陷：主要由开发修复，也有可能是产品经理修复问题
- 验证缺陷：测试人员去验证是否修复成功
- 关闭缺陷：只能是测试人员进行，否则出了问题一律不负责。
3 缺陷的识别
客观依据： 需求文档、设计文档、产品原型、测试用例。
- 通过测试用例中的预期结果进行识别
- 通过需求规格说明书进行识别
- 通过用户手册及其他文档进行识别
主观依据 ：
- 通过同行业相类似成熟的商业软件来识别
- 通过和开发人员的沟通进行识别
- 通过和有经验的测试人员沟通进行识别
- 参照同行业隐式需求进行识别
4 缺陷报告
4.1 缺陷报告模板
| 缺陷编号 | 所属模块 | 优先级 | 严重程度 | 缺陷概述 | 缺陷描述 | 提交人 | 备注 |
|---|---|---|---|---|---|---|---|
- 缺陷编号：Bug_项目名称_模块名称_功能名称_0001
- 所属模块：一级模块/二级模块/三级模块
- 优先级：缺陷修复紧急程度。 P1>P2＞P3＞P4
- 严重程度：S1>S2＞S3＞S4
- 缺陷概述：用一句话描述缺陷基本情况
- 缺陷描述：将缺陷复现步骤、预期结果和实际结果列出来
- 提交人：xxx
- 备注：一般写产生该缺陷的特殊情况，可将bug截图作为备注信息
4.2 缺陷报告编写目的
- 易于搜索软件测试报告缺陷
- 报告的软件缺陷进行了必要的隔离 ，报告的缺陷信息更具体、准确
- 软件开发人员希望获得缺陷的本质特征和复现步骤
- 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度
4.3 缺陷报告编写准则
- 准确（Correct）：每个组成部分的描述准确，不会引起误解
- 清晰（Clear）：每个组成部分的描述清晰，易于理解
- 简洁（Concise）：只包含必不可少的信息，不包括任何多余的内容
- 完整（Complete）：包含复现该缺陷的完整步骤和其他本质信息
- 一致（Consistent）：按照一致的格式书写全部缺陷报告
4.4 缺陷描述准则
单一准确、可以再现（绝大数，除类似闪退、崩溃的缺陷）、完整统一、短小简练、特定条件、补充完善、不做评价
4.5 缺陷跟踪系统
- Bugzille（英文），安装比较复杂
- Bugfree（中文），安装简单，用例、缺陷的跟踪，功能单一
- 禅道（中文），国产，项目、产品、测试齐全，组织机构、人员、开源、免费
- QC（ALM） 国外 英文 功能齐全
- JIRA 国外的软件 java环境 主流（商业）
- 企业自己开发
测试需求和测试用例、缺陷报告的关系？
测试的基本流程： 获取测试需求—编写测试计划—设计和开发测试用例—执行测试—提交缺陷报告—测试分析和评审—测试总结—准备下一版本的测试
-
获取测试需求是测试工作进行的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。例如：
1）分析出系统的模块和组织结构。
2）分析出软件的基本 功能和运行流程。（业务分析）包括可能哪些人或者哪些角色要用。
3）识别出软件的重要功能和次要功能。 -
获取测试需求的过程中，测试人员就要有相应的分析成果。一般使用如xmind的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。
当有了测试需求后，就开始对每一个需求点进行测试用例的设计。因此，测试的过程中，衡量需求的覆盖程度就非常重要。使用以下公式进行计算和说明。
需求的覆盖程度 = 被测试用例覆盖的需求数 / 需求点数
如果需求覆盖度 ＜ 100％，那一定说明测试的覆盖度不够。
测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
1）设计的测试用例总量，TC；
2）执行的测试用例数量，EC；
3）未执行的测试用例数量，WC
4）执行通过的测试用例总量，SC；
5）执行失败的测试用例总量，FC；
6）提交的缺陷的总量，BC(Bug Counts)。
以上六个数据，要符合如下的数量关系：
1）TC ≥ EC
2）TC = EC + WC
3）EC = SC + FC
4）BC ≥ FC。这是由于一条测试用例的预期结果数量是固定的（甚至是唯一的）。根据需求所写的测试用例中执行失败的用例，或许会发现需求之外的缺陷，又或者预期结果之外的缺陷。即缺陷不止是从失败的测试用例中发现的，一部分也会是测试人员自身经验和直觉带来的。
5）SC / EC 可以表现出系统的质量是否合格。
6）EC / TC 可以表现出系统的需求是否得到满足。