51Testing软件测试论坛

标题: 测试过程中如何应对频繁的版本变更？（08-02-29）（获奖名单已公布） [打印本页]

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

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

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	huior	当当购物卡50元	41#
二等奖	buzz	300论坛积分	32#
	charles		52#
三等奖	wangyong3552128	100论坛积分	4#
	gogonorman		16#
	havards		20#

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

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

作者: wangyong3552128 时间: 2008-2-29 20:05
标题: 测试人员如何面对频繁的版本变更？
在我们测试过程中发现自己所测试的版本频繁变更(很让人郁闷呀，刚测试过的还得要测试一遍，哈哈)，这在软件公司是很普遍的现象。那么我们怎么去控制或者避免研发人员去频繁的变更测试版本呢，首先我们要分析在软件公司产生这种不规范现象的原因：

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

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

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

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

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

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

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

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

作者: BenjaminCheung 时间: 2008-2-29 21:21
有关于软件质量我也来侃侃二句！详细见附件，谢谢！
不知可以从版主万小姐哪里拿多少51论坛多少分！（版主的名字我就不说了！

）

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

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

作者: yanzizhao1102 时间: 2008-3-1 15:37
标题: 不能根除只有百测不厌
(1)测试是与开发相辅相成的,有频繁的变更是对的.

(2)版本变更越快,说明开发的速率也越快,软件本身的更新也就越快.

(3)测试的本身就是不断的发现问题和修改问题的,所以我们要不要抱着测两次就完事的观点

(4)写好测试用例.不断的修改测试用例.这方面很重要,能避免不必要的时间浪费.

(5)一次通过是不可能的,要不厌其烦的,百测不厌的将测试进行到底

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

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

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

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

作者: liujun007 时间: 2008-3-2 11:12
因此提倡自动化测试

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

作者: gogonorman 时间: 2008-3-2 17:34
标题: 测试过程中如何应对频繁的版本变更?
我觉得测试团队作为产品质量的监控者，在这种情况下应该向项目的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 编辑 ]

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

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

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

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

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

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

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

作者: duola1119 时间: 2008-3-3 17:12
很支持20楼朋友的观点。

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

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

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

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

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

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

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

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

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

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

作者: lovemiya 时间: 2008-3-4 13:23
本人意见是尽可能多的在原始版本上进行测试，除非是遇到block的BUG，才更换至新的的版本。在新的版本中需要对修复后的bug进行详细的测试，包括与之有关联的相关模块。

最后，在说一句话，回归测试是一个很好解决版本经常更替的方法，至于作几轮，就要看各个资源配置情况和质量控制情况了！
谢谢！

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

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

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

作者: buzz 时间: 2008-3-4 13:50
标题: 测试过程中如何应对频繁的版本变更?
1、通过管理制度约束，要有明确的版本打回的考核制度，把版本打回次数与开发人员的考核指标挂钩，并有一定的惩罚措施，这样才能使开发提高提交版本的质量，从而使提交版本可测试。

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

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

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

作者: tiger_86 时间: 2008-3-4 14:46
还是那句老话：过程保证质量！
还是要做好过程的啊！

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

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

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

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

作者: 庖丁解牛 时间: 2008-3-4 16:26
测试过程如果只是测试执行过程，如果能够预见面对版本的频繁变更，测试执行策略应该做出弹性规划，或者跟更多的采用探索式的session based的测试。

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

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

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

作者: janedeng 时间: 2008-3-4 17:49
标题: 测试过程中如何应对频繁的版本变更?
现在让我们来假定频繁的版本变更已成事实。

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

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

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

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

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

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

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

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

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

作者: huior 时间: 2008-3-4 17:56
我的回答就在
http://www.51testing.com/?10851/ ... e_itemid_76216.html

作者: crazysusan 时间: 2008-3-4 20:34
使用版本控制管理软件,对产生的多个版本,有直观的掌握....

