关于如何写好测试用例的一些建议:
1. 要参与需求评审,评审需求的过程实际也是熟悉需求业务的过程。只有对业务比较熟悉了,才能更好的,更充分的设计出高质量的测试用例;
2. 要多阅读文档,其中包括产品策划书、规格说明书、需求文档,接口文档等,我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标;
3. 要保持质疑,缺陷越早发现,修复成本越低;
4. 测试步骤描述要简单、清晰,并且要写清楚每一个步骤的描述,当编写用例的人和执行用例的人不是同一个人时,清晰的操作步骤可以节省大量的沟通成本。
5. 用例的预期结果要完整而且清晰,并且要各个输出的结果写出来,包括:返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。
6. 测试用例需要不断更新和维护,不要认为测试用例的设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例。并且需要在测试执行时利用发散思维不断的构造和完善测试用例。
对于设计测试用例的方法,今天就主要介绍几种测试方法,如边界值、等价类、场景法、因果图法、错误猜测。
一、等价类划分
等价列划分设计方法是把所有可能的输入数据划分成若干部分(子集),然后从每一个子集中选取少量具有代表性的数据作为测试用例,测试某等价类的代表值就等于对这一类其他值的测试。
1、划分等价类
等价类划分有两种不同的情况:有效等价类代表对程序的有效输入和无效等价类代表不正确的输入值。下面是确定等价类的原则:
(1)在输入条件规定了取值范围的情况下,则可以确立一个有效等价类(在取值范围之内)和两个无效等价类(小于取值范围和大于取值范围)
例如:在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如:输入值是学生成绩,范围是0~100;
例如:使用手机发送短信的时候,短信内容长度必须在70个字符之内,则有效等价类:短信内容长度在70个字符之内,无效等价类:短信内容长度为0、短信内容长度大于70;
(2)在输入条件规定了“必须如何”的条件的情况下,则可以确立一个有效等价类和一个无效等价类。例如:变量的命名比如以大写字母开头,则有效等价类为:变量命名以大写字母开头,无效等价类为:变量开头非大写字母开头;
(3)在规定了输入数据必须遵守的规则的情况下,可以确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。例如:要求的导入的文件必须为.log结尾,小于等于256K的文件,可以确定至少两个无效类是:.log结尾但大于256K和小于等于256K但是以.csv结尾,还有其他的无效类,如:.txt结尾小于256K等等;
(4)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。例如:若规定输入的数据是整型,则可划分为正整数、0、负整数;
2、生成测试用例
在确立了等价类后,可建立等价类表,列出所有划分出的等价类,过程为:
(1)为每一个等价类规定一个唯一的编号;
(2)设计一个新的测试用例,使其尽可能多的覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;
(3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止;
边界条件指的是输入和输入等价类中刚好处于边界、或超过边界或小于边界的状态。
与等价划分的区别:边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果。场景法一般包含基本流和备选流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备选流来完成整个场景。
下图来展示一下网上最常见的场景法基本情况的一个实例图。
在这个图中,有一个基本流和四个备选流。
每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:
场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4
从上面的实例我们就可以了解场景是如何利用基本流和备用流来确定的。
基本流:采用直黑线表示,是经过用例的最简单的路径(无任何差错,程序从开始直接执行到结束)
备选流:采用不同颜色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中,也可以起源于另一个备选流,或终止用例,不在加入到基本流中;(各种错误情况)
有一个在线购物的实例,用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用帐号登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。
第一步我们来确定基本流和备选流:
基本流 | 登录在线购物网站,选择物品,登录帐号,付钱交易,生成订购单 |
---|---|
备选流1 | 帐号不存在 |
备选流2 | 帐号或密码错误 |
备选流3 | 用户帐号余额不足 |
备选流4 | 用户帐号没有钱 |
备选流x | 用户退出系统 |
第二步我们根据基本流和备选流来确定场景:
场景1-成功购物 | 基本流 | |
---|---|---|
场景2-帐号不存在 | 基本流 | 备选流1 |
场景3-帐号或密码错误 | 基本流 | 备选流2 |
场景4-用户帐号余额不足 | 基本流 | 备选流3 |
场景5-用户帐号没有钱 | 基本流 | 备选流4 |
第三步我们来设计用例
对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。
测试用例ID | 场景/条件 | 帐号 | 密码 | 用户帐号余额 | 预期结果 |
---|---|---|---|---|---|
1 | 场景1:成功购物 | V | V | V | 成功购物 |
2 | 场景2:帐号不存在 | I | I | 提示帐号不存在 | |
3 | 场景3:帐号或密码错误(帐号正确,密码错误) | V | I | 提示帐号或密码错误,返回基本流步骤3 | |
4 | 场景3:帐号或密码错误(帐号错误,密码正确) | I | V | 提示帐号或密码错误,返回基本流步骤3 | |
5 | 场景4:用户帐号余额不足 | V | V | I | 提示帐号余额不足请充值 |
6 | 场景5:用户帐号没有钱 | V | V | I | 提示帐号余额请充值 |
四、因果图法
因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法。如果程序的功能中含有输入条件的组合情况,应在一开始就选用因果图法。
利用因果图生成测试用例的步骤为:
(1)将规范说明书分解成可执行的片段。
(2)确定规格说明书中的因果关系。分析软件规格说明描述中哪些是原因,哪些是结果,并给每个原因和结果赋予一个标识符。
(3)分析软件规格说明描述的语义,找出原因和结果之间、原因和原因之间的关系,并将其转换成因果图。
(4)在因果图上加上注解符号,用一些记号表明约束或限制条件。
(5)跟踪图中的状态变化情况,把因果图转换为判定表。
(6)把判定表的每一列拿出来作为依据,设计测试用例。
(1) 例:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。解答过程如下:
画出因果关系表和因果图。
(2) 根据因果图建立判定表。
按条件的各种组合情况产生对应的动作。原因1和原因2不能同时成立,故可排除这种情况。
从判定表可设计出测试用例:6个测试用例是所需的数据。
五、错误推测法
错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误,从而有针对性地设计测试用例的方法。
六、测试方法的综合策略
1)在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2)必要时用等价类划分方法补充一些测试用例。
3)用错误推测法再追加一些测试用例。
4)对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例。
5)如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。