软件测试中的测试文档（示例）
托马斯·汉密尔顿
什么是测试文档？
测试文档是对软件测试之前或测试过程中创建的各种工件的记录。它有助于测试团队估算所需工作量、跟踪资源和进度，并确保充分的测试覆盖率。测试记录和报告是一套完整的文档，可用于描述和记录测试计划、测试设计、测试执行以及从测试活动中获得的测试结果。
👉 免费注册实时软件测试项目
为什么需要测试形式化？
对于新手来说，很容易误以为测试就是随意执行代码的各个部分并验证结果。但实际上，测试是一项非常规范的活动，并且会详细记录下来。测试文档使得测试的计划、审查和执行变得简单易行，并且可验证。
测试的规范程度取决于：
- 被测应用程序（AUT）的类型。
- 您的组织遵循的标准。
- 开发过程的成熟度。
测试活动通常耗时介于 30％和50％ 文档是软件开发总工作量的一部分。文档有助于发现可应用于未来项目的测试流程改进之处。
测试文档有哪些类型？
以下是一些重要的测试文档类型：
“实际上，这些文档是在不同的阶段创建的——从早期规划（测试策略、方法）到执行和收尾（缺陷报告和总结报告）。”
| 测试文档的类型 | 描述 |
|---|---|
| 测试政策 | 这是一份高层次的文件，描述了该组织的原则、方法以及所有重要的测试目标。 |
| 测试策略 | 一份高层次文档，用于确定项目要执行的测试级别（类型）。 |
| 测试计划 | 测试计划是一份完整的计划文件，其中包含测试活动的范围、方法、资源、进度安排等。 |
| 需求可追溯性矩阵 | 这是一份将需求与测试用例联系起来的文档。 |
| 测试场景 | 测试场景 是软件系统中可以通过一个或多个测试用例进行验证的项目或事件。 |
| 测试用例 | 它包含一组输入值、执行前提条件、预期执行后置条件和结果。它是为测试场景而开发的。 |
| 测试数据 | 测试数据是指在执行测试之前已存在的数据，用于执行测试用例。 |
| 缺陷报告 | 缺陷报告是对软件系统中任何未能执行其预期功能的缺陷的记录报告。 |
| 测试总结报告 | 测试总结报告是一份高层次的文件，总结了所进行的测试活动以及测试结果。 |
实现测试文档编写的最佳实践是什么？
在本节中，我们将学习有助于编写测试文档的最佳实践，并通过示例帮助您更好地理解：
- 让质量保证团队尽早参与项目： 从项目一开始就让质量保证团队参与进来，以便测试文档能够与产品设计和需求同步发展。
计费示例： QA 在迭代计划会议期间与用户协作，根据用户故事起草初始测试用例。 - 保持文档更新： 不要创建测试文档后就置之不理——当需求或功能发生变化时，要及时更新测试文档。
计费示例： 当登录 API 发生变更时，应立即更新相关的测试用例和结果。 - 使用版本控制： 通过版本控制系统管理和跟踪测试文档的所有更改，以避免混淆和数据丢失。
计费示例： 将测试计划存储在 GitHub 中，以便保持清晰的版本历史记录和回滚选项。 - 文件应清晰明确、目的明确： 只记录那些有助于你和你的利益相关者了解测试进度和交付成果的内容。
计费示例： 包含测试总结报告，其中应重点突出通过、失败和阻塞的测试用例，供管理层审核。 - 使用标准模板： 遵循一致的格式（例如 Excel 或 Word 模板），使文档的创建和审核更加容易。
计费示例： 使用标准的“测试用例模板”，其中包含 ID、描述、前提条件和预期结果等字段。 - 集中式文档存储： 将所有项目相关文档保存在一个易于访问的位置，以确保团队成员可以轻松查阅或更新这些文档。
计费示例： 将测试工件存储在共享目录中 Google Drive 整个测试和开发团队都可以访问此文件夹。 - 提供足够细节： 避免提供模糊或不完整的信息；详细的文档有助于提高理解，并减少测试执行过程中的错误。
计费示例： 请勿写“检查登录”，而应写成“验证用户使用有效凭据登录后，是否成功重定向到控制面板”。
软件测试何时需要编写测试文档？
以下是何时应该为软件测试创建测试文档的一些关键点：
- 规划阶段： 在测试执行开始之前，要明确定义范围、目标和测试策略。
- 测试准备： 在测试计划阶段，要高效地确定时间表、资源和环境要求。
- 需求分析： 在需求分析之后，确保功能性和非功能性规范得到全面覆盖。
- 设计标准化： 在设计测试用例之前，要规范格式并保持所有文档的可追溯性。
- 场景文档： 在测试设计过程中，记录场景、输入、预期输出和测试数据详情。
- 执行准备情况： 在执行测试之前，验证测试环境、工具和文档的准备情况是否准确。
- 事后评估： 测试后，记录结果、缺陷和经验教训，以改进流程。
测试文档需要哪些类型的模板？
以下是一些软件测试中编写测试文档所需的模板：
| 模板名称 | 工具 |
|---|---|
| 测试计划模板 | Microsoft Word, Google Doc或 Confluence，用于协作编辑和版本控制 |
| 测试用例模板 | TestRail、Zephyr（在 JIRA 中）、Xray 或 Excel/Google Sheets 用于结构化测试管理 |
| 测试场景模板 | 使用 JIRA、TestLink 或 Google Sheets 来记录高级测试条件 |
| 需求可追溯性矩阵 (RTM) 模板 | 使用 Excel、Google Sheets 或 TestRail 将需求映射到测试用例 |
| 缺陷报告模板 | JIRA、Bugzilla 或 Azure DevOps 用于缺陷记录和跟踪 |
| 测试总结报告模板 | 合流， Google Docs，或者使用 TestRail 来编译测试结果和进行分析 |
测试文档的优点和缺点
优点
- 创建测试文档的主要目的是减少或消除测试活动中的不确定性。它有助于消除在任务分配过程中经常出现的歧义。
- 文档不仅提供了系统的方法 软件测试，但它也可作为软件测试流程中新手的培训材料。
- 展示测试文档可以很好地体现成熟的测试流程，这是一种有效的营销和销售策略。
- 测试文档有助于您在规定的时间内向客户提供高质量的产品。
- In 软件工程测试文档还可以通过配置文档和操作手册来配置或设置程序。
- 测试文档有助于提高与客户的沟通透明度。
缺点
- 由于文档非常耗时，其成本可能超过其价值。
- 很多时候，它是由文笔不好或不了解材料的人写的。
- 跟踪客户要求的变更并更新相应的文件是件很累的事。
- 文档不完善会直接影响产品质量，因为客户和组织之间可能会出现误解。
测试文档中应避免的常见错误
以下是编写测试文档时最常犯的错误，您应该避免这些错误：
- 避免编写不清晰或含糊不清的测试用例描述。
- 不要省略测试前提条件和依赖项的文档编写。
- 切记要包含每次测试的预期结果。
- 避免不同测试文档格式不一致。
- 不要使用模糊或无法衡量的测试目标。
- 测试文档更新绝不能忽略版本控制。
- 避免在多个测试工件中重复信息。
- 切勿忽视对文件的准确性和完整性进行审核。