关注其它前辈的精彩回复...........

作者: 王爬爬 时间: 2008-3-4 22:07
1.首先在需求分析阶段，我们要对SRS进行充分的评估，并能使相关测试人员参与其中。并建立基线化。(这样能保证SRS上所反应的需求都能实现并可测。)
2.根据测试项优先级，按一定比例抽调部分测试用例进行预测试。如果没有达到预测试通过标准。不宜发布测试版本进行测试。(可以保证测试版本的可测姓)
3.其次在测试计划阶段，要明确系统测试的测试对象、系统测试的通过与失败标准、系统测试的挂起标准机恢复的必要条件。(解决大量用例堵塞无法测试)

作者: hcn302 时间: 2008-3-5 14:10
个人认为有效的应对版本频繁变更
要针对当前的具体情况，找出根本原因，找到合适的方案来解决。例如：1.若是配置管理工作做的不充分造成的新版本不是一个稳定的测试环境，造成测试阻塞。应先确保每天的配置部署正确无误，当然这又牵涉到相关工作的组织和管理。2.若是新需求测试和原来的功能测试造成的边修边改情况，应规范流程，做好计划安排，使开发÷测试工作正常有序进行。

作者: yifeiyu 时间: 2008-3-5 15:05
大家讨论得很激烈哦，呵呵，我的想法很简单，从管理开始，一步一步来。
每个公司都有自己适合的不同模式，也会遇到不一样的状况。
对于我现在所在的公司而言，我想先从管理开始吧

作者: 水印无痕 时间: 2008-3-5 15:06

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

需求变更会引起频繁的版本变更么？
事实上管理到位的话，即使是频繁的需求变更也和频繁的版本变更没有直接联系
如果你非要说6楼的帖子谈的就是如何应对频繁的版本变更问题的话那我也没办法了。。。

作者: eve_lincoin 时间: 2008-3-5 15:16
我们单位版本发布也很频繁
原因：
1.单位不做需求文档，程序由开发自主发挥，由于开发对需求的理解有限，往往是先做成demo类的程序，给客户，客户不通过，然后再修改
2.开发自己不做单元测试
3.测试拿到新版本，往往一点就出错，然后大部分的时间都用于等待新版本的发布，导致后面的流程无法进行
4.测试对需求的理解不够，由于没有完善的需求文档，只能按照显性的功能测试，有时隐形的功能也无法测试到，更无法提及隐形的需求
5.项目经理没有给予充分时间测试，导致很多复杂以及破坏性测试没有进行到，测试没有充分覆盖到每个程序
6.测试人员自身的水平问题
以上问题皆导致客户直接打电话来投诉有bug，或者不适用的情况，于是改了又改

作者: sqa1314 时间: 2008-3-5 15:17
控制版本的软件配置管理机制实际上就是一个软件配置管理存储库。版本控制提供了每一次软件变更的历史和可追溯性，包括谁做了什么变更、为什么做及什么时候做的等。
在软件生命周期中。软件组件（版本）不断地演化着，在某个特定的时点，每个组件都会达到一个相对稳定的状态。但当修改缺陷或实现增强功能时，就会导致组件新版本的产生。维护这些软件组件版本的过程就是版本的控制过程。
对每个软件组件都要进行标识，以区别于该组件的所有其他版本。当修改软件组件时，应该对新旧版本分别加以标识。因此，除了最初的那个版本，每个版本都有一个前驱版本。组件版本的连续性就代表了组件的历史和可追溯性。不同的版本也起到了备份的作用，使开发人员能够回到软件的早先版本。

作者: asking110 时间: 2008-3-5 15:23
标题: 回复 4# 的帖子
楼主《牛牛将军》说的好啊！现实工作中普遍是这样的！

