测试过程中发现的bug提交给开发人员，开发人员在对提交的bug进行修改，bug修改后开发人员会将修改后的代码放入当前的软件版本之中，导致软件测试版本发布过于频繁，测试版本不稳定，导致修改过的bug再次出现，测试重复、失效和混乱。测试进度无法保证，同时不便于追溯跟踪问题。 原因是：对于修改过的代码，不能够保证他们一定是正确的，很可能在开发人员修改过之后，仍然是错误的，或者在修改过之后仍然会给软件带来别的问题，测试人员对新提交的代码以及之前的代码都要再次进行验证，进行排错，来确保不会因此而带来新的隐患，新的漏洞，导致大量重复测试。 引入版本控制的好处：提高开发和测试的效率，提高软件版本稳定性，便于追溯问题。
1、版本控制对象： 开发提交给测试的产品版本。 测试人员提交的bug到了开发人员手中之后，开发人员针对这些bug进行修复工作，并且将修改后的代码放入程序中，作为新的软件版本，而不能直接替换到现有的测试版本中去。
2、版本控制定义： 测试版本的交付在专人控制之下，对每次测试的版本有明确的标识（新增加的功能、修复的bug等），不同版本可以看到稳定度趋势，每个版本的测试状态。
1. 制定合理版本发布计划，加强版本控制管理。 协商测试版本发布及发布频率：制定版本进度计划，该计划中包括开发团队提交不同版本的计划时间、每个版本中新增功能模块列表、提交版本的要求、修复的bug列表等。 测试版本发布基础：代码评估（代码review），版本控制的文档（标识新增或修改的功能、修复的bug、能够很方便的跟踪和监控测试版本的执行） 测试启动条件：功能是否开发完成、有没有进行自测（避免出现版本质量太差）、软件版本说明。 提测后注意事项：非bug fix的修改，必须说明（如代码重构）；Bug fix涉及的代码，明确回归范围和影响范围（避免修复bug是修改共同文件，引起全局问题）。
2、强化测试准入条件 测试启动条件：功能是否开发完成、有没有进行自测（自测报告，避免出现版本质量太差）、软件版本说明（清楚每一次版本更新都修改了什么，会对哪些功能造成影响）。 开展冒烟测试：保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断，如果最基本的测试都有问题则直接打回。
（开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。）
冒烟测试的通过标准：基本的功能和流程通过就可以。（测试场景/点可以提供） 软件提测后注意事项：非bug fix的修改，必须周知（如重构），Bug fix涉及的代码，代码review，明确回归范围，减少质量隐患。
3、强化bug管理 bug内容（发现版本，对应人员，发现模块，回归次数，bug关闭的版本号），可以分析不同版本和不同模块bug走势。 发现此次迭代范围外的之前遗留的bug，测试记录后，和开发及项目管理人员商讨是否解决，解决方式（代码限制OR操作说明中限制），是否占用此次迭代的开发时间。
4、版本控制文档管理工作 版本信息、测试记录、测试结果（开发和测试活动的追溯）
5、及时沟通
保证开发和测试的独立性：打的包，部署的环境，尽量连接181的服务。测试环境和开发环境分开，尽量做到测试数据不会被开发人员修改。 明确测试需求：需求功能点全部实现，如果有需求不能在规定时间完成，需要在需求阶段提出，而不是在测试阶段完善需求，从而加长了开发和测试时间，影响效率。 细化提测标准：开发到什么程度可以接受测试。 预测试：达到送测标准，在服务器上取下测试的版本，编译、部署后，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。 控制需求的变更：变更了软件需求一定要有记录和说明，相应的测试用例及时追加和维护。 进行bug分级：界面和易用性的bug等到开发完成和重要bug解决完毕再改。 增强质量意识：上线前临时改代码修复问题或者临时口头追加的变动要有记录，要通知一下。
开发文档和产品需求文档生成或者变动后请周知一下，保证测试用户及时编写和维护。 测试环境最好是专人维护（开发、运维、测试），频繁和擅自发布新功能或者修改是不可取的。保证版本的统一性很重要。 测试人员提交的bug到了开发人员手中之后，开发人员针对这些bug进行修复工作，并且将修改后的代码放入程序中，作为新的软件版本，而不能直接替换到现有的测试版本中去。 代码提交 ，review后再部署，直接打包部署的代码不能保证完整 （提交冲突，合代码后发布失败等）
