测试用例的设计

发表于:2008-07-14来源:作者:点击数: 标签:
测试用例 这种东西对于刚入行的人来说是一种诱惑,初入测试的人急于掌握这门学问,所以一开始就会问测试用例怎么写,问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵,任何人没有必要注重形式问题,如果你现在或者未来的公司有套非常完善的文档
测试用例这种东西对于刚入行的人来说是一种诱惑,初入测试的人急于掌握这门学问,所以一开始就会问测试用例怎么写,问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵,任何人没有必要注重形式问题,如果你现在或者未来的公司有套非常完善的文档管理体系,那么你可以参考标准模版,如果没有你们大可跟我一样使用下面的格式:51Testing软件测试网9de3CA!H"BY8d*O'e

8@xEA+Vl C:S174837---------------------------------------------------------------
4~#nlK/N%bA174837- ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE
ZI-X5NS NT174837---------------------------------------------------------------

我认为没有什么问题,ID代表用例标号。ACT代表一种动作,因为测试动作非常复杂,如果手动执行或者自动执行,或者是一种异常状态都可以占用此位置。DATA代表数据,很多的测试类书籍中虽然没有直接讲明测试数据的划分,但是通常我们引用三种数据“正常”、“异常”、“错误”,分别对应关键字“PASS”、“ERROR”、“FAIL”,对于数据的划分我不细说了。为什么会在一个文档中体现这些内容——主要是为了以后的测试自动化,一个不能将手动测试转为自动测试的人员注定是平庸的。EXPECTED、ACTUAL分别代表期望和实际,我们做这一行的经常对这两种值的差异感到困惑,是不是“正常”、“异常”、“错误”就看个人的经验了。T/F的引入是因为有这样的一种情况介入,如果EXPECTED、ACTUAL是不同的,但是我们还是要给个T,因为对于单项的是否通过测试人员有着使用权,但决定权在于市场或者高层决策。DATE是一种好习惯,通常记为发现“PASS”、“ERROR”、“FAIL”的时间,很多人会忽略这个值,当然对于我们来说没什么损失,对于QA团队来说,仅仅提供给他们T/F是不够的。51Testing软件测试网@4GE*r.LKKr"z
》qiuyangzh:不过在我看来,还是要把ACTUAL-T/F-DATE部分抽取出来,因为这部分不能算是测试用例的内容,而是在后面实际执行测试的时候填写的。当然,可以使用同一个格式,在编写测试用例的时候,ACTUAL-T/F-DATE部分的内容空着,在每次执行这些用例的时候,将实际情况填写进去,当然,测试用例和每次的测试执行要写在不同的文档里。

我觉得这就是一种构造朴实的测试用例的方式,不要过于在意一份文档的表现形式,如果你有很多的时间,如果你一年才写一次测试用例,你当然可以从互联网上下载很多的资源把文档修饰的像APPLE的产品一样。
d"kBGU ]'gvA174837》qiuyangzh:测试用例要简洁、有效,这一点我非常同意。也许你和我一样,也曾经看到过那些格式复杂的测试用例,不能说它们不好,但不一定适合组织的情况。我认为在很多情况下,应该保持测试用例简洁和朴实的风格。简洁不等于简单,真正简洁、朴实的测试用例,仍然是非常有效和实际的。
FcoM w c174837  不过上面的测试用例格式有些过于单薄,比如测试用例的设计者和对应的测试需求,还是需要写上的。而且我的看法一直是:应该将测试用例和测试用例执行的记录分开,不要混在同一个部分,这样便于工作的进行。
nfzseMu17483751Testing软件测试网%bM7ya)MG
   入行的人员会更进一步的发挥测试偏执狂的能力,这时候的他们急需一种数量,例如:我们一个动态库的测试用例就有3000多个,厉害吧?厉害,我当然说你厉害,你难道不厉害吗?我记得有个500强的面试题就是你能为登录的动作写多少测试用例?我想了半天说就三个,或者四个,在听到了一声深深叹息后,我惶恐的说大概我能写5个吧?当然我自己也没底,我就能写出三个:LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL,所有的测试用例就是他们的衍生,一种本源的问题。我们继续讨论3000多个测试用例的事情,有人明眼就会说:这家伙肯定是微软的,没错,除了这种大公司有了充足的资源和技术支持,哪家公司能跟他们一样呢?当然了,写3000个我想入行久了谁都可以,并且跟你对系统的熟悉程度,工作经验有莫大的关系,但是这里我又想说说关于构造朴实的测试用例的问题了。
#yFsFTj)]174837   当你开始测试的时候,实际上最终是对代码设定路径的一种验算,如果我们都生活在单线程、无UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三种状态,可我们已经错过了这个年代,我们有了包装的UI,有了封装的API,有了各种各样的MESSAGE,所以你就要承受更多ERROR的打击。这个时候有人就会通过增加测试用例的数量来回避这些陷阱,出发点是好的做法是累死人的,如果你愿意你可以为机器码写1亿个测试用例,如果你还是很偏执,你可以为门电路写上1万亿个测试用例,你有时间执行吗?51Testing软件测试网L;K7cxJ
》qiuyangzh:如果资源充分,当然测试用例的数量多一些对于检验产品的质量是有好处的。但实际情况往往是资源有限的,这种情况下,就必须挑选出那些最有价值的测试来执行。

我通常不愿意写太多的测试用例,很多人认为我工作态度有问题,我认为这更能说明我的态度:我愿意朴实的构造我的测试用例,但是我有原则来保证我的测试用例的质量:
RM B.|4GD V8p174837   1。接到任务不急于作而在于多思考,首先在纸上构造好业务流图
%Hw'|V9z,_174837   2。业务流程图构造好,快速挑选出公用的测试用例
J#qNS0vh4f|2a Fr174837   3。构造测试用例,先写符合主路径的三种“PASS”、“ERROR”、“FAIL”51Testing软件测试网9H4JC_%Q/m}
   4。精化测试用例,努力为ERROR多构造1-7种假设
!r(G9f G2^6U[6i174837   5。执行测试用例,增加FAIL的标准化失败的测试,但是对应减少PASS测试用例
/O$`I9c,F|%es4hl174837   6。进一步精化测试用例,使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10
h [+jB]I5s4M'J4I174837》qiuyangzh:就是因为上面这段话,更确切的说是第4、5、6条,使我决定把这篇文章放到我的Blog中来。根据我的经验,在设计和执行测试的时候,应该按照这种比例来操作。51Testing软件测试网;}*J f\ku Z
51Testing软件测试网(Q;q5[)qgD
我将继续我的朴实理论,多出来的时间,我可以看看蓝天,享受享受生活!51Testing软件测试网%ZN7\|3Jl%{:[
》qiuyangzh:享受生活,享受工作

原文转自:http://www.ltesting.net