作者: zhb329 时间: 2008-3-5 16:28
版本发布过于频繁首先是公司的流程还是规范没有很好的制定好。
针对版本发布频繁，可以针对性的做以下一些尝试：
1.版本发布的计划性，如果每周什么时候发版本，一周发几个版本？
2.版本进入测试的标准，什么样的版本符合测试的标准？如果不符合标准不允许发布。
3.制定比较好的测试计划，就算软件人员不停的发布版本，还是按照原计划进行全面测试，否则测试就无穷无尽。
4.测试和开发应该共同沟通，因为大家的目标一致，就是把项目做好，这是一个大的原则。

希望对楼主有点帮助。

作者: yamaya 时间: 2008-3-5 17:02
我觉得发版本之前由测试部门的组长对新版本进行猫冒烟测试，发现严重问题及时打回去，是比较直接有效的办法。

作者: charles 时间: 2008-3-5 17:23
1、制定合理的版本发布计划，并加强版本控制管理；
2、版本发布时有开发负责人编写详细的软件变更说明；
3、开发人员应该加强单元测试和冒烟测试；
4、测试部跟开发部协商拒绝测试的标准；
5、公司高层应该将软件版本发布的质量纳入部门绩效考核；
个人拙见，欢迎大家多提意见

作者: 3115702 时间: 2008-3-5 23:01
首先不可否认，研发人员的太多很大程度的影响了软件的质量。研发人员过分依赖测试人员，自身的单元测试不够充分。这样会导致程序开发初期，软件问题很多。而且不时的碰到影响系统流程的bug不得不中断测试。因此在系统开发初期频繁的版变更不可避免。
但在项目的整个开发过程中如果是由于需求变更而频繁变更版本，这样往往是由于前期需求分析不到位造成的，或者是由于客户需求不对挖掘而产生的新需求。这时候测试经理应该控制程序版本，保证系统在原有需求稳定的情况下，分版本对新增需求做增量的开发测试。

作者: zhaich 时间: 2008-3-6 09:51
看了大家的发言,我也说说我的看法.
大家的观点,大部分都是从测试人员的角度考虑.
但是,开发的产品除了要保证质量过关的前提下,还要保证能在第一时间推向市场.
这样,就很难避免测试人员跟着开发人员跑的现象.
所以,无法消除频繁的版本变更,
我们所能做的就是在发现bug的时候,第一时间与开发人员协调,解决bug.

作者: haohaoxuexi 时间: 2008-3-6 09:52
标题: 回复 47# 的帖子
呵呵，同感啊。
还有一种可能性，那就是开发人员很自觉地去完善程序，结果。。。。。。

作者: haohaoxuexi 时间: 2008-3-6 09:55

原帖由 charles 于 2008-3-5 17:23 发表
1、制定合理的版本发布计划，并加强版本控制管理；
2、版本发布时有开发负责人编写详细的软件变更说明；
3、开发人员应该加强单元测试和冒烟测试；
4、测试部跟开发部协商拒绝测试的标准；
5、公司高层应该将软件 ...

严重同意2、4、5点，同意1、3点

作者: haohaoxuexi 时间: 2008-3-6 10:15
标题: 回复 35# 的帖子
文中提到：
“一般还是要按照周期来做比较保险。新版本交付测试一个周期完成后再打包。当然这其中可能碰到一下阻碍测试
继续进行的问题可以适当处理，但是这个比例是要控制的。一般情况下如果交付测试的版本不能达到需求说明书中80%功能完成标准的我们还是应该坚决拒绝测试的。”
从文中来看，意思是先用未更新的包先测试一个周期以后再安排开发人员修改缺陷重新出包（排除阻碍测试
继续进行的问题的存在的情况下），可是如果在你测试的时候，开发人员刚好空闲就修改了bug，然后在修复这个bug的同时其实已经修复了很多关联的bug，而你如果不用新更新的包去测试，结果你费尽心思找出来的bug可能在新包中根本不会再出现了。我们强调的是问题及早修复，但是要经过一个周期以后才更新包，才去发现新问题，是不是有悖于这种想法？
另外“一般情况下如果交付测试的版本不能达到需求说明书中80%功能完成标准的我们还是应该坚决拒绝测试的”，在没有测试前，你怎么知道这个交付测试的版本不能达到需求说明书中80%功能完成标准的呢？是靠开发人员告诉你的还是可以通过什么方式判断的呢？
以上两点疑惑，还请各位大侠多多指点，谢谢了！

