七、 代码检查方法的研究
　　1、基于DOM的模式匹配计算
　　对程序代码进行静态分析后，代码中所包含的大量各类语法信息，对于代码检查具有很好的指导意义。为了方便在静态分析的基础上进一步的研究，并使得静态分析结果能方便的被解释和显示，甚至能提供给其它的模块或者软件使用，需要采用一种合适的格式来保存静态分析结果。在本文中选择的是XML格式。
　　XML即可扩展标记语言（eXtensible Markup Language）是一种具有数据描述功能、高度结构性及可验证性的语言。在XML文件中，可以使用标记并配合属性来描述数据，因此，XML非常适合用于作为对象或者标准的描述语言。
　　对于XML有两种解析方式：
　　DOM：文档对象模型（ Document Object Model）
　　DOM以一种平台和语言无关的方式表示XML文档的官方 W3C 标准。DOM是以层次结构组织的结点或信息片断的集合。这个层次结构允许开发人员在树中寻找特定信息。分析该结构通常需要加载整个文档和构造层次结构，然后才能做任何工作。由于它是基于信息层次的，因而DOM被认为是基于树结构或基于对象的。DOM以及广义的基于树的处理具有几个优点。
　　首先，由于树在内存中是持久的，因此可以修改它以便应用程序能对数据和结构做出更改。它还可以在任何时候在树中上下导航，而不是像SAX那样是一次性的处理。DOM使用起来也要简单得多。
　　另一方面，对于特别大的文档，解析和加载整个文档可能很慢且很耗资源，因此使用其他手段来处理这样的数据会更好。这些基于事件的模型，比如 SAX。
　　SAX（Simple API for XML）
　　这种处理的优点非常类似于流媒体的优点。分析能够立即开始，而不是等待所有的数据被处理。而且，由于应用程序只是在读取数据时检查数据，因此不需要将数据存储在内存中。这对于大型文档来说是个巨大的优点。事实上，应用程序甚至不必解析整个文档；它可以在某个条件得到满足时停止解析。一般来说，SAX 还比它的替代者 DOM 快许多。
　　对于需要自己编写代码来处理XML文档的开发人员来说，选择DOM还是SAX解析模型是一个非常重要的设计决策。
　　DOM采用建立树形结构的方式访问XML文档，而SAX采用的事件模型。
　　DOM解析器把 XML 文档转化为一棵包含其内容的树，并可以对树进行遍历。用DOM解析模型的优点是编程容易，开发人员只需要调用建树的指令，然后利用navigation APIs访问所需的树结点来完成任务。可以很容易的添加和修改树中的元素。然而由于使用 DOM 解析器的时候需要处理整个 XML 文档，所以对性能和内存的要求比较高，尤其是遇到很大的 XML 文件的时候。由于它的遍历能力，DOM 解析器常用于 XML 文档需要频繁的改变的服务中。
　　SAX 解析器采用了基于事件的模型，它在解析XML文档的时候可以触发一系列的事件，当发现给定的tag的时候，它可以激活一个回调方法，告诉该方法制定的标签已经找到。SAX对内存的要求通常会比较低，因为它让开发人员自己来决定所要处理的tag。特别是当开发人员只需要处理文档中所包含的部分数据时，SAX这种扩展能力得到了更好的体现。但用SAX解析器的时候编码工作会比较困难，而且很难同时访问同一个文档中的多处不同数据。
　　通过以上对这两种解析特点的比较，不能看出，对于处理静态分析结果这种结构性很强，并且内容保持相对稳定的信息数据，选用DOM解析模型是非常合适。
　　JDOM：Java 文档对象模型 （Java Document Object Model）
　　JDOM的本质是一种使用Java作为编程语言实现文档对象模型解析XML的工具，它简化与XML的交互并且比使用DOM实现更快。由于它是第一个Java特定模型，JDOM一直得到大力推广和促进。正在考虑通过“Java规范请求JSR-102”将它最终用作“Java标准扩展”。
　　虽然，JDOM与j2sdk中包含的标准DOM都能实现对XML的DOM方式解析，但两者仍然在两个方面存在不同。首先，JDOM仅使用具体类而不使用接口。这在某些方面简化了API，但是也限制了灵活性。第二，JDOM的API大量使用了Collections类，简化了那些已经熟悉这些类的Java开发者的使用。
　　JDOM 文档声明其目的是“使用 20%（或更少）的精力解决80%（或更多）Java/XML 问题”（根据学习曲线假定为 20%）。JDOM对于大多数Java/XML应用程序来说当然是有用的，并且大多数开发者发现API比DOM容易理解得多。JDOM 还包括对程序行为的相当广泛检查以防止用户做任何在XML中无意义的事。然而，它仍需要充分理解XML以便做一些超出基本的工作（或者甚至理解某些情况下的错误）。
　　模式匹配
　　在传统的《数据结构》教材中都提到了模式匹配这个概念，通常情况下它指的是字符串的模式匹配，即子串定位，是一种重要的串运算。一个通俗的描述如下；设s和t是给定的两个串，在主串s中找到等于子串t的过程称为模式匹配。如果在s中找到等于t的子串，则称匹配成功，函数返回t在s中的首次出现的存储位置(或序号)，否则匹配失败，返回-1。其中的t也称为模式。
　　使用正则表达式的方法来分析字符串，可以看作一种很好的模式匹配实现。事实上，不少开源代码检查工具之所以使用Perl、Python和Tcl 等脚本语言来实现，也是看中了内置在其中的强大的正则表达式功能。
　　上面阐述的这种传统的模式匹配和模式的基本元素是单个字符。如果基本元素换成DOM模型中Element元素，传统的模式匹配转变成了针对Element序列的模式匹配。我们称之为基于DOM的模式匹配。
　　当静态分析结果以DOM形式解析时，当把代码检查规则也描述成相应的DOM对象的Element序列时，检查代码对象静态语法树上是否包含代码规则对应的Element序列的过程，也就是进行基于DOM的模式匹配计算的过程。
　　图7为一个基于DOM的模式匹配模型示意。其中左侧的静态语法结构就是使用DOM方式的静态分析结果，而右侧的检查规则就是基于DOM方式解析的、潜在的编码规则。

　　图7   代码检查辅助工具模型数据流图
　　2、支持版本变更的代码检查
　　程序开发过程中，同一模块的设计以及所对应的实现代码总是不会一蹴而就的，随着开发工作持续开展，测试团队会定期收到开发团队提交的新版本程序代码。当版本变化很大时，将新版本认为是一个全新的模块重新进行完整的代码检查，效率影响不大。当然，工程实践中这种极端情况出现的几率并不大，通常情况只会因为改进或增强某项功能，甚至只是为了修复某个软件问题，对一个类中的某几个方法，或者一个函数中某个分支做了一些局部的改动。在这种情况下，如果对新版本的代码再重新按照静态分析、代码检查完整的周期走一遍，肯定是多数代码检查员所不希望的，而且这样做的效率也非常低的。代码检查员总是希望能使用软件把新版本代码中改变部分标示出来，并参考静态分析结果来引导检查的进行，这样会更有针对性、更有效率。

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。