软件测试基础：缺陷、用例与测试文档
软件测试作为质量保障的核心手段，其基础理论决定了测试活动的有效性与可追溯性。本章围绕四个关键支柱展开：软件缺陷的识别与生命周期管理、测试用例的设计要素与原则、以及测试文档（计划、方案、报告）的编写规范。理解这些基础，是构建高效、可度量的测试体系的前提。下图概括了本章知识框架及核心要素之间的逻辑关系。
2.1 软件缺陷的定义与属性
核心原理
软件缺陷（Defect/Bug）是指软件产品在开发或维护过程中存在的、导致软件不能完全满足用户需求或规格说明的问题。根据IEEE标准，缺陷是“程序或系统中存在的，可能导致系统失效或产生不正确结果的瑕疵”。缺陷不仅包括代码错误，还涵盖设计缺陷、文档错误、界面问题、性能瓶颈等。
缺陷的属性是缺陷管理的基础，主要包括：
- 缺陷标识：唯一编号，便于追踪。
- 缺陷状态：New、Open、Fixed、Closed等。
- 严重程度（Severity）：对系统的影响程度，通常分为致命（Fatal）、严重（Critical）、一般（Major）、轻微（Minor）四级。
- 优先级（Priority）：修复的紧迫程度，分为紧急（Urgent）、高（High）、中（Medium）、低（Low）。
- 缺陷来源：需求、设计、编码、集成、文档等阶段。
- 复现步骤与环境：帮助开发人员定位问题。
判断方法或操作流程
判断一个问题是缺陷还是预期行为，通常遵循以下流程：
- 对照需求规格说明书：确认是否与需求不一致。
- 对照设计文档：检查是否偏离设计意图。
- 参考用户手册：确认是否与文档描述冲突。
- 与产品经理/开发确认：对于模糊需求，需人工确认。
案例拆解
某电商平台在支付流程中，用户点击“确认支付”后，页面无响应，但后台订单状态已更新为“已支付”。测试人员记录缺陷：严重程度=严重（Critical），优先级=紧急（Urgent），因为该问题直接影响用户资金安全和交易体验。复现步骤包括：使用Chrome浏览器、登录账号、添加商品、进入支付页、点击确认支付。环境信息包括操作系统、浏览器版本、网络状态等。该缺陷最终定位为前端回调接口超时导致。
2.2 缺陷生命周期
核心原理
缺陷生命周期描述了缺陷从被发现到关闭的完整状态流转过程。标准流程包括：New（新建）→ Open（打开/确认）→ Fixed（修复）→ Closed（关闭），以及Reopen（重开）和Rejected（拒绝）等状态。生命周期管理确保每个缺陷都有明确的处理路径和责任人。
| 状态 | 含义 | 责任人 | 操作 |
|---|---|---|---|
| New | 测试人员提交缺陷 | 测试工程师 | 填写缺陷报告 |
| Open | 开发确认缺陷有效 | 开发负责人 | 分配修复任务 |
| Fixed | 代码已修复 | 开发工程师 | 提交修复版本 |
| Closed | 测试验证通过 | 测试工程师 | 回归测试通过 |
| Reopen | 验证未通过或回归失败 | 测试工程师 | 重新激活缺陷 |
| Rejected | 非缺陷或重复提交 | 开发负责人 | 说明拒绝理由 |
操作流程
- 测试人员发现缺陷，填写缺陷报告并提交。
- 测试负责人审核，确认信息完整后置为New。
- 开发负责人分配缺陷给对应开发人员，状态置为Open。
- 开发修复后提交代码，状态置为Fixed。
- 测试人员在新版本中执行回归测试，通过则置为Closed；不通过则置为Reopen。
- 若开发认为不是缺陷，可置为Rejected并附说明。
2.3 测试用例的基本要素与设计原则
核心原理
测试用例（Test Case）是为特定测试目标而设计的一组输入、执行条件和预期结果的集合。一个完整的测试用例应包含以下基本要素：
- 用例编号：唯一标识，如TC-PAY-001。
- 测试标题：简洁描述测试目的。
- 前置条件：执行用例前必须满足的环境或数据条件。
- 测试输入：具体的数据或操作。
- 测试步骤：详细的操作步骤。
- 预期结果：系统应产生的正确行为。
- 实际结果：执行后的真实结果（执行时填写）。
- 优先级：用例执行的先后顺序。
设计基本原则
- 代表性：用例应能代表一类输入，而非仅覆盖单一数据。
- 可判定性：预期结果必须明确、可验证。
- 可复现性：用例步骤清晰，任何测试人员执行结果一致。
- 最小性：用最少的用例覆盖最多的功能点。
- 可追踪性：用例应能追溯到需求。
案例拆解：登录功能测试用例设计
假设一个登录模块，需求为“用户名和密码正确则登录成功，否则提示错误”。使用等价类划分和边界值分析设计用例：
| 用例编号 | 输入 | 预期结果 | 设计方法 |
|---|---|---|---|
| TC-LOGIN-001 | 正确用户名+正确密码 | 登录成功，跳转首页 | 有效等价类 |
| TC-LOGIN-002 | 正确用户名+错误密码 | 提示“密码错误” | 无效等价类 |
| TC-LOGIN-003 | 用户名长度为1字符 | 提示“用户名长度不足” | 边界值（下边界） |
| TC-LOGIN-004 | 用户名长度为20字符 | 登录成功（若规则允许） | 边界值（上边界） |
2.4 测试文档的编写规范
核心原理
测试文档是测试活动的“契约”和“证据”。主要包括三类：测试计划（管理性文档）、测试方案（技术性文档）、测试报告（总结性文档）。
测试计划编写规范
- 项目背景：简述项目目标、范围。
- 测试目标：明确要验证的功能、性能、兼容性等。
- 测试范围：列出被测功能点和不测范围。
- 资源安排：人员、环境、工具、时间表。
- 风险与应对：识别风险并制定预案。
测试方案编写规范
- 测试策略：选择测试类型（功能、性能、安全等）。
- 测试环境：硬件、软件、网络拓扑。
- 测试数据：数据准备方案。
- 用例设计方法：说明采用的具体技术。
- 准入准出标准：明确开始和结束测试的条件。
测试报告编写规范
- 测试概述：测试时间、人员、环境。
- 测试结果统计：用例执行数、通过率、缺陷数。
- 缺陷分析：按严重程度、模块分布。
- 质量结论：是否达到发布标准。
- 遗留问题：未解决缺陷及影响。
案例拆解：测试报告中的缺陷分析
某项目测试报告显示：共执行用例500条，通过460条，通过率92%。缺陷总数30个，其中致命0个，严重5个，一般15个，轻微10个。按模块分布：支付模块12个（40%），订单模块8个（27%），用户模块6个（20%），其他4个（13%）。结论：严重缺陷集中在支付模块，需修复后回归测试，暂不满足发布条件。
总结复盘
本章核心要点：
- 缺陷管理是测试的基础，需明确属性并跟踪生命周期。
- 测试用例设计需遵循代表性、可判定性等原则，结合等价类、边界值等方法。
- 测试文档（计划、方案、报告）是测试活动的规范化和可追溯性的保障。
- 缺陷生命周期中的Reopen率、测试用例通过率是衡量测试质量的关键指标。