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

birdcc

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

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


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

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


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

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