查看完整版本: 测试过程中如何应对频繁的版本变更？（08-02-29）（获奖名单已公布）

测试过程中如何应对频繁的版本变更？（08-02-29）（获奖名单已公布）

不少测试管理者都遇到过这样的问题：测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现、基本功能点出现缺陷导致大量测试用例堵塞无法进行、缺陷太多导致继续测试失去意义等等，不得不频繁打回版本、修复缺陷后重新开始测试，使得本该完整的测试过程变成了边测边改、边改边测，不仅使测试进度无法按计划进行，还影响对测试对象质量的完整评估。这种情况是否有好的办法加以规范呢？欢迎大家各抒己见！

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

[table=410][tr][td=4,1,410][align=center][font=宋体][size=2][color=red][b]获奖名单[/b][/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=blue]奖项[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=blue]获奖名单[/color][/size][/font][/align][/td][td][align=center][size=2][font=宋体][color=blue]奖励[/color][/align][/font][/size][/td][td=1,1,72][align=center][font=宋体][size=2][color=blue]答案链接[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]一等奖[/color][/size][/font][/align][/td][td][align=center][color=#000000][size=2]huior[/size][/color][/align][/td][td][align=center][font=宋体][size=2][color=#000000]当当购物卡50元[/color][/size][/font][/align][/td][td][font=Verdana][font=Verdana][url=http://bbs.51testing.com/viewthread.php?tid=107290&page=3#pid892251][align=center][font=Verdana]41#[/font][/align][align=center][/url][/font][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]二等奖[/color][/size][/font][/align][/td][td][align=center][color=#000000][size=2]buzz[/size][/color][/align][/td][td][align=center][size=2][color=#000000][font=宋体]300论坛积分[/font][/color][/size][/align][/td][td][font=Verdana][url=http://bbs.51testing.com/viewthread.php?tid=107290&page=2#pid891753][align=center][font=Verdana]32#[/font][/align][align=center][/url][/font][/align][/td][/tr][tr][td][align=center][font=宋体][color=#800080][/color][/font][/align][/td][td][align=center][color=#000000][size=2]charles[/size][/color][/align][/td][td][align=center][font=宋体][size=2][color=#000000][/color][/size][/font][/align][/td][td][font=Verdana][url=http://bbs.51testing.com/viewthread.php?tid=107290&page=3#pid893514][align=center][font=Verdana]52#[/font][/align][align=center][/url][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]三等奖[/color][/size][/font][/align][/td][td][align=center][color=#000000][size=2]wangyong3552128[/size][/color][/align][/td][td][align=center][font=宋体][size=2][color=#000000]100论坛积分 [/color][/size][/font][/align][/td][td][font=Verdana][url=http://bbs.51testing.com/viewthread.php?tid=107290&page=1#pid889685][align=center][font=Verdana]4#[/font][/align][align=center][/url][/font][/align][/td][/tr][tr][td][align=center][font=宋体][color=#800080][/color][/font][/align][/td][td][align=center][color=#000000][size=2]gogonorman[/size][/color][/align][/td][td][align=center][font=宋体][size=2][color=#000000][/color][/size][/font][/align][/td][td][font=Verdana][url=http://bbs.51testing.com/viewthread.php?tid=107290&page=1#pid890240][align=center][font=Verdana]16#[/font][/align][align=center][/url][/font][/align][/td][/tr][tr][td][align=center][font=宋体][color=#800080][/color][/font][/align][/td][td][align=center][color=#000000][size=2]havards[/size][/color][/align][/td][td][align=center][font=宋体][size=2][color=#000000][/color][/size][/font][/align][/td][td][font=Verdana][url=http://bbs.51testing.com/viewthread.php?tid=107290&page=1#pid890921][align=center][font=Verdana]20#[/font][/align][align=center][/url][/font][/align][/td][/tr][/table]

的确是个普遍的问题。我认为，开发是一个过程，这种现象肯定是避免不了的。也是最大的一个风险。而质量也往往是经过这个过程来提高。项目之初定schedule的时候应该考虑这种风险。阶段要划清，对于开发，测试都一样。比如一周一个版本。如果各个component相互影响比较大，最好一个版本做完整测试，不要零星来测。如果相互比较独立，可以不同的版本测不同的component。目前我就是这样在做。评估项目的时候，我就明确提出这个风险，引起大家的高度重视。测试过程中，我就坚持测试的节奏，不能太多的出现每个版本都只测部分，然后到头来好多case没测到。只是个人感受，供参考。

回复 1# 的帖子

测试版本质量差的根本原因是没有有效执行开发和测试计划造成的；造成这种情况的原因可能是以下几种：
    1、开发质量太低；
    2、版本计划不切实际；
    3、测试质量太低；
    针对以上几种原因分别提出对策：
    1、测试第一轮就进行详尽的测试，找出尽可能多的Bug反馈相应开发；
    2、尽早提给相应主管，要求重订计划；
    3、检查并评估各功能的测试用例，跟踪测试进度，有产品经理监督测试及开发进度，及时修正，避免延迟。
    其实工作要做好，各角色之间需建立有效的监督与促进机制才是王道。

测试人员如何面对频繁的版本变更？

在我们测试过程中发现自己所测试的版本频繁变更(很让人郁闷呀，刚测试过的还得要测试一遍，哈哈)，这在软件公司是很普遍的现象。那么我们怎么去控制或者避免研发人员去频繁的变更测试版本呢，首先我们要分析在软件公司产生这种不规范现象的原因：

1.公司领导们（特别是研发部领导）对软件测试不注重或者注重的程度不高；
2.测试部内部没有对此问题向公司提出自己的见解和解决的办法，没有和研发部达成一定的共识（多交流才是解决问题的办法），测试部要有公司领导做后盾，由研发部领导在场，制定硬性措施，强制研发人员配合测试部的工作；
3.在产品初期，研发人员对产品没有做冒烟测试而直接提交给测试人员进行测试，这样测试人员虽然能发现大量的BUG，但是研发也会提交更多的测试版本，他们修改后甚至没有做过测试而直接提交给测试人员测试；
4.测试人员的基本素质和测试态度起码不够坚强，研发人员没有站在测试人员的角度去考虑，要让他们时刻意识到“边测边改、边改边测”的办法是行不通的，测试人员更要杜绝“边测边改、边改边测”的不规范现象；
5.当测试人员在测试中发现问题，在向研发人员确认此问题时没有提醒研发人员“不要修改版本”或“不要动服务器”之类的话，要时刻提醒他们，久而久之他们也会养成一个不在测试完毕不向更新程序的习惯；

   以上几点不仅是版本频繁变更的产生原因，而且也是我们针对这些原因找到解决此问题的办法。关于版本频繁变更的原因都是我个人根据实际工作经验而得出的，实际原因可能不止以上这些，希望各专家多多补充，尽量、全面的找出公司测试版本频繁变更的解决方案，给测试人员的工作带来方便。

[[i] 本帖最后由 wangyong3552128 于 2008-3-3 18:33 编辑 [/i]]

1.如果新版本增加新功能，那么按原计划完成当前工作再测试新功能；
2.如果是修改缺陷后提交的新版本，那么返测缺陷，注意缺陷群集现象；
3.和需求，开发人员交流，明确任务安排。

什么是需求变更？如何处理需求变更？

要回答如何需求变更，首先要弄明白是是需求变更。
所谓“需求变更”是指在基线化的开发设计规格和测试需求规格后，产生了新的设计规格和与之对应的测试规格，或者是变化了原有的设计规格，导致原有的测试需求规格不得不随之改变这么一种情况。需求变更的影响要看这个变更是在什么阶段发生的。

为什么会有需求变更？一般来讲，我们的系统设计规格通常不会一次性的完全满足客户的要求，那么随着需求的明确化，有可能隐含的需求被进一步挖掘出来了，这时我们不能不做这些需求啊，所有只好在原有的设计规格中加入这些新的需求规格。以及补充测试设计，和重新制定和调整测试计划。
一般理论而言，测试和开发基本上是同步的，但是实际的开发和测试过程活动中，往往是不同步的，即使是华为，爱立信这样的顶级的通讯企业的测试和开发也不是完全同步的，所以呢大家也不必对不变更或者不同步产生恐惧心理:)

