测试用例设计————场景分析法
定义
分析软件应用的场景,从用户的角度出发,从场景的角度来设计测试用例,是一种面向用户的测试用例设计方法。
优点:实用性强,有效,设计出来的用例有价值
缺点:可能使用的场景不一定能对时间系列进行全面的分析,设计出来的用例不完整。
场景分析是通过描述经用例路径来确定的过程,这个流程经过要从用例开始到结束遍历其中所有基本流:直黑线表示基本流,是最基本、最简单的路径;(软件功能按照正确的事件流实现的一条正确流程无任何错误,程序从开始直到结束)。
遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:
场景1 | 基本流 | |||
---|---|---|---|---|
场景2 | 基本流 | 备选流1 | ||
场景3 | 基本流 | 备选流1 | 备选流2 | |
场景4 | 基本流 | 备选流3 | ||
场景5 | 基本流 | 备选流3 | 备选流1 | |
场景6 | 基本流 | 备选流3 | 备选流1 | 备选流2 |
场景7 | 基本流 | 备选流4 | ||
场景8 | 基本流 | 备选流3 | 备选流4 |
注:为方便起见,场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。
用场景分析法设计测试用例的步骤:
1.根据说明,画出流程图,确定基本流和备选流;
2.根据基本流和各项备选流确定场景;
3.对每一个场景生成测试用例;
4.对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测试用例确定测试数据值。
用例场景示例
用户登录到网站后,进行书籍的选择,当选好自己心仪的书籍后进行订购,这时把所需图书放进购物车,等进行结帐的时候,用户需要登录自己注册的帐号,登录成功后,进行付款交易,交易成功后,生成订购单,整个购物过程结束。
第一步:画出流程图,确定基本流和备选流;
基本流:登录在线网站→选择课程/方案,放入购物车→登录账号→付款→生成订单
备选流1:用户不存在→注册用户
备选流2:密码不正确
备选流3:账户余额不足→充值
备选流 4 :账户无金额→充值
第二步:根据基本流和各项备选流确定场景;
场景1(成功购物):基本流;
场景2(账户不存在):基本流 备选流1
场景3(账户密码错误):基本流 备选流2
场景4(账户余额不足):基本流 备选流3
场景 5(账户无金额):基本流 备选流4
第三步:对每一个场景生成测试用例;
用例编号 | 场景描述 | 步骤描述 | 输入 | 预期结果 |
---|---|---|---|---|
1 | 场景1:成功购物 | 登录HB | ||
2 | 选择方案/视频,放入购物车 | |||
3 | 登录账号 | |||
4 | 付款 | |||
5 | 生成订单 | 成功购物 | ||
场景2:账户不存在 | 登录HB | |||
选择方案/视频,放入购物车 | ||||
登录账号 | ||||
账号不存在,注册用户 | 提示账号不存在,返回基本流程步骤4 | |||
登录账号 | ||||
付款 | ||||
生成订单 | ||||
场景3:账户密码错误 | 登录HB | |||
选择方案/视频,放入购物车 | ||||
登录账号 | ||||
密码错误,重新输入登录 | 提示账号密码错误,返回基本流步骤4 | |||
付款 | ||||
生成订单 | ||||
场景4:账户余额不足 | 登录HB | |||
选择方案/视频,放入购物车 | ||||
登录账号 | ||||
付款 | ||||
余额不足,充值 | 提示账号余额不足,请充值;返回基本流步骤5 | |||
付款 | ||||
生成订单 | ||||
场景5:账户无金额 | 登录HB | |||
选择方案/视频,放入购物车 | ||||
登录账号 | ||||
付款 | ||||
账号无金额,充值 | 提示账号无余额,请充值;返回基本流步骤5 | |||
付款 | ||||
生成订单 |
第四步:对生成的所有测试用例重新复审,补充测试数据值
用例编号 | 场景描述 | 步骤描述 | 输入 | 预期结果 |
---|---|---|---|---|
1 | 场景1:成功购物 | 登录HB | ||
2 | 选择方案/视频,放入购物车 | 总价:80元人民币 | ||
3 | 登录账号 | 账号:张三,密码:123456 | ||
4 | 付款 | 账号余额:200元 | ||
5 | 生成订单 | 成功购物 | ||
场景2:账户不存在 | 登录HB | |||
选择方案/视频,放入购物车 | 总价:80元人民币 | |||
登录账号 | 账号:李四1,密码:123456 | |||
账号不存在,注册用户 | 提示账号不存在,返回基本流程步骤4 | |||
登录账号 | ||||
付款 | 账号余额:200元 | |||
生成订单 | ||||
场景3:账户密码错误 | 登录HB | |||
选择方案/视频,放入购物车 | 总价:80元人民币 | |||
登录账号 | 账号:张三,密码:12345 | |||
密码错误,重新输入登录 | 提示账号密码错误,返回基本流步骤4 | |||
付款 | 账号余额:200元 | |||
生成订单 | ||||
场景4:账户余额不足 | 登录HB | |||
选择方案/视频,放入购物车 | 总价:80元人民币 | |||
登录账号 | 账号:王五,密码:123456 | |||
付款 | ||||
余额不足,充值 | 账号余额:30元 | 提示账号余额不足,请充值;返回基本流步骤5 | ||
付款 | ||||
生成订单 | ||||
场景5:账户无金额 | 登录HB | |||
选择方案/视频,放入购物车 | 总价:80元人民币 | |||
登录账号 | 账号:张华,密码:123456 | |||
付款 | ||||
账号无金额,充值 | 账号余额:无余额 | 提示账号无余额,请充值;返回基本流步骤5 | ||
付款 | ||||
生成订单 |
提款测试用例
基本流/备用流 | 流程描述 |
---|---|
基本流 | 本用例的开端是 ATM 处于准备就绪状态。 准备提款 - 客户将银行卡插入 ATM 机的读卡机。 验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码,并检查它是否属于可以接收的银行卡。 输入 PIN - ATM 要求客户输入 PIN 码(4 位) 验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是否正确。对于此事件流,帐户是有效的而且 PIN 对此帐户来说正确无误。 ATM 选项 - ATM 显示在本机上可用的各种选项。在此事件流中,银行客户通常选择“提款”。 输入金额 - 要从 ATM 中提取的金额。对于此事件流,客户需选择预设的金额(10 美元、20 美元、50 美元或 100 美元) 。 授权-ATM 通过将卡 ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流,银行系统处于联机状态,而且对授权请求给予答复,批准完成提款过程,并且据此更新帐户余额。 出钞 - 提供现金。 返回银行卡 - 银行卡被返还。 收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。 用例结束时 ATM 又回到准备就绪状态。 |
备选流 1 - 银行卡无效 | 在基本流步骤 2 中 - 验证银行卡,如果卡是无效的,则卡被退回,同时会通知相关消息。 |
备选流 2 - ATM 内没有现金 | 在基本流步骤 5 中 - ATM 选项,如果 ATM 内没有现金,则“提款”选项将无法使用。 |
备选流 3 - ATM 内现金不足 | 在基本流步骤 6 中- 输入金额,如果 ATM 机内金额少于请求提取的金额,则将显示一则适当的消息,并且在步骤 6 - 输入金额处重新加入基本流。 |
备选流 4 - PIN 有误 | 在基本流步骤 4 中- 验证帐户和 PIN,客户有三次机会输入 PIN。 如果 PIN 输入有误,ATM 将显示适当的消息;如果还存在输入机会,则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。 如果最后一次尝试输入的 PIN 码仍然错误,则该卡将被 ATM 机保留, 同时 ATM 返回到准备就绪状态,本用例终止。 |
备选流 5 - 帐户不存在 | 在基本流步骤 4 中 - 验证帐户和 PIN,如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款,则 ATM 显示适当的消息并且在步骤 9 - 返回银行卡处重新加入基本流。 |
备选流 6 - 帐面金额不足 | 在基本流步骤 7 - 授权中,银行系统返回代码表明帐户余额少于在基本流步骤 6 - 输入金额内输入的金额,则 ATM 显示适当的消息并且在步骤 6 - 输入金额处重新加入基本流。 |
备选流 7 - 达到每日最大的提款 金额 | 在基本流步骤7- 授权中, 银行系统返回的代码表明包括本提款请求在内,客户已经或将超过在 24 小时内允许提取的最多金额,则 ATM 显示适当的消息并在步骤 6 - 输入金额上重新加入基本流。 |
备选流 x - 记录错误 | 如果在基本流步骤 10 - 收据中,记录无法更新,则 ATM 进入“安全模式”,在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明 ATM 已经暂停工作。 |
备选流 y - 退出 | 客户可随时决定终止交易(退出) 。交易终止,银行卡随之退出。 |
备选流 z - “翘起” | ATM 包含大量的传感器,用以监控各种功能,如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻,如果某个传感器被激活,则警报信号将发送 给警方而且 ATM 进入“安全模式”,在此模式下所有功能都暂停使用,直到采取适当的重启/重新初始化的措施。 |
第一次迭代中,根据迭代计划,我们需要核实提款用例已经正确地实施。此时尚未实施整个用例,只实
施了下面的事件流:
基本流 - 提取预设金额(10 美元、20 美元、50 美元、100 美元)
备选流 2 - ATM 内没有现金
备选流 3 - ATM 内现金不足
备选流 4 - PIN 有误
备选流 5 - 帐户不存在/帐户类型有误
备选流 6 - 帐面金额不足
以从这个用例生成下列场景
场景描述 | 基本流/备用流 | 基本流/备用流 |
---|---|---|
场景1 - 成功的提款 | 基本流 | |
场景2 - ATM 内没有现金 | 基本流 | 备选流2 |
场景3 - ATM 内现金不足 | 基本流 | 备选流3 |
场景4 - PIN 有误(还有输入机会) | 基本流 | 备选流4 |
场景5 - PIN 有误(不再有输入机会) | 基本流 | 备选流4 |
场景 6 - 帐户不存在/帐户类型有误 | 基本流 | 备选流 5 |
场景 7 - 帐户余额不足 | 基本流 | 备选流 6 |
表1-3 提款场景
注:为方便起见,备选流 3 和 6(场景 3 和 7)内的循环以及循环组合未纳入上表。
对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表 测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例 ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。然后,对于每个场景,至少要确定包含执行场景所需的适当条件的测试用例。例如,在下面的矩阵 中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流。下表中使用的“n/a”(不适用)表明这个条件不适用于测试用例。
表1-4 用例矩阵
TC(测试用例)ID 号 | 场景/条件 | PIN | 帐号 | 输入的金额(或选择的金 额) | 帐面 金额 | ATM 内的金额 | 预期结果 |
---|---|---|---|---|---|---|---|
CW1. | 场景1 - 成功的提款 | V | V | V | V | V | 成功的提款。 |
CW2. | 场景2 - ATM 内没有现金 | V | V | V | V | I | 提款选项不可用,用例结束 |
CW3. | 场景3 - ATM 内现金不足 | V | V | V | V | I | 警告消息,返回基本流步骤6 -输入金额 |
CW4. | 场景4 -PIN 有误(还有不止一次输入机会) | I | V | n/a | V | V | 警告消息,返回基本流步骤4,输入PIN |
CW5. | 场景4 -PIN 有误(还有一次输入机会) | I | V | n/a | V | V | 警告消息,返回基本流步骤4, 输入PIN |
CW6. | 场景4 -PIN 有误(不再有输入机会) | I | V | n/a | V | V | 警告消息,卡予保留,用例结束 |
在上面的矩阵中,六个测试用例执行了四个场景。对于基本流,上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行,未发生任何偏差。基本流的全面测试必须包括负面测试用例,以确保只有在符合条件的情况下才执行基本 流。这些负面测试用例由 CW2 至 6 表示(阴影单元格表明这种条件下需要执行备选流)。虽然 CW2 至 6 对于基本流而言都是负面测试用例,但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言,至少存在一个负面测试用例(CW1 - 基本流)。
每个场景只具有一个正面测试用例和负面测试用例是不充分的,场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误,至少需要三个正面测试用例(以激活场景 4):
输入了错误的 PIN,但仍存在输入机会,此备选流重新加入基本流中的步骤 3 - 输入 PIN。
输入了错误的 PIN,而且不再有输入机会,则此备选流将保留银行卡并终止用例。
最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。
注:在上面的矩阵中,无需为条件(数据)输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I(或此处采用的阴影单元格),这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格,这表明测试用例还不完 全,如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。
一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。
测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据。
表1-5 实际用例
TC ( 测试用例)ID 号 | 场景/条件 | PIN | 帐号 | 输入的金额或 选择的金额 | 帐面金额 | ATM 内的金额 | 预期结果 |
---|---|---|---|---|---|---|---|
CW1. | 场景1 - 成功的提款 | 4987 | 809 - 498 | 50.00 | 500.00 | 2,000 | 成功的提款。帐户 余额被更新为450.00 |
CW2. | 场景2 - ATM 内没有现金 | 4987 | 809 - 498 | 100.00 | 500.00 | 0.00 | 提款选项不可用,用例结束 |
CW3. | 场景3 - ATM 内现金不足 | 4987 | 809 - 498 | 100.00 | 500.00 | 70.00 | 警告消息,返回基本流步骤6-输入金额 |
CW4. | 场景4 - PIN 有误(还有不止一次输入机会) | 4978 | 809 - 498 | n/a | 500.00 | 2,000 | 警告消息,返回基本流步骤4,输入PIN |
CW5. | 场景4 - PIN 有误(还有一次输入机会) | 4978 | 809 - 498 | n/a | 500.00 | 2,000 | 警告消息,返回基本流步骤4,输入PIN |
CW6. | 场景4 - PIN 有误(不再有输入机会) | 4978 | 809 - 498 | n/a | 500.00 | 2,000 | 警告消息,卡予保留, 用例结束 |
以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括:
场景 6 - 帐户不存在/帐户类型有误:未找到帐户或帐户不可用
场景 6 - 帐户不存在/帐户类型有误:禁止从该帐户中提款
场景 7 - 帐户余额不足:请求的金额超出帐面金额
在将来的迭代中,当实施其他事件流时,在下列情况下将需要测试用例:
无效卡(所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等).
无法读卡(读卡机堵塞、脱机或出现故障).
帐户已消户、冻结或由于其他方面原因而无法使用.
ATM 内的现金不足或不能提供所请求的金额(与 CW3 不同,在 CW3 中只是一种币值不足,而不是所有币值都不足).
无法联系银行系统以获得认可.
银行网络离线或交易过程中断电.
分析
what?
分析软件应用场景,从用户角度出发,从场景角度设计测试用例,是一种面向用户的测试用例设计方法。
- 基本流:经过用例的最简单路径(正常流程)
- 备选流:一个备选流可以从基本流开始,在某个特定条件下执行,然后重新加入基本流中;也可以起源于另一个备选流,或终止用例。(当备选流不再加入基本流时,备选流一般为错误流程)
why?
从用户角度出发,是一种面向用户的测试用例设计方法。
how?
1.根据需求,描述出程序的基本流以及各项备选流
2.根据基本流和各项备选流生成不同的场景
3.对每一个场景生成相应的测试用例
4.对生成的测试用例重新复审,去掉多余的测试用例
5.测试用例确定后,为每一个测试用例确定测试数据值