关于测试环境版本管理(对于冲突文件)

平常开小组例会时，大家提及最多的就是测试环境版本管理，经常听到某个功能的程序被其它更新文件覆盖，导致测试无法进行。开发人员经查找原因后，发现文件被其它人覆盖。这种原因引起的程序无法跑通是让开发人员比较懊恼，不仅担误测试时间和进度，也影响开发人员工作心情。这个问题确实挺复杂，在目前客观的软件作坊环境下还真难解决，特别是对于行业软件维护性项目。以下环境所说，也基于运维式项目。

目前环境分为开发环境，测试环境，大版本测试环境，UAT环境，升级接收环境。解释下，开发环境主要是面向开发组，测试环境主要是面向测试组测试各种测试任务，大版本测试环境基于每个月的升级大版本测试，UAT环境主要是面向业务部门验收需求环境，升级接收环境，主要是提供升级包，在上正式环境前，在接收环境上进行验证升级包版本。

对于开发和测试人员来说，关注更多的是测试环境。如果按照理论化和理想化的情况，推演下场景。开发人员提交测试申请到开发组长，附件为文件清单和相关需求和设计文档。开发组长审核过后，发送邮件给版本管理人员。版本管理人员根据接收文件，到配置库提取升级文件，打包成升级包，发邮件给测试环境管理人员。测试环境管理人员根据升级包，更新测试环境，并通知测试人员，开发人员环境已更新，可以进行测试。这个场景遇到什么现实问题呢?

[@more@]

1、 需要配置专门的版本管理人员和测试环境管理人员。在目前的软件开发情况，这个人员配置是否能达到。

2、 目前相应测试任务很多，频率很高。一个人员根据文件清单取文件，是否来得及？是否能保证升级包质量。

3、 目前各种需求时间并发性比较高，对于冲突文件，版本管理人员如何进行判断？一般版本管理人员没有参预过开发。

4、 程序开发质量不高，遇到问题修改文件，经过几道工序，是否会引起更多的时间浪费。是否会延长缺陷解决的时间和测试进度。

也正因为这些现实问题，目前的测试环境并没有控制权限，还是由各开发人员整理自己程序包，更新测试环境。以前想把文件更新权限放到开发组长身上。但通长开发组长本身也很忙，也会引起很多问题。但因为开发人员自己更新环境，各个需求的程序耦合度比较高，也因为各开发组缺乏沟通，导致一些常用文件被误覆盖。

对测试环境的管理，目前也没有想到什么好的管理方式。初步想法是在配置库上建立一个程序更新目录，开发人员每次更新程序时，都要放到该目录。下次开发人员放上程序时，对于有冲突文件，要进行合并，然后进行更新。这个过程遇到的问题也是工作量比较大。

对于目前的实际开发情况，也只能在现有基础上进行逐步改进。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21327621/viewspace-1022343/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21327621/viewspace-1022343/