精华内容
下载资源
问答
  • 该方法是一种重要的,常用的黑盒测试用例设计方法。 2.划分等价类: 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一...
  • 黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。(一)等价类划分法定义:等价类划分法是把所有可能输入的数据,即程序的输入域...
  • 软件测试中的测试用例设计方法场景VS功能1、目的不管我们在做哪些测试我想第一我们要站在用户的角度,以用户的使用逻辑及操作习惯为出发点,结合功能用例的设计方法,使用例设计更符合用户使用逻辑更具有可执行性,...
  • 测试用例设计方法

    2019-05-09 22:05:22
    测试设计方法,详细讲解边界值、等价类划分、状态转移、因果图、判定表的设计方法和技巧
  • 软件测试中黑盒测试用例设计方法总结测试用例(TestCase)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。 测试用例(TestCase)目前没有经典的...
  • 1.定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,...使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就
  • 测试用例设计方法之组合测试法中的全对偶测试法.在测试设计过程中,大家都会遇到很多变量进行组合的情况,对相互组合的两个或更多变量进行的测试活动就是组合测试,一般情况下都是使用组合测试法  在测试设计过程中...
  • 黑盒测试的测试用例设计方法软件测试 一、黑盒测试的测试用例设计方法 1.等价类划分方法 2.边界值分析方法 3.错误推测方法 4.因果图方法 5.判定表驱动分析方法 6.正交实验设计方法 7.功能图分析方法 二、...
  • 软件测试之黑盒测试用例设计方法课程资源PPT,谢谢您的下载!
  • 定义:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例方法。2.错误推测方法的基本思想:  错误推测方法  一.方法简介  1.定义:基于经验和直觉推测程序中所有可能存在的各种错误,...
  • 比较全测试用例设计方法总结与大家分享,希望提出更好的建议!
  •  2、使用者  用例设计、执行及热爱测试的人员  3、测试用例设计方法  按照不同的规则可以将测试用例分为四个部分:场景用例(用户场景)、系统用例(用户场景的细化)、功能用例(基于业务规则、界面)、设计指标...
  • 软件测试用例编写方法
  • 由于对软件测试用例的作用和设计方法的理解不同,测试人员对软件测试用例存在不少片面的认识,具体表现在以下三个方面:(1)测试输入数据设计方法等同于测试用例设计方法一些测试书籍和文章经常这样表述:测试用例的...
  • 软件测试中浅谈黑盒测试的测试用例设计方法在软件测试中目前黑盒测试的测试用例设计方法有5种:等价类划分边界值分析错误推测法因果图功能图一、等价类划分等价列划分设计方法是把所有可能的输入数据,即程序的输入...
  • 软件测试中测试用例设计方法场景VS功能1、目的站在用户的角度,以用户的使用逻辑及操作习惯为出发点,结合功能用例的设计方法,使用例设计更符合用户使用逻辑更具有可执行性,从而最大程度上覆盖用户需求。...
  • 里面列举了有关测试用例的几种设计方法,希望有帮助。
  • 软件测试中黑盒测试的测试用例设计方法/软件测试的14种类型等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,...
  • 【测试】黑盒测试用例设计方法

    万次阅读 多人点赞 2019-06-03 13:27:39
    黑盒测试用例设计方法包括: 1、等价类划分法、 2、边界值分析法、 3、错误推测法、 4、因果图法、 5、判定表驱动法、 6、正交试验设计法、 7、功能图法、 8、场景法等。 9、状态迁移法 10、流程分析法 ...

     黑盒测试用例设计方法包括:

    1、等价类划分法、

    2、边界值分析法、

    3、错误推测法、

    4、因果图法、

    5、判定表驱动法、

    6、正交试验设计法、

    7、功能图法、

    8、场景法等。 

    9、状态迁移法

    10、流程分析法

    11、逐级细分法

    12、输入域分析法

    13、输出域分析法

    14、异常分析

     

     

    1. 等价类划分法

     

    1. 概念

    等价类划分法是把程序的输入域划分成若干部分(子集),然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

    1. 等价类划分法的应用
    1. 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类。
    1. 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
    2. 无效等价类:与有效等价类的定义恰巧相反。
    3. 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。
    1. 划分等价类的六大原则:

    在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

    例:输入值是学生成绩,范围是0~100:

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case1.jpg

    • 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
    • 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类. 布尔量是一个二值枚举类型, 一个布尔量具有两种状态: true 和 false 。
    • 在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

    例:输入条件说明输入字符为:中文、英文、阿拉伯文三种之一,则分别取这三种这三个值作为三个有效等价类,另外把三种字符之外的任何字符作为无效等价类。

    • 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
    • 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类
    • 将等价类转化成测试用例:
    • 按照[输入条件][有效等价类][无效等价类] 建立等价类表,列出所有划分出的等价类
    • 为每一个等价类规定一个唯一的编号.
    • 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
    • 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.
    1. 等价类划分实例
    1. 某程序规定:"输入三个整数 a b c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。)

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

    1)整数    2)三个数    3)非零数   4)正数  
    5)两边之和大于第三边     6)等腰     7)等边
     如果 a b c 满足条件( 1 ~ 4 ),则输出下列四种情况之一:
     1)如果不满足条件(5),则程序输出为 " 非三角形 "
     2)如果三条边相等即满足条件(7),则程序输出为 " 等边三角形 "
     3)如果只有两条边相等、即满足条件(6),则程序输出为 " 等腰三角形 "
     4)如果三条边都不相等,则程序输出为 " 一般三角形 "
     列出等价类表并编号

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case2.jpg

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

    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

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

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case3.jpg

    1. 设有一个档案管理系统,要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。(不考虑2月的问题)

    1)划分等价类并编号,下表等价类划分的结果

    输入等价类

    有效等价类

    无效等价类

    日期的类型及长度

    6位数字字符

    有非数字字符

    少于6位数字字符

    多于6位数字字符

    年份范围

    1990~2049之间

    小于1990

    大于2049

    月份范围

    01~12之间

    等于00

    大于12

    2)设计测试用例,以便覆盖所有的有效等价类在表中列出了3个有效等价类,编号分别为①、⑤、⑧,设计的测试用例如下:

    测试数据    期望结果      覆盖的有效等价类
    200211      输入有效      、⑤、⑧
    3)为每一个无效等价类设计一个测试用例,设计结果如下:
        测试数据   期望结果     覆盖的无效等价类
        95June     无效输入         
        20036      无效输入          
        2001006   无效输入         
        198912     无效输入         
        200401     无效输入         
        200100     无效输入         
        200113     无效输入         

    1. NextDate 函数包含三个变量:month day year ,函数的输出为输入日期后一天的日期。 例如,输入为 20063 7日,则函数的输出为 200638 。要求输入变量 month day year 均为整数值,并且满足下列条件:
        1≤month≤12
       
      1≤day≤31
       
      1812≤year≤2012 
      1)
      有效等价类为:
          M1{月份:1≤月份≤12}
          D1
      {日期:1≤日期≤31}
          Y1
      {年:1812≤≤2012}
      2)
      若条件 ~ 中任何一个条件失效,则 NextDate 函数都会产生一个输出,指明相应的变量超出取值范围,比如 "month 的值不在 1-12 范围当中 " 。显然还存在着大量的 year month day 的无效组合, NextDate 函数将这些组合作统一的输出: " 无效输入日期 " 。其无效等价类为:
          M2{月份:月份<1}
          M3
      {月份:月份>12}
          D2
      {日期:日期<1}
          D3
      {日期:日期>31}
          Y2
      {年:年<1812}
          Y3
      {年:年>2012}
       
      弱一般等价类测试用例
        月份    日期                      预期输出
         6       15        1912           1912616
        强一般等价类测试用例同弱一般等价类测试用例
        注:弱--有单缺陷假设;健壮--考虑了无效值
       
        (
      )弱健壮等价类测试
        用例ID   月份  日期              预期输出
        WR1      6      15    1912      1912616
        WR2     -1     15    1912      月份不在112
        WR3     13     15    1912      月份不在112
        WR4      6      -1    1912      日期不在131
        WR5      6      32    1912      日期不在131
        WR6      6      15    1811      年份不在18122012
        WR7      6      15    2013      年份不在18122012

      ()强健壮等价类测试
         用例ID   月份    日期                预期输出
         SR1       -1      15       1912      月份不在112
         SR2        6      -1        1912      日期不在131
         SR3        6      15       1811      年份不在18122012
         SR4       -1      -1       1912      两个无效一个有效
         SR5        6      -1        1811      两个无效一个有效
         SR6       -1      15       1811      两个无效一个有效
         SR7       -1      -1       1811      三个无效

    1. 边界值分析法

     

    1. 概念

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

    1. 边界值分析法的应用

    根据大量的测试统计数据,很多错误是发生在输入或输出范围的边界上,而不是发生在输入/输出范围的中间区域。因此针对各种边界情况设计测试用例,可以查出更多的错误。

    使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

    边界值分析法与等价类分析法的区别:

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

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

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

    --输入:实数

    --输出:实数

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

    等价类划分:
            I.可以考虑作出如下划分:
                   a、输入 (i)<0 和 (ii)>=0
                   b、输出 (a)>=0 和 (b) Error
            II.测试用例有两个:
                   a、输入4,输出2。对应于 (ii) 和 (a) 。
                   b、输入-10,输出0和错误提示。对应于 (i) 和 (b) 。

    边界值分析:

    划分(ii)的边界为0和最大正实数;划分(i)的边界为最小负实数和0。由此得到以下测试用例:
                   a、输入 {最小负实数}
                   b、输入 {绝对值很小的负数}
                   c、输入 0
                   d、输入 {绝对值很小的正数}
                   e、输入 {最大正实数}

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

    相应地,以上类型的边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、  最短/最长、 空/满等情况下。利用边界值作为测试数据

     

    边界值

    测试用例的设计思路

    字符

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

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

    数值

    最小值-1/最大值+1

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

    空间

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

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

     

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

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

    范围或值

    位(bit)

    0 或 1

    字节(byte)

    0 ~ 255

    字(word)

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

    千(K)

    1024

    兆(M)

    1048576

    吉(G)

    1073741824

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

     

    字符

    ASCII码值

    空 (null)

    0

    空格 (space)

    32

    可输入的字符

    33~126

    0~9

    48~57

    A~Z

    65~90

    a~z

    97~122

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

    硬件设备

    范围或值

    手机锂电池电压

    工作电压:3.6~4.2V;

    保护电压:2.5~3V不等

    手机正常使用温度

    -25°C~+60°C

    基于边界值分析方法选择测试用例的原则

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

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

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

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

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

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

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

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

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

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

    1. 实例

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

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

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

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

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

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

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case5.jpg

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

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case6.jpg

    1. 三角形问题的边界值分析测试用例
      在三角形问题描述中,除了要求边长是整数外,没有给出其它的限制条件。在此,我们将三角形每边边长的取范围值设值为[1, 100]
       
    2. NextDate函数的边界值分析测试用例
      NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤121≤day≤31,并设定变量year的取值范围为1912≤year≤2050

    测试用例

    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

    等腰三角形

    等腰三角形

    等腰三角形

    非三角形

    测试用例

    mouth

    day

    year

    预期输出

    Test1

    Test2

    Test3

    Test4

    Test5

    Test6

    Test7

    6

    6

    6

    6

    6

    6

    6

    15

    15

    15

    15

    15

    15

    15

    1911

    1912

    1913

    1975

    2049

    2050

    2051

    1911.6.16

    1912.6.16

    1913.6.16

    1975.6.16

    2049.6.16

    2050.6.16

    2051.6.16

    Test8

    Test9

    Test10

    Test11

    Test12

    Test13

    6

    6

    6

    6

    6

    6

    -1

    1

    2

    30

    31

    32

    2001

    2001

    2001

    2001

    2001

    2001

    day超出[1…31]

    2001.6.2

    2001.6.3

    2001.7.1

    输入日期超界

    day超出[1…31]

    Test14

    Test15

    Test16

    Test17

    Test18

    Test19

    -1

    1

    2

    11

    12

    13

    15

    15

    15

    15

    15

    15

    2001

    2001

    2001

    2001

    2001

    2001

    Mouth超出[1…12]

    2001.1.16

    2001.2.16

    2001.11.16

    2001.12.16

    Mouth超出[1…12]

    1. 错误推断法

     

    1. 概念

     错误推测法主要是测试设计人员的测试经验相关,测试经验不同,设计出来的测试用例也区别很大。 推测法主要依赖经验、直觉来作出简单的判断甚至是猜测,给出可能存在缺陷的条件、场景等,在找到缺陷后,设计出相应的测试用例。

    1. 错误推断法的应用

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

    1. 例如, 输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
    2. 例如,前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例:
    1. 程序是否把空格作为回答
    2. 在回答记录中混有标准答案记录
    3. 除了标题记录外,还有一些的记录最后一个字符即不是2也不是3
    4. 有两个学生的学号相同
    5. 试题数是负数
    1. 例如,测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:
    1. 输入的线性表为空表;
    2. 表中只含有一个元素;
    3. 输入表中所有元素已排好序;
    4. 输入表已按逆序排好;
    5. 输入表中部分或全部元素相同。
    1. 例如,测试手机终端的通话功能,可以设计各种通话失败的情况来补充测试用例:
    1. 无SIM 卡插入时进行呼出(非紧急呼叫)
    2. 插入已欠费SIM卡进行呼出
    3. 射频器件损坏或无信号区域插入有效SIM卡呼出
    4. 网络正常,插入有效SIM卡,呼出无效号码(如1、888、333333、不输入任何号码等)
    5. 网络正常,插入有效SIM卡,使用“快速拨号”功能呼出设置无效号码的数字

     

    1. 因果图法

     

    1. 概念

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

    1. 因果图法的应用
    1. 4种符号分别表示了规格说明中向4种因果关系。

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case7.jpg

    1. 因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。
    2. C1表示原因,通常置于图的左部;e1表示结果,通常在图的右部。C1和e1均可取值0或1,0表示某状态不出现,1表示某状态出现。
    1. 因果图涉及的概念

    1)关系

      • 恒等:若c11,则e1也是1;否则e10
      • 非:若c11,则e10;否则e11
      • 或:若c1c2c31,则e11;否则e10可有任意个输入。
      • 与:若c1c2都是1,则e11;否则e10也可有任意个输入。

    2)约束

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

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case8.jpg

      • 输入条件的约束有以下4类:
    • E约束(异):ab中至多有一个可能为1,即ab不能同时为1
    • I约束(或):abc中至少有一个必须是1,即 ab c不能同时为0
    • O约束(唯一);ab必须有一个,且仅有1个为1
    • R约束(要求):a1时,b必须是1,即不可能a1b0
      • 输出条件约束类型

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

    1. 采用因果图法设计测试用例的步骤:
    1. 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
    2. 分析软件规格说明描述中的语义,找出原因与结果之间, 原因与原因之间对应的关系,根据这些关系,画出因果图。
    3. 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
    4. 把因果图转换为判定表。
    5. 把判定表的每一列拿出来作为依据,设计测试用例。
    1. 实例

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

               原因:

              1——第一列字符是A

              2——第一列字符是B

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

              结果:

              21——修改文件;

                     22 ——给出信息L

              23——给出信息M

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

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

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case9.jpg

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

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case10.jpg 

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

    1. 有一个处理单价为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——钱已付清

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case11.jpg

    3)转换成判定表:

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case12.jpg 

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

    1. 判定表驱动法
    1. 概念

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

    1. 判定表驱动法

     判定表的优点

    能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。

    在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。

    1. 阅读指南”判定表         
     

    1

    2

    3

    4

    5

    6

    7

    8

    问题

    觉得疲倦?

    Y

    Y

    Y

    Y

    N

    N

    N

    N

    感兴趣吗?

    Y

    Y

    N

    N

    Y

    Y

    N

    N

    糊涂吗?

    Y

    N

    Y

    N

    Y

    N

    Y

    N

    建议

    重读

       

       

    继续

     

       

      

    跳下一章

          

    休息

      

        

     

    1. 判定表通常由四个部分组成如下图所示。

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case13.jpg

    1.  条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
    2. 动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
    3. 条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
    4. 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。

     

    1. 规则及规则合并
    1. 规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
    2. 化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。
    1. 规则及规则合并举例
    1. 如下图左端,两规则动作项一样,条件项类似,在1、2条件项分别取Y、N时,无论条件3取何值,都执行同一操作。即要执行的动作与条件3无关。于是可合并。“-”表示与取值无关。

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case14.jpg

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

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case15.jpg

     

    1. 化简后的读书指南判定表
     

    1

    2

    3

    4

    问题

    你觉得疲倦吗?

    -

    -

    Y

    N

    你对内容感兴趣吗?

    Y

    Y

    N

    N

    书中内容使你胡涂吗?

    Y

    N

    -

    -

     

    建议

    请回到本章开头重读

    x

       

    继续读下去

     

    X

      

    跳到下一章去读

       

    x

    停止阅读,请休息

      

    x

     
    1. 判定表的建立步骤:(根据软件规格说明)
    1. 确定规则的个数.假如有n个条件。每个条件有两个取值(0,1),故有2n种规则。
    2. 列出所有的条件桩和动作桩。
    3. 填入条件项。
    4. 填入动作项。等到初始判定表。
    5. 简化.合并相似规则(相同动作)。
    1. 实例
    1. 问题要求:”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器,应给予优先的维修处理……” 。这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。请建立判定表。

    解答:

    1. 确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。
    2. 列出所有的条件茬和动作桩:

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case16.jpg

    1. 填入条件项。可从最后1行条件项开始,逐行向上填满。如第三行是: Y N Y N Y N Y N,第二行是: Y Y N N Y Y N N等等。 
    2. 填入动作桩和动作顶。这样便得到形如图的初始判定表。
     

    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

    初始判定表

    1. 化简,合并相似规则后得到图。
     

    1

    2

    3

    4

    5

    条件

    功率大于50马力吗?

    Y

    Y

    Y

    N

    N

    维修记录不全吗?

    Y

    N

    N

    -

    -

    运行超过10年吗?

    -

    Y

    N

    Y

    N

    动作

    进行优先处理

    x

    x

     

    X

     

    作其他处理

      

    x

     

    x

    1. 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决策表

     

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case17.jpg

     

    1. 用决策表测试法测试以下程序:该程序有三个输入变量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不是闰年}

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

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

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

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

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

      • 当条件1和条件2满足,并且条件3和条件4不满足,或者当条件1、3和条件4满足时,要执行操作1。
      • 在任一个条件都不满足时,要执行操作2。
      • 在条件1不满足,而条件4被满足时,要执行操作3。 根据规格说明得到如下判定表:

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case18.jpg

    这里,判定表只给出了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)判定表的优点和缺点

      • 优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。
      • 缺点:不能表达重复执行的动作,例如循环结构。
    1. B. Beizer 指出了适合使用判定表设计测试用例的条件:
      • 规格说明以判定表形式给出,或很容易转换成判定表。
      • 条件的排列顺序不会也不影响执行哪些操作。
      • 规则的排列顺序不会也不影响执行哪些操作。
      • 每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
      • 如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

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

    1. 正交试验法

     

    1. 概念 

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

    1. 正交试验法 

    利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计

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

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

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

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

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

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

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

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

    1. 功能图法

     

    1. 概念

     

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

    1. 功能图法的应用
    1. 功能图介绍

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

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

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

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

    1. 测试用例生成方法

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

    1. 测试用例生成规则

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

    1. 从功能图生成测试用例的过程
    1. 生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。
    2. 测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。
    3. 测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。
    1. 测试用例的合成算法:采用条件构造树.
    1. 场景法

     

    1. 概念

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

    1. 场景法的应用

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

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case19.jpg

    1. 实例

     

    1.  例子描述

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

     

    https://p-blog.csdn.net/images/p_blog_csdn_net/vincetest/266723/o_case20.jpg

      

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

    表3-8 场景设计

    场景1——成功提款

    基本流

     

    场景2——ATM内没有现金

    基本流

    备选流2

    场景3——ATM内现金不足

    基本流

    备选流3

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

    基本流

    备选流4

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

    基本流

    备选流4

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

    基本流

    备选流5

    场景7——账户余额不足

    基本流

    备选流6

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

    1. 用例设计

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

    表3-9 测试用例表

       

    TCID

    场景/条件

    PIN

    账号

    输入(或选择)的金额

    账面

    金额

    ATM内的金额

    预期结果

    CW1

    场景1:成功提款

    V

    V

    V

    V

    V

    成功提款

    CW2

    场景2ATM内没有现金

    V

    V

    V

    V

    I

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

    CW3

    场景3ATM内现金不足

    V

    V

    V

    V

    I

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

    CW4

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

    I

    V

    n/a

    V

    V

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

    CW5

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

    I

    V

    n/a

    V

    V

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

    CW6

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

    I

    V

    n/a

    V

    V

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

     

    1. 数据设计

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

    测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表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. 状态迁移法

     

    1. 概念及使用

    许多需求用状态机的方式来描述,状态机的测试主要关注在测试状态转移的正确性上面。对于一个有限状态机,通过测试验证其在给定的条件内是否能够产生需要的状态变化,有没有不可达的状态和非法的状态。可能不可能产生非法的状态转移等。对于被测系统,若我们可以抽象出它的若干个状态,以及这些状态之间的切换条件和切换路径,那么就可以从状态迁移路径覆盖的角度来设计用例对该系统进行测试。状态迁移法的目标是设计足够的用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖。

     

    状态迁移法的思想是提供将多个状态的转换串联起来进行测试的思路。该方法适合测试各种状态的转换,而且这些状态转换的测试在实践中是易遗漏的。例如像手机、MP3等,都可以使用状态迁移法对使用状态的迁移(即用户使用场景的转换)进行测试。

     

    状态迁移法的使用:

      步骤一:根据需求提取全部状态;

      步骤二:绘制状态迁移图;

      步骤三:根据状态迁移图推导测试路径(状态迁移树);

      步骤四:选取测试数据,构造测试用例。

    1. 实例:

    一、需求: 路人甲打电话预订飞机票,要去某地。

    二、分析:

     1、测试需求分析:

      a)客户向航空公司打电话预订机票。此时,机票信息处于“完成预订”状态;

      b)顾客支付了机票款项后,机票信息变为“已支付”状态;

      c)客户当天到达机场并使用身份证换领登机牌后,机票信息变为“已出票”状态;

      d)检票登机后,机票信息变为“已使用”状态;

      e)在登机前,可以取消自己的订票信息,若已支付机票费用,则可以退回票款。

      取消后,订票信息处于“已取消”状态;

      由以上分析得出客户预订机票时订单的全部状态:

      完成预定、已支付、已出票、已使用、已取消;

    2、测试设计方法分析(状态迁移法):

      a)状态迁移图:

      b)测试路径(状态迁移树):

      由状态迁移图得出的测试路径:

      (1)A->B->E;

      (2)A->B->C->E;

      (3)A->B->C->D。

    3、用例设计(输入部分):

      (1)完成预定->已支付->已取消;

      (2)完成预定->已支付->已出票->已取消;

      (3)完成预定->已支付->已出票->已使用;

    1. 总结

      状态迁移法实际测试了被测系统各种状态的转换,这些状态转换的测试在实际工作中是容易遗漏的,只要能够将这些状态的转换测试到,是否采用状态迁移法并不重要,因为状态迁移法只是提供了一种将多个状态的转换串联起来进行测试的思路。

      实际工作中,在业务流程中都涉及到了复杂的业务场景(即业务状态的迁移)。而这些业务场景在需求规格中往往不能够完全阐述清楚,容易出现遗漏。所以当被测系统的业务场景复杂时,在工程中应用这种针对状态迁移测试的思路完成对复杂业务场景的测试有时是很有必要的

     

    1. 流程分析法
    1. 概念

    流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计,是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种很重要的方法。在白盒测试中,路径就是指函数代码的某个分支组合,路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。在黑盒测试中,若将软件系统的某个流程看成路径的话,则可以针对该路径使用路径分析的方法设计测试用例。

      采用路径分析的方法设计测试用例的好处:

      1、降低测试用例设计的难度。即只要清楚程序流程、看懂程序流程图,就可以设计出质量较高的测试用例;

      2、是在测试资源紧张的情况下,可以据此有选择的执行测试用例,而非全部依靠经验做取舍。

      使用流程分析法的具体实施步骤:

      步骤1:画出业务流程图;

      步骤2:定义状态节点和条件分支;

      步骤3:确定测试路径;

      步骤4:选取测试数据,构造测试用例。

    1.   实例

      一、需求:使用ATM机取款

      二、分析:

      1、测试需求分析:

        a)用户向ATM取款机中插入银行卡,若银行卡合法,取款机提示用户输入密码;若插入无效银行卡,取款机提示用户银行卡无效,并自动退卡。

      b)用户输入银行卡密码,取款机将密码传至银行主机进行校验。若密码正确,取款机提示用户输入取款金额,

      提示信息:请输入取款金额:若密码错误,取款机提示用户:密码错误!,并退回输入密码界面。

      当三次输入密码错误时,自动退卡,锁卡。提示:密码错误,密码输入次数超限!

      c)用户输入取款金额,系统校验金额正确。即取款机余款大于用户取款金额。提示:请确认取款金额为XX

      用户按下确认键,确认取款XX。若用户输入取款金额不正确,提示:输入错误!

      此处为分析方便忽略输入取款金额错误的各种情况下的异常流程处理,降低分析的复杂度。

      d)系统同步银行主机,点钞票,输出给用户并减去用户卡中相应数目的存款金额。

      若卡内余额小于用户取款金额,则提示:余额不足!,并退回输入取款金额界面。

      若取款机与银行主机通信超时、通信中断、传输错误等情况,提示:连接超时,本次操作取消

      若主机已经做了数据库操作,减去了用户存款余额,则要做回退操作。

      e)用户取款,银行卡退卡。用户拔出银行卡。取款机恢复初始界面。正常取款操作结束。

      若用户未按时拿走取出的钱款、用户未按时拔出银行卡,则取款机做相应异常处理操作。

      2、测试设计方法分析(流程分析法):

      根据需求,画出业务流程图,如下:

      定义状态节点和条件分支:

      上面的业务流程图中,只描述正常流程-取款成功的情况。异常流程未做描述,是为了分析方便,实际中异常流程必须在业务流程图中描述清楚状态、分支等。

      3、用例设计(确定测试路径):

      需求描述及流程图中,ATM取款机的提示信息对应于测试用例中的预期输出部分,用户的操作对应测试用例中的测试步骤部分。原则是一条有效路径使用一个测试用例覆盖。

      依据业务流程图确定测试路径,即需要测试的业务流程。其主要包含三个方面:

      a)正常流程,取款成功(基本流程):对应一次性取款成功;

      b)异常流程,取款失败(分支流程):对应取款失败,包括退卡、吞卡;

      c)异常流程,取款成功(循环流程):对应取款中间出现意外,比如密码输入错误,但是最终成功取钱的情况。

    1.   总结

      流程分析法适用于有先后顺序的测试。常用于业务流程测试、安装流程测试等。

      流程分析法重点在于测试流程。因此,一般每个流程用一个测试用例验证。但是,流程测试没有问题并不能说明系统功能没有问题,还需要针对单步功能进行测试。对于包含复杂流程的系统,只有功能点和处理流程都进行测试覆盖,才算是比较充分的测试。

     

    1. 逐级细分法

     

    逐级细分是一种由粗到细的设计策略。对粒度较大的源数据(源数据可能是需求项,也可能是测试项)使用“逐级细分法”进行逐级分解,得到粒度较小的测试子项,再根据较小的测试子项去设计测试用例,从而降低测试冗余度。

    把给定的模块功能转变为它的详细过程性描述,通常采用逐级细分的策略。挖掘显式需求背后或对应功能所隐藏的隐式需求,把不明确的需求转变为明确的需求,并确定其测试项。把细化后的测试项,进行深化分析,确定其测试子项。

     

    针对测试特性中各测试项,需要分多个层次逐层细化,最终得到可以进行具体用例设计的测试子项,从整体上降低测试设计的复杂度。每个细分层次都是从同一个角度对上一层次划分结果的进一步分解。每层进行划分的角度可以是多个方面的,同一产品,同一业务都有很多选择,可以是从用户属性角度、从组网角度、从功能流程角度、从系统配置参数等一些全局因素角度来考虑。不同产品在这一点上会有很大区别,需要根据产品本身特点作经验积累,形成自己固化的细分层次和每层分类属性。

    1. 输入域测试法

            输入域测试法:输入域测试法是一种综合的方法,综合了等价类划分法、边界值分析法等方法。这里说的输入域就是指输入,针对输入会有各种各样的输入值。

    输入域测试主要考虑三个方面:

    1.极端测试(Extremal Testing)

    2.中间范围测试(Midrange Testing)

    3.特殊值测试(Special Value Testing)

            对于结构化的输入域,要选择每个成员的输入点的组合,这个过程可能会产生大量的数据。若考虑输入域之间内部联系有选择的进行组合,可以一定程度上减轻这个问题。

            输入域测试法实际上是在等价类划分法、边界值分析法的基础上考虑了特殊值测试等其他情况,因此从步骤上来说,只需要在使用完等价类划分、边界值分析的基础上再考虑特殊值和长时间输入。

    1.特殊值:主要和输入的特点有关,需要了解系统对该输入的存储和处理。

    2.长时间输入:对于那些没有限制输入长度的输入进行长时间的持续输入,以查看是否会存在输入的数据内存越界导致系统故障的情况。

    1. 输出域分析法

    输出域分析:在输入域测试中,是针对系统的输入域进行分析,设计用例覆盖输入域的等价类和边界值。但由于系统输出和输入之间一般并不是线性关系,所以从输出域的角度来看,这些覆盖了输入域所有等价类和边界值的用例,并不一定能完全覆盖输出域的等价类和边界值。因此,有必要对输出域进行等价类和边界值分析,确定要覆盖的输出域样点,然后反推得到应该输入的输入值,从而构造出测试用例。这种测试方法(思考方式)就是输出域分析,它的目的是为了达到输出域的等价类和边界值覆盖。

    1.针对输出域划分等价类(可选)

    2.分析样点

    3.确定覆盖的输出点,然后反推得到应该输入的输入值,从而构造出测试用例

    1. 异常分析
    1. 概念

           异常分析:异常分析就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析,依此设计测试用例。主要针对系统的容错能力、故障恢复能力进行测试。简单的说就是人为让系统出故障,然后检查系统的故障恢复能力。

            另一方面,针对系统的异常测试(是否做了不应该做的事)也要通过异常分析等手段。

    1. 应用

    1)针对系统罗列可能的故障

            例如:断电;断网;数据损坏;内存错误;

    2)针对每种可能的故障设计测试用例

    展开全文
  • 功能性测试用例设计方法深入理解

    千次阅读 2020-03-25 16:49:19
    一 进行测试设计的一般流程 设计测试案例的时候,需要有清晰的测试...测试用例设计一般包括以下几个步骤: 1、测试需求分析 从软件需求文档中,找出待测试软件/模块的需求,通过自己的分析、理解,整理成为测试需...

    一 进行测试设计的一般流程

    设计测试案例的时候,需要有清晰的测试思路,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程,而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤:

    1、测试需求分析
    从软件需求文档中,找出待测试软件/模块的需求,通过自己的分析、理解,整理成为测试需求,清楚被测试对象具有哪些功能。测试需求的特点是:包含软件需求,是否具有可测试性。

    测试需求应该在软件需求基础上进行归纳、分类或细分,方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系,即一个或多个测试用例集或测试用例套件对应一个测试需求。

    2、业务流程分析
    软件测试,不单纯是或不能是只基于功能的黑盒测试,还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点,需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前,先画出软件的业务流程。如果设计文档中已经有业务流程设计,可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程,测试工程师应通过阅读设计文档,与开发人员交流,最终画出业务流程图。业务流程图可以帮助理解软件的业务和数据处理逻辑和数据流向,从而指导测试用例的设计。

    从业务流程上,应得到以下信息:

    A、 主流程是什么

    B、 条件备选流程是什么

    C、 数据流向是什么

    D、 关键的判断条件是什么

    3、测试用例设计
    完成了测试需求分析和软件流程分析后,开始着手设计测试用例。测试用例设计的类型包括功能测试,边界测试,异常测试,性能测试,压力测试等。在用例设计中,除了功能测试用例外,应尽量考虑边界、异常、性能的情况,以便发现更多的隐藏问题。

    黑盒测试的常见测试用例设计方法有:场景图,因果图分析,判定表法,正交表法,状态转换法,等价类划分,边界值划分、和错误猜测法等,白盒测试的测试用例设计方法有:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法,结合前面的需求分析和软件流程分析进行设计:

    功能测试:测试某个功能是否满足需求的定义,功能是否正确,完备。

    适合的技术:由业务需求和设计说明导出的功能测试、等价类划分

    边界测试:对某个功能的边界情况进行测试。

    适合的技术:边界值划分

    异常测试:对某些功能来说,其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的,类似这样的情况需要书写相关的异常测试。

    适合的技术:由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、

    性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。

    适合的技术:业务需求和设计说明导出的测试

    压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件兼容测试:测试软件产品在不同的平台,不同的工具,相同工具的不同版本下功能的兼容性。

    4、测试用例评审
    测试用例设计完成后,为了确认测试过程和方法是否正确,是否有遗漏的测试点,需要进行测试用例的评审。
    测试用例评审一般是由测试leader安排,参加的人员包括:测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕,测试工程师根据评审结果,对测试用例进行修改,并记录修改日志。

    5、测试用例更新完善
    测试用例编写完成之后需要不断完善,软件产品新增功能或更新需求后,测试用例必须配套修改更新;在测试过程中发现设计测试用例时考虑不周,需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成,也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。测试用例是“活”的,在软件的生命周期中不断更新与完善。

    二 进行测试需求提取与排查问题的思路

    2.1 以人为纲
    什么是以人为纲,就是根据软件开发生命周期过程中,测试人员所面对的测试上游项目成员角色。

    一般互联网型项目型公司,标准岗位角色配置

    一 产品人员:产品经理

    原型设计

    交互设计

    页面重构

    二 开发人员 前端开发

    服务接口开发

    后台管理开发

    DBA数据库管理

    2.2 以物为纲
    以物为纲就是指,测试上游所面对的可供测试设计参考的交付物(主要从测试人员面向角度以及前期首轮测试考虑,过于精细的岗位不纳入):

    一 产品人员:产品经理 需求文件(业务流程说明,业务规则说明)

    原型设计 页面原型设计稿

    交互设计 页面体验交互设计说明

    页面重构 可供前端开发人员调试开发前端脚本的重构页面

    二 开发人员 前端开发 可执行访问的前端页面、前端页面实现技术说明

    服务接口开发 服务接口文档、服务架构组件间部署调用说明、服务内部伪处理逻辑流程说明

    后台管理开发 后台查询管理系统(面向客服 CMS内容 生产运维等)

    DBA数据库管理 库表结构数据字典说明

    最终要达到,人物合一,人和物要对的上一致统一。是人为产生的问题,就去问责相关人员。是交付产物的问题,就对交付产物进行分析定位,最终协调产品与开发给出合理的产品设计与技术解决方案,并及时提醒更正文件并做用例落地设计。

    2.3 5W1H方法
    what 什么

    why 为什么

    when 何时

    where 何地

    who 谁

    How 怎么做

    这个方法,一般可以用来询问具体的设计细节或技术实现细节,以加强对细节问题的梳理理解。

    三 用例设计系统理解框架

    在这里插入图片描述
    此图大家要务必深入理解,测试用例的设计本质就是 ,找对测试对象->测试对象组合设计->减少无效组合->得到流程或数据流序列.
    针对不同的层,如系统页面层,页面内部,具体输入项 ,虽然每个层的测试对象不一样,但你用久了这些用例设计方法就会发现如上图的"测试用例共性步骤"其实是一样的.用例设计方法的本质是相同的,
    灵活采用设计方法,不要被该图所迷惑,不是死的,不是教你这层就是这样固定的设计方法,要活学活用领悟精髓.
    这种用例目录树结构,可以很好的和用例设计管理工具平台(如Testlink ,ALM或者叫QC等之类的用例管理工具) 相结合.达到 分层 解耦 重用 调用之用例特性.各层之间不耦合,业务流,操作流和数据流分开.

    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 159,042
精华内容 63,616
关键字:

测试用例设计方法