51Testing软件测试论坛

标题: 如何最好完成对需求变更后的软件测试任务?（08-05-12）（获奖名单已公布） [打印本页]

作者: 51testing 时间: 2008-5-12 12:28
标题: 如何最好完成对需求变更后的软件测试任务?（08-05-12）（获奖名单已公布）
现在在测试行业，对测试人员来讲，最受困扰的问题之一就是测试的设计工作都做完了，结果需求又发生了变化，原来做的很多工作不得不重新开展，一方面测试的进度受到了影响，另一方面，也让测试人员身心疲惫。我们是否分析过：这种现象产生的原因是什么？面对这样的风险，我们采取怎样的策略来应对，从而最好完成测试任务？欢迎大家讨论交流！

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

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

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

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

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

作者: hanchangyan 时间: 2008-5-12 21:26
标题: 如何处理需求变更?
需求分析是软件测试首先要进行的任务.需求的变更可能只是少量变化或有一部分的变化,不可能将原本的需求全部否决.
1.首先分析哪一部分需求发生了变化,对原本缺少的需求分析将其加入到已完成的测试计划中.
2.其次检查已完成的测试计划中的需求分析对于新的需求是否冲突?删除有冲突的测试用例.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者: shhuangfy 时间: 2008-5-13 10:50
需求变更后如何做好测试?

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

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

作者: wangjcltj 时间: 2008-5-13 14:19
需求的变更是每个项目都不可避免的问题.那么如何才能适应需求的变更呢.

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

作者: 忘记了 时间: 2008-5-13 16:01
先占前排板凳。

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

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

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

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

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

作者: liuh3218 时间: 2008-5-15 19:06
头痛的问题

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

作者: rayblue 时间: 2008-5-16 09:43
沟通,规范,改...

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

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

作者: rayblue 时间: 2008-5-16 09:45
进度么重新制定呀，来不及么就只好加班了...

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

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

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

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

作者: dzhot 时间: 2008-5-16 09:53

俺也头痛

作者: 风吹我走 时间: 2008-5-16 10:01
首先,我们就要在需求分析阶段就要重视, 将用户的需求挖掘出来, 显式需求,隐式需求等. (有很多需求是需要需求分析阶段挖掘出来, 而不是抱怨用户没有提出来,因为用户是外行,他们只是要用软件, 而不是设计软件)
其次,将需求基线化, 不能随意更改, 要有一个严格的管理制度或者管理流程. 如果提交修改, 需要从各个方面进行考虑,成本,能力,时间,需求重要程度等.
再次,就是多从自身找原因, 把每次的修改都记录下来, 为以后需求分析有一个参考. 经验还是最重要的.

(不要抱怨用户没有把需求提出来,因为他们是不懂技术的.还是要在自身找一些原因,才能找到一些实质性的东西)

作者: bhzxqq 时间: 2008-5-16 10:09
做的什么项目？网站？应用软件？手机软件？有多少时间？一天？一周？多少人？3？5？10？资源如何？通过标准是什么？

作者: guanweirong 时间: 2008-5-16 10:12
针对出现需求变更问题，我觉得不单单是测试的问题。包括和整个软件开发周期都有关系。
首先，明确这个需求是什么情况导致更改，例如：是否需求人员理解有偏差；是否政策的要求；
用户的不确定因素等等原因。
然后呢，我想项目经理（公司领导）应该会和用户确定好需求变更之后，整个项目上线的时间节点吧。
这个时候，测试人员就根据重新制定的项目计划，制定测试计划，来安排测试投入的时间资源和人力资源。
运用适合这个需求的测试策略（根据测试人员的技术和经验），在规定的时间完成这个需求的测试。

作者: call888 时间: 2008-5-16 10:44
看需求变更程度来定方案。。小变动就鄙视定需求的家伙。大变动就暴K。只有心情愉快了才能安心的工作。

作者: rayblue 时间: 2008-5-16 11:00
要是对方是个武林高手,或者象某妞一样喜欢穿黑色运动袜咋办呢...

作者: smyz725 时间: 2008-5-16 11:00
用需求跟踪矩阵表啊，呵呵，我就记得这个，商老师讲的。