怎样识别需求变更？如何识别需求变更的影响？如何应对需求变更？

如果原有计划、测试规格、测试用例不适应了当前的完整的需求了，那么此时一般是出现了变更。
变更一般有这么几个出现的时机，1是需求分析阶段 2是方案设计阶段 3是用例设计阶段 4是测试评估阶段
房东来了，没得心情讲了，改天再谈

有关于软件质量我也来侃侃二句！详细见附件，谢谢！
不知可以从版主万小姐哪里拿多少51论坛多少分！（版主的名字我就不说了！:) ）

测试过程中如何对应频繁的版本变更

我个人认为测试人员要尽早进入测试，必须在需求阶段就介入，尽早发现缺陷，在需求发生变更后应确定变更的时间点，而且明确在需求变更时间点后都执行了那些测试用例，确定需求变更后对哪些测试工作产生了影响，要对需求进行跟踪。不管在那个阶段都要对需求进行跟踪。虽然在单元测试和集成测试阶段的目的中没有涉及到SRS文档，但是作为测试人员也应该要要参照SRS文档。要查看HLD和LLD是否是按照SRS来写的，每个功能是否都描述得清楚，有没有歧义，不仅要查看显示的问题，最主要是查看它的隐式问题。测试人员还必须熟悉行业背景，要做到客户想不到的测试人员都得考虑到，这样还可以预防需求变更。
上述是我个人的想法，还望大家指导。

