中国测试平台网

 

 

测试用例 软件测试用例的设计
查看: 467|回复: 3
go

软件测试用例的设计

Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8Rank: 8

     测试用例这种东西对于刚入行的人来说是一种诱惑,初入测试的人急于掌握这门学问,所以一开始就会问测试用例怎么写,问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵,任何人没有必要注重形式问题,如果你现在或者未来的公司有套非常完善的文档管理体系,那么你可以参考标准模版,如果没有你们大可跟我一样使用下面的格式:  ---------------------------------------------------------------
  - ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE
  ---------------------------------------------------------------
  我认为没有什么问题,ID代表用例标号。ACT代表一种动作,因为测试动作非常复杂,如果手动执行或者自动执行,或者是一种异常状态都可以占用此位置。DATA代表数据,很多的测试类书籍中虽然没有直接讲明测试数据的划分,但是通常我们引用三种数据“正常”、“异常”、“错误”,分别对应关键字“PASS”、“ERROR”、“FAIL”,对于数据的划分我不细说了。为什么会在一个文档中体现这些内容——主要是为了以后的测试自动化,一个不能将手动测试转为自动测试的人员注定是平庸的。EXPECTED、ACTUAL分别代表期望和实际,我们做这一行的经常对这两种值的差异感到困惑,是不是“正常”、“异常”、“错误”就看个人的经验了。T/F的引入是因为有这样的一种情况介入,如果EXPECTED、ACTUAL是不同的,但是我们还是要给个T,因为对于单项的是否通过测试人员有着使用权,但决定权在于市场或者高层决策。DATE是一种好习惯,通常记为发现“PASS”、“ERROR”、“FAIL”的时间,很多人会忽略这个值,当然对于我们来说没什么损失,对于QA团队来说,仅仅提供给他们T/F是不够的。
  》qiuyangzh:不过在我看来,还是要把ACTUAL-T/F-DATE部分抽取出来,因为这部分不能算是测试用例的内容,而是在后面实际执行测试的时候填写的。当然,可以使用同一个格式,在编写测试用例的时候,ACTUAL-T/F-DATE部分的内容空着,在每次执行这些用例的时候,将实际情况填写进去,当然,测试用例和每次的测试执行要写在不同的文档里。
  我觉得这就是一种构造朴实的测试用例的方式,不要过于在意一份文档的表现形式,如果你有很多的时间,如果你一年才写一次测试用例,你当然可以从互联网上下载很多的资源把文档修饰的像APPLE的产品一样。
  》qiuyangzh:测试用例要简洁、有效,这一点我非常同意。也许你和我一样,也曾经看到过那些格式复杂的测试用例,不能说它们不好,但不一定适合组织的情况。我认为在很多情况下,应该保持测试用例简洁和朴实的风格。简洁不等于简单,真正简洁、朴实的测试用例,仍然是非常有效和实际的。
  不过上面的测试用例格式有些过于单薄,比如测试用例的设计者和对应的测试需求,还是需要写上的。而且我的看法一直是:应该将测试用例和测试用例执行的记录分开,不要混在同一个部分,这样便于工作的进行。
  入行的人员会更进一步的发挥测试偏执狂的能力,这时候的他们急需一种数量,例如:我们一个动态库的测试用例就有3000多个,厉害吧?厉害,我当然说你厉害,你难道不厉害吗?我记得有个500强的面试题就是你能为登录的动作写多少测试用例?我想了半天说就三个,或者四个,在听到了一声深深叹息后,我惶恐的说大概我能写5个吧?当然我自己也没底,我就能写出三个:LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL,所有的测试用例就是他们的衍生,一种本源的问题。我们继续讨论3000多个测试用例的事情,有人明眼就会说:这家伙肯定是微软的,没错,除了这种大公司有了充足的资源和技术支持,哪家公司能跟他们一样呢?当然了,写3000个我想入行久了谁都可以,并且跟你对系统的熟悉程度,工作经验有莫大的关系,但是这里我又想说说关于构造朴实的测试用例的问题了。
  当你开始测试的时候,实际上最终是对代码设定路径的一种验算,如果我们都生活在单线程、无UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三种状态,可我们已经错过了这个年代,我们有了包装的UI,有了封装的API,有了各种各样的MESSAGE,所以你就要承受更多ERROR的打击。这个时候有人就会通过增加测试用例的数量来回避这些陷阱,出发点是好的做法是累死人的,如果你愿意你可以为机器码写1亿个测试用例,如果你还是很偏执,你可以为门电路写上1万亿个测试用例,你有时间执行吗?
  》qiuyangzh:如果资源充分,当然测试用例的数量多一些对于检验产品的质量是有好处的。但实际情况往往是资源有限的,这种情况下,就必须挑选出那些最有价值的测试来执行。
  我通常不愿意写太多的测试用例,很多人认为我工作态度有问题,我认为这更能说明我的态度:我愿意朴实的构造我的测试用例,但是我有原则来保证我的测试用例的质量:
  1、接到任务不急于作而在于多思考,首先在纸上构造好业务流图
  2、业务流程图构造好,快速挑选出公用的测试用例
  3、构造测试用例,先写符合主路径的三种“PASS”、“ERROR”、“FAIL”
  4、精化测试用例,努力为ERROR多构造1-7种假设
  5、执行测试用例,增加FAIL的标准化失败的测试,但是对应减少PASS测试用例
  6、进一步精化测试用例,使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10
  》qiuyangzh:就是因为上面这段话,更确切的说是第4、5、6条,使我决定把这篇文章放到我的Blog中来。根据我的经验,在设计和执行测试的时候,应该按照这种比例来操作。
  我将继续我的朴实理论,多出来的时间,我可以看看蓝天,享受享受生活!
  》qiuyangzh:享受生活,享受工作!

Rank: 1

楼主高人啊,我先收藏了











static/image/common/sigline.gif
实习生客服

Rank: 1

蛮通东西巧,设计也很妙,插头可扩展,插座还带槽,
   头尾能互连,再多能接好,规范又美观,功大用得牢。
ac170.com   武汉魔块电器   淘宝搜索  蛮通

创业机遇并不多,   使用范围足够大,   进门入行门槛低,
绝好机会莫错过,   取代插头和插座,   货物花钱只几个,
蛮通产品独家有,   插头再多连一体,   淘宝搜搜看蛮通,
销售加盟先入伙;   电流大还不脱落;   有财不发千万莫。

蛮通:插头插座时代终结者

欢迎:电器生产商、投资商、经销商、各种有能够用得上的机构加盟,
诚聘:生产管理、设计、推广、销售、网络、财务等有各种用得上的资源人士入伙,      
先到入伙电话:027-83219370

Rank: 1

支持你加分











闪电从不打在相同的地方,人不该被相同的方式伤害两次。

除湿机  dna100.com小店出售各类空气处理设备,淘宝店铺搜索“方凌电器”就可以找到。

Copyright (C) 1997-2013 Chinabyte.com, All Rights Reserved

GMT,

Powered by Discuz!

© 2001-2010 Comsenz Inc.