第一天建立博客，还没一下想好写什么又不想让这里空着，就把我刚参与的每周一问贴过来吧，算作我在这里的第一个印记，希望以后这里将成为我和大家交流测试心得的地方。

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