也谈软件测试的调试

也谈软件测试的调试 软件测试方法

每年二月末到三月初，公司都会安排一批实习生到各个部门实习。虽说去年经济危机了，但公司的实习生数量似乎并没有减少。起码我们部门“新同事”的数量基本与去年持平。按惯例，每位新同事都会有一名导师，与此同时各个部门还会根据自身的业务特点对这批学生进行有针对性的集中培训和交流。比起我入司那会儿，现在的实习生已经算是幸福多了。我那会儿实习生人数少，部门没有安排什么培训，完全靠导师安排自己努力学习。此次培训的内容是经过老员工们讨论和对新员工的需求调查后才确定的。其中新同事们普遍对如何进行程序调试这块比较感兴趣，我负责准备和实施了这个题目。虽说有过几年调试程序的经验，但是自已也没有系统的总结过，这次培训后顺便在这里做一下总结和记录。

　　说到程序员，各位大脑中第一反应就是编码；但我们知道软件开发可不仅仅只有编码，调试也占据了程序员很大一部分精力。程序员“简单”的工作中，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