应该取消测试用例。

yy903

当测试人员拿到需求文档的时候，会把需求中提到的测试点写成测试用例（test case）。可是大家有没有想到，95％以上的test case是直接copy需求的，只有那5％是测试人员对需求的置疑和补充。 为什么不能把这些有价值的东西添加到需求文档中，从而成为需求管理的一部分。 这样当测试人员拿到一份完美的需求就可以直接开始测试了。 如果测试人员需要test case，我觉得有2部分极端浪费：
1。test case 95％copy需求，本身就是浪费。
2。因为需求的变化而造成test case维护工作既复杂，又量大。
test case真正对测试人员和开发人员的参考价值值得测试人员花费如此精力去创建和维护吗？本人表示怀疑。  

在我们实际项目中，test case在最初创建之后，基本上没有维护，也对测试人员根本没有参考价值。 基本上在创建之后就是废纸一堆。

我觉得如果有一份很好的需求文档，测试人员就可以开始测试了。 不知大家对test case的实际价值有什么高论？

476860312

帖子很老了。我们一直都在实践，尝试超越传统的模式。回头看时，走过的路，有些已经离得太远而不再清晰。只 ...
archonwang 发表于 2012-2-6 16:32

    顶一下，这是论坛存在的意义，有交流，才能更快、更好的进步...

archonwang

帖子很老了。我们一直都在实践，尝试超越传统的模式。回头看时，走过的路，有些已经离得太远而不再清晰。只是，走过的弯路，不希望后辈们再重新走过。

archonwang

不是很懂。

取消与否的决定权可能不在我们。。

如果说可以取消测试用例，那么需求水平是很高水平的。清楚、完整、无二义性。同时，在需求中应该已经罗列了所有的业务规则，基本处理逻辑、操作逻辑、甚至是界面布局及控件格式设置。

做这样一份需求会比较累，看过了日美一些公司做的样式书和需求说明后，觉得国内的需求水平说起来真不过尔尔。

对于测试人员而言，重要的内容已经有了，重要的逻辑已经有了，剩下的基本上全靠个人感觉。举个最简单的例子，在需求文档中，你们会用多少笔墨描述页面布局？又会花多少笔墨描述操作逻辑和处理逻辑？

一个小问题：对于任何基本的输入定义，我们是这样做的么？

输入字段名称？含义？必填？默认值？类型代码？长度？格式？规则约束？

——恐怕很少。大多数时候都是因为基于项目的要求将这部分工作全部用到了设计阶段，然后再往后直到拖延到编码阶段。这个时候，测试几乎对其一无所知，或者，是按自己的想法考虑罢了。


老实说，我一点也不希望有测试用例，费时耗力，不得善终。但是又离不开它。倡导这样的做法，如果你要让测试用例消失，请让测试人员至少参与编写需求。但一般情况下，需求总是BA的事情，与测试编写无关。

wzc369

楼主说的是,探索性测试.可以去查相关的理论知识,应该可以消除你的疑虑.

        一句话概况的话,探索性测试是完全依赖于测试人员水平的测试.虽然效率不错,但风险较大.基本是在没有办法的时候才采取的方式.

福建的熊熊

要么你们学业务需求的人太强，强到把案例都写出来了。
要么你们写测试案例的人太懒，懒到都不去识别测试需求，不去用正反案例覆盖测试需求。

yeats913

不应该取消吧

fwind1

高手很多

margare0291

一个需求不止对应一个测试用例，再完美的需求也不会面面俱到，只是描述正常工作流，而测试用例还要覆盖很多异常情况，如果只是拿需求来对应检查功能，那么LZ表述的应该是验收测试！

xxjgogogo

一个需求点是需要使用多个测试用例来验证的，搞清楚，不是一对一的关系！

清风随雨

LZ所说得和测试用例有必然什么关系？需求只是要你明白需要实现什么，测试用例是你的测试方法哦

猪猪哦

天天变更的需求如何去开发，如何去测试，如何去发布，如何去交付

changlang530

测试用例是为了保证软件功能正常运行，进一步到性能等。

zhanglang

一个测试需求可能要产生多个测试用例,而一个测试用例也有可能来自多个测试需求.

xiongxing

学习了．

yuyanshe

我公司的需求天天变更。。。。

xhzhou_cll

1：以前每接一个项目，都会先写测试用例。发现写测试用例的好处就是对整个项目有个了解。但是每次写完测试用例后，由于测试时间很紧，所以就基本上没有按照已经写好的测试用例来执行测试了。到了执行测试的时候，都是想到哪就测到哪，这样发现BUG的速度还快得多。此时发现测试用例就是一堆没有用的废纸了。
2：因为需求变得快，基本上是初步写完测试用例，以后就不会再对其进行维护了。但是如果遇到版本更新很快的项目且又没有测试用例时，则会在每次发布给客户版本之前的测试又是很不全面，软件质量就差了很多。所以现在的做法是，先写个大概的测试用例，就当是了解整个项目的测试需求了，当执行测试完后，利用空闲时间好好的整理，维护好测试用例，等到下一次版本更新的时候，就可以用整理好的测试用例了。

liulinzhu

都说单元测试可以查出80%的BUG，可为啥还有人提出取消测试用例呢？

bzcy

原帖由 ccc11yyy 于 2007-2-1 17:44 发表
还可以让客户来写测试用例，来取代需求。这也是一种精益开发方法中的一点。

有多少客户懂测试。。。
写测试用例不只是对需求上的，另外总要考虑其他方面的吧，比方些异常

xinxiachen

其实这是由于测试工作分配不合理才造成你的误解.
如果测试人员是由一个项目开始跟到结束,可能测试用例需要不大,但如果要在测试过程中插进新人手,在他学习业务的过程中,可以由测试用例进行测试并结合来学习.这也是用例的存在原因.
特别是没有参与需求,而需求文档不能面面俱到,很多功能点都会漏掉.在回归在最容易发现这点.

ccc11yyy

还可以让客户来写测试用例，来取代需求。这也是一种精益开发方法中的一点。