其次,将需求基线化, 不能随意更改, 要有一个严格的管理制度或者管理流程. 如果提交修改, 需要从各个方面进行考虑,成本,能力,时间,需求重要程度等.
再次,就是多从自身找原因, 把每次的修改都记录下来, 为以后需求分析有一个参考. 经验还是最重要的.
(不要抱怨用户没有把需求提出来,因为他们是不懂技术的.还是要在自身找一些原因,才能找到一些实质性的东西) 做的什么项目？网站？应用软件？手机软件？ 有多少时间？一天？一周？多少人？3？5？10？资源如何？通过标准是什么？ 针对出现需求变更问题，我觉得不单单是测试的问题。包括和整个软件开发周期都有关系。
首先，明确这个需求是什么情况导致更改，例如：是否需求人员理解有偏差；是否政策的要求；
用户的不确定因素等等原因。
然后呢，我想项目经理（公司领导）应该会和用户确定好需求变更之后，整个项目上线的时间节点吧。
这个时候，测试人员就根据重新制定的项目计划，制定测试计划，来安排测试投入的时间资源和人力资源。
运用适合这个需求的测试策略（根据测试人员的技术和经验），在规定的时间完成这个需求的测试。 看需求变更程度来定方案。。小变动就鄙视定需求的家伙。大变动就暴K。只有心情愉快了才能安心的工作。 要是对方是个武林高手,或者象某妞一样喜欢穿黑色运动袜咋办呢... 用需求跟踪矩阵表啊，呵呵，我就记得这个，商老师讲的。 个人觉得，测试人员一定要对需求进行很好的评审，在设计用例时，就是对需求进行逆向思维，深度考虑的时候，有任何大小异议，一定要及时提出，可避免测试人员后期工作的有效，不会白白做。
如果是真正需求的变更和添加，那不是我们可把控的范围，只能把需求稳定性问题提交给上一级，督促需求开发人员的尽量把需求一次性做全。
有需求就一定会变的，只是我们各方面保证需求变的少，相对稳定。 培养自己压抑心情下工作的能力。。 哎呀，没这方面的经验 1、需求变更是任何一个IT项目都必须要面对的问题。所有，在项目开发计划中就要预留和界定变更的比例；
2、构建需求变更流程，讲需求变更纳入一个理性的、可控的、经过评审的过程中；最大限度降低变更的风险；
3、需求是测试的依据，需求的变更，必然引起测试计划的同步变更，直接的影响是测试需求的变更；
4、测试需求和系统需求一样，同样需要做变更控制；
典型的测试需求的变更过程的例子，当一个营业系统上线后，在运维阶段，不断有新需求要上线，则需要对新需求进行测试。这一类的变更可以通过版本的控制来管理。比如，新提出的某一批需求需要在一周后上线，则在和客户沟通的过程中，开发经理需要对需求进行筛选，预留出足够的开发与测试时间。也可利用需求重要级别排序，优先解决客户最关注的最急迫的需求变更。
当然，以上情形需要不断的沟通，客户、开发、测试三者达成共识，有共同的质量目标，则需求变更就不是一个难题。
5、很多情况下，客户没有对系统的清晰认识，开发团队也没有对需求变更的深入分析，则测试需求的变更会陷入一滩泥沼，测试人员会和开发人员一起疲于奔命，但最终的效果不见得很好。
6、个人认为，有了良好的变更控制，需求变更后的软件测试任务，基本等同于做一个新的测试计划；
对于测试团队来说，变更并不可怕，测试既是变更的有效质量控制手段。对于变更后的需求，要利用已熟悉的业务，对需求做测试需求的分析，主要包括两部分的内容：
1）变更的需求部分，如果变更部分同时牵扯到其他的变更，则需要分析2）条；
2）变更的需求所引起的其他需求的变更部分；所有有关联的对象、数据库表、模块组建以及函数等等；
3）变更的深度和广度不同，觉得了要回归范围的不同；觉得了测试优先级的不同
有效的变更控制 加上明确的变更范围的分析，测试优先级的确定，应该可以较好地安排测试任务。
*还有一点项目的经验，如果 变更没有预留合理的测试时间，要去和开发、客户方一起沟通，要说明变更没有足够测试带来的风险；坚持你的专业测试精神，本着为项目着想的出发点。至少会赢得尊重，然后会得到重视。：）
不要每次都默默忍受变更的痛苦，这样只能是恶性循环！
个人见解
我现在也是常为需要变更感觉头疼。1、需求变更后，首先要向需求人员及开发人员了解，为什么需求要做变更，了解客户真正的需求。
2、其次，向开发人员了解本次需求变更，都改却了哪些模块。会影响到哪些模块。
3、询问开发进度
4、整理测试计划及测试用例，确认哪些模块应该重点测试。
5、展开下一步的测试工作。并确定测试时间。
6、通过本次需求变更，测试人员要总结经验，尽量站在客户的角度进行测试。在客户没有发现不能满足需求时，测试人员先提出来。当然，需求人员及开发人员也要从中吸取教训。
我相信，如果每一次都能从需求变更中吸取教训，相信以后开发及测试出来的软件质量会更好的。 LS各位都说了很多，包括如何防止或减小需求变更，如何跟踪需求变更等。
不过我觉得提这个问题的人应该更关心的是如何在变更后能如期并且完满的完成工作吧。
LS很多人都提到了需求人员，但若需求并非本公司人提供的呢？而是由客户提供的呢？这个时候，是不是除了review外没有办法去控制需求人员该如何如何呢？毕竟，人家是给钱的主。
所以，撇开测试无法控制的部分，从本身来讲，我觉得做如下工作可以适当减少需求变更后的工作量
1. review，这是最重要的，有可能会减少很多不必要的工作。
2. 经过review后若觉得会耗费很多工作量，请先与PM交流沟通，说清楚工作量，不要最后一个人自己默默的加班而无人知晓。
3. 若变更的需求影响到已经开发的部分，请与开发先交流，弄明白要改哪部分，对现有的部分是否有影响，以此来决定要增加的case的checkpoint和数量
4. 诚如上面某位说的，测试要敏感一些，不要只会关注手中分配到的任务，多留心一下，也许你就能早点获知需求变化的“苗头”，而获取更多时间。 我想这个问题可以从两方面来准备, 一个是事前还有就是事后了:)
事前
1. 最初项目开始需求分析的时候就要详细分解需求, 对客户提出的需求经过分析, 用户有时的想法也许在效果做出来的时候会感到不满意, 既而提出改动. 所以我们一开始就考虑用户的需求是否合理, 因为他们对技术不是太了解. 特别是服务类, 类似保险, 证券项目, 客户后面还有客户.这是我们不妨站在真正用户的立场和客户进行沟通, 做出一个相对合理的需求
2. 最初的时候就考虑到需求会有变动的可能, 相对类来讲做产品的可能这方面问题会少点, 服务类遇到的会多点, 因此要有相应的方案来处理
两手都硬, 就不怕啦 拿到新的需求变更的时候，首先要看需求变动的幅度。
1.需求变动不大
a. review 先前的case，找出必须执行的case；
b. 编写新的符合需求的case，当然也要根据项目的进度量力而为。
2.需求变更较大
a. 尽量跟客户争取多一点的时间
b. 跟PM 开发 一起讨论，决定那些地方要改，如何改。最好再得出结论后，能给客户一个review，避免会有进一步的变更带来的不便。
c. 根据schedule，添加或修改case
个人认为还有很重要的一点，就是在测试需求变更的时候，一定要有好的心态。不要不耐烦或者烦躁，尽管枯燥或很麻烦。
总之态度正确，心态良好是能做好工作的前提吧.:) 强烈响应我们项目中的QCers要求，来到51testing上，看帖回帖。
关于这个帖子的标题
从一个developer的角度来说
大家的交流，非常重要。特别是对于需求中的东西，经过彼此的讨论，可能会发现自己理解不当的地方，或者说有了更好的idea。 发表一下个人愚见（名次怎么17点前就出来了。。自己给自己一个鼓励奖了，嘿嘿）：
首先，对于客户更改需求这种情况，应该说在一个项目进行过程中是难以避免的（就像这次四川地震。。。在这里默哀一个，愿活着的能坚强生活下去），我们能做到的就是如何尽量少的控制这种情况的发生，我想这主要就是看与客户的沟通是否深入，有无真正的理解客户的需求。在项目前期需求确认阶段，务必应该与客户深入研究项目的各个方面，开发这边有需求不明确的要及时提出。对于所有的需求，最好都能文档化，这样对之后项目的推进是很有帮助的，如果有人员变动，后来者也能根据文档很快熟悉了解这个项目。
对于已经发生这种情况，测试人员如何应对的话，测试方面，还是应该可以先和开发交流一下，具体改动了哪些模块的代码，模块间有联系的是哪些模块，接下来根据这些有影响的模块来测试相对应的功能，整个系统的话可以进行简单冒烟测试即可，如觉得不够保险，加入一些简单测试点也可。另外，需求更改了文档上面也应该及时更新，最好也都能注明下哪个issue导致了这次的需求变更，做到文档保持最新的。
就这么说一下，再次鼓励自己一下，嘿嘿，第一次写这么多，冒着可能误导人的风险，嘿嘿！ 呵呵支持一下
页:
1
[2]
