常见的测试用例设计方法

1、等价类划分法:

有这样一条测试基本原则:穷尽测试是不可能的。即使是看起来规模很小的软件产品,其输入数据的组合或逻辑路径也几乎是无穷的,也就是说,想对测试对象进行完全的检查和覆盖,基本上是不可能的。

我们可以依据数据的特性,将所有的测试数据分为若干个类,每一类的代表性数据在测试中的作用等价于这一类中的其他值,也就是说,如果某一类中的一个例子发现了错误A,这一等价类中的其他例子也能发现这个错误A;反之,如果某一类中的一个例子没有发现错误,则这一类中的其他例子也不会查出错误。这种划分数据的方法被称为等价类划分方法,划分等价类时遵循以下三个标准:

  • 完备性:划分的子集合的并集是整个集合;
  • 无冗余性:子集互不相交;
  • 等价性:属于同一等价类的测试数据,映射到“相同的执行路径”。

 通过这种选择适当的数据子集3来代表整个数据集的方法,既降低了测试的数目,又实现了“合理的”覆盖。

!!注意:软件不仅要能接收合理的数据,也要能经受意外的考验。因此在划分等价类的时候不仅要考虑合理的、有意义的输入数据构成的集合,还要考虑不合理的或无意义的输入数据所构成的集合。我们将前者称为有效等价类,它能验证需求是否实现,后者则为无效等价类,能检验是否会出现异常。无效等价类至少应有一个,也可能又多个,视具体情况而定。

 

EXAMPLE需求:要求用户输入年份,年份限定在1980~2020年,由4位数字表示。

使用等价类划分法,首先确定有效等价类:4位数字字符且年份为1980~2020。然后确定无效等价类:如输入的类型和长度不合理,年份超出范围等,具体如下表所示:

 设计测试用例,覆盖所有的有效等价类和无效等价类:

 

2、边界值

大量的错误发生在输入或输出范围的边界上,而不是在输入输出范围的内部。因此针对各种边界情况设计测试用例,有很大的概率可以查出更多的错误。

这种对输入或输出的边界值进行测试的方法就是边界值法。边界值法多用于对数据进行测试,在数据测试的时候,除了要关注边界值还要关注默认值,空白,空值,零值和无。除上述常规数据外,非常规的数据还要关注非法值,错误值,不正确值和垃圾数据,即所有可能的无效等价类数据。

具体应用边界值法时,应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。要特别说明的是,使用边界值法不仅只考虑输入数据,也应该考虑输出数据。

 

EXAMPLE需求:豆瓣用户可在首页搜索框内输入关键词搜索感兴趣的内容。如在豆瓣搜索“星际穿越”。

 使用边界值法设计测试用例,覆盖输入数据和输出数据:

  • 关键词(输入数据):
    • 为空
    • 关键词长度为1(最小长度)
    • 关键词长度为60(最大长度)
    • 关键词长度为61
  • 搜索结果(输出数据):
    • 搜索结果为空
    • 有一个搜索结果
    • 有20个搜索结果(一次最多展示20条数据)
    • 有21个搜索结果(通过更多按钮查看)

 

3、场景法/流程分析法

 上面介绍的这两种方法对于单点测试是十分有效额,例如用户想使用Amazon买东西,搜索输入框的测试我们可以运用边界值法。但是搜索可能只是用户使用Amazon的第一步,它还可能点击某商品查看详情、将商品加入购物车、从购物车中进行结算或者使用直接购买功能结算,用户的操作会触发事件,不同事件触发的顺序不同,会形成不同的事件结果。

根据场景来设计测试用例的方法我们称之为场景法,也称为流程分析法。使用场景法的第一步自然是画出业务流程图,通常我们能从BA/UX处获取到流程图,如果没有,那就需要自己去梳理了。场景法一般包括基本流、备用流和异常流,基本流表示通过业务流程时输入都正确,能达到目标;备选流表示通过业务流程时输入错误(或者操作错误)导致流程存在反复,但是经过纠正后仍能达到目标;异常流是指通过业务流程时输入错误(或者操作错误)产生异常终止流程。

画流程图可以先从基本流开始,也就是确定Happy Path,然后补充备选流,最后还要考虑异常场景来确定异常流。有了流程图,就可以从中选取测试路径来构造测试用例。

 

EXAMPLE需求:“豆瓣评分”微信小程序支持用户使用微信登陆,并在登陆时获取用户额手机号码。

 

 上图左为已开发完成的微信登陆功能截图,右图为根据要求画出的业务流程图,图中实际上只包括了基本流和备选流。根据流程图设计的测试用例的过程较为简单。

 

4、错误推断法

在测试程序时,人们可以根据经验或直觉推测程序中可能存在的各种错误,从而有针对性地编写检查这些错误的测试用例的方法,这种方法被称为错误推断法。

错误推断法没有固定的形式,依靠的是经验和直觉,很多时候,我们都会不知不觉的使用到。

错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的,这类方法在目前的敏捷开发模式下的投入产出比很高,因此被广泛应用。但是,这个方法的缺点也显而易见,那就是难以系统化,而且过度依赖个人能力。