测试用例怎么编写与设计

编写与设计测试用例的过程：1、收集测试文档；2、提取要求；3、设定测试目标；4、编写测试用例。收集测试文档是指，收集描述被测功能/系统的文档，测试人员将依靠这些类型的文档来了解被测功能/系统的要求，然后开始为其设计和编写测试用例。

一、编写与设计测试用例的过程

1、收集测试文档

测试文档是描述被测功能/系统的文档。测试人员将依靠这些类型的文档来了解被测功能/系统的要求，然后开始为其设计和编写测试用例。

测试文档包括：

• 功能需求规范 （FSR）
• 系统要求规范 （SRS）
• UI 样机或 UI 线框
• 用例
• 帮助文件
• 发行说明
• 甚至是电子邮件。

同样，这因团队而异，因公司而异。有些会有更好的文档，而有些则没有，但没关系。如果测试人员不确定或找不到正确的文档，应当继续向上级索取这些文件。即使在最坏的情况下，也要继续与开发人员讨论所测试的功能/系统。此步骤的整个思想是拥有可以依赖的东西来理解功能的要求，以便您可以开始设计测试。

注意：维护文档并使其保持最新是麻烦的，因此测试人员不要假设手中的所有文档都得到了很好的更新。请准备好与团队同步功能的实际构建方式。

2、提取要求

如果测试人员足够幸运，已经有一个从文件中提取的要求列表，那就可以直接使用。如果没有，测试人员必须自己提取。

以下是提取要求的操作：

• 逐行阅读文档
• 确定描述要求的短语
• 跳过不是必需的短语
• 注意不明确的要求，并要求产品所有者、项目经理和客户解释它们。

以下是测试人员经常问的两个重要问题，以便确定良好的要求：

• 这个要求明确吗？例如：我是否清楚地了解哪些特性/功能可以正常工作？这里的期望是什么？
• 此要求是否可测试？例如：我可以测试它吗？我可以预测预期的结果吗？

3、设定测试目标

根据收集的需求，测试人员可以开始列出测试目标/测试想法以满足需求。这是测试人员的创造力脱颖而出的地方。利用测试人员的创造力创建尽可能多的测试想法来验证需求。但是，为了保持设计测试用例方式的一致性，建议应用常用测试技术来设计测试思路：

• 等价类划分法
• 边界值分析法
• 决策表法
• 判定表法
• 错误推测法
• 正交实验法

测试人员可以在测试管理工具或电子表格中跟踪测试要求。您还可以根据需要添加一些属性，例如优先级、类型（功能、非功能、外观等）、可追溯性等

4、编写测试用例

现在测试人员应该有一个满足你需求的测试想法列表，以及基本上完成了测试用例设计。测试人员可以根据列出的测试想法开始测试。但是，为了完全完成测试设计阶段，您需要开始为测试用例或所谓的“编写测试用例”添加详细信息。

测试用例包含以下组件：

• 测试用例名称：您的测试用例名称应清晰，并反映您正在测试的组件。
  • TC_Login_Valid_01
  • TC_Login_Valid_02
  • TC_Login_Invalid_01
• 测试用例说明：描述要测试的内容或要测试的目标。我的建议是将测试需求描述放入此字段。
• 前提条件：描述运行此测试用例之前的必要准备工作。这将有助于测试人员正确运行测试。例如：需要什么浏览器、支持设备和软件等。
• 测试用例步骤：描述执行测试的必要步骤。有两种编写测试用例步骤：详细步骤和高级步骤。

详细步骤示例（以Gmail为例）：

• 第 1 步：导航到“http://mail.google.com”
• 第 2 步：输入用户名
• 第 3 步：输入密码
• 第 4 步：单击登录按钮

高级步骤示例（以Gmail为例）：

• 第 1 步：转到 Gmail
• 第 2 步：使用有效帐户登录

每种风格都有一些优点和缺点。正如您可能观察到的，对于详细步骤的测试用例，测试步骤简单明了且易于遵循。这很好，因为它避免了测试过程中的任何偏差并保持一致性。对于新测试人员来说，这也更容易运行这些案例，甚至不需要对被测系统了解很多。

但是，这种风格的问题是有两个：一个是编写起来很耗时，还有在功能更改时更新测试用例很耗时。如果你在软件行业，你应该知道功能更改是软件开发过程中不可避免的一部分。

为了最大限度地减少维护测试用例的工作量，我们的想法是编写高级测试步骤，其中详细的测试步骤在高级/逻辑测试步骤下被掩盖，以便我们可以减少详细更改的影响。但是，高级模式的问题在于，它可能会在测试运行之间产生偏差，并且对于不熟悉所测试功能/系统的测试人员来说有点挑战。所以，请根据您的需要进行选择。

二、什么是好的测试设计

1、能够揭示系统中的潜在问题

您可以为一个功能编写十几个或数百个测试用例，但如果这些测试用例是重复的，或者在执行它们时没有增加检测问题/缺陷的机会，那么它们就是废品。要有创造力，从用户的角度考虑系统可能出错的想法/案例。请注意，测试用例不仅用于确认功能有效，还用于揭示可能出错的用例。

2、提供良好的系统覆盖

您的测试用例应涵盖被测系统的所有必需功能。为了知道你是否已经涵盖了足够的内容，你应该能够追溯你的测试需求/测试用例，看看它们来自哪些需求。您的测试用例也应该是负面、正面、用例测试用例等的混合体。

3、可维护性

您的测试用例应涵盖被测系统的所有必需功能。为了知道你是否已经涵盖了足够的内容，你应该能够追溯你的测试需求/测试用例，看看它们来自哪些需求。您的测试用例也应该是负面、正面、用例测试用例等的混合体。

延伸阅读

设计测试用例的注意点

1. 了解要求。了解需求是测试设计的第一步。如果没有需求或知道需求是什么，就无法设计测试用例。
2. 测试思路是关键。测试设计的核心在于测试理念。如果你对你的测试有好的想法，你应该没问题。如果您的测试设计只是一个测试想法列表，而没有带有测试步骤的详细测试用例，这仍然很好。同样，专注于您的测试想法。
3. 注重质量。为测试设计设计大量测试想法/测试用例是非常诱人的，因为它可能会产生一种错误的感觉，即您正在覆盖或行使足够的功能。与其关注数量，不如关注测试的质量。