请问大家需求在变，测试用例一定要实时更新吗？
我们的一个小项目，本来都定好的，但是后来客户需求变了，然后程序改了，我们的测试用例，测试报告，测试大纲，帮助文档大家连夜加班更新了，结果第二天，客户看了后，需求又变了一点点，程序改了，我们的测试用例，测试报告，测试大纲，帮助文档又得重新更改，气人。。。
最后客户总算满意了，但程序员又把一个地方的文本诓改成了下拉框，我们又得重新抓图，那么多文档又得改，一个小小的项目，把我们要累死了
有时候我也在想，我们等项目完全结束了再彻底更新这些文档，但是又怕时间 来不及等其他未知的因素，我也没有敢这样试过
大家是怎么样对待这样万变的事情呢？有什么好主意吗？ 首先我觉得前期的需求可能做的不足够好,当然原因也是多方面的,这样导致了不少重复的劳动.
需求变了,测试的相关东西也是要改的,但可以把范围缩小点啊.
此外,在编写测试用例的时候,多注意一下设计case的复用性,可能好点.
个人意见,仅供参考sdlkfj2 在项目前期要做好需求分析,多和用户沟通,充分挖掘用户的显性和隐性需求.一旦需求通过了评审,基线后,就要对需求进行配制管理.做好变更控制和需求跟踪.所有变更都必须提交申请,审核通过才能进行.需求变更后,就要做好需求的跟踪,所有关于这个变更需求相关的文档（包括开发的设计文档，和测试的计划，方案、用例文档）、程序代码都要做好修改。
楼主做的项目前期用户对需求提出了多次变更，说明可能前期的需求分析做的不好。还有楼主提到“但程序员又把一个地方的文本诓改成了下拉框”这么一句话，从中可以看出楼主公司对需求的管理做的不好，能让程序员随意的变更。 1.不能想变就变，变化需要经过审核。具体说来就是楼上的需求变更的管理。
2.不能要变就变，经过审核的变化需要有计划的实施。打个比方，三天内发生了三个变化，这三个变化可以在三天后累积提交，这样，相应的三次更新就变成了一次。 嗯，最好把多次的变更集中在一次更新中
需求和用例可以及时更新，帮助文档、报告之类可以再最后发布的时候更新的 看来还是前期工作没有做好
需求评审是一个很重要的过程，应当引起足够重视。 我觉得第一，首先要把前期的工作尽量做好，如尽量与客户进行沟通，挖掘出客户明显的和隐性的需求，使其尽量避免过多的修改；
第二，如果需求变化了，要求被变更的需求通过评审，然后把最需要更改的用例更新下，
其他一些不重要，不是很紧急的文档在最后一次修改；
第三，在这个修改的过程中要注意文档的管理，也就是做好配置管理吧。 测试过程中客户更改需求是在所难免的.因为测试用例是和客户需求息息相关的,为了能够避免测试用例的频繁改动.首先.需要项目经理与客户的深层沟通.使得开发人员在编写详细设计之前就能够把需求定下来.最大程度的避免需求在开发过程中改动.
第二.测试人员的测试用例,可以看其需求改动的大小,而决定您的测试用例是否要跟随改动.一般来说如果您所测试的项目不需要回归测试,那么这个文档改动不改动都是无关重要的(但是作为职业的测试人员不提倡这中做法). 举个简单的例子来说明问题吧，开发人员就像是雕塑家，而需求就像是模特，做一个模特的雕塑作品相当于开发出符合需求的软件。
可以想象，模特如果一直在动的话，很显然，雕塑家是没法完成作品的。
因此，必须找一个折中的办法，比如先为模特拍一张照片，然后按照照片来雕塑，（照片相当于是需求的发布）。由于照片是不会变的，这样，可以有比较大的把握先出一个和照片差不多的作品。在雕塑的过程中，可能会发现有些地方照片上看不到，（说明需求不够完备），模特的姿势不雅，（说明需求需要修改），等等问题，把这些问题汇总一下，再拍一张照片，然后再开始雕塑，周而复始，一次一次的循环，最终得到一个满意的作品。
当然，还有一些具体的情况，雕塑家可以把胳膊腿先单独做好，然后组装，（开发过程模块化），也可以让模特安静下来，面部来张特写（需求的挖掘和细化）等等，但都和流程无关。
照片拍得越多，作品和模特的相似程度就会越好，当然，代价也会非常的大。
照片拍得少，虽然成本最低，但很可能做出一个和模特差距非常大的作品来。
而不同的雕塑家要根据自己的情况，在不拍片和拍无数张照片这两个极端中取得一个自己合适的点，可以同时满足成本和质量的要求。
开发的过程其实也是一样的。
回到楼主的问题。
需求一直在变，但设计人员要通过需求基线化和需求发布的方法，把变的东西变为不变的东西。
按照楼主的描述，需求发生了3次变化，而实际的的操作，是按照3次发布来处理的（虽然不正规，但实际的结果等同于发布），如果想省事的话，就要想办法看看能不能把发布的次数减下来。方法就像楼上提到的，要有审核，要有计划。
另外，也可以通过提高设计水平，尽量把变动的内容控制在最小的范围内。
小的项目不规范关系可能不大，但越大的项目，对于流程的规范化要求就越高。 如果是外包公司，需求规格说明书都是客户给的，到最后客户要求变更，这种情况如何处理呢？ 这个情况是那种很典型的反面教材 跟着改呗！sdlkfj9 我个人认为：需求的问题不可能由测试来解决，如果需求变了，用例肯定有变化这个是毫无疑问的！但是我们可以在做用例的时候采用取巧的办法，我们可以将需求稳定的部分先写需求并测试通过，至于需求是否稳定，必须和客户沟通！如果实在无法避免，那么情详细记录需求变化的量，以及你们为需求变化所进行的用例修改量，这样保证测试人员了基本利益！
页:
[1]
