自动化代码分析的过去、现状和将来

发表于:2008-2-01 17:54

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:译者:陈能技    来源:51Testing投稿

分享:

  经过几年的努力,自动化代码分析工具终于走出幕后,相比以前,显得越来越受瞩目了,越来越强大,越来越必要。自动化代码分析是一类软件和工具的总称,它们帮助程序员发现、诊断和预防大范围的错误和不符合要求的行为的代码。
  自动化代码分析可分成两大类基本类型:静态和动态。静态类型的分析器检查源代码或者目标代码,不需要真正执行代码。动态类型则需要运行代码,在运行过程中检查代码效果。有些问题能被静态分析很好地定位,有些则需要动态分析来定位,而很多情况下需要综合利用静态和动态分析的方法来解决问题。
  我会从静态和动态自动化代码分析工具的发展过程谈起 – 从它们朴实无华但是又充满希望的出身,到成为不可或缺的普及技术。我也会介绍一下目前的自动化代码分析工具。然后展望一下它们的美好未来 – 自动化代码分析技术的新发展,可以非常快速高效地帮助开发者定位和解决痛苦的、耗时的各类问题的技术。
基本的代码分析:从Lint到IDE
  执行基本代码分析的第一个工具就是编译器。为了顺利地编译,代码必须首先是词法正确的,因此代码分析的第一步就是检查程序是否符合编程语言的语法。在上世纪80年代中期之前,这种编译器执行最低限度的检查的方式被很好地使用,它的特点是缺乏或者拥有很少的诊断能力。那时候对编译器的评论会单独评价它们在预防误报虚假错误信息方面的能力。遗漏一个分号就可能导致编译器的混乱,发出一连串的错误信息,大部分信息是不对的或者是容易让人误解的。有经验的程序员会变得熟练掌握和识别这些长长的信息序列,并且知道哪些是需要修正的 – 通常仅仅需要添加一个遗漏了的分号而已。
  早期的编译器在代码分析方面还有另外一个限制。它们的主要目的是把源代码翻译和转换成可执行的二进制代码,而不是通过代码检查来帮助你编写更干净、更健壮的代码。因此,这些编译器只是检查语法错误,而对于那些语法上正确但是非常可疑的代码结构置之不理。这种设计是哪个时代的必然结果。硬件系统资源有限,编译很慢。每次编译要花费额外的时间来执行额外的分析是不值得的,对于编译器厂商和开发者而言都是不愿意接受的。
  对于需求而言,自动化的普通代码错误检查确实是需要的。1977年,贝尔实验室的Steve Johnson引入了一个名为Lint的工具 – 名字的由来是感觉从程序中排除错误就像从大衣上摘除细小的棉绒。Lint能检查出类似该使用“==”号,但是却使用了“=”号的错误,或者是那些代码模块之间的不一致的函数接口的错误。Lint被广泛用在Unix社区,尤其是作为代码签入前,或者是大版本的构建之前的最后健全性检查。然而,Lint的用途还是有限,Lint的运行是个冗长的、繁复的、交互性不够强的“编辑-保存-分析”循环。在保存源代码之前不能得到反馈信息,要退出编译器(那时候还没有多窗口系统),然后运行Lint。最主要的是,Lint输出的是命令行的信息,就像下面的:
          1

  为了定位警告信息,你必须自己回到代码编辑器,加载出现警告信息的相关源代码文件,找到出现问题的代码行来修改它。然后又要回到Lint中来,看修正后问题是否还会出现。想象一下要处理的是更多的警告信息时结果会怎样。不管怎样,Lint被证实是一个非常有用的工具。
  若干年后,随着计算能力的增强,还有集成开发环境(IDE)的出现,让实时的基本源代码分析成为可能,在编辑器中能直接定位和高亮显示警告信息和可能的错误 – 通常是紧跟着开发人员的输入,马上就能提示出来。大部分的IDE都把Lint提供的功能整合进来了。使用现代的IDE,如果我输入下面的代码作为程序的一部分:

     11

  IDE会马上让我知道应该使用“==”,而不是“=”。我能当场解决这个问题。这些及时反馈节省的时间和交互性可能看起来很琐碎,但是当你重复出现大量类似的问题时,IDE的内建静态检查器都能发现这些愚蠢的错误,这样节省下来的时间可能是一个开发人员几天的时间。
  除了基本的分析、内建的静态分析外,大部分IDE都有可选的插件来执行更多更全面的分析。截至目前为止,流行的开源的Eclipse已经有26个插件在“源代码分析器”的分类列表中。
  这些插件包括增强代码规则或者是代码风格的检查(例如:Checkstyle、JLint、PMD),到检查和移出冗余代码的分析器(例如Duplication Management Framework),它们填补了IDE内建分析器的不足。例如,很多Java的初级程序员有时候会使用“==”来比较字符串的值(例如使用name==”Elvis”,而不是使用name.equals(“Elvis”),这样的话是在比较对象引用而不是比较字符串的相等)。这也许是大部分Java程序员犯的普遍性错误,但是奇怪的是,默认的Eclipse设置不把这个问题当成警告发出,但是大部分的代码规则/风格检查器插件会。这是我从Eclipse得到的警告信息(安装了CheckStyle插件后):

       111

  对于静态分析代码而言,分析出普遍的编程错误和编码规则或风格的违反,相对Lint时代已经有了长足的进步。IDE的内建分析器、第三方工具和插件让我们可以在开发过程中发现和定位并修改大量的这些错误。与此同时,这个世界变得更加互联互通、更加复杂、也更加危险。今天运行着的软件必须变得更加健壮,面对新的潜在错误和威胁。幸运的是,新的代码分析工具也出现了。

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

21/212>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • xiechungang
    2008-2-19 15:52:03

    不错 fortify就是个不错的静态代码分析工具

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号