Coverity Readiness Manager为代码质量引入可视化度量

作者 Scott Delap 译者 张龙 发布于 2008年9月24日 上午6时45分

社区

Java

主题

性能和可伸缩性

标签

测试,

Coverity,

代码覆盖率

Coverity最近发布了其新产品Software Readiness Manager的首个版本，该产品针对Java。Software Readiness Manager从多处收集并分析基本数据，并从多方面给出分析结果，比如代码复杂度、最佳实践违例、架构完整性、相互依赖以及测试覆盖率。它通过估算风险、对重构进行优先级排序以及估算软件现状来管理开发。

除此之外，Software Readiness Manager还提供了大量其他的Java代码分析工具。InfoQ最近有幸采访了Coverity的首席科学家Andy Chou，与其讨论了Coverity Prevent和Thread Analyzer。

针对Java的Coverity Prevent来源于该产品的C++版本。Thread Analyzer的灵感来源于哪儿呢？

我们看到多核处理器已经成为一种趋势，根据经验我们知道，多线程程序的行为在这种新硬件上开始变得不同。尤其是潜在的竞态条件和死锁会突然间成为最令人头疼的问题。这些问题最难调试了，因为它们很难重现。我们的静态分析产品Coverity Prevent也可以发现并发缺陷，但我们知道动态分析可以在测试过程中找到更多的并发缺陷，以此来补充静态分析结果。这样我们就开发了Thread Analyzer，迄今为止客户的反应都是很积极的。

与一些分析工具相比，比如Yourkit，你认为Thread Analyzer的强项在于哪方面？

Thread Analyzer主要用来解决多线程代码中最致命的问题。重现并找到一个并发缺陷可能要花费数天甚至数周的时间。甚至在确定了会产生问题的几行关键代码后，依旧难以解耦那些会导致竞态条件或者死锁的交叉存取事件。

Thread Analyzer使这一切变得清晰而可重现，因此它能在调试或测试时很快找到问题的所在，为你节省大量的时间和精力。分析工具会做很多事情，包括分解应用所花的时间和占据的内存。我想说的是，它们是互补的工具，每种工具的价值取决于所开发应用的类型和当前的实际情况。

最近blogsphere上的一个论调就是开源正在谋杀商业开发工具。开源对你们的业务有何影响？

开源为我们的业务带来了实惠——每个代码集都为我们的静态分析系统进行了扩展测试，我们调整算法来最小化失误率、最大化Bug发现率，将其用到了极致，所有这一切都轻松搞定。我们也很自豪于通过Scan（http://scan.coverity.com）向开源社区报告我们的工具所发现的缺陷。到目前为止，开源的开发者通过查询Scan上的结果，已经修复了超过8000个的缺陷。就开源工具来说，它们确实会对开发工具市场产生一定的影响，但我们发现，对于那些采用先进技术、提供企业级特性和支持、并且一直在其核心价值方面不断进取以保持领先地位的工具来说，依然有很大的空间。那些只是盯着钱而不进行自我改进的工具则会被开源远远甩在后面。

你认为对于创建多线程应用的Java开发者来说，最首要的问题是什么呢？

以前我们认为竞态条件是最重要的问题，因为它们会破坏数据，而且很难找到问题的根源。但令我们惊讶的是，很多客户告诉我们死锁才是更重要的问题，因为它会导致应用完全中断。甚至在我们自己内部的开发中，我们的企业架构师也曾说，他认为死锁是在Java平台上测试和部署企业应用的一个重要问题。这些看法反映了一些认知的欠缺：竞态条件会导致严重的数据破坏……死锁是很明显的，但竞态条件可能不那么引人注意，这取决于竞态的本质。

下个版本的Thread Analyzer会增加什么新特性呢？

我们打算让它与我们的静态分析产品更加紧密地结合，这样它们就能共享彼此的信息以改进性能并找到更多的缺陷。我们还打算在使用多个服务器的分布式程序中检测并发问题。最后，我们还在探求与平台供应商的整合，以让Thread Analyzer拥有更多的用户。

查看英文原文：Coverity Readiness Manager Brings Quick Visibility to Code Characteristics

• 更早的 >