如何编写测试用例？
什么是测试用例？
测试用例是测试人员用来验证软件应用程序是否满足客户要求的一组标准。前提条件、案例名称、输入条件和预期结果都包含在测试案例设计中。测试用例是源自测试场景的基本活动。
它是一个综合文档，包含所有可能的输入（正面和负面）以及测试执行过程的导航指令。编写测试用例是一次性的工作，可以在将来重复用于回归测试。
测试用例包含有关测试策略、过程、前提条件和预期结果的全面信息。这些在测试过程中用于查看软件应用程序是否能够执行其创建目的。
通过将缺陷与测试用例ID相关联，测试用例可以帮助测试人员报告缺陷。测试团队从详细的测试用例文档中受益，因为如果开发人员遗漏了什么，可以在执行这些完整的测试用例时被发现。为了构建测试用例，我们需要提取输入的需求，以及确保我们不会忽略任何测试功能的测试场景。然后，为了保持一致性，我们应该有一个测试用例模板，或者每个测试工程师都应该以相同的方式准备测试文档。
每当开发人员忙于编写代码时，我们通常会编写测试用例。
测试用例与测试场景
测试情况有点模糊，涵盖了很多领域。当涉及到测试时，这一切都是非常具体的。
作为测试场景的示例，请考虑以下-检查登录功能有多种测试用例需要考虑-
测试用例1-检查插入有效用户ID和密码的结果
测试用例2-检查在测试用例2中输入无效用户ID和密码的结果。
测试案例3-检查用户ID为空且登录按钮被按下时的响应，以及许多其他响应。
这些都是测试用例。
什么时候应该编写测试用例？
当我们有以下信息时，我们将编写测试用例-
当客户提供业务需求时，开发人员开始工作，估计产品需要3.5个月才能完成。
同时，测试组将开始编写测试用例。
完成后，它会将其发送给测试主管进行审核。
一旦开发人员完成构建，产品就会移交给测试团队。
因为测试是恒定的，不取决于人的心情而不是测试工程师的素质，所以测试工程师在测试产品文档时从不看需求。
重要-因为产品仍在开发中，所以在编写测试用例时不应该写出实际结果。因此，只有在测试用例完成后才应编写实际结果。
编写测试用例的过程
编写测试用例的过程可以分解为以下步骤-
系统研究
考虑所有可能的情况
制作测试用例。
检查测试用例。
修复发现的故障（如有）
批准测试用例
在测试用例存储库中跟踪您的测试用例。
系统研究
在这种情况下，我们将查看客户提供的要求或SRS，以更好地了解应用程序。
考虑所有可能的情况
当产品发布时，最终用户可以通过哪些不同的方法利用软件来确定所有的可能性？
在标题为测试设计/高级设计的文档中，我涵盖了所有可以想象的场景。
测试设计是一个包含所有可能场景的数据库。
制作测试用例
将所有发现的场景转换为测试声明，根据它们的特性对它们进行分组，对模块进行优先级排序，并使用测试用例设计方法和标准测试用例模板编写测试用例，这是为项目选择的。
检查测试用例
将测试用例交给组长进行评审，然后修正评审员提供的评审批评。
批准测试用例
根据输入修复测试用例后，将其发回以供批准。
在测试用例存储库中跟踪您的测试用例。
测试用例获得批准后，将其存储在测试用例存储库中，这是一个熟悉的位置。
编写测试用例时要考虑的术语
编写测试用例时，请记住提供以下详细信息。
本节描述了正在测试的需求。
系统将如何进行测试的描述
测试设置，其中包括诸如硬件、安全访问、物理或逻辑日期、被测应用程序版本、软件、数据文件、操作系统、一天中的时间、其他测试等先决条件以及任何其他设置信息等信息与被测试的要求相关。
（行动和预期结果）投入和产出
任何附件或证明
使用活跃的案例术语
测试用例中的步骤不应超过15个。
输入、目的和预期结果都记录在自动化测试脚本中。
编写测试用例的最佳方法
测试用例必须简单明了
使您的测试用例尽可能简单。它们必须清晰直接，因为测试用例作者可能无法执行它们。
使用声明性语言，例如“转到主页”、“输入数据”、“单击此处”等。这使得更容易理解测试阶段并加快测试过程。
创建一个考虑最终用户的测试用例
任何软件项目的最终目标都是生成满足客户要求且易于使用和运行的测试用例。测试人员必须从最终用户的角度编写测试用例。
不要两次使用相同的测试场景
不应重复测试用例。如果执行另一个测试用例需要一个测试用例，请在前置条件列中通过其测试用例ID引用它
不要做假设
创建测试用例时，不要对软件应用程序的功能和特性做出假设。遵循规范文档中的规范。
确保您拥有完整的保险
确保您编写了测试用例，以确保您已经涵盖了规范文档中的所有软件需求。要验证没有未测试的功能或条件，请使用可追溯性矩阵。
测试用例必须能够被识别
测试用例id应该以这样的方式命名，以便稍后可以轻松识别以监控故障或识别软件需求。
使用测试方法
在您的软件应用程序中，您将无法验证每种可能的情况。软件测试方法可帮助您选择少数最有可能检测到缺陷的测试用例。
自清洁
您编写的测试用例必须将测试环境恢复到以前的状态，并且不应使其无法使用。在配置测试方面尤其如此。
可靠且独立
无论谁评估测试用例，结果都应该是一致的。
同行评价
编写完测试用例后，让您的同事对其进行审查。您的同行可以发现您可能忽略的测试用例设计中的缺陷。