现在在测试行业，对测试人员来讲，最受困扰的问题之一就是测试的设计工作都做完了，结果需求又发生了变化，原来做的很多工作不得不重新开展，一方面测试的进度受到了影响，另一方面，也让测试人员身心疲惫。我们是否分析过：这种现象产生的原因是什么？面对这样的风险，我们采取怎样的策略来应对，从而最好完成测试任务？欢迎大家讨论交流！

感谢会员bzfyhfyh提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

非常感谢各位会员积极参与，截止至5月16日17：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	风动	当当购物卡50元	32#
二等奖	huxb_dowant	300论坛积分	2#
	shhuangfy		8#
三等奖	tengmy	100论坛积分	7#
	judy2sa		12#
	markbullet		14#

这个问题要根据需求变更的严重程度来决定测试计划的变更：
1、如果原来的需求发生了根本性变化，则测试计划需要重新制定，与原需求对应的开发及测试工作就被全部推翻，一切从零开始。
2、如果需求只是少许变化，则修改相应功能的测试用例，测试计划即可；当然这种情况如果可以通过加班解决就不要修改版本发布计划了，给客户留个好印象，但要同时告诉客户需求变化的影响，使其对提出的需求有一定的责任感。
    需求变更在软件测试过程中是比较多的，产生该问题的原因主要是需求人员不能很好控制需求导致的，必须强化需求人员的技术水平，使其有能力引导客户向现有功能靠拢，不会发生修改的功能比开发一个同样的功能还要耗时的情况。
    最后我想说，在IT行业“客户不会永远都是对的”，用自己的技术为客户做出高效完美的软件才是王道。

本人入行不久，观点有何异议请各位大虾指证，谢谢！
总结如下：
     1.查看代码，或询问开发人员，需求变更后都该了什么地方，从而分析出它的关联模块（即相互间有调用关系的），进行重点验证测试，同时根据项目时间对非关联模块进行有代表性的适当回归。
     2.限定开发人员提交测试版本的周期（比如一个礼拜）。意思是说，不要一有修改，就提交给测试一个新版本，使测试人员做过多的重复工作。
     3.条件允许的话，可以自动化工具录制一些自动话测试脚本，做回归测试。

需求分析是软件测试首先要进行的任务.需求的变更可能只是少量变化或有一部分的变化,不可能将原本的需求全部否决.
      1.首先分析哪一部分需求发生了变化,对原本缺少的需求分析将其加入到已完成的测试计划中.
   2.其次检查已完成的测试计划中的需求分析对于新的需求是否冲突?删除有冲突的测试用例.

我的一点个人见解请多指教：
要对变更进行评审，如果变更被接受，更新需求。明确当前的工作进度，要建立需求基线，确定变更所影响的范围，对需求进行跟踪，能够更好的控制变更，有利于测试质量的保证。

其实无论在多大的公司，需求变更不发生是不可能的.
关键是我们如何应对这种变更，
以及整体的流程是如何的，我想各个公司处理问题的方式不一样
理想化的来讲,是可以有需求基线的，然后每一步变更都可以记录，然后都可以更改在测试计划中，
让一切变化有据可依,但是事实上很少有公司能做到这样。
个人认为一般公司的解决方法。.是改变以下原由的流程，测试计划的工作可以跳出细节,只描述大面的东西。
然后十分细的测试用例等待开发过程中在同步编写。
总的用例在设计阶段编写,需求不发生本质性的变更,不会起到太大影响.
大型的变更,要做记录了，将来拖进度问题，也有依据了

关于这种风险,真正要治理,需求阶段，大公司就要多评审,小公司就要勤开会确定和交流需求了。
必要的时候还是要责任到人，避免和稀泥的现象。

这是一个常见的令人头疼的问题。
fw:
如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

好的代码注释和好的文档有助于开发人员作出相应的改变。

只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

在项目的时间表中应当留出余量，以应付可能出现的变更。

尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

在设计自动测试剧本时，试图使其有一些灵活性。

在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

对变更进行适当的风险分析，以减少回归测试的要求。

