5{ J4PB%Cr0 很多测试团多都会既开展脚本化的测试,也开展探索性的测试,关于二者的定义和区别,可以参见Cem Kaner的胶片:http://www.kaner.com/pdfs/QAIExploring.pdf
b%V'e%ooQd!c0T#]r s)NQ+Q3G%kn*\u0 本文探讨脚本化测试中的测试用例的有效性问题,尤其是针对功能性测试用例而言。51Testing软件测试网"dY9X~h |t
51Testing软件测试网$a:h7V}n1K;A 如何评价测试用例的有效性?51Testing软件测试网#[)\Y_-?;m8U:i
c*z
H2jf9p5S-qo+l8Qx7J0 我的答案:Incremental Analysis & Traceability51Testing软件测试网,\U;k|B0z
51Testing软件测试网7U
U-U&IXoLQ 你所在团队是如何评价测试用例的有效性的?51Testing软件测试网8f?#dv#w
51Testing软件测试网 Q"I)VAFyG A9K - 对用例进行检视
#H'V r'bzu051Testing软件测试网N"M5\!f$Xm#R'a
L - 看用例总数51Testing软件测试网|3xP/n2hW{1\
51Testing软件测试网^2C-[N1i0btO#ZL/d - 看代码覆盖率51Testing软件测试网Eo0b%]0u6}&hn
51Testing软件测试网5VCP(t:f2B/Fp'bV9? - 网上问题多少
#V$IaH)YC+[0z8G;f051Testing软件测试网j;gl-n7h-XM - 千行代码用例数
AD#we/x[ R;C051Testing软件测试网o;z7~
w"JsWFe;H3f - 用例发现缺陷密度
-`-WQ&qX_k
s0~051Testing软件测试网oBY3`2HV \N ......51Testing软件测试网.}Px6g&c0j
51Testing软件测试网
Hi0u;ZA0QXs(@ | 如何评价代码的有效性?– 通过测试验证。
B*B3m%B%w8ewH051Testing软件测试网/UZJ)I3dq 如何评价测试用例的有效性? — 通过产品发布后用户反馈的问题。51Testing软件测试网 F
~#dPLffGp~4X
5?$P1]1I|3p2q2]0 OK, 用户反馈的问题确实能总体上评价测试的有效性,不过这已经是事后了,我们想事前就能有信心。
%s:Nx!hXp09j%I}9D&q1t:J0 那么,换一种问法。51Testing软件测试网e2{D|;hB$Yq
yQon7I Ry_0 如何确保,你写的代码确实实现了给定的需求?51Testing软件测试网P b pEk*N3s;}(m
i?"j+Ovd fodE0
看一看我们的V模型吧,从“需求”到“代码”你走了怎样的路?你从拿到需求开始,开展了一系列的活动,需求分析、功能设计、技术设计,经过这些增量的过
程,你的分析越来越深入,最终出来的是代码,这样的系统化的过程本身就一定程度地保证了你的代码是针对这些需求的、是有效的(这就是
verification),但不一定是正确的,也许其中还有bug,这可以通过事后的测试活动找出来(这就是validation)。51Testing软件测试网QmVPAeD
3N6@2n!s ov;j5ZQ0 即使你采用敏捷开发,也仍然需要进行“需求分析”“系统设计”“编码”。
4R8gR%{/E8oTG
S051Testing软件测试网0C8l+E-}AL#]
[O 那么如何确保,你写的测试用例充分地测试了给定的需求?51Testing软件测试网]$R t+nS}
51Testing软件测试网ejLPH)s
从“需求”到“测试用例”你走了怎样的路?你是拿到需求,基于个人经验,写出来一大批用例?(这就像你拿到需求一上来就编码一样。)
你是否经过了一个“系统化的、增量的、分析过程”,来一步一步地确保你的用例能够充分覆盖这些需求?这就是我所说的测试分析设计的框架的概念。你需要分
析、画model、找出测试条件,然后才出具测试用例,你需要这样一系列的过程。
%S6i*^
KS0S051Testing软件测试网 HQ\/Nr,R 你是否会对每一行代码进行检视之后,才知道代码的有效性或质量?不会。那为什么要求“通过逐个检视测试用例,就能判断出测试用例的有效性”呢?51Testing软件测试网1y$D/lb'm.v u
*\;Rz!M_#cs0 你是否会通过代码行的总数判断代码的有效性(是否实现了需求)?不会。那么为什么要去“通过检查测试用例个数或密度的方法来判断测试用例的有效性”呢?
Z{
EYMx0&s5K+wV_\1}5y0 你是否因为需求分析、功能设计、技术设计等这些CMM的中间过程太耗时,而要求员工直接编码呢?不会。那为什么叫喊“测试分析、画model等测试设计活动工作量太大了”呢?(每当我讲完一次“MFQ&PPDCS:软件测试分析与测试设计”这门课,培训调查表中就会有这样的反馈:“测试分析的工作量太大了,没有时间做”;而与此同时,课前反馈的培训需求中又总是会有“学习测试设计技术,确保测试用例的有效性”、“设计出高质量的用例”。)51Testing软件测试网F3w7p#iD
9W%{/K%}1N X0
一边希望几乎不花什么时间、不用太费脑筋,就能得出测试用例;一边又对测试用例的有效性和评估提出高要求。测试是一种投资,测试设计活动更是一种投资,
用户会买你的代码,但不会买你的测试用例。你的用例的质量可以增加你对代码质量的信心,这其中是个平衡。如果你自信你的代码质量很高,那么恭喜你,无须在
测试用例上投资太多;如果你没有这份自信,那么请不要不舍得在测试设计上多投一些时间,请不要不愿意花一点精力去专研测试设计这门技术,更不要认为只有编
码是高尚的技术行为、测试只是没有什么技术含量的活儿。51Testing软件测试网'Z5hKf"e_%w
$Ma:f3M,Pw
jm&P0 如果你想知道你的产品的测试用例的有效性,我的建议,从测试分析设计框架上看,不仅仅看最终的一个一个的测试用例,更要看的是中间的、增量的、测试分析设计的过程,同时确保从需求到model、到测试条件、到测试用例的可跟踪性。
,GAob$^0