测试的艺术:测试用例的设计

由于时间和成本的约束,软件测试的最关键问题是:

在所有可能的测试用例中,哪个子集最有可能发现最多的错误

测试方法:

黑盒测试

  • 等价类划分(Equivalence Partitioning)

1. 严格控制测试用例的增加,减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量

2. 它覆盖了大部分其他可能的测试用例。

划分了等价类后,就可以说,如果对该集合中某个元素所进行的测试没有发现错误的话,那么对该集合中其他元素所进行的测试也不大可能会发现错误。

使用等价类划分方法设计测试用例主要有两个步骤:(1)确定等价类; (2)生成测试用例

(1)确定等价类

外部条件,有效等价类(代表对程序的有效输入),无效等价类(其他任何可能的输入条件-即不正确的输入值)

确定等价类大体上是一个启发式的过程,一些指导原则:

  • 如果输入条件规定了一个取值范围(eg. “数量可以是从1到99”),那么就应确定出一个有效等价类(1<数量<99),以及两个无效等价类(数量<1, 数量>99)
  • 如果输入条件规定了取值个数(eg. “汽车可登记一至六名车主”),那么就应确定出一个有效等价类和两个无效等价类(没有车主,或车主对于六个)
  • 如果输入条件规定了一个输入值的集合,而且有理由认为程序会对每个值进行不同的处理(eg. “交通工具的类型必须是公共汽车、卡车、出租车、火车或摩托车”),那么就应为每个输入值确定一个有效等价类和一个无效等价类(eg. 拖车)
  • 如果存在输入条件规定了“必须是”的情况(eg. “标识符的第一个字符必须是字母”), 那么就应确定一个有效等价类(首字符是字母)和一个无效等价类(首字符不是字母)

(2)生成测试用例

使用等价类来生成测试用例的过程:

  • 为每个等价类设置一个不同的编号
  • 编写新的测试用例,尽可能多地覆盖那些尚未被涵盖的有效等价类,知道所有的有效等价类都被测试用例所覆盖
  • 编写新的用例,覆盖一个且仅一个尚未被覆盖的无效等价类,直到所有的无效等价类都被测试用例覆盖: 用单个测试用例覆盖无效等价类,是因为某些特定的输入错误检查可能会屏蔽或取代其他输入错误检查。
  • 边界值分析(Bondary-Value Analysis)

所谓边界条件,是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。

  • 因果图分析(Cause-Effect Graphing)

  生成测试用例时采用的过程:

    • 将规格说明分解为可执行的片段
    • 确定规格说明中的因果关系。所谓因,是指一个明确的输入条件或输入条件的等价类。所谓果,是指一个输出条件或系统转换。
    • 分析规格说明的语义内容,并将其转换为连接因果关系的布尔图。这就是所谓的因果图
    • 给图加上注解符号,说明由于语法或环境的限制而不能联系起来的因和果
    • 通过仔细地跟踪图中的状态变化情况,将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例
    • 将判定表中的列转换成测试用例

  因果图中的基本符号:

设想一下,每个结点的值为0或为1,0表示“不存在”状态, 1 表示“存在” 状态。identity函数表示,如果a等于1,则b也是1,否则b为0. not函数表示如果a等于1,则b为0,否则b为1.Or函数表示如果a或b或c等于1,则d为1,否则d为0。 and函数表示如果a和b都等于1,则c为1,否则c为0.

  • 错误猜测(Error Guessing)

