51Testing软件测试论坛

标题: 生命周期半年的项目需求是否有必要写用例？（2009-2-9 ）获奖名单已公布 [打印本页]

作者: 默默巫 时间: 2009-2-9 13:58
标题: 生命周期半年的项目需求是否有必要写用例？（2009-2-9 ）获奖名单已公布
背景描述:对于稳定客户的项目类测试,经常会遇到需求三天一变,两天一变,由于时间周期不是太长,客户需求经常变动,导致BA/PM等都未能及时更新需求,从而给测试组的需求经常是非最新版本,且测试阶段的需求也经常有小变动,导致用例效果不大甚至失效.(可能是针对需求说明书失效,更多情况是针对实际需求-即系统实现方式失效).

感谢会员joycena提供此精彩话题！如果你也有矛盾的问题想提出来和大家一起讨论，请点击此处>>
说不定下期PK的话题就是由你提出的哦，请快快参与吧！

奖项 获奖名单 奖励 答案连接
最佳话题PK手 Jackc
当当购物卡50元+最佳PK手勋章
39#

作者: aman_cao 时间: 2009-2-9 15:40
需求总是在变动的，但变是相对于不变的需求而言的，软件在各阶段，需求总是变化的。有变化，就要记录变更，就要记录对应的用例。这样做可以使需求，用例，结果的可跟踪。

作者: zynuage 时间: 2009-2-9 16:52
不管软件的生命周期是多长时间，写测试用例是必须的。测试的宗旨是使软件的bug降低到最小，对客户的影响最小，如果没有测试用例，测试工程师会想出很多冗余的测试用例，浪费了很多时间，最后有可能漏掉致命的缺陷。

作者: ahu201 时间: 2009-2-10 10:21
标题: 必要的前提是代价
1. 正如对方aman_cao所说: "需求总是在变动的", 但显然他曲解了使用了后半句"但变是相对于不变的需求而言的", 我们使用论点的背景是"经常会遇到需求三天一变,两天一变,由于时间周期不是太长,客户需求经常变动".
如果需求变动很小或者相对很小,我关注的是重新写还是跟踪它的变化?那一点更有价值更有必要? 我们都知道需求决定用例,如果需求变了测试用例必然需要更新, 但是当测试用例"效果不大甚至失效"时,有必要去写么?
2. 而zynuage所说:"不管软件的生命周期是多长时间，写测试用例是必须的",请问写测试用例在软件生命中的哪个周期?请问合理的流程和开发模式又是什么?而将测试的重点放在测试用例上,显然又和辩友的"测试宗旨是使软件的bug降低到最小"是矛盾的,当需求不断变化的时候,如何保证测试用例的可依据性?

下面我提出我方观点:
1. 对于需求变动比较频繁,或者软件生命周期比较短的, 我们测试的依据可以适当进行调整,譬如:i, 最新的需求个功能列表. ii, 公司软件规范要求列表. iii, 软件需求变化跟踪列表.
2. 对于需求变动比较频繁,或者软件生命周期比较短的, 我们测试重点不是测试用例编写, 而是如何快速准确的定位客户的最新需求, 在软件生命周期中可开发协调工作,保证最优的实现, 将项目代价降低到最低,避免重复冗余的劳动.

以上观点, 从软件工程角度来说可能是不合理的,但是在我们大部分国内软件公司中确实就是这么去做的,"存在即为合理", 因为这样的论题背景在软件工程也是要尽量避免的.

-----抛砖引玉,不吝赐教..

作者: pupu840323 时间: 2009-2-10 15:17
标题: 测试用例的意义以及适用性
开门见山的说，我认为不需要写测试用例，但我们需要简化版的功能覆盖点。

一、测试用例意义：
测试用例主要是督促测试人员熟悉理解业务情况，辅助全面回归测试，梳理测试思路，测试用例的好坏，在交叉测试中尤为凸显。
测试用例的引入，致使测试人员在测试之前就需要对业务很了解，知道如何着手测试，在这个过程中寻找模块间关联点，不断补充进测试用例。就好比油画，通过不断的渲染和填充，才能使我们发表一幅优秀的作品。他的作用就在于让我们深入透彻的了解系统架构和业务知识，以及数据关联性等。
在回归测试以及交叉测试中，用例让我们可以很快速的想起测试思路和过程，帮助其他测试人员熟悉测试模块，检测其他人员的测试用例是否全面等。有很多时候，我们往往会突然冒出一些有亮点测试思路，但人又偏偏是记性差的生物，到后面也就忘记的干净，测试用例的记录，帮助我们将所有的测试思路和过程记录，辅助我们进行记忆。举个例子，一个人拿着模板来写字，您说能不容易吗。交叉测试中，别人对你的测试模块一无所知，再讲一遍，不仅自己感觉繁琐，也影响进度时间，而好的用例不需要讲解，就可以很好的引导测试人员进行测试工作。举个例子，盲人走路很困难，但有了导盲犬后，他们就可以非常方便的出行。
通过上面这些，可以看出测试用例的重要性，可以说，测试用例是不可缺少的。

二、测试用例适用性
测试用例如果想实用，那麽他所带来的工作量就会非常大，我们需要很多的时间来完善和补充，所以如果项目变动很小，那麽测试用例将是长久性的保持效用。但如果项目变动大，则测试用例的维护成本将使测试质量明显下降。
通过这些我们可以看出，测试用例在这种情况下又是不能引入的。