作者: 水上飘 时间: 2008-3-6 14:55
这个问题的确很常见也很伤脑筋的
做测试也有两年了，经常碰到这种情况，有时候感觉频繁的版本变更会让测试人员非常被动，整天跟着开发人员的屁股跑，累啊，而且郁闷
下面就个人经验就公司案例情况我谈谈导致频繁的版本变更的原因：
一、开发人员没有签入完全自己更新的代码，导致一些功能未能实现就发布新版本，而且导致一些基本功能走不通，整个基本流程走不下去。
二、开发人员进行版本升级和提交的时候没有进行基本的smoke test，基本功能都未实现，流程走不下去，所以导致要重新打回开发部继续等待新的版本提交。
三、开发团队没有合理的按计划进行开发，项目整体概念不是很强，比如安排一个星期计划做好的东西拖到两个多星期才完成，测试人员提交的级别高的BUG没有FIX就更新，导致测试人员不好进行工作，来回回归测试一些BUG，版本是一天几个，BUG没见完全处理完，这个就是项目经理的问题了，很头疼的
提出一些个人建议：
一、开发人员首先要保证打包的版本是最新的代码，细心检查自己的东西，做到代码完全签入再更新
二、项目经理要严格规范开发人员，smoke test一定要做到位，不要动不动就更新，每个版本的BUG要基本解决掉（可以遗留一些小问题到下一版本解决）才能更新版本。
三、需求变更要及时做出计划，合理安排项目进度，测试和开发配合要到位，测试环境一定要让测试人员来搭建，测试人员不同意更新就不要随便更新，

作者: 如夏之晴 时间: 2008-3-6 15:26
针对提出的问题:
1.版本本身存在缺陷
2.版本频繁更替
个人认为的解决办法:
1.版本本身问题太多,即第一轮测试中发现严重级别的bug数目太多,且是一些低级bug,测试人员有权将版本打回,重新完成单元测试.(我们这单元测试和后期的集成测试是分开的).其实公司就应该有这样一个体制.
2.对于版本更替,这要有一个强有力的保证版本的制度和bug管理体系.对于由于需求变更而引起的版本变更,应着重对新功能进行测试,然后正个版本再集成测试.对于已经提交的可测试版本的版本更替,应由测试人员掌控版本更替的时间.比如一轮测试完成后,开发人员应当把本轮测试过程中发现的bug基本全改完后,才可进行版本更替,否则测试效率低下.尽量建立测试人员的独立的测试环境,版本代码运用工具管理如vss等,保证工具中的代码是最新的,由测试人员取代码,部署测试环境.这样就有效的控制了版本的混乱问题.对于bug尽量采用工具管理,比较清晰,也便于分析,提高测试效率.

作者: cityyard 时间: 2008-3-6 15:34
标题: 回复 1# 的帖子
版本变更是我们测试中经常遇到的问题，版本变更一般有几方面的原因，首先是功能没有全部开发完，这种情况一般是比较复杂的功能先实现简单的，然后测试，同时作后续开发。另一种是新功能的引入，比如了解到了竞争对手的一些比较赢得用户的功能希望加入，再一个就是bug的修正。前两个可以看作是开发过程中的版本变更，后一个则是测试中的版本变更，这两者首先要隔离开。

我们可以通过cvs辅助管理来帮我们解决这个问题。首先当我们决定开始测试的时候，功能A已经完成，功能B还在开发中，这没有关系，我们把当前的测试版标记一个tag做成一个新的branch，比如function_test_A_0_0，而原来的分支我们叫做开发分支比如dev_branch_B_0_15之类的。注意目前function_test_A_0_0和dev_branch_B_0_15仅仅是名字不同，内容是一样的。

