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

Jackc

以上是偶以前工作的一些体会，有些怨气在里面（看来还没有磨练到“心平如水”的境界），大家见谅~

CHOUYUNHAT

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

puchonghui

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

lanbiers

需求决定功能

功能取决于测试

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

sssddd

看各种情况，再决定咯

单尾鱼

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

功能取决于测试

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

同意！！

birdcc

需要写，但是要看你怎么写，在什么阶段写

    首先按照传统的测试方法：
    项目研发周期为半年的小项目，大概需要5人以下小团队花至少一星期去编写测试用例（包括了解需求的时间），根据楼主的说明（经常会遇到需求三天一变,两天一变），估计用例刚刚写完，就发现需求完全变了，然后更新用例，至少又要花上两到三天时间（而且还没有算上BA/PM等都更新需求的时间），需求再变~~用例再更新~~~测试人员花费了大量的时间浪费在用例上，也可能是老牛耕地，耕了又耕，毫无进展。而且测试人员编写的用例的质量也会慢慢变低，根本起不到用例的原始作用，反而成为累赘。
   成本又多大，根本没办法估算，收益几乎为0.
   
    对于这种情况我认为有必要先解决项目的经常变更的问题。变更是无限的，项目周期是有限的，怎么样在有限时间内控制住无限的变更呢？这就必须将客户提前带入项目中，加强客户体验，加强和客户之间的交流。
    开发需要分成很多小组，每组负责一个子功能（具体分配可以根据实际情况）
    按自上往下的开发原则，首先将项目大体框架完成，再逐一实现里面的子功能。完成一个子功能，进行简单的测试保证功能可以正常运行试用后给客户试用，客户试用过程周期中可能会提出一些新的需求，负责该功能的开发小组进行修改，反复几个周期后，需求基本稳定，测试组再进行详细的测试，这时候就可以编写用例 …………很快第二个子功能就出来了，现在就需要一个简单的集成测试…………然后反反复复，一个完整的系统就出来了。
    说起来非常的简单，做的时候必须要加强于客户之间沟通，完完全全的了解客户到底要做成什么样的，再进行严格的需求分析。所以了解需求和需求分析是重中之重。
    还有个隐患就是现状，测试人员明显比开发少，可能一个测试需要负责一个开发组，甚至一个人需要负责两个以上小组，这什么就可以有充足的理由招人了~~呵呵


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

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


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

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

qinkun26911615

对于需求不断变化的项目，只要大体写出级别为高的用例（项目或产品目标不会变化太大），其他用例根据需求微妙的变化简单记录就可。

xiaodada

反方支持一下．

xiaodada

我也觉得没必要写，楼上有些说的不错．

kukumaru

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

kukumaru

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

calliopsis

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

liyayaliutao

用例是必要的

chengxq

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

joanzq

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

搂搂兔

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

佐伊

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

我崩溃．．．

雅丹咔咔

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


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

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

yanjie_4

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