三、解决方法
为了解决测试用例的意义所带来的效益，测试用例适用性所带来的缺陷，我认为应该引入功能覆盖点来平衡这两方面因素。
功能覆盖点是对所测试项目功能点的一个简要概括，编写功能覆盖点可以让我们去熟悉业务系统，平且将功能点，关联点等简单罗列，让我们纵观测试的广度和深度。在需求变动情况大的情况下，维护功能覆盖点的成本要远远小于测试用例，他所带来的效用是实效而灵活的。

综上所述，测试用例在需求变动大的项目中，是不需要引入的，而应该引入更为实效的功能覆盖点，辅助测试工作的开展和考察。

作者: 62369432 时间: 2009-2-11 11:33
用例是必需的.软件在用例在.如果时间赶,那只能在后面补咯

作者: candy_83 时间: 2009-2-11 13:48
标题: 追踪需求进行测试
编写维护测试用例是需要很多人力和时间成本的，如果维护用例的速度都赶不上需求变化的速度，在这种情况下不如根据需求来测，而不是测试用例，日常追踪需求的变化，根据需求的变化进行对应的测试。当然测试工程师必须要有责任心，在没有用例的情况下也能尽可能地进行各种各样的有效测试，只要保证需求100%被覆盖就可以了。

作者: yetties2005 时间: 2009-2-11 17:50
觉得还是有必要去设计测试用例的。自由测试避免不了会漏测
随着需求的变更在跟着更改测试用例。前提测试人手要充足

作者: 不要长大的小孩 时间: 2009-2-11 17:59
标题: 有必要的，侧重点偏移下。
我认为还是有必要的，不能因为周期短而忽略这部分，对于管理来说，会有漏洞的。
至于怎么写，整个项目组需要达成一直，尽量简化，模板化，节约成本。
而至此引发了一个问题，版本的管理问题，因为需求变更的频繁，版本的管理要跟上，不然写起用例来，会跟不上进度。
拙见，

作者: b45993e 时间: 2009-2-11 18:00

扔有必要写用例，不能因为时间短就忽略．

作者: ipkh840122 时间: 2009-2-12 10:52
按照CMMI的要求，需求进行变更后，是需要做记录的，所以应该要写用例。

作者: wadextzy 时间: 2009-2-12 15:03
标题: 必要
非常必要
测试用例是需要写的！！

作者: hblinna 时间: 2009-2-12 15:05
标题: 有必要写用例，但可以写简化用列
虽然需求在经常变动，但一个相对小的时间里需求总是稳定的，所以用列还是需要写，不仅是在写用列的过程中可以发现一些细节性的问题，而且还可以让测试人员更好的理解需求。由于需求经常变动，我们的用列也可以稍微简化，可以只写到没有用列应当关注的点，测试步骤就可以不写。呵呵个人观点。

作者: hai105 时间: 2009-2-12 15:21
我认为仍有必须写测试用例，因为通过测试用例除了可以发现BUG，同时还要依据用例对BUG进行重现，如果不修改测试用例，仅仅通过个人的想象来测试，很难做到BUG的重现，而且有了测试用例，其它人员也能容易的接收对软件的测试工作。同时随着需求的改变，修改测试用例，也更加深了测试人员对需求的理解。

作者: maclehappy13 时间: 2009-2-12 15:21
对于需求变更非常频繁的项目可不用花过多时间在测试用例上面，如果非得写用例，就会因用例搞人仰马翻。测试活动是靠测试计划指导的。所以只要在需求变更时候，根据需要调整测试计划即可。但需求变更后是必须记录的。测试覆盖还可以通过需求的覆盖来保证。我在现在中就是这样做的。非常赞同pupu840323说的前两点。

作者: wsr123321 时间: 2009-2-12 15:57
标题: 必要：但可以分情况编写或补充
个人认为：在项目时间和人员允许的的情况下可编写测试用例；条件不具备的情况下可以在项目完成后补充。对照需求变更，用例起一个项目跟踪的作用，可在项目中有效重复利用。

作者: namisang 时间: 2009-2-12 16:08
没有必要写
费神浪费时间．

作者: sweetxmy 时间: 2009-2-12 16:10
标题: 写需求（或测试用例）是为了更好的确认测试目标和提高团队工作能力
写需求（或测试用例）是为了更好的确认测试目标和提高团队工作能力

1、很多开发团队认为写不断变化的需求（或测试用例）是浪费时间，何不用这个时间做开发和测试。
但事实是，随着时间的推移，同时因为没有需求文档（或测试用例），每个人记住的资料又非常有限（谁都不能否认自己的记忆力随着年龄的增长不断老化，二者人总有个头痛脑热的时候，有时如果不是开会或小组讨论也许会遗忘通知某些人），最差的后果一有分岐导致大家找PM或客户做确认。

2、由谁来写需求（或测试用例），一个小团队并没有划分真正写需求文档（或测试用例）的人。
做为测试人员，当公司的开发未完成这项任务时，只有测试人员自己整理需求（或测试用例），在测试过程中不断完善需求（或测试用例）。

3、无论谁写文档（或测试用例），从长远来看。对个人或公司都是一笔很大的财富。
一个经常写需求（或测试用例）的人，势必非常了解所写项目的功能，当二次出现同类的需求（或测试用例）时，可以在第一时间做出有利的判断（因为之前有失败的经验做后盾）。
对于一个新人，是锻炼和提升自我的最佳机会。
对于公司是一大笔无形资产。

