`
vipshichg
  • 浏览: 260867 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

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

    博客分类:
  • java
阅读更多
 软件开发流程中,测试环境是不可或缺的,那涉及到的问题包括,需要多少个环境、分别做什么用,有了环境就要考虑如何部署,部署的时候如何做到版本控制,要保证测试人员进行有效的测试,减少测到一半不能测的情况或者说完全测不下去的情况,相信谁都不愿看到工作被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说,现在的情况不能进入新功能的开发,或者是不能进入下一个环境,不然只会让项目越来越糟,肯定无法按期交付。这里又补充到了一个规范标准的定义,这其实是应该是制定在测试计划中的,每个阶段或者每次大型测试之前都应制定相应的计划,来衡量测试的结果是否达到预期,是否可以进行后续开发。
6
1
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics