测试用例是测试人员用来验证软件应用程序是否满足客户要求的一组标准。
前提条件、案例名称、输入条件和预期结果都包含在测试案例设计中。测试用例是源自测试场景的基本活动。
它是一个综合文档，包括所有潜在的输入（正面和负面）以及测试执行过程的导航指令。编写测试用例是一次性的工作，将来可能会重复用于回归测试。
测试用例包含有关测试方法、程序、前提条件和预期结果的全面信息。这些在测试阶段使用，以查看软件程序是否能够执行创建它的目的。
通过将缺陷与测试用例 ID 相关联，测试用例可以帮助测试人员报告缺陷。测试团队受益于详细的测试用例文档，因为如果开发人员遗漏了某些内容，则可能会在执行这些完整的测试用例期间被检测到。
为了构建测试用例，我们需要提取输入的需求，以及确保我们不会忽略任何测试功能的测试场景。然后，为了保证一致性，我们应该有一个测试用例模板，或者每个测试工程师都应该以相同的方式生成测试文档。
每当开发人员忙于创建代码时，我们通常都会编写测试用例。
当我们有以下信息时，我们将编写测试用例 -
当客户提供业务需求时，开发人员开始工作，估计产品需要 3.5 个月才能完成。
同时，测试组将开始开发测试用例。
完成后，它将通过电子邮件发送给测试主管进行评估。
一旦开发人员完成构建，产品就会移交给测试团队。
因为测试是一致的，不取决于人的心情而不是测试工程师的素质，所以测试工程师在测试产品文档时从不看需求。
可以测试的任何功能都被指定为测试场景。它是一组测试场景，可帮助测试团队确定项目的正面和负面特征。
测试场景提供了必须测试的高级概述。
在 liner 语句中，测试场景是一个完整的列表，其中包含覆盖软件程序端到端功能的测试用例。场景被定义为线性陈述。测试场景是对可测试需求的高级别分类。这些标准根据模块的功能进行分类并源自用例。
因为场景中的测试用例太多，所以有一个彻底的测试过程。在完成测试场景之前，测试人员必须评估每个场景的测试用例。
测试人员必须在测试场景中站在用户的角度，因为他们是从用户的角度测试软件应用程序。该过程最重要的方面是场景准备，这需要向消费者、利益相关者或开发人员寻求建议或帮助。
要构建测试场景作为测试人员，请按照下列步骤操作
检查软件的需求文档，例如BRS（业务需求规范）、SRS（系统需求规范）和FRS（功能需求规范）。
对于每个需求，确定所有技术因素和目标。
找到所有可行的方式让用户与软件交互。
确定系统可能被滥用的所有可能场景，以及可能成为黑客的用户。
在阅读需求文档并完成计划分析后，列出可能的测试用例以检查程序的每个功能。
确定所有可用的测试场景后，创建一个可追溯性矩阵，以查看每个需求是否具有匹配的测试场景。
所有的可能性都由项目主管审查。然后由项目的其他利益相关者审查它们。
测试场景是指导测试人员完成测试过程的单线。
通过使用测试场景降低了产品的复杂性和重复性。
测试场景是当您非常详细地谈论和思考测试时，将它们写成线性语句。
它是串联在一起的一系列程序。
当测试人员没有足够的时间来开发测试用例并且团队就一个全面的线性场景达成一致时，测试场景变得更加重要。
测试场景是节省时间的有用练习。
由于添加和修改测试用例简单且独立，因此易于维护。
电子商务应用程序的一些测试用例可能是 -
场景 1 - 检查搜索功能
检查场景 2 中的支付功能
检查场景 3 中的登录功能
测试用例是为检查某些特性或功能而执行的操作的集合，而测试场景是可以评估的任何能力。
测试场景源自 BRS 和 SRS 等测试工件，而测试用例源自测试场景。
测试用例有助于对应用程序进行彻底测试，而测试场景有助于以更灵活的方式测试端到端功能。
测试用例更关心测试什么和如何测试，而测试场景更关心测试什么。
低级活动是测试用例，而高级操作是测试场景。
测试用例需要更多的资源和时间来执行，而测试场景需要更少的资源和时间。
测试用例包括测试程序、数据和预期结果，而测试场景包含要评估的端到端功能。
将有测试场景的测试用例：“检查登录功能”。
输入有效的电子邮件地址和密码后，观察系统的反应。
当提供了不正确的电子邮件地址和合法密码时，请观察系统的行为。
当提交合法的电子邮件地址和错误的密码时，请观察系统的行为。
提交错误的电子邮件地址和密码时，请检查系统的响应。
当电子邮件地址和密码留空并按下登录按钮时，检查系统的行为。
确保忘记密码工作正常。
当输入的号码和密码有效或不正确时，请观察系统的行为。
选择“保持签名”后，观察系统的操作。
以下是开发测试用例的几个令人信服的理由
测试用例有助于验证是否符合相关标准、指南和客户需求。
帮助您验证客户的期望和要求。
控制、逻辑和数据流覆盖都得到了改进。
您可以玩转真实的最终用户场景。
暴露缺陷或过失
当为测试执行开发测试用例时，测试工程师的工作将更加结构化和简单。
以下是构建测试场景的一些令人信服的理由
编写测试场景的主要目标是确保软件应用程序的整个功能得到验证。
它还有助于确保业务流程和流程符合功能要求。
为保证被测应用程序得到充分测试，业务分析师、开发人员和客户等多个利益相关者可以批准测试方案。它确保程序在最普遍的场景中正常运行。
它们可用于确定测试工作量，并因此为客户创建建议或组织劳动力。
它们有助于识别最重要的端到端交易或软件程序的实际使用。
一旦最终确定，就可以从这些测试场景中生成测试用例。
测试用例和测试场景之间有重要的区别。
| 测试场景 | 测试用例 |
|---|---|
| A test scenario is a high-level document that defines the functionality to be tested from beginning to end. | 为了评估应用程序的所有功能，测试用例包含指定的测试程序、数据和预期结果。 |
| It emphasizes "what to test" rather than "如何测试。" | 重点完全在于“测试什么”和“如何测试”。 |
| A one-liner is a test case. As a result, there is always the risk of ambiguity during testing | 步骤、先决条件、预期结果等都在测试用例中描述。因此，在这个程序中没有误解的余地 |
| BRS, SRS, and other test artifacts are used to create test scenarios. | 大多数测试用例来自测试场景。单个测试场景可能提供多个测试用例。 |
| It aids in the rapid testing of end-to-end functionality. | 它有助于对应用程序进行彻底的测试。 |
| High-level actions are used in test scenarios. | 低级操作就是测试用例。 |
| Creating and testing scenarios requires significantly less time and money. | 测试用例文档和执行需要更多资源。 |
测试用例应该清晰易懂。
创建一个考虑到最终用户的测试用例。
应避免重复测试用例。
您必须确保编写测试用例以确保满足规范文档中指定的所有软件需求。
在创建测试用例时，永远不要对软件应用程序的功能和特性做出假设。
测试用例必须易于区分。
大多数测试用例是单行语句，指定应该测试什么。
场景描述应该简单易懂。
应对规定的标准进行彻底检查。
在开始测试过程之前，收集必要的工具和资源。