软件测试中也谈软件调试

关键字：软件测试 软件调试

　　说到程序员，各位大脑中第一反应就是编码;但我们知道软件开发可不仅仅只有编码，调试也占据了程序员很大一部分精力。程序员“简单”的工作中，80%的时间都是在编码和调试(现在文档工作也不少)。调试的对象是BUG，BUG是什么呢?BUG就是编码过程的伴生品。既然将之诠释为“伴生品”，那就意味着“凡是软件，内必有BUG”。也许有人不同意这样的观点，但无关大碍，因为如何看待BUG本身就可以看成是一个哲学范畴的话题，大可见仁见智。

　　调试前，首先做好心理准备。

　　调试BUG的过程可以用“艰苦卓绝”来形容;特别是一些“又臭又硬”的BUG，难于重现，难于定位，甚至在投入相当大的精力后仍然无法Fix。所以调试BUG前就要摆正心态，要保持清醒、保持耐心，甚至要做好打“持久战”的打算。要知道Unix下还有一些BUG也是在隐藏了几十年后才被Fixed。

　　预防BUG的发生，降低BUG发生概率。

　　我们还需要清醒的认识到：事实证明与编码相比，调试BUG的成本是更高的。BUG可简单分为产品Release前BUG和Release后的BUG。无论哪一种，你都要经历收集数据、重现BUG、定位问题、修正问题和Aclearcase/" target="_blank" >ccepted等多个步骤后才能重新Release。这其中以Release后的BUG花费的成本为更高。既然如此，我们何不采用一些手段来相对的预防BUG的发生，降低BUG发生的概率呢!这里说说我想到的。从一个软件的整个生命周期来看，保证软件质量应从需求开始，但这里我们主要关注编码阶段。从个体开发者角度我们可以从以下三个方面考虑：

　　* 充分的静态代码检查

　　充分利用你手头上的工具对你编写的代码做严格的检查，这些工具包括编译器(尽可能将警告级别提升到你可以接受的最高级别)、LINT工具等。这将帮你将代码中潜在的细小问题发掘出来，避免这些问题在事后成为隐藏的大BUG。

　　* 调试版添加断言

　　充分利用断言Assertions这把发现BUG的利器，借鉴契约式编程的一些规则，在你的调试版代码中适当的地方添加Assertions。这样的方法同样可以帮助你及时发现代码中隐藏的缺陷。

　　* 充分的单元测试

　　充分的单元测试提高代码覆盖率，减少业务逻辑遗失导致的BUG;单元测试用例还可以结合断言发现更多程序潜在问题。如果能做到测试先行，也许效果会更好。

　　* 代码同级评审

　　让其他人来审核你的代码，提前帮你发现潜在的问题;如果能做到结对编程，

　　也许效果会更好。

　　从组织的角度来看，持续集成的实践可以让组员更加及时的发现编码阶段的问题，不让问题遗漏到后面阶段成为严重BUG。

　　如果很好的实施了上述这些手段后，你的BUG发生率会大大降低，但是前面说过：BUG不能避免，一旦BUG发生了，该怎么办?其实与BUG做艰苦卓绝的斗争，也是有一定方法的。

原文转自：http://www.ltesting.net