一、测试用例概述

1、测试用例的定义

简单地说，测试用例就是：

设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果

2、测试用例特点：

有效性：测试用例是测试人员测试过程中的重要参考依据。

可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率。

易组织性：即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过 程中被创建和使用。

可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。

可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。

3、测试用例应该包含的内容

测试用例应该包含以下内容：

标识符：由测试设计过程说明和测试程序说明引用的惟一标识符

测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。还要指出引用 的产品说明书或者测试用例所依据的其他设计文档。

输入说明：该说明列举执行测试用例的所有输入内容或者条件。

输出说明：描述进行测试用例预期的结果。

环境要求：是指执行测试用例必要的硬件、软件、测试工具、人员等。

特殊要求：描述执行测试必须的特殊要求。

用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。

4、设计测试用例的好处

测试用例在软件测试中的作用

• 指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试

• 规划测试数据的准备

除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

• 编写测试脚本的"设计规格说明书"

为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

• 评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。

• 分析缺陷的标准

通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

二、测试用例模板

测试用例模板

1. 编号: 唯一 规则:准确标识一条测试用例 产品名称(编号)+模块名称+测试阶段+编号

2. 所属模块: 规则:详细到具体的操作的模块名称

3. 优先级别: 规则: 高(基本功能)，中(页面展示效果,不影响整个流程的的操作)，低(页面排版)

4. 标题: 规则:准确描述用例目的

5. 测试前提: 规则:详细描述测试环境的状态

6. 测试步骤 规则:有条理的描述测试步骤

7. 测试数据: 规则:详细清晰描述测试数据

8. 期望结果: 规则:详细清晰描述预期结果 与测试步骤一一对应

9. 实际结果: 规则:T 成功 F 失败 Na 表示有阻碍

测试用例编号规则

目的：好的测试用例编号，可以更好的去了解此项用例所针对的模块，也有助于记忆和新用例的增加。

规则：测试用例编号采用“版本+细类+编号”的形式。

备注：其中“版本”为设计此测试用例的软件版本。

“细类”为小模块中的汉字头一个字母，以最多5个字母为标准。

“编号”为BUG用例的编号，以4位为标准，依次递增。

例如：引导系统V2.01版本中，候车点设置，用例编号可以书写为：

 2.01_HCDSZ_0001

三、用例编写注意

不要设计“穷举测试用例”

在详细测试用例与有效测试时间中找到平衡点

好的测试用例应该多关注“反向测试问题”

测试用例库应该不断更新和维护

测试用例可以复用，但要注意数据有效性与环境变化

测试用例是设计出来的，不是写出来的

多去学习经验丰富的测试工程师所设计的测试用例

针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法

四、测试用例设计的误区

1、能发现到目前为止没有发现的缺陷的用例是好的用例：

测试本身是一种“V&V”的活动，测试需要保证以下两点：

程序做了它应该做的事情

l程序没有做它不该做的事情

因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；

测可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。

测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。

3、测试用例设计是一劳永逸的事情；

测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据；

测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。

5、测试用例中不需要明显的验证手段；

“预期结果”的含义并不只是程序的可见行为。因此，在一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

作者：小小馋猫

原文链接：https://blog.csdn.net/weixin_48187806/article/details/108747658