【软件测试】测试用例篇

玩技站长
玩技站长
管理员, Keymaster
11056
文章
0
粉丝
测试分享评论113字数 2219阅读7分23秒阅读模式
摘要测试用例是为了实施测试而向被测试的系统提供的一组集合,这组集合包括:测试环境、操作步骤、测试数据、预期结果等要素

1.什么是测试用例?

测试用列(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素。文章源自玩技e族-https://www.playezu.com/185143.html

2.测试用例的要素文章源自玩技e族-https://www.playezu.com/185143.html

测试用例的标题、测试思路、预设条件、步骤、预期输出文章源自玩技e族-https://www.playezu.com/185143.html

一个好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。文章源自玩技e族-https://www.playezu.com/185143.html

评价测试用例的标准:文章源自玩技e族-https://www.playezu.com/185143.html

•用例表达清楚,无二义性文章源自玩技e族-https://www.playezu.com/185143.html

•用例可操作性强文章源自玩技e族-https://www.playezu.com/185143.html

•永猎的输入与输出明确,一条用例只有一个预期结果文章源自玩技e族-https://www.playezu.com/185143.html

•用例的可维护性好文章源自玩技e族-https://www.playezu.com/185143.html

•用例对需求的覆盖率高文章源自玩技e族-https://www.playezu.com/185143.html

•暴露程序bug的能力强

3.测试用例的好处

•它是测试执行者的依据

•它使得工作可重复,自动化测试的基础

•评估需求覆盖率

•用例的复用

•积累测试的方法思路以供后续借鉴

4.测试用例的设计方法

4.1 总体的设计方法

基于需求的设计

基于需求的测试方法RBT(Requirements-Based Testing)是基于需求的测试方法,会使得测试更加有效,它使测试专注于质量问题产生的根源,即需求。

基于需求的测试是一种最根本的软件测试,它关注以下问题:

•验证需求是否正确、完整、无二义性,并且逻辑一致

•要从“黑盒”的角度,设计出充分并且必要的测试集,以保证设计和代码都能完全符合要求

4.2具体的设计方法

<1>等价类:

依据需求将输入(特殊情况下会考虑输出)划分为若干个等价类,从等价类找那个选出一个测试用例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题。

•有效等价类

对于程序的规格说明书是合理的、有意义的输入数据构成的集合,利用有效等价类验证程序是否实现了规格说明书中所规定的功能和性能

•无效等价类

根据需求说明书,不满足需求的集合

等价类只考虑输入域的分类,没有考虑输入域的组合,需要其他的设计方法和补充。

<2>边界值:

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分的补充,这种情况下,其测试用例来自等价类的边界。

例:针对6-15位长度设计测试用例。

有效等价类:6 < x < 15

无效等价类:x < 6 || x > 15

边界值:5,6,15,16

完整的测试用例:5,6,10,15,16

在有效等价类中任选一个值代表这个等价类。

为什么6和15不能代表等价类?

边界值法要和等价类法结合使用,是互补的,边界值是等价类的一种补充。有效等价类的选取时,不选边界值,边界值单独写。

为什么不用3和4作为边界值?

3和4可以代表小于边界的类,但不能代表等于边界的类,5可以代表等于边界的类,也可以代表小于边界的类

数据是有区间的:取边界值的时候要注意是否包含边界值,注意开区间和闭区间

[1,50] 边界值:0,1,50,51

(1,50) 边界值 :1,2,49,50

[1,50) 边界值:0,1,49,50

<3>因果图

因果图是一种简化了的逻辑图,能直观地表明程序输入条件(原因)和输出动作(结果)之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法,特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

•恒等

【软件测试】测试用例篇插图

恒等:如果原因为真,那么结果必定为真

•与

【软件测试】测试用例篇插图1

与:只有两个原因都为真,结果才为真

•或

【软件测试】测试用例篇插图2

2个原因中有一个为真,结果就为真

•非

【软件测试】测试用例篇插图3

只有原因为假,结果才为真

因果图设计测试用例的步骤:

•分析所有可能的输入和输出

•找出输入与输出之间的对应关系

•画出因果图

•把因果图转换成判定表

•把判定对应到每一个测试用例

因果法设计测试用例可以帮助测试人员理清输入和输出的关系,但对于比较复杂的输入和输出,会耗费大量的时间

<4>正交排列

目的:正交法是为了减少用例数目,ongoing尽量少的用例覆盖输入的两两组合。

定义:正交试验设计是研究多因素多水平的一种设计方法,它是根据正交性,由试验因素的全部水平组合中挑选出部分有代表性的点进行试验,通过对这部分试验结果的分析了解全面试验的情况,找出最优的水平组合,正交试验设计是一种基于正交表的、高效率、快速、经济的是试验。

正交表中的有关概念:

因素(Factor):在一项试验中,凡欲考察的变量称为因素(变量)

水平(位级)(Level):在实验范围内,因素被考察的值称为水平(变量的取值)

行数(Runs):正交表中的行的个数,及试验的次数,用N表示

因素数(Factors):正交表中列的个数,用C代表

水平数(Levels):任何单个因素能够取得的值的最大个数。

正交表中包含的值为从0到“水平数-1”,或从1到“水平数”,用T代表

正交表的表示形式:

L=行数(水平数*因素数)

L=N(TC)

L 6(25):代表有6次试验,5代表有5列,有5个考察的因素,2代表每个因素有2种水平,也就是2种取值

正交表的两条性质:

•每一列中各数字出现的次数都一样多

•任何两列所构成的各有序数对出现的次数都一样多

<5>场景法

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的场景,有利于测试设计者设计测试用例,使测试用例更容易理解和执行。

用业务流把各个孤立的功能点串起来,为测试人员建立整体业务感觉,从而避免陷入功能细节忽视业务流程要点的错误倾向。

<6>错误猜想法

错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。基于经验和直觉,找出程序中你认为可能出现的错误,有针对性的设计测试用例。

5.测试用例的有效性

可以正常的发现有BUG的程序,或正常的验证程序是正确的。

6.测试用例的粒度和评价

测试用例的粒度:是指测试用例编写的详细程度。

测试用例可以写得和简单,也可以写的很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内容,复杂的测试用例会指定输入的每项数,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等。

大多数的测试团队编写的测试用例的粒度介于两者之间,如何把握好粒度是测试用例设计的关键,也将影响测试用例设计的效率和效果,应该根据项目的时机情况、测试资源情况来决定设计出怎样粒度的测试用例。

可以考虑以下的内容:

•产品的质量要求

•项目对用例的要求

•测试时间和资源是否充分

测试用例的评价:

评审分为正式和非正式评审。

•同行评审

•用户评审

•项目组的评审

总结:

编写测试用例的时候,要分为正向、逆向、考虑边界条件、容错、性能、安全、兼容等方面考虑。

 
匿名

发表评论

匿名网友
确定

拖动滑块以完成验证