• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

测试用例的设计

发布: 2007-6-01 10:13 | 作者: 网络转载 | 来源: 网络 | 查看: 937次 | 进入软件测试论坛讨论

领测软件测试网

 测试用例这种东西对于刚入行的人来说是一种诱惑,初入测试的人急于掌握这门学问,所以一开始就会问测试用例怎么写,问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵,任何人没有必要注重形式问题,如果你现在或者未来的公司有套非常完善的文档管理体系,那么你可以参考标准模版,如果没有你们大可跟我一样使用下面的格式:

---------------------------------------------------------------
- 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中来。根据我的经验,在设计和执行测试的时候,应该按照这种比例来操作。

  我将继续我的朴实理论,多出来的时间,我可以看看蓝天,享受享受生活!

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 测试 设计 用例


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网