作为
软件测试
人员,执行测试用例是我们进行测试
工作
的主要手段,测试
用例设计
的好坏,直接影响着测试工作的质量。一个“好”的测试用例能保证测试的质量,规范测试的进程,进而提高我们的测试效率。
那什么样的用例才是好的测试用例?这已经是一个老生常谈的问题,大家见仁见智 ,众说云云,不一而足。
而我的TL–候风的一句话,让我对用例的有了新的认识。他是这样说的:一个好的测试用例,就是在保证测试质量的前提下,做到以下几点:当一个不熟悉业务的人,看到你的用例后,要知道用例的测试目的什么,知道你要做什么,怎么做,为什么这样做,取得了什么什么成果。
做什么?
做任何事情,都要有的放矢。我们在编写一个测试用例的时候,应该知道我们要的是什么,这也是编写一个用例最基本的前提。
怎么做?
即具体的如何设计用例。就是要明确用例的执行过程,这样在测试的时候才能有章可循,摸着石头过河
为什么这样做?
这要求用例编写者要明确设计用例时用到的方法(如边界值,等价类等等),以及用这种方法的好处。
取得了什么成果?
这要求用例编写者明确通过这个测试用例,我们将取得什么效果。比如一个采用边界值设计的用例,取得的效果是在极端的数据下,软件是否能够正常执行功能。
标准规范中包含的主要元素如下:
1测试名称(Test Name):测试用例编号和测试用例名称。
2创建日期(Creation Date):测试用例创建时间,系统自动产生。
3设计人员(Designer):测试用例设计人员
4状态(Status):测试用例状态
5描述(Descrīption):测试用例详细描述
6步骤名称(Step Name):测试步骤名称
7步骤描述(Step Descrīption):测试步骤详细描述。
8预期结果(Expected Result):测试预期结果。
要是按照“候风标准”(暂且这样命名,还没申请侯哥批准),我们要对上面的标准进行规范的优化以及内容的明确
1测试名称
A)用例根据各用例的功能来命名,尽量做到简洁明了。
B)一级目录使用各项目的顶级菜单名称来命名,如功能、业务、查询三大类;
C)二级目录使用顶级菜单下的二级菜单名称类命名,用户可根据名字判别该用例是测试哪个模块的。
2 描述(Descrīption):测试用例详细描述
要用通俗易懂而又简洁的语言描述描述用例的设计目的,让其他人能够明白我们在什么
3 步骤描述
步骤描述要详细而不臃肿,条理而不凌乱。
同时,在规范上要增加以下几项
1 测试目的(Purpose):编写这个测试用例的目的
2 测试方法选择依据(Foundation):即用这样方法的好处
3 测试取得的成果(Achievement):通过执行用例取得的成果
4 用例执行的前提条件(Precondition):执行用例的需要满足的前提
这样,一个完整的用例包含的元素如下:
1测试名称(Test Name)
2 测试目的(Purpose)
3 测试方法选择依据(Foundation)
4 用例执行的前提条件(Precondition)
5创建日期(Creation Date)
6设计人员(Designer)
7状态(Status)
8描述(Descrīption)
9步骤名称(Step Name)
10步骤描述(Step Descrīption)
11预期结果(Expected Result)
12 测试取得的成果(Achievement)
.
综上所述,测试用例的“侯式标准”的精髓,就是把自己的思维过程尽可能的展现到用例中,做到即使一个完全不懂业务的人,看到我们的用例后,也能知道业务的需求和流程,知道测试的过程,能够无障碍的执行我们的用例。
以上是我学习用例编写过程中的一些体会,不足之处请大家批评指正。让我们一起交流分享,共同进步成长。