指南:
|
场景 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 所需的测试用例:
测试用例标识 | 场景 | 条件 | 期望的结果 |
---|---|---|---|
TC x | 场景 4 | 步骤 2 - 提款金额 > 帐户余额 | 重新进入基本流程中的步骤 2 |
TC y | 场景 4 | 步骤 2 - 提款金额 < 帐户余额 | 不执行备用流程 3,采用基本流程 |
TC z | 场景 4 | 步骤 2 - 提款金额 = 帐户余额 | 不执行备用流程 3,采用基本流程 |
注意:由于未提供其它信息,所以上面所示的测试用例极为简单。测试用例很少有这么简单。
下面提供由用例得出测试用例的更真实示例:
示例:
ATM 机器中的参与者和用例。
下表包含上图中“提取现金”用例的基本流程和某些备用流程:
基本流程 | 该用例是从 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 回到备用状态,且该用例终止。 |
备用流程 5 - 帐户不存在 | 在基本流程步骤 4 -“验证帐户和 PIN”中,如果银行系统返回一个代码,表示找不到该帐户或该帐户不允许提款,ATM 则显示相应的消息并重新进入基本流程步骤 9 -“退卡”。 |
备用流程 6 - 帐户中现金不足 | 在基本流程步骤 7 -“授权”中,银行系统返回一个代码,表示帐户余额小于在基本流程步骤 6 -“输入金额”中输入的金额,ATM 则显示相应的消息并重新进入基本流程步骤 6 -“输入金额”。 |
备用流程 7 - 已达到日提款最大金额 | 在基本流程步骤 6 -“授权”中,银行系统返回一个代码,表示包括该请求提款额在内,客户已超出或即将超出 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 |
注意:为简单起见,备用流程 3 和 6(场景 3 和 7)中的循环以及循环的组合未包括在上表中。
对于这七个场景中的每个场景而言,需要确定测试用例。可使用矩阵或决策表来确定和管理测试用例。下面显示了常见的格式,其中每一行都代表一个单独的测试用例,这些列则确定测试用例信息。在该示例中,每个测试用例都有一个测试用例标识、条件(或描述)、参与该测试用例的所有数据元素(作为输入信息或已存在于数据库中)以及期望的结果。
要开始定制矩阵,首先确定执行用例场景所需的数据元素。然后,至少为每个场景确定包含适当条件以执行场景的测试用例。例如,在下面的矩阵中,V(有效)用于表示该条件必须有效,才能执行基本流程;I(无效)用于表示将调用所期望的备用流程的条件。下表中,“n/a”表示该条件对测试用例不适用。
测试用例标识号 | 场景/条件 | 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 -“输入金额” |
CW5. | 场景 4 - PIN 不正确(还有一次输入机会) | I
|
V | n/a | V | V | 警告消息,回到基本流程步骤 4 -“输入金额” |
CW6. | 场景 4 - PIN 不正确(没有输入机会) | I
|
V | n/a | V | V | 警告消息,卡被扣留,用例结束 |
在上面的矩阵中,有六个测试用例执行四个场景。对基本流程而言,上述的测试用例 CW1 被称为正测试用例。它执行用例中的基本流程路线,没有任何偏差。基本流程的综合测试必须包括负测试用例,以确保仅在条件正确的情况下采用基本流程。测试用例 CW2 至 CW6 代表了这些负测试用例(有阴影的单元格表示执行备用流程所需的条件)。虽然 CW2 至 CW6 对基本流程而言是负测试用例,但它们对备用流程 2 至 4 而言是正测试用例,每个备用流程(CW1 - 基本流程)至少有一个负测试用例。
场景 4 是一个示例,其中每个场景仅含有一个正测试用例和一个负测试用例是不够的。要全面测试场景 4 -“PIN 不正确”,至少需要三个正测试用例(来调用场景 4):
注意,在上面的矩阵中,没有对条件(数据)输入实际值。这样创建测试用例矩阵的优点在于,很容易知道正在测试的条件。由于您仅需查看 V 和 I 的情况(在此由阴影单元格区分),因此确定是否已确定足够的测试用例也很容易。从上表中可以看出,有许多条件并没有阴影单元格,因此某些场景缺少测试用例,例如场景 6 -“帐户不存在或帐户类型错误”和场景 7 -“帐户余额不足”。
一旦确定了足够的测试用例,则应复审并验证这些用例以确保准确性和适用性,并删除重复、相同或多余的测试用例。关于更多详细信息,请参阅概念:测试观点列表。关于其它详细信息,另请参阅定义测试用例的测试数据一节。
测试用例标识号 | 场景/条件 | 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 -“输入金额” |
CW5. | 场景 4 - PIN 不正确(还有一次输入机会) | 4978
|
809 至 498 | n/a | 500.00 | 2,000 | 警告消息,回到基本流程步骤 4 -“输入金额” |
CW6. | 场景 4 - PIN 不正确(没有输入机会) | 4978
|
809 至 498 | n/a | 500.00 | 2,000 | 警告消息,卡被扣留,用例结束 |
上述测试用例仅仅是验证该迭代的提取现金用例所需的一些测试用例。所需的其它测试用例包括:
在以后的迭代中,当实施其它流程时,以下方面将需要测试用例:
确定功能测试用例时,请确保以下因素:
关于其它的指导信息,请参阅定义测试用例的测试数据一节。
并非测试目标的所有需求都将在功能需求工件(例如,用例规范)中得到反映。非功能需求(例如绩效、安全与访问以及配置需求)指定了测试目标的附加行为或特征,这些需求经常是单独记录的,以区别于功能需求。补充规范是获得针对这些附加需求的测试用例的主要来源之一。
下面描述了用于获得这些附加测试用例的指南:
性能测试用例的主要输入信息是包含非功能需求的补充规范(请参阅工件:补充规范)。获得针对性能测试的测试用例时,使用以下指南:
和功能测试的测试用例一样,通常每个使用场景或需求将有多个测试用例。一般将定义多个测试用例 - 例如,一个小于性能阈值(平均交易速率),另一个等于该阈值(高交易速率),第三个测试用例大于该阈值(最高交易速率)。
除了上述性能标准外,还要确保您确定了影响响应时间的特定条件,包括:
常见的做法是在表格矩阵中记录针对性能测试的测试用例(做法和用于功能测试的那些用例相似)。
关于其它详细信息,请参阅定义测试用例的测试数据一节。
以下是不同类型的性能测试的一些示例:
对于负载测试:
测试用例标识号 | 工作负载 | 条件 | 期望的结果 |
---|---|---|---|
PCW1. |
1 (单个 ATM) |
完成提款交易 |
在 20 秒内完成交易(非参与者相关计时) |
PCW2. |
2 (1,000 台 ATM 同时交易) |
完成提款交易 |
在 30 秒内完成交易(非参与者相关计时) |
PCW3. |
3 (10,000 台 ATM 同时交易) |
完成提款交易 |
在 50 秒内完成交易(非参与者相关计时) |
对于压力测试:
测试用例标识号 | 工作负载 | 条件 | 期望的结果 |
---|---|---|---|
SCW1. |
2 (1,000 台 ATM 同时交易) |
数据库锁定 - 2 台 ATM 请求同一帐户 |
将 ATM 请求排队 |
SCW2. |
2 (1,000 台 ATM 同时交易) |
银行系统通信不可用 |
交易进入排队等待或超时 |
SCW3. |
2 (1,000 台 ATM 同时交易) |
银行通信系统在交易过程中终止 |
显示警告消息 |
参与者和用例描述了系统外部用户和系统执行的操作之间的交互,这种交互将为特定参与者产生值。复杂系统包含多个参与者,且制订测试用例以确保仅指定的参与者可执行用例,这是至关重要的。如果在基于参与者类型的用例实际事件流中存在差别,则尤其如此。
例如,在 ATM 用例中,如果参与者“银行客户”的卡和帐户均来自 ATM 机所在的银行,而该“银行客户”却使用竞争银行的银行卡(和帐户),或尝试使用非加盟性的银行卡,则可能为参与者“银行客户”执行不同的用例事件流。
请遵循上面列出的针对功能测试用例的相同指南。
关于其它的指导信息,请参阅定义测试用例的测试数据一节。
用于安全与访问的测试用例示例:
测试用例标识号 | 条件 | 卡
(V 表示有效卡) |
读卡器
(V 表示读卡器正常工作) |
银行网络 | 期望的结果 |
---|---|---|---|---|---|
ACW1. | 银行网络内 | V | V | V | 所有用例均可用 |
ACW2. | 银行网络外 | V | V | I | 仅现金提取用例可用 |
ACW3. | 无法读卡 | I | V | V | 警告消息,卡被弹出 |
ACW4. | 报告卡被盗 | I | V | V | 警告消息,卡被扣留 |
ACW5. | 卡已过期 | I | V | V | 警告消息,卡被扣留 |
在典型的分发式系统中,可允许存在许多受支持的硬件和软件的组合。应执行测试,以验证不同配置(例如不同的操作系统、浏览器或 CPU 速度)中可接受的测试目标功能或执行。此外,测试还需要覆盖组件的组合,以发现不同组件的交互所产生的缺陷,(举例)确保由一个应用程序安装的 DLL 版本与另一应用程序所期望的相同 DLL 版本不冲突。
要获得针对配置测试的测试用例,请使用以下指南:
安装测试需要验证是否可在所有可能的安装场景下安装测试目标。安装场景可能包括初次安装测试目标、安装更新的版本或测试目标的工作版本(安装到包含较旧版本的机器上)。安装测试还应确保,当遇到异常情况(例如磁盘空间不足)时,测试目标允许执行操作。
测试用例应覆盖软件的安装场景,包括:
客户机-服务器软件的安装程序有一组专门的测试用例。和基于主机的系统不同,服务器和客户端的安装程序通常是分开的。因此,安装测试执行测试目标的所有组件的安装(包括客户端、中间层和服务器),这是非常重要的。
理想情况下,应查找所有必要的输入信息来获得“用例模型”、“设计模型”和“补充规范”工件中的测试用例。但是,此时通常需要补充所找到的信息。
示例如下:
在多数情况下,可通过创建测试用例(由先前确定的用例得出的测试用例)的变体或聚集体来查找这些测试用例。
产品验收测试是部署软件之前的最终测试操作。验收测试的目标在于,验证软件准备就绪且可由最终用户用来执行那些功能和任务(该软件就是为此而构建的)。产品验收测试通常不仅仅涉及到执行软件以做好准备,它还涉及到交付给客户的所有产品工件,例如培训、文档记录和打包。
按上述章节所述的方式获得软件工件的测试用例。根据产品验收测试的等级和正式程度,测试用例既可与上面已确定的用例相同或相似(正式),也可与其中的一部分相同或相似(非正式)。应在实施和执行产品测试之前就测试用例和产品验收标准达成一致,而与测试用例的深度无关。
非软件工件的评估会根据被评估的工件而大有不同。关于评估内容和方式的信息,请参阅每个具体非软件工件的指南和核对表。
回归测试将比较同一测试目标的两个工作版本或版本,并将其差别确定为潜在的缺陷。因此,假设某一新版本应像较早版本那样运行,并确保未因为这些变更而引入缺陷。
理论上,您希望一个迭代中的所有测试用例都将用作以后迭代中的测试用例。应使用以下指南来确定、设计并实施测试用例,这些测试用例在使维护最小化的同时使回归测试值和重用的价值最大化:
一旦讨论了测试用例且取得一致/认同,则可更详细地确定实际数据值(例如,在测试用例实施矩阵中)并创建测试数据工件。
Rational Unified Process
|