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

版本变更是我们测试中经常遇到的问题，版本变更一般有几方面的原因，首先是功能没有全部开发完，这种情况一般是比较复杂的功能先实现简单的，然后测试，同时作后续开发。另一种是新功能的引入，比如了解到了竞争对手的一些比较赢得用户的功能希望加入，再一个就是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 编辑 ]

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

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

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

冒烟测试很重要

引用:

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

我个人觉得，对于测试团队来说，主导（或者说是控制）版本的发布是一件很危险的事情．在实际的项目过程中，你获取了主导的权利，那么大家就会把相应的责任加在你身上（当然这没什么不对），以后产品发布或者相应的进度出了问题（出问题经常是难以避免的），项目的其他人（甚至是除了测试团队外的所有人）都会认为应该为此负责的人是测试团队，但是这绝对是不公平的，我个人觉得产品出了问题，开发团队和测试团队都有责任，甚至开发团队的责任可能应该更大些，但是因为产品的发布是你主导的（拍板，"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.版本号变更太多,项目经理也是有很大的负责的,应该指针些问题在全项目组内开会分析问题,并把结果发给公司高层负责人或让其参加会议.

引用:

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

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

学习中！！

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

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

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

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

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

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