软件测试 - 测试用例
软件测试是借助一系列工件进行的,即测试计划、策略、场景和测试用例。它不仅用于检测错误,还用于验证软件是否按预期运行。为此,遵循特定模板来验证每个功能。它被称为测试用例。
什么是测试用例?
测试用例是测试中遵循的标准格式,用于检查软件是否按要求运行。它包含一组需要验证的条件,以验证软件的实际结果是否与预期结果相匹配。
测试用例的各个部分列在下面 −
- 功能名称 − 它指向已验证的功能。
- 测试用例标识符 −它指向分配给每个测试用例的唯一 ID。
- 测试人员姓名 − 将执行测试的测试人员的姓名。
- 测试场景名称 − 将转换为测试用例的场景的名称。
- 测试用例描述 − 将在测试用例中验证的需求或标准。
- 测试步骤 − 要对软件执行的操作以验证测试条件。
- 先决条件 − 开始测试步骤之前需要满足的先决条件。
- 测试优先级 − 测试优先级分配给测试用例以决定需要执行的顺序。
- 测试数据 −完成测试所需的输入和数据。
- 预期结果 − 根据要求的预期结果。
- 测试设置 − 运行测试前需要设置的设置和参数。
- 实际结果 − 软件产生的实际结果。
- 环境 − 执行测试的环境配置,包括操作系统、配置、安全性等。
- 测试状态 − 测试状态应反映为通过、失败、未执行和阻止。
- 注释 −针对每个测试用例添加的注释。
测试用例和测试场景之间的差异
测试用例和测试场景之间存在多个差异 −
Sr.No | 测试用例 | 测试场景 |
---|---|---|
1 | 它包含有关要测试的内容、需要执行的测试步骤、实际结果和预期结果等所有详细信息。 | 它是一份高级文档,涉及所有功能的所有功能和用户故事。 | 2 | 创建它是为了使测试人员和开发人员能够协同工作。 | 它指导测试团队执行任务。 | 3 | 它是根据测试场景文档创建的,并在回归或重新测试阶段再次使用。 | 它是根据需求直接创建的,但只要有任何需求发生变化或增加,就需要更新。 |
我们什么时候编写测试用例?
在软件开发开始之前,当需求准备好时,就会编写测试用例。测试人员在软件开发完成时完成测试用例的设计。
它也是在完成软件开发(生产部署之前)或根据需要实施新功能之后立即创建的。
测试用例创建是整个软件开发过程中的一个持续过程,一旦模块或模块的一部分准备就绪,就可以立即进行并行测试。
为什么要编写测试用例?
编写测试用例的原因如下 −
- 检查软件是否按要求运行。
- 检查软件是否在指定条件下运行。
- 它有助于限制软件更新和其他需求。
- 它确保涵盖并记录所有可能场景和用例的所有需求,从而提高测试覆盖率。
- 它有助于实现测试执行的均匀性。精心设计的测试用例可让任何测试人员开始验证软件。
- 好的测试用例需要最少的维护工作。
测试用例的基本格式是什么?
组件 | 目的 |
---|---|
测试用例 ID | 它指向分配给每个测试用例的唯一 ID。 |
测试用例描述 | 简要描述测试用例的设计原因。 |
先决条件 | 开始测试前需要满足的先决条件步骤。 |
测试步骤 | 详细描述测试步骤。 |
测试数据 | 完成测试所需的输入和数据。 |
预期结果 | 根据要求的预期结果。 |
后置条件 | 测试用例成功运行后需要满足的条件。 |
实际结果 | 软件上产生的实际结果。 |
测试状态 | 与实际和预期进行比较后的测试状态结果。 |
项目名称 | 项目名称。 |
模块名称 | 模块名称。 |
参考资料 | 参考资料所在的位置。 |
创建者 | 设计测试用例的测试人员姓名。 |
创建日期 | 创建测试用例的日期。 |
审核日期 | 审核测试用例的日期。 |
执行者 | 执行测试用例的测试人员姓名。 |
执行日期 | 测试用例的日期执行。 |
注释 | 针对测试用例添加的注释。 |
下图显示了测试用例格式。

