51Testing软件测试论坛

标题: 应该取消测试用例。 [打印本页]

作者: 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

原帖由冰河于 2005-11-10 09:19 发表
这就足以说明是楼主那里的测试用例设计的不好!
确切的说,是没从根本上去弄清楚测试用例是怎么一回事,而且估计你们在设计测试用例的时候也没有什么明确的方法,是吗?

如果真要设计出成功的测试用例,夸张点说,或 ...

那再问一下，测试用例到底是怎么一回事？如果以用上面的例子为例，怎样设计测试用例？ :|

作者: yy903 时间: 2005-11-11 09:45

原帖由 null2 于 2005-11-9 17:42 发表
50个以内用户同时访问成功
50个以上用户同时访问时，保证有50个用户访问成功
50个以上用户同时访问时，系统响应时间在XX之内
......

lz还是先去学学测试用例吧

这位TX，这些难到不应该写在需求里面吗？如果需求中已经明显界定了50个用户需要相应的时间，那测试过程中，不是一样要验证测试的吗？

作者: null2 时间: 2005-11-11 10:07
一个需求会产生多个测试用例。
请lz先理解我的回帖。

作者: 冰河 时间: 2005-11-11 10:28

原帖由 yy903 于 2005-11-11 09:43 发表

那再问一下，测试用例到底是怎么一回事？如果以用上面的例子为例，怎样设计测试用例？ :|

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

我感觉你说的那个例子,根据其特点,那就该采用等价类划分和边界值分析的方法来设计测试用例了......

呵呵

作者: yy903 时间: 2005-11-11 14:35

原帖由 null2 于 2005-11-11 10:07 发表
一个需求会产生多个测试用例。
请lz先理解我的回帖。

那也请这位TX先了解一下需求里面应该写什么。我认为需求应该是一份不能引人歧义的非常明确的文档。如果需求中有一句话，能让你引申出n多问题，那需求本身就不够严谨。需求人员在需求捕捉的时候就没有做到位。

作者: yy903 时间: 2005-11-11 14:44

原帖由冰河于 2005-11-11 10:28 发表

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

我感觉你说的那个例子,根据其特点,那就该采用等价类划分和边界值分析的方法来设 ...

谢谢TX。那如果需求中对输入数据，执行条件和预期结果都有论及的话，是不是可以不用创建测试用例？我觉得问题忽然转向了，现在的问题是怎样的需求是一个好的需求。

在我们这里，需求采集人员被要求在书写需求时，要求记录相应的输入数据，输出数据和执行条件。以UseCase的形式。对一些边界值在需求文档中也要有明确的说明。

所以，足够好的需求可以代替测试用例。对吗？ :p

作者: null2 时间: 2005-11-11 14:54

原帖由 yy903 于 2005-11-11 14:44 发表

谢谢TX。那如果需求中对输入数据，执行条件和预期结果都有论及的话，是不是可以不用创建测试用例？我觉得问题忽然转向了，现在的问题是怎样的需求是一个好的需求。

在我们这里，需求采集人员被要求在书写 ...

按lz的意思，概要设计、详细设计都可以取消了，都能在需求里反映

作者: yy903 时间: 2005-11-13 11:32

原帖由 null2 于 2005-11-11 14:54 发表

按lz的意思，概要设计、详细设计都可以取消了，都能在需求里反映

这位TX挺极端的嘛！如果你和用户去讨论Code，那不是有点自找麻烦嘛！

作者: 冰河 时间: 2005-11-13 18:43
呵呵

完美的需求我还真没见过，也许你们公司的需求真的是很完美！如果你们感觉你们按照需求测试出来的效果比设计用例后按照用例测试的效果明显好的话，你不妨就按照你们的需求测试吧。。。。。
其实测试工作本身就是保证软件或者产品的质量，怎么样有效的保证，我们就怎么做比较好！不是吗？

作者: yy903 时间: 2005-11-14 09:38

