软件测试 - 文档

软件测试 - 基本文档

软件测试文档是指在测试活动之前、期间和之后创建的一系列工件。全面的文档对于整个测试过程的规划、执行、跟踪和沟通至关重要。它有助于估算工作量、确保测试覆盖率、追踪需求，并保留测试结果记录。

虽然文档的形式和详细程度可能有所不同（例如，传统项目中更详细，敏捷 (Agile) 项目中更轻量和动态），但某些核心文档仍然重要。现代测试管理工具（例如，集成了 Xray/Zephyr 的 Jira、TestRail、qTest）通常有助于以数字化方式管理这些工件，使其成为“活文档”。

测试计划 (Test Plan)

测试计划是一个战略性文档，概述了预期测试活动的范围、方法、资源和进度。它为整个测试工作提供了路线图。通常，测试负责人 (Test Lead) 或测试经理 (Test Manager) 负责创建测试计划，通常基于 IEEE 829 等标准。

一份全面的测试计划通常包括：

引言和范围：将测试什么和不测试什么。
测试策略：总体方法、测试类型（例如，功能测试、性能测试）和测试级别。
测试目标：测试工作的目标。
待测试/不测试的功能：在范围内的具体功能。
测试可交付成果：将产出的文档和工件列表。
测试环境：硬件、软件和数据要求。
资源：角色、职责和所需技能。
进度：时间表、里程碑和依赖关系。
风险和应急计划：潜在问题和缓解计划。
入口和出口标准：开始和结束测试阶段的条件。
度量指标：如何衡量和报告测试进度和质量（例如，在测试总结报告中）。

在敏捷环境中，测试计划可能是一个更精简的文档，或集成到团队的 Wiki 或 Backlog（任务清单）中，更侧重于未来迭代的测试策略。

测试场景 (Test Scenario)

测试场景提供了需要测试的功能或用户故事的高级描述。它本质上回答了“应该测试什么？”的问题。测试场景源自需求（例如，用户故事、用例），有助于确保从端到端视角覆盖所有重要的流程流和功能。一个测试场景可以引出多个更详细的测试用例。

例如，对于一个电子商务应用，一个测试场景可能是：“验证注册用户使用信用卡支付的完整结账流程。”这个高级别的场景随后会被分解为覆盖结账流程中不同步骤和条件的具体测试用例。测试场景有助于组织测试并在更广泛的层面沟通测试覆盖率。

测试用例 (Test Case)

测试用例是一组详细的条件或动作，以及它们的预期结果，旨在验证功能或需求的特定方面。它回答了“如何测试这个特定部分？”的问题。编写良好的测试用例精确、可重复，并具有明确的通过/失败标准。

测试用例的常见组成部分包括：

测试用例 ID：唯一标识符。
标题/目的：正在测试内容的简要描述。
模块/功能：正在测试的应用的特定部分。
前置条件：执行测试前必须满足的条件。
测试步骤：详细的执行动作序列。
测试数据：将使用的具体输入值。
预期结果：如果软件正常工作，预期的结果。
实际结果：执行测试步骤后观察到的结果（在执行期间填写）。
通过/失败状态：指示测试是通过还是失败。
后置条件：测试执行后的系统状态。

行为驱动开发 (Behavior-Driven Development, BDD) 使用 Gherkin 语法编写测试用例，这些测试用例同时也是人类可读的规范，例如：“Given a user is on the login page, When they enter valid credentials, Then they should be redirected to the dashboard.”（给定用户位于登录页面，当他们输入有效凭据时，那么他们应该被重定向到仪表板）。有效地管理测试数据也是测试用例设计的一个关键方面。

追溯矩阵 (Traceability Matrix)

需求追溯矩阵 (Requirement Traceability Matrix, RTM) 是一个文档，通常以表格形式存在，它将需求与其对应的测试用例（有时也与设计元素、代码模块和缺陷）关联起来。它确保所有需求都至少被一个测试用例覆盖到（正向追溯：需求到测试），并且每个测试用例都关联到一个有效需求（反向追溯：测试到需求）。

RTM 的主要目标和优势包括：

确保所有指定需求都有 100% 的测试覆盖率。
帮助识别遗漏的需求或未测试的功能。
协助影响分析：如果需求发生变化，RTM 显示哪些测试用例需要更新。
提供每个需求的测试进度可见性。
通过追溯到需求，有助于识别缺陷的根本原因。

其他重要的测试文档包括缺陷报告 (Bug Reports)（详细说明发现的缺陷，包括重现步骤、严重性和优先级）和测试总结报告 (Test Summary Reports)（总结测试活动、结果，并在测试周期或里程碑结束时提供质量的总体评估）。这些文档对于沟通和决策制定至关重要。