需求频繁变动中，如何进行用例维护及测试
小弟所在公司，用例都按照老需求完成，产品已经提交测试，但经常出现后期需求的变动，导致原来的用例很多都不适用，浪费了很多测试时间，各位碰到这样的问题如何进行处理及沟通的？而且最郁闷的在于辛苦写出来的用例可能用一次就浪费掉，也导致后期用例维护非常繁琐
恳请各位达人意见及先进的用例管理理念。。。 要随着需求的改变去改用例的，公司里都是这样的。像一些常用的用例，例如像增、删、改、查你可以做成类似的模板，用的时候小改一下就OK了。可以减少很多的时间 看来各公司都会出现需求经常变动的情况？那前期想的用例不是都浪费掉了。。。 我不太清楚你们公司测试用例的流程是什么，需求变更，那是很正常的事情，我们公司一个项目都要快纳期了
还在变，但是客户变，我们需要完善什么
我们公司一般都是根据客户和我们确定的需求规格说明书或者说是详细设计书，开发人员负责编码，测试人员负责写测试用例，先写出测试观点，就是针对每个机能或功能在写测试case，这样可以保证客户修改了哪部分，我直接对应
还有客户需求的变更，这些又没有相应的统计，我们的工作怎么能叫没有用呢，对这部分工作量的统计，变更的纪录，这些量化的东西都必须纪录和保留，否则客户哪天问你为什么要延期，为什么要增加成本怎么办？
总之，我们的过程要完善，具体探讨，可短消息联系 我觉得需求变动频繁会导致成本大增，还是需要一定的手段去控制需求变更的。
记得什么培训里说的需求工作一方面要帮助用户在前期想到他们还没有提出来的需求，把后期的变动缩到最小；另一方面也要引导说服用户去向着我们系统实现的方向上去使用，或者有时要增加一些规范流程类的工作，让需求变更不那么“容易”，自然而然会减少一些需求变更。 我们公司现在是自己研发产品并提交测试，所以需求变动很多，也没有固定的模板用例，导致现在习惯性加班。。一直苦于没有合适的方式来减少这种情况。 汇总需求信息，根据需求来写用例。这样变需求即可变用例，不会漏掉测试点。:) 原帖由 superlm 于 2008-12-23 11:46 发表 http://bbs.51testing.com/images/common/back.gif
小弟所在公司，用例都按照老需求完成，产品已经提交测试，但经常出现后期需求的变动，导致原来的用例很多都不适用，浪费了很多测试时间，各位碰到这样的问题如何进行处理及沟通的？
而且最郁闷的在于辛苦写出来的 ...
迅速的反應及敏捷的響應 需求跟踪矩阵 我公司的需求也是经常变动,而且项目管理上也十分的混乱,导致现在通常是先测试,再补测试用例.虽然我已做了很大努力,规范这方面,但是领导的推行力度不大,以至于现在很多测试用例没有完善!郁闷! 对需求很不稳定的模块，不设计详细的用例，只要让自己看得懂就行，甚至就只写个记号；在测试用例不可继承的情况下，选择花大量时间写下所谓高质量的测试用例是没有意义的，因为除了你以外，可能没有第二个人再去用它，测试用例就不需要写得很细，让大家都明白，只需要写得让自己懂就行了。
在测试用例会得到多次复用的情况下，应该详细设计，这样可以缩短其它人进入测试的时间；短时间来看设计这样的用例可能是耗费了时间，长时间来看，它实际上是节约了测试成本。 LZ 参考下这里
http://bbs.51testing.com/thread-107290-1-2.html
烦恼呀
烦恼呀测试用例的维护真的蛮烦恼的
页:
[1]
