实用测试用例书写规范

王 彩

成都东软学院计算机科学系，四川成都 611844

0 引言

在软件项目中，测试用例的设计起着至关重要的作用。在测试过程中使用测试用例具有以下几个方面的作用：有效性，准确的测试用例的设计、执行和跟踪是测试有效性的有力证明；可评估性，测试用例的通过率和bug的数量是普遍采用的测试量化标准；可复用性，良好的测试用例具有易于修改维护可重复使用的特点。

1 测试用例概念

测试用例是可以独立进行执行的最小测试单元，描述了测试内容的一系列情景和每个情景中所包含的输入和输出，以及对软件行为/状态的正确性做出判断的依据。如果结合实际应用，用公式可以这样表示：Test Case = ID + Initialization + operate+ data+expected results，也就是以下要素相加，编号、初始化条件/环境、操作、数据和预期结果。

2 测试用例设计讨论

测试用例该如何写才实用，我们结合一个虚拟的测试需求加以讨论。假设我们要测试某网站邮箱的注册功能，用户只需注册邮件账号，邮件域名是固定的。Email账号必须满足以下规则：由字母和数字组成 ；必须以字母开头 ；长度为6位～18位 ；账号唯一 。测试用例设计讨论示例一、二，如表1、表2。

表1 测试用例设计示例一

表2 测试用例设计示例二

上述测试用例的设计是否规范实用，我们可以通过几个用例的后续工作流程来看，分别是审查、执行、维护和复用：用例是否方便审查？审查的内容有很多方面，实际应用中常常关心的是用例设计思路是否完整。示例一中这种用例形式，粗略的分成有效用例和无效用例，只有测试数据，没有测试思路，要想高效评审是非常困难的。用例方便执行吗？示例一没有思路描述 ，测试执行者是不容易理解测试重点在哪儿，照着数据敲又容易出错，这样的用例对执行者来说是不具备指导意义的。用例方便维护吗，可以复用吗？这两个方面是相互关联的。假如这里邮件账号组成变了，像示例一中这种没有思路提示的用例是很难修改的。这样就不利于用例的维护，更无法谈复用的问题了。

示例一只强调测试数据，把用例设计简单等同于测试数据设计。示例二强调的是测试思路，避免了示例一中产生的问题。但是示例二没有测试数据和预期结果，适用情况有限。对于无测试数据、测试数据简单、预期结果简单直观 ，或者项目时间紧的情况，才可以用这种形式的用例。

从上述讨论，我们可以得出这样的结论，测试思路比测试数据更具有指导意义。但是，示例二中并不适用普遍的情况。规范的测试用例至少要包含下述关键要素：用例编号、测试环境、用例标题、用例操作、测试数据以及预期结果，下面我们将一一阐述：

编号不用赘述，符合一般的要求即可：便于检索，易于识别，保证唯一性。

测试环境很重要，针对不同测试对象会有不一样的环境项，比如这里我们只要标示出操作系统和浏览器就足够了。但如果是手机测试，环境项就要包含很多手机参数，包括手机品牌、手机型号、操作系统、是否智能机、屏幕分辨率、手机卡容量等等。

用例的标题是用一个词或者一句话表达用例的主题，反映测试的思路。比如“有效用例”就可以作为标题，但是不能简单的用“无效用例”作为标题。因为无效的情况太多了，要尽量明确无效原因，“大于最大长度”还是“重复的邮件账号”。

测试用例的操作也叫输入条件。很多测试人员对测试用例操作有这样一个误解：把用例操作当成填写具体操作步骤的表格。“操作”并不只是用来描述具体实现的，而是着重描述处理问题的思路，描述我们将要如何进行测试。

测试数据的重要性毋庸置疑！本例中，有思路提示后执行者很清楚应该用什么样的测试数据，所以测试数据列可写可不写。但是这种情况绝不是一概而论 。特别是某些用例的失败和特定的测试数据相关的情况。

还有很重要的一个因素是预期结果，它是对软件行为/状态的正确性做出判断的依据。不要像示例一中那样，简单写成通过/不通过。有很多附属结果会发生，并影响对用例结果的判断。本例中注册失败后，可能有系统提示，光标移动等可见行为，还要注意在后台数据库中验证数据有没有写进数据库表。

综合上述用例的要素描述并结合本文假定的测试需求，给出部分测试用例参考如下：

表3 测试用例设计规范参考

3 结论

本文就测试用例的几个关键要素阐述了作者的观点和设计思路，在实际应用中，不同公司不同类型项目所适用的用例规范不可能完全一样，一定是和具体实践相结合的。国内的测试行业和测试规范还处在一个快速发展的时期，有无限的潜力和机遇等待我们去发掘。

[1]Edward.Kit.软件测试过程改进[M].李新华，陈丽容，等译.机械工业出版社，2011，5.

[2]Gerard,ORegan,闪四清.软件质量实用方法论[M].清华大学出版社，2011，5.

[3]朱少民.全程软件测试[M].电子工业出版社，2010，8.

[4]Rex.Black.软件测试过程管理[M].龚波，但静培，等译.机械工业出版社，2007，10.

[5]聂长海.关于软件测试的几点思考[J].计算机科学，2011(2).