古人说对症下药，所以我们应该先找出出现频繁版本变更这种现象的原因，从根本上解决问题：
本人思考原因有下：
1.需求写得粗糙，需求分析的工作没有做好，很多隐藏的需求更甚至是显示的需求都没有考虑到，导致开发人员设计的代码有局限性，以致于测试时总是出现问题，总是返工再测试。
  这种问题通常是需求没有进行正规的审查，与测试工作脱节，测试设计的测试用例跟需求不能很好的对应，还有可能是开发人员对业务不够熟悉，不能弥补需求的不足。这就需要工作人员从头做起，把需求做好，做好需求的评审工作，用相应的文档比如需求跟踪矩阵约束好需求与测试用例的对应，但并不是说简化测试用例的设计工作，是指的测试用例与需求是有对应覆盖关系的（其中对需求的覆盖包括显示的和隐示的），在工作中也好统计测试覆盖率；再一方面在工作过程中要对员工进行相应的业务培训，使得不管是开发还是测试等工作人员在工作中更能得心应手，避免交流的障碍，和不必要的重复性劳动。
2.需求变更的工作没有做好，需求通常是由客户提出，而客户通常是非IT类人员，对软件制作过程的不了解可能会导致交流有障碍，就会出现需求的不断提出，不断的变更，使得开发人员措手不及，提交一次又一次不同的版本。
  这种问题通常是与客户的沟通环节上以及变更控制环节上出了问题。那就需要在沟通上多用善于交流、挖掘需求信息的人，得到全部的需求后设计出详细规范的需求规格说明书，在需求评审完后将需求基线化，做好变更控制，一旦出现变更要由权威人士商讨变更的可能性，确定变更是否执行，这样一来不会有很多的需求版本也不会有由此而导致的很多开发版本。
3.缺少预测试环节或者预测试工作没有做好。测试人员拿到被测软件后没有做好预测试工作，将不成熟的软件进行全面的测试导致软件缺陷百出，不停的返回修改导致版本增多。
   出现这种问题要是没有预测试环节在这种情况下就要增加，如果其他项目中项目比较小开发人员能力有比较强的情况下可以省略；如果预测试工作作了还是有这种问题出现那就要考察预测试用例是否不够典型，进行相应的修改。
4.开发人员的能力有限。开车人再懂交通规则不会开车，车也开不出去呀！
   以上是本人的想法，偶是初学者，大家多提意见^_^

不能根除只有百测不厌

(1)测试是与开发相辅相成的,有频繁的变更是对的.:loveliness:
(2)版本变更越快,说明开发的速率也越快,软件本身的更新也就越快.:loveliness:
(3)测试的本身就是不断的发现问题和修改问题的,所以我们要不要抱着测两次就完事的观点:loveliness:
(4)写好测试用例.不断的修改测试用例.这方面很重要,能避免不必要的时间浪费.:loveliness:
(5)一次通过是不可能的,要不厌其烦的,百测不厌的将测试进行到底:victory:

[[i] 本帖最后由 yanzizhao1102 于 2008-3-1 15:40 编辑 [/i]]

对于频繁的版本变更，会造成测试人员不断的重复工作，效率较低。
测试人员应该把握好自己的步调，不能跟着开发人员跑。
在初期，当然是需要整体过一遍，对大概存在的问题有个了解，
然后可以将大模块拆分成小模块，功能测试，功能大部分都是可以拆分成多个部分，然后可以将问题集中的模块和问题相对较少的模块区分测试。
版本变更频繁度会有一定的趋势，可以在版本变更较少的时候再做整体的测试

原因很多
1.需求不切实际
2.单元或单服测试不规范
3.程序能力存在问题
4.工作态度存在问题
5.没有计划,计划过于理想,或流程计划通过有效的监督进行实现
6.版本更新过于草率
问题很多,甚至涉及到公司高层的领导是否有能力等
改善的话,对一个公司来说需要很长的时间和很大的精力
(不好意思,下面把测试划分为开发的一部分,可能有些人不太认同,当没看到就可以了).
1.在需求评审阶段必须由开发人员(设计\程序\测试)参与,并必须就需求提出疑虑\难点,为可能出现的问题作出预防,并使需求切合实际,不天马行空
2.要求测试人员必须对需求作出完整的需求分析,测试计划和详尽的测试用例,通过评审完善相关文案.需要严格按照规程执行相关用例.遇到因某些问题而用例无法继续执行时.需要及时与程序及设计人员进行沟通,并积极跟踪问题的解决进度
3.这条看着好笑.如果程序能力存在问题这个需求基本上就完了.但一些需要研究解决的技术难点需要时间解决,或者根本不能解决,这些在需求分析阶段就应该提出问题并制定相应方案,如果该需求放弃的代价较大或必须实现,在不能解决时也只能寻求第三方的技术支持或外包了
4.在能力没有问题的情况下,由于工作态度而导致的问题,由环境\待遇\个人等等原因,具体原因具体分析解决方法,避免该人员的想法影响整个项目组的士气.
5.人都不是完美的,制定计划时应该也必须要考虑突发情况,考虑延误,预留出必要的调整时间.合理制定计划.严格执行计划.是一个项目快速开发的必要前提,需要有决定权限的人来监督计划的实施
6.集成测试和待发布版本的更新必须待单元测试或新开发系统稳定后再加入.否则单个系统的问题会影响整个项目的进度.
至于领导,呵,不好说....