那么接下来开发人员和QA人员要做的事情就明确了。QA人员使用function_test_0_0来测试，发现的问题报告bug给开发人员，开发人员负责提交修改的代码，但是这个代码必须而且只能提交到测试分支function_test_0_0，并且必须保证每次修正一个bug每次提交都做成新的tag，比如修改了一个bug之后，tag名就应该变成function_test_0_1。QA组通过daily build的办法来每天获取测试分支的最新物件来及时测试开发人员的修改，这个build的频度也可以根据开发测试需要修改，比如半日build之类。这样一来我们就保证了这个分支我们做的仅仅是针对A功能的测试和修改，必须严禁开发人员提交自己的开发代码，哪怕是开发人员自己发现了bug，也必须首先上报bug，然后申请修改。

与此同时，开发人员可以在自己的开发分支上继续新功能的开发，他们的tag也不断增加。这个过程中，也可以把经过QA组承认的测试分支的重大bug修正代码merge到开发分支来，但是禁止从开发分支向测试分支的merge。

这样当QA组那边认为，测试分支的代码已经达到了一定的品质需求的时候。开发组可以经过和QA组负责人讨论之后，把测试分支的全部代码merge进入开发分支，并关闭测试分支。于是A功能的测试到此告一段落。

然后我们用把当前的开发分支，比如dev_branch_B_0_30，再做一个新的测试分支出来，比如function_test_B_0_0，新的循环就开始了。测试开发互不干扰，同时bug也能及时修正，修正的bug也可以及时反映在新代码中。

总之开发和测试是一个分离又统一的过程，分离在于新开发的不稳定的甚至不能跑通的代码不能来影响当前的测试，同时测试中发现的问题开发方能及时解决并交给QA确认，这样我认为是比较高效的。千万不能QA开发一起用一个版本分支，那样一定会乱的。

[ 本帖最后由 cityyard 于 2008-3-7 09:40 编辑 ]

作者: qingdou 时间: 2008-3-6 16:44
我觉得V-model是个很好的测试和开发交互的模型。
1、软件开发的需求分析阶段：开发人员获得并生成客户的需求说明书后，需要认真核对需求说明书是否完整和准确。这样可以确保开发人员开发的软件模型和客户需求不至于差得太远，也就是版主所说的频繁变更问题。
2、软件开发的代码生成阶段：开发人员在开发过程中应一个完成模块后尽早测试，保证该模块的正确性；并由单元测试-集成测试-系统测试依次完成。这时软件测试人员和开发人员的合作是很紧密的。
3、软件开发的质量保证阶段：软件第一版完成后，如果出现bug或者客户有新的要求等等，需要重新对相应模块进行修正，并进行回归测试。
偶的观点大概是这样的。
突然想起微软和Google的软件开发流程。一个是生成了一个软件版本后，通过投入给客户使用得到一系列的bug反馈，从而在第一个软件版本的基础上形成第二版、第三版……；而Google则是开发出一个基本的版本，

作者: qingdou 时间: 2008-3-6 16:46
我觉得V-model是个很好的测试和开发交互的模型。
1、软件开发的需求分析阶段：开发人员获得并生成客户的需求说明书后，需要认真核对需求说明书是否完整和准确。这样可以确保开发人员开发的软件模型和客户需求不至于差得太远，也就是版主所说的频繁变更问题。
2、软件开发的代码生成阶段：开发人员在开发过程中应一个完成模块后尽早测试，保证该模块的正确性；并由单元测试-集成测试-系统测试依次完成。这时软件测试人员和开发人员的合作是很紧密的。
3、软件开发的质量保证阶段：软件第一版完成后，如果出现bug或者客户有新的要求等等，需要重新对相应模块进行修正，并进行回归测试。
偶的观点大概是这样的。
突然想起微软和Google的软件开发流程。一个是生成了一个软件版本后，通过投入给客户使用得到一系列的bug反馈，从而在第一个软件版本的基础上形成第二版、第三版……；而Google则是开发出一个基本的版本，然后直接投放到网上让大众测试，感觉大众的参与频率更高，效果ms更好。
有点扯远了，毕竟微软和Google一个是做操作系统这样的大型软件，一个是做中小型软件，开发和测试的人员、资源管理是不同的。

