项目总结—敏捷测试中多环境如何做到版本控制

　软件开发流程中，测试环境是不可或缺的，那涉及到的问题包括，需要多少个环境、分别做什么用，有了环境就要考虑如何部署，部署的时候如何做到版本控制，要保证测试人员进行有效的测试，减少测到一半不能测的情况或者说完全测不下去的情况，相信谁都不愿看到工作被Block住。

　　环境这个东西尽量不要搞得太多，执行的人记不住，也會導致推一個版本需要很長的時間；太少也不好，环境混杂的話，测试没有办法测试，开发没有办法调试也很麻烦。另外，测试环境需要有套干净的环境。两个层面，一个是测试数据需要是干净的，符合业务逻辑的；另一个是只有测试可以动到环境，开发不能在上面调试。严格意义上来说，我经历的第一个项目，环境管控的很好，任何环境开发都是不会上去调试的，大家都有自己的调试环境。那你可能会问，有些特定数据产生的问题就要去测试环境调试啊，那我们应该把DB分开，开发人员有自己的库，测试环境固定为1～2个库，有需要调试的时候就换到测试环境的库。这样应该是更合理的做法。

　　這里同樣有不同项目需要不同考量的情况。举例来说，如果只是單方開發的項目，从版本上说基本上有個HEAD版本、BRANCH版本就好，如果再有其他测试用途可以再架其他的环境，例如Performance，因为会有不同的需要；如果是多方共同開發的項目，那可能就需要说有alpha、beta，不仅是单方的alpha、beta，还要分alpha(beta) for one side & alpha(beta) for both sides(这里我持保留意见，因为alpha env. for both sides integration的意义并不大，因为能串接的功能实在有限)。但从测试的角度，无论是alpha、beta、HEAD或是Branch，基本的要求都应是开发人员不能碰到的，为什么？因为开发应该有自己的环境起个服务，把包装一下就可以调试了。另外还牵扯到一个问题，客户的要求是什么？所以除了满足基本原则外，还要在项目开始之前与客户达成一致的标准，这些事情不要在后面再干扰到项目进程。

　　需要多少环境、分别做什么用的部分商榷好後就要来讨论，如何做到可以快速的推版本到某个環境进行测试。同样有两个层面的意思，一个是推到某个环境，一个是保证质量。如果项目上通过持续集成开发来进行项目管理，第一个问题就很好解决，只要点一下Run job就好。解決第二个問題才是关键。只有质量有保障了之后才可以推出去进行Regression。其实这个问题的本質應該是代碼質量要有所保證，有完善的unit test、automation testing，每個bug fix或者feature change经过pair review才commit，开发人员对自己负责的功能在自己的开发环境上测试过才commit code，才能以最快的速度deploy，進行smoke testing，再部署到下一个环境進行regression testing。

　　先简单说下持续集成(CI: Continuous Integration)，我接触过的两个工具一个是CruiseControl，一个是Hudson(Jenkins)。持续集成的理念是每个开发人员在本地开发所负责的功能过程中，commit code到代码版本库(例如，SVN)，这个commit应尽量以小单位进行，而不是所有功能开发完之后才提交。通过配置job进行unit test、代码规范性检查通过後(一般情况下job状态为蓝灯)，再进行打包，例如java的项目可能是打war或是jar包。若无特别的情况就可以进行deploy了，基本上这之前都会有环境依赖的相关job，例如需要什么依赖包啊之类的。谁来执行部署等一些工作呢，可能是maven、ant或者是make等等，这部分的选取也是通过项目本身情况考虑了。通过持续集成是可以很好的管理你的项目，让项目在进入测试之前就具有良好的品质的，当然这取决于项目从一开始就秉承测试先行的理念，每个function都要有Unit Test。要让Unit Test发挥它的价值，不是为了单元测试而写单元测试，不然就等于浪费时间。至于CI这部分如果我有能力稍後再sharing出来吧

　　既然有CI，有Unit Test，有pair review这几道关理论上应该就能很好的保证代码质量，为快速部署一个可测试的版本提供保障。其他的工作就要看测试怎么做了。例如在HEAD或Alpha环境上如何进行测试，何时可以进入到下一个环境等等。之前我经历的项目会定义一个code freeze date，在这个时间点必须切一个Branch出来，部署到branch的环境上进行测试，但这样的执行方式应该是运行的比较好的项目，可以控制好这个时间。但如果项目紧、需求变更多这种方式就不适用，需要灵活处理。比如说，HEAD或者ALPHA环境上的版本基本上还都处于开发阶段，大部分情况是没有办法把大流程走下去的，没有办法进行regression testing，所以alpha上为了验证版本是否可用，可以进行smoke testing，如果遇到版本很不好的情况，该拒绝测试就要拒绝测试。但这里有个矛盾点，当发现了大问题之后就停止测试的话，可能有潜藏的大问题并未被发现、修改，下个版本还是存在，那可能就会造成反复工作量，所以这里我还是建议说可以完整的进行完smoke之后把整体情况反馈给开发。在相应模块流程调通、功能趋于稳定之后再进行regression testing。趋于稳定可以从两个方面获得，一个是新bug的产生率，二个是P1，P2 bug的close情况。这也牵扯到了测试开始之前定义的标准，例如Entry criteria & Exit criteria。符合了定义好的标准之后才可以进入到测试下一阶段，同样下一个环境或者阶段也应该达到相应标准之后才可以进入。

　　从这个角度来说，我觉得如果PM看不到这个情况或在项目很紧的时候，测试应该有这样的power说，现在的情况不能进入新功能的开发，或者是不能进入下一个环境，不然只会让项目越来越糟，肯定无法按期交付。这里又补充到了一个规范标准的定义，这其实是应该是制定在测试计划中的，每个阶段或者每次大型测试之前都应制定相应的计划，来衡量测试的结果是否达到预期，是否可以进行后续开发。