4、如果一个项目做好了形成公司的产品，原有的需求文档（或测试用例）优势就更大了。
当团队进行2次开发或升级时就有参照的依据，可以屏弃不适合的模式，寻求高效益的功能。
如果是外资企业，国内做好了需求（或测试用例），想想2期开发只能由国内开发（测试）团队来完成，可以说增加大家的工作机会。（现在可是经济危机）

个人观点仅供参考，希望和大家一起讨论。

[ 本帖最后由 sweetxmy 于 2009-2-12 16:13 编辑 ]

作者: milklybaby 时间: 2009-2-12 16:22
标题: 来尝试一下
这种情况在做客户现场项目时候实在是太常见了。

首先批评一下公司方的客户联络人员，对客户没有一点影响力，就这么容忍他随便改需求吗？带来的工作量和不断的返工次数，如果对方不付钱，你们老板不会吹胡子瞪眼吗？

其次既然现象已经发生，为了避免开发人员和测试人员都跟着重复劳动疲于追命，那就做一个好的需求跟踪矩阵吧，做不到？偶说第三点

再次测试人员不能够只拘泥于需求规格说明书啊，当然测试用例的第一版还是要依据这个的，后面就得多靠自己把握啦，灵活多变是必须得能力哈。

最后，该写的还是写吧，免得最后会发现统计工作量时没有必要的支撑数据。

作者: 光明 时间: 2009-2-12 16:32
标题: 支持
谁都不能否认自己的记忆力随着年龄的增长不断老化，二者人总有个头痛脑热的时候，有时如果不是开会或小组讨论也许会遗忘通知某些人

作者: 郁闷的我 时间: 2009-2-13 13:26
仍有必要写用例吧．

作者: 博一笑 时间: 2009-2-13 14:30
我个人认为要写用例，但是我有个疑问啊，有没有必要实时得去改用例，就是需求一变，用例就要修改，这样得人力投入是不是比较不值得

作者: atomtiger 时间: 2009-2-17 16:10
标题: 我觉得还是要写测试用例的
如果变动的很频繁，甚至1，2天，半天一变的。
但变的也大概只会是细节。总的目标不会变。

哪怕是简单的写写，写上测试目的，内容，测试过程，即使很简单很大略的写写。也是要写的。

测试的工作是相对比较繁琐，比较要求细致完善的。
写下来，其实也是为了有个头绪。有个工作的路线。

作者: jenvee 时间: 2009-2-17 16:20
标题: 更新修改原有用例
如果客户经常性变更需求(增加)，那么必须重新添加用例；如果只是在原有基础上更改需求的话，可以不用添加新的用例，只需在原来用例基础上作以修改，这样就产生新的用例了，而且投入的精力，物力，财力也很少。

作者: lansnor 时间: 2009-2-17 16:48
就我公司的做法，用户验收项目的时候，是要测试用例的，因此不论需求怎么变化，测试用例还是要编写，当然我公司的做法是，项目后期再写用例，这样改动较小。

作者: tinayuan1981 时间: 2009-2-17 18:29
当然要写，测试用例是写给自己看的，不写自己不就乱了？

作者: Okayde 时间: 2009-2-17 21:36
标题: 有必要写用例，用例是用来保障测试的质量
用例是根据需求来设计的，如果需求改变的话，也可以根据改变的需求，跟踪到具体的用例来修改。我觉得用例没必要写太复杂，不过一定要写，而且要与需求相匹配，这样可以防漏测，也防止变更。

作者: 月野幻儿 时间: 2009-2-18 10:40
没有必要写，耗力．
需求三天两头变，自己随机应变．

作者: b45993e 时间: 2009-2-18 10:44
需要编写

作者: wuyu702 时间: 2009-2-18 13:57
写还是有必要的，关键是怎么写，什么时候写：
首先，我们要搞清楚为什么写用例，依据是什么。我觉得写用例有三个目的：
一个是为了更好的理解需求，只有在写用例的过程中我们测试人员才能深入的理解某些需求。二是为了测试过程中能够更好的方便快捷的进行测试。
三是能够为下个版本的测试提供一些帮助。

如果需求变动很频繁，可以说我们如果一开始就去写用例的话，变一次需求就改一次用例，其实达不到方便快捷的目的。深入理解需求也谈不上，因为需求不停的变，你理解了又变了。。。所以呢，我一般遇到这种项目，都是先会把大概的用例写出来，测试的过程中，不停的添加用例。最后测试完了，用例也出来了。。下次测试忘记了。。还是可以依据这次的用例去给出些指导。

作者: jessies 时间: 2009-2-18 14:29
标题: 用例是必须的，否则无法保证整个测试过程是否符合需求
必须要写，不写用例，你何以保证你的测试是满足需求的？何必保证你的执行过程是正确的？
对于需求经常变的项目，为什么不让需求进入到稍微稳定的阶段再进入用例的编写？需求变更是不可避免的，但是有时候，需求变更的频率是我们可以控制的。
用例天天修改可能会浪费一些时间，但是对于整个项目来说还是有必要的，可以用一种简单的方式来写用例，保证前后可追溯。