1. 测试人员应该尽早的开始测试。应该从有正式版本的时候就开始测试sanity test, smoke test，这样能发现更多的问题。而且在第一次测试的时候应该把所有的case都跑一遍，找出尽可能多的问题，不要因为一个两严重的问题就重新更换版本；
2. 根据80-20原理，80%的问题集中在20%的功能模块，如果某个功能模块的问题比较多，应该对其的改动进行回归测试，和开发人员充分的沟通， 了解改动对什么部分有影响，只对改动有影响的部分进行测试。
:)

因此提倡自动化测试

软件测试本来就是一需要有耐心和细心的工作,对于杜绝频繁的版本变更,我个人认为:研发工程师应该做到边研发边测试,只有自己对自己的软件有信心后方能下发,同时应该给研发工程师配备一专用软件测试员,当然软件测试员的水平要看所在公司的经济实力

测试过程中如何应对频繁的版本变更?

我觉得测试团队作为产品质量的监控者，在这种情况下应该向项目的stake holder（比如project manager）提供详细的数据，比如目前能测试的feature的比例，被阻塞的feature和test cases的比率等，让他们了解目前release的质量状况，以及对测试团队schedule的影响，同时建议开发团队修改release计划（暂时停止发布daily build等，当然这还要看其他stake holder的需求），加强unit test的强度等．相应的测试团队的测试计划也要做出调整，有时也有可能降低冒烟测试的强度(有时这是迫于developer manager的压力)，可以先对部分相对稳定的模块进行测试，同时要根据模块之间的关系细致安排test cycle避免回归测试间隙引起的bug escape,但是一定要留出足够的时间来对产品作完整的cover．我觉得这个时候test manager(leader)的沟通技能很重要，因为你没法去控制开发团队的工作，只能通过stake holder来push他，同时也需要大家坐下来一起重新讨论各个计划的修改等．

[[i] 本帖最后由 gogonorman 于 2008-3-2 17:37 编辑 [/i]]

版本变更频繁，要分析内容很多，但是就实际问题实际分析而言：
1、开发人员存在问题较多，过度的依赖测试人员，自己编码完成后，未作单元测试和一般的功能测试，
提交版本给测试人员，经测试发现一些功能未能实现，或者未按照功能实习，或者实际上功能实现了，由于严重基本较高的bug存在，致使实际功能无法展现，就导致‘边测边改’现象出现，条件一问题多处于对待工作的态度！并非需求分析和设计上存在漏洞；
2、项目经理或者技术经理，没有进行工作的量化和细化，未对版本发布做实际的限制，比如一周几个版本，这样测试人员所关注的问题就会集中到每个版本去测试，开发在发布版本之前要确保基本功能的实习和走通；
3、时间的概念，对一个项目而言时间是非常宝贵和有限，如一个bug的发现（特指基础的功能行bug）时间，如果开发人员没有发现，移交给测试人员进行测试这个bug最终是会被发现，在时间总量上是相等的，或者可能由于测试人员对编码，构架理解等等存在偏差，所花费的时间更长，对整个项目来说其实是一种损失；
4、团队的问题，相互之间了解和谅解；对问题的一个完善思考，不应该一味的只强调测试人员改怎样怎样，问题的解决应该是一个团队的，大家在一个团队，只有发挥整个团队力量整体的最大化，那才是最优化的设计，最好的团队!

我们公司也遇到过类似情况，不过并没有那么夸张，
说说我的看法吧：
1。制定的项目计划不合理；
2。开发人员的心态不好，即便他知道有问题也不说出来；
3。开发人员的技术能力不强，代码质量不高；
4。测试的计划也不合理；
5。测试的质量不高；
不管怎么说，说到底感觉都是管理人员，开发人员，及测试人员的心态，能力的问题；
不过还好我们公司刚刚对开发进行了改革，实行了承包到户，相信会象中国的改革开发一样，能够提高开发的质量。

以上是我的一点想法，请大家指教！！

呵呵，大家讨论很激烈啊
这种现象的确很常见，当然我们也存在，以下是我们目前的处理方法，欢迎大家一起探讨
1、在设计测试用例时，增加冒烟测试用例。
2、版本提交后，先按冒烟测试用例进行冒烟测试，保证软件的基础功能及流程可实现后才按计划安排测试，否则返回给项目组修改，直至冒烟测试通过。
冒烟测试不通过时，直接导致测试计划延期，我们每次都向项目经理反馈，严重时直接向上级领导反馈，经过几次配合，开发人员也特别注意，在提交版本前自己也进行简单测试，确保冒烟测试通过。
经常还出现这样的情况：开发人员担心提交的版本不通过，在版本提交之前，私下找测试人员简单过一遍:)

