软件需求说明及对应的测试用例,测试用例与需求的对应关系 - Mr.南柯 - 51Testing软件测试网 51Testing软件测试网-软件测试人的精神家园...

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

d*\-r0K2tV!S@7W0　　讨论在以下三方面进行。`1ir"MK-U%DAe051Testing软件测试网Je7Meqa

第一：(自动化)测试用例的表现能力g.aBC!}&wfLv se0

-sa/|Jm%J&@0　　第二：测试用例的易用性lj7ts5~,V&V051Testing软件测试网H(v-h%Hy:^"T

第三：测试用例的生成与维护成本51Testing软件测试网9F&gkGuz*p3Ns

F0Onyr`Z0测试用例的表现能力51Testing软件测试网+B.^%l6sz4E;Z^J

[MIW:~|4H0　　参与讨论的人都认同测试用例有助于帮助理解需求，但并不是所有的人都能认同用例可以用做需求文档。不能认同的一个原因是他们认为测试用例的表现能力有限，写得再好的测试用例也很难让每个人都读得懂。另一种观点认为测试用例中的信息不完整，测试用例只能做为需求的实例而不能取代需求本身。6nD)t*oe6s-lz'{q051Testing软件测试网ALuRJKI"~;`r

暂时搁置争议，我们也会发现，如果一个用例只测一条需求，那么整个需求—用例结构会相对简单，更有助理解。51Testing软件测试网t

Cg4c%O#K51Testing软件测试网3Zn|:pEF9j-Qw*Ta

测试用例的易用性3Z[,aK5p&c051Testing软件测试网1W&f(D6BtV BD

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

"yT1RXH0　　也有人指出，在测试用例中给出更明确的出错提示也能帮助定位错误。iKzHOg,A6|?0

IK#hV#i-l'S5k0　　另一方面，如果每个case只测一件事情，case的数量会更多。功能测试/系统测试往往速度比较慢，把很多事情放在一起测会快一点。可我们是否应该牺牲测试用例的质量来提高效率？(这个问题怎么看起来和那个“是否应该牺牲代码质量来提高性能”那么象！)51Testing软件测试网7m

?(^s1CR%T `'O)ra51Testing软件测试网9ts4NDhkB#x9b'F(r

测试用例的生成与维护成本+Y4F&rqj%[ Q/E

}U(_0

u+XY;z\M%RD0　　大家都认为，一个case只测一件事，这样的测试用例生成成本相对高一些，需要的能力更高一点，而且要求系统有更好的可测性。51Testing软件测试网}%_Xu,S`T51Testing软件测试网/{.pl$LPtg7m@

u-K

但是关于维护成本，大家的观点不尽相同。对于第一种测试用例，有人认为cases的数量太多会增加维护成本。也有人认为减少case之间的依赖关系会降低维护成本。zBcI6B}0

b%w)d{bl/t*Y%xh0　　我相信，对于这样的一个问题，我们很难得到一个非此即彼的答案。关键是要能暂时放开自己信心满满的想法，听一听别人对这个事情是如何理解的:)-fc&D(K{/y!t0