2011.11.1好日子,今天博客访问量超过1000了。 2012.01.29,访问量突破2000了. 2012.02.01,访问量突破3000了.继续进步

测试自我培训之二(测试用例编写)

上一篇 / 下一篇  2012-01-20 00:06:59 / 个人分类:测试流程培训

作为一个普通的测试人员,接下来就是掌握测试用例,测试用例是软件测试的核心.测试用例是测试工作的指导,是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。所谓的测试用例就是将软件测试的行为活动,做一个科学化的组织归纳.

 

测试用例内容:实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。对交互式系统,软件交互执行过程的控制也是一种测试用例,具体包括用例编号,用例标题,用例级别,前置条件,输入步骤,预期结果,备注.

 

测试用例的基本原则:测试用例的代表性,能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等;测试结果的可判定性:即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果;测试结果的可再现性:即对同样的测试用例,系统的执行结果应当是相同的。

 

设计测试用例的方法:具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、场景法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。在使用时要针对开发项目的特点对方法加以适当的选择.

等价类划分法:等价类划分法是把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值,也就是说,如果某一类中的一个例子发现了错误,这一等价类中的其他例子也能发现同样的错误;反之,如果某一类中的一个例子没有发现错误,则这一类中的其他例子也不会查出错误。使用这一方法设计测试用例,首先必须在分析需求规格说明的基础上划分等价类,列出等价类表。基本的分为有效等价类和无效等价类.

 

边界值分析法:边界值分析是一种补充等价划分的测试用例设计技术,它不是选择等价类的任意元素,而是选择等价类边界的测试用例。如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

 

场景法:用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。

 

错误推测法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。我个人认为此方法在测试人员经验和业务都有一定的积累情况之下,可以选择此方法.

 

正交实验设计方法:从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.正交实验设计方法的原则是用最少的测试用例来覆盖多个变量取值的两两组合

 

至于判定表驱动方法和因果图法,我至今编写过n个用例都没运用到此方法,所以暂时选择性放弃深入学习.

 

当我们学习和运用了测试用例方法后,根据知识和经验,我们可以配合项目来编写用例,而我个人现在的习惯是:

首先进行等价类划分,包括输入条件和输出条件的等价划分,将无限测试变成有限测试,这是减少工作量和提高测试效率的最有效方法.此方法是在需求规格书有规定数据的情况下例如该数据进行划分.所以此方法一般在测试开始都用(我基本很少碰到从头到尾写用例却没规格书的情况下,有也是建立在前辈的基础上增删.)

然后在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。

 

当用上面两种方法写完用例之后,假设我对测试的业务和经验有相当的积累,可以通过错误推断法来加入一些测试用例.这里开始算是初级工程师和中高级别工程师的分水岭.

接下来,假设是我的所在的项目的话,我应该已经写好了简单的预设条件,用例标题,测试用例的基本框架就出来,接下来做什么呢.就是开始分析需求了.

 

做个理想状态,我现在手下有2个组有人肯帮我写用例,一个组是用户体验测试组,一个组是一群测试老油条.项目现在有很充裕的时间的话,我会以高粒度(就是详细,多分支)来要求他们完善用例,但是老油条组的编写人员不用写得那么详细,只要把步骤内容的基本要素写好就行了,我相信他们领域能力高.但是体验组呢我会告诉他尽可能的详细些,同时运用场景测试法来编写新用例.

 

为什么在不同的情况会有不同的要求呢?第一,项目不紧张的时候我们可以更多时间去维护测试用例,编写更多情况的测试用例,反之,你需要衡量编写和测试的时间.第二,测试阶段的评估,假设你在功能测试阶段,其实很少有机会运用到场景测试的.因为该阶段我个人理解为条件不足够来编写好的场景测试用例,在用户体验阶段你可以设计出事件流和备用流,让你对从用户的角度来描述系统的行为,反映系统的期望运行方式。第三,你要考虑到测试人员的水平,你根据该组的水平来制订一套详细或者简单的测试用例.

 

好的测试人员能够写出高效且重复性高的用例,但是种种外界因素导致我们不能够做到理想状态.在这里补充说下场景测试设计.首先我们按照一个正常流程所涉及的几项数据或者操作步骤列出来,成为事件留,再按照不同的异常状况分出几种备用流.编写备用流前提是规格说明书需要给出每种异常的处理和你已经进行前面边界和等价法的测试.此时我们根据条件作出一个矩阵的表格,像火锅店的那样勾选条件,作出组合,然后按照组合来编写出测试用例.最后用正交法(其实也可以通过后期版本维护)来优化一下我们的用例.

 

这样,通过自学方式,我总结出我自己的编写用例方法:等价+边界值编写初始用例,然后通过错误法进行补充,在时间充裕和测试进度的改变进行场景+正交法来优化用例.

TAG:

xiao_chongqing的个人空间 引用 删除 xiao_chongqing   /   2012-03-06 16:04:38
-5
eallian的个人空间 引用 删除 eallian   /   2012-01-29 17:21:18
5
 

评分:0

我来说两句

acbennn

acbennn

站在云端看浮云,晕. CSDN的博客:http://blog.csdn.net/bullswu/article/details/6798437

日历

« 2024-04-30  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 60229
  • 日志数: 44
  • 建立时间: 2011-09-18
  • 更新时间: 2013-09-22

RSS订阅

Open Toolbar