应该取消测试用例。

xiongxing · 发表于 2007-8-23 16:56:36

学习了．

zhanglang · 发表于 2007-8-23 22:09:32

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

changlang530 · 发表于 2007-9-3 19:01:38

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

猪猪哦 · 发表于 2007-10-10 14:50:50

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

清风随雨 · 发表于 2007-10-11 13:00:24

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

xxjgogogo · 发表于 2007-10-12 11:43:53

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

margare0291 · 发表于 2011-11-3 16:52:48

本帖最后由 margare0291 于 2011-11-3 16:53 编辑

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

fwind1 · 发表于 2011-12-7 14:28:54

高手很多

yeats913 · 发表于 2011-12-7 16:17:51

不应该取消吧

福建的熊熊 · 发表于 2012-1-20 13:13:37

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

wzc369 · 发表于 2012-2-6 16:00:06

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

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

archonwang · 发表于 2012-2-6 16:30:53

不是很懂。

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

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

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

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

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

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

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

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

archonwang · 发表于 2012-2-6 16:32:38

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

476860312 · 发表于 2012-5-4 16:06:41

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

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

		自动登录	找回密码
密码			(注-册)加入51Testing

应该取消测试用例。

回复 40# 的帖子

站长推荐 /1