测试过程中版本频繁变更，在各软件公司，特别是软件开发过程不规范的项目组中是很普遍的现象，大大增加了测试人员的工作量，而开发人员也叫苦不迭。那么该如何避免这种情况呢，以下列出几个较常见的问题原因及解决办法：
       一、由于部分开发人员没有及时更新在svn上的文件，导致编译打包的内容不是最新更改过的代码。这需要开发养成习惯，保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等。
       二、开发人员和测试人员进行版本升级的时候，没有进行质量把关，结果最基本的功能都未实现。要解决这个问题，最好从流程上入手，建立起每日构建的制度，构建过程最好能自动进行，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统，并且强化冒烟测试（Smoke testing），及时对每一个build的基本功能点进行验证（Build Verification Test）。在此基础上，建立起测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，测试部就要测试，测试部需要跟开发部协商拒绝测试的标准。比如把测试分级，一个版本的提交，通过几个级别的测试，然后再确定是否全面投入测试，没有达到准入条件的一律打回处理，不能浪费更多的时间测试一个不可测试的版本。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的。
       三、由于产品初期测试的时候，肯定是问题多发期，这个时候测试人员没有和开发人员保持时刻的沟通，导致问题不能得到及时的解决。其实不管是什么测试阶段，在条件允许的情况下，测试人员都需要保证和开发人员的及时沟通，以求尽快的解决问题。可以通过使用BUG管理工具，例如devtrack，QC等，保证bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。综上，可以通过建立一套完整的、规范的开发过程把风险和影响降到最低，但最终的根本还在于整个研发团队的质量意识和团队精神，这两方面都比较强的话，再加以健全的流程和制度，包括这个问题在内的许多问题都可以迎刃而解了。