测试用例具体用法续
上一篇 / 下一篇 2007-03-28 12:02:44 / 个人分类:技术术
六、测试用例设计的误区51Testing软件测试网%Y0MK$^4N
(来源:关河测试网)
ro&]+[g-^0·能发现到目前为止没有发现的缺陷的用例是好的用例;
F!X"DH:m+xm0*D)} I&y8[$C'M+L0 首先要申明,其实这句话是十分有道理的,但我发现很多人都曲解了这句话的原意,一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去,忘记了测试的目的所在,这是十分可怕的。我倾向于将测试用例当作一个集合来认识,对它的评价也只能对测试用例的集合来进行,测试本身是一种“V&V”的活动,测试 需要保证以下两点:51Testing软件测试网p(lJg`$O ?.WQ
51Testing软件测试网,MW6WM0B^*om 程序做了它应该做的事情
b"t#qk
X)Bq b0 程序没有做它不该做的事情51Testing软件测试网0oF)^3b!xY1ed
因此,作为测试实施依据的测试用例,必须要能完整覆盖测试需求,而不应该针对单个的测试用例去评判好坏。51Testing软件测试网`JD/um,P1q)c!~
·测试用例应该详细记录所有的操作信息,使一个没有接触过系统的人员也能进行测试;
HF,\X-Zf`$\0@to'Zl1{ [2c0 不知道国内有没有公司真正做到这点,或者说,不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中,对测试用例描述的详细和复杂程度 也曾有过很多的彷徨。写得太简单吧,除了自己没人能够执行,写得太详细吧,消耗在测试用例维护(别忘了,测试用例是动态的,一旦测试环境、需求、设计、实 现发生了变化,测试用例都需要相应发生变化)上的时间实在是太惊人,在目前国内大部分软件公司的测试资源都不足的情况下,恐怕很难实现。但我偏偏就能遇到 一些这样的老总或者是项目负责人,甚至是测试工程师本身,全然不顾实际的资源情况,一定要写出“没有接触过系统的人员也能进行测试”的用例。51Testing软件测试网@"\nO\/t
51Testing软件测试网5\W~ a7dG]/o在讨论这个问题之前,我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷,测试活动本身也可以被看作是一个Project,也需要在 给定的资源条件下尽可能达成目标,根据我个人的经验,大部分的国内软件公司在测试方面配备的资源都是不足够的,因此我们必须在测试计划阶段明确测试的目 标,一切围绕测试的目标进行。51Testing软件测试网t#u5?"T5jQO@
51Testing软件测试网P)qc)W5Kp+t除了资源上的约束外,测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻,那测试用例就没有必要太详细了,文档的作用本来就在于沟通,只要能达到沟通的目的就OK。在我担任测试经理的项目中,在测试计划阶段,一般给予测试设计30% - 40%左右的时间,测试设计工程师能够根据项目的需要自行确定用例的详细程度,在测试用例的评审阶段由参与评审的相关人对其把关。
DJ%K(Zu*o-@%E*Y ]&k051Testing软件测试网d0zsw pg$| T·测试用例设计是一劳永逸的事情;
*P_)D!Tf&I051Testing软件测试网~0y w%^D$f;[这句话摆在这里,我想没有一个人会认可,但在实际情况中,却经常能发现这种想法的影子。我曾经参与过一个项目,软件需求和设计已经变更了多次,但测试用例 却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措,间接的后果是测试用例成了废纸一堆,开发人员在多次被无效的缺陷报告打扰 后,对测试人员不屑一顾。51Testing软件测试网v.M2dal(c1M5T
u e+B&]1~0 这个例子可能有些极端,但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的,测试用例文档是“活的”文档,这一点应该被测试工程师牢记。51Testing软件测试网e V{o'q7L
51Testing软件测试网g![8h6lO/Bp·测试用例不应该包含实际的数据;
(?O+|8c^0]6W5\mu2`D&d0 测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出,没有测试数据的用例最多只具有指导性的意义,不具有可执行 性。当然,测试用例中包含输入数据会带来维护、与测试环境同步之类的问题,关于这一点,《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法,可以参考。51Testing软件测试网 A!P@qr _ }hfy f
;@[ H'Z#^\i0·测试用例中不需要明显的验证手段;
V/EPi*v`(w }_C0B2]WX1Yxeu0 我见过很多测试工程师编写的测试用例中,“预期输出”仅描述为程序的可见行为,其实,“预期结果”的含义并不只是程序的可见行为。例如,对一个订货系统, 输入订货数据,点击“确定”按钮后,系统提示“订货成功”,这样是不是一个完整的用例呢?是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢? 显然不是。订货是否成功还需要查看相应的数据记录是否更新,因此,在这样的一个用例中,还应该包含对测试结果的显式的验证手段:在数据库中执行查询语句进行查询,看查询结果是否与预期的一致。
C;B R,iZ g:A4hd051Testing软件测试网_vrn4A3Ib sv.m:R七、从用例中生成测试用例
Di7\8oZ0j&D M?ad`!s!RM051Testing软件测试网3H3Cpz%uVn)Ba
用于功能性测试的测试用例来源于测试目标的用例。应该为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定,这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
例如,下图中经过用例的每条不同路径都反映了基本流和备选流,都用箭头来表示。基本流用直黑线来表示,是经过用例的最简单的路径。每个备选流自基本流开始,之后,备选流会在某个特定条件下执行。备选流可能会重新加入基本流中(备选流 1 和 3),还可能起源于另一个备选流(备选流 2),或者终止用例而不再重新加入某个流(备选流 2 和 4)。
s*w i{q@#N k:K0']*i%S D$` x@5a;sT0
O*A3Z)o v'G k0用例的事件流示例51Testing软件测试网3V#YO?H
YQ
遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:51Testing软件测试网[myPh$C
场景 1 | 基本流 | |||
场景 2 | 基本流 | 备选流 1 | ||
场景 3 | 基本流 | 备选流 1 | 备选流 2 | |
场景 4 | 基本流 | 备选流 3 | ||
场景 5 | 基本流 | 备选流 3 | 备选流 1 | |
场景 6 | 基本流 | 备选流 3 | 备选流 1 | 备选流 2 |
场景 7 | 基本流 | 备选流 4 | ||
场景 8 | 基本流 | 备选流 3 | 备选流 4 |
1o-Je"A,CzCcn1a g0注:为方便起见,场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。
pD#hr{w8V\0%W2Tf6NkO9c0生成每个场景的测试用例是通过确定某个特定条件来完成的,这个特定条件将导致特定用例场景的执行。
%E)t b0RO H0? ~ Gt3`o Xz0例如,假定上图描述的用例对备选流 3 规定如下:
$Hn0rU$v7X0o:}Bpd'z_/S:kg.K#c0“如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额,则出现此事件流。系统将显示一则警告消息,之后重新加入基本流,再次执行上述步骤 2‘输入提款金额’,此时银行客户可以输入新的提款金额。”51Testing软件测试网)w)xR+h7G
51Testing软件测试网K~9_Za9Z1Z据此,可以开始确定需要用来执行备选流 3 的测试用例:51Testing软件测试网+N)V R/Tz_w(F
测试用例ID | 场景 | 条件 | 预期结果 |
TC x | 场景 4 | 步骤 2 - 提款金额 > 帐户余额 | 在步骤 2 处重新加入基本流 |
TC y | 场景 4 | 步骤 2 - 提款金额 < 帐户余额 | 不执行备选流 3,执行基本流 |
TC z | 场景 4 | 步骤 2 - 提款金额 = 帐户余额 | 不执行备选流 3,执行基本流 |
注:由于没有提供其他信息,以上显示的测试用例都非常简单。测试用例很少如此简单。
S4qn8H$W'EJ06H.W4lK9\j9c5cQB9ki0下面是一个由用例生成测试用例的更符合实际情况的示例。
pJ,D/P?{051Testing软件测试网2n(J1j.j e%Vk
&g*|!H O*Z0示例:51Testing软件测试网bE+u B(X3mGy_!D
6?b*eQK+Z'Wi'd0一台 ATM 机器的主角和用例。
F U0U(~ q0d ofy!J8G(F Y#o0下表包含了上图中提款用例的基本流和某些备用流:51Testing软件测试网5a3cD1|.lh$kJ
51Testing软件测试网eZ|'lh2Lq.R本用例的开端是 ATM 处于准备就绪状态。
用例结束时 ATM 又回到准备就绪状态。 | |
备选流 1 - 银行卡无效 | 在基本流步骤 2 中 - 验证银行卡,如果卡是无效的,则卡被退回,同时会通知相关消息。 |
备选流 2 - ATM 内没有现金 | 在基本流步骤 5 中 - ATM 选项,如果 ATM 内没有现金,则“提款”选项将无法使用。 |
备选流 3 - ATM 内现金不足 | 在基本流步骤 6 中- 输入金额,如果 ATM 机内金额少于请求提取的金额,则将显示一则适当的消息,并且在步骤 6 - 输入金额处重新加入基本流。 |
备选流 4 - PIN 有误 | 在基本流步骤 4 中- 验证帐户和 PIN,客户有三次机会输入 PIN。51Testing软件测试网b{*ZI
@.A H^4F 51Testing软件测试网] H6X0p@$x 如果 PIN 输入有误,ATM 将显示适当的消息;如果还存在输入机会,则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。51Testing软件测试网v+q4E1aA 51Testing软件测试网u$Ff8s4n8So 如果最后一次尝试输入的 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 进入“安全模式”,在此模式下所有功能都暂停使用,直到采取适当的重启/重新初始化的措施。 |
51Testing软件测试网j(P q,s/`[-_
rD(IT+L;S8|Y0 C&q*B-HfC FY#{0 |
可以从这个用例生成下列场景
^&W'jbN.f@\,Q]W`0场景 1 - 成功的提款 | 基本流 | |
场景 2 - ATM 内没有现金 | 基本流 | 备选流 2 |
场景 3 - ATM 内现金不足 | 基本流 | 备选流 3 |
场景 4 - PIN 有误(还有输入机会) | 基本流 | 备选流 4 |
场景 5 - PIN 有误(不再有输入机会) | 基本流 | 备选流 4 |
场景 6 - 帐户不存在/帐户类型有误 | 基本流 | 备选流 5 |
场景 7 - 帐户余额不足 | 基本流 | 备选流 6 |
注:为方便起见,备选流 3 和 6(场景 3 和 7)内的循环以及循环组合未纳入上表。51Testing软件测试网`&_Q"AH1wj1GT}e
51Testing软件测试网!@ Br Y?对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例 ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。51Testing软件测试网6Z~'C1^E4Z8J t
51Testing软件测试网lxt-}4^@/W通过从确定执行用例场景所需的数据元素入手构建矩阵。然后,对于每个场景,至少要确定包含执行场景所需的适当条件的测试用例。例如,在下面的矩阵中,V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流。下表中使用的“n/a”(不适用)表明这个条件不适用于测试用例。
,V9N jk6O(`0TC(测试用例)ID 号 | 场景/条件 | PIN '\&Q'AX%x-J'E0 '\m O&~+Vhb;|0 | 帐号 $\,Lf0Id Z@s+f p0 51Testing软件测试网-toH9o!q&| | 输入的金额 }1K"]B s[7mZY0(或选择的金额) ~*_hTI051Testing软件测试网)P(zOv,PI51Testing软件测试网I%E)^;drW8O8HL | 帐面金额 2G3Yld0yW*AhP!S"e0 51Testing软件测试网tUV!N2T3pr8sM | ATM 内的金额 +?t VK*Y(o&g0 SlO@ChP?.R0 | 预期结果 |
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 51Testing软件测试网!n.I[9S*n"]@!^&s2o 0p3Ac8bv0 | V | n/a | V | V | 警告消息,返回基本流步骤 4,输入 PIN |
CW5. | 场景 4 - PIN 有误(还有一次输入机会) | I 51Testing软件测试网.l0V]Fa 51Testing软件测试网f$N\ A8K:LNZ | V | n/a | V | V | 警告消息,返回基本流步骤 4,输入 PIN |
CW6. | 场景 4 - PIN 有误(不再有输入机会) | I 51Testing软件测试网ZT2FM2So0{? *j6as"b-A0 | V | n/a | V | V | 警告消息,卡予保留,用例结束 |
在上面的矩阵中,六个测试用例执行了四个场景。对于基本流,上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行,未发生任何偏差。基本流的全面测试必须包括负面测试用例,以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示(阴影单元格表明这种条件下需要执行备选流)。虽然 CW2 至 6 对于基本流而言都是负面测试用例,但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言,至少存在一个负面测试用例(CW1 - 基本流)。
)F E:w$p*Q9cTm;L051Testing软件测试网:X#d v;zh5T每个场景只具有一个正面测试用例和负面测试用例是不充分的,场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误,至少需要三个正面测试用例(以激活场景 4):
"yc$A#^qd0- 输入了错误的 PIN,但仍存在输入机会,此备选流重新加入基本流中的步骤 3 - 输入 PIN。
- 输入了错误的 PIN,而且不再有输入机会,则此备选流将保留银行卡并终止用例。
- 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。
注:在上面的矩阵中,无需为条件(数据)输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I(或此处采用的阴影单元格),这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格,这表明测试用例还不完全,如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。51Testing软件测试网&m1n EQu_
51Testing软件测试网 q@${j.F%W9{一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。
K Um(l\051Testing软件测试网Kp&X7y~)S测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据51Testing软件测试网"OB3z({^n)Zf/~L$Mn
TC(测试用例)ID 号 | 场景/条件 | PIN G]P)H+e0 51Testing软件测试网K!j%aOxj | 帐号 3P|+w2I9~ K2V0 51Testing软件测试网2p9XdUb | 输入的金额 3fX5b4@V gf#E0(或选择的金额) xy/?u0b1\U)R051Testing软件测试网^WJU$_51Testing软件测试网.pu|.B:HB | 帐面金额 r(`P[ ^(n0 ?!GgVvW4u0 | ATM 内的金额 !Rav(`%I~"[0 +pV0{/yo8w0 | 预期结果 |
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 .CfNF3h(R|z8a0 51Testing软件测试网vfaw'?0p | 809 - 498 | n/a | 500.00 | 2,000 | 警告消息,返回基本流步骤 4,输入 PIN |
CW5. | 场景 4 - PIN 有误(还有一次输入机会) | 497851Testing软件测试网AcDd&Y-~1r 51Testing软件测试网#zK,b3O mG] | 809 - 498 | n/a | 500.00 | 2,000 | 警告消息,返回基本流步骤 4,输入 PIN |
CW6. | 场景 4 - PIN 有误(不再有输入机会) | 4978 51Testing软件测试网7bB#[J+X-k1|$I myg^4hv2~6c:s0 | 809 - 498 | n/a | 500.00 | 2,000 | 警告消息,卡予保留,用例结束 |
p wr7Ct.u0
;B*wI(|7R7LQC p00Y H@E]@:vN_b9g0 以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括:
l*u8fztO"D;hD j0- 场景 6 - 帐户不存在/帐户类型有误:未找到帐户或帐户不可用
- 场景 6 - 帐户不存在/帐户类型有误:禁止从该帐户中提款
- 场景 7 - 帐户余额不足:请求的金额超出帐面金额
*v$Df ~n0在将来的迭代中,当实施其他事件流时,在下列情况下将需要测试用例:
2R:T1Zj{OA0- 无效卡(所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等)
- 无法读卡(读卡机堵塞、脱机或出现故障)
- 帐户已消户、冻结或由于其他方面原因而无法使用
- ATM 内的现金不足或不能提供所请求的金额(与 CW3 不同,在 CW3 中只是一种币值不足,而不是所有币值都不足)
- 无法联系银行系统以获得认可
- 银行网络离线或交易过程中断电
V)c+f(egw0在确定功能性测试用例时,确保满足下列条件:
4['pF ~C} Z;a6r TH T0- 已经为每个用例场景确定了充足的正面和负面测试用例。
- 测试用例可以处理用例所实施的所有业务规则,确保对于业务规则,无论是在内部、外部还是在边界条件/值上都存在测试用例。
- 测试用例可以处理所有事件或动作排序(如在涉及模型的序列图中确定的内容),还应能处理用户界面对象状态或条件。
- 测试用例可以处理为用例所指定的任何特殊需求,如最佳/最差性能,有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。
八、从补充规约中生成测试用例
51Testing软件测试网9]qBM;yl%x并不是所有的测试目标需求都将在用例中有所反映。非功能性需求(如性能、安全性和访问控制)以及配置要求等将会说明测试目标的其他行为或特征。补充规约是为其他行为生成测试用例的主要来源。
/{@R'qW t01J.bWIS"LlNw0 关于如何生成这些其他测试用例的指南说明如下:
0Ufd*ST'rrD0- 为性能测试生成测试用例
- 为安全性/访问控制测试生成测试用例
- 为配置测试生成测试用例
- 为安装测试生成测试用例
- 为其他非功能性测试生成测试用例
为性能测试生成测试用例
m*~ l%r|Pc$~0 性能测试用例的主要输入是补充规约,补充规约中包含了非功能性需求(请参见工件:补充规约)。为性能测试生成测试用例时,请使用下列指南:
m"OC9A,wQM5B;^0- 对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。性能标准通常表示为时间/事务、事务量/用户或百分数的形式。
- 对每个关键用例,都应确保至少要确定一个测试用例。关键用例是在上述说明中和/或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例(请参见工件:工作量分析文档)。
与功能性测试的测试用例类似,通常对于每个用例/需求都会存在不止一个测试用例。常见的情况是:存在一个低于性能阈值的测试用例、一个处于阈值上的测试用例,还有一个测试用例高于阈值。51Testing软件测试网:iFnqu(U0? E
0HyUz6_q.p0除了以上性能标准以外,确保已确定影响响应时间的特定条件,包括:51Testing软件测试网X+r;_;~S I`
- 数据库的大小 - 存在多少个记录?
- 工作量 - 同时执行操作的最终用户的数量和类型,以及要同时执行的事务的数量和类型
- 环境特征(硬件、网件以及软件配置)
将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。51Testing软件测试网-P{_8r6?r
+HR"W9AEo$a3`0以下是各种性能测试的一些示例:
&n Q"q;MI051Testing软件测试网S1_8qqH8ku0Y(x,S对于负载测试:
}3m,t-\$G[*q0TC(测试用例)ID 号 | 工作量 | 条件 y$olieA0 W*q_*Oe9RF9Hm0 | 预期结果 |
PCW1. | 151Testing软件测试网)yHj7DN0PQC (单个 ATM)51Testing软件测试网!og&M:RWw | 完成提款交易51Testing软件测试网ES]4[L J8s drw N | 全部交易(不依赖于主角的时间)在 20 秒之内完成 |
PCW2. | 2 {,_\6z5l3Y%q[0(1,000 个同时运行的 ATM) 5w_#`L lk,i"z0 | 完成提款交易 -F1o `z}-J ^0 | 全部交易(不依赖于主角的时间)在 30 秒之内完成 |
PCW3. | 3 #y/ln2[-s*mU*t't0(10.000 个同时运行的 ATM)51Testing软件测试网x:g[|r | 完成提款交易51Testing软件测试网\nyi.UN | 全部交易(不依赖于主角的时间)在 50 秒之内完成 |
对于强度测试:
2g t@sK7B!F9k0TC(测试用例)ID 号 | 工作量 | 条件 V$Z}'O1uO ei0 51Testing软件测试网A&s!o1St5Yp&L6sB | 预期结果 |
SCW1. | 2 3zhl7fb.{YF!_#Z0(1,000 个同时运行的 ATM)51Testing软件测试网 [&IU;Sk?` | 数据库锁定 - 2 个 ATM 请求同一帐户 5we@^]6^1pJ0 | ATM 请求排成队列 |
SCW2. | 251Testing软件测试网6}.\+N,ym k }3NN%x (1,000 个同时运行的 ATM) RB&T%B)pR%Z0 | 无法实现银行系统的通信 {d"F)x?U+JC"i U0 | 交易排成队列或超时 |
SCW3. | 251Testing软件测试网:y(EHjEUhUI0Y (1,000 个同时运行的 ATM)51Testing软件测试网[!o5av7f*dC)V9x | 在交易过程中,银行系统通信被终止51Testing软件测试网1v&EQO-T^c8{Am | 显示警告消息 |
为安全性/访问控制测试生成测试用例
51Testing软件测试网k*c8]9M*t?J+n主角和用例一同说明系统外部用户与系统所执行的动作之间的交互,以便为特定主角生成测试结果。复杂系统包含许多主角,所以我们编制测试用例时必须确保只有指定执行用例的主角可以进行此操作,这一点非常关键。在基于主角类型的用例事件流存在差别时,尤其如此。51Testing软件测试网~ k*yL7{5\"j
51Testing软件测试网/nE5q"uHp例如,在 ATM 用例中,如果主角“银行客户”的卡和帐户有的属于拥有这个 ATM 机的银行,有的是竞争银行的银行卡(和帐户),或是企图使用该 ATM 不支持的银行卡,则将对该主角“银行客户”执行不同的用例事件流。51Testing软件测试网3~Q+^U0gP
51Testing软件测试网ty_,Sf#x AI对于功能性测试用例,请同样遵循上面列举的指南。
%UyQ5N+L"T7S051Testing软件测试网*L2m]$gH!Cs_关于安全性和访问控制测试用例的示例:51Testing软件测试网-Wq&FlRkG,m
TC(测试用例)ID 号 | 条件 | 卡51Testing软件测试网 a"m(QAVW3E4p~ (V 表明卡有效)51Testing软件测试网2t+j2C,sDd;_e1~&D | 读卡机 O2HH0QZ1l1[_O0(V 表明读卡机工作正常) "Y1m!^9}c8g.A!JP0 | 银行的网络 | 预期结果 |
ACW1. | 在银行网络之内 | V | V | V | 所有用例都可用 |
ACW2. | 银行网络之外 | V | V | I | 只有提款用例可用 |
ACW3. | 无法读卡 | I | V | V | 警告消息,卡被退出 |
ACW4. | 因被盗,卡已挂失 | I | V | V | 警告消息,卡予保留 |
ACW5. | 卡已过期 | I | V | V | 警告消息,卡予保留 |
为配置测试生成测试用例
U&vW%X$q+J7av/[{0在典型的分布式系统中,允许存在许多种受支持的硬件和软件组合。为了核实测试目标在不同的配置情况下(如不同的操作系统、浏览器或 CPU 的速度)能否正常工作或执行,应该对此进行测试。此外,测试还应涵盖构件的组合,以便检测在不同构件的交互中产生的缺陷。例如,确保由应用程序安装的 DDL 版本不会与另一个应用程序需要的相同 DDL 的版本发生冲突。51Testing软件测试网Q#u2y.A#wD H9d+w"uk
FW4i'f[!nrj4j0采用下列指南来生成用于配置测试的测试用例:51Testing软件测试网"rxq fA_
- 确保对每个关键配置,应至少存在一个测试用例可用于对其进行确定。这是通过确定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优先级来完成的。应确保最先测试最常见的配置,包括:
- 打印机支持
- 网络连接 - 局域网和广域网
- 服务器配置 - 服务器驱动程序、服务器硬件
- 台式机和/或服务器上安装的其他软件
- 所有已安装软件的软件版本
- 确保对于每个可能有问题的配置至少存在一个测试用例。这些配置可能包括:
- 具有最低性能的硬件。
- 历史上存在兼容性问题的共驻内存的软件。
- 通过最慢的 LAN/WAN 连接访问服务器的客户机。
- 资源不足(缓慢的 CPU 速度、最小的内存或分辨率,磁盘空间不足等等)
为安装测试生成测试用例
51Testing软件测试网!J Z\4i*FP"tV安装测试需要核实测试目标可以在所有可能的安装情况下安装。安装情况可以指首次安装测试目标,或是在装有较早版本的机器上安装测试目标的某个较新的版本或工作版本。安装测试还应确保在遇到异常情况时(如磁盘空间不足),测试目标的执行情况仍可接受。
T {r.JI:R0[j;\ ` f.E(S\yO0 测试用例应包含以下各种软件的安装情况:51Testing软件测试网C^,rAHaX
- 分发介质,例如磁盘、CD-ROM 或文件服务器。
- 首次安装。
- 完全安装。
- 自定义安装。
- 升级安装。
@E-P4\y*S9ZH0 客户机服务器软件的安装程序具备一组特定的测试用例。不同于基于主机的系统,服务器和客户机上的安装程序是有所不同的。因而,安装测试应执行构成测试目标的所有构件的安装,包括客户机、中间层以及服务器,这一点至关重要。51Testing软件测试网;g)|@(q k"l
为其他非功能性测试生成测试用例
51Testing软件测试网 \s kaV;O@理论上,应找到所有必需的输入来生成测试用例模型、设计模型以及补充规约工件的测试用例。不过,如果此时您需要补充已有的输入,那也不足为奇。51Testing软件测试网 _ v1oT^Ij0d+s