作者: 兆隆8032 时间: 2009-2-18 14:44
标题: 测试用例可以是证据
没有测试用例，在一些偶然出现缺陷即不可重现的缺陷，是很难被记录下来的。
在向开发人员说明曾出现这个错误的时候，没有证据，没有证据谁相信啊！自己做了事情反而没有得到效果，这样干工作太笨了。

作者: 猫猫的拖鞋 时间: 2009-2-18 16:31
有人力就写，没人力何必写。

作者: hushiping2222 时间: 2009-2-18 16:59
有必要写

作者: namisang 时间: 2009-2-18 17:10

原帖由 wuyu702 于 2009-2-18 13:57 发表
写还是有必要的，关键是怎么写，什么时候写：
首先，我们要搞清楚为什么写用例，依据是什么。我觉得写用例有三个目的：
一个是为了更好的理解需求，只有在写用例的过程中我们测试人员才能深入的理解某些需求。二是 ...

不错不错．

作者: namisang 时间: 2009-2-18 17:10

原帖由 wuyu702 于 2009-2-18 13:57 发表
写还是有必要的，关键是怎么写，什么时候写：
首先，我们要搞清楚为什么写用例，依据是什么。我觉得写用例有三个目的：
一个是为了更好的理解需求，只有在写用例的过程中我们测试人员才能深入的理解某些需求。二是 ...

不错不错

作者: wxm2004734 时间: 2009-2-19 08:57
唉，写简单一点。没有规矩，不成方圆。要是你能控制过来，你NX

作者: 默默巫 时间: 2009-2-19 11:59
希望大家都讨论起来．

作者: beryl_lin 时间: 2009-2-19 13:15
标题: 有必要写测试用例
测试的目的就是尽可能的减少系统的bug，确保软件的质量，好的测试用例是保证测试质量的前提。
如果没有测试用例，对于相对比较复杂的功能，尤其是多人同时参与测试的情况下，很可能忽略某些很重要的细节，从而放过了很多bug。严格的讲，不仅需要测试用例，而且测试用例必须经过多人评审，确保其质量才行。需求变动，测试人员拿不到最新的需求，但这不是不写测试用例的借口，相反，应该尽可能的督促相关人员以拿到最新的需求，根据变动及时更新测试用例。

作者: Jackc 时间: 2009-2-19 13:49
标题: 敏捷性测试团队才是王道
1、LZ的题目中缺少两个关键属性：项目的规模（包括需求变更规模）和测试资源

2、浅析项目规模和测试资源的影响
其实LZ这个题目最大的争议点就是在这里，如果这两个属性可以确定，相信大家的思路会清晰很多。下面偶只分两类进行简单的分析：
A、项目规模大（需求变更规模大），测试资源少：按照CMMI 5中测试用例的编写标准来说，限定6个月的时间。测试团队需要完成测试策略/计划的拟定和评审、测试用例的设计/评审/修改、变更需求的评审/修改、新需求测试用例的设计/评审/修改...
   显而易见，剩余还有多少时间完成测试执行的跟踪和改进？即使前期能勉强跟进，偶相信在后期也只能疲于奔命，敷衍了事，什么“测试驱动开发”也只是梦中花而已。
   国内很多企业都是这样的情况，相信N多测试同仁对此是深有体会。
B、项目规模小（需求变更规模小），测试资源多：人多好办事，只要Test Manger不是个草包，将测试工作进行有条理的细分，责任到人，在测试准备阶段选择有利于修改的测试流程（包括简易需求和测试资源变更流程以及便于变更的测试用例模板等等），在测试执行阶段，注意需求收集已经各部门以及客户之间的信息交流，还是很容易搞定的。

3、浅析正方观点的风险：
A、如正方wuyu702 所说：“先会把大概的用例写出来，测试的过程中，不停的添加用例。最后测试完了，用例也出来了。。”。
   什么叫大概的用例?
   用例最基本的要求就是任何测试人员都可以操作,敢问你如果写出这样缺斤少两的用例，当你临时有其他更重要的任务，然后把这块测试工作交付给其他人来做，能够保证别人肯定能看明白？
B、又如正方Okayde、wuyu702、jessies、兆隆8032等提出的：用例是用来保障测试的质量，以及对测试执行的指引。
   测试用例是唯一的保障产品/测试质量的手段？没有测试用例就无法指导和跟踪测试执行了？
   当然不是，这里偶引用一个只有部分公司在用的一个概念“测试规程（test procedure）”。它是个提供详细的测试用例执行指令的文档。测试规程更注重测试的流程、方法等比较泛的内容，以方便对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。
   测试规程与测试用例的区别：理想化的测试用例确实需要很多测试数据集合，但是现实中对某一软件进行测试时，由于涉及的面太广，无法一一列举出所有数据，所以要根据公司的规范来做相应的调整。所以，测试规程的文档编辑量较轻，但是只适合熟练的测试人员执行，而测试用例的执行者可以使任何人。
   楼上很多同仁谈到的根据实际情况写简化用列的做法实际就是将设计测试用例变为设计测试规程，然后以测试规程来指导测试执行，提供测试质量（比如测试覆盖率）的评估。但是楼上的同仁没有对简化测试用例提出标准？如果一个测试团队里有3、4个简化标准，大家的测试用例简化的“度”都不一致，岂不乱套？