作者: xiao小尾巴 时间: 2008-3-6 17:36
标题: 版本控制
1.预测很重要;
2.研发成型产品需要大致运行一遍功能点
3.测试计划和测试沟通很重要.融洽的团队,有利于工作.

作者: 六月的雪 时间: 2008-3-6 17:54
冒烟测试很重要

作者: gogonorman 时间: 2008-3-6 18:55
标题: 回复31#

原帖由 yayapang 于 2008-3-4 13:36 发表
1、测试从需求阶段开始介入。加入测试角色进行需求分析以及需求评审工作可以有效避免因为需求不清以及需求歧义导致的测试版本更新。
2、测试部分介入测试之前，开发团队需要提供一个可测试的基准版本。
3、测试 ...

我个人觉得，对于测试团队来说，主导（或者说是控制）版本的发布是一件很危险的事情．在实际的项目过程中，你获取了主导的权利，那么大家就会把相应的责任加在你身上（当然这没什么不对），以后产品发布或者相应的进度出了问题（出问题经常是难以避免的），项目的其他人（甚至是除了测试团队外的所有人）都会认为应该为此负责的人是测试团队，但是这绝对是不公平的，我个人觉得产品出了问题，开发团队和测试团队都有责任，甚至开发团队的责任可能应该更大些，但是因为产品的发布是你主导的（拍板，"say go!"的人是你），那么大家就会把大部分的责任都加到你身上，追究测试团队的责任，你将可能面临很大的压力．你可能保护不了自己，也保护不了团队的成员．

作者: chenyunjun169 时间: 2008-3-6 21:38
对于这个问题，我觉得首先应该分析清楚引起频繁的版本的原因是什么？我觉得有以下3种原因：
1. 客户方经常提出对需求的修改；
2. 开发前期的需求分析没有做好；
3. 开发提交的软件版本质量太差，达不到进行系统测试的标准；
针对以上3种可能的原因，相应的对策如下：
1. 如果是客户方经常提出对需求的修改，则可以与他们协商尽量在需求阶段提出，如果是在设计编码阶段提出，则
   应该明确需求的修改对测试有无影响，如果有大的影响则要拒绝此次修改，可以放到下一个版本中解决；如果没有
   大的影响，则可以修改，不过这样的变更次数要尽量少。
2. 如果是开发前期的需求分析没有做好，则要加强需求分析的质量，要对每一个需求的功能点都分析得很透彻。
3. 如果是开发提交的软件版本质量太差，则可以在软件系统正式进行系统测试时，先进行预测试，主要是对软件的
   基本功能点和核心功能进行测试，如果通不过，则不能进行正式的系统测试，这样就避免了出现边测边改、边改
   边测的现象。另外也可以在制定测试计划时，在测试挂起/恢复的条件中写明类似如“当测试发现的缺陷数量
   比较多，导致有40%以上的测试用例无法继续执行下去时，测试被挂起！”这样的标准，并且还要让开发经
   理、项目经理以及高层管理人员知道，这样当发生这样的情况时测试就不能继续执行下去。此外，进行系统
   测试时应该以一个版本为单位进行测试。
   以上是我个人的看法，如有不当之处，请大家指正，谢谢！

