软件静态测试方法

软件静态测试方法“审查”述评

黄锡滋 张昊

软件测试在软件开发过程中具有非常重要的作用。软件测试的实质在于，按照规定步骤采用有效方法，对程序进行严格的检验，发现和改正软件的各种差错，提高软件质量，使其逐步达到规定要求，交付用户使用。

经过几十年的发展，软件测试方法体系业已经形成，软件项目开发机构可以结合实际需要选择使用。软件测试方法，按照是否在计算机上运行被测软件，区分为静态测试和动态测试两大类。图1是软件测试技术分类框架。

图1 软件测试技术分类框架图

长期以来，动态测试是最为业界推崇的方法，有时甚至是项目采用的唯一方法。静态测试则被多数开发团队忽视。

一、 从费用效益看软件测试

动态测试方法走红和静态测试冷落所导致的弊端，终于逐渐被业界察觉，其中最具警示性的事件，当属权威性的美国国家标准技术研究所（NIST），在2002

年发表的题为‘不适当的软件测试基础结构的经济影响’研究报告1]，该报告对美国软件开发弊端提出尖锐批评。报告说：

“。。。。。。虽然所有错误不可能完全消除，超过1/3的费用或估计达220亿美元的费用是可以节省的。用改善测试的基础结构，采用评审（Review），审查(Inspection)等方法，可以更早，更有效地识别和消除软件错误。使用这些方法可以在接近错误注入的时刻，用很大的百分比（虽然不是100%）识别和消除错误。现在的情况是有超过半数的错误在进入测试阶段之前无法发现，甚至拖延到销售给用户使用之后”。

Bennett的工作进一步验证了NIST关于早期发现和改正错误，可以带来极大经济效益的论断2]。图2显示了错误发现阶段和错误注入阶段，改正一个软件错误所需要的相对费用。

图2 软件排错费用图

由此可见静态测试技术的最大优点恰好是它能够及早发现和改正错误，从而带来可观的经济效益。常用的静态测试方法有审查（Inspection）和走查（Walk Through）两种，其中审查（Inspection）比较正规，颇具潜力。

二、怎样正确实施审查

（一） 审查的定义

IEEE Std 610.12-1990 3]定义，审查（Inspection）是指：“一种静态分析技术，它依靠目视检查开发的产品，发现错误、发现和开发标准的偏离以及其它问题，典型的审查类型包括编码审查，设计审查”。

IEEE Std 1028-1997 4]对审查的内容有更具体的描述：

审查的目的是探测和识别软件产品的反常现象，是一种系统的目视检查，审查用来：

a) 验证软件产品满足规格说明；

b) 验证软件产品满足规定的质量属性；

c) 验证软件产品符合适用的规章、标准、指南、计划和程序；

d) 识别对标准和规格说明的偏离；

e) 收集软件工程数据，（例如异常的或投入的时间和人力数据）(可选择)）。 f) 使用收集的软件工程数据，改进审查过程本身和它的支持文档（例如检查表）（可选择）

这里提及的软件产品包括：软件需求规格说明； 软件设计说明 ；源代码；软件测试文档；软件用户文档；维护手册；系统构建程序；安装程序；发布注释。

（二） 审查实施过程

软件审查方法源于上世纪70年代，由IBM的质量控制专家Fagan.提出和实施，起因是他力图将统计抽样质量控制技术引用到软件发过程。Fagan认为软件寿命周期过程等同于产品生产线，审查类似于抽样载体，用来在软件开发早期进行产品抽样。随后，审查逐步发展成为一个独立的质量检查过程。

1. 审查队成员组成

审查队通常由5人组成，包括领导人，记录员，阅读员，软件产品作者，检查员。各有明确职责。

领导者：承担审查过程的全部管理责任。

记录员：记录软件异常、决策、建议、用于过程分析的审查数据。领导者可以是记录员。

阅读员：用广泛的合理的方式，引导审查团队透彻领悟软件产品，解释某些关键部分的重要特征。审查队领导者可以担任阅读员。

软件产品作者：负责使软件产品达到审查的准入标准。用自己对软件产品的

特殊理解为审查队提供帮助，承担审查要求的修改使其满足审查通过标准。

审查员：负责识别和阐述软件产品异常。审查员应该从具有不同观点的专业人士中选择，例如产品发起人，需求分析人员，设计人员，编码人员，安全性分析人员，测试人员，项目管理人员，质量管理人员，硬件工程师等，

2. 审查步骤

1）管理准备:项目经理应该保证审查符合应用标准和程序。符合法律，合同和相关政策的要求。

2）制定审查规划

软件产品作者汇总审查材料，提供给审查队领导人；

审查队领导人给队员分配任务；

安排会议日程，选择会议地点。分配资料给参与人等。

3）提交审查产品总揽

软件产品作者汇总和编制软件产品总揽资料，提交给审查队。

4）技术准备

