测试用例
测试用例
测试用例定义为一组条件，测试人员在这些条件下确定软件应用程序是否按照客户的要求工作。测试用例设计包括前置条件、用例名称、输入条件和预期结果。测试用例是第一级操作，源自测试场景。
它是一个输入-details 文档，包含所有可能的输入(正面和负面)和导航步骤，用于测试执行过程。编写测试用例是一次性的尝试，可以在将来进行回归测试时使用。
测试用例提供了有关测试策略、测试过程、前提条件和预期输出的详细信息。这些在测试过程中执行，以检查软件应用程序是否正在执行为其开发的任务。
测试用例通过将缺陷与测试用例 ID 联系起来帮助测试人员报告缺陷。详细的测试用例文档为测试团队提供了全面的证据保护，因为如果开发人员遗漏了什么，那么在执行这些全面的测试用例的过程中可能会被发现。
要编写测试用例，我们必须有导出输入的要求，并且必须编写测试场景，以便我们不会错过任何测试功能。那么我们应该有测试用例模板来保持一致性，或者每个测试工程师都按照相同的方法来准备测试文档。
一般来说，我们会在开发人员忙于编写测试用例时编写测试用例
我们什么时候写测试用例？
当我们得到以下内容时，我们会写测试用例:
当客户提出业务需求时，开发人员开始开发并说他们需要 3.5 个月的时间来构建此产品。
与此同时，测试团队将开始编写测试用例。
完成后，它会将其发送给测试主管进行审核。
开发人员完成产品开发后，将其移交给测试团队。
测试工程师在测试产品文档时从不看需求，因为测试是持续的，不取决于人的心情，而不是测试工程师的素质。
注意: 在编写测试用例时，切勿编写实际结果，因为产品仍在开发过程中。这就是为什么应该在测试用例执行后才写入实际结果。
我们为什么要编写测试用例？
我们将出于以下原因编写测试:
要求测试用例执行的一致性
确保更好的测试覆盖率
这取决于过程而不是一个人
避免对每位新的测试工程师进行产品培训
要求测试用例执行的一致性: 我们将看到测试用例并开始测试应用程序。
为了确保更好的测试覆盖率: 为此，我们应该覆盖所有可能的场景并记录下来，这样我们就不需要一次又一次地记住所有场景。
这取决于过程而不是一个人: 测试工程师在第一次发布、第二次发布期间测试了一个应用程序，并在第三次发布时离开了公司。当测试工程师理解一个模块并通过推导许多值来彻底测试应用程序时。如果第三次发布时该人不在，对新人来说就变得困难了。因此，所有派生值都被记录下来，以便将来使用。
为了避免对每个新的产品测试工程师进行培训: 当测试工程师离开时，他/她带着很多知识和场景离开。应该记录这些场景，以便新的测试工程师可以使用给定的场景进行测试，也可以编写新的场景。
注意: 当开发人员为First release开发第一个产品时，测试工程师编写测试用例。在第二个版本中，当添加新功能时，测试工程师也为此编写测试用例，而在下一个版本中，当元素被修改时，测试工程师将更改测试用例或编写新的测试用例以及。
测试用例模板
编写测试用例的主要目的是实现应用程序的效率。
我们知道，实际结果是在测试用例执行之后写入的，大部分时间，它将与预期结果相同。但是如果测试步骤会失败，那就不同了。因此，可以跳过实际结果字段，在评论部分，我们可以写下错误。
还有输入字段可以删除，并且可以将此信息添加到描述字段。
我们上面讨论的上述模板不是标准模板，因为它可能因每个公司和每个应用程序而异，它基于测试工程师和测试负责人。但是，为了测试一个应用程序，所有的测试工程师都应该遵循一个通常的模板，该模板是制定的。
测试用例应该用简单的语言编写，以便新的测试工程师也能理解和执行相同的.
在上面的示例模板中，标题包含以下内容:
步骤编号
这也是必不可少的，因为如果步骤编号 20 失败，我们可以记录错误报告，从而确定工作的优先级，并确定它是否是严重错误。
测试用例类型
它可以可以是功能、集成或系统测试用例，也可以是正面或负面或正面和负面的测试用例。
发布
一个发布可以包含该发布的多个版本.
前置条件
这些是每个测试工程师在开始测试执行过程之前需要满足的必要条件。或者是需要为测试创建的数据配置或数据设置。
例如: 在一个应用程序中，我们正在编写测试用例来添加用户，编辑用户，删除用户。如果在编辑和删除用户 A 之前添加用户 A，将看到每个条件。
测试数据
这些是我们的值或输入需要根据每个条件创建。
例如，用户名，密码和用户帐号。
测试负责人可能是给定用户名或密码等测试数据来测试应用程序，或者测试工程师可以自己生成用户名和密码。
严重性
严重性可以主要、次要和关键，测试用例中的严重性说明了特定测试用例的重要性。所有的文本执行过程总是取决于测试用例的严重性。
我们可以根据模块选择严重性。一个模块中包含许多特性，即使一个元素是关键的，我们也声称测试用例是关键的。这取决于我们编写测试用例的功能。
例如，我们将使用 Gmail 应用程序，让我们查看基于模块的严重性:
| 模块 |
严重性 |
| 登录 |
关键 |
| 帮助 |
次要 |
| 撰写邮件 |
关键 |
| 设置 |
次要 |
| 收件箱 |
关键 |
| 已发送项目 |
主要 |
| 退出 |
关键 |
而对于银行应用程序，严重性可能如下:
简要说明
测试工程师为特定功能编写了测试用例。如果他/她暂时来阅读测试用例，他/她将不知道是什么特性编写的。因此，简要描述将帮助他们编写哪些功能测试用例。
测试用例模板示例
在这里，我们正在编写一个测试用例ICICI 应用程序的登录模块:
测试用例的类型
我们有不同类型的测试用例，如下:
功能测试用例
集成测试用例
系统测试用例
功能测试用例
Firstly，我们检查我们将编写测试用例的字段，然后进行相应的描述。
在功能测试中或者如果应用程序是数据驱动的，我们需要输入列 else；这有点耗时。
编写功能测试用例的规则:
在预期结果栏中，尝试使用应该或必须。
突出显示对象名称。
我们只需要描述我们最需要的那些步骤；否则，我们不需要定义所有步骤。
为了减少多余的执行时间，我们将正确编写步骤。
编写一个通用的测试用例；不要试图对其进行硬编码。
假设它是金额转移模块，因此我们正在为其编写功能测试用例，然后还指定它不是登录功能。
转账模块的功能测试用例在下面的Excel文件中:
集成测试用例
在这里，我们不应该编写我们在功能测试用例中已经涵盖的内容，并且我们在集成测试用例中写的东西不应该再写在系统测试用例中。
编写集成测试用例的规则
首先了解产品
确定可能的场景
根据优先级编写测试用例
测试工程师在编写测试用例时，可能需要考虑以下几个方面:
如果测试用例很详细:
他们将努力实现最大的测试覆盖率。
正确描述了所有测试用例值或场景。
他们会尝试从执行的角度考虑。
用于编写测试用例的模板必须是唯一的。
注意: 当我们涉及的步骤数较少或覆盖率较高时，它应该是最好的测试用例，当这些测试用例提供给任何人时，他们都会很容易理解。
系统测试用例
我们将编写端到端业务流的系统测试用例。
编写测试用例的过程
编写测试用例的方法可以完成为步骤如下:
系统学习
在这里，我们将通过查看需求或客户提供的 SRS 来了解应用程序。
识别所有场景:
当产品推出时，最终用户可能会使用哪些软件来识别所有可能的方式。
我在一份文档中记录了所有可能的场景，称为测试设计/高级设计。
测试设计是包含所有可能场景的记录。
编写测试用例
将所有确定的场景转换为测试声明并将与其功能相关的场景分组，对模块进行优先级排序，并编写测试用例应用测试用例设计技术并使用标准测试用例模板，这意味着为项目决定的那个。
审查测试用例
将测试用例交给团队负责人进行审查，然后修正审查者给出的审查反馈。
测试用例批准
根据反馈修改测试用例后，再次发送审批。
存储在测试用例库中
审批通过后特定的测试用例，存储在熟悉的地方，称为测试用例存储库。