作者: comfort8 时间: 2008-3-7 09:23
标题: 下面说说频繁的版本变更问题：
下面说说频繁的版本变更问题：
1.制定项目计划不合理；
2.开发人员个人心理素质差；
3.开发人员技术还没有达到一定的水平；
4.开发人员做出来就升级，没有通过全面的测试；
5.开发人员对质量不是很严格，没有质量意识。

作者: apron 时间: 2008-3-7 11:30
标题: 测试过程中如何应对频繁的版本变更？
首先，版本变更，是要对变更的严重程度有所估计的
1. 需求变更，导致产品/项目出现彻头彻尾的一些变化

这种情况，理论上我们是要坚决杜绝的
这就需要做好最初期的需求工作
做需求的时候，测试组可以多确认几次
不能嫌麻烦，project manager说什么样就什么样
   test manager要有高度的积极性去一而再再而三的确认每一条细节
   把不可测不明确的需求扼杀在摇篮里

   但是，估计大家都会不可避免遇到这样的情况的，尤其是客户定制的一些项目
   客户是上帝啊，他们的想法有不可预见性
   很可能就在半年以后，突发奇想，给你来一个大逆转
   这个时候怎么办呢？
   我个人还真的没有什么好主意
   遇到这种情况，只能是整个项目组，包括测试组的人重新坐下来商量讨论一番
   确定这新增加新改动的需求对原来的进程有多大的影响
   进而视情况绝对如何处理
   如果影响不大，那好办，只要稍微的修正一下需求用例，然后按原计划进行
   如果影响很大，那可能就得重新制定开发测试计划了
   整个项目的进度表都要随之调整

2. bug修复导致的版本变更
   这种情况不可避免的
   我个人认为，应该有不少的公司都是这种边测边改的情况
   我倒觉得这样的情况不是什么坏事情
   我建议的做法是
   在合适的时机引入daily build（产品相对稳定，或者某些模块逐步完成，进入增    值式集成测试的时候）
   每天的测试都用新版本进行
   但是测试内容还是按照原定计划进行
   即，在第一遍测试没有完整的做完之前，不考虑任何回归
   当全面测试结束以后，再开始回归，验证bug的修复情况
   在回归过程中，一方面跑例行的功能自动化
   另一方面，验证bug（这是重点）
   回归也跟第一遍测试一样，以新版本为主
   但是在未完成完整的一遍回归之前，都是接着昨天的活往下干。。。

个人建议，仅供参考。。。

作者: 不要长大的小孩 时间: 2008-3-7 13:22
利用版本控制工具把，这个问题我也提出过，没有人解答。

自我觉得是需要利用工具来控制，分轮测试，一轮未进行完之前，赞不修改，以免边测边改，永无止境。

作者: funly 时间: 2008-3-7 15:50
1.在测试计划里明确进入和退出测试的准则
2.让冒险测试起到它因有的作用,基本功能不能实现有哪个基本功能不能实现都应该在冒险测试的时候发现,然后把问题汇总并提交到BUG管理系统定为最严重级别
3.冒险测试不通过的原因要追查到底,沟通不到位的原因还是人为不负责的作法所引起的.这些数据都可以是员工绩效考核提供参考并做一些处理.
4.某个版本的BUG数量修复太少(根据实际情况判断),做为测试管理者是不应该接受这种版本的
5.版本号变更太多,项目经理也是有很大的负责的,应该指针些问题在全项目组内开会分析问题,并把结果发给公司高层负责人或让其参加会议.

作者: lovemiya 时间: 2008-3-7 17:48

原帖由 51testing 于 2008-2-29 18:11 发表
       不少测试管理者都遇到过这样的问题：测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现、基本功能点出现缺陷导致大量测试用例堵塞无法进行、缺陷太多导致继 ...

我重新思考了这个问题,这个问题的关键在于版本的频繁更替,根源应该是在软件的版本控制方面中出现的问题.
应该遵循“提交->版本集成->集成测试->FIX版本->版本发布->版本备份->功能测试”。对每一个环节都要设置入口准则和出口准则,与软件的质量控制结合在一起!

