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