静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
看了一系列的静态代码扫描或者叫静态代码分析工具后，总结对工具的看法：静态代码扫描工具，和编译器的某些功能其实是很相似的，他们也需要词法分析，语法分析，语意分析...，但和编译器不一样的是他们可以自定义各种各样的复杂的规则去对代码进行分析。
1、PMD
PMD是一个代码检查工具，它用于分析Java源代码，找出潜在的问题：
- 潜在的bug：空的try/catch/finally/switch语句
- 未使用的代码：未使用的局部变量、参数、私有方法等
- 可选的代码：String/StringBuffer的滥用
- 复杂的表达式：不必须的if语句、可以使用while循环完成的for循环
- 重复的代码：拷贝/粘贴代码意味着拷贝/粘贴bugs
PMD特点
- 与其他分析工具不同的是，PMD通过静态分析获知代码错误。也就是说，在不运行Java程序的情况下报告错误。
- PMD附带了许多可以直接使用的规则，利用这些规则可以找出Java源程序的许多问题
- 用户还可以自己定义规则，检查Java代码是否符合某些特定的编码规范。
- 同时，PMD已经与JDeveloper、Eclipse、jEdit、JBuilder、BlueJ、CodeGuide、NetBeans、Sun JavaStudio Enterprise/Creator、IntelliJ IDEA、TextPad、Maven、Ant、Gel、JCreator以及Emacs集成在一起。
- PMD规则是可以定制的: 可用的规则并不仅限于内置规则。您可以添加新规则：可以通过编写Java代码并重新编译PDM，或者更简单些，编写XPath表达式，它会针对每个Java类的抽象语法树进行处理。
- 只使用PDM内置规则，PMD也可以找到你代码中的一些真正问题。某些问题可能很小，但有些问题则可能很大。PMD不可能找到每个bug，你仍然需要做单元测试和接受测试，在查找已知bug时，即使是PMD也无法替代一个好的调试器。
- 但是，PMD确实可以帮助你发现未知的问题。
2、FindBugs
FindBugs是一个开源的静态代码分析工具，基于LGPL开源协议，无需运行就能对代码进行分析的工具。不注重style及format，注重检测真正的bug及潜在的性能问题，尤其注意了尽可能抑制误检测(false positives)的发生。以bytecode（*.class、*.jar）为对象进行检查。除了单独动作，还可以用作Eclipse 的plug-in，以及嵌入Ant作为task之一 进行利用。
findbugs自带检测器的介绍: findbugs自带60余种Bad practice，80余种Correntness，1种Internationalization，12种Malicious code vulnerability，27种Multithreaded correntness，23种Performance，43种Dodgy。
Findbugs的一些特点：
- FindBugs主要着眼于寻找代码中的缺陷，这就与其他类似工具有些区别了，直接操作类文件（class文件）而不是源代码。
- FindBugs可以通过命令行、各种构建工具（如Ant、Maven等）、独立的Swing GUI或是以Eclipse和NetBeans IDE插件的方式来运行。
- FindBugs输出结果既可以是XML的，也可以是文本形式的。
- 开发者可以通过多种方式来使用FindBugs，最常见的是在新编写模块的代码分析以及对现有代码进行更大范围的分析。
- 不注重style及format，注重检测真正的bug及潜在的性能问题，尤其注意了尽可能抑制误检测(false positives)的发生。
- FindBugs可检测的bug pattern举例:检测java programing中容易陷入的bug pattern，equals() 实现时的一般规约违反Null pointer的参照 ，Method的返回值的check遗漏 ，初始化前field的访问，Multi-thread的正确性， 同期化处理的矛盾， 无条件的wait()， Code的脆弱性 ，可以变更的静态object ，内部数列参照的return等
3、Checkstyle
定义： Checkstyle是一款检查Java程序源代码样式的工具。
特点：
- 它可以有效的帮助我们监视代码，以便更好的遵循代码编写标准，特别适用于小组开发时彼此间的样式规范和统一。
- Checkstyle提供了高可配置性，以便适用于各种代码规范，所以除了使用它提供的几种常见标准之外，你也可以定制自己的标准。
- Checkstyle提供了支持大多数常见IDE的插件，大部分插件中就含有最新的Checkstyle，就不用费心再部署一份了。
- Checkstyle可以检查代码的很多方面，从传统观点看，它主要是用来检查代码层面的，自从第三版以后，它的内部架构作了重大改变，很多其它意图的检测加了进来，现在Checkstyle可以检查像类设计的问题，重复代码，如锁的双重检查的bug模式。
CheckStyle的主要流程是：
- 对Java文件进行词法语法分析，生成语法树。
- 载入配置文件（checkstyle-metadata.xml以及自定义的配置文件）register check事件。
- 按照深度优先遍历对语法树进行解析，按照注册的事件，在到达某些节点( AST ) 时进行style检查（AST，A child-Sibling Tree，是语法树中的某个节点，其类型在TokenTypes类中定义。）
- 我们所说的自定义Style的检查，就是在第二步设定的。这里牵涉到一个叫com.puppycrawl.tools.checkstyle.api.Check 的类，我们通常需要重载其中的两个函数： public int[] getDefaultTokens()和public void visitToken(DetailAST ast)。 这两个函数的含义为，在遍历语法树的过程中，每当到达getDefaultTokens函数所返回的AST类型，程序就进入visitToken进行具体的检查和分析，即，真正的分析检查过程是在visitToken中实现的。
4、Hammurapi
定义： Hammurapi它是一个开源的代码审查/评审(review)工具。它可以帮助改进Java代码的质量。它可以基于一套设计规范来分析代码库。当它碰到违反规范的地方，会在报告中标识。就像Checkstyle一样，它与Ant无缝集成并且由基于XML配置文件来驱动。
特点：
- Hammurapi是用来强制代码设计规范的。
- Hammurapi是一个遵循设计的工具，提供了自动而且一致的方式来实现设计规范，因此使代码评审更加有效而轻松。
- Hammurapi如何工作： Hammurapi这样的代码分析工具都带有语言分析器。语言分析器是一种输入语言代码并输出抽象语法树的工具。这个树上的节点代表语言标识。例如，考虑一下简单的算术表达式：3+4. 语言分析器会解析他成为一个如图5所示的语法树。在这个树中，节点+代表操作符标识。节点3和4是操作数标识Hammurapi使用ANTLR（另一个语言识别工具）作为语言分析器。然而ANTLR API是相当底层的。为改善可用性，Hammurapi使用另一个API，基于ANTLR 的JSEL（Java源程序工程类库），来访问抽象语法树。 一旦树构建完成，一种树遍历算法就被用来访问树中每一个节点。每次访问到一个节点，一种回调机制（Visitor模式）被用来提示相应的检查器。在这些回调方法中，检查器收集相关的信息来确定是否有违反规范的地方存在。
定义：Lint4J是一个针对Java的源代码分析工具，它可以对Java源码和字节码进行静态分析，判断其中是否存在死锁、性能问题或者伸缩性问题。它可以集成到任何IDE种或构建系统
特点：
- 检测代码语法规则
- 潜在的bug
- 检测编码模式对代码可读性及大小的影响
- 检测是否违反EJB规范
定义：代码质量管理工具Sonar提供了设计与架构度量。Sonar 2.0引入了针对Java应用的设计分析、架构与面向对象的度量，Sonar 2.1可以检测到未使用的方法以及对不建议使用方法的调用。是一个集成了CheckStyle、PMD、Findbugs的代码校验规则，重复代码发现，代码测试覆盖率，代码注释率，及所有的检测率变化追踪的完美代码质量检查工具。它包含了代码质量检测的七个方面
特点：
- 代码覆盖：通过单元测试，将会显示哪行代码被选中。
- 改善编码规则。
- 搜寻编码规则：按照名字，插件，激活级别和类别进行查询。
- 项目搜寻：按照项目的名字进行查询。
- 对比数据：比较同一张表中的任何测量的趋势。
- 单元测试
Sonar2.1：
- Sonar还基于Squid引入了一个全新的规则引擎、Sonar解析器既可以处理源代码，也可以处理字节码，解析器带有内建的规则，可以检测未使用的私有与保护方法以及客户端对不建议使用的方法的调用。Squid通过分析应用源代码、Java API和外部程序库的字节码来决定哪些方法、类和属性是不建议使用的。
Sonar 2.1的新特性：
- 一个全新的“Libraries”页面，显示了项目中所有的程序库和依赖，该特性要求使用Maven来构建项目。一旦在Sonar站点的主页上选择了一个项目，该服务就会以可视化的树形结构展示出项目依赖。此外，还有一个可选的动态过滤器，可以根据名称过滤程序库以便在应用的依赖间导航。
- 用于搜索程序库使用情况的“Dependencies”页面。比如说，可以搜索到使用了第三方框架如Commons Logging 1.1的所有项目。
- 可以使用各种插件扩展Sonar的功能。现在有一个全新的“System Info”页面显示了系统属性、已装插件和Java虚拟机内存统计信息。该页面还给出了关于Sonar配置和数据库统计的详细信息。
- 一个用于管理已装插件和系统信息的管理控制台。最新版的Sonar为这些插件引入了一个测试框架和一个客户化的Maven生命周期管理工具。它还带有一个用于集成项目事件的Web Service并在项目的size widget中增加了一个新的度量模块。
JDepend一个开放源代码的可以用来评价Java程序质量的优秀工具，它遍历Java class的文件目录，以Java包（package）为单位，为每一个包/类自动生成 包的依赖程度，稳定性，可靠度等的评价报告，根据这些报告，我们可以得到包或类之间的依赖关系，并分析出包的稳定程度，抽象程度，是否存在循环依耐关系等 。可以根据JDepend给出的报告数据，分析出我们的包是否是可靠的，稳定的，健壮的包，是否符合面向对象的设计原则。
特点：
- 评价设计质量
- 翻转依赖性
- 支持并行开发和极限编程
- 独立的发布模块
- 识别package的循环依赖
Depend生成的Java包的质量评价报告主要包括：
- Number of Classes and Interfaces：实现类与抽象接口的数目
- Abstractness (A)：包的抽象度。指一个包内包含的抽象类或接口占整个包中的类的比重。
- Afferent Couplings (Ca)：向心耦合。依赖该包（包含的类）的外部包（类）的数目（i.e. incoming dependencies），该数值越大，说明该包的担当的职责越大，也就越稳定。
- Efferent Couplings (Ce)：离心耦合。被该包依赖的外部包的数目（i.e. outgoing dependencies），该数值越大， 说明该包越不独立（因为依赖了别的包），也越不稳定。
- Instability (I)：衡量一个包的不稳定程度。I=Ce/(Ce+Ca)。它的值处于[0，1]之间。I=0时说明包是最稳定的，反之I=1则说明包极不稳定。
- Distance from the Main Sequence (D)： 该指标主要用来评价包的抽象程度与稳定程度的平衡关系，它可以用二维直线图 A + I = 1 来表示。
- Package Dependency Cycles：包的循环依赖度。
定义：是 IBM 开发的一个静态分析工具，可以用于分析并查找出 C, C++ 和 Java代码中的一些不容易发现的潜在错误，从而达到提高代码质量的目的。同动态分析工具和其它静态分析工具相比，它拥有一些可贵的特性。
特点：
- 对代码进行语法扫描，通过算法对代码进行检查分析。
- 和一些 bug 模式进行比较，最终标明问题区域，输出分析结果。
- 使用了额外的定理证明（theorem proving）技术来判断一个潜在的错误是否是真正的错误，从而减轻了程序员判断错误真伪所需的工作量。
定义：LDRA Testbed为应用软件的确认和验证提供强大的源代码测试和分析功能，是独特的质量控制工具。 它有助于提高计算机软件必需的可靠性，健壮性和尽可能的零缺陷，它的使用带来时间、成本和效率上真实的节省，这些都是无法衡量其价值的。它是强大和完整的集成工具包，使先进的软件分析技术应用在开发生命周期的关键阶段。
LDRA Testbed提供强大的分析功能，用于两个主要的测试领域，静态分析和动态分析。
- 静态分析： 分析代码，并且提供对代码结构的理解。
- 动态分析： 利用源代码的插装版本，使用测试数据执行，在运行时发现软件缺陷
使用LDRA testbed 的好处软件开发和测试过程的成本效率分析工具单元、集成和系统测试的理想工具贯穿于软件开发的整个生命周期LDRA Testbed应用于许多不同的领域过程改进软件测试软件维护
LDRA Testbed的优点：
- 改进软件质量
- 定位软件缺陷
- 强制执行工业标准
- 减少维护费用40％以上
- 减少开发和测试成本75％以上
- 通过自动化过程提高员工动力