http://www.51testing.com/?10851/action_viewspace_itemid_76216.html 使用版本控制管理软件,对产生的多个版本,有直观的掌握....:)
关注其它前辈的精彩回复...........:victory: 1.首先在需求分析阶段，我们要对SRS进行充分的评估，并能使相关测试人员参与其中。并建立基线化。(这样能保证SRS上所反应的需求都能实现并可测。)
2.根据测试项优先级，按一定比例抽调部分测试用例进行预测试。如果没有达到预测试通过标准。不宜发布测试版本进行测试。(可以保证测试版本的可测姓)
3.其次在测试计划阶段，要明确系统测试的测试对象、系统测试的通过与失败标准、系统测试的挂起标准机恢复的必要条件。(解决大量用例堵塞无法测试) 个人认为有效的应对版本频繁变更
要针对当前的具体情况，找出根本原因，找到合适的方案来解决。例如：1.若是配置管理工作做的不充分造成的新版本不是一个稳定的测试环境，造成测试阻塞。应先确保每天的配置部署正确无误，当然这又牵涉到相关工作的组织和管理。2.若是新需求测试和原来的功能测试造成的边修边改情况，应规范流程，做好计划安排，使开发÷测试工作正常有序进行。 大家讨论得很激烈哦，呵呵，我的想法很简单，从管理开始，一步一步来。
每个公司都有自己适合的不同模式，也会遇到不一样的状况。
对于我现在所在的公司而言，我想先从管理开始吧:) 原帖由 haohaoxuexi 于 2008-3-4 12:19 发表 http://bbs.51testing.com/images/common/back.gif
to Ls，人家的题目是如何应对频繁的版本变更，需求变更很容易引起频繁的版本变更，所以至少我认为上面的回帖有不止一个人说的是需求变更是没有问题的，偶实在不太赞成你说人家“作为一个测试工作者居然那么不仔细。。 ...
需求变更会引起频繁的版本变更么？
事实上管理到位的话，即使是频繁的需求变更也和频繁的版本变更没有直接联系
如果你非要说6楼的帖子谈的就是如何应对频繁的版本变更问题的话那我也没办法了。。。 我们单位版本发布也很频繁
原因：
1.单位不做需求文档，程序由开发自主发挥，由于开发对需求的理解有限，往往是先做成demo类的程序，给客户，客户不通过，然后再修改
2.开发自己不做单元测试
3.测试拿到新版本，往往一点就出错，然后大部分的时间都用于等待新版本的发布，导致后面的流程无法进行
4.测试对需求的理解不够，由于没有完善的需求文档，只能按照显性的功能测试，有时隐形的功能也无法测试到，更无法提及隐形的需求
5.项目经理没有给予充分时间测试，导致很多复杂以及破坏性测试没有进行到，测试没有充分覆盖到每个程序
6.测试人员自身的水平问题
以上问题皆导致客户直接打电话来投诉有bug，或者不适用的情况，于是改了又改 控制版本的软件配置管理机制实际上就是一个软件配置管理存储库。版本控制提供了每一次软件变更的历史和可追溯性，包括谁做了什么变更、为什么做及什么时候做的等。
在软件生命周期中。软件组件（版本）不断地演化着，在某个特定的时点，每个组件都会达到一个相对稳定的状态。但当修改缺陷或实现增强功能时，就会导致组件新版本的产生。维护这些软件组件版本的过程就是版本的控制过程。
对每个软件组件都要进行标识，以区别于该组件的所有其他版本。当修改软件组件时，应该对新旧版本分别加以标识。因此，除了最初的那个版本，每个版本都有一个前驱版本。组件版本的连续性就代表了组件的历史和可追溯性。不同的版本也起到了备份的作用，使开发人员能够回到软件的早先版本。
回复 4# 的帖子
楼主 《牛牛将军》说的好啊！现实工作中普遍是这样的 ！ 版本发布过于频繁首先是公司的流程还是规范没有很好的制定好。针对版本发布频繁，可以针对性的做以下一些尝试：
1.版本发布的计划性，如果每周什么时候发版本，一周发几个版本？
2.版本进入测试的标准，什么样的版本符合测试的标准？如果不符合标准不允许发布。
3.制定比较好的测试计划，就算软件人员不停的发布版本，还是按照原计划进行全面测试，否则测试就无穷无尽。
4.测试和开发应该共同沟通，因为大家的目标一致，就是把项目做好，这是一个大的原则。
希望对楼主有点帮助。 我觉得发版本之前由测试部门的组长对新版本进行猫冒烟测试，发现严重问题及时打回去，是比较直接有效的办法。 1、制定合理的版本发布计划，并加强版本控制管理；
2、版本发布时有开发负责人编写详细的软件变更说明；
3、开发人员应该加强单元测试和冒烟测试；
4、测试部跟开发部协商拒绝测试的标准；
5、公司高层应该将软件版本发布的质量纳入部门绩效考核；
个人拙见，欢迎大家多提意见 首先不可否认，研发人员的太多很大程度的影响了软件的质量。研发人员过分依赖测试人员，自身的单元测试不够充分。这样会导致程序开发初期，软件问题很多。而且不时的碰到影响系统流程的bug不得不中断测试。因此在系统开发初期频繁的版变更不可避免。
但在项目的整个开发过程中如果是由于需求变更而频繁变更版本，这样往往是由于前期需求分析不到位造成的，或者是由于客户需求不对挖掘而产生的新需求。这时候测试经理应该控制程序版本，保证系统在原有需求稳定的情况下，分版本对新增需求做增量的开发测试。 看了大家的发言,我也说说我的看法.
大家的观点,大部分都是从测试人员的角度考虑.
但是,开发的产品除了要保证质量过关的前提下,还要保证能在第一时间推向市场.
这样,就很难避免测试人员跟着开发人员跑的现象.
所以,无法消除频繁的版本变更,
我们所能做的就是在发现bug的时候,第一时间与开发人员协调,解决bug.
回复 47# 的帖子
呵呵，同感啊。还有一种可能性，那就是开发人员很自觉地去完善程序，结果。。。。。。:L 原帖由 charles 于 2008-3-5 17:23 发表 http://bbs.51testing.com/images/common/back.gif
1、制定合理的版本发布计划，并加强版本控制管理；
2、版本发布时有开发负责人编写详细的软件变更说明；
3、开发人员应该加强单元测试和冒烟测试；
4、测试部跟开发部协商拒绝测试的标准；
5、公司高层应该将软件 ...
严重同意2、4、5点，同意1、3点
回复 35# 的帖子
文中提到：“一般还是要按照周期来做比较保险。新版本交付测试一个周期完成后再打包。当然这其中可能碰到一下阻碍测试
继续进行的问题可以适当处理，但是这个比例是要控制的。一般情况下如果交付测试的版本不能达到需求说明书中80%功能完成标准的我们还是应该坚决拒绝测试的。”
从文中来看，意思是先用未更新的包先测试一个周期以后再安排开发人员修改缺陷重新出包（排除阻碍测试
继续进行的问题的存在的情况下），可是如果在你测试的时候，开发人员刚好空闲就修改了bug，然后在修复这个bug的同时其实已经修复了很多关联的bug，而你如果不用新更新的包去测试，结果你费尽心思找出来的bug可能在新包中根本不会再出现了。我们强调的是问题及早修复，但是要经过一个周期以后才更新包，才去发现新问题，是不是有悖于这种想法？
另外“一般情况下如果交付测试的版本不能达到需求说明书中80%功能完成标准的我们还是应该坚决拒绝测试的”，在没有测试前，你怎么知道这个交付测试的版本不能达到需求说明书中80%功能完成标准的呢？是靠开发人员告诉你的还是可以通过什么方式判断的呢？
以上两点疑惑，还请各位大侠多多指点，谢谢了！ 这个问题的确很常见也很伤脑筋的
做测试也有两年了，经常碰到这种情况，有时候感觉频繁的版本变更会让测试人员非常被动，整天跟着开发人员的屁股跑，累啊，而且郁闷
下面就个人经验就公司案例情况我谈谈导致频繁的版本变更的原因：
一、开发人员没有签入完全自己更新的代码，导致一些功能未能实现就发布新版本，而且导致一些基本功能走不通，整个基本流程走不下去。
二、开发人员进行版本升级和提交的时候没有进行基本的smoke test，基本功能都未实现，流程走不下去，所以导致要重新打回开发部继续等待新的版本提交。
三、开发团队没有合理的按计划进行开发，项目整体概念不是很强，比如安排一个星期计划做好的东西拖到两个多星期才完成，测试人员提交的级别高的BUG没有FIX就更新，导致测试人员不好进行工作，来回回归测试一些BUG，版本是一天几个，BUG没见完全处理完，这个就是项目经理的问题了，很头疼的
提出一些个人建议：
一、开发人员首先要保证打包的版本是最新的代码，细心检查自己的东西，做到代码完全签入再更新
二、项目经理要严格规范开发人员，smoke test一定要做到位，不要动不动就更新，每个版本的BUG要基本解决掉（可以遗留一些小问题到下一版本解决）才能更新版本。
三、需求变更要及时做出计划，合理安排项目进度，测试和开发配合要到位，测试环境一定要让测试人员来搭建，测试人员不同意更新就不要随便更新， 针对提出的问题:
1.版本本身存在缺陷
2.版本频繁更替
个人认为的解决办法:
1.版本本身问题太多,即第一轮测试中发现严重级别的bug数目太多,且是一些低级bug,测试人员有权将版本打回,重新完成单元测试.(我们这单元测试和后期的集成测试是分开的).其实公司就应该有这样一个体制.
2.对于版本更替,这要有一个强有力的保证版本的制度和bug管理体系.对于由于需求变更而引起的版本变更,应着重对新功能进行测试,然后正个版本再集成测试.对于已经提交的可测试版本的版本更替,应由测试人员掌控版本更替的时间.比如一轮测试完成后,开发人员应当把本轮测试过程中发现的bug基本全改完后,才可进行版本更替,否则测试效率低下.尽量建立测试人员的独立的测试环境,版本代码运用工具管理如vss等,保证工具中的代码是最新的,由测试人员取代码,部署测试环境.这样就有效的控制了版本的混乱问题.对于bug尽量采用工具管理,比较清晰,也便于分析,提高测试效率.
回复 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 编辑 ]