C、2A中描述的项目情况，仍采用设计常规的测试用例的方法，那么只能有两种结果：a、披着“测试用例”的外套，却是到处缺胳膊少腿，敷衍了事，难以达到测试用例的覆盖标准；b、忙于测试用例的编写，无法在测试执行中完成测试的跟踪与改进，每天都疲于奔命，最终完成N个项目后，测试团队的水平仍然停滞不前，经常受到项目组的“鄙视”。

4、偶的观点：敏捷性测试团队才是王道，项目不同测试流程不同。针对LZ的项目，选择测试规程代替测试用例是明智之举。下面偶只针对与设计测试规程有关的部分提出一个简单的方案。
A、前提：测试团队组成基本由熟练测试人员组成（就软件黑盒测试来说，加入团队半年以上的就可以叫做熟练了）。统一规范的测试流程（相信这个只要是稍微正规点的公司都有）PS：此流程只适用于2B的情况，并且可以进行裁减。有些公司是将标准流程做成checklist形式，方便项目组选择。
B、策划：测试负责人根据项目实际情况在测试准备阶段裁减出适用于该项目的测试流程，并进行评审。其中有两点必须说明：测试执行依据采用测试用例还是测试规程或者两者皆用；测试用例（测试规程）设计的标准。
C、变更：满足以上两个条件，如若遇到实际需求被迫变更，则修改相应测试规程，并评审即可。修改测试规程和修改测试用例在工作量上存在很大的区别，偶举一个例子：
   为了简单，用例和规程的格式就忽略了，只写具体输入步骤一部分，书写格式也比较随意。
   原需求：编辑框A中允许输入最多20个中文
   规程的输入步骤：
   只输入0~20个中文,点击确定，检查结果。备注：其中0、20必须测试
   输入21个中文，检查结果
   输入非中文字符，检查结果。备注：包括英文/特殊符号...
   混合输入中文与非中文字符，检查结果。备注：中文字符在第一位的情况必须测试
   ...
   测试用例的输入步骤：
   不输入任何字符，点击确定，检查结果
   输入10个中文字符，点击确定，检查结果
   输入20个中文字符，点击确定，检查结果
   输入21个中文字符，点击确定，检查结果。
   ....（不写了，N多）
   假如修改需求：编辑框A中允许输入最多20个中文或数字
   规程的输入步骤：
   输入0~21个中文或数字，点击确定，检查结果。备注：数字/中文混合输入、0/20/21位字符输入必须测试。
   ....
   假如换成测试用例，那就只有....慢慢写了~
D、跟踪/评估：其实从4C中的例子可以看出，测试规程是可以对测试质量进行跟踪和评估的。当然还有其他很多测试质量评估方法，比如缺陷分析技术，详细信息请看http://bbs.51testing.com/thread-117496-1-2.html

小结：综上，LZ所说的问题可以使用测试规程代替测试用例来解决。
建立敏捷性测试团队，不“墨守成规”的进行测试活动，才是测试的王道

[ 本帖最后由 Jackc 于 2009-2-19 14:02 编辑 ]

作者: Jackc 时间: 2009-2-19 14:04
以上是偶以前工作的一些体会，有些怨气在里面（看来还没有磨练到“心平如水”的境界），大家见谅~

作者: CHOUYUNHAT 时间: 2009-2-19 17:13
标题: 测试用例是工作成果的体现
虽然需求总在变动，但测试用例还是应该写。这既体现了你的工作成果，也是出现问题后的证据。测试用例也表明了哪些需求是测试过的，哪些没有，避免了工作的随意性。

作者: puchonghui 时间: 2009-2-20 08:40
关键并不是需不需要写用例
而是明确自身的目的（你写用例的目的是什么？）
如果真的是变动比较多日程又比较紧的话
可以列一个check list...

作者: lanbiers 时间: 2009-2-20 13:26
需求决定功能

功能取决于测试

需求有变，功能跟着变，如何确定正确的变更？唯有测试

作者: sssddd 时间: 2009-2-20 13:32
看各种情况，再决定咯

作者: 单尾鱼 时间: 2009-2-20 13:46

原帖由 lanbiers 于 2009-2-20 13:26 发表
需求决定功能

功能取决于测试

需求有变，功能跟着变，如何确定正确的变更？唯有测试

同意！！

作者: birdcc 时间: 2009-2-20 16:30
需要写，但是要看你怎么写，在什么阶段写

首先按照传统的测试方法：
项目研发周期为半年的小项目，大概需要5人以下小团队花至少一星期去编写测试用例（包括了解需求的时间），根据楼主的说明（经常会遇到需求三天一变,两天一变），估计用例刚刚写完，就发现需求完全变了，然后更新用例，至少又要花上两到三天时间（而且还没有算上BA/PM等都更新需求的时间），需求再变~~用例再更新~~~测试人员花费了大量的时间浪费在用例上，也可能是老牛耕地，耕了又耕，毫无进展。而且测试人员编写的用例的质量也会慢慢变低，根本起不到用例的原始作用，反而成为累赘。
成本又多大，根本没办法估算，收益几乎为0.