下面说说频繁的版本变更问题：
一、说说我工作时候出现版本频繁变更的原因：
    1.由于部分开发人员没有在svn上及时的check in和check out，导致打包的内容不是最新更改过的代码。
    2.开发人员和测试人员进行版本升级的时候，没有进行smoke test，结果最基本的功能都未实现。
    3.开发经理分配设计任务的时候，未进行设计优先级的划分，结果最基本和最重要的功能最后才设计出来。
    4.由于产品初期测试的时候，肯定是问题多发期，这个时候测试人员没有和开发人员保持时刻的沟通，导致问题不能得到及时的解决。

根据原因，我提出了自己的几点想法：
    1.开发人员要对svn或者其他版本控制工具上的代码及时的check in和check out,一定要保持svn上的所有代码都是最新的。
    2.开发人员将安装包交给测试人员的时候，测试人员一定要进行冒烟测试，这是一定要进行的。
    3.开发经理分配设计任务的时候，一定要进行优先级的划分，首先要保证最重要和最基本的功能，再谈其他的功能。
    4.不管是什么测试阶段，在条件允许的情况下，测试人员都要保证和开发人员的及时沟通，以求尽快的解决问题。
    5.不管版本更换多频繁，一定要使用缺陷管理工具(不管是mantis还是其他的)，这样也可以乱中觅得一丝头绪。

现在也是想解决这个问题，目前我的方法是：定一个周期做一个版本，如果软件修改比较大或测试进行到一定的阶段，还有根据项目计划来制定版本。

很支持20楼朋友的观点。

需求变动是正常存在的，不能根治，但可以有几个方面降低其风险
1，软件开发方式不能再一味的用瀑布开发模式，应先开发出一个核心功能模块，后再继续扩展。即演化方法开发
2，真正的重视测试，不要再最后才拉进测试团队。应确保测试人员对于客户的需求以及改动及时掌握，并对与测试用例第一时间改动
3，自然对于测试的项目不能随改随测，即在一定较短的时间内出一版本
4，自然最后就是客户，PG，TESTER之箭及时沟通，以确保清晰表达及被准确的理解

呵呵，大家讨论很激烈啊
这种现象的确很常见，当然我们也存在，以下是我们目前的处理方法，
1、在设计测试用例时，增加冒烟测试用例。
2、版本提交后，先按冒烟测试用例进行冒烟测试，保证软件的基础功能及流程可实现后才按计划安排测试，否则返回给项目组修改，直至冒烟测试通过。
冒烟测试不通过时，直接导致测试计划延期，我们每次都向项目经理反馈，严重时直接向上级领导反馈，经过几次配合，开发人员也特别注意，在提交版本前自己也进行简单测试，确保冒烟测试通过。
经常还出现这样的情况：开发人员担心提交的版本不通过，在版本提交之前，私下找测试人员简单过一遍

关于版本控制和需求变更的几点想法

我相信每个公司都会涉及到这两个问题，不管是大的还是小的，如何减少版本过多造成测试效率低下至关重要，版本过多根本原因是需求的变更和项目缺少有效的管理。众所周知，需求变更在带来管理的难度的同时也创造了价值，需求变更的评审是必须的，项目经理在每次提交一个新的版本时，必须检查是不是最新，从而确保测试人员都能拿到最新的。

根本原因是管理不善。一般从以下几个方面着手改善，但不能杜绝
1. 不能有效管理客户需求的变更请求，导致版本更迭过于频繁
这种情况应在项目经理层进行控制，可以采用延后集中处理的方式进行处理；在实在不能妥协的情况下，才采取立即变更处理——但一般情况下都可以通过沟通协调解决；
2. 不能有效使用Smoke Testing工作，导致提交版本错误迭出，继而进行补丁修正；
这种情况一般是由于工作流程不完善导致的。常见的场景是本地没问题，一旦更新提交了就出问题。PM可以借助Smoke Testing的方式规避掉这种由于配置管理无效导致的问题，同时应在项目管理制度上进行增强。确保具体的流程实施。
3. 更新配置管理计划失调
这种情况是缺乏预见和预防的表现，也是一种比较糟糕的情况。出现这种情况的罪魁祸首是项目组的经验（尤其是项目领导人）缺乏，不能预防可预见的风险而导致的。项目计划的后期出现这种情况的话则是由于处理失当导致的，如：项目计划的更新与配置管理计划不匹配，出现明显的偏离等。
4. 技能不足
这种情况最好解决。增强培训和相关技能即可。但是项目组不一定可以在短时间内达成目标，所以归根结底还是项目准备阶段的问题。

