使用用例场景,设计测试用例。

本文详细介绍了测试用例的概念、设计方法和好处,强调了用例场景在测试设计中的重要性。测试用例是软件测试的核心,好的用例能有效发现错误。通过等价类划分、边界值分析等黑盒测试方法和逻辑覆盖等白盒测试方法设计用例。用例场景定义了用例的执行路径,帮助设计出涵盖各种情况的测试场景。

使用用例场景,设计测试用例

作者:周毅

概念和定义

不完全、不彻底是软件测试的致命缺陷,任何程序只能进行少量而有限的测试。测试用例在此情况下产生,同时它也是软件测试系统化、工程化的产物。而测试用例的设计一直是软件测试工作的重点和难点.

 

什么是测试用例?

为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据,称之为测试用例。我们不可能进行穷举测试,为了节省时间和资源、提高测试效率,必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。

 

怎样的用例算是好用例?

一个好的测试用例是在于它能发现至今未发现的错误。

 

使用测试用例的好处

在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。

在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期。

功能模块的通用化和复用化使软件易于开发,而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展,并随着测试用例的不断精化其效率也不断攀升。

 

设计测试用例的方法

u     黑盒测试:

等价类划分法

边界值分析法

错误推测法

因果图法

u     白盒测试:

逻辑覆盖法

基本路径测试法

 

测试用例的设计过程

测试设计员(分析设计员)依据不同阶段的测试计划、设计模型和实施模型来设计该阶段测试用例。

测试设计员是具有丰富测试经验或具有软件分析设计能力的高级测试工程师。如果没有测试设计员,则可用分析设计员代替。

针对白盒,还应有驱动程序和桩模块。

 

测试点的确定

u     ISO 质量体系:

在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。

u     CMM 质量体系:

在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程,每一个用例模型为一个测试点,用例模型中每一个测试需求至少应有两个测试用例。

 

理解上的误区

测试用例应由测试设计员或分析设计员来制定,而不是普通的测试员。

测试点应由分析设计员确立,与测试人员无关。

测试工作展开于项目立项后,而不是代码开发完成之后。

测试对象不仅仅是源代码,还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档。

 

用例场景的定义

用例场景是通过描述流经用例的路径来确定的过程,这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

 

为什么引入用例场景

现在的软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中,生动的描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时测试用例也更容易的得到理解和执行。

提出这种测试思想的是Rational 公司,在RUP2000 中文版当中有其详尽的解释和应用,用例场景贯穿其中。

 

用例场景例子

下图中经过用例的每条不同路径都反映了基本流和备选流,都用箭头来表示。基本流用直黑线来表示,是经过用例的最简单的路径。每个备选流自基本流开始,之后,备选流会在某个特定条件下执行。备选流可能会重新加入基本流中(备选流 1 和 3),还可能起源于另一个备选流(备选流 2),或者终止用例而不再重新加入某个流(备选流 2 和 4)

 

 


1-1 测试用例流

遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:

场景 1        基本流

场景 2        基本流        备选流 1

场景 3        基本流        备选流 1      备选流 2

场景 4        基本流        备选流 3

场景 5        基本流        备选流 3      备选流 1

场景 6        基本流        备选流 3      备选流 1      备选流 2

场景 7        基本流        备选流 4

场景 8        基本流        备选流 3      备选流 4

注:为方便起见,场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

 

生成每个场景的测试用例是通过确定某个特定条件来完成的,这个特定条件将导致特定用例场景的执行。

测试用例例子

假定上图描述的用例对备选流 3 规定如下:

“如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额,则出现此事件流。系统将显示一则警告消息,之后重新加入基本流,再次执行上述步骤 2‘输入提款金额’,此时银行客户可以输入新的提款金额。”

据此,可以开始确定需要用来执行备选流 3 的测试用例:

 

1-1 备选流 3 的测试用例

测试用例ID

场景

条件

预期结果

TC x

场景4

步骤2 - 提款金额> 帐户余额

在步骤2 处重新加入基本流

TC y

场景4

步骤2 - 提款金额< 帐户余额

不执行备选流3,执行基本流

TC z

场景4

步骤2 - 提款金额= 帐户余额

不执行备选流3,执行基本流

 

 

 

 

 

 

 

 


注:由于没有提供其他信息,以上显示的测试用例都非常简单。测试用例很少如此简单。

下面是一个由用例生成测试用例的更符合实际情况的示例。

 




1-2 用例实例

一台 ATM 机器的主角和用例。

 

下表包含了上图中提款用例的基本流和某些备用流:

 

 

 

 

 

 

 

1-2 提款测试用例

基本流

本用例的开端是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 中只是一种币值不足,而不是所有币值都不足).

无法联系银行系统以获得认可.

银行网络离线或交易过程中断电.

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值