yy903 2005-11-9 16:38
应该取消测试用例。
当测试人员拿到需求文档的时候，会把需求中提到的测试点写成测试用例（test case）。可是大家有没有想到，95％以上的test case是直接copy需求的，只有那5％是测试人员对需求的置疑和补充。 为什么不能把这些有价值的东西添加到需求文档中，从而成为需求管理的一部分。 这样当测试人员拿到一份完美的需求就可以直接开始测试了。 如果测试人员需要test case，我觉得有2部分极端浪费：
1。test case 95％copy需求，本身就是浪费。
2。因为需求的变化而造成test case维护工作既复杂，又量大。
test case真正对测试人员和开发人员的参考价值值得测试人员花费如此精力去创建和维护吗？本人表示怀疑。
在我们实际项目中，test case在最初创建之后，基本上没有维护，也对测试人员根本没有参考价值。 基本上在创建之后就是废纸一堆。
我觉得如果有一份很好的需求文档，测试人员就可以开始测试了。 不知大家对test case的实际价值有什么高论？
skinapi 2005-11-9 16:49
不是直接由需求得到测试用例的，先需要由需求得到测试需求，然后逐步细分得到测试用例。如果测试用例绝大部分是直接拷贝需求，那只能说是测试用例设计的很粗，很不合理。这不是测试用例本身的错，是设计的人没设计好。
yy903 2005-11-9 17:02
请问楼上的，测试需求和需求在多大程度上是不重复的？ 测试需求和需求实际上就是一回事。 比如说： 需求中说，某一个页面要支持50个用户同时访问。 那测试需求就是要测试50个用户同时访问这个页面是否成功。 这不就是换个说法而已。实质上没有什么区别。
null2 2005-11-9 17:42
50个以内用户同时访问成功
50个以上用户同时访问时，保证有50个用户访问成功
50个以上用户同时访问时，系统响应时间在XX之内
......
lz还是先去学学测试用例吧
songfun 2005-11-9 19:01
呵呵
楼主蛮可爱的
冰河 2005-11-10 09:19
这就足以说明是楼主那里的测试用例设计的不好!
确切的说,是没从根本上去弄清楚测试用例是怎么一回事,而且估计你们在设计测试用例的时候也没有什么明确的方法,是吗?
如果真要设计出成功的测试用例,夸张点说,或许你能从需求中拷贝的只是5%,而95%需要发挥测试工程师或者说专门的设计用例人员的主观能动性了!~~~
嘻嘻~~个人意见.............
yy903 2005-11-11 09:43
[quote]原帖由 [i]冰河[/i] 于 2005-11-10 09:19 发表
这就足以说明是楼主那里的测试用例设计的不好!
确切的说,是没从根本上去弄清楚测试用例是怎么一回事,而且估计你们在设计测试用例的时候也没有什么明确的方法,是吗?
如果真要设计出成功的测试用例,夸张点说,或 ... [/quote]
那再问一下，测试用例到底是怎么一回事？ 如果以用上面的例子为例，怎样设计测试用例？ :|
yy903 2005-11-11 09:45
[quote]原帖由 [i]null2[/i] 于 2005-11-9 17:42 发表
50个以内用户同时访问成功
50个以上用户同时访问时，保证有50个用户访问成功
50个以上用户同时访问时，系统响应时间在XX之内
......
lz还是先去学学测试用例吧 [/quote]
这位TX，这些难到不应该写在需求里面吗？ 如果需求中已经明显界定了50个用户需要相应的时间，那测试过程中，不是一样要验证测试的吗？
null2 2005-11-11 10:07
一个需求会产生多个测试用例。
请lz先理解我的回帖。
冰河 2005-11-11 10:28
[quote]原帖由 [i]yy903[/i] 于 2005-11-11 09:43 发表
那再问一下，测试用例到底是怎么一回事？ 如果以用上面的例子为例，怎样设计测试用例？ :| [/quote]
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
我感觉你说的那个例子,根据其特点,那就该采用等价类划分和边界值分析的方法来设计测试用例了......
呵呵
yy903 2005-11-11 14:35
[quote]原帖由 [i]null2[/i] 于 2005-11-11 10:07 发表
一个需求会产生多个测试用例。
请lz先理解我的回帖。 [/quote]
那也请这位TX先了解一下需求里面应该写什么。 我认为需求应该是一份不能引人歧义的非常明确的文档。 如果需求中有一句话，能让你引申出n多问题，那需求本身就不够严谨。 需求人员在需求捕捉的时候就没有做到位。
yy903 2005-11-11 14:44
[quote]原帖由 [i]冰河[/i] 于 2005-11-11 10:28 发表
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
我感觉你说的那个例子,根据其特点,那就该采用等价类划分和边界值分析的方法来设 ... [/quote]
谢谢TX。那如果需求中对输入数据，执行条件和预期结果都有论及的话，是不是可以不用创建测试用例？ 我觉得问题忽然转向了，现在的问题是怎样的需求是一个好的需求。
在我们这里，需求采集人员被要求在书写需求时，要求记录相应的输入数据，输出数据和执行条件。以UseCase的形式。 对一些边界值在需求文档中也要有明确的说明。
所以，足够好的需求可以代替测试用例。 对吗？ :p
null2 2005-11-11 14:54
[quote]原帖由 [i]yy903[/i] 于 2005-11-11 14:44 发表
谢谢TX。那如果需求中对输入数据，执行条件和预期结果都有论及的话，是不是可以不用创建测试用例？ 我觉得问题忽然转向了，现在的问题是怎样的需求是一个好的需求。
在我们这里，需求采集人员被要求在书写 ... [/quote]
按lz的意思，概要设计、详细设计都可以取消了，都能在需求里反映
yy903 2005-11-13 11:32
[quote]原帖由 [i]null2[/i] 于 2005-11-11 14:54 发表
按lz的意思，概要设计、详细设计都可以取消了，都能在需求里反映 [/quote]
这位TX挺极端的嘛！ 如果你和用户去讨论Code，那不是有点自找麻烦嘛！
冰河 2005-11-13 18:43
呵呵
完美的需求我还真没见过，也许你们公司的需求真的是很完美！如果你们感觉你们按照需求测试出来的效果比设计用例后按照用例测试的效果明显好的话，你不妨就按照你们的需求测试吧。。。。。
其实测试工作本身就是保证软件或者产品的质量，怎么样有效的保证，我们就怎么做比较好！不是吗？
yy903 2005-11-14 09:38
[quote]原帖由 [i]冰河[/i] 于 2005-11-13 18:43 发表
呵呵
完美的需求我还真没见过，也许你们公司的需求真的是很完美！如果你们感觉你们按照需求测试出来的效果比设计用例后按照用例测试的效果明显好的话，你不妨就按照你们的需求测试吧。。。。。
其实测试工作本 ... [/quote]
:d
迎风 2005-11-14 10:08
在某种意义上，测试系统的一切，包括测试过程、测试工具、测试报告、测试环境等，都应该支持测试用例的执行。也就是说，测试用例的生命期是贯穿整个测试过程与所有测试件的。测试用例负责对被测系统采取行动，由被测系统提供数据并执行，被测系统在某种情况下结束测试，产生测试人员能和期望结果进行比较的输出结果与行为。行为、数据和期望结果这三个值的集合是测试发生与测试条件创建的三个因素。因此，测试用例在测试过程中起到的作用可见一斑。
楼主，你所说的测试用例我想应该是狭义上的测试用例，它作为整个测试用例集中的一个子集，不同规模的项目中的确可以进行不同程度的取舍，但绝不能忽略。就如同楼主所描述的这类用例是基于规则导出法来构造的，规则来源于需求、协议、常识等外部依据，它们可以包含在需求中，也可以来自于其它参考资料。而除了规则导出，测试设计中还需要用到其它的方法，比如等价类划分法、边界值分析、因果图、判定表、正交实验设计、基于风险的测试、错误猜测等，这些如果统统包含在需求中加以描述的话那代价会有多高？同时，不知楼主有没有做过完整的系统测试，系统测试中除了功能测试外还有性能测试、压力测试、安全测试、文档测试、兼容性测试等，要有效的执行它们并且可以进行最大程度的量化分析，如果脱离开测试用例大纲，那如何进行？最后，测试用例还是测试设计人员与测试执行人员间的纽带，因为专业、能力与分工的不同比将导致他们协作间产生大量的沟通，对于分布式的系统架构更新如此，如果再加上人处异地，离开测试用例的媒介，沟通与反馈如何有效的开展？
当然，还可以从不同角度来阐述测试用例对于测试过程的关键性作用，比如内外评审、审计追踪与配置管理等方面，对于测试外包的工程，测试用例的规范文档化更是竞标的筹码，试想，如果一家从不写用例或写的用例如COPY需求般的测试外包公司来承接你的重要工程，你会同意吗？
以上纯属个人观点，欢迎大家继续交流讨论～～
yy903 2005-11-14 15:36
[quote]原帖由 [i]迎风[/i] 于 2005-11-14 10:08 发表
在某种意义上，测试系统的一切，包括测试过程、测试工具、测试报告、测试环境等，都应该支持测试用例的执行。也就是说，测试用例的生命期是贯穿整个测试过程与所有测试件的。测试用例负责对被测系统采取行动，由被 ... [/quote]
其实我觉得我们争的还是需求文档的内容问题。就拿性能测试来说吧，用户也许最初在需求采集的时候并没有想到性能，压力这么些事。 如果需求采集人员或者测试人员注意到了，请问性能测试的合格标准从哪里来，应该是用户，得到用户确认的标准吧！这些也可以补充到需求中去。
我不知道我做过的测试是不是这位TX所说的系统测试，但是在我测试的过程中，即使我创建了在需求文档中没有提及的测试用例，它的预期结果我还是要和需求人员确认，或者说和用户确认。 确认之后我们会将其补充到需求文档中。 所以对我们来说，需求是永远更新，永远被充实的。而用户我觉得对我们的工作也是满意的，因为我们为他们设想了更多。
对于测试外包的事，我没做过，不能发表什么意见。 不过，我觉得用户都是一样的，他不一定在乎你的测试用例写了多少，他也许真正在意的是你的测试对他产品的价值。能为他的产品带来什么样的提升。 所以他不一定在乎你是否用测试用例，还是需求来规范测试。
这是我的看法。 欢迎继续讨论。 :)
yy903 2005-11-14 15:38
[quote]原帖由 [i]yy903[/i] 于 2005-11-14 15:36 发表
其实我觉得我们争的还是需求文档的内容问题。就拿性能测试来说吧，用户也许最初在需求采集的时候并没有想到性能，压力这么些事。 如果需求采集人员或者测试人员注意到了，请问性能测试的合格标准从哪里来，应 ... [/quote]
另外补充一点，我说的这种操作要求测试人员从需求采集阶段就介入，测试人员进入项目越早越好。而且做这件事的测试人员要求相对要高，也许就是楼上那位TX所说的测试设计人员，而不是测试执行人员。 :)
冰河 2005-11-14 15:56
分开这个问题，我想问楼主一下：TX是什么意思啊？
嘿嘿
见谅，偶见识少 ：）
yy903 2005-11-14 16:01
[quote]原帖由 [i]冰河[/i] 于 2005-11-14 15:56 发表
分开这个问题，我想问楼主一下：TX是什么意思啊？
嘿嘿
见谅，偶见识少 ：） [/quote]
TX=同学（Tong Xue）:d
冰河 2005-11-14 16:14
我晕.............................................
py就是朋友了~~~~~~~
汗一下~~~~~~~~
yy903 2005-11-14 16:36
[quote]原帖由 [i]冰河[/i] 于 2005-11-14 16:14 发表
我晕.............................................
py就是朋友了~~~~~~~
汗一下~~~~~~~~ [/quote]
PY偶倒是没听说呢！ 嘻嘻。。。。:p
cwei0623 2007-1-17 16:27
LZ(楼主)TX(同学)需要好好理解测试用例sdlkfj5
1个需求产生N个测试用例
枫飞林 2007-1-22 11:57
本人觉的用例还是要写的啊！不是直接从需求中拷贝过来的，初期的测试用例可以是这样的，但是随着软件的完成，用例也应该逐步的完善。
windsmile 2007-1-22 13:02
测试用例的设计是整个软件测试工作的核心，测试用例反映队被测对象的质量要求，决定队测试对象的质量评估！
oracletest 2007-1-22 18:02
测试用例是必不可少的文档，没有测试用例，测试过程中会失去测试方向，导致测试覆盖率低，影响项目质量。
lana.li 2007-1-24 11:26
科学的测试用例会很好的帮助测试的进行
测试用例与需求分析的文档区别应该说是相当大的sdlkfj2
需求分析一般只有正常的流通
而测试用例则需要有错误的流通
如果你知道边界值分析法，等价类划分法就用该知道测试用例与需求分析文档的区别了sdlkfj2
luoyear 2007-1-26 22:18
测试用例不仅要识别需求场景形成具体的case
并且有case的执行步骤
case的期望结果
需求也许只涵盖了场景
但却没告诉你验证方法
和基于验证方法的结果判断
另外还有一个很重要的问题
测试设计应该是最经济的测试实施的方案。
难道有100种排列组合
你直接按需求去测试
你挑哪20种组合具有代表性呢？
April.H.X 2007-1-27 19:33
测试用例要覆盖需求的正常事件,异常事件,还有需求中没有涉及到的潜在但隐含着的事件.
测试用例是必不可少的,如果真的如LZ所说的那样, 那要么是你们的需求做的非常细致, 要么是对测试用例存在理解上的偏差.
对于测试人员来说,不是取消用例的设计,而是要提高用例设计的水平,提高测试用例的质量.
欣奕 2007-1-30 10:07
大家都说得很好，学习了sdlkfj2
白菜叶子 2007-1-31 17:17
如果没有测试用例做回归测试比较困难
oracletest 2007-2-1 15:19
[quote]原帖由 [i]白菜叶子[/i] 于 2007-1-31 17:17 发表
如果没有测试用例做回归测试比较困难 [/quote]
如果用例是你自己写的，那是因为你比较清楚该测试些什么?做回归测试的时候也许你就记得不太清楚了.我的意思是不光是做回归测试比较困难,要是有人员变动,接手人员也无法很快进入测试.
ccc11yyy 2007-2-1 17:44
还可以让客户来写测试用例，来取代需求。这也是一种精益开发方法中的一点。
xinxiachen 2007-7-19 18:46
回复 #1 yy903 的帖子
其实这是由于测试工作分配不合理才造成你的误解.
如果测试人员是由一个项目开始跟到结束,可能测试用例需要不大,但如果要在测试过程中插进新人手,在他学习业务的过程中,可以由测试用例进行测试并结合来学习.这也是用例的存在原因.
特别是没有参与需求,而需求文档不能面面俱到,很多功能点都会漏掉.在回归在最容易发现这点.
skyzjh 2007-7-23 14:45
在拿到需求的初期，我觉得还是以测试点的分析为主；等开发到一定阶段，再细化测试用例
bzcy 2007-7-23 18:21
[quote]原帖由 [i]ccc11yyy[/i] 于 2007-2-1 17:44 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=430068&ptid=20857][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
还可以让客户来写测试用例，来取代需求。这也是一种精益开发方法中的一点。 [/quote]
有多少客户懂测试。。。
写测试用例不只是对需求上的，另外总要考虑其他方面的吧，比方些异常
liulinzhu 2007-7-24 16:43
都说单元测试可以查出80%的BUG，可为啥还有人提出取消测试用例呢？
xhzhou_cll 2007-7-24 18:06
测试用例
1：以前每接一个项目，都会先写测试用例。发现写测试用例的好处就是对整个项目有个了解。但是每次写完测试用例后，由于测试时间很紧，所以就基本上没有按照已经写好的测试用例来执行测试了。到了执行测试的时候，都是想到哪就测到哪，这样发现BUG的速度还快得多。此时发现测试用例就是一堆没有用的废纸了。
2：因为需求变得快，基本上是初步写完测试用例，以后就不会再对其进行维护了。但是如果遇到版本更新很快的项目且又没有测试用例时，则会在每次发布给客户版本之前的测试又是很不全面，软件质量就差了很多。所以现在的做法是，先写个大概的测试用例，就当是了解整个项目的测试需求了，当执行测试完后，利用空闲时间好好的整理，维护好测试用例，等到下一次版本更新的时候，就可以用整理好的测试用例了。
yuyanshe 2007-8-16 15:51
我公司的需求天天变更。。。。