空间管理您的位置: 51Testing软件测试网 » huior的测试烩 » 日志

这里没有软件测试的泛泛理论，只有博主的最佳实践。博主的研究方向为静态分析和性能测试，致力于各种测试工具的引入、评估和开发。本博的测试文章均为作者原创，转载请务必注明出处。

我看“静态测试”

上一篇 / 下一篇 2008-01-16 17:12:38 / 个人分类：静态分析

在开始我的文章之前，先引用一段关于静态测试的文字

http://bbs.51testing.com/thread-262-1-7.html

我猜想，引用的文字应该是教科书式的定义，简单总结，静态测试主要是对各种软件文档进行测试。

以下是我的观点。不求描述的太详细，简单点明我的思路即可。

静态测试，其定义为Testing of an object without execution on a computer.，就是说不需要在计算机上执行程序的测试，测试对象是软件的静态属性。软件包括程序+文档，但软件开发过程中的文档不应该是静态测试的对象，参考CMM的要求，可以明确：

l 软件开发文档应该是由各种角色的人员来评审的，而不是进行测试的。

l 软件测试概念中的“文档测试”的对象应该是随软件交付的文档，例如online help、reference manual等，而不是软件的开发文档。文档测试也应该是系统测试中的一个环节。51Testing软件测试网*pq8|hUM ]e

所以我的观点是，静态测试的对象主要是程序代码，过程主要是在单元测试和集成测试阶段。插一句，其实在测试的概念方面，国人和老外还是有一些细微的差别。老外口中的测试（test/testing）一般指的是动态测试，例如功能测试、性能测试等。我们说的静态测试，其实更接近老外眼中的static analyse(静态分析)。那么如何实施静态测试呢？51Testing软件测试网YLd/A;w@

1编码规范检查——一切的基础

一个项目或者一个企业，如果要下决心实施软件质量，实施软件工程，第一步要做的就是软件编码规范。

编码规范是程序编写过程中必须遵循的规则，一般会详细规定代码的语法规则、语法格式等。企业实施怎样的编码规范，取决于很多个因素：51Testing软件测试网;]!PUY/Kd*J)~

l 编程采用的语言，例如C、C++、JAVA、ADA等

l 项目的规范化程度。目前现成的C/C++编码规范有很多，例如前几年网络上比较流行的《华为公司编程规范》、《摩托罗拉C+编程规范》等。但项目不能完全照搬，应该根据自己所处的阶段，定制属于自己的规范，否则的话，会让程序员无所适从，严重打击程序员的积极性。

l 行业。不同的行业对软件的可靠性有不同的要求，例如航空/航天的嵌入式软件对代码的要求很高，而传统的windows平台应用软件则相对要宽松。

在嵌入式软件中，尤其是汽车行业，国际上目前流行的C语言编程规则为MISRA-C:2004，其中包括包括141条规则，其中121条是强制（Required）遵守的，20条是建议（Advisory）遵守的。详细信息可以参考其官方网站www.misra.org.uk

有了统一的规范后，测试工程师或者程序员自身，就可以实施编码规范检查了。

根据笔者的实践，要真正把编码规范贯彻下去，单单靠测试员程序员的热情，很难坚持下去，所以笔者建议借助于一些专业的工具来实施。在C/C++语言的编程规则检查方面，比较专业的工具有C++ Test、LINT工具、QAC/QAC++等，这些工具通常可以和比较流行的开发工具集成在一起，程序员在编码过程中，在编译代码的同时即同时完成了编程规则的检查。

2静态质量度量——提高软件的可维护性

有了严格的编程规范，只能算是万里长征迈出了第一步。要提高软件的可重用性，以及软件的可维护性，还需要进一步的努力，即静态质量度量。

静态质量度量所依据的标准是ISO 9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性（Maintainability）、可移植性(Portability)。

以ISO 9126质量模型为基础，可以构造质量度量模型。具体到静态测试，这里主要关注的是可维护性。

要衡量软件的可维护性，可以从四个方面去度量，即可分析性（Analyzability）、可改变性（Changeability）、稳定性（Stability）以及可测试性（Testability）。具体到软件的可测试性怎么去衡量呢？又可以从三个度量元去考虑，例如圈复杂度、输入/输出的个数等。圈复杂度越大，说明代码中的路径越多；路径越多，意味着要去做测试，需要写更多的测试用例。输入/输出的个数同样的道理。

在具体的实践中，专门的质量度量工具是必要的。没有工具的支持，这一步很难只靠人工完成。在这个阶段，比较专业的工具有Testbed、Logiscope等。51Testing软件测试网`G&vcDp-U

3代码错误检测——提高软件的靠性

在传统意义上认为，错误检测应该是动态的系统测试的范围。但在bug的成本上分析，有以下公认的结论。

In Boris Beizers well known analysis, the longer a fault stays in the product as it goes through the lifecycle, by a factor of 10 at each stage. This has become a cliche somewhat, but is not without foundation. If the fault can be found by the developer or colleague it will cost tens or hundreds of pounds. If a customer finds the fault, thousands of pounds may be the cost.

51Testing软件测试网(xr'~o&a%YM

bug发现的越晚，修正的成本就越高，测试阶段修正bug的成本是编码阶段的约4倍的关系。为了减少成本，bug被发现的越早越好。在编程阶段，静态的分析代码就能找到代码的bug，是很多人的梦想。这个梦想在21世纪初变成了现实。以PolySpacee、Klocwork、Coverity为代表的静态分析软件，实现了只要静态分析代码，就可以发现代码的bug，例如数组越界、除数为0、缓冲区溢出等，虽然还不是特别完美。