测试用例

测试用例被定义为一组条件，测试人员在这些条件下确定软件应用程序是否按照客户的需求工作。测试用例设计包括前提条件、用例名称、输入条件和预期结果。测试用例是第一级的动作，从测试场景中派生出来。

它是一个详细的文档，包含所有可能的输入(积极的和消极的)和导航步骤，这些步骤用于测试执行过程。编写测试用例是一次性的尝试，可以在将来的回归测试时使用。

测试用例给出了关于测试策略、测试过程、前提条件和预期输出的详细信息。这些在测试过程中执行，以检查软件应用程序是否正在执行它所开发的任务。

测试用例通过将缺陷与测试用例ID联系起来，帮助测试人员报告缺陷。详细的测试用例文档可以作为测试团队的完整证明保护，因为如果开发人员遗漏了一些东西，那么可以在执行这些完整证明测试用例的过程中捕获它。

为了编写测试用例，我们必须有获取输入的需求，并且必须编写测试场景，这样我们就不会错过任何用于测试的特性。然后我们应该有测试用例模板来保持一致性，或者每个测试工程师都遵循相同的方法来准备测试文档。

通常，当开发人员忙于编写代码时，我们就会编写测试用例。

我们什么时候编写测试用例?

当我们得到以下内容时，我们将编写测试用例:

• 当客户给出业务需求时，开发人员开始开发，并说他们需要3.5个月来构建这个产品。
• 与此同时，测试小组会开始编写测试用例．
• 一旦完成，它将发送给测试领导进行评审过程。
• 当开发人员完成产品开发后，将其移交给测试团队。
• 测试工程师在测试产品文档时从不看需求，因为测试是恒定的，不取决于人的情绪，而取决于测试工程师的质量。

注意:当编写测试用例时，实际的结果永远不应该编写，因为产品仍然处于开发过程中。了吗?为什么实际的结果应该在测试用例执行之后才写。

为什么我们要编写测试用例?

我们将基于以下原因编写测试:

• 要求测试用例执行的一致性
• 以确保更好的测试覆盖率
• 这取决于过程，而不是一个人
• 避免对每个新测试工程师进行产品培训

要在测试用例执行中要求一致性:我们将看到测试用例并开始测试应用程序。

为了确保更好的测试覆盖率:为此，我们应该涵盖所有可能的场景并将其记录下来，这样我们就不需要一遍又一遍地记住所有场景。

它取决于过程而不是人:一个测试工程师在第一个版本、第二个版本期间测试了一个应用程序，并在第三个版本时离开了公司。由于测试工程师理解了一个模块，并通过派生许多值彻底测试了应用程序。如果这个人在第三次发布时不在那里，对新人来说就很困难了。因此，所有派生的值都被记录下来，以便将来可以使用。

避免对每个新测试工程师进行产品培训:当测试工程师离开时，他/她会带着很多知识和场景离开。这些场景应该被记录下来，这样新的测试工程师就可以用给定的场景进行测试，也可以编写新的场景。

注意:当开发人员为第一个版本开发第一个产品时，测试工程师编写测试用例。在第二个版本中，当新特性被添加时，测试工程师也会为此编写测试用例，在下一个版本中，当元素被修改时，测试工程师也会更改测试用例或编写新的测试用例。

测试用例模板

编写测试用例的主要目的是实现应用程序的效率。

正如我们所知，实际结果是在测试用例执行之后编写的，并且大多数情况下，它与预期的结果．但是如果测试步骤失败，情况就不一样了。因此，可以跳过实际的结果字段，并在的评论科，我们可以写bug。

还有，输入字段可以删除，并且可以将此信息添加到描述字段．

我们上面讨论的模板不是标准模板，因为它对每个公司和每个应用程序都是不同的，这是基于测试工程师和测试负责人的。但是，为了测试一个应用程序，所有的测试工程师都应该遵循一个常用的模板。

测试用例应该用简单的语言编写，这样新的测试工程师也能理解并执行。

在上面的示例模板中，头文件包含以下内容:

步数

这也是很重要的，因为如果第20步失败了，我们可以记录错误报告，从而确定工作的优先级，并确定它是否是一个严重的错误。

测试用例类型

它可以是功能、集成或系统测试用例，也可以是正面或负面的测试用例，也可以是正面和负面的测试用例。

