表达式分析 :对表达式进行分析,以发现和纠正在表达式中出现的错误。包括:在表达式中不正确地使用了括号造成错误。数组下标越界造成错误。除式为零造成错误。对负数开平方,或对π求正切值造成错误。以及对浮点数计算的误差进行检查。
界面分析 :关于接口的静态错误分析主要检查过程、函数过程之间接口的一致性。因此要检查形参与实参在类型、数量、维数、顺序、使用上的一致性;检查全局变量和公共数据区在使用上的一致性。
5.2人工测试
静态分析中进行人工测试的主要方法有桌前检查、代码审查和走查。经验表明,使用这种方法能够有效地发现30%到70%的逻辑设计和编码错误。
① 桌前检查(Desk Checking)
由程序员自己检查自己编写的程序。程序员在程序通过编译之后,进行单元测试设计之前,对源程序代码进行分析,检验,并补充相关的文文件,目的是发现程序中的错误。检查项目有:
检查变数的交叉引用表 :重点是检查未说明的变量和违反了类型规定的变量;还要对照源程序,逐个检查变量的引用、变量的使用序列;临时变量在某条路径上的重写情况;局部变量、全局变量与特权变量的使用;
检查标号的交叉引用表 :验证所有标号的正确性:检查所有标号的命名是否正确;转向指定位置的标号是否正确。
检查子程序、宏、函数 :验证每次调用与被调用位置是否正确;确认每次被调用的子程序、宏、函数是否存在;检验调用序列中调用方式与参数顺序、个数、类型上的一致性。
等值性检查 :检查全部等价变量的类型的一致性,解释所包含的类型差异。
常量检查 :确认每个常量的取值和数制、数据类型;检查常量每次引用同它的取值、数制和类型的一致性;
标准检查 :用标准检查程序或手工检查程序中违反标准的问题。
风格检查 :检查在程序设计风格方面发现的问题。
比较控制流 :比较由程序员设计的控制流图和由实际程序生成的控制流图,寻找和解释每个差异,修改文档和校正错误。
选择、启动路径 :在程序员设计的控制流图上选择路径,再到实际的控制流图上启动这条路径。如果选择的路径在实际控制流图上不能启动,则源程序可能有错。用这种方法启动的路径集合应保证源程序模块的每行代码都被检查,即桌前检查应至少是语句覆盖。
对照程序的规格说明,详细阅读源代码 :程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则,仔细地阅读源代码,逐字逐句进行分析和思考,比较实际的代码和期望的代码,从它们的差异中发现程序的问题和错误。
补充文档 :桌前检查的文档是一种过渡性的文档,不是公开的正式文档。通过编写文文件,也是对程序的一种下意识的检查和测试,可以帮助程序员发现和抓住更多的错误。
这种桌前检查,由于程序员熟悉自己的程序和自身的程序设计风格,可以节省很多的检查时间,但应避免主观片面性。
② 代码会审(Code Reading Review)
代码会审是由若干程序员和测试员组成一个会审小组,通过阅读、讨论和争议,对程序进行静态分析的过程。
代码会审分两步:第一步,小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员,作为评审的依据。小组成员在充分阅读这些材料之后,进入审查的第二步:召开程序审查会。在会上,首先由程序员逐句讲解程序的逻辑。在此过程中,程序员或其它小组成员可以提出问题,展开讨论,审查错误是否存在。实践表明,程序员在讲解过程中能发现许多原来自己没有发现的错误,而讨论和争议则促进了问题的暴露。
在会前,应当给会审小组每个成员准备一份常见错误的清单,把以往所有可能发生的常见错误罗列出来,供与会者对照检查,以提高会审的实效。这个常见错误清单也叫做检查表,它把程序中可能发生的各种错误进行分类,对每一类列举出尽可能多的典型错误,然后把它们制成表格,供在会审时使用。这种检查表类似于本章单元测试中给出的检查表。
③ 走查(Walkthroughs)
走查与代码会审基本相同,其过程分为两步。第一步也把材料先发给走查小组每个成员,让他们认真研究程序,然后再开会。开会的程序与代码会审不同,不是简单地读程序和对照错误检查表进行检查,而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例,提交给走查小组。走查小组开会,集体扮演计算机角色,让测试用例沿程序的逻辑运行一遍,随时记录程序的踪迹,供分析和讨论用。
原文转自:http://www.uml.org.cn/Test/201511262.asp