Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
X
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Reading Time: 2 minutes如何编写测试用例 似乎并不是开发中非常重要的一部分。但是为了使软件测试人员能够更好地完成工作，他们需要遵循一个标准的流程，并对测试的内容有一个清晰的定义。
从NASA、GE 到企业级公司，每个人都可以从运营团队中获得最佳受益。Parasoft可以让团队快速编写出色的测试用例从而提高团队效率。
在本文中，我们将介绍如何编写测试用例相关的主题：
测试用例：一个测试场景，用于测量一组操作或条件的功能，以验证预期结果。它们适用于任何软件应用程序，可以使用手动测试或自动化测试，并且可以利用测试用例管理工具。
在编写测试用例时要记住的一点的是它们旨在测试基本变量或任务，例如在电子商务网站中对应价格折扣的代码是否适用于正确的商品。这使软件测试人员能够更灵活地测试代码和功能。
还应阐明测试用例与测试脚本之间的区别。测试脚本是用于测试某些功能的简短程序。测试用例是一个文档，其中包含要提前按计划完成的步骤。
将测试用例看作是一次精心计划的旅行，而测试脚本更像是一次去杂货店的快速旅行。
测试用例可以验证代码的许多不同方面。所涉及的步骤还可能有意导致失败结果，而不是只包含正向的预期结果，例如当用户在登录界面上输入错误密码的场景。
以下是一些常见的测试用例示例：
测试用例可以应用于任何给定软件中的任何功能。其中一些最受欢迎的包括：
测试用例可以在各种软件场景中派上用场。从银行到个人软件，这些都需要测试用例的应用程序。例如，如果目标是拥有加密的敏感数据，则软件需要具有按预期工作的功能。
但功能测试只是编写测试用例的一个方面。软件测试应该有力地挑战代码的各个方面，从性能到兼容性再到安全性。这就是为什么个人加密软件需要彻底地进行测试的原因 – 尤其是在Web API等方面。
编写测试用例因测试用例数量或测试的内容而异。这也是在开发和测试团队之间共享测试资产可以加速软件测试的一种情况。但这一切都始于知道如何有效和高效地编写测试用例。
测试用例有几个不可或缺的部分，这些部分应始终存在于测试用例中。每个测试用例可以分为 8 个基本步骤。
步骤 1： 测试用例 ID
测试用例都应具有唯一的 ID 来表示它们。在大多数情况下，遵循此命名 ID 的约定有助于组织、清晰和理解。
步骤 2： 测试说明
此描述应详细说明正在测试的单元、特性或功能或正在验证的内容。
第3步： 假设和前提条件
这需要在执行测试用例之前满足任何条件。具体例子如需要有效的 Outlook 帐户才能登录。
步骤 4： 测试数据
这与测试用例中的变量及其值有关。在电子邮件登录的示例中，它将是帐户的用户名和密码。
步骤5： 要执行的步骤
从最终用户的角度操作这些步骤，应该是非常简单便捷。例如，用于登录电子邮件服务器的测试用例可能包括以下步骤：
步骤 6： 预期结果
这表示测试用例步骤执行后的预期结果。输入正确的登录信息后，预期结果成功登录。
步骤 7： 实际结果和后置条件
与预期结果相比，我们可以确定测试用例的状态。在电子邮件登录的情况下，用户将成功登录或不成功登录。后置条件是由于步骤执行（例如被重定向到电子邮件收件箱）而发生的情况。
步骤 8： 通过/失败
确定通过/未通过状态取决于预期结果和实际结果之间的区别
相同结果 = 通过
不同结果 = 失败
编写良好的单元测试 定义几个核心方面，包括：
重要的是要了解良好的测试标准格式由以下部分组成：
如上所述，有一个标准的测试用例格式。测试用例模板可能因公司而异，也可能因团队而异。测试用例模板是包含测试方案和后续测试用例列表的文档。
虽然测试用例会根据测试类型和整体测试领域而有所不同，但构建质量测试用例归结为上面的几个可靠事项。请记住：测试方法的名称必须包括所测试的方法或单元以及预期结果。
还应该注意的是，每个单元都应该单独测试。在这种情况下，“隔离”意味着尽可能地保持测试的重点，以便仅执行我们正在测试的应用程序部分。
此示例来自与银行相关的测试用例：
使用此方法名称，我们知道这是一个单元测试：
有意义的方法名称允许查看结果的任何人了解单元测试所测试的内容。此外，它还指示要测试的数据，预期结果以及测试的内容。
如果测试失败，了解预期结果对于简化故障排除和确保不引入回归至关重要。
使用的数据需要能够执行测试。对于单元测试，我们希望尽可能简单地测试应用程序的最基本单元。数据可以像创建字符串或变量一样简单，您可以控制其数据。或者，如果依赖项不可用，或者您需要该依赖项处于特定状态，则可以将模拟(mock)框架用于测试。
如果有足够的时间来测试那一个部分。您无需配置应用程序的每个部分即可运行测试。
所有这些都会影响单元测试的行为方式，因为这是用于单元测试执行的数据。因此，单元测试的这一部分是最耗时的，因为它需要对正在测试的代码有一定的了解，以便于了解要用于测试的数据。
通过只使用被测代码所需的部分来让测试变得简单。模拟(mock)在此阶段非常有用，因为它们允许您控制这些对象中的方法在与测试交互时的行为方式。
例如，给定以下数据：
我们通过使用“Customer类”的模拟(mock)来测试隔离，从而避免了“真实Customer类”。我们不想为此测试引入或配置另一个对象，因为它为该对象增加了另一层可维护性，并且不会影响所测试方法的结果。
要创建的下一个变量是“初始余额”，这是由于了解代码而已知的。下一行显示通过模拟(mock)创建的 Account 对象包含这个初始余额，为的是通过我们刚刚使用的数据来准备所需要测试的方法。
因此，在此示例中，Account 对象是使用模拟(mock) customer 对象配置的，原因是我们不关心 customer对象的数据，并且我们传递了一个初始余额，我们可以控制该余额进行测试。
下一行定义输入，因为所测试的方法需要使用数字。我们定义了要在测试方法中使用的“balance” 。然后执行该方法，并将该方法的结果存储在我们的变量中，供我们以后使用。
一旦测试可以成功完成，那么是时候将断言应用于单元测试了。如果没有断言，单元测试就毫无意义，因为您没有强制执行任何内容来确保它按预期工作。
行覆盖率可以了解具体行的执行情况，但它没有提供足够的细节来确定以下内容：
断言的优势:
单元测试只有包含断言才是有意义的。
通过应用单元测试的标准格式，团队可以更轻松地维护、读取和更新测试，以便轻松查看在哪些地方可以将测试应用于更多其他应用程序。
如何编写有效的测试和测试用例可以随着时间的推移而简化。一些最佳做法包括使用强标题、强描述以及保持语言简洁明了。
但是，您还需要包括前提条件，提供预期结果。所有这些信息都与软件测试人员相关 – 特别是在确定测试用例应该是“通过”还是“失败”时。
用于创建运行良好的测试用例的备忘单如下：
良好的测试用例需要保证其可读性以及可复用性。如果要更直观地了解如何编写高质量的测试用例，请查看Parasoft关于该主题的网络研讨会。
测试用例的另一个方面涉及测试套件和测试计划。它们对测试用例开发都至关重要。
测试套件在测试用例中发挥作用，因为它与源代码、依赖项集合或要对代码执行的测试套件相关。测试套件允许您以符合任何分析或规划需求的方式对测试用例进行分类。
这意味着核心软件功能可能有自己的测试套件，而另一个测试套件则用于特定的测试类型，如安全性。
相比之下，测试计划更像是覆盖所有测试套件的保护伞。如果测试用例是书籍，测试套件是书架，则测试计划是包含书架的房间。
通常，测试计划是根据手动测试，自动测试和如何进行测试的格式来设计的。他们将在实施更改或添加新功能之前，利用测试套件和测试用例从头开始测试软件。
Parasoft通常在开发其工具和套件时考虑到“George Jetson”理论。也就是说，我们希望我们的客户能够简单点击按钮就能处理好一切。虽然这并不完全现实，但在编写测试用例时，专注于自动化的工具是最好的选择。
我们可以帮助客户在开发的初始阶段实现自动化测试用例的编写。
这款工具允许无论是初学者还是专家都能更快地提高他们的单元测试技能，以及单元测试体验。在建立基础之后，它执行单元测试，然后引导用户确保测试是有意义的。当您能够理解要在测试中查找的内容时，测试用例的编写就变得不那么令人生畏了。
作为Parasoft的解决方案架构师，William帮助团队在组织中采用现代软件开发和测试实践时制定战略并确定优先级。