释放

一个版本可以包含该版本的多个版本。

前提条件

这些是每个测试工程师在开始测试执行过程之前需要满足的必要条件。或者，需要为测试创建数据配置或数据设置。

例如:在应用程序中，我们正在编写测试用例来添加用户、编辑用户和删除用户。如果在编辑和删除用户A之前添加了用户A，则会看到每个条件。

测试数据

这些是我们需要根据每个条件创建的值或输入。

例如、用户名、密码、帐号。

测试负责人可以获得测试数据，例如用户名或密码，以测试应用程序，或者测试工程师可以自己生成用户名和密码。

严重程度

严重程度可以是大的，小的和严重的，测试用例中的严重性讨论了特定测试用例的重要性。所有的文本执行过程总是依赖于测试用例的严重性。

我们可以根据模块选择严重程度。在一个模块中包含许多特性，即使其中一个元素是关键的，我们也认为这个测试用例是关键的。这取决于我们为其编写测试用例的函数。

例如,我们将采取Gmail应用程序，让我们看到基于模块的严重性:

对于银行应用程序，严重性可以如下所示:

简要描述

测试工程师已经为特定的特性编写了一个测试用例。如果他/她现在来阅读测试用例，他/她将不知道它是为什么特性编写的。因此，简短的描述将帮助他们编写特性测试用例。

一个测试用例模板的例子

的测试用例ICICI应用程序的登录模块:

测试用例的类型

我们有不同类型的测试用例，如下所示:

• 功能测试用例
• 集成测试用例
• 系统测试用例

功能测试用例

首先，我们检查我们将为哪个字段编写测试用例，然后相应地进行描述。

在功能测试中，或者如果应用程序是数据驱动的，我们需要输入列else;这有点耗时。

编写功能测试用例的规则:

• 在预期结果栏中，尝试使用应该是或必须．
• 突出显示对象名称。
• 我们只需要描述那些我们最需要的步骤;否则，我们不需要定义所有步骤。
• 为了减少多余的执行时间，我们将正确地编写步骤。
• 编写一个通用的测试用例;不要尝试硬编码。

假设它是金额转账模块，因此我们正在为它编写功能测试用例，然后还指定它不是一个登录特性。

转账模块功能测试用例如下Excel文件:

集成测试用例

在这种情况下，我们不应该编写已经在功能测试用例中涉及到的东西，并且我们在集成测试用例中编写的东西不应该再次在系统测试用例中编写。

编写集成测试用例的规则

• 首先，了解产品
• 确定可能的场景
• 基于优先级编写测试用例

当测试工程师编写测试用例时，他们可能需要考虑以下方面:

如果测试用例是详细的:

• 他们将努力实现最大的测试覆盖率。
• 所有测试用例值或场景都被正确描述。
• 他们会考虑执行的角度。
• 用于编写测试用例的模板必须是唯一的。

注意:当我们涉及较少数量的步骤或覆盖较多时，它应该是最好的测试用例，并且当这些测试用例提供给任何人时，他们都很容易理解。

系统测试用例

我们将为端到端业务流程编写系统测试用例。我们已经准备好了编写系统测试用例的整个模块。

编写测试用例的过程

编写测试用例的方法可以分为以下几个步骤:

系统研究

在这里，我们将通过查看客户给出的需求或SRS来理解应用程序。

识别所有场景:

• 当产品推出时，终端用户可能使用软件识别所有可能的方式是什么。
• 我在一个文档中记录了所有可能的场景，这个文档被称为测试设计/高级设计。
• 测试设计是一个包含所有可能场景的记录。

编写测试用例

将所有已识别的场景转换为测试声明，并将与它们的特性相关的场景分组，对模块进行优先级排序，并通过应用测试用例设计技术和使用标准测试用例模板来编写测试用例，这意味着为项目决定的用例模板。

检查测试用例

通过将测试用例交给团队负责人来评审，在此之后，修正评审人员给出的评审反馈。

测试用例批准

在根据反馈修正测试用例之后，再次将其发送给批准。

存储在测试用例存储库中

在批准了特定的测试用例之后，将其存储到熟悉的地方，这个地方被称为测试用例存储库。

要获得关于测试用例评审过程的完整信息，请参考以下链接:

//m.047138.com/test-case-review-process