白盒测试(White-Box Testing)

  • 语句覆盖
    • 度量被测代码中每个可执行语句是否被执行到了。
    • int foo(int x, int y)
              {
                  return x / y;
              }

      测试用例,x=10, y=5.

    • 测试人员的测试结果会告诉你,代码覆盖率达到了100%,并且所有测试案例都通过了。然而遗憾的是,却没有发现最简单的bug,比如,让y=0时,会抛出一个除零异常。
  • 判定覆盖
    • 该准则要求必须编写足够的测试用例,使得每一个判断都至少有一个为“真”和为“假”的输出结果, 并且每条语句都至少被执行一次。换句话说,即每个判断都必须有“是”和“否”的结果,且每个入口点都必须至少被调用一次。
  • 条件覆盖
    • 在条件覆盖情况下,要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次,且每个入口点都必须至少被调用一次。
  • 判定/条件覆盖
    • 将一个判断中的每个条件的所有可能的结果至少执行一次,将每个判断的每个条件的所有可能的结果至少执行一次,将每个判断的所有可能的结果至少执行一次,将每个入口点都至少调用一次。
  • 多重条件覆盖
    • 该准则要求编写足够多的测试用例,将每个判定中的所有可能的条件结果的组合,以及所有入口点都至少执行一次。
    • 其中的原因是“与”和“或”表达式中某些条件的结果可能会屏蔽或阻碍其他条件的判读。举例来说,如果“与”表达式中有个条件为“假”,那么就无须计算该表达式中的后续条件。

public void foo(int a, int b, int x)
    {
        if (a > 1 && b == 0)
            {
                x = x / a;
            }
        if (a == 2 || x > 1)
            {
                x = x + 1;
            }
    }
  • 语句覆盖: ace - A=2, B=0, X=3
  • 判定覆盖:acd, abe - A=3, B=0, X=3; A=2, B=1, X=1
  • 条件覆盖:abe - A=2, B=0, X=3; A=1, B=1, X=1
  • 多重条件覆盖:测试用例必须覆盖一下8中组合
    • A>1, B=0
    • A>1, B<>0
    • A<=1, B=0
    • A<=1, B<>0
    • A=2, X>1
    • A=2, X<=1
    • A<>2, X>1
    • A<>2, X<=1
      • A=3, B=0, X=4
      • A=2, B=1, X=1
      • A=1, B=0, X=2
      • A=1, B=1, X=1

测试策略:

1. 如果规格说明中包含输入条件组合的情况,应首先使用因果图分析方法

2. 在任何情况下都应使用边界值分析方法。对输入和输出边界进行的分析

3. 应为输入和输出确定有效和无效等价类,在必要情况下对上面确认的测试用例进行补充

4. 使用错误猜测技术增加更多的测试用例

5. 针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则。

时间: 2024-12-21 04:32:51

测试的艺术:测试用例的设计的相关文章

测试小笔记(黑\白盒测试及区别、测试用例的设计)

测试的概念: 白盒测试 黑盒测试 白盒测试.黑盒测试优劣比较   测试用例的设计 一般而言,在所有的方法中效率最低的是随机输入测试,即在所有可能的输入值中随机选取某个子集来对程序进行测试的过程. 白盒测试的方法:1)语句覆盖.2)判定覆盖.3)条件覆盖.4)判定/条件覆盖.5)多重条件覆盖. 1.>语句覆盖:较弱的准则,将程序中的每条语句至少执行一次. 2.>判定覆盖或分支覆盖:较强的逻辑覆盖准则,必需编写足够的测试用例,使得每个判断都至少有一个为真和为假的输出结果.也就是说每条分支路劲都必须

011-黑盒测试的测试用例常见设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

黑盒测试的测试用例常见设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用. 1)等价类划分 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2)边界值分析法 边界值分析方法是

在国外,资深的软件测试人员大多是手动测试,他们厉害之处在于测试用例的设计,但在国内,很多测试人员都把自动化测试当成很厉害的资本,为什么?

导语:”在国外,资深的软件测试人员大多是手动测试,他们厉害之处在于测试用例的设计,但在国内,很多测试人员都把自动化测试当成很厉害的资本,为什么?” 偶然在知乎上看到一篇关注度很高的话题,标题如上. 作为一名从业8年有余的软件测试工程师,并且一直在外企做测试的我, 忍不住想发表一些自己的看法和见解. 我觉得在国内,很多公司或者个人把自动化测试当成一个了不起的资本,根本是源于国内大家对代码的无上崇拜,这也造就了国内现在IT互联网行业内一个鄙视链: 开发---> 测试开发--->自动化测试---&g

客户端GUI测试技术和自动化测试架构设计简谈