作者: 小月三木 时间: 2008-5-16 11:07
个人觉得，测试人员一定要对需求进行很好的评审，在设计用例时，就是对需求进行逆向思维，深度考虑的时候，有任何大小异议，一定要及时提出，可避免测试人员后期工作的有效，不会白白做。

如果是真正需求的变更和添加，那不是我们可把控的范围，只能把需求稳定性问题提交给上一级，督促需求开发人员的尽量把需求一次性做全。

有需求就一定会变的，只是我们各方面保证需求变的少，相对稳定。

作者: call888 时间: 2008-5-16 11:10
培养自己压抑心情下工作的能力。。

作者: rting 时间: 2008-5-16 11:18
哎呀，没这方面的经验

作者: xxn_xxn 时间: 2008-5-16 11:45
1、需求变更是任何一个IT项目都必须要面对的问题。所有，在项目开发计划中就要预留和界定变更的比例；
2、构建需求变更流程，讲需求变更纳入一个理性的、可控的、经过评审的过程中；最大限度降低变更的风险；
3、需求是测试的依据，需求的变更，必然引起测试计划的同步变更，直接的影响是测试需求的变更；
4、测试需求和系统需求一样，同样需要做变更控制；
典型的测试需求的变更过程的例子，当一个营业系统上线后，在运维阶段，不断有新需求要上线，则需要对新需求进行测试。这一类的变更可以通过版本的控制来管理。比如，新提出的某一批需求需要在一周后上线，则在和客户沟通的过程中，开发经理需要对需求进行筛选，预留出足够的开发与测试时间。也可利用需求重要级别排序，优先解决客户最关注的最急迫的需求变更。
当然，以上情形需要不断的沟通，客户、开发、测试三者达成共识，有共同的质量目标，则需求变更就不是一个难题。
5、很多情况下，客户没有对系统的清晰认识，开发团队也没有对需求变更的深入分析，则测试需求的变更会陷入一滩泥沼，测试人员会和开发人员一起疲于奔命，但最终的效果不见得很好。
6、个人认为，有了良好的变更控制，需求变更后的软件测试任务，基本等同于做一个新的测试计划；
对于测试团队来说，变更并不可怕，测试既是变更的有效质量控制手段。对于变更后的需求，要利用已熟悉的业务，对需求做测试需求的分析，主要包括两部分的内容：
1）变更的需求部分，如果变更部分同时牵扯到其他的变更，则需要分析2）条；
2）变更的需求所引起的其他需求的变更部分；所有有关联的对象、数据库表、模块组建以及函数等等；
3）变更的深度和广度不同，觉得了要回归范围的不同；觉得了测试优先级的不同

有效的变更控制加上明确的变更范围的分析，测试优先级的确定，应该可以较好地安排测试任务。

*还有一点项目的经验，如果变更没有预留合理的测试时间，要去和开发、客户方一起沟通，要说明变更没有足够测试带来的风险；坚持你的专业测试精神，本着为项目着想的出发点。至少会赢得尊重，然后会得到重视。：）
不要每次都默默忍受变更的痛苦，这样只能是恶性循环！

作者: 风动 时间: 2008-5-16 13:39
标题: 个人见解
我现在也是常为需要变更感觉头疼。
1、需求变更后，首先要向需求人员及开发人员了解，为什么需求要做变更，了解客户真正的需求。
2、其次，向开发人员了解本次需求变更，都改却了哪些模块。会影响到哪些模块。
3、询问开发进度
4、整理测试计划及测试用例，确认哪些模块应该重点测试。
5、展开下一步的测试工作。并确定测试时间。
6、通过本次需求变更，测试人员要总结经验，尽量站在客户的角度进行测试。在客户没有发现不能满足需求时，测试人员先提出来。当然，需求人员及开发人员也要从中吸取教训。

我相信，如果每一次都能从需求变更中吸取教训，相信以后开发及测试出来的软件质量会更好的。

作者: morpar82 时间: 2008-5-16 14:09
LS各位都说了很多，包括如何防止或减小需求变更，如何跟踪需求变更等。
不过我觉得提这个问题的人应该更关心的是如何在变更后能如期并且完满的完成工作吧。