原帖由冰河于 2005-11-13 18:43 发表
呵呵

完美的需求我还真没见过，也许你们公司的需求真的是很完美！如果你们感觉你们按照需求测试出来的效果比设计用例后按照用例测试的效果明显好的话，你不妨就按照你们的需求测试吧。。。。。
其实测试工作本 ...

作者: 迎风 时间: 2005-11-14 10:08
在某种意义上，测试系统的一切，包括测试过程、测试工具、测试报告、测试环境等，都应该支持测试用例的执行。也就是说，测试用例的生命期是贯穿整个测试过程与所有测试件的。测试用例负责对被测系统采取行动，由被测系统提供数据并执行，被测系统在某种情况下结束测试，产生测试人员能和期望结果进行比较的输出结果与行为。行为、数据和期望结果这三个值的集合是测试发生与测试条件创建的三个因素。因此，测试用例在测试过程中起到的作用可见一斑。

楼主，你所说的测试用例我想应该是狭义上的测试用例，它作为整个测试用例集中的一个子集，不同规模的项目中的确可以进行不同程度的取舍，但绝不能忽略。就如同楼主所描述的这类用例是基于规则导出法来构造的，规则来源于需求、协议、常识等外部依据，它们可以包含在需求中，也可以来自于其它参考资料。而除了规则导出，测试设计中还需要用到其它的方法，比如等价类划分法、边界值分析、因果图、判定表、正交实验设计、基于风险的测试、错误猜测等，这些如果统统包含在需求中加以描述的话那代价会有多高？同时，不知楼主有没有做过完整的系统测试，系统测试中除了功能测试外还有性能测试、压力测试、安全测试、文档测试、兼容性测试等，要有效的执行它们并且可以进行最大程度的量化分析，如果脱离开测试用例大纲，那如何进行？最后，测试用例还是测试设计人员与测试执行人员间的纽带，因为专业、能力与分工的不同比将导致他们协作间产生大量的沟通，对于分布式的系统架构更新如此，如果再加上人处异地，离开测试用例的媒介，沟通与反馈如何有效的开展？

当然，还可以从不同角度来阐述测试用例对于测试过程的关键性作用，比如内外评审、审计追踪与配置管理等方面，对于测试外包的工程，测试用例的规范文档化更是竞标的筹码，试想，如果一家从不写用例或写的用例如COPY需求般的测试外包公司来承接你的重要工程，你会同意吗？

以上纯属个人观点，欢迎大家继续交流讨论～～

作者: yy903 时间: 2005-11-14 15:36

原帖由迎风于 2005-11-14 10:08 发表
在某种意义上，测试系统的一切，包括测试过程、测试工具、测试报告、测试环境等，都应该支持测试用例的执行。也就是说，测试用例的生命期是贯穿整个测试过程与所有测试件的。测试用例负责对被测系统采取行动，由被 ...

其实我觉得我们争的还是需求文档的内容问题。就拿性能测试来说吧，用户也许最初在需求采集的时候并没有想到性能，压力这么些事。如果需求采集人员或者测试人员注意到了，请问性能测试的合格标准从哪里来，应该是用户，得到用户确认的标准吧！这些也可以补充到需求中去。

我不知道我做过的测试是不是这位TX所说的系统测试，但是在我测试的过程中，即使我创建了在需求文档中没有提及的测试用例，它的预期结果我还是要和需求人员确认，或者说和用户确认。确认之后我们会将其补充到需求文档中。所以对我们来说，需求是永远更新，永远被充实的。而用户我觉得对我们的工作也是满意的，因为我们为他们设想了更多。

对于测试外包的事，我没做过，不能发表什么意见。不过，我觉得用户都是一样的，他不一定在乎你的测试用例写了多少，他也许真正在意的是你的测试对他产品的价值。能为他的产品带来什么样的提升。所以他不一定在乎你是否用测试用例，还是需求来规范测试。

