生命周期半年的项目需求是否有必要写用例？（2009-2-9 ）获奖名单已公布

默默巫

背景描述:对于稳定客户的项目类测试,经常会遇到需求三天一变,两天一变,由于时间周期不是太长,客户需求经常变动,导致BA/PM等都未能及时更新需求,从而给测试组的需求经常是非最新版本,且测试阶段的需求也经常有小变动,导致用例效果不大甚至失效.(可能是针对需求说明书失效,更多情况是针对实际需求-即系统实现方式失效).

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

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

maclehappy13

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

sweetxmy

写需求（或测试用例）是为了更好的确认测试目标和提高团队工作能力


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

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

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

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

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

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

milklybaby

这种情况在做客户现场项目时候实在是太常见了。

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

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

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

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

jenvee

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

猫猫的拖鞋

有人力就写，没人力何必写。

hushiping2222

有必要写

默默巫

希望大家都讨论起来．

puchonghui

关键并不是需不需要写用例
而是明确自身的目的（你写用例的目的是什么？）
如果真的是变动比较多 日程又比较紧的话
可以列一个check list...

sssddd

看各种情况，再决定咯

单尾鱼

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

功能取决于测试

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

同意！！

joanzq

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

搂搂兔

起码还是工作量呢，年底算奖金时可以加点分

lqc5211314

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

默默巫

都讨论起来哦！

tiannianyong

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

圣西罗

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

nqk

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

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

同意！

fengbo

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

Eric2515

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