回顾测试用例的概念:
测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素,还有其他的,包括测试前提,测试版本,功能模块,重要性,标题
- 设计测试用例的好处
(1)可以评估测试的覆盖率
(2)可以重复使用(做回归测试的时候)
(3)后辈借鉴,学习,汲取经验 - 总的测试用例设计方法
基于需求的设计:要保证需求的正确性和完整性,逻辑要一致,验证需求(用户需求和软件需求) - 黑盒测试用例设计的方法
(1)等价类
依据需求将输入(特殊情况下会考虑输出)划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题。
有效等价类:对于程序的规格说明书是合理的、有意义的输入数据构成的集合,利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
无效等价类:根据需求说明书,不满足需求的集合
(2)边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
(3)因果图
因果图是一种简化了的逻辑图,能直观地表明程序输入条件(原因)和输出动作(结果)之间的相互关系。
适用场景:被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况
因果图法设计测试用例的步骤如下:
(1)分析所有可能的输入和可能的输出。
(2)找出输入与输出之间的对应关系。
(3)画出因果图。
(4)把因果图转换成判定表。
(5)把判定表对应到每一个测试用例。
例:618活动,订单提交,订单金额合计大于300或者有红包,则有优惠,
1.对于这条业务规则,首先通过分析所有可能的输入和可能的输出,可以得到如下结果:
● 输入:订单已提交、金额大于300、有红包。
● 输出:优惠、不优惠。
2.然后,进行第二步,找出输入与输出之间的对应关系。
(1)订单已提交,订单金额大于300元,无红包,有优惠。
(2)订单已提交,订单金额小于300元,有红包,有优惠
(3)订单已提交,订单金额大于300元,有红包,有优惠。
(4)订单已提交,订单金额小于300元,无红包,无优惠。
(5)订单未提交,订单金额大于300元,无红包,无优惠。
(6)订单未提交,订单金额小于300元,有红包,无优惠
(7)订单未提交,订单金额大于300元,有红包,无优惠。
(8)订单未提交,订单金额小于300元,无红包,无优惠。
3.画因果图
4.画判定表
5.测试用例
(4)正交法
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法,原理是根据正交性,选出输入的最优的组合进行测试,分析这些测试的结果,以分析整个实验的结果
因素:测试中需要考察的变量(变量);因素数:变量的个数
水平:一个变量的取值;水平数(T):变量的取值(每个变量的水平数一般不同)
例如:注册功能,姓名、邮箱、密码、确认密码、验证码(均为必填项,这里只考虑填与不填),则共有2^5=32种可能出现的结果,因素有姓名、邮箱、密码、确认密码、验证码,因素数为5,水平为填、不填,水平数为2(这里较为特殊,每个变量的水平数相同)
因素数是正交表列的个数(C)
正交表L=N(CT),其中N为正交表的行数
当每个变量的水平数相等时,N=(水平数-1)*因素数+1
正交表的两条性质:
a. 每一列中各数字出现的次数都一样多。
b. 任何两列所构成的各有序数对出现的次数都一样多
如何根据正交法设计测试用例(步骤):
1,找出因素,因素数,水平,水平数
2,根据因素数和水平数选择一个合适的正交表
3,根据正交表的性质填写正交表
4,根据完成的正交表设计测试用例,每一行为一个测试用例
5,补充认为可能的测试用例
(5)场景法
把各个孤立的功能点串起来想成一个业务场景进行测试,分为基本事件流和备选事件流
这里以ATM机银行卡取款为例:插卡-输入密码-输入金额-取钱-退卡
基本流程:插卡成功,密码输入成功,输入金额小于银行卡余额,出钞成功,退卡
备选流程:
1,插卡失败(卡芯片损坏,卡识别不出来)
2,连续三次密码输入失败,账户锁定
3,前两次输入密码失败,最后一次输入成功,输入金额小于银行卡余额,出钞成功,退卡
4,银行卡没有激活
5,输入金额大于银行卡余额,再次输入金额小于银行卡余额,出钞成功,退卡
6,ATM余额不足
7,操作等待时间太长,ATM吞卡
8,身份证信息过期
9,网络异常
10,输入的金额不是100的整数倍,或超过5万
…
(6)错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。
基于经验和直觉,找出程序中认为可能出现的错误,有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多,也可以来自于售后用户的反馈意见,或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题,问题越多的地方,潜在的bug也就越多。