对于这种情况我认为有必要先解决项目的经常变更的问题。变更是无限的，项目周期是有限的，怎么样在有限时间内控制住无限的变更呢？这就必须将客户提前带入项目中，加强客户体验，加强和客户之间的交流。
开发需要分成很多小组，每组负责一个子功能（具体分配可以根据实际情况）
按自上往下的开发原则，首先将项目大体框架完成，再逐一实现里面的子功能。完成一个子功能，进行简单的测试保证功能可以正常运行试用后给客户试用，客户试用过程周期中可能会提出一些新的需求，负责该功能的开发小组进行修改，反复几个周期后，需求基本稳定，测试组再进行详细的测试，这时候就可以编写用例

…………很快第二个子功能就出来了，现在就需要一个简单的集成测试…………然后反反复复，一个完整的系统就出来了。
说起来非常的简单，做的时候必须要加强于客户之间沟通，完完全全的了解客户到底要做成什么样的，再进行严格的需求分析。所以了解需求和需求分析是重中之重。
还有个隐患就是现状，测试人员明显比开发少，可能一个测试需要负责一个开发组，甚至一个人需要负责两个以上小组，这什么就可以有充足的理由招人了~~呵呵

我体验过一个项目的都进行随机测试，没有任何用例，简单模块完全可以应付的过来，复杂的模块根本达不到100%覆盖，而且很累人，最后还是顶着需求变更的风险，加班完成了用例的编写。

事实告诉我们用例不能少。

有空给我投点票~~~~HOHO

[ 本帖最后由 birdcc 于 2009-2-20 16:33 编辑 ]

作者: qinkun26911615 时间: 2009-2-22 22:27
标题: 应该写级别为高的用例
对于需求不断变化的项目，只要大体写出级别为高的用例（项目或产品目标不会变化太大），其他用例根据需求微妙的变化简单记录就可。

作者: xiaodada 时间: 2009-2-23 00:32
反方支持一下．

作者: xiaodada 时间: 2009-2-23 00:33
我也觉得没必要写，楼上有些说的不错．

作者: kukumaru 时间: 2009-2-23 00:38
　测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
　　测试用例（TESt Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
　　测试用例（TESt Case）是将软件测试的行为活动做一个科学化的组织归纳．目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一．

作者: kukumaru 时间: 2009-2-23 00:39
要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。
　　既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

作者: calliopsis 时间: 2009-2-23 10:03
标题: 应该写,但形式可以多样
我认为不管周期多长的项目写测试用例都是必要的,只是形式上可以多样：如果没有硬性要求,可以写得比较简洁，这样既能保证测试的覆盖率（特别是回归测试的时候容易漏测），如果需求变更修改起来也会比较省力。

作者: liyayaliutao 时间: 2009-2-23 11:13
用例是必要的

作者: chengxq 时间: 2009-2-23 18:04
首先，我们必需要清楚，我们为什么要写测试用例，现在项目出现变更，不写测试用例会出现什么问题，就是说，测试用例有什么用处，现在的实际情况，说明现在的测试流程可能出现的问题，或者说现在测试的流程已经不适合现在开发的过程，所以我们可以从过程改进的角度进行分析
改进我们的过程，符合项目开发实际

作者: joanzq 时间: 2009-2-25 11:34
对于项目周期短，需求变更快的项目我想是否可以采用简化测试用例，标注测试关键点的方法来进行，只要测试团队同心协力富有责任心即可。不过在时间允许的情况下我觉得写用例是很重要的

作者: 搂搂兔 时间: 2009-2-25 16:13
标题: 还是写用例的好，
起码还是工作量呢，年底算奖金时可以加点分

作者: 佐伊 时间: 2009-2-25 17:11

原帖由 搂搂兔 于 2009-2-25 16:13 发表
起码还是工作量呢，年底算奖金时可以加点分

我崩溃．．．

作者: 雅丹咔咔 时间: 2009-2-26 15:16

原帖由 sweetxmy 于 2009-2-12 16:10 发表
写需求（或测试用例）是为了更好的确认测试目标和提高团队工作能力

1、很多开发团队认为写不断变化的需求（或测试用例）是浪费时间，何不用这个时间做开发和测试。
但事实是，随着时间的推移，同时因为没有需求 ...

这样一分析，自然写用例更有意义了！

作者: yanjie_4 时间: 2009-2-26 15:26
用例还是要写的!
1.作为测试负责人.必须要把握好项目的进展程度,以便安排好测试工作.即使生命周期为半年,也要参照第一版的需求文档写出用例,这个用例可以不用细化到步骤级,但测试重点要明确.
2.由于项目周期比较长,因此可以让测试人员有足够的时间去消化需求.即使大家担心需求变更,根据经验来说,做项目的时候需求不变才是不正常的.但每次变化只是局部变更,如果客户产生了大规模的变更,只能是pm要说明原因了(需求没有控制好).
3.真正要开始项目的时候,此时再进行细化用例,对于测试人员来说应该是得心应手了,而且可以设计出效率较高的用例.因为我们有了之前的需求理解.
4.用例是用来支撑测试的重要因素,没有用例的支撑,我们的测试只能是狗熊掰梆子了.的确,写用例的时间和精力都很多,但这也是为了更好的测试,为了项目的质量.作为测试人员,担当项目中把握质量最后一关的重要角色,所以一定要严格按照最基本的测试过程.
5.另一方面,也是工作量核算的重要依据.同时也在提醒需求人员,一定要控制好需求,否则发生变更,将会带来一连串的工作量.
6.开始可以安排较少的人员来参与用例的编写.还是那句话,用例还是要写的!

