应该取消测试用例。
当测试人员拿到需求文档的时候，会把需求中提到的测试点写成测试用例（test case）。可是大家有没有想到，95％以上的test case是直接copy需求的，只有那5％是测试人员对需求的置疑和补充。 为什么不能把这些有价值的东西添加到需求文档中，从而成为需求管理的一部分。 这样当测试人员拿到一份完美的需求就可以直接开始测试了。 如果测试人员需要test case，我觉得有2部分极端浪费：1。test case 95％copy需求，本身就是浪费。
2。因为需求的变化而造成test case维护工作既复杂，又量大。
test case真正对测试人员和开发人员的参考价值值得测试人员花费如此精力去创建和维护吗？本人表示怀疑。
在我们实际项目中，test case在最初创建之后，基本上没有维护，也对测试人员根本没有参考价值。 基本上在创建之后就是废纸一堆。
我觉得如果有一份很好的需求文档，测试人员就可以开始测试了。 不知大家对test case的实际价值有什么高论？ 不是直接由需求得到测试用例的，先需要由需求得到测试需求，然后逐步细分得到测试用例。如果测试用例绝大部分是直接拷贝需求，那只能说是测试用例设计的很粗，很不合理。这不是测试用例本身的错，是设计的人没设计好。 请问楼上的，测试需求和需求在多大程度上是不重复的？ 测试需求和需求实际上就是一回事。 比如说： 需求中说，某一个页面要支持50个用户同时访问。 那测试需求就是要测试50个用户同时访问这个页面是否成功。 这不就是换个说法而已。实质上没有什么区别。 50个以内用户同时访问成功
50个以上用户同时访问时，保证有50个用户访问成功
50个以上用户同时访问时，系统响应时间在XX之内
......
lz还是先去学学测试用例吧 呵呵
楼主蛮可爱的 这就足以说明是楼主那里的测试用例设计的不好!
确切的说,是没从根本上去弄清楚测试用例是怎么一回事,而且估计你们在设计测试用例的时候也没有什么明确的方法,是吗?
如果真要设计出成功的测试用例,夸张点说,或许你能从需求中拷贝的只是5%,而95%需要发挥测试工程师或者说专门的设计用例人员的主观能动性了!~~~
嘻嘻~~个人意见............. 原帖由 冰河 于 2005-11-10 09:19 发表
这就足以说明是楼主那里的测试用例设计的不好!
确切的说,是没从根本上去弄清楚测试用例是怎么一回事,而且估计你们在设计测试用例的时候也没有什么明确的方法,是吗?
如果真要设计出成功的测试用例,夸张点说,或 ...
那再问一下，测试用例到底是怎么一回事？ 如果以用上面的例子为例，怎样设计测试用例？ :| 原帖由 null2 于 2005-11-9 17:42 发表
50个以内用户同时访问成功
50个以上用户同时访问时，保证有50个用户访问成功
50个以上用户同时访问时，系统响应时间在XX之内
......
lz还是先去学学测试用例吧
这位TX，这些难到不应该写在需求里面吗？ 如果需求中已经明显界定了50个用户需要相应的时间，那测试过程中，不是一样要验证测试的吗？ 一个需求会产生多个测试用例。
请lz先理解我的回帖。 原帖由 yy903 于 2005-11-11 09:43 发表
那再问一下，测试用例到底是怎么一回事？ 如果以用上面的例子为例，怎样设计测试用例？ :|
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
我感觉你说的那个例子,根据其特点,那就该采用等价类划分和边界值分析的方法来设计测试用例了......
呵呵 原帖由 null2 于 2005-11-11 10:07 发表
一个需求会产生多个测试用例。
请lz先理解我的回帖。
那也请这位TX先了解一下需求里面应该写什么。 我认为需求应该是一份不能引人歧义的非常明确的文档。 如果需求中有一句话，能让你引申出n多问题，那需求本身就不够严谨。 需求人员在需求捕捉的时候就没有做到位。 原帖由 冰河 于 2005-11-11 10:28 发表
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
我感觉你说的那个例子,根据其特点,那就该采用等价类划分和边界值分析的方法来设 ...
谢谢TX。那如果需求中对输入数据，执行条件和预期结果都有论及的话，是不是可以不用创建测试用例？ 我觉得问题忽然转向了，现在的问题是怎样的需求是一个好的需求。
在我们这里，需求采集人员被要求在书写需求时，要求记录相应的输入数据，输出数据和执行条件。以UseCase的形式。 对一些边界值在需求文档中也要有明确的说明。
所以，足够好的需求可以代替测试用例。 对吗？ :p 原帖由 yy903 于 2005-11-11 14:44 发表
谢谢TX。那如果需求中对输入数据，执行条件和预期结果都有论及的话，是不是可以不用创建测试用例？ 我觉得问题忽然转向了，现在的问题是怎样的需求是一个好的需求。
在我们这里，需求采集人员被要求在书写 ...
按lz的意思，概要设计、详细设计都可以取消了，都能在需求里反映 原帖由 null2 于 2005-11-11 14:54 发表
按lz的意思，概要设计、详细设计都可以取消了，都能在需求里反映
这位TX挺极端的嘛！ 如果你和用户去讨论Code，那不是有点自找麻烦嘛！ 呵呵
完美的需求我还真没见过，也许你们公司的需求真的是很完美！如果你们感觉你们按照需求测试出来的效果比设计用例后按照用例测试的效果明显好的话，你不妨就按照你们的需求测试吧。。。。。
其实测试工作本身就是保证软件或者产品的质量，怎么样有效的保证，我们就怎么做比较好！不是吗？ 原帖由 冰河 于 2005-11-13 18:43 发表
呵呵
完美的需求我还真没见过，也许你们公司的需求真的是很完美！如果你们感觉你们按照需求测试出来的效果比设计用例后按照用例测试的效果明显好的话，你不妨就按照你们的需求测试吧。。。。。
其实测试工作本 ...
:d 在某种意义上，测试系统的一切，包括测试过程、测试工具、测试报告、测试环境等，都应该支持测试用例的执行。也就是说，测试用例的生命期是贯穿整个测试过程与所有测试件的。测试用例负责对被测系统采取行动，由被测系统提供数据并执行，被测系统在某种情况下结束测试，产生测试人员能和期望结果进行比较的输出结果与行为。行为、数据和期望结果这三个值的集合是测试发生与测试条件创建的三个因素。因此，测试用例在测试过程中起到的作用可见一斑。
楼主，你所说的测试用例我想应该是狭义上的测试用例，它作为整个测试用例集中的一个子集，不同规模的项目中的确可以进行不同程度的取舍，但绝不能忽略。就如同楼主所描述的这类用例是基于规则导出法来构造的，规则来源于需求、协议、常识等外部依据，它们可以包含在需求中，也可以来自于其它参考资料。而除了规则导出，测试设计中还需要用到其它的方法，比如等价类划分法、边界值分析、因果图、判定表、正交实验设计、基于风险的测试、错误猜测等，这些如果统统包含在需求中加以描述的话那代价会有多高？同时，不知楼主有没有做过完整的系统测试，系统测试中除了功能测试外还有性能测试、压力测试、安全测试、文档测试、兼容性测试等，要有效的执行它们并且可以进行最大程度的量化分析，如果脱离开测试用例大纲，那如何进行？最后，测试用例还是测试设计人员与测试执行人员间的纽带，因为专业、能力与分工的不同比将导致他们协作间产生大量的沟通，对于分布式的系统架构更新如此，如果再加上人处异地，离开测试用例的媒介，沟通与反馈如何有效的开展？
当然，还可以从不同角度来阐述测试用例对于测试过程的关键性作用，比如内外评审、审计追踪与配置管理等方面，对于测试外包的工程，测试用例的规范文档化更是竞标的筹码，试想，如果一家从不写用例或写的用例如COPY需求般的测试外包公司来承接你的重要工程，你会同意吗？
以上纯属个人观点，欢迎大家继续交流讨论～～ 原帖由 迎风 于 2005-11-14 10:08 发表
在某种意义上，测试系统的一切，包括测试过程、测试工具、测试报告、测试环境等，都应该支持测试用例的执行。也就是说，测试用例的生命期是贯穿整个测试过程与所有测试件的。测试用例负责对被测系统采取行动，由被 ...
其实我觉得我们争的还是需求文档的内容问题。就拿性能测试来说吧，用户也许最初在需求采集的时候并没有想到性能，压力这么些事。 如果需求采集人员或者测试人员注意到了，请问性能测试的合格标准从哪里来，应该是用户，得到用户确认的标准吧！这些也可以补充到需求中去。
我不知道我做过的测试是不是这位TX所说的系统测试，但是在我测试的过程中，即使我创建了在需求文档中没有提及的测试用例，它的预期结果我还是要和需求人员确认，或者说和用户确认。 确认之后我们会将其补充到需求文档中。 所以对我们来说，需求是永远更新，永远被充实的。而用户我觉得对我们的工作也是满意的，因为我们为他们设想了更多。
对于测试外包的事，我没做过，不能发表什么意见。 不过，我觉得用户都是一样的，他不一定在乎你的测试用例写了多少，他也许真正在意的是你的测试对他产品的价值。能为他的产品带来什么样的提升。 所以他不一定在乎你是否用测试用例，还是需求来规范测试。
这是我的看法。 欢迎继续讨论。 :) 原帖由 yy903 于 2005-11-14 15:36 发表
其实我觉得我们争的还是需求文档的内容问题。就拿性能测试来说吧，用户也许最初在需求采集的时候并没有想到性能，压力这么些事。 如果需求采集人员或者测试人员注意到了，请问性能测试的合格标准从哪里来，应 ...
另外补充一点，我说的这种操作要求测试人员从需求采集阶段就介入，测试人员进入项目越早越好。而且做这件事的测试人员要求相对要高，也许就是楼上那位TX所说的测试设计人员，而不是测试执行人员。 :) 分开这个问题，我想问楼主一下：TX是什么意思啊？
嘿嘿
见谅，偶见识少 ：）