客户端自动化特点 客户端的自动化,通常做过的人都不是很愿意深入讨论.因为除了功能和逻辑之外,不得不面对各种界面变化,各种和环境交互,各种兼容问题以及想不到灰色地带,就算这样,也找不到太多有效的bug.然而即便如此,客户端的自动化必须去做,尤其是GUI的.它的自动化特点是: 复杂 成本高 不容易发现问题 技术要求高 架构很难通用 下面,从一些基本的东西开始一点点的讨论客户端GUI测试的一些问题和处理办法,以及自动化架构设计的一些思路.事实上就像上面说的,GUI的测试并不是为了发现bug,而是回归的

测试用例的设计方法

测试用例的设计方法有: 等价类划分方法,边界值分析方法,错误推理方法,因果图方法,判定表驱动分析方法,正交实验设计方法,功能图分析方法,场景设计方法 等价类划分方法: 基本概念: 一.方法简介 1.定义 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 2.划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等

软件测试用例的设计和编写

一.为什么要写测试用例 写测试用例可以让测试的需求覆盖更加全面,让测试工作进行得条理有序,且方便移交和交流 好的测试用例要做到:结构设置和理,case覆盖全面,且具有可执行性,可重复等特点. 二.软件测试文档 1.测试范围列表:需求编号.模块名称.功能名称.复杂度.复用性.自测充分性.是否公用模块.使用频率.优先级 2.测试用例一般包含的要素:用例编号.测试项目.用例标题.优先级(致命.严重.一般.微小.建议).预置条件.输入参数.执行步骤.预期结果 3. 缺陷报告要素:缺陷编号.缺陷标题.严重

Web测试的常用测试用例与知识

1. Web测试中关于登录的测试 2. 搜索功能测试用例设计 3. 翻页功能测试用例 4. 输入框的测试 5. Web测试的常用的检查点 6. 用户及权限管理功能常规测试方法 7. Web测试之兼容性测试 8. Web测试-sql注入 9. Web测试中书写用例时要考虑的检查点 10. 手机电子邮件测试用例 11. 记事本与日历的测试用例 12. Web测试总结 13. 让web站点崩溃最常见的七大原因 14. Web应用程序是否存在跨站点脚本漏洞 15. Web测试总结(全) 16. 理解we

从“系统登陆”测试用例案例来分析测试用例的设计

编写测试用例是软件测试工程师最基本的工作.但是如何要编写出好的测试用例,这还真是需要我么对平时的工作认真的进行总结一下. 下面我以"系统登陆"黑盒测试用例设计来分析一下测试用例到底如何来写? 一.案例描述 测试对象:是一个以B/S结构系统的登陆功能点. 功能描述:1.用户在地址栏输入相应的地址,要求限时登陆界面 2.输入用户名.密码和验证码,登陆,系统自动校验,并给出相应提示信息. 3.如果用户名.密码.验证码任一信息未输入,登陆后系统给出相应提示信息. 4.连续3次未通过验证时,自动

测试用例的设计步骤

测试用例的设计步骤作为测试新人,如何实现测试用例的设计一直是我的一个疑惑,在工作中写过几个项目的测试用例,尝试总结一个测试用例的设计步骤.前提:编写测试用例之前我们需要对项目的需求有清晰的了解,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数,作为测试用例的编写者不仅了解要有常见的测试用例编写方法,同时需要了解被测软件的设计.功能规格说明.用户试用场景以及程序/模块的结构.步骤:1.测试需求分析从项目部拿到软件的需求规格说明书后,开始对项目的需求进行分析,通过自己的分析.理解,整理成为测

单元测试中测试用例的设计方法

单元测试中测试用例的设计方法 1. 用于语句覆盖的基路径法 基路径法保证设计出的测试用例,使程序的每一个可执行语句至少执行一次,即实现语句覆盖.基路径法是理论与应用脱节的典型,基本上没有应用价值,读者稍作了解即可,不必理解和掌握. 基路径法步骤如下: 1)画出程序的控制流图 控制流图是描述程序控制流的一种图示方法,主要由结点和边构成,边代表控制流的方向,节点代表控制流的汇聚处,边和结点圈定的空间叫做区域,下面是控制流图的基本元素: 以下代码: void Sort(int iRecordNum,