软件测试——测试用例

错误猜测法是对被测试软件设计的理解过往经验以及个人直觉推测出软件可能存在的缺陷从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致这类方法在敏捷开发模式下的投入产出比很高被广泛应运于测试。
这个方法的缺点是难以系统化并且过度依赖个人能力。

判定表法使用于关系组合

这里所介绍的是判定表法而不是因果图法因为因果图法的第一步是确定输入输出条件然后找出输入和输出之间的关系接着画因果图然后再将因果图转换为判定表个人觉得因果图这一步既麻烦用处也不大我们完全可以根据输入条件和输出条件来画判定表直接省略因果图这一步。

设计步骤

确定输入条件和输出条件。
找出输入条件和输出条件之间的关系。
画判定表。
根据判定表编写测试用例。

具体例子

假设业务单据的处理规则为“淘宝618活动订单已提交订单合计金额大于300元或有红包则进优惠”。

1.确定输入条件和输出条件

● 输入订单已提交、金额大于300、有红包。
● 输出优惠、不优惠。

2.找出输入条件和输出条件之间的关系

(1)订单已提交订单金额大于300元则优惠。
(2)订单已提交订单金额小于等于300元无红包不优惠
(3)订单已提交有红包则优惠。
(4)订单已提交订单金额大于300元有红包则优惠。
(5)订单未提交不优惠。

3.画判定表

4.根据判定表编写测试用例

1)金额大于300元没有红包提交订单结果为有优惠

2) 金额不大于300元有红包提交订单结果为有优惠

3)金额大于300元有红包提交订单结果为有优惠

4)金额不大于300元没有红包提交订单结果为无优惠

5)金额大于300元没有红包不提交订单结果为无优惠

6)金额不大于300元有红包不提交订单结果为无优惠

7)金额大于300元有红包不提交订单结果为无优惠

8)金额不大于300元没有红包不提交订单结果为无优惠

正交法

正交法需要用到我们的正交表而正交表由因素数和水平数来构成。

比如我们下面这个例子用户注册信息的填写。

那么因素数就是姓名电子邮箱密码确认密码验证码。

水平数为填写与不填写。

正交表的两条性质
每一列中各数字出现的次数都一样多。
任何两列中的各有序数对出现的次数都一样多。

我们的正交表通常是很难写的所以我们常借助allpairs工具来生成:

步骤

1.找到因素数和水平数:

因素数姓名电子邮箱密码确认密码验证码。

水平数填写不填写。

2.allpairs工具来生成正交表

3.根据正交表来编写测试用例
1) 全部填写姓名电子邮箱密码确认密码验证码

2) 填写姓名不填写电子邮箱密码确认密码验证码

3) 填写电子邮箱确认密码不填写姓名密码验证码

4) 填写密码、验证码不填写姓名电子邮箱确认密码

5) 填写姓名电子邮箱密码不填写确认密码验证码

6) 填写姓名确认密码验证码不填写电子邮箱密码

4.补充其它的测试用例

针对上面我们可以再次补充一条不填写电子邮箱确认密码姓名密码验证码。

场景设计法

现在的软件几乎都是用事件触发来控制流程的事件触发时的情景便形成了场景而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景有利于测试设计者设计测试用例是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来为测试人员建立整体业务感觉从而避免陷入功能细节忽视业务流程要点的错误倾向。