我的回答就在
http://www.51testing.com/?10851/ ... e_itemid_76216.html

使用版本控制管理软件,对产生的多个版本,有直观的掌握....

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

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

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

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

引用:

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

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

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

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

楼主 《牛牛将军》说的好啊！现实工作中普遍是这样的 ！

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

希望对楼主有点帮助。

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

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

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

dadadada

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

呵呵，同感啊。
还有一种可能性，那就是开发人员很自觉地去完善程序，结果。。。。。。

引用:

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

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

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

引用:

原帖由 gogonorman 于 2008-3-2 17:34 发表
我觉得测试团队作为产品质量的监控者，在这种情况下应该向项目的stake holder（比如project manager）提供详细的数据，比如目前能测试的feature的比例，被阻塞的feature和test cases的比率等，让他们了解目前release ...

再在这里顶一下这个回复。
很多朋友在这里都指出了出现版本等问题发生的原因，但是很少有人针对这个目前的状况来给个很好的solution。
一般都是问题发生了之后，才知道找原因，但是不是找了原因就对当前的问题有所帮助了呢？
原因估计大家都能说出一二，但是重点我认为是：
解决问题！

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