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

我的回答就在
[url]http://www.51testing.com/?10851/action_viewspace_itemid_76216.html[/url]

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

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

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

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

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

[quote]原帖由 [i]haohaoxuexi[/i] 于 2008-3-4 12:19 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=891661&ptid=107290][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
to Ls，人家的题目是如何应对频繁的版本变更，需求变更很容易引起频繁的版本变更，所以至少我认为上面的回帖有不止一个人说的是需求变更是没有问题的，偶实在不太赞成你说人家“作为一个测试工作者居然那么不仔细。。 ... [/quote]

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

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

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

回复 4# 的帖子

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

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

希望对楼主有点帮助。

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

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

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

dadadsad

dadadada

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

回复 47# 的帖子

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

[quote]原帖由 [i]charles[/i] 于 2008-3-5 17:23 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=893514&ptid=107290][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
1、制定合理的版本发布计划，并加强版本控制管理；
2、版本发布时有开发负责人编写详细的软件变更说明；
3、开发人员应该加强单元测试和冒烟测试；
4、测试部跟开发部协商拒绝测试的标准；
5、公司高层应该将软件 ... [/quote]

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

回复 35# 的帖子

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

你解决问题了吗？

[quote]原帖由 [i]gogonorman[/i] 于 2008-3-2 17:34 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=890240&ptid=107290][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
我觉得测试团队作为产品质量的监控者，在这种情况下应该向项目的stake holder（比如project manager）提供详细的数据，比如目前能测试的feature的比例，被阻塞的feature和test cases的比率等，让他们了解目前release ... [/quote]

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

这个问题的确很常见也很伤脑筋的
做测试也有两年了，经常碰到这种情况，有时候感觉频繁的版本变更会让测试人员非常被动，整天跟着开发人员的屁股跑，累啊，而且郁闷
下面就个人经验就公司案例情况我谈谈导致频繁的版本变更的原因：
一、开发人员没有签入完全自己更新的代码，导致一些功能未能实现就发布新版本，而且导致一些基本功能走不通，整个基本流程走不下去。
二、开发人员进行版本升级和提交的时候没有进行基本的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开发一起用一个版本分支，那样一定会乱的。

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

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

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

版本控制

1.预测很重要;
2.研发成型产品需要大致运行一遍功能点
3.测试计划和测试沟通很重要.融洽的团队,有利于工作.

冒烟测试很重要

回复31#

[quote]原帖由 [i]yayapang[/i] 于 2008-3-4 13:36 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=891739&ptid=107290][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
1、 测试从需求阶段开始介入。加入测试角色进行需求分析以及需求评审工作可以有效避免因为需求不清以及需求歧义导致的测试版本更新。
2、 测试部分介入测试之前，开发团队需要提供一个可测试的基准版本。
3、 测试 ... [/quote]

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

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

下面说说频繁的版本变更问题：

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

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

首先，版本变更，是要对变更的严重程度有所估计的
1. 需求变更，导致产品/项目出现彻头彻尾的一些变化

    这种情况，理论上我们是要坚决杜绝的
    这就需要做好最初期的需求工作
    做需求的时候，测试组可以多确认几次
    不能嫌麻烦，project manager说什么样就什么样
     test manager要有高度的积极性去一而再再而三的确认每一条细节
     把不可测不明确的需求扼杀在摇篮里
     
     但是，估计大家都会不可避免遇到这样的情况的，尤其是客户定制的一些项目
     客户是上帝啊，他们的想法有不可预见性
     很可能就在半年以后，突发奇想，给你来一个大逆转
      这个时候怎么办呢？
      我个人还真的没有什么好主意
      遇到这种情况，只能是整个项目组，包括测试组的人重新坐下来商量讨论一番
       确定这新增加新改动的需求对原来的进程有多大的影响
       进而视情况绝对如何处理
       如果影响不大，那好办，只要稍微的修正一下需求用例，然后按原计划进行
       如果影响很大，那可能就得重新制定开发测试计划了
       整个项目的进度表都要随之调整

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


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

利用版本控制工具把，这个问题我也提出过，没有人解答。

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

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

[quote]原帖由 [i]51testing[/i] 于 2008-2-29 18:11 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=889622&ptid=107290][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
       不少测试管理者都遇到过这样的问题：测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现、基本功能点出现缺陷导致大量测试用例堵塞无法进行、缺陷太多导致继 ... [/quote]

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

学习中！！:) :)

提出自己的看法

我做测试还不到一年，谈谈心情！
看了前辈们的心得感受很深，有些情况跟我们公司的很类似。我做手机测试，一个项目已经脱了3个月了。但是好像没动静，我就这样天天抱着手机测啊测，我感觉没意思了。:([size=4]产品经理也就记起来了就问我一下。说测试的怎么样了，项目经理也不管。改BUG也慢，成天不知道在干啥。我测的怎么样了。他也不问，成天改版本。改了好多了。但还是BUG多多啊。我有时候看不到希望。时间就在我手中流失了。希望前辈们看了我这帖子能给出回复！谢谢！[/size]

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

我们项目组的做法：

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

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

很受启发！

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

好，，我又收获不少东东``

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

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

×开发部使用版本控制工具，比如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走势和工作量等。

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

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