LS很多人都提到了需求人员，但若需求并非本公司人提供的呢？而是由客户提供的呢？这个时候，是不是除了review外没有办法去控制需求人员该如何如何呢？毕竟，人家是给钱的主。
所以，撇开测试无法控制的部分，从本身来讲，我觉得做如下工作可以适当减少需求变更后的工作量
1. review，这是最重要的，有可能会减少很多不必要的工作。
2. 经过review后若觉得会耗费很多工作量，请先与PM交流沟通，说清楚工作量，不要最后一个人自己默默的加班而无人知晓。
3. 若变更的需求影响到已经开发的部分，请与开发先交流，弄明白要改哪部分，对现有的部分是否有影响，以此来决定要增加的case的checkpoint和数量
4. 诚如上面某位说的，测试要敏感一些，不要只会关注手中分配到的任务，多留心一下，也许你就能早点获知需求变化的“苗头”，而获取更多时间。

作者: lhd85 时间: 2008-5-16 15:57
我想这个问题可以从两方面来准备, 一个是事前还有就是事后了

事前
1. 最初项目开始需求分析的时候就要详细分解需求, 对客户提出的需求经过分析, 用户有时的想法也许在效果做出来的时候会感到不满意, 既而提出改动. 所以我们一开始就考虑用户的需求是否合理, 因为他们对技术不是太了解. 特别是服务类, 类似保险, 证券项目, 客户后面还有客户. 这是我们不妨站在真正用户的立场和客户进行沟通, 做出一个相对合理的需求
2. 最初的时候就考虑到需求会有变动的可能, 相对类来讲做产品的可能这方面问题会少点, 服务类遇到的会多点, 因此要有相应的方案来处理

两手都硬, 就不怕啦

作者: selingna 时间: 2008-5-16 16:36
拿到新的需求变更的时候，首先要看需求变动的幅度。
1.需求变动不大
a. review 先前的case，找出必须执行的case；
b. 编写新的符合需求的case，当然也要根据项目的进度量力而为。
2.需求变更较大
a. 尽量跟客户争取多一点的时间
b. 跟PM 开发一起讨论，决定那些地方要改，如何改。最好再得出结论后，能给客户一个review，避免会有进一步的变更带来的不便。
c. 根据schedule，添加或修改case

个人认为还有很重要的一点，就是在测试需求变更的时候，一定要有好的心态。不要不耐烦或者烦躁，尽管枯燥或很麻烦。
总之态度正确，心态良好是能做好工作的前提吧.

作者: Roy_Zhang 时间: 2008-5-16 17:15
强烈响应我们项目中的QCers要求，来到51testing上，看帖回帖。
关于这个帖子的标题
从一个developer的角度来说
大家的交流，非常重要。特别是对于需求中的东西，经过彼此的讨论，可能会发现自己理解不当的地方，或者说有了更好的idea。

作者: random_qjj 时间: 2008-5-16 17:46
发表一下个人愚见（名次怎么17点前就出来了。。自己给自己一个鼓励奖了，嘿嘿）：
首先，对于客户更改需求这种情况，应该说在一个项目进行过程中是难以避免的（就像这次四川地震。。。在这里默哀一个，愿活着的能坚强生活下去），我们能做到的就是如何尽量少的控制这种情况的发生，我想这主要就是看与客户的沟通是否深入，有无真正的理解客户的需求。在项目前期需求确认阶段，务必应该与客户深入研究项目的各个方面，开发这边有需求不明确的要及时提出。对于所有的需求，最好都能文档化，这样对之后项目的推进是很有帮助的，如果有人员变动，后来者也能根据文档很快熟悉了解这个项目。
对于已经发生这种情况，测试人员如何应对的话，测试方面，还是应该可以先和开发交流一下，具体改动了哪些模块的代码，模块间有联系的是哪些模块，接下来根据这些有影响的模块来测试相对应的功能，整个系统的话可以进行简单冒烟测试即可，如觉得不够保险，加入一些简单测试点也可。另外，需求更改了文档上面也应该及时更新，最好也都能注明下哪个issue导致了这次的需求变更，做到文档保持最新的。
就这么说一下，再次鼓励自己一下，嘿嘿，第一次写这么多，冒着可能误导人的风险，嘿嘿！

作者: xiaoyfanger 时间: 2010-5-14 11:32
呵呵支持一下

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)