设计测试用例的最佳实践
设计测试用例的最佳实践如下 −
- 它不应该复杂、清晰且易于理解。
- 每个测试用例都应该是不同的。
- 只有在清楚了解需求、输入、数据并且没有任何假设的情况下才能设计它。
- 每个测试用例都应该映射到至少一个可追溯性的要求。
- 每个测试用例都应使用所有可能的输入、条件和数据进行验证。
- 测试用例描述、名称等应该是不言自明的,但可以用几句话来解释。
- 每个测试用例都应涵盖客户要求。
- 测试用例的设计不应产生相同的结果。
- 设计时应考虑最终用户的要求和观点。
- 每个测试用例都应具有唯一的 ID。
- 应具有明确定义的先决条件和后置条件。
- 应以可在其他地方重复使用的方式编写。
- 应纳入测试用例的精确预期结果。
测试管理工具
不同的测试管理工具列于下方 −
正式和非正式测试用例
- 正式测试用例 − 它遵循上面讨论的测试用例模板或格式。
- 非正式测试用例 − 它不遵循任何测试用例模板或格式。
不同类型的测试用例
不同类型的测试用例如下所示 −
- 功能测试用例 − 它们用于验证软件的功能是否按预期运行。
- 单元测试用例 − 它们由开发人员编写,用于验证他们开发的软件单元是否正常运行。
- GUI 测试用例 −它们用于验证软件的图形用户界面。
- 集成测试用例 − 它们用于验证软件的不同组件在与其他组件集成后是否正常工作。
- 性能测试用例 − 它们用于验证软件的响应时间和整体性能。
- 数据库测试用例 − 它们用于验证后端以及所有数据是否反映在数据库中的正确表中。
- 安全测试用例 − 它们用于验证软件的安全功能。
- 可用性测试用例 − 它们用于验证软件是否可用且用户友好。
- 用户验收测试 −它们是为了验证软件在现实场景和环境中是否正常工作而编写的。
测试用例的实际示例
以下是功能测试用例的示例,旨在验证是否只有在用户拥有最低账户余额时才能处理付款。
模块名称 | Payment |
---|---|
测试用例 ID | 10 |
创建者 | Ram |
测试用例描述 | 验证付款功能 |
前提条件 | 1. 用户应该能够登录。 2. 用户的帐户中应该有一些余额。 |
环境 | Windows,最新的 Chrome 浏览器 UAT 环境 |
场景名称 | 验证是否仅在用户拥有最低帐户余额时才能处理付款。 |
测试用例 ID | 测试步骤 | 测试数据 | 预期结果 | 实际结果 | 状态 | 评论 |
---|---|---|---|---|---|---|
10 | 启动浏览器 | 用户凭据 | 应启动浏览器 | 已启动浏览器 | 通过 | N/A |
打开 URL | 应打开应用程序 URL | 应用程序 URL 是打开 | ||||
单击"余额"选项卡 | 应打开"余额"页面,并且用户应有一些余额。 | 已打开"余额"页面,并且用户有一些余额 | ||||
单击"付款"选项卡 | 应打开"付款"页面,并且用户应使用余额成功处理付款。 | 已打开"付款"页面,并且用户使用余额成功处理付款。 | ||||
单击注销 | 应注销应用程序。 | 应用程序已注销 |
在上面的例子中,用户首先启动浏览器并在那里打开一个应用程序。然后检查用户帐户余额,然后使用该余额付款。
结论
至此,我们对软件测试用例教程的全面介绍就结束了。我们首先描述了什么是测试用例,测试用例的基本特征是什么,什么时候编写测试用例,为什么要编写测试用例,测试用例和测试场景有什么区别,有哪些不同的测试管理工具,什么是正式和非正式的测试用例,有哪些不同类型的测试用例,以及测试用例的实际示例。
这将使您对软件测试测试用例有深入的了解。明智的做法是继续实践您所学到的知识,并探索与软件测试相关的其他知识,以加深您的理解并拓展您的视野。