1 质量第一。

       Bug要改一个少一个，尽可能减少由于改Bug而引入其他Bug。毕竟越往后其的bug越难以修改，我们要重做数据-->重现现象-->分析原因/确定方案-->调试/修改-->开发个人验证-->测试验证。这样6个步骤下来还是要花费不少时间。因此少出现一个Bug比快速改一个Bug更有效率。

    2 集中修改。

        一般来讲就是一个模块的Bug一块改，一个模块的Bug清理完毕了再清理另一个模块的，或者某一类的Bug一块改。

        一个模块的bug集中修改，能大量减少重做数据、重现现象和个人验证所花费的时间。一个模块一个模块集中修改，可以统一考虑这些问题，避免见招拆招、因而提高修改质量减少引入其他Bug的几率。

        对于某一类的Bug一并修改可以节省不少时间，有时候不仅仅是测试人员提到的模块有问题，相关模块也有同样的问题，这时候就要一并清理、格杀勿论。

       对于原来不是自己实现的模块，集中修改Bug的同时也可以发现新Bug，Bug集中起来也就有时间做Code Review或者白盒测试了。

    3 及时沟通。

        有些Bug很难重现的，或者需要重做大量数据。这些Bug测试人员与开发人员及时沟通，许多时候能省掉重做数据和重现现象的时间，也能及时定位问题，有些项目中甚至能立即修改和验证。

        而对于最初不是自己实现的模块，与原实现者沟通有时能起到“听君一席话，省调两小时”的效果。

    4 耐心和冷静。我改Bug是常会眼冒金星、头昏脑胀的，特别是有些钉子户级别的Bug，需要换些手段对付的。例如：换一个别的思路修改、向别人求助分析、或者干脆休息一下放一放此问题，先去修改一些容易修改的Bug，这样可以调整自己的情绪，另找时间专门对付那些钉子户。