个人认为能够引起版本变更的因素很多，但比较普遍的是如下几点：
1.需求频繁变更。（个人认为软件的核心就是需求，软件是为了满足需求而生的，所以需求变更，往往会引起版本变更）
2.代码频繁变更。（可能是为了新功能，也可能是改缺陷，也可能是优化之类的）
3.版本控制没做好（找不到以前的版本了，或者找到了也不知道哪个是最新的，找还不如重新做一个快，结果版本越生越多，一片混乱）
针对以上，个人认为因从几方面控制：
a.在开发前期，要认清客户，定位好产品，要做好需求分析（尽可能地多挖掘，功夫做前头，要让需求有扩展性）
b.在确定需求过程中尽量让客户参与，能充分引导客户，并且消除和客户之间的误解，在充分沟通达成一致后要白纸黑字落实，并和客户约定好在一段时间里面不会做太多调整。（呵呵，当然这个需要客户支持，如果遇上强势客户，这步就比较麻烦了）
c.对需求进行评审把关（尽可能保证要实现的需求合理而且扩展性较好），对决定在某个版本中应满足的需求进行明确化并进行管理。
d.需求确定后，在进行设计的时候，应充分考虑扩展性，同时也对设计进行评审。做好版本规划。
e.对开发人员进行技能培训，在项目小组进行充分地沟通，消除误会。（尽量不要出现客户想要苹果，但是项目小组的人开发人员以为要的是梨，别的人员以为是香蕉的现象）
f.如果可以，支持测试先行，把缺陷尽可能地解决在前面。
g.看到前面有些帖子说，先开发核心系统，这个观点我支持，系统的耦合度应尽可能地低，尽可能地简单易拼装，争取能以不变应万变。
h.如果客户频繁变更需求，则应该对客户提出的需求变更进行评审，要考虑是不是和原来的有冲突，不要因为容易实现就满口应承，再容易实现也是要有成本的。即要作为引导方，正确引导客户能稳定需求。一方面如果确定合理的变更，应及时做好需求变更。要尽可能在全过程中保证需求和实现一致。因为需求是核心啊！
i.对于开发人员对测试的态度不端正的问题，建议增加绩效考核。当然最好是从思想上给予教育，加强培训。毕竟善良的人多。
j.还有有帖子说引入自动化工具提前进入测试，支持，不过这个只是争取让变更降低成本的一个措施，如果不从根本上去控制，再多的工具也可能忙不过来。
k.版本混乱，那就要做好配置管理了，就好像住家，总不能老住猪窝吧，该清理的要清理，该命名的就命名，合理的配置管理计划还是很重要的。干净整洁的环境能让人更健康，软件也一样。
   总之，确实是个管理问题，而管理应该从一开始就开始控制，要让变更变成可控的，可追溯的。毕竟做什么事情都希望能够用最少的成本获取最大的效益，要争取“双赢”才是根本目的的。
    以上纯属个人观点，可能有些理想化，仅供参考。

[[i] 本帖最后由 haohaoxuexi 于 2008-3-4 12:00 编辑 [/i]]

提到版本问题必然会牵涉到配置管理
在国外，很多公司都是聘请一些很有经验的开发人员来做配置管理的事情
配置管理人员地位是相当高的
但是在国内，不少配置管理人员是因为开发做不下去，或者测试做的太差才会被指派去做配置管理
所以首要问题要加强配置管理意识：
1 不允许随意地提交版本
2 打tag
当然除了配置管理以外还有其他因素
比如流程管理的问题
但是规范配置管理是当务之急
改过了就提交一下的现象必须要杜绝


还有个问题。。。
我看到上面回帖的有不止一个人说的是需求变更。。。-_-
作为一个测试工作者居然那么不仔细。。。

回复 28# 的帖子

to Ls，人家的题目是如何应对频繁的版本变更，需求变更很容易引起频繁的版本变更，所以至少我认为上面的回帖有不止一个人说的是需求变更是没有问题的，偶实在不太赞成你说人家“作为一个测试工作者居然那么不仔细。。。”。。。。。。

[[i] 本帖最后由 haohaoxuexi 于 2008-3-4 12:21 编辑 [/i]]

本人意见是尽可能多的在原始版本上进行测试，除非是遇到block的BUG，才更换至新的的版本。 在新的版本中需要对修复后的bug进行详细的测试，包括与之有关联的相关模块。:)
最后，在说一句话，回归测试是一个很好解决版本经常更替的方法，至于作几轮，就要看各个资源配置情况和质量控制情况了！
谢谢！

[[i] 本帖最后由 lovemiya 于 2008-3-4 13:27 编辑 [/i]]

测试版本由测试人员主导发布（基于测试团队与开发团队分离的情况下）

1、 测试从需求阶段开始介入。加入测试角色进行需求分析以及需求评审工作可以有效避免因为需求不清以及需求歧义导致的测试版本更新。
2、 测试部分介入测试之前，开发团队需要提供一个可测试的基准版本。
3、 测试过程中的版本更新由测试人员主导发布。这也是个行之有效的方法。可以直接由测试人员发布也可是由测试人员监督发布。这样测试人员可以对本版本的情况了熟于心，这会节省不少回归测试的时间；
4、 这样最终版本经过测试人员测试得出，无疑增加了提交版本到客户的赢得好评的信心。

[[i] 本帖最后由 yayapang 于 2008-3-4 13:43 编辑 [/i]]

测试过程中如何应对频繁的版本变更?