作者: lqc5211314 时间: 2009-2-26 15:47
标题: 实际情况实际分析
根据项目的规模，如果项目规模较大的话，测试用例是必须的，但如果时间较短，测试准备时间和，测试时间可能会有冲突，所以大多这类项目均执行冒烟测试。
我们公司的项目大多都只有一个月甚至更短，测试时间本身就只有2-3天时间，需求时常变动，有些在出厂前都没有明确定义，最主要的是人力不够，如果书写测试用例将造成测试周期加长，造成项目无法正常出厂，项目延期可是很不好的事哦

作者: 默默巫 时间: 2009-2-26 17:15
都讨论起来哦！

作者: atomtiger 时间: 2009-2-26 20:44
起码可以简单写写吧。。。。。列个提纲总是好的。。。

作者: 试验 时间: 2009-2-27 09:29
测试一下！

作者: linda22 时间: 2009-2-27 11:37
标题: 时间紧迫，只能特殊对待
谁也没有质疑测试用例的有效性，可是对于一个有经验的测试人员来说，那么短的时间，可能与项目经理、程序员沟通，测试的时间都不是很充足，花大力气写完了测试用例，可能还没写完，就有需求变动了，而且这变动还是自己不知情的，再改测试用例还是用不适用的测试用例去执行呢？还不如按自己的经验来进行测试，虽然可能会有疏漏，总比来不及执行测试这最后，并且最终要的一步来的好吧。

作者: jessies 时间: 2009-2-27 12:26

原帖由 ahu201 于 2009-2-10 10:21 发表
下面我提出我方观点:
1. 对于需求变动比较频繁,或者软件生命周期比较短的, 我们测试的依据可以适当进行调整,譬如:i, 最新的需求个功能列表. ii, 公司软件规范要求列表. iii, 软件需求变化跟踪列表.
2. 对于需求变动比较频繁,或者软件生命周期比较短的, 我们测试重点不是测试用例编写, 而是如何快速准确的定位客户的最新需求, 在软件生命周期中可开发协调工作,保证最优的实现, 将项目代价降低到最低,避免重复冗余的劳动.

对于ahu201的回答，我有一个疑问，变更后的需求，快速定位了之后，你怎么保证在多个测试人员的团队内，每一个人对这个变更之后的需求都是理解一致的？
或者提一个场景来说，如果用户提出了一个新的需求，项目组做了变更，也修改了功能列表，那么真正执行这部分功能的测试人员是否知道这个变更呢？或者说，他是否已经领会了这个变更的真正意思？他的测试是否真的遵循了变更后的列表？测试负责人要如何衡量如何保证？
测试人员的测试执行是否正确，这个又如何保证？也许他执行的过程和实际需求有出入呢？你又如何去把握？
其实我觉得这个辩题可能没有完全的描述好真正的场景，在软件测试过程中，个人认为，如果测试组是一个小团队的话，那么就需要描述清楚完整的用例场景，但是如何测试人员是熟练的或者说，测试人员就一个或者两个，那么沟通不成问题的情况，可以写比较简单的用例。
但是用例是必要的，简单的功能列表我觉得也是用例的一种，用例不一定非要标准到步骤输入输出，特殊情况下，用例可以简化，当然这个视项目组成员的能力以及项目规模和时间来决定。
对于较复杂的项目，我支持写用例，维护的成本可能比较高。但是如果项目到最后发现最后测试的功能其实是和需求有偏差的，那么这种修改带来的代价可能更加大。

作者: jessies 时间: 2009-2-27 12:30

原帖由 pupu840323 于 2009-2-10 15:17 发表
开门见山的说，我认为不需要写测试用例，但我们需要简化版的功能覆盖点。

三、解决方法
为了解决测试用例的意义所带来的效益，测试用例适用性所带来的缺陷，我认为应该引入功能覆盖点来平衡这两方面因素。
功能覆盖点是对所测试项目功能点的一个简要概括，编写功能覆盖点可以让我们去熟悉业务系统，平且将功能点，关联点等简单罗列，让我们纵观测试的广度和深度。在需求变动情况大的情况下，维护功能覆盖点的成本要远远小于测试用例，他所带来的效用是实效而灵活的。

综上所述，测试用例在需求变动大的项目中，是不需要引入的，而应该引入更为实效的功能覆盖点，辅助测试工作的开展和考察

支付你的解决办法，但是在我们这里，我们可能会使用简化版的测试用例来代替，同你提出的功能覆盖点。

作者: ghf.m 时间: 2009-2-27 12:31
个人觉得主要功能还是需要用例的...并且和原需求一起存档，如果客户改来改去还是觉得原来的功能好的话，也不至于又要卷土重来..

作者: tiannianyong 时间: 2009-2-27 13:37
我觉得测试计划和方案是一定要写的。方案里面写明重点测试内容，以及各主要功能点测试用的方法。
如果多人测试：最好要写测试用例。
如果一个人或者两个人，按照测试方案来直接执行测试就可以了。
目前我是这样来做的，感觉还行。
请指正。。

作者: drwei123 时间: 2009-2-27 13:38
需求经常变,那程序的设计呢??CODE呢??
如果都变了,不更新 TC ,那测试标准有反方怎么来定义呢??
TC 也是一个熟悉需求的过程,只有更新它,很多的细节上的问题都会出现,那样能更好了解需求,了解客户到底是要什么样的一个东西.....
那样才能对开发人员做出来的东西进行一个很好,很全面的 TEST