审查队人员提前研究软件产品和相关资料，记载在发现的异常，提交给领导人；

领导人制定异常类别，并将异常及其类别转交产品作者；

领导人安排产品审查顺序；

阅读人应确保能够在预定的审查会议上对审查提供正确引导。

5）检查

正式召开审查会议，对软件产品进行审查。审查按下列步骤进行：

a) 情况介绍会议

b) 会外准备

c) 评审公共项目

d) 评审软件产品和记录异常

e) 评审异常表

f) 作出结束决定

g) 返工或继续深入审查

三 专家和企业界对审查的评价

1. 专家评价

下面我们引用近期部分软件工程专家对“审查”技术研究的评价。

1） “审查对质量、费用、进度的正面影响的数据是毫无疑义的，他们是高质量软件工程不可分割的部分”。5]

2） “审查的确是一个关键课题，在采用正确的方法和培训时，它是一种最有效的缺陷检测技术。特别是作为一种前端技术使用，它既有效率又节省费用。除大规模的应用程序外，我们正在应用它到较小的应用程序和增量开发中”。5]

3） “审查不断的证明能够产生10比1的投资回报，……，非常郁闷的是只有很少的从业人员懂得这种源于30年前的软件检查技术，只有很少的项目进行有效的审查和一些其他类型的目视检查”。6]

4） “审查的缺陷移出有效率超过95%，但是部分的问题是没有多少公司知道如何使用这些技术”。7]

2. 实际应用中的问题

尽管软件工程专家对审查给出高度评价，许多软件开发企业仍然心存疑虑，其中显然存在认识误区，同时也存在若干实际问题。主要是：

1） 审查耗用时间较长，在项目日程紧张约束下，很难安排充分的时间用于审查。

2） 规定的审查方法和程序过分僵硬，缺乏弹性。

3） 缺少支持审查的有效工具。

业界人士认为，正是由于这些问题的存在，使预期的开发费用节省不能实现；预期的质量改进目标无法全部实现；预期的节省维护费用不能实现。

五 改进方向

Roger Stewart 针对存在的问题提出了改进审查方法的意见，其要点在于改进开发过程和审查方法的基础结构。8]

1. 完善开发环境和基础结构

1）首先需要选择一个适合项目开发的模型，例如瀑布模型，螺旋模型；

2）其次是明确定义项目开发的寿命周期；

3）与项目开发的全部机构对开发模型和寿命周期达成共识；

4）选择确定用于计划、数据收集、报告、监控、跟踪的工具。

2. 优化审查的使用范围，建立一个富有弹性的，优化的审查过程

在没有充分时间和人力将审查用于软件寿命期全过程的条件下，需要对审查的使用范围加以优化。在项目开发的寿命周期中，首选的应用阶段是需求定义和设计阶段，因为这两个阶段注入的错误如果流转到后继阶段，改正错误的费用，将大幅度增加。在编码阶段，可以重点提倡选择若干关键区域进行审查。图3显示了这个优选过程。

图3 审查优化图

3. 完善审查技术基础结构 开发供审查使用的计算机辅助工具

1）开发用于审查计划编制和费用预计的计算机辅助工具。

2）开发用来帮助审查人员实施审查和收集相关数据的计算机辅助工具。

3）开发监控审查过程和审查后的评估工具。

4）开发用来分析审查投资回报的管理工具和各种评估计算跟踪项目费用结余的工具。

4. 编制各种类型的培训教材，提高项目开发人员的技术水平

1）提供通用的包括专用术语的审查过程培训教材。

2）提供面向项目参加者的大范围的1至2天的快速培训教材。

3）为上层管理人士提供审查技术概要，同时提供更严格的管理实施教程。

4）坚持从业人员的知识更新，应对处理执实施中出现的问题（包括短期和长期），使审查成功。

参考资料

[1] NIST. “The Economic Impacts of Inadequate Infrastructure for Software Testing.” NIST Planning Report 02-3. May 2002.

[2] Bennett, Ted L.,. “Eliminating Embedded Software Defects Prior to Integration Test.” CrossTalk Dec. 2005.

[3] Software Engineering Standards Committee of the IEEE Computer Society. “. IEEE Standard Glossary of Software Engineering Terminology ” lEEE Std 610.12-1990，1990

[4] Software Engineering Standards Committee of the IEEE Computer Society. “IEEE Standard for Software Reviews, Section 6. Inspections.” IEEE Std. 1028-1997, 1997.

[5] McConnell, Steve. “Best Influences on Software Engineering Over Past 50 Years.” IEEE Software Jan./Feb. 2000.

[6] 4. Wiegers, Karl. “The More Things Change.” Better Software Oct. 2006.

[7] 5. Jones, Capers. “Interview.” Computer Aid Inc. July 2005.

[8] Roger Stewart and Lew Priven “How to Avoid Software Inspection Failure and Achieve Ongoing Benefits“CrossTalk Jan. 2008.