1、通过管理制度约束，要有明确的版本打回的考核制度，把版本打回次数与开发人员的考核指标挂钩，并有一定的惩罚措施，这样才能使开发提高提交版本的质量，从而使提交版本可测试。

2、通过清晰，明确的流程保证，如提交测试的版本要有一定的测试准入条件，没有达到准入条件的一律打回处理，不能浪费更多的时间测试一个不可测试的版本。针对版本所规划的需求未实现这一问题，可以增加需求验证这一环节，这个环节的验证不会要求很细，但是可以规划的需求已全部实现，或实现的功能与需求规划是一致的，这样提交到测试环节的版本，我们就可以按计划开展比较详细的测试。

3、通过一些方法和策略保证。把测试分级，一个版本的提交，通过几个级别的测试，然后再确定是否全面投入测试，1级的可以定义为运行BVT或一些预测试，例如正确执行安装，运行等测试用例，这些是最基本的用例，通过后再运行2级用例，定义为一些基本功能和主要流程类的用例，运行通过后再按计划展开全面的测试，避免盲目的投入造成测试资源的浪费和做无用功。前2个级别的测试完全可以通过自动化来实现，这样的话可以夜间进行，既提升了效率，也不会对进度有太大影响。

总之，我认为制度，流程，方法结合，可以把风险和影响降到最低，但最终的根本还在于整个研发团队的质量意识和团队精神，这两方面都比较强的话，再加以健全的流程和制度，包括这个问题的许多问题都可以迎刃而解了。

还是那句老话：过程保证质量！
还是要做好 过程的啊！

赶上大家讨论的末班车了
个人看法：
1.开发人员编码的规范和修改bug的质量；
2.build版本的质量
3.测试用例的覆盖度，测试人员严格执行情况
4.开发与测试之间的沟通
5.缺陷管理工具的跟踪
6.公司的管理体制

1测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现
在流程中作相应的规定出现上述问题可以申请停止测试，原因是交付的版本不能达到测试标准，这点很重要。会减少很多没有必要的重复测试工作.:victory:

2测试过程中发现自己所测试的版本频繁变更(很让人郁闷呀，刚测试过的还得要测试一遍，哈哈)，这在软件公司是很普遍的现象。
说实话频繁的变更版本对测试人员和研发人员都不是好事，实际操作时经常会出现这个人的代码没有打进去或是那个人的代码刚改完
从新打包的情况。一般还是要按照周期来做比较保险。新版本交付测试一个周期完成后再打包。当然这其中可能碰到一下阻碍测试
继续进行的问题可以适当处理，但是这个比例是要控制的。一般情况下如果交付测试的版本不能达到需求说明书中80%功能完成标准的
我们还是应该坚决拒绝测试的。前提是你公司和你的领导真的很重视测试。否则一切都是扯淡

针对上面的问题还有一个相对比较好的解决办法,在进行单元测试时又测试人员进行协助测试,这过程中不紧紧是简单的功能测试还有性能测试.在单元测试时严格把关,把一些简单的BUG(界面上的)尽量大的在单元测试中结束,这样即减少了后期系统测试时的很多无谓的重复劳动也把很多严重的性能问题在最早期发现并解决.但是需要研发人员的配合.:victory:

测试过程如果只是测试执行过程，如果能够预见面对版本的频繁变更，测试执行策略应该做出弹性规划，或者跟更多的采用探索式的session based的测试。

事后分析原因，看看问题是出在配置管理还是代码质量上
第一个问题说明要有一个好的构建发布的配置管理流程
如果是第二个问题，原因可能不同，首先可以尝试加强unit test, integration test以及requirement review, design review, code review等quality control的方法

“边测边改”不能算是一个很糟糕的现象。
我现在所在的公司多数项目就处于这种状态。我之所以说“边测边改”不是一个糟糕的现象是由于，项目组对于版本的划分不是非常明确，从而导致有很多版本的出现，但是这种多版本并不能算是真正意义上的“版本”，可以算做是开发阶段或者说集成阶段的“开发版本”或“小版本”。
在这种版本提交到测试的时候，如果发现影响测试进行的缺陷，这种版本立即退回并停止测试，这个时候开发人员有事情去处理，测试人员依然有事情需要去做，测试人员需要做的可以是继续完善系统测试用例等等。
“边测边改”的情况是测试部来划定软件版本的一个方法，例如收到项目组的一个测试版本的时候，测试组可以对此版本定义测试版本，测试提交缺陷，同时开发人员在缺陷管理器上查看缺陷，修复并继续开发。
一轮测试结束（覆盖所有的业务功能点）后，分析缺陷管理器，之后，项目组可以修复提交的缺陷，并重新发布新的版本供测试部进行回归测试
这个过程是一个迭代的过程，因此“边测边改”并不能算是一个很糟糕的现象。
:)

个人见解

