选择静态分析工具的三个关键指标

选择静态分析工具，或者说判断静态分析工具的“优劣”，可以考虑以下三个指标。

1 Precision（精确度） =TP/ (TP+FP),

TP 表示 静态分析工具发现的真正的bug；FP表示 误报，即工具报告了，但不是真正的bug。

如果工具从没有产生误报，则Precision 等于100%。不过，很不幸，静态分析结果中的误报是不可避免的。尽管这几年商业化的工具在这方面有了很大的改善，但大部分的工具还是深陷误报率过高（它会掩盖住结果中真正的bug）的泥潭，因为大量的误报会让程序员做很多无用功，导致效率低下，并且真正的bug因此会被忽略。

就好比“狼来了”的故事。误报就好比小孩说谎。撒谎太多次（误报很多次），以后即便是真话（真正的bug），人们也不再相信你，甚至直接忽略你的存在。

2 Recall =TP/ (TP+FN),

TP 表示 静态分析工具发现的真正的bug；FN 表示 工具没有报出来的真正bug，即通常所说的“漏报”。

要确定漏报的数量FN，即有多少真正bug没有报告出来，是非常难的，因为谁都不知道代码中一共有多少bug，呵呵，如果知道的话，测试就简单了。所以为了度量Recall指标，不妨采用以下策略。

以代码正式发布后的一段约定时间（如3个月，或半年）内，通过其他手段发现的bug（当然，这个bug应该指的是代码方面的，你要是功能或其他的，它也不是静态分析的任务呀），作为FN 的值。

如果工具能发现代码中所有潜在的缺陷（即没有漏报），那么Recall就等于100%。和误报类似，如果大量的漏报，即FN太高，静态工具存在的意义，或者说静态工具的有效性，就会受到质疑。

从技术上来讲，达到100%的Recall，就如同达到100%的Precision，是不可能的。如果有的话，也一定是以高误报为代价的。二者似乎有点矛盾。

3Performance

性能，很难定量的公式来计算。一般来讲，Performance指的是工具为了分析，需要占用的计算资源的数量。这个资源必须是主流的公司可以接受的。举例说明，如果使用主流配置的PC或者小型工作站，工具分析一个项目的代码（以百万行计），需要的时间在12小时以内，则这样的性能就是可以接受的；如果时间在24小时以上，就是不现实不能接受的；还有如果工具只能运行在大型机上，则对于大多数公司来讲，也是不可接受的。

当然还要考虑到学习成本。如果工具复杂到只有科学家才能用，那么也是不可以的。即要考虑简单易用。

以上系个人观点，仅供参考。