软件测试--测试用例

Posted 2021-06-11 Kirl z

软件测试--测试用例（二）

• 1. 设计测试用例的方法
• • 1.1 因果图法
  • 1.2 正交法
  • 1.3 场景法
  • 1.4 错误猜测法

1. 设计测试用例的方法

1.1 因果图法

因果图是一种逻辑图, 能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。
当输入有很多, 不同输入的组合对应不同的输出, 用因果图来分析不同输入组合和不同输出之间的关系

• 恒等
  

• 与
  

• 或
  

• 非
  

用因果图法设计测试用例的步骤
(1) 分析出所有的输入, 输出
(2) 找出输入输出之间的逻辑关系
(3) 根据输入输出之间的关系画因果图
(4) 根据因果图画判定表
(5) 根据判定表设计测试用例

示例:
“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”。

1. 分析输入输出
   ● 输入：订单已提交、订单没有提交、金额大于300、金额小于等于300、有红包、没有红包。
   ● 输出：优惠、不优惠。
2. 关系
   (1)订单已提交，订单金额大于300元，无红包，优惠。
   (2)订单已提交，订单金额小于等于300元，无红包，不优惠
   (3)订单已提交，订单金额小于等于300元，有红包，优惠。
   (4)订单已提交，订单金额大于300元，有红包，优惠。
   (5)订单未提交，不优惠。
3. 画因果图
   
4. 画判定表
   
5. 写测试用例
   订单已提交, 金额大于300, 有红包, 有优惠
   订单已提交, 金额大于300, 没有红包, 有优惠
   订单已提交, 金额小于等于300, 有红包, 有优惠
   订单已提交, 金额小于等于300, 没有红包, 没有优惠
   订单未提交, 金额大于300, 没有红包, 没有优惠
   订单未提交, 金额小于等于300, 有红包, 没有优惠
   订单未提交, 金额小于等于300, 没有红包, 没有优惠
   订单未提交, 金额大于300, 有红包, 没有优惠

1.2 正交法

研究多因素多水平的一种实验 (测试) 方法. 根据正交性, 从输入组合当中选取最优的组合进行实验, 分析结果, 通过这些最优组合得出的实验结果来分析这个实验的结果

因素: 输入的变量
水平: 变量的取值
正交表的构成:
列: 因素数, 变量的个数
水平数: 每个变量的最大个数
行: L(正交表的行) = (水平数 - 1) * 因素数 + 1

正交表的性质:
(1) 每一列不同数据出现的次数一致
(2) 任意两列不同数据的组合出现的次数一样

正交表设计测试用例的步骤:

1. 确定所有的输入 (变量)
2. 确定每一个变量的取值的个数
3. 确定因素数 (正交表的列), 水平数 正交表的行: L(正交表的行) = (水平数 - 1) * 因素数 + 1
4. 根据正交表的性质, 把变量的值映射到表中
5. 写测试用例, 正交表的每一行就是一个测试用例
6. 补充正交表中没有的但是你认为可能出现的测试用例

示例:

姓名、邮箱、密码、确认密码、验证码
只考虑每一项输入不输入两种情况

1. 确定因素数
   因素: 姓名、邮箱、密码、确认密码、验证码
   因素数: 5

2. 确定水平数
   水平数: 2

3. 正交表的列 = 因素数 5
   正交表的行 = (水平数 - 1) * 因素数 + 1 = 1 * 5 + 1 = 6

4. 测试用例
   

5. 写测试用例
   姓名填写, 邮箱不填写, 密码填写, 确认密码不填写, 验证码填写
   姓名不填写, 邮箱填写, 密码不填写, 确认密码填写, 验证码不填写
   姓名不填写, 邮箱不填写, 密码填写, 确认密码不填写, 验证码不填写
   姓名填写, 邮箱填写, 密码不填写, 确认密码不填写, 验证码填写
   姓名填写, 邮箱填写, 密码填写, 确认密码填写, 验证码不填写
   姓名不填写, 邮箱不填写, 密码不填写, 确认密码填写, 验证码不填写

1.3 场景法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

根据场景法设计测试用例: 把场景中的每一个功能点提出来, 考虑功能点可能的不同的情况, 根据这些情况去设计测试用例

1.4 错误猜测法

错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。

基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。