测试用例相关内容

目录

1. 什么是测试用例?

2. 测试用例的特征

3. 编写测试用例的好处

4. 测试用例的4个特性

5. 测试用例通常包括以下几个组成元素

6. 编写测试用例的基本方法、

    6.1 等价划分法

    6.2 边界值法

    6.3 因果图法

    6.4 判定表法

    6.5 场景法

    6.6 错误推算法

    6.7 正交表法

1. 什么是测试用例?

       测试用例是执行测试的依据,把测试系统的操作步骤用文档的形式描述出来

  1)测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误,而精心设计的少量测试数据,包括测试输入、执行条件和预期的结果,实际结果

  2)测试用例是执行的最小实体。

  3)测试用例是测试工作的指导,是软件测试的必须遵守的准则,更是软件测试质量稳定的根本保障

2. 测试用例的特征

  1、有效性:

    测试用例的能够被使用,且被不同人员使用测试结果一致

  2、可重复性:

    良好的测试用例具有重复使用的功能。(回归测试)

  3、易组织性:

    好的测试用例会分门别类地提供给测试人员参考和使用(功能、性能、易用分类编号)

  4、清晰、简洁:

    好的测试用例描述清晰,每一步都应有相应的作用,有很强的的针对性,不应出现一些无用的操作步骤。

  5、可维护性:

    由于软件开发过程中需求变更等原因的影响,常常对测试用例进行修改、增加、删除等,以便测试用符合相应测试要求。

3. 编写测试用例的好处

  在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。

  测试用例的使用令软件测试的实施重点突出、目的明确。

  在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期。

  检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路

4. 测试用例的4个特性

  1、代表性:

    能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。

  2、针对性:

    对程序中的可能存在的错误有针对性地测试

  3、可判定性:

    测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果

  4、可重现性:

    对同样的测试用例,系统的执行结果应当是相同的。

5. 测试用例通常包括以下几个组成元素

  用例编号、测试模块、用例标题、用例级别、前置条件、测试输入、执行操作、预期结果,实际结果

6. 编写测试用例的基本方法、

    6.1 等价划分法

    应用场景:多用于输入框

    等价类划分是指分步骤地把海量(无限)的测试用例集减得很小,但过程同样有效。

    等价类 :何为等价类,某个输入域的集合,在这个集合中每个输入条件都是等效的。

    一般可分为有效等价类和无效等价类

    有效等价类:指符合《需求规格说明书》,输入合理的数据集合

    无效等价类:指不符合《需求规格说明书》,输入不合理的数据集合
           

           

    6.2 边界值法

  应用场景:

  一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。

  比如下面代码:
    for(int i = 0;i <100; i ++)
  {
    int j = i+1;
    System.out.println("循环第“+j+“次”)//循环地做某件事情
  }

  这里的程序是循环了100次,所以会做100次;

  如果程序员不小心,把i <100写成i <= 100,则多循环添加一次,这时候边界值检查是一个很好的测试方法。

  确定边界值的方法:

    选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

  上点:

    实心圆当前的两个值或离空心圆内侧最近的值

  离点:
    距离实心圆最近的前一个值或空心圆当前位置的值
      

   注明:

    边界值不是从每个等价类中挑一个作为代表,而是把每个等价类的边界都进行测试。

    6.3 因果图法

  应用场景:

    因果图法比较适合输条件比较多的情况,测试所有的输入条件的排列组合。所谓的原因就是输入,所谓的结果就是输出。

  因果图测试用例

     

   两原因是互斥的,不会同时成立,最多有一个可能成立

    6.4 判定表法

    

    6.5 场景法

  从用例开始到结束遍历其中所有基本流和备选流。

  注没有基本流,备选流是无法实现的

            

   比如:

  从ATM机取款的过程就是一个基本流,前提是他的每个环节都没有问题

                

  第一次测试中,根据测试计划,我们需要核实提款用例已经正确地实施。此时尚未实施整个用例,只实施了下面的事件流:

    基本流-提取预设金额(100 元、200元、500元、1000元)

    备选流2 - ATM 内没有现金

    备选流3 - ATM 内现金不足

    备选流4 - PIN 有误

    备选流5 - 帐户不存在/帐户类型有误

    备选流6 - 帐面金额不足

            

    6.6 错误推算法

  错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。

  一般这种方法是基于经验和直觉推测程序中可能发送的各种错误,有针对性地设计。只能作为一种补充。

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

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

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

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

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

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

  技巧:

  最重要的是要思考和分析测试对象的各个方面,多参考以前发现的bug的相关数据,总结的经验,个人多考虑异常的情况、反面的情况、特殊的输入,以一个攻击者的态度对待程序,就能设计出比较完善的测试用例来。

    6.7 正交表法

  应用场景:常用于下拉菜单

  在一个界面中有多个控件,每个控件有多个取值,控件之间可以相互组合,不可能(也没有必要)为每一种组合编写一条用例,如何使用最少最优的组合进行测试。

  判定表,因果图也是考虑控件组合,但是组合数量较少(一般不会超过20中)

  公式:

           

  m:表示每个下拉框的所有因素加起来的个数,一般由多个下拉框时我们去因素个数最多的下拉框

  k:表示一共有多少个下拉框

  正交表查询地址:

  https://www.york.ac.uk/depts/maths/tables/orthogonal.htm

  正交排列法:

  http://support.sas.com/techsup/technote/ts723_Designs.txt

  还可以利用一个测试工具生成正交表:

  正交设计助手

原文地址:https://www.cnblogs.com/xinzaiyuan/p/14562762.html