如何评价软件测试用例的有效性?

上一篇 / 下一篇  2012-07-09 08:44:56 / 个人分类:测试用例

*Lj Ej0]9_G.J0  很多测试团多都会既开展脚本化的测试,也开展探索性的测试,关于二者的定义和区别,可以参见Cem Kaner的胶片:http://www.kaner.com/pdfs/QAIExploring.pdf

t rz B%W0

`Y6~5ML1h0  本文探讨脚本化测试中的测试用例的有效性问题,尤其是针对功能性测试用例而言。51Testing软件测试网 Z A$g:n5i[ O._X

!nE#t Dp:Cfr^$l0  如何评价测试用例的有效性?

Q P)G1t }H8w?051Testing软件测试网 p&n/|4~5|'D"fS

  我的答案:Incremental Analysis & Traceability

}\ C*t#Cw4iGa051Testing软件测试网5m2P(N)ZnT'uI9h;b

  你所在团队是如何评价测试用例的有效性的?51Testing软件测试网%s0`7j-k g P

51Testing软件测试网/u}_v r4t;p

  - 对用例进行检视51Testing软件测试网'zc-EV dt e"~y&w6D

N(["i3@G#[:zW$j(AmV0  - 看用例总数

z [+[`V:_&xI0

}1JO}!j2Z0  - 看代码覆盖率51Testing软件测试网c*c\~*cH

?0@-Z'jP't~/Ks[7j6j0  - 网上问题多少51Testing软件测试网6k \ht}

2V_r.FA1[!Ajw0  - 千行代码用例数

fZ;DHSa jEy:A051Testing软件测试网6{0w n(Z"tb5M5sV G

  - 用例发现缺陷密度

-g bd|$e'v0

h%S#aIyP0  ......51Testing软件测试网)ns X qR!K%Ro

!~ u3}R2{-w1h't0  如何评价代码的有效性?– 通过测试验证。51Testing软件测试网4M,wb0O.Pco4u

51Testing软件测试网 HnLA+LH^H%o

  如何评价测试用例的有效性? — 通过产品发布后用户反馈的问题。

+J-iIk(e0

3E1t8j1Iu0  OK, 用户反馈的问题确实能总体上评价测试的有效性,不过这已经是事后了,我们想事前就能有信心。

([!f%D0W%nTZ*g4X+Y9Y051Testing软件测试网1v"?,V e+IW

  那么,换一种问法。51Testing软件测试网;DT+{p`WM H

51Testing软件测试网p$xN5Be"k?b

  如何确保,你写的代码确实实现了给定的需求?

,e!Z3d0QR*g a Z'r+u0

x @w6zxH0   看一看我们的V模型吧,从“需求”到“代码”你走了怎样的路?你从拿到需求开始,开展了一系列的活动,需求分析、功能设计、技术设计,经过这些增量的过 程,你的分析越来越深入,最终出来的是代码,这样的系统化的过程本身就一定程度地保证了你的代码是针对这些需求的、是有效的(这就是 verification),但不一定是正确的,也许其中还有bug,这可以通过事后的测试活动找出来(这就是validation)。

"F*PQ%\9C+{051Testing软件测试网;s(` M%x S:g!P!B

  即使你采用敏捷开发,也仍然需要进行“需求分析”“系统设计”“编码”。51Testing软件测试网0F'Hx |^ k

.gEh f{0  那么如何确保,你写的测试用例充分地测试了给定的需求?

:{'^/d$HC\-^0

#zo8|3Kx;K F!m9x0   从“需求”到“测试用例”你走了怎样的路?你是拿到需求,基于个人经验,写出来一大批用例?(这就像你拿到需求一上来就编码一样。) 你是否经过了一个“系统化的、增量的、分析过程”,来一步一步地确保你的用例能够充分覆盖这些需求?这就是我所说的测试分析设计的框架的概念。你需要分 析、画model、找出测试条件,然后才出具测试用例,你需要这样一系列的过程。

*JKYY.e0h8F051Testing软件测试网;L,ibtY(BA(`UQ

  你是否会对每一行代码进行检视之后,才知道代码的有效性或质量?不会。那为什么要求“通过逐个检视测试用例,就能判断出测试用例的有效性”呢?

^wT:nj,w051Testing软件测试网)[_ZB{J

  你是否会通过代码行的总数判断代码的有效性(是否实现了需求)?不会。那么为什么要去“通过检查测试用例个数或密度的方法来判断测试用例的有效性”呢?

@4xM1f*R4r:`8[0

*O9|6Hx"p0  你是否因为需求分析、功能设计、技术设计等这些CMM的中间过程太耗时,而要求员工直接编码呢?不会。那为什么叫喊“测试分析、画model等测试设计活动工作量太大了”呢?(每当我讲完一次“MFQ&PPDCS:软件测试分析与测试设计”这门课,培训调查表中就会有这样的反馈:“测试分析的工作量太大了,没有时间做”;而与此同时,课前反馈的培训需求中又总是会有“学习测试设计技术,确保测试用例的有效性”、“设计出高质量的用例”。)

8SQ7\)j7Z051Testing软件测试网*pFlP w}6k)VjM

   一边希望几乎不花什么时间、不用太费脑筋,就能得出测试用例;一边又对测试用例的有效性和评估提出高要求。测试是一种投资,测试设计活动更是一种投资, 用户会买你的代码,但不会买你的测试用例。你的用例的质量可以增加你对代码质量的信心,这其中是个平衡。如果你自信你的代码质量很高,那么恭喜你,无须在 测试用例上投资太多;如果你没有这份自信,那么请不要不舍得在测试设计上多投一些时间,请不要不愿意花一点精力去专研测试设计这门技术,更不要认为只有编 码是高尚的技术行为、测试只是没有什么技术含量的活儿。

I"sZ`-].Z z3w051Testing软件测试网h5~yyn1DE

  如果你想知道你的产品的测试用例的有效性,我的建议,从测试分析设计框架上看,不仅仅看最终的一个一个的测试用例,更要看的是中间的、增量的、测试分析设计的过程,同时确保从需求到model、到测试条件、到测试用例的可跟踪性。

3\yJ-FYo Ju0

TAG:

 

评分:0

我来说两句

Open Toolbar