首先，我认为对处理版本的变更是一个重要的环节。由于需求的不同及增多，会产生很多不同的版本，所以在测试的时候会带来很多不必要的麻烦。因此，我建议将测试版本化。将测试需求、计划、执行的测试用例等分成不同的版本。并且要了解各个版本之间的区别，这样可以重点的测试这些环节。为了醒目还可以采用不同的颜色加以标识。
还有一种可行办法就是可以做一个通用版本的测试需求、计划、执行的测试用例，然后对不同的版本对应不同的功能再附加其相应信息。

测试过程中如何应对频繁的版本变更?

现在让我们来假定频繁的版本变更已成事实。:)

既然现在的情况是这样，肯定能找出造成这种现象的原因。

1.需求不断变换:       当碰到客户有新的需求或需求有改动的时候，开发和测试人员应该要协调好，正确的学习新的需求和变动的需求。这样开发和测试人员才能统一对需求的理解。要是对需求的理解不一致，在整个开发和测试过程中就会出现很多不必要的麻烦。例如：开发人员对需求理解有误，写出来的功能点程序必然不符合客户的需求，这样在测试人员那里通不过，就得返工；测试人员对需求的理解有误，在测试的过程中，将正确的功能点报告成bug，反馈到开发人员那里，这样就浪费了开发和测试的时间。当版本频繁变更，作为测试人员一定要紧跟需求变更，抓住一个软件的质量的根源，及时更形测试用例。

2.系统的开发管理：     一个软件的开发的好坏很大程度上取决于整个软件开发的项目管理上。当各个团队之间的实力都相差无几的情况下，项目管理越完善，开放一个软件的成本就越低，质量就越好。因此，面对版本频繁变更的情况，及时调整项目管理的方法，亡羊补牢。

3.开放人员的程序能力存在问题：     这是在软件开发环节中致命的弱点。当碰到这种情况，也只能耐着性子，慢慢来了。^_^

4.工作态度存在问题：     有些人会认为，版本更新的越快软件就更新的快，整个开发的过程质量就越高。这种想法是错误的。一个版本的更新到下一个版本的更新时间间隔必须要达到一定的时间度，也就是说，要让测试人员有足够的时间测试一个新的版本。在这种情况下，测试人员能做的有两个方面。一方面是，主动和开发人员协商，调整版本更新的时间；另一方面是，清楚的知道开放人员改动的地方是哪些，对改动的地方，以及与其相关的地方进行重点测试，同时，对于每一个新版本，一定要把每一个功能点都测试到，不能遗漏。

5.版本更新过于草率：     有的开发人员，在改过一次代码后，不经过检查，就迫不及待的将代码提交了上去，更新版本。这样，在这个新的版本中就可能会出项很多很简单很不应该有的简单错误。这样就增加了版本更换的频率。作为测试人员应当跟开发人协调，让一个新的版本在进行完整的测试之前，进行预测试，测试各个主要的功能是正确。通过了之后，再进行全面的测试。

以上仅仅是个人意见，各位高手多多指教！

回复 1# 的帖子

当前问题：测试过程中如何应对频繁的版本变更？（08-02-29）
       不少测试管理者都遇到过这样的问题：测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现、基本功能点出现缺陷导致大量测试用例堵塞无法进行、缺陷太多导致继续测试失去意义等等，不得不频繁打回版本、修复缺陷后重新开始测试，使得本该完整的测试过程变成了边测边改、边改边测，不仅使测试进度无法按计划进行，还影响对测试对象质量的完整评估。这种情况是否有好的办法加以规范呢？欢迎大家各抒己见！
==========================================================
这应该是一个公司的测试从混乱走向规范，必然经历的一个过程。
这个现象我觉得需要分两种情况来说：
1.需求随着市场等各方面因素不断变化的情况：这种情况下，无论计划做得再好，计划跟不上变化，必须不定期的变更需求，生成版本，不断测试。这是一个频繁迭代的过程，就需要边测边改。
2.需求相对比较稳定的情况：这种情况下，如果发生了上述问题，我觉得那就是研发、配置管理、测试三方面的责任了。1）研发的责任在于，没有将单元、集成测试做好，没有经过基本的自测试，可能是开发完，最基本的验证都没做就提交了代码；
2）配置管理的责任在于，没有对提交给测试的版本进行冒烟测试（或由其他人以及自动化完成），没有把好版本控制关。对于基本的冒烟测试都无法通过的版本（除非特殊情况、特殊放行），是不能提交给测试的；
3）测试方面的责任在于，不能一味的追求在最新版本上测试，应该按照测试计划，有目的、有步骤，系统的进行全面的测试。切忌无目的、盲目的测试。

因此，如果不是需求变更导致的频繁生成版本，我觉得重点应该在研发及配置管理这两块把好关。否则，只能适应这种快速迭代的开发过程，对于这种情况，测试计划就不能定的太长，总体测试计划可以比较粗，把测试的原则、目标、总体规划定义清楚即可。随着项目的推进，小节点的测试计划必须跟研发计划同步，随时更新。另外，对于基本的功能、性能测试点，可以自动化的尽量自动化，重复的劳动能省就省。
    以上是个人的一些观点，欢迎指教。