Coverity谈“开发中测试”与程序员最常犯的编码错误

Coverity谈“开发中测试”与程序员最常犯的编码错误

　Coverity公司位于美国加州旧金山，他们的产品包括Coverity Integrity Control、Coverity Static Analysis等一系列代码分析工具与解决方案。日前，Coverity公司产品副总Ezi Boteach先生就“开发中测试”、代码复查和开发人员最常犯的编码错误接受了采访。

　　问题：能否介绍下Coverity的“开发中测试”理念和你们的Development Testing Platform？

　　Ezi：“开发中测试”是新出现的一种技术，包括一系列流程和软件，例如静态分析。开发中测试的目的是要帮助开发人员、管理层和业务人员能在开发周期的早期，找到并修复质量和安全方面的问题，这些代码还在开发之中，不会影响上市时间、成本或客户满意度。

　　“开发中测试”扩大了传统测试范围，可以包括功能测试、性能测试和安全审核，为开发团队提供更快、更便捷的方式来测试代码中的缺陷，而且是以非侵入的方式。这种方式下，开发人员能够把注意力集中在创新上，管理层能够在开发周期早期尽早了解问题以作出决策，业务人员能持续向市场交付高质量的产品，获得竞争优势。

　　问题：代码复查是人们高度推荐的编程实践。如果使用你们的产品，对于代码复查，您有什么建议？

　　Ezi：代码复查是软件“开发中测试”很重要的部分，而且其成本很高，因为需要另一个开发人员来复审代码，很多时候这个开发人员还必须是资深人员。在代码复查之前先做静态分析，这能让代码复审过程更快，而且成本更低。使用自动化分析来检查变更以及于系统其他部分的集成点，以此来识别和消灭代码错误，代码复审就可以更集中于逻辑和功能错误，而不是代码的缺陷，这样做更划算，能够自动化，而且易于重复。

　　我们推荐测试驱动开发所有的工具和实践，包括代码复审、单元测试和代码覆盖率。当然，要是能和Coverity的自动化代码测试工具一起使用就更好了。

　　问题：你们的产品如何与像xUnit这样的工具一起配合使用？

　　Ezi：单元测试是“开发中测试”的重要组成，需要支持测试驱动开发。使用Coverity 5.5，我们引入了“开发中测试”的平台，能够让多种不同工具与测试工作流集成。目前我们还不能专门与xUnit集成在一起，但是我们的客户现在能够很方便地把他们使用的测试工具与Coverity Development Testing平台集成。举个例子：Coverity 5.5.1版本包括与常用Java静态分析工具FindBugs的集成。这样的集成让管理人员能够降低维护多个测试工具的成本，并通过统一的工具来推行策略。开发人员也有统一的界面来查看缺陷，并排定解决的优先级。

　　问题：你们的产品是否能与持续交付流程集成？

　　Ezi：Coverity Static Analysis可以与多个构建系统集成，包括Jenkins这个常用的持续集成系统。一般来说，与Jenkins和持续集成系统的集成是为了确保所有的持续构建都能运行自动化代码测试工具。如果分析中发现了新的缺陷，一个构建版本就是失败的。这确保新的缺陷不会引入到交付的软件的主干代码中，而交付过程是持续交付流程的一部分。这也能保证失败的构建版本不会进入流程的下一个阶段，一般来说是QA阶段。Coverity就像是交付过程中的一道闸门。

　　问题：除了使用你们的产品，您是否还能为开发人员和架构师提供一些其他的原则与实践？

　　Ezi：确保软件的质量，防止安全漏洞，这需要良好协作、工具和开发流程管理这几方面的结合。从清晰的需求文档开始，这是开发任何新功能的基础。需求文档之后，就是功能和系统架构师完成的功能和需求设计。代码开发完成后，“开发中测试”应该是这个流程的有机部分。不仅仅是一个产品，而应该是流程和技术的组合，帮助开发组织在开发周期早期、撰写代码的时候，就能修复软件的问题，确保代价高昂的缺陷不会进入后续阶段和生产环境。

　　架构师要确保软件的架构良好。这需要人工复审和架构分析，此外还要有经过考验的软件开发方法论。与之类似，开发人员也要保证，除了使用静态和动态分析的自动化测试之外，也要使用代码复审和单元测试。质量保证（QA）是任何软件开发过程中都很重要的阶段，以确保功能测试和性能测试顺利通过。最后，安全审核也很重要，保证在识别、修复、移除代码缺陷时不会带入新的安全漏洞。

　　问题：根据Coverity收集的数据，您能否列举一些开发人员最常犯的错误？

　　Ezi：开源项目SCAN（scan.coverity.com）能够很好地发现开发人员常犯的错误。从2006年开始，Coverity与美国国土安全部一起，研发了Coverity SCAN项目，来保证开源软件的安全性和完整性。Coverity SCAN分析了超过290个开源项目，包括Linux、Apache、PHP和Android，识别出49，654个缺陷，开源软件开发人员已经修复了超过15，000个缺陷。虾米的表格就展示出了开源软件中最常出现的缺陷，商业软件也与之类似。

	SCAN项目中的出现频率	风险程度
NULL指针引用	27.60%	中
资源泄露	23.19%	高
非原意图表达式	9.76%	中
读未初始化的值	8.41%	高
释放后使用	5.91%	高
缓冲区溢出	5.52%	高

　　很重要的一点要指出：像NULL指针引用、内存泄露和缓冲区溢出常常会带来很严重的质量和安全风险。很多这样的缺陷，使用传统的测试方法，有时难以找到。使用Coverity的工具会更易于发现类似问题。

　　要想了解更多关于SCAN项目的信息，可以访问 2010 SCAN报告，其中包括对于Android核心代码的分析结果。

　　问题：对于代码分析可视化的重要性，程序员们认识得越来越明白了。您能否列出3个最重要的相关分析图？

　　Ezi：Coverity的Development Testing平台能以代码可视化形式让开发人员和管理层看到代码的质量。可视化能够在几个方面起到帮助作用：它有助于标识代码的所有者和缺陷，能帮助展示出软件代码的整体可读性，以及质量和安全风险较高的代码区域，还能有助于推行代码完整性的检查策略。

　　只谈3个图很困难，但我想选的是：未解决的缺陷与已解决的缺陷的对比、每个软件组件中的缺陷个数、新的Integrity Control热度图。