作者: andison 时间: 2008-3-10 22:46
学习中！！

作者: longhu123 时间: 2008-3-11 11:15
标题: 提出自己的看法
我做测试还不到一年，谈谈心情！
看了前辈们的心得感受很深，有些情况跟我们公司的很类似。我做手机测试，一个项目已经脱了3个月了。但是好像没动静，我就这样天天抱着手机测啊测，我感觉没意思了。

产品经理也就记起来了就问我一下。说测试的怎么样了，项目经理也不管。改BUG也慢，成天不知道在干啥。我测的怎么样了。他也不问，成天改版本。改了好多了。但还是BUG多多啊。我有时候看不到希望。时间就在我手中流失了。希望前辈们看了我这帖子能给出回复！谢谢！

[ 本帖最后由 longhu123 于 2008-3-11 12:01 编辑 ]

作者: 兰兰 时间: 2008-3-13 15:27
标题: 我们项目组的做法：
在测试过程中，版本的频繁变化的确让测试人员头疼
尤其是在测试人员不充足，时间紧的情况下，开发人员提交的测试版本在没有进行单元测试就匆匆集成下发，导致测试人员在接到新的测试程序后，还没有运行几步就出现了致命性的错误，此时测试人员不得不打回开发人员进行修改，在下发－打回－修改－下发如此的反复循环，费时费力，而且还是测试只成了一种边缘性的测试，很难进行系统的测试。
我们项目组的做法是：每天都有开发组的专人负责下发保证可以正常化运行的版本，测试组人员在当日只测试这一个版本，如果发现错误统一提交到bug库，由开发人员统一进行修改，修改完后在统一下发版本，再进行测试，这样最起码可以保证每天的测试都有效。

作者: wo_cool 时间: 2008-3-14 17:08
每个阶段的基线控制没有做到位啊!!
个人认为不是管理问题是人的问题,开发自己要找原因,他找不到就全推给测试的,最后就进入堵塞了

作者: xhzhou_cll 时间: 2008-3-19 15:49
标题: 很受启发！
做测试做了几年了，在实际操作中，版本频繁变更的问题确实很常见！
今天看了这篇文章，深受启发，并将其载入到日志中了。希望对日后的工作有所帮助。

作者: 别叫我神 时间: 2008-3-24 09:39
好，，我又收获不少东东``

作者: vivian2008 时间: 2008-8-6 14:11
具体到当前这个项目遇到的情况，从上面的问题分析，我认为主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：

×在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；

×开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；

×每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；

×强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build Verification Test ），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；

×强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；

×强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。

×积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。

要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。

作者: vivian2008 时间: 2008-8-21 23:08
我认为有以下几个关键点：
1、在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；
2、开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；
3、每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；
4、强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build Verification Test ），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；
5、强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；
6、强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。
7、积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。
要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。

作者: lisa_zeng 时间: 2008-10-4 21:22

原帖由 布丁qhh 于 2008-3-1 15:28 发表
古人说对症下药，所以我们应该先找出出现频繁版本变更这种现象的原因，从根本上解决问题：
本人思考原因有下：
1.需求写得粗糙，需求分析的工作没有做好，很多隐藏的需求更甚至是显示的需求都没有考虑到，导致开发人员设计的代码有局限性，以致于测试时总是出现问题，总是返工再测试。

我现在也有这样的体会。需求分析没有做好，详细设计没有做到对开发应该重视的地方进行描述或者没有描述。问题在开发过程中不会被暴露，却会在测试过程中很容易发现。
尤其是在集成测试的时候。

感觉是，各个环节都做到认真考虑，到测试的时候，出现反功频繁修改开发的情况就会减少。

作者: 乘风摘月 时间: 2008-10-29 20:16
使得本该完整的测试过程变成了边测边改、边改边测，不仅使测试进度无法按计划进行，
支持！！说的好！！

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