测试过程中如何应对频繁的版本变更？（08-02-29）（获奖名单已公布）
不少测试管理者都遇到过这样的问题：测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现、基本功能点出现缺陷导致大量测试用例堵塞无法进行、缺陷太多导致继续测试失去意义等等，不得不频繁打回版本、修复缺陷后重新开始测试，使得本该完整的测试过程变成了边测边改、边改边测，不仅使测试进度无法按计划进行，还影响对测试对象质量的完整评估。这种情况是否有好的办法加以规范呢？欢迎大家各抒己见！非常感谢各位会员积极参与，截止至3月7日１７：３０分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。
获奖名单奖项获奖名单奖励答案链接一等奖huior当当购物卡50元41#二等奖buzz300论坛积分32#charles52#三等奖wangyong3552128100论坛积分 4#gogonorman16#havards20# 的确是个普遍的问题。我认为，开发是一个过程，这种现象肯定是避免不了的。也是最大的一个风险。而质量也往往是经过这个过程来提高。项目之初定schedule的时候应该考虑这种风险。阶段要划清，对于开发，测试都一样。比如一周一个版本。如果各个component相互影响比较大，最好一个版本做完整测试，不要零星来测。如果相互比较独立，可以不同的版本测不同的component。目前我就是这样在做。评估项目的时候，我就明确提出这个风险，引起大家的高度重视。测试过程中，我就坚持测试的节奏，不能太多的出现每个版本都只测部分，然后到头来好多case没测到。只是个人感受，供参考。
回复 1# 的帖子
测试版本质量差的根本原因是没有有效执行开发和测试计划造成的；造成这种情况的原因可能是以下几种：1、开发质量太低；
2、版本计划不切实际；
3、测试质量太低；
针对以上几种原因分别提出对策：
1、测试第一轮就进行详尽的测试，找出尽可能多的Bug反馈相应开发；
2、尽早提给相应主管，要求重订计划；
3、检查并评估各功能的测试用例，跟踪测试进度，有产品经理监督测试及开发进度，及时修正，避免延迟。
其实工作要做好，各角色之间需建立有效的监督与促进机制才是王道。
测试人员如何面对频繁的版本变更？
在我们测试过程中发现自己所测试的版本频繁变更(很让人郁闷呀，刚测试过的还得要测试一遍，哈哈)，这在软件公司是很普遍的现象。那么我们怎么去控制或者避免研发人员去频繁的变更测试版本呢，首先我们要分析在软件公司产生这种不规范现象的原因：1.公司领导们（特别是研发部领导）对软件测试不注重或者注重的程度不高；
2.测试部内部没有对此问题向公司提出自己的见解和解决的办法，没有和研发部达成一定的共识（多交流才是解决问题的办法），测试部要有公司领导做后盾，由研发部领导在场，制定硬性措施，强制研发人员配合测试部的工作；
3.在产品初期，研发人员对产品没有做冒烟测试而直接提交给测试人员进行测试，这样测试人员虽然能发现大量的BUG，但是研发也会提交更多的测试版本，他们修改后甚至没有做过测试而直接提交给测试人员测试；
4.测试人员的基本素质和测试态度起码不够坚强，研发人员没有站在测试人员的角度去考虑，要让他们时刻意识到“边测边改、边改边测”的办法是行不通的，测试人员更要杜绝“边测边改、边改边测”的不规范现象；
5.当测试人员在测试中发现问题，在向研发人员确认此问题时没有提醒研发人员“不要修改版本”或“不要动服务器”之类的话，要时刻提醒他们，久而久之他们也会养成一个不在测试完毕不向更新程序的习惯；
以上几点不仅是版本频繁变更的产生原因，而且也是我们针对这些原因找到解决此问题的办法。关于版本频繁变更的原因都是我个人根据实际工作经验而得出的，实际原因可能不止以上这些，希望各专家多多补充，尽量、全面的找出公司测试版本频繁变更的解决方案，给测试人员的工作带来方便。
[ 本帖最后由 wangyong3552128 于 2008-3-3 18:33 编辑 ] 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:
[ 本帖最后由 yanzizhao1102 于 2008-3-1 15:40 编辑 ] 对于频繁的版本变更，会造成测试人员不断的重复工作，效率较低。
测试人员应该把握好自己的步调，不能跟着开发人员跑。
在初期，当然是需要整体过一遍，对大概存在的问题有个了解，
然后可以将大模块拆分成小模块，功能测试，功能大部分都是可以拆分成多个部分，然后可以将问题集中的模块和问题相对较少的模块区分测试。
版本变更频繁度会有一定的趋势，可以在版本变更较少的时候再做整体的测试 原因很多
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他，同时也需要大家坐下来一起重新讨论各个计划的修改等．[ 本帖最后由 gogonorman 于 2008-3-2 17:37 编辑 ] 版本变更频繁，要分析内容很多，但是就实际问题实际分析而言：
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还是其他的)，这样也可以乱中觅得一丝头绪。
