EEPW论坛

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

　　讨论在以下三方面进行。

　　第一：（自动化）测试用例的表现能力

　　第二：测试用例的易用性

　　第三：测试用例的生成与维护成本

　　测试用例的表现能力

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

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

　　测试用例的易用性

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

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

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

　　测试用例的生成与维护成本

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

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

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