这是我的看法。欢迎继续讨论。

作者: yy903 时间: 2005-11-14 15:38

原帖由 yy903 于 2005-11-14 15:36 发表

其实我觉得我们争的还是需求文档的内容问题。就拿性能测试来说吧，用户也许最初在需求采集的时候并没有想到性能，压力这么些事。如果需求采集人员或者测试人员注意到了，请问性能测试的合格标准从哪里来，应 ...

另外补充一点，我说的这种操作要求测试人员从需求采集阶段就介入，测试人员进入项目越早越好。而且做这件事的测试人员要求相对要高，也许就是楼上那位TX所说的测试设计人员，而不是测试执行人员。

作者: 冰河 时间: 2005-11-14 15:56
分开这个问题，我想问楼主一下：TX是什么意思啊？

嘿嘿
见谅，偶见识少：）

作者: yy903 时间: 2005-11-14 16:01

原帖由冰河于 2005-11-14 15:56 发表
分开这个问题，我想问楼主一下：TX是什么意思啊？

嘿嘿
见谅，偶见识少：）

TX=同学（Tong Xue）:d

作者: 冰河 时间: 2005-11-14 16:14
我晕.............................................

py就是朋友了~~~~~~~

汗一下~~~~~~~~

作者: yy903 时间: 2005-11-14 16:36

原帖由冰河于 2005-11-14 16:14 发表
我晕.............................................

py就是朋友了~~~~~~~

汗一下~~~~~~~~

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

原帖由 白菜叶子 于 2007-1-31 17:17 发表
如果没有测试用例做回归测试比较困难

如果用例是你自己写的，那是因为你比较清楚该测试些什么?做回归测试的时候也许你就记得不太清楚了.我的意思是不光是做回归测试比较困难,要是有人员变动,接手人员也无法很快进入测试.

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

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

作者: bzcy 时间: 2007-7-23 18:21

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

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

作者: liulinzhu 时间: 2007-7-24 16:43
都说单元测试可以查出80%的BUG，可为啥还有人提出取消测试用例呢？

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

作者: yuyanshe 时间: 2007-8-16 15:51
我公司的需求天天变更。。。。

作者: xiongxing 时间: 2007-8-23 16:56
学习了．

作者: zhanglang 时间: 2007-8-23 22:09
一个测试需求可能要产生多个测试用例,而一个测试用例也有可能来自多个测试需求.

作者: changlang530 时间: 2007-9-3 19:01
测试用例是为了保证软件功能正常运行，进一步到性能等。

作者: 猪猪哦 时间: 2007-10-10 14:50
标题: 回复 40# 的帖子
天天变更的需求如何去开发，如何去测试，如何去发布，如何去交付

作者: 清风随雨 时间: 2007-10-11 13:00
LZ所说得和测试用例有必然什么关系？需求只是要你明白需要实现什么，测试用例是你的测试方法哦

作者: xxjgogogo 时间: 2007-10-12 11:43
一个需求点是需要使用多个测试用例来验证的，搞清楚，不是一对一的关系！

作者: margare0291 时间: 2011-11-3 16:52
本帖最后由 margare0291 于 2011-11-3 16:53 编辑

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

作者: fwind1 时间: 2011-12-7 14:28
高手很多

作者: yeats913 时间: 2011-12-7 16:17
不应该取消吧

作者: 福建的熊熊 时间: 2012-1-20 13:13
要么你们学业务需求的人太强，强到把案例都写出来了。
要么你们写测试案例的人太懒，懒到都不去识别测试需求，不去用正反案例覆盖测试需求。

作者: wzc369 时间: 2012-2-6 16:00
楼主说的是,探索性测试.可以去查相关的理论知识,应该可以消除你的疑虑.

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

作者: archonwang 时间: 2012-2-6 16:30
不是很懂。

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

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

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

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

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

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

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

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

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

作者: 476860312 时间: 2012-5-4 16:06

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

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

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)