同一个Bug来回修改测试有没有什么从制度上面解决的方法

用冒烟测试，让开发者通过冒烟测试用例。

一般都是有冒烟测试的，能起到一定的作用，同时比较考验测试和研发的水平。

冒烟测试啊。 转一篇文章。

什么时候进行冒烟测试

测试是测试人员确认软件存在bug的过程，此过程中不可避免是需要开发人员要不停的修改bug，那么常常会发现一个功能的改动，导致下一轮系统测试出现问题。即发现也许以前修改的bug的确是解决了，可是由于修改一个或多个bug导致其他功能模块出现新的问题，测试跑不通了，只能测试终止。那么我们如何确保开发人员修复了bug后，这个bug的修复没有影响到其他功能模块呢？这时就需要进行冒烟测试啦。

什么是冒烟测试

冒烟测试是自由测试的一种，由开发人员与测试人员共同进行。在测试过程中发现问题，测试人员找到了一个Bug，然后开发人员会来修复这个Bug，冒烟测试是否通过决定了下一轮系统测试是否可以执行。

诚然第一次看到他的时候，有人给过解释即：使用一袋烟的功夫快速对软件的主要功能进行测试，理所当然仍人为很简单，随便点点就好啦。这次正式开始了解后明白冒烟测试的重要性不作用于本身而是决定了下一轮测试是否能达到理想的效果，与系统测试不同之处在于冒烟测试是一种不要求覆盖面有多广测试，但是要保证被测对象的主要部分功能要得到测试，不要求每一个功能都面面俱到，但是要保证所有被修改过以及与修改相关的功能、主要的功能都是可用的，即证明这个版本可进行系统测试。

执行冒烟测试的前提

前面提到冒烟测试是与开发的合同协作，因此有几个合作前提 a)初步了解代码中进行了什么更改。若要理解该更改，必须理解使用的技术 b)开发需告知此修改对其他功能是否影响 c)更改对各组件的依存关系有何影响。

执行冒烟测试所需要注意的

a)列出冒烟测试的主要功能、测试点。 b)冒烟测试不是只对修改过功能进行测试 c)重视平时测试时容易忽略的隐藏功能 d)重视常见又很重要的步骤如：下载安装

冒烟测试与回归测试的区别

冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，功能可以正常运行（不会出现跑不通的状况），不会影响下一轮测试的进行，如果上述都符合那么这个版本就可以进行下一轮测试。个人理解冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。

而回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

关于区别这里有详解http://www.cnblogs.com/Abby123/p/6612148.html

http://blog.it985.com/21726.html