测试用例与需求的对应关系

这是一个开放的讨论。命题是这样的：测试用例与需求的对应关系往往有两种。一种是一个测试用例只测一条需求。另外一种是一个测试用例可能测到很多条需求。前者的需求与测试用例有一对多的关系，后者的需求与测试的对应关系则是一个矩阵。哪一种更合理？

.X2J"q5A(j,NqM0　　讨论在以下三方面进行。51Testing软件测试网0{2ATU^aXt

51Testing软件测试网q9e:N#Sz&m#m0M

　　第一：（自动化）测试用例的表现能力51Testing软件测试网$N#]/Mn\y

51Testing软件测试网-d rLw-Gvta S0th

　　第二：测试用例的易用性

^O/au:hI)rt0

Bo9XI`:~0　　第三：测试用例的生成与维护成本51Testing软件测试网 {8wo*E~2p"QCk-O

Q Iw5Wn0　　测试用例的表现能力

Sof.oX9Rx:V8@;v0

8S5`;IUp:K0　　参与讨论的人都认同测试用例有助于帮助理解需求，但并不是所有的人都能认同自动化测试用例可以用做需求文档。不能认同的一个原因是他们认为测试用例的表现能力有限，写得再好的测试用例也很难让每个人都读得懂。另一种观点认为测试用例中的信息不完整，测试用例只能做为需求的实例而不能取代需求本身。

3tB)i[\0

a3F9D:Dvt1f6S0　　暂时搁置争议，我们也会发现，如果一个用例只测一条需求，那么整个需求—用例结构会相对简单，更有助理解。51Testing软件测试网5X/f2krn(`8Y

-x"B0G
FAtXZ0　　测试用例的易用性

't"y.vcj[S0

.C Vt xHO d}e@j0　　如果每个测试用例都测很多东西，那么如果有case失败的话那么就需要花费更高的成本来定位错误。正如Simon所说，这种case成功的意义大于失败的意义。然而一个好的测试用例应该在失败时更有意义，它的失败应该明确的代表系统中某一具体功能不工作，甚至不需调试就能定位到错误在哪里。51Testing软件测试网jE2~.~x

51Testing软件测试网J%Z+WhlA&g3L/W

　　也有人指出，在测试用例中给出更明确的出错提示也能帮助定位错误。

t8I6t)B?|k2V;c(Y0

.wZ2?\!uz0　　另一方面，如果每个case只测一件事情，case的数量会更多。功能测试/系统测试往往速度比较慢，把很多事情放在一起测会快一点。可我们是否应该牺牲测试用例的质量来提高效率？（这个问题怎么看起来和那个“是否应该牺牲代码质量来提高性能”那么象！）51Testing软件测试网CCk/@#zh9`

R n"G i^0o1e9?a0　　测试用例的生成与维护成本51Testing软件测试网7if}%@:X~

51Testing软件测试网9TCe(b'Hh

　　大家都认为，一个case只测一件事，这样的测试用例生成成本相对高一些，需要的能力更高一点，而且要求系统有更好的可测性。

3Lp4gVJ9B051Testing软件测试网yQX:k-B-T5l8e%j

　　但是关于维护成本，大家的观点不尽相同。对于第一种测试用例，有人认为cases的数量太多会增加维护成本。也有人认为减少case之间的依赖关系会降低维护成本。51Testing软件测试网%WHHi-B-Z

51Testing软件测试网~0a,k/a6QzLMT"T

　　我相信，对于这样的一个问题，我们很难得到一个非此即彼的答案。关键是要能暂时放开自己信心满满的想法，听一听别人对这个事情是如何理解的:)

qy!L/u1@+Z%Ia0Q0