在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。
PS
需求变更测试人员应怎样进行有效的处理
每个公司，甚至每个项目都有可能有不同的方式来处理这个问题。
对于测试人员来说，最为重要的一点其实就是心理的适度调整。
诚然，需求的变更导致自己的很多工作都成了无用功，很多东西要从头做起。
但是一定不要抱怨，因为那样解决不了问题，事实就是事实。已经无法更改。需求方开发方任何一个都希望项目从立项一开始就按部就班的做下去，不会有任何的变化。没有人喜欢需求的变化，但是计划总是没有变化快的。所以首先要调整的就是心态。要有积极地心态，全新的去面对新的需求。分析，设计，一切重来。

需求变更后如何做好测试?

1：客户提出的要变更的需求，要经过需求变更申请表经公司相关人员确定后，一定要把它记录下来，归为需求变更文档中一部分，变更文档中应该包括此变更的原因等相关信息
2：测试人员根据变更的需求分析此变更产生的影响，当然可以借助项目组成员的力量一起分析，理清变更对当前系统有哪些实质性的影响，这也是在测试时要重点测试的功能点
3：根据分析的结果更改相应的测试计划及用例，在编码没有完成前，用例不用写的很全很细，全与细的用例可待程序出来后再完善，测试前的用例很多的时候只是做为功能点集合，来指导测试，为测试提供方向等用处
另外要说的是：其实有些变更并非是有效的，我们要评审变更就是要考核变更的必要性，这样也能避免多重变更。

我们公司就经常发生这种事情，项目立项时大家高高兴兴开会，立项了，大致说一下需要那些功能。 客户和我们公司都没有需求文档，或者说没有详细的需求文档。导致在开发和测试都不停的更改需求，特别累，尤其是开发人员！所以说在立项时一定要有详细的需求文档，并且开发人员和测试人员都要对需求文档进行Comment，把不合理的或者不可能做到的功能先提出来，并且在更改时都要有文档或者Mail，避免纠纷！个人经验，一般前期有文档的，开发过程中更改的地方比较小。如果前期没有文档，那就是想怎么改怎么改，完全没谱！
如果需求变更太大，Root Cause应该是需求人员没有管理好需求。所以一定要公司高层重视需求管理的问题！否则测试和开发只能被动的被客户牵着鼻子走！从某种意义上讲，测试比较测试管理和问题预防（FMEA），所以在需求管理中应该提前参与！

需求的变更是每个项目都不可避免的问题.那么如何才能适应需求的变更呢.

我觉得要从以下几个方面入手:
1.需求文档的编写和检查.
需求变更也有大有小,需求分析做得越好,需求文档写得越好,最后发生的需求变更就越少,所以测试人员介入项目的时间要早,从项目立项开始就要跟进,对需求文档和设计文档进行检查,尽量从一开始就将需求做好.
2.建立风险控制机制.
要提前考虑到项目会遇到的各种风险,预先准备好应对机制,最简单的做法是在做项目开发计划时,总时间上要留下一定的缓冲时间,防止项目到了后期才出现需求变更,而预定时间已到,最后不得不延迟项目的开发期限.
3.进行需求变更审核.
当客户提出需求变更时,要进行审核,分析是否有变更的需要,还有变更的成本和收益,来决定是否变更.当确定后,要添加到需求变更文档里,并及时通知开发和测试人员.
4.及时了解需求的变更
当需求发生变更时,测试人员要及时获取需求变更的内容和影响,并在原测试用例的基础上进行修改.(当然如果改动太大,不能重用之前的测试用例时就得尽快重新编写了.)

先占前排板凳。

GOD,这个问题相信是每个项目都可能遇到的，对于测试人员来说，工作非常被动，我觉得应该从三方面去解决：
1.公司的项目规范：这个是至关重要的，如果公司有好的项目管理规范，那么所说的这一切都不是问题，大家完全可以按照制定好的制度来按部就班。比如会有要求产生需求变更说明书，那么测试人员在拿到这个文档的时候就可以顺利开展对计划的修改、对用例的补充或调整。
2.项目经理的管理风格：项目经理的做事风格也很重要，比如项目组例会是否有进行？需求变更后是否有通知到测试人员并说明清楚？需求沟通会议是否通知测试人员参与，及时更新的文档是否发送给每位项目组成员，这些都决定了需求变更后项目组成员是否第一时间得到通知并清楚变更了哪些需求，变动有多大，影响有多大。
3.测试人员主动性：如果一个做事不积极的，整天等着接通知才动一动的测试人员，可想而知，做事情肯定是非常被动的，总是会在最后才得到消息，有可能在你得到消息的时候已经太晚并且来不及对计划或者用例来进行调整了，于是急匆匆地测试一番，最后用例并不能满足最新的需求，只有结束后进行补充，这样的用例是没有什么价值可言。但如果测试人员能够主动找项目经理，或者开发人员保持良好的沟通，并提出适当的要求让他们提供需求变更相关的说明文档和修改后的项目计划，在拿到这些东西后就可以及时对测试计划及用例进行调整，保持最新的状态，让后续的工作来得更加轻松，问大家一句，你是哪一种呢？

