对测试版本的控制也是很多公司不太重视的一个点，一般测试版本都是由开发人员发布的，而一个项目往往有好多开发，当每个人可以发布测试版本时，这时候往往会产生问题，导致测试人员因为版本问题做了重复和没必要的测试。
举个测试中经常遇到问题的例子：
一个bug修复验证通过之后又重现了，那很有可能就是某个开发人员修复bug的代码被其他开发人员的旧代码给覆盖了，如果经常会有这种情况那测试真的要累死了。
不知道什么时候修复的bug又出现了，运气好发现了至少还能解决，就怕最后没发现带着上线了，这种情况测试真的要背锅了（所以上线前需要做一个完整的测试，并且把之前的bug都再验证一遍，这个之后也会将流程优化也会讲到），所以做好测试版本的控制是非常重要的。还是那个意思，要将可能出现影响测试的因素统统扼杀在摇篮里。
那么问题来了，怎么样才能对测试版本进行有效的控制呢？
最好的办法肯定是由测试负责人进行测试版本的发布，开发只有提交代码的权限，然后由测试负责人同步最新的代码库，最后确定好都是最新的代码再进行发布。这样既可以控制测试环境的代码质量，还可以知道这个版本修复了哪些问题从而进行有效的bug验证。不仅如此，还能保证测试环境和版本的稳定，从而在测试中不会因为开发发布版本而打断测试，可谓一举多得。
当然如果测试没有发布版本，也不会管理代码库的权限。那就只能要求开发给一个负责人发布权限，所有的发布都是由他完成，这样也可以规避版本混乱的问题，缺点只是得配合他有空的时候才能发布，但这也算退而求其次的选择了。
如果由于种种原因上面2种都无法实现的话，那就只能约束相关的开发人员规范发布的步骤，即提交代码之前先同步最新的代码，然后再提交新的代码，最后完成发布。即便如此如果开发之间没有沟通好，同时提交代码或者同时发布了测试版本，那么还是会出问题的，只是相对来说会稍微好点，迫不得已的最差选择了。
所以可以看出最好还是需要测试人员（不仅是负责发布的测试人员）学习SVN、VSS、GIT等代码管理工具，然后独立进行测试版本的发布和控制。虽然有学习的成本，但从长远来说还是有利于减少测试不必要的工作和加班，同时也提高了测试自身的技能。