对于具体的某个测试用例，不妨可定义如下的质量标准：
（1） 测试用例的出发点是发现缺陷，即单个测试用例在“暴露缺陷”上具有较高的可能性。
（2） 测试用例的单一性。一个测试用例面向一个测试点，不要将许多测试点揉在一起。例如，通过一个测试用例发现1～2个缺陷，而不能发现5～10个缺陷甚至更多的缺陷。
（3） 符合测试用例设计规范或测试用例模板，见下面附表所示。
（4） 描述清楚，包括特定的场合、特定的对象和特定的术语，没有含糊的概念和一般性的描述。例如，测试用例名称为“登录功能使用正常”，就是一个描述不清楚的例子，而这样的描述“登录功能中用户名大小写不敏感性验证”、“登录功能中用户名唯一性验证”和“用户帐号被锁定后再进行登录操作”等就比较好。
（5） 操作步骤的准确性，按照步骤的操作得到唯一的测试结果。
（6） 操作步骤的简单性。操作步骤不应该太复杂，过于复杂的操作步骤意味着测试用例需要被分解为多个测试用例或者分解为多个环节进行验证。
（7） 所期望的测试结果是可验证的，即能迅速、明确地判断测试的实际结果是否与所期望的结果相同或相匹配。例如，在测试用例中描述期望结果为“登录成功”，这实际是不可验证的。要使这个期望结果具有可验证性，我们就应该这样描述所期望的结果——“‘退出（log out）’按钮出现”。
（8） 测试环境的正确性、测试数据的充分性。
（9） 前提条件、依赖性被完全识别出来。
这样，测试用例具有很好的可理解性和可维护性，可以提高测试执行的效率。并能保证不同的人员执行相同的用例能获得统一的结果。步骤的准确性和期望结果的可验证性，非常有助于测试执行的自动化实现。也只有实现了测试执行的自动化，测试执行的效率才是最高的，而且测试人员才有更多的时间去思考、去设计更优秀的测试用例，进入良性循环，相互促进，不断地提升测试的质量和效率。
| 字段名称 | 类型 | 注释 |
| 标志符 | 整型 | 唯一标识该测试用例的值，自动生成 |
| 测试项 | 字符型 | 测试的对象，可以从软件配置库中选择 |
| 测试目标 | 字符型 | 从固定列表中选择一个 |
| 测试环境要求 | 字符型 | 可从列表中选择，如果没有，则直接输入新增内容 |
| 前提 | 字符型 | 事先设定、条件限制，如已登录、某个选项已选上 |
| 输入数据 | 字符型 | 输入要求说明、或数据列举 |
| 操作步骤 | 字符型 | 按1., 2., …操作步骤的顺序，准确详细地描述。 |
| 期望输出 | 字符型 | |
| 所属模块 | 整型 | 模块标识符。 |
| 优先级 | 整型 | 1，2，3（1－优先级最高） |
| 层次 | 整型 | 0，1，2，3 ( 0 –最高层) |
| 关联的测试用例 | 整型 | 上层（父）用例的标识符。 |
| 执行时间 | 实型 | 分钟 |
| 自动化标识 | 布尔型 | T，F |
| 关联的缺陷 | 枚举型 | 缺陷标识符列表。 |
|
|
|
|
文章来源于领测软件测试网 https://www.ltesting.net/