以上三点是在需求已经发生变化的情况下三方面的因素，另外一个项目管理方面很重要的便是对客户需求的控制，首先就要清楚客户的目标，并且大家要保持目标一致，并且项目经理要管理好客户，这个就是另外的话题了--项目管理的艺术。

嗯，大家说的都非常棒，说到了怎么做，也说到了心态的问题，
我也非常赞同，
的确在遇到需求变更，每个人都会感觉头大，但我们却必须做。
首先就要调整好自己的心态，因为这是工作，我们的一切生活资本及公司的运转都要靠他们的腰包，呵呵……
接着我们要对用户提出的需求与用户接洽，如果改动不大，我们大可在这个项目中完成，如果这个需求的改动非常大，我们就需要让用户明白他的这个改动会造成很大的资源浪费，而且项目的进度也会受到很大影响，建议他在下个版本中再进行变更。当然很多时候并不能如我们的意愿，通常最终的结果还是要改，而且改动似乎也非常大……
那么我们就需要从需求分析中评审这个改动会造成已有功能的哪些改动？跟哪些模块相关联？并做好需求变更的记录。
搞清楚这些之后，测试经理就需要重新制定计划，并修改添加相应的测试用例。
其实这也只是我自己的一点浅见，大家见笑了，如果我所的不准确，也请告诉我，谢谢!!!!

1 和客户进行沟通，尽量减小修改的部分，毕竟客户的要求不一定全是合理的，科学的；
2 确认变更的范围及模块大小，在整个系统里的比重，确认是否对软件的交付日期造成影响，如果影响较大，必须和项目经理和客户重新规划项目进度和交付时间；
3 对已有的测试需求分析，测试方案和用例进行修改；
4 每一次的需求变更必须有文档，客户方，开发方，测试方（三方外包）签字等，不可是口头命令等。

[ 本帖最后由 markbullet 于 2008-5-15 15:08 编辑 ]

头痛的问题

需求变更是项目中少不了的问题，而测试的一些计划、设计变更往往是属于被动变更，除了对一些设计、任务的被动变更的同时，我觉得另一方面要从需求跟踪矩阵中得以体现，在版本控制中发生变更前应打相应标签，个人认为通过需求跟踪矩阵是一个很好的监控跟踪的办法

沟通,规范,改...

发生需求变更，即使与客户商议也无济于事，因为这本身就是他们提出来的，其结果就是一个字：马上改。就如前面一位大侠所说，我们是要的是他们腰包里的银子。这种情况下什么发牢骚、抱怨都是一种没用的表现（既起不到任何作用，又会让领导觉得你没用）。

个人认为，如果发生这样的事情，首先做好新需要的跟踪，关注哪些地方发生了变化，把受影响的部分都列举出来，然后根据变化后的需求重新进行测试的设计。至于具体怎么样做，我就不说了。

进度么重新制定呀，来不及么就只好加班了...

首先关于需求变更产生的原因:1,由于最初项目开始的需求分析人员并没有把握准用户的需求导致后期的需求变更,2,由于当时无法估计是否能用最简单的适合的代码来实现用户的需求,导致最后实现需求的时候用了很多冗余的,结构复杂的程序,此时客户可能要求修改此需求.3,由于客户对于当初的需求并不满意,或者需要增加新的需求..

风险控制是一个很重要的环节....公司都应该重视起来..

应对措施:1,对于需求分析人员需要多和用户,项目组开发人员,.多多交流以及沟通,能够在技术上保证需求的饿实现,同时应该最大程度上去挖掘用户的隐式和显式需求即用户的实际需求.2 对于需求修改 即在原来的需求规格上进行几项功能的修改,此时测试可以采用自动化的回归测试来节省时间和资源..3 对于增加功能,则应该采取相应的回归策略,如完全覆盖,选择性覆盖等方法...视项目组工作进度而定...

大概就是这样一个思想...@@ 个人愚见~~呵呵