指南测试用例测试用例是为某个特殊目标而编制的一组测试输入执行条件以及预期结果15页Word文件下载.docx
《指南测试用例测试用例是为某个特殊目标而编制的一组测试输入执行条件以及预期结果15页Word文件下载.docx》由会员分享，可在线阅读，更多相关《指南测试用例测试用例是为某个特殊目标而编制的一组测试输入执行条件以及预期结果15页Word文件下载.docx（24页珍藏版）》请在冰点文库上搜索。
需条件下才能够满足该需求，这个测试用例称作负面测试用例。
从用例中生成测试用例
用于功能性测试的测试用例来源于测试目标的用例（请参见工件：
用例）。
应该
为每个用例场景编制测试用例。
用例场景要通过描述流经用例的路径来确定，这
个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表
示。
基本流用直黑线来表示，是经过用例的最简单的路径。
每个备选流自基本流
开始，之后，备选流会在某个特定条件下执行。
备选流可能会重新加入基本流中
（备选流1和3），还可能起源于另一个备选流（备选流2），或者终止用例
而不再重新加入某个流（备选流2和4）。
用例的事件流示例
遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。
从基本流开始，
再将基本流和备选流结合起来，可以确定以下用例场景：
场景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的测试用例：
ID
场景条件预
期结果
TCx场景4步骤2-提款金额>
帐户余额在
步骤2处重
新加入基本流
TCy场景4步骤2-提款金额<
帐户余额不
执行备选流
3，
执行基本流TCz场景4步骤2-提款金额=帐户余额不
执行基本流
由于没有提供其他信息，以上显示的测试用例都非常简单。
测试用例很少如
此简单。
下面是一个由用例生成测试用例的更符合实际情况的示例
示例：
一台ATM机器的主角和用例。
下表包含了上图中提款用例的基本流和某些备用流：
基本流本用例的开端是ATM处于准备就绪状态。
1.准备提款-客户将银行卡插入ATM机的读卡机。
2.验证银行卡-ATM机从银行卡的磁条中读取帐户代
码，并检查它是否属于可以接收的银行卡。
3.输入PIN-ATM要求客户输入PIN码（4位）
4.验证帐户代码和PIN-验证帐户代码和PIN以确定
该帐户是否有效以及所输入的PIN对该帐户来说是否
正确。
对于此事件流，帐户是有效的而且PIN对此帐
户来说正确无误。
5.ATM选项-ATM显示在本机上可用的各种选项。
在
此事件流中，银行客户通常选择“提款”。
6.输入金额-要从ATM中提取的金额。
对于此事件流，
客户需选择预设的金额（10美元、20美元、50美元
或100美元）。
7.授权-ATM通过将卡ID、PIN、金额以及帐户信息作
为一笔交易发送给银行系统来启动验证过程。
对于此事
件流，银行系统处于联机状态，而且对授权请求给予答
复，批准完成提款过程，并且据此更新帐户余额。
8.出钞-提供现金。
9.返回银行卡-银行卡被返还。
10.收据-打印收据并提供给客户。
ATM还相应地更新内
部记录。
用例结束时ATM又回到准备就绪状态。
备选流1-
银行卡无效
在基本流步骤2中-验证银行卡，如果卡是无效的，则卡被
退回，同时会通知相关消息。
备选流2-在基本流步骤5中-ATM选项，如果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有误（不再
有输入机会）
场景6-帐户不存在/帐
户类型有误
基本流备选流5
场景7-帐户余额不足基本流备选流6
为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入
上表。
对于这7个场景中的每一个场景都需要确定测试用例。
可以采用矩阵或决策表
来确定和管理测试用例。
下面显示了一种通用格式，其中各行代表各个测试用例，
而各列则代表测试用例的信息。
本示例中，对于每个测试用例，存在一个测试用
例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存
在于数据库中）以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。
然后，对于每个场景，
至少要确定包含执行场景所需的适当条件的测试用例。
例如，在下面的矩阵中，
V（有效）用于表明这个条件必须是VALID（有效的）才可执行基本流，而I（无
效）用于表明这种条件下将激活所需备选流。
下表中使用的“n/a”（不适用）
表明这个条件不适用于测试用例。
TC
（测
试用
例）
号
场景/条件PIN
帐号
输入的
金额
（或
选择
的金
帐面金
ATM
内的金
预期结果
额）
CW1.场景1-成
功的提款
VVVVV成功的提
款。
CW2.场景2-
VVVVI提款选项不
可用，用例
结束
CW3.场景3-
VVVVI警告消息，
返回基本流
步骤6-输
入金额
CW4.场景4-PIN
有误（还有
不止一次输
入机会）
I
Vn/aVV警告消息，
步骤4，输
入PIN
CW5.场景4-PIN
一次输入机
会）
CW6.场景4-PIN
有误（不再
有输入机
卡予保留，
用例结束
在上面的矩阵中，六个测试用例执行了四个场景。
对于基本流，上述测试用例CW1
称为正面测试用例。
它一直沿着用例的基本流路径执行，未发生任何偏差。
基本
流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基
本流。
这些负面测试用例由CW2至6表示（阴影单元格表明这种条件下需要执
行备选流）。
虽然CW2至6对于基本流而言都是负面测试用例，但它们相对于
备选流2至4而言是正面测试用例。
而且对于这些备选流中的每一个而言，至
少存在一个负面测试用例（CW1-基本流）。
每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景4正是这
样的一个示例。
要全面地测试场景4-PIN有误，至少需要三个正面测试用例
（以激活场景4）：
输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3-输
入PIN。
输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
最后一次输入时输入了“正确”的PIN。
备选流在步骤5-输入金额处重新加入基本
流。
在上面的矩阵中，无需为条件（数据）输入任何实际的值。
以这种方式创建
测试用例矩阵的一个优点在于容易看到测试的是什么条件。
由于只需要查看V
和I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的
测试用例。
从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还
不完全，如场景6-不存在的帐户/帐户类型有误和场景7-帐户余额不足就
缺少测试用例。
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适
度，并取消多余或等效的测试用例。
有关详细信息，请参见检查点：
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定
测试数据（关于测试数据的详细信息，请参见指南：
测试数据）。
4987809-
498
50.00500.002,000成功的提
帐户余
额被更新
为450.00
100.00500.000.00提款选项
不可用，用
例结束
100.00500.0070.00警告消息，
返回基本
流步骤6-
输入金额
CW4.场景4-
（还有不止
4978
809-
n/a500.002,000警告消息，
流步骤4，
输入PIN
CW5.场景4-
（还有一次
CW6.场景4-4978809-n/a500.002,000警告消息，
（不再有输
498卡予保留，
以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。
需要
的其他测试用例包括：
场景6-帐户不存在/帐户类型有误：
未找到帐户或帐户不可用
禁止从该帐户中提款
场景7-帐户余额不足：
请求的金额超出帐面金额
在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）
无法读卡（读卡机堵塞、脱机或出现故障）
帐户已消户、冻结或由于其他方面原因而无法使用
ATM内的现金不足或不能提供所请求的金额（与CW3不同，在CW3中只是一
种币值不足，而不是所有币值都不足）
无法联系银行系统以获得认可
银行网络离线或交易过程中断电
在确定功能性测试用例时，确保满足下列条件：
已经为每个用例场景确定了充足的正面和负面测试用例。
测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、
外部还是在边界条件/值上都存在测试用例。
测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还
应能处理用户界面对象状态或条件。
测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊
需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。
关于测试数据的其他信息，另请参见指南：
测试数据。
从补充规约中生成测试用例
并不是所有的测试目标需求都将在用例中有所反映。
非功能性需求（如性能、安
全性和访问控制）以及配置要求等将会说明测试目标的其他行为或特征。
补充规
约是为其他行为生成测试用例的主要来源。
关于如何生成这些其他测试用例的指南说明如下：
为性能测试生成测试用例
为安全性/访问控制测试生成测试用例
为配置测试生成测试用例
为安装测试生成测试用例
为其他非功能性测试生成测试用例
为性能测试生成测试用例
性能测试用例的主要输入是补充规约，补充规约中包含了非功能性需求（请参见
工件：
补充规约）。
为性能测试生成测试用例时，请使用下列指南：
对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。
性能
标准通常表示为时间/事务、事务量/用户或百分数的形式。
对每个关键用例，都应确保至少要确定一个测试用例。
关键用例是在上述说明中和/
或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例（请参见工件：
工
作量分析文档）。
与功能性测试的测试用例类似，通常对于每个用例/需求都会存在不止一个测试
用例。
常见的情况是：
存在一个低于性能阈值的测试用例、一个处于阈值上的测
试用例，还有一个测试用例高于阈值。
除了以上性能标准以外，确保已确定影响响应时间的特定条件，包括：
数据库的大小-存在多少个记录？
工作量-同时执行操作的最终用户的数量和类型，以及要同时执行的事务的数量和
类型
环境特征（硬件、网件以及软件配置）
将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。
以下是各种性能测试的一些示例：
对于负载测试：
TC（测
例）ID
工作量条件
PCW1.1
（单个ATM）
完成提款交易全部交易（不依
赖于主角的时
间）在20秒之
内完成
PCW2.2
（1,000个同时运
行的ATM）
间）在30秒之
PCW3.3
（10.000个同时
运行的ATM）
间）在50秒之
对于强度测试：
SCW1.2
数据库锁定-2个
ATM请求同一帐户
ATM请求排成
队列
SCW2.2
无法实现银行系统
的通信
交易排成队列或
超时
SCW3.2
在交易过程中，银行
系统通信被终止
显示警告消息
为安全性/访问控制测试生成测试用例
主角和用例一同说明系统外部用户与系统所执行的动作之间的交互，以便为特定
主角生成测试结果。
复杂系统包含许多主角，所以我们编制测试用例时必须确保
只有指定执行用例的主角可以进行此操作，这一点非常关键。
在基于主角类型的
用例事件流存在差别时，尤其如此。
例如，在ATM用例中，如果主角“银行客户”的卡和帐户有的属于拥有这个ATM
机的银行，有的是竞争银行的银行卡（和帐户），或是企图使用该ATM不支持
的银行卡，则将对该主角“银行客户”执行不同的用例事件流。
对于功能性测试用例，请同样遵循上面列举的指南。
关于安全性和访问控制测试用例的示例：
条件卡
（V表明卡
有效）
读卡机
（V表明读
卡机工作正
常）
银行的网
络
ACW1.在银行网
络之内
VVV所有用例都可
用
ACW2.银行网络
之外
VVI只有提款用例
可用
ACW3.无法读卡IVV警告消息，卡被
ACW4.因被盗，卡
已挂失
IVV警告消息，卡予
保留
ACW5.卡已过期IVV警告消息，卡予
为配置测试生成测试用例
在典型的分布式系统中，允许存在许多种受支持的硬件和软件组合。
为了核实测
试目标在不同的配置情况下（如不同的操作系统、浏览器或CPU的速度）能否
正常工作或执行，应该对此进行测试。
此外，测试还应涵盖构件的组合，以便检
测在不同构件的交互中产生的缺陷。
例如，确保由应用程序安装的DDL版本不
会与另一个应用程序需要的相同DDL的版本发生冲突。
采用下列指南来生成用于配置测试的测试用例：
确保对每个关键配置，应至少存在一个测试用例可用于对其进行确定。
这是通过确
定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优先级来完成的。
应确
保最先测试最常见的配置，包括：
o打印机支持
o网络连接-局域网和广域网
o服务器配置-服务器驱动程序、服务器硬件
o台式机和/或服务器上安装的其他软件
o所有已安装软件的软件版本
确保对于每个可能有问题的配置至少存在一个测试用例。
这些配置可能包括：
o具有最低性能的硬件。
o历史上存在兼容性问题的共驻内存的软件。
o通过最慢的LAN/WAN连接访问服务器的客户机。
o资源不足（缓慢的CPU速度、最小的内存或分辨率，磁盘空间不足等等）
为安装测试生成测试用例
安装测试需要核实测试目标可以在所有可能的安装情况下安装。
安装情况可以指
首次安装测试目标，或是在装有较早版本的机器上安装测试目标的某个较新的版
本或工作版本。
安装测试还应确保在遇到异常情况时（如磁盘空间不足），测试
目标的执行情况仍可接受。
测试用例应包含以下各种软件的安装情况：
分发介质，例如磁盘、CD-ROM或文件服务器。
首次安装。
完全安装。
自定义安装。
升级安装。
客户机服务器软件的安装程序具备一组特定的测试用例。
不同于基于主机的系
统，服务器和客户机上的安装程序是有所不同的。
因而，安装测试应执行构成测
试目标的所有构件的安装，包括客户机、中间层以及服务器，这一点至关重要。
为其他非功能性测试生成测试用例
理论上,应找到所有必需的输入来生成测试用例模型、设计模型以及补充规约工
件的测试用例。
不过，如果此时您需要补充已有的输入，那也不足为奇。
示例如下：
操作测试（用以检验在某次故障发生后以及在下一次故障发生前“较长时间”内软件
的运行情况）的测试用例。
对性能瓶颈、系统容量或测试目标的强度承受能力进行调查的测试用例。
大多数情况下，您可以通过先前所确定的测试用例生成的某些测试用例来构建其
变体或聚合关系体，借此来查找测试用例。
为单元测试生成测试用例
单元测试要求既测试单元的内部结构同时还要测试其行为特征。
测试内部结构要
求了解实施单元的方式，基于这种了
升级会员 