作者: 七明芝 时间: 2009-2-27 15:10
还是要写的吧，否则如何向老板证明你做了多少事情。只是可以简略些

作者: 圣西罗 时间: 2009-2-27 18:01
个人认为还是有必要写的，但是没有必要全部按部就班的去写，那样对测试人员的心里也是一种疲劳战术，首先可以明确测试重点，根据测试点的要求，找出重点，严格按照测试用例的标准详细写清测试步骤，其他的可以根据实际情况适当安排，根据测试点的需要，最后可以看出测试用例的覆盖程度，而且可以保证项目常用模块的完全覆盖。

作者: nqk 时间: 2009-3-1 22:01

原帖由 birdcc 于 2009-2-20 16:30 发表
需要写，但是要看你怎么写，在什么阶段写

首先按照传统的测试方法：
项目研发周期为半年的小项目，大概需要5人以下小团队花至少一星期去编写测试用例（包括了解需求的时间），根据楼主的说明（经常会遇到 ...

同意！

作者: fengbo 时间: 2009-3-2 14:09
标题: 当然得需写用例
我觉得这个问题必须得认真对待。测试用例作为可衡量的软件测试过程与测试效果和与之相对应的测试工作进展是重要的一个评估手段。测试用例的设计能力直接体现着公司的测试技术力量，所以因为项目周期短，项目变更频繁而对测试用例的设计不加重视。
一个软件项目变更在频繁，也会有其基本的项目架构和主线，而如何对其软件项目主线和架构进行有效的测试用例编写，从而形成测试用例复用以降低软件项目功能的增对测试用例编写的成本。
但现在测试用例复用技术好像许多许多的公司都不重视，我当年就研究的这项技术，但我还是被公司守旧势力给扼杀了。

作者: Eric2515 时间: 2009-3-2 15:03
必须写测试用列,而且要进行需求跟踪...对于人力成本的提高可以找客户收手要钱.控制好客户的需求是解决这个问题的根本..是需求分析人员本身存在调研不足还是客户本身善变..对于不同的情况有不同的解决方法。
客户需求频繁变更,但是软件本身有很多需求是不会变的,测试LEADER可以优先考虑把计划定在这些范围内;比如软件的性能,环境等.

作者: himily 时间: 2009-3-27 20:22
支持写写提纲，写写思路，也就是业界说的测试规程。我在设计一些取值比较易变的测试用例时，就是采用这种方法，把我的测试思路记录下来，写一个大概的提纲，因为是自己测所以只要自己能够看懂就可以了，对于经常做需求变更的项目可以具具体情况而采用这种方案

作者: maxhoo8003 时间: 2010-1-22 09:45
标题: 可笑居然不用测试用例
1、没测试用例怎么通过用户单位或者监理单位的验收过程？
2、测试用例起码要准备两份：一份是自己写的详细的针对系统每个功能点的详细用例一份是简单命了的通过性测试用例给用户和监理验收使用的

作者: yuefang3344 时间: 2010-6-27 09:24
恩恩....

我的MSN jk@tiwens.com

作者: Michael0112 时间: 2011-3-13 10:58
非常有必要做 design test cases。

作者: 春天梅花 时间: 2011-5-5 13:42

作者: songjunster 时间: 2011-5-31 22:26
生命周期只有半年就不该开发！

你说的应该是研发周期半年吧？很长了啊，俺们这边一般一个项目研发周期也就3个月。

作者: yxx8012 时间: 2011-6-26 17:28
一个月,半个月的项目用例也是有必要的.这是个测试设计(测试用例\测试方案等)的过程是必须的.就像开发的代码一样.是你的产出.而且用例必须经过一系列的评审.前期必须输出AT用例.后期完成ST,SDV.项目周期短可以省略SIT,但是如果是半年的项目有充分的时间完成上面一系列的质量动作.

切记,不是为了写用例而用例.而是这是质量保证的必要手段.是检查软件能否正常工作的动作.不然裸奔．这样的项目最后将是一塌糊涂．

作者: 高次有 时间: 2012-3-21 10:45
程经理：18850468120 QQ:2310682411 个人无抵押无担保信用贷款，有工作有信用即可申请，额度1-50万，最快2天放款，老师、医生、公务员、律师及国家事业单位的工作人员，利息低，无手续费，福州五区八县宁德莆田泉州可办理。网址，www.CreditEase.cn详询
2 银行信用贷款，主要针对老师、医生、公务员、律师及国家事业单位上班的工作人员，手续简便，利息5厘到8.3厘。
3 房贷信用贷款，只要你有房子，曾经或现在有房贷，便可申请，额度可做到每月月供的20-28倍不等，4-7天便可下款，利息7厘
4 车贷，若你在福州有房子，信用没有太大问题，可贷20-30万，5-7天可下款。
5 低点**，保证能报销。

资金渠道多样，不论大额还是小额，都可与本人联系

作者: femir 时间: 2012-3-27 11:00
重要功能用例是必须要写的，每次需求变动之后对变化的需求写少部分用例就可以了

作者: aloan 时间: 2019-3-19 14:12

http t点cn/Efk3pEv 线上网址马上观看

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

奖项	获奖名单	奖励	答案连接
最佳话题PK手	Jackc	当当购物卡50元+最佳PK手勋章	39#