精华内容
下载资源
问答
  • 软件测试用例设计(三)——场景

    千次阅读 多人点赞 2019-10-30 17:24:46
    1、面试官问:场景举例说明,怎么回答? 反正我有点懵,虽然在工作过程中,我一直运用的是场景法,但我说不出场景法的观点来。 2、群友热心回答:正向流和逆向流,基本流和备选流 然而,我还是非洲问号脸???...

    场景法

    影子

    本来想直接跳过场景法的,今天群友提出问题:
    1、面试官问:场景法举例说明,怎么回答?
    反正我有点懵,虽然在工作过程中,我一直运用的是场景法,但我说不出场景法的观点来。
    2、群友热心回答:正向流和逆向流,基本流和备选流
    然而,我还是非洲问号脸???

    场景法介绍

    首先上网查资料,给了我一个图,这个图是啥啊???
    场景业务流通常分为基本流、备选流、异常流程
    在这里插入图片描述
    然后看文字:
    我先放上查到的定义。·
    基本流:基本流表示通过业务流程时输入都正确,能达到目标的流程。

    (插卡–》输入正确密码–》输入金额–》取款–》取卡)

    备选流:备选流表示通过业务流程时输入错误(或者操作错误)导致流程存在反复,但是经过纠正后仍能达到能达到目标的流程
    .(插卡–>输入错误密码–》输入正确密码–》输入金额–》取款–》取卡)

    异常流:异常流表示通过业务流程时输入错误(或者操作错误)产生异常终止流程 (插卡–>输入3次错误密码–》吞卡)

    结合例子和文字描述就很清楚了:
    基本流:
    业务流程开始——业务流程结束
    (1)只有1种情形,中间的所有业务流程也是正确的,最后达到的结果是正确结束,这个场景是一个基线。
    举个例子:就是你从起点开始,一直沿着正确的道路走,最后到达终点。
    备选流:
    (1)业务流程开始——业务流程存在反复——业务流程结束
    (2)业务流程开始——业务流程存在反复——业务流程中断——未结束
    举个例子:
    你从起点开始,走到中途走错了路,但是你认得路,于是沿着新的路线,虽然绕了路,但是最终还是走到了终点
    你从起点开始,走到中途走错了路,但是你不认得路,于是开始探路,但是最终还是没有走到终点

    异常流:
    业务流程开始——业务流程中断——未结束
    在这种情况下正确的业务流程没有走完
    举个例子:
    就是你从起点开始,走到中途走错了路,但是你被困于死迷宫,然后你就一直到不了终点

    场景法用例设计举例

    例子举的有点不是很恰当,但我对场景法很自信,因为我测试的项目天天在用。
    一个重要的测试模块就是登录,我们的登录方式是密码+短信,密码输错5次后账号会冻结,短信验证码有效时间是200s,验证错误超过3次后,短信验证码也会失效
    我先用文字描述一下
    基本流:
    (1)输入正确账号——输入正确密码——点击登录,获取短信验证码成功——200s内输入正确短信验证码——再次点击登录按钮——登录成功——返回上次登录时间和IP——登录日志记录正确
    备选流
    (1)输入正确账号——输入四次错误密码——输入正确密码——点击登录,获取短信验证码成功——200s内输入正确短信验证码——再次点击登录按钮——登录成功——返回上次登录时间和IP——登录日志记录正确
    (2)输入正确账号——输入五次错误密码——输入正确密码——点击登录,提示账号已被冻结——登录失败——登录日志记录正确

    异常流
    (1)输入正确账号——输入错误密码——登录失败——登录日志记录正确
    (2)输入冻结账号——输入正确密码——登录失败——登录日志记录正确

     这里强调一下,场景流梳理实际上是业务的梳理,意味着相关的业务场景必须都考虑进去,真正达到业务流程开始从业务流程结束
     实际的业务场景要考虑的更多
     区分备选流和异常流主要是看用例结束后业务流程是否是正确结束
    

    场景法设计用例步骤和表示

    步骤:
    1、首先确定执行用例场景所需的数据元素
    2、然后构建矩阵,最后要确定包含执行场景所需的适当条件的测试用例。
    在矩阵中,V表示这个条件必须是有效的才可执行基本流,I表示这种条件下将激活所需备选流 ,n/a表示这个条件不适用于测试用例。
    表示:
    每一个场景都需要确定测试用例,一般采用矩阵或决策表来确定和管理测试用例。第一行是测试用例ID、场景/条件、测试用例中涉及的所有数据元素和预期结果。

    场景法举例

    【举例1:】
    还是登录场景,我们的登录方式是密码+短信,密码输错5次后账号会冻结15分钟,短信验证码有效时间是200s,验证错误超过3次后,短信验证码也会失效
    在这里插入图片描述符号定义:
    V:Valid
    I:Invalid
    n/a:Not Applicable

    涉及到的数据元素
    账号、密码、短信验证码

    这里举的例子比较简单

    扩展例子

    游戏签到场景测试用例
    这里先看一下游戏策划书写的游戏签到策划方案
    https://gameinstitute.qq.com/community/detail/111163
    其中:附上一个APP的签到界面
    在这里插入图片描述再配上一个游戏的签到界面。
    在这里插入图片描述
    1、进入签到界面,页面显示正确和美观
    2、第N(N=1,2,3,4,5,6,7)天签到,当天签到状态变为已签到,领取当天的签到奖励
    3、第N(N=1,2,3,4,5,6,7)天没有签到,当天签到状态变为未签到,无法领取当天的到奖励
    4、连续M(M=1,2,3,4,5,6,7)天签到,当天签到状态变为已签到,领取到当天的签到奖励和累计的签到奖励
    5、连续M(M=1,2,3,4,5,6,7)天签到中断,当天签到状态变为未签到,无法领取到当天的签到奖励和累计的签到奖励,重新计算累计签到时间
    6、当天签到后,领取签到奖励,奖励领取状态变更正确,文字提示,增加到累计签到时间
    7、奖励领取成功,奖励发放的物品种类、数量增加正确,并且领到的物品能够在游戏内正常的消耗和被使用
    8、一天签到结束后,当天不再显示签到界面,如果当天一直不签到,当天登录首先进入的是签到界面
    9、一段时间的签到活动时间(比如:一周)结束后,是否开始新一轮的游戏签到7天活动
    10、签到的时间规则:在约定时间范围内签到,签到得到今天的奖励,在约定时间外签到,可能没有奖励(一般情况下,签到时间范围和自然日有区别)
    11、签到对所有等级用户都开放,VIP等级有加倍奖励

    异常场景:
    1、连续点击N次签到,只领取一次奖励,
    2、多次领取一天签到、累计签到奖励

    扩展:补签功能
    1、补签的天数+实际签到天数<=最大签到天数
    2、补签次数限制

    其实签到的这个例子并不是找的特别好,但我觉得有代表性。你们发现没有:当我把场景法的矩阵顺时针旋转90度时,是不是演化成了判定表,这是因为签到只有两种状态。
    但是我觉得你在面试游戏测试的时候,面试官肯定想考察的是你的场景考虑的全不全的问题。也就是文章末尾提到的整体业务感觉的问题。

    总结

    最后,总结一下场景法和因果图(用例设计二和三提到的方法)两种方法的区别和适用范围。
    因果图的分析步骤:
    1、在需求规格说明书中找出哪些是输入条件(原因),哪些是输出条件(结果)
    2、判定表的每一行首写输入条件、输出条件
    3、根据原因和结果找对应的逻辑关系,用符号0,1,-分别表示满足、不满足和无关,每一列是一个用例

    场景法的分析步骤:
    1、根据说明,找出基本流
    2、根据基本流中不同的数据元素据此找出备选流和异常流
    3、根据备选流和异常流构造新的场景

    因果图的适用范围
    因果关系很复杂,用场景法很难找到一个基本流时,不妨关注需求规格说明,找出输入条件和输出条件的因果关系,利用因果图法和判定表反而能快速梳理条件之间的因果关系
    eg:上一篇博文中的售货机就不使用场景法,因为你用场景法很难去构造一个基本流。没有了基本流作为一个准绳,用场景法构造会很费脑力,而且也很容易忽略条件之间的因果关系

    场景法的适用范围
    场景法多用于系统的典型业务和典型功能,首先能很方便的构造一个基本流,因果图侧重因果关系,用0和1区分有效无效的数据元素,不如场景法的矩阵图来的直观,也不能穷尽场景法的所有场景
    (因为场景法不只有0和1两种场景,举个例子:登录场景账号状态的校验有账号是否输入、账号是否存在、账号是否过期等校验,用判定表会增加行数,也不方便于我们理清所有的业务流)

    场景法的注意点

    注意:
    场景法偏重于大的业务流程,目的是用业务流把各个孤立的功能点串起来,所以在用场景法设计用例时,测试人员必须建立整体业务感觉,避免忽略业务流程要点
    当然,在整理测试用例的过程中,我们也不要忘记使用等价类和边界值方法。

    展开全文
  • 用例场景来测试需求是指模拟特定场景边界发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现需求中存在的问题。 场景法一般包含了基本流和备选流两种: 基本流:很顺利的操作了一遍系统的...

    用例设计法——场景法[模拟用户使用场景]

    若文章存在不理解或者错误的地方,欢迎留言指出

    定义

    场景法:通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现需求中存在的问题。

    场景法是基于软件业务流程,去模拟用户在实际使用过程的场景,针对用户在实际使用过程中会遇到的各种情况,去判断软件的实际结果与需求是否相符*(个人理解)

    场景法一般包含了基本流和备选流两种:
    基本流:很顺利的操作了一遍系统的流程,不存在错误操作(实例图的打大黑线,很顺利)
    备选流:不顺利的操作系统,过程中存在错误的操作(实例图中的彩色线,备选流存在重新回到基本流的情况,也存在直接结束用例的情况)

    实例图:
    在这里插入图片描述

    应用场景

    1、从定义不难看出,场景法主要是针对系统的业务流程来进行测试的
    2、通常会先使用场景法对主要业务流程进行测试,当主要业务流程没问题后,再对每个功能模块进行更细节的测试

    步骤

    1、根据需求分析基本流和备选流
    2、根据基本流和备选流生成不同场景
    3、 对每一个场景生成相应的测试用例
    4. 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测试用例确定测试数据值

    实例分析

    我们还是以QQ为例进行分析,这里举QQ注册后登录的场景:
    1、根据需求可分析出基本流和备选流如下:

    基本流:打开QQ——注册账号——登录账号——显示QQ界面
    备选流1:注册密码格式错误
    备选流2:注册手机号输入错误
    备选流3:登录账号不存在
    备选流4:登录密码输入错误

    2、根据流生成场景:

    场景
    场景1 :正常登录基本流
    场景2 :密码格式错误基本流,备选流1
    场景3 :手机号格式错误基本流,备选流2
    场景4:账号不存在基本流,备选流3
    场景5:登录密码错误基本流, 备选流4

    3、对每个场景生成测试用例
    通过从确定执行用例场景所需的数据元素入手构建矩阵。然后,对于每个场景,至少要确定包含执行场景所需的适当条件的测试用例。例如,在下面的矩阵中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流。下表中使用的“n/a”(不适用)表明这个条件不适用于测试用例。

    用例ID场景注册密码手机号登录账号登录密码预期结果
    1场景1 :正常登录VVVV登录成功
    2场景2 :密码输入错误In/an/an/a密码格式错误
    3场景3 :手机号格式错误n/aIn/an/a手机号格式错误
    4场景4:账号不存在VVIn/a账号不存在
    5场景5:登录密码错误VVVI登录密码错误

    4、对每一个测试用例确定测试数据值

    用例ID场景注册密码手机号登录账号登录密码预期结果
    1场景1 :正常登录qwe123451380441122110249qwe12345登录成功
    2场景2 :密码输入错误123n/an/an/a密码格式错误
    3场景3 :手机号格式错误n/a123n/an/a手机号格式错误
    4场景4:账号不存在qwe12345138044112211n/a账号不存在
    5场景5:登录密码错误qwe123451380441122110249qwe登录密码错误

    注意:我这里只是简单的举下例子哈,其实也可以进一步补充一些断网的场景,异地登录的场景。个人感觉场景法在测试用例的设计中使用最广吧,不过这里建议用思维导图的形式去写,这样感觉效率上来讲更高一些,然后再通过思维导图转化成用例。

    展开全文
  • 参与者:具有某些行为的人或事物。...用例:一组相关的成功和失败的场景集合。 场景用例中的某条执行路径。 用例模型:用例的集合 比如: 用例:退货 场景1:退货成功 场景2:退货失败...
    参与者:具有某些行为的人或事物。如上一章中的收银员。
    |_主要参与者:收银员。
    |_协助参与者:程序(自动付费、帮收银员验证输入要素)
    |_幕后参与者:政府等(电子签章取证找公证机构)
    用例:一组相关的成功和失败的场景集合。
    场景:用例中的某条执行路径。
    用例模型:用例的集合

     

     

    比如:

    用例:退货

    场景1:退货成功

    场景2:退货失败时怎么办

     

    用例不是面向对象的。但是OOA/D的关键输入。

     

    用例解决的问题是:“谁使用系统?”、“目的是什么?”、“他们使用的典型场景是什么?”

     

    下一节:UML-6.3-用例-详述示例

    转载于:https://www.cnblogs.com/yaoyuan2/p/10772793.html

    展开全文
  • 测试用例设计方法与举例说明

    千次阅读 2019-03-05 13:28:00
    黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。 (一)等价类划分法 定义:等价类划分法是把所有可能输入的数据,即程序的...

    转载自---https://www.cnblogs.com/molrang/p/6420918.html

    黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。

    (一)等价类划分法

    定义:等价类划分法是把所有可能输入的数据,即程序的输入域划分策划国内若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。

    等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其他值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分有两种不同的情况:有效等价类和无效等价类。

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

    无效等价类 指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能多个。

     

    划分标准:

    1) 完备测试、避免冗余

    2) 划分等价类重要的是:集合的划分、划分为互不相交的一组子集,而子集的并是整个集合

    3) 并是整个集合:备性

    4) 子集互不相交:保证一种形式的无冗余性

    5) 同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到“相同的执行路径”。

     

    划分方法:

    1)  在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如:输入值是学生成绩,范围是0~100;

    2)在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类:

    3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。布尔量是一个二值枚举类型, 一个布尔量具有两种状态: true 和 false 。

    4)在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

      例:输入条件说明学历可为:专科、本科、硕士、博士四种之一,则分别取这四种的四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类。

    5)在规定了输入数据必须遵守的规则情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则);

    6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应在将该等价类进一步的划分为更小的等价类。

     

    转化为测试用例:

    在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例:

    1)为每一个等价类规定一个唯一的编号;

    2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;

    3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。

     

    实例1:三角形问题

    某程序规定:“输入三个整数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形、等边三角形时,分别做计算。。。”用等价类划分方法为该程序进行测试用例设计。

    分析题目中给出和隐含的对输入条件的要求:

    1)整数  (2)三个数(3)非零数(4)正数

    5)两边之和大于第三边(6)等腰  (7)等边

    如果a、b、c满足条件(1)~(4),则输出下列四种情况之一:

    1)如果不满足条件(5),则程序输出为“非三角形”

    2)如果三条边相等即满足条件(7),则程序输出为“等边三角形”

    3)如果只有两条边相等,及满足条件(6),则程序输出为“等腰三角形”

    4)如果三条边都不相等,则程序输出为“一般三角形”

    列出等价类表并编号

    覆盖有效等价类的测试用例:

    a b c覆盖等价类号码

    3 4 5 (1)  (7)

    4 4 5  (1)(7)  (8)

    4 5 5 (1)  (7)  (9)

    5 4 5 (1)  (7)  (10)

    4 4 4 (1)  (7)  (11)

    覆盖无效等价类的测试用例:

    覆盖有效等价类的测试用例:

    a b c覆盖等价类号码

    3 4 5 (1)  (7)

    4 4 5  (1)(7)  (8)

    4 5 5 (1)  (7)  (9)

    5 4 5 (1)  (7)  (10)

    4 4 4 (1)  (7)  (11)

    覆盖无效等价类的测试用例:

    实例2,NextDate

    NextDate函数包含三个变量:month、day、year,函数的输出为输入日期后一天的日期。

    例如,输入2006年3月7日,则函数的输出为2006年3月8日。要求输入变量month、day、year均为整数值,并且满足下列条件:

    1、1<=month<=12

    2、1<=day<=31

    3、1812<=year<=2012

    1)有效等价类为:

    M1={月份:1<=月份<=12}

    D1={日期:1<=日期<=31}

    Y1={年份:1812<=年<=2012}

    2)若条件1~3中任何一个条件失效,则NextDate函数都会产生一个输出,指明相应的变量超出取值范围,比如“month的值不在12范围中”。显然还存在这大量的year、month、day的无效组合,NextDate函数将这些组合作为统一的输出:“无效输入日期”。

    其无效等价类为:

    M2={月份:月份<1}

    M3={月份:月份>12}

    D2={日期:日期<1}

    D3={日期:日期>31}

    Y2={年份:年<1812}

    Y3={年份:年>2012}

    弱一般等价类测试用例

    月份

    日期

    预期输出

    6

    15

    1912

    1912年6月16日

     

    强一般等价类测试用例同弱一般等价类测试用例

    注:弱有单缺陷假设;健壮考虑了无效值。

    (一)弱健壮等价类测试

    用例

    ID

    月份

    日期

    预期输出

    WR1

     

    6

    15

    1912

    1912年6月16日

    WR2

     

    0

    1

    1912

    月份不在1~12中

    WR3

     

    15

    1

    1912

    月份不在1~12中

    WR4

     

    1

    0

    1912

    日期不在1~31中

    WR5

     

    1

    32

    1912

    日期不在1~31中

    WR6

     

    1

    1

    1811

    年不在1812~2012中

    WR7

     

    1

    1

    2013

    年不在1812~2012中

    (二)强健壮等价类测试

    用例

    ID

    月份

    日期

    预期输出

    SR1

     

    15

    1

    1912

    月份不在1~12中

    SR2

     

    1

    32

    1912

    日期不在1~31中

    SR3

     

    1

    1

    1811

    年份不在1812~2012中

    SR4

     

    0

    0

    1912

    两个无效一个有效

    SR5

     

    0

    1

    1811

    两个无效一个有效

    SR6

     

    1

    0

    1811

    两个无效一个有效

    SR7

     

    0

    0

    1811

    三个无效

     

    (二)边界值分析法

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

    与等价类区别:

    1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。

    2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

    分析方法:

    大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

    常见边界值:

     1)对16Bit的整数而言,32767和32768是边界

     2)屏幕上光标在最左上、最右下位置

     3)报表的第一行和最后一行

     4)数组元素的第一个和最后一个

     5)循环的第0次、第1次和倒数第2次、最后一次

     

    边界值分析:

    1)边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,因此在等价类的边界上以及两侧的情况设计测试用例。

           例:测试计算平方根的函数

           输入:实数

           输出:实数

    规格说明:当输入一个0或比0大的数的时候,返回其正平方根;当输入一个小于0的数时,显示错误信息“平方根非法,输入值小于0”并返回0;库函数printLine可以用来输出错误信息。

           2)等价类划分:

              i.              可以考虑做出如下划分:

    A、输入(i)<0 和(ii)>=0

    B、输出(a)>=0和(b)Error

            ii.              测试用例有两个

    A、输入4,输出2.对应(ii)和(a)。

    B、输入10,输出0和错误提示。对应与(i)和(b)

           3)边界值分析

           划分(ii)的边界为0和最大正实数;划分(i)的边界为最小负实数和0.由此得到一下测试用例:

           A、输入{最小负实数}

           B、输入{绝对值很小的负数}

           C、输入0

           D、输入{绝对值很小的正数}

           E、输入{最大正实数}

           4)通常情况下,软件测试所包含的边界检验有几种类型:数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

           5)相应地,以上类型的边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下。

           6)利用边界值作为测试数据

    边界值

    测试用例的设计思路

    字符

    起始1个字符/结束+1个字符

    假设一个文本输入区域允许输入1个到255个字符,输入1个和255个字符作为有效等价类;输入0个和256个字符作为无效等价类,这几个数值都属于边界条件值

    数值

    最小值1/最大值+1

    假设某软件的数据输入域要求输入5位的数据值,可以使用10000作为最小值、9999作为最大值;然后使用刚好小于5位和大于5位的数值作为边界条件。

    空间

    小于空余空间一点/大于满空间一点

    例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件作为边界条件

           7)内部边界值分析

           在多数情况下,边界值条件是基于应用程序的功能设计而需要考虑的因素,可以从软件的规格说明或常识中得到,也是最终用户可以很容易发现问题的。然而,在测试用例设计过程中,某些边界值条件是不需要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件。

           内部边界值条件主要有下面几种:

    1)数值的边界值检验:计算机是基于二进制进行工作的,因此,软件的任何数值运算都有一定的范围限制。

    范围或值

    位(Bit)

    0或者1

    字节(byte)

    0~255

    字(Word)

    0~65535(单字)或0~4294967295(双字)

    千(K)

    1024

    兆(M)

    1048576

    吉(G)

    1073741824

     

    2)字符的边界值检验:在计算机软件中,字符也是很重要的表示元素,其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

    字符

    ASCII码值

    字符

    ASCII码值

    空(Null)

    0

    A

    65

    空格(Space)

    32

    a

    97

    斜杠(/)

    47

    z

    122

    0

    48

    Z

    90

    冒号(:)

    58

    单引号(’)

    96

    @

    64

     

     

     

    3)其它边界值检验:在不同的行业应用领域,依据硬件和软件的标准不同而具有各自特定的边界值。如下列出部分手机相关的边界值:

    硬件设备

    范围或值

    手机锂电池电压

    工作电压:3.6~4.2V;

    保护电压:2.5~3V不等

    手机正常使用温度

    -25°C~+60°C

     

    转化为测试用例:

    1)    如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

    Ø  例如,如果程序的规格说明中规定:"重量在10公斤至50公斤范围内的邮件,其邮费计算公式为……"。作为测试用例,我们应取10及50,还应取10.01,49.99,9.99及50.01等。

    2)    如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

    Ø  例如,一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。

    3)    将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。

    Ø  例如,某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元",其测试用例可取0.00及1165.24、还可取一0.01及1165.26等。

    Ø  再如一程序属于情报检索系统,要求每次"最少显示1条、最多显示4条情报摘要",这时我们应考虑的测试用例包括1和4,还应包括0和5等。

    4)    如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

    5)    如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

    6)    分析规格说明,找出其它可能的边界条件。

     

    实例1,批阅试卷

    现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

     

     

    1) 标题:这一组只有一个记录,其内容为输出成绩报告的名字。

    2) 试卷各题标准答案记录:每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。

    3) 每个学生的答卷描述:该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。

    4) 学生人数不超过200,试题数不超过999。

    5) 程序的输出有4个报告:
        a)按学号排列的成绩单,列出每个学生的成绩、名次。
        b)按学生成绩排序的成绩单。
        c)平均分数及标准偏差的报告。
        d)试题分析报告。按试题号排序,列出各题学生答对的百分比。

    解答:分别考虑输入条件和输出条件,以及边界条件。给出下表所示的输入条件及相应的测试用例。

     
              输出条件及相应的测试用例表。

     

    实例2,三角形的边界问题分析测试用例

    在三角形问题描述中,除了要求边长是整数外,没有给出其它的限制条件。在此,我们将三角形每边边长的取范围值设值为[1, 100]。
     

    测试用例

    a

    b

    c

    预期输出

    Test1

    Test2

    Test3

    Test4

    Test5

    60

    60

    60

    50

    50

    60

    60

    60

    50

    50

    1

    2

    60

    99

    100

    等腰三角形

    等腰三角形

    等边三角形

    等腰三角形

    非三角形

    Test6

    Test7

    Test8

    Test9

    60

    60

    50

    50

    1

    2

    99

    100

    60

    60

    50

    50

    等腰三角形

    等腰三角形

    等腰三角形

    非三角形

    Test10

    Test11

    Test12

    Test13

    1

    2

    99

    100

    60

    60

    50

    50

    60

    60

    50

    50

    等腰三角形

    等腰三角形

    等腰三角形

    非三角形

     

    实例3,NextDate函数边界值分析测试用例

    在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为1912≤year≤2050。

     

    (三)错误推测法

    定义:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。

    基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

    1.     例如,输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

     

    2.     例如,前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例:

    1)     程序是否把空格作为回答

    2)     在回答记录中混有标准答案记录

    3)     除了标题记录外,还有一些的记录最后一个字符即不是2也不是3

    4)     有两个学生的学号相同

    5)     试题数是负数

     

    3.     例如,测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:

    1)    输入的线性表为空表;

    2)    表中只含有一个元素;

    3)    输入表中所有元素已排好序;

    4)    输入表已按逆序排好;

    5)    输入表中部分或全部元素相同。

     

    4.     例如,测试手机终端的通话功能,可以设计各种通话失败的情况来补充测试用例:

    1)    无SIM 卡插入时进行呼出(非紧急呼叫)

    2)    插入已欠费SIM卡进行呼出

    3)    射频器件损坏或无信号区域插入有效SIM卡呼出

    4)    网络正常,插入有效SIM卡,呼出无效号码(如1、888、333333、不输入任何号码等)

    5)    网络正常,插入有效SIM卡,使用“快速拨号”功能呼出设置无效号码的数字

     

    (四)因果图法

    定义:因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

    应用:

    等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。

    如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。

    1.     因果图介绍

    1)    4种符号分别表示了规格说明中向4种因果关系。

    2)    因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。

    3)    C1表示原因,通常置于图的左部;e1表示结果,通常在图的右部。C1和e1均可取值0或1,0表示某状态不出现,1表示某状态出现。

    2.     因果图涉及的概念

    1)    关系

    Ø 恒等:若c1是1,则e1也是1;否则e1为0。

    Ø 非:若c1是1,则e1是0;否则e1是1。

    Ø 或:若c1或c2或c3是1,则e1是1;否则e1为0。“或”可有任意个输入。

    Ø 与:若c1和c2都是1,则e1为1;否则e1为0。“与”也可有任意个输入。

    2)    约束

    输入状态相互之间还可能存在某些依赖关系,称为约束。例如,某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

    Ø 输入条件的约束有以下4类:

    ·        E约束(异):a和b中至多有一个可能为1,即a和b不能同时为1。

    ·        I约束(或):a、b和c中至少有一个必须是1,即 a、b 和c不能同时为0。

    ·        O约束(唯一);a和b必须有一个,且仅有1个为1。

    ·        R约束(要求):a是1时,b必须是1,即不可能a是1时b是0。

    Ø 输出条件约束类型

                   输出条件的约束只有M约束(强制):若结果a是1,则结果b强制为0。

    3.     采用因果图法设计测试用例的步骤:

    1)    分析软件规格说明描述中,那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件),并给每个原因和结果赋予一个标识符。

    2)    分析软件规格说明描述中的语义,找出原因与结果之间,原因与原因之间对应的关系,根据这些关系,画出因果图。

    3)    由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。

    4)    把因果图转换为判定表。

    5)    把判定表的每一列拿出来作为依据,设计测试用例。

     

    实例1,字符

    某软件规格说明书包含这样的要求:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。

    解答:

    1)    根据题意,原因和结果如下:

                 原因:

                 1——第一列字符是A;

                 2——第一列字符是B;

                 3——第二列字符是一数字。

                 结果:

                 21——修改文件;

                 22 ——给出信息L;

                 23——给出信息M。

    2)    其对应的因果图如下:

    11为中间节点;考虑到原因1和原因2不可能同时为1,因此在因果图上施加E约束。

    3)    根据因果图建立判定表。

     

                               表中8种情况的左面两列情况中,原因①和原因②同时为1,这是不可能出现的,故应排除这两种情况。表的最下一栏给出了6种情况的测试用例,这是我们所需要的数据。

     

    实例2,自动售货机

    有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。

    1)    分析这一段说明,列出原因和结果

    原因:

    1——售货机有零钱找

    2——投入1元硬币

    3——投入5角硬币

    4——押下橙汁按钮

    5——.押下啤酒按钮

    结果:

    21——售货机〖零钱找完〗灯亮   

    22——退还1元硬币

    23——退还5角硬币             

    24——送出橙汁饮料

    25——送出啤酒饮料

    2)    画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右边。建立中间结点,表示处理的中间状态。中间结点:

    11—— 投入1元硬币且押下饮料按钮

                    12——押下〖橙汁〗或〖啤酒〗的按钮

                    13——应当找5角零钱并且售货机有零钱找

                    14——钱已付清

    3)    转换成判定表:

     

    4)    在判定表中,阴影部分表示因违反约束条件的不可能出现的情况,删去。第16列与第32列因什么动作也没做,也删去。最后可根据剩下的16列作为确定测试用例的依据。

     

    (五)判定表驱动法

    定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

    优点:能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表适合于处理这类问题。

    阅读指南,判定表:

     

    1

    2

    3

    4

    5

    6

    7

    8

    问题

    觉得疲倦吗?

    Y

    Y

    Y

    Y

     

     

     

     

    感兴趣吗?

    Y

    Y

     

     

    Y

    Y

     

     

    糊涂吗?

    Y

     

    Y

     

    Y

     

    Y

     

    建议

    重读

     

     

     

     

    Y

     

     

     

    继续

     

     

     

     

     

    Y

     

     

    跳下一章

     

     

     

     

     

     

    Y

    Y

    休息

    Y

    Y

    Y

    Y

     

     

     

     

     

    判定表由四部分组成,如下图:

     1)        条件桩(Condition Stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。

    2)        动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

    3)        条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。

    4)        动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。

    规则及规则合并:

    1)  规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

    2)  化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。

    合并举例:

    1)        如下图左端,两规则动作项一样,条件项类似,在1、2条件项分别去Y、N时,无论条件3取何值,都执行同一操作。即要执行的动作与条件3无关。于是可合并。“-”表示与取值无关

     

    2)        与上类似,下图中,无关条件项“-”可包含其他条件项取值,具有相同动作的规则可合并。

     

    3)        

    3)        化简后的读书指南判定表

     

    1

    2

    3

    4

    问题

    觉得疲倦吗?

    -

    -

    Y

    N

    感兴趣吗?

    Y

    Y

    N

    N

    糊涂吗?

    Y

    N

    -

    -

    建议

    重读

    X

     

     

     

    继续

     

    X

     

     

    跳下一章

     

     

     

    X

    休息

     

     

    X

     

    判定表建立步骤:

    1)  确定规则的个数。假如有n个条件,每个条件有两个取值(0,1),故2n种规则。

    2)  列出所有的条件桩和动作桩

    3)  填入条件项

    4)  填入动作项,等到初始判定表

    5)  简化,合并相似规则(相同动作)

     

    实例1,机器维修

    问题要求:“。。。。。。对功率大于50马力的机器,维修记录不全或已运行10以上的机器,应给予优先的维修处理。。。。。。”,这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义。请建立判定表。

    解答:

    1、确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。

    2、列出所有的条件桩和动作桩:

    条件

    功率大于50马力吗?

    维修记录不全吗?

    运行超过10年吗?

    动作

    进行优先处理

    3、填入条件项。可从最后1行条件项开始,逐行向上填满。

    4、填入动作桩和动作项。这样便得到如下图的初始判定表

     

     

     

     

     

     

     

     

     

     

    条件

     

    1

    2

    3

    4

    5

    6

    7

    8

    功率大于50马力吗?

    Y

    Y

    Y

    Y

    N

    N

    N

    N

    维修记录不全吗?

    Y

    Y

    N

    N

    Y

    Y

    N

    N

    运行超过10年吗?

    Y

    N

    Y

    N

    Y

    N

    Y

    N

    工作

    进行优先处理

    X

    X

    X

     

    X

     

    X

     

    作其它处理

     

     

     

    X

     

    X

     

    X

    5、

    初始判定表化简。合并相似规则后得到

     

     

     

     

     

     

     

    条件

     

    1

    2

    3

    4

    5

    功率大于50马力吗?

    Y

    Y

    Y

    N

    N

    维修记录不全吗?

    Y

    N

    N

    -

    -

    运行超过10年吗?

    -

    Y

    N

    Y

    N

    工作

    进行优先处理

    X

    X

     

    X

    X

    作其它处理

     

     

    X

     

    X

     

    实例2,NextData函数的精简决策表

    M1={月份, 每月有30天}

    M2={月份, 每月有31天}

    M3={月份, 2月}                 有29=512条规则

    D1={日期,1~28}                 12月末31日和其它31

    D2={日期,29}                    日月份的31日处理不同

    D3={日期,30}                    平年2月28日处理不同

    D4={日期,31}                    于2月27日

    Y1 ={年:年是闰年}

    Y2 ={年:年不是闰年}

    改进为:

    M1={月份: 每月有30天}

    M2={月份: 每月有31天, 12月除外}

    M4={月份:12月}

    M3={月份: 2月}

    D1={日期:1<=日期<=27}

    D2={日期:28}

    D3={日期:29}

    D4={日期:30}

    D5={日期:31}

    Y1 ={年:年是闰年}

    Y2 ={年:年不是闰年}

    输入变量间存在大量逻辑关系的NextData决策表

     

     

    3.     用决策表测试法测试以下程序:该程序有三个输入变量month、day、year(month、day和year均为整数值,并且满足:1≤month≤12和1≤day≤31),分别作为输入日期的月份、日、年份,通过程序可以输出该输入日期在日历上隔一天的日期。

    例如,输入为2004年11月29日,则该程序的输出为2000年12月1日。

    1)    分析各种输入情况,列出为输入变量month、day、year划分的有效等价类。

    2)    分析程序规格说明,结合以上等价类划分的情况给出问题规定的可能采取的操作(即列出所有的动作桩)。

    3)    根据(1)和(2),画出简化后的决策表。

    案例分析如下:

    Ø  month变量的有效等价类:

    M1: {month=4,6,9,11}              M2: {month=1,3,5,7,8,10}

    M3: {month=12                       }M4: {month=2}

    Ø  day变量的有效等价类:

    D1:{1≤day≤26}                        D2: {day=27}                D3: {day=28}               D4: {day=29}                             D5: {day=30}                D6: {day=31}

    Ø  year变量的有效等价类:

    Y1: {year是闰年}                       Y2:  {year不是闰年}

    4)    考虑各种有效的输入情况,程序中可能采取的操作有以下六种:

    a1: day+2                                 a2: day=2                     a3: day=1

    a4: month+1                            a5: month=1                a6: year+1 

    4.     判定表在功能测试中的应用

    1)    一些软件的功能需求可用判定表表达得非常清楚,在检验程序的功能时判定表也就成为一个不错的工具。如果一个软件的规格说明指出:

    Ø  当条件1和条件2满足,并且条件3和条件4不满足,或者当条件1、3和条件4满足时,要执行操作1。

    Ø  在任一个条件都不满足时,要执行操作2。

    Ø  在条件1不满足,而条件4被满足时,要执行操作3。 根据规格说明得到如下判定表:

    这里,判定表只给出了16种规则中的8种。事实上,除这8条以外的一些规则是指当不能满足指定的条件,执行3种操作时,要执行1个默许的操作。在没必要时,判定表通常可略去这些规则。但如果用判定表来设计测试用例,就必须列出这些默许规则(如下表)。

    规则5

    规则6

    规则7

    规则8

    条件1

    -

    N

    Y

    Y

    条件2

    -

    Y

    Y

    N

    条件3

    Y

    N

    N

    N

    条件4

    N

    N

    Y

    -

    默许操作

    x

    x

    x

    x

    默许的规则 

    2)    判定表的优点和缺点

    Ø  优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。

    Ø  缺点:不能表达重复执行的动作,例如循环结构。

    3)    B. Beizer 指出了适合使用判定表设计测试用例的条件:

    Ø  规格说明以判定表形式给出,或很容易转换成判定表。

    Ø  条件的排列顺序不会也不影响执行哪些操作。

    Ø  规则的排列顺序不会也不影响执行哪些操作。

    Ø  每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。

    Ø  如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

    B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。

     

     (六)正交试验法

    定义:从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.

     

    利用正交实验设计测试用例的步骤:

    1.     提取功能说明,构造因子--状态表

    把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试用例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。

    2.     加权筛选,生成因素分析表

    对因子与状态的选择可按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。

    3.     利用正交表构造测试数据集

    正交表的推导依据Galois理论(这里省略,需要时可查数理统计方面的教材)。

    利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。

     

    (七)功能图法

    定义:功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置(或时间),而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。

    应用:

    1.    功能图介绍

    一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.

    静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例.

    功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

    (功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.)

    2.    测试用例生成方法

    从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例. 若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题(如白盒测试)问题了.

    3.    测试用例生成规则

    为了把状态迁移(测试路径)的测试用例与逻辑模型(局部测试用例)的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移(SST)中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.(其表示图形省略)。

    4.    从功能图生成测试用例的过程

    1)    生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。

    2)    测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。

    3)    测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

    5.    测试用例的合成算法:采用条件构造树.

     

    (八)场景图法

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

    应用:

    基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。

     

    9.3.             实例

     

    1.     例子描述

    下图所示是ATM例子的流程示意图。

     

     

     

    2.    场景设计:下表所示是生成的场景。

    表3-8 场景设计

    场景1——成功提款

    基本流

    场景2——ATM内没有现金

    基本流

    备选流2

    场景3——ATM内现金不足

    基本流

    备选流3

    场景4——PIN有误(还有输入机会)

    基本流

    备选流4

    场景5——PIN有误(不再有输入机会)

    基本流

    备选流4

    场景6——账户不存在/账户类型有误

    基本流

    备选流5

    场景7——账户余额不足

    基本流

    备选流6

    注:为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。

    3.    用例设计

    对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。

    表3-9 测试用例表

       

    TCID

    场景/条件

    PIN

    账号

    输入(或选择)的金额

    账面

    金额

    ATM内的金额

    预期结果

    CW1

    场景1:成功提款

    V

    V

    V

    V

    V

    成功提款

    CW2

    场景2:ATM内没有现金

    V

    V

    V

    V

    I

    提款选项不可用,用例结束

    CW3

    场景3:ATM内现金不足

    V

    V

    V

    V

    I

    警告消息,返回基本流步骤6,输入金额

    CW4

    场景4:PIN有误(还有不止一次输入机会)

    I

    V

    n/a

    V

    V

    警告消息,返回基本流步骤 4,输入 PIN

    CW5

    场景4:PIN有误(还有一次输入机会)

    I

    V

    n/a

    V

    V

    警告消息,返回基本流步骤 4,输入 PIN

    CW6

    场景4:PIN有误(不再有输入机会)

    I

    V

    n/a

    V

    V

    警告消息,卡予保留,用例结束

     

    4.    数据设计

    一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。

    测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。

    表3-10   测试用例表

    TCID

    场景/条件

    PIN

    账号

    输入(或选择)的金额(元)

    账面
    金额(元)

    ATM内的金额(元)

    预期结果

    CW1

    场景1:成功提款

    4987

    809-498

    50.00

    500.00

    2 000

    成功提款。账户余额被更新为450.00

    CW2

    场景2:ATM内没有现金

    4987

    809-498

    100.00

    500.00

    0.00

    提款选项不可用,用例结束

    CW3

    场景3:ATM内现金不足

    4987

    809-498

    100.00

    500.00

    70.00

    警告消息,返回基本流步骤6,输入金额

    CW4

    场景4:PIN有误(还有不止一次输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,返回基本流步骤4,输入PIN

    CW5

    场景4:PIN有误(还有一次输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,返回基本流步骤4,输入PIN

    CW6

    场景4:PIN有误(不再有输入机会)

    4978

    809-498

    n/a

    500.00

    2 000

    警告消息,卡予保留,用例结束

     

     

    测试用例设计综合策略

    1.    Myers提出了使用各种测试方法的综合策略:

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

      2)    必要时用等价类划分方法补充一些测试用例。

      3)    用错误推测法再追加一些测试用例。

      4)    对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例。

      5)    如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。

    2.    测试用例的设计步骤

      1)    构造根据设计规格得出的基本功能测试用例;

      2)    边界值测试用例;

      3)    状态转换测试用例;

      4)    错误猜测测试用例;

      5)    异常测试用例;

      6)    性能测试用例;

      7)    压力测试用例。

    3.    优化测试用例的方法

      1)    利用设计测试用例的8种方法不断的对测试用例进行分解与合并;

      2)    采用遗传算法理论进化测试用例;

      3)    在测试时利用发散思维构造测试用例;

    转载于:https://www.cnblogs.com/yao-zhang/p/10476145.html

    展开全文
  • 众所周知,测试用例是编制的一组测试输入、...当然测试用例的设计方法不止这些,下面只是通过举例说明着重讲讲这常用的五种方法。一、正交实验法用语言描述正交实验法会很抽象难懂,简单说,就是在各因素互相独立...
  • 场景法主要用于测试软件的业务过程或业务逻辑,是一种基于软件业务和用户行为的测试方法。1.概念:前几篇讨论的...场景法运用场景对系统的功能点或业务流程进行描述,然后设计测试用例,从而提高了对系统主要功能和...
  • 这种在软件设计方面的思想可以引入到软件测试中,可以生动地描绘出事件触发时的情景,有利于设计测试用例,同时使测试用例更容易理解和执行。 在测试一个软件的时候,在场景法中,测试流程是软件功能按照正确的事件...
  • 一、等价类划分法 1.概念:等价类划分法是一种典型的、重要的黑盒测试方法,是指某个输入域的子集。...设计一个新的测试用例(数据),使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆
  • 性能测试的用例场景

    千次阅读 2018-05-08 19:22:39
    脚本模板 场景模板 性能测试工具选择 1. 数据建模工具 DataFactory是一种强大的数据产生器,它允许开发人员和QA很容易产生百万行有意义的正确的测试数据库,该工具支持DB2、Oracle、 Sybase、SQL Server数据库,...
  • 备选的用例场景,异常的用例场景,假定推测的场景。 二、基本流备用流: 上图为,用例基本流和备选流(注意:备选流的起止点) 基本流:采用直黑线表示,是经过用例的最简单的路径(无任何差错,程序从...
  • 该篇文章我自己至少读了有5遍,写的非常好,...而测试用例的设计一直是软件测试工作的重点和难点,那么什么是测试用例?为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据,称之为测试用例。我...
  • 测试用例概要

    2021-05-05 19:01:08
    测试用例概念和作用 1.定义 是为某个业务目标,而编制的一组由测试输入,执行条件以及预期结果组成的案例。 2.作用 在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试...
  • 这时候就要用到场景法来设计测试用例,也就是说场景法主要是针对业务流程来设计测试用例的。 现在的软件几乎都是通过事件触发来控制流程的,事件触发时的场景便形成了场景,而同一事件不同的触发顺序和处理结果就...
  • 前言 写测试用例,是测试绕不开的工作内容,不管是功能、自动化,还是...性能测试用例(有的称为场景用例)的设计,有别于功能测试用例、自动化测试用例的设计,毕竟,考虑的点不一样。对于性能测试来说,一般要考虑这...
  • 软件测试--用例编写

    万次阅读 多人点赞 2018-08-15 18:47:30
    测试用例编写是软件测试的基本技能;也有很多人认为测试用例是软件测试的核心;软件测试中最重要的是设计和生成有效的测试用例;测试用例是测试工作的指导,是软件测试的必须遵守的准则。 在这里我们不讨论以上的...
  • 1.3 场景法 1.4 错误推测法(反推法) 2 等价类划分法 2.1 等价类划分法的概念 等价类划分法是一种典型的、重要的黑盒测试方法,是指某个输入域的子集合。在该子集合中,所有的输入数据对于揭露软件中的错误都是...
  • 业务用例用例的对应关系一般是1对1和1对多最为普遍,但是也可能出现多对1的形式,甚至一些用户业务间交叉过多的业务实现中还可能出现多对1的形式。比如下面这个例子就是2003年底在北航给软工硕士讲课期间产生的...
  • 游戏测试用例

    千次阅读 2021-05-24 11:03:50
    游戏测试用例1. 设计步骤1. 需求文档分析1.1 文档阅读1.2 功能细节沟通探讨1.3 逻辑梳理1.4 功能拓展思考1.5 兼容相关思考2. 功能模块划分2.1 功能模块划分时应遵循什么样的规则?2.2 功能模块划分有哪些比较好的...
  • 一、场景法 一个有关功能流程的测试方法。 在不同的场合(情景)下会测试走向不同的流程。 1.背景 现在的软件都是用事件触发来控制流程,事件触发了就成了场景。 当同一事件有了不同的触发顺序和处理结果时,...
  • 十大异常测试用例(转载)

    千次阅读 2019-05-08 15:06:00
    十大异常测试用例(转载) 此文乃转载,原名为《十大负面测试用例》,我觉得负面测试不如异常测试来的好理解,自己改了改。恩,先说一说我自己的心得。前八个用例都是原来已经在我的思维体系中的,...
  • 编写测试用例的方法

    2020-12-16 20:48:13
    一、首先我们来说一下编写测试用例的好处有哪些? 总结一下有以下几点 (1)设计好测试用例,可以避免盲目测试并提高测试效率。 (2)测试用例的使用令软件测试的实施重点突出、目的明确。 (3)降低了工作强度、缩短项目...
  • 描述测试用例及例子

    千次阅读 2018-05-31 16:43:25
    一.概念 1.什么是测试用例? 在测试过程中很重要的一类文档,它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。...用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、...
  • 测试用例设计方法

    千次阅读 多人点赞 2019-03-20 16:41:26
    注意,规则1、2列是不可能同时出现的,排除,简化后即为测试用例 1.5 其他黑盒测试方法 随机测试、 错误推测、 场景测试、 综合测试 上面介绍的是比较常用的测试方法,至于这些测试方法这里就不一一介绍啦(偷懒) ...
  • 软件测试用例的设计

    2021-07-28 01:29:28
    关键词:等价类划分法 边界值分析法 因果图法 判定表驱动分析法 场景法一、等价类划分法(1)设计测试用例在确立了等价类后(等价类中元素的处理方式不同时,需要进一步划分),可建立等价类表,列出所有划分出的等价类...
  • 功能测试用例设计方法分享

    千次阅读 热门讨论 2020-12-15 16:32:45
    测试用例可以用来衡量一个项目测试质量,因此在平时的测试流程中,编写测试用例就是测试过程中很重要的一步,每一个测试工程师都需要并且非常熟练的编写测试用例,能在编写测试用例中尽可能的覆盖任何异常的测试点;...
  • 前言 写测试用例,是测试绕不开的工作内容,不管是功能、自动化,还是...性能测试用例(有的称为场景用例)的设计,有别于功能测试用例、自动化测试用例的设计,毕竟,考虑的点不一样。对于性能测试来说,一般要考虑这...
  • 只供参考,喜欢请支持正版图书 3.3 用例 用例在UML建模中是最最重要的一个元素。...而用例正是施加这一“外力”的元素,正是用例使得其他那些“孤独”的UML元素能够共同组成一篇有意义的文字。...
  • 什么才算好的测试用例

    万次阅读 多人点赞 2018-12-16 20:14:21
    对于测试用例来讲,“好的”测试用例一定是一个完备的集合,能够覆盖所有的等价类以及各种边界值,而跟能否发现缺陷无关。 如果把测试软件看做一个池塘,软件缺陷是池塘中的鱼,建立测试用例集的过程就像是在编织...
  • 测试用例设计思路

    2021-08-27 22:34:50
    测试用例编写思路: 首先是明确测试范围: 功能测试 界面测试(界面友好性、易用性、一致性) 兼容性测试(不同类型、型号手机、系统(手机系统、桌面系统)、分辨率、浏览器及其版本) 性能测试(页面加载时间...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,146
精华内容 2,458
关键字:

举例说明用例、场景

友情链接: SkinFormDemo.rar