测试用例可简可繁

tomzhang

测试用例可简可繁，我始终认为测试用例的设计不必太刻板，理清了系统的功能点，然后套个模板就可以了。如果非要用UML来画个用例图，我觉得没有必要，毕竟你不是在需求调研阶段，不需要和用户讨论需求；而且功能点的划分，开发组已经都划分好了，他们在这方面的能力应该是比测试组的能力强一些，为什么不复用他们的？可能有人要说--测试人员是依据测试用例来测试的，我想问一下，有多少公司，有多少测试人员是拿着测试用例，按部就班的测试的？领导想这样，恐怕临近发布的时间了，时间上也不允许你这么做，这些都只是理论情况。个人拙见，见笑啦！我的QQ号：896219716，欢迎大家和我交流，加Q请注明来自51Testing，谢谢！

没有如果

前半段很赞同。

受我的上一个leader影像，我目前也对一句话用例十分推崇。

我们用例描述会直接写清验证内容，如：“验证出库单出库后，下级退回，本级可以操作出库单作废”，要测试这个系统的测试人员不会完全不了解业务，拿到这样的用例，还不知道如何操作，验证什么就可以去屎了，呵呵。我们的用例步骤往往被弄得比较简单，因为我们做项目的，需求变化比较大，所以花太多时间维护用例不现实。

至于后半段有一丁点不一样的想法，用例我觉得还是必要的，要花时间维护的，虽然我也跟我的团队裸奔过多次，项目太紧，但事实证明，裸奔总有一些遗漏。

当然也不是有了用例就能不遗漏，但我觉得会少。

一个团队一般都是稂莠不齐，有高工、初级也有实习生，高工对一个功能点可以想到4、5个验证点，而初级看到的可能只是一个保存。这时候，测试用例如果是经过高工指导过的，就能保证初级和实习生也能测试的更加充分。

另外有时候项目需求不明确的时候，我们还和开发过用例（开发负责需求调研）。开发给我们讲系统，10个功能点，可能他只讲到9个，而我们理解的有的可能是8.5，有的可能是7。如果有用例跟开发过，那9个他会跟你说，你哪里没涉及到，甚至会引导出他没讲到的部分。

以上，一些个人实践中得到的观点，欢迎大家交流。

[ 本帖最后由 没有如果 于 2010-4-25 08:06 编辑 ]