|
|
知识路径： > 测试技术的分类 > 白盒测试技术 > 白盒测试方法 >
|
被考次数：2次
被考频率：低频率
总体答错率：33%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：掌握
相关知识点：22个
|
|
|
|
|
代码检查包括桌面检查、代码审查和走查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等方面；发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
|
|
|
|
|
|
|
|
这是一种传统的检查方法，由程序员检查自己编写的程序。程序员在程序通过编译之后，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。
|
|
|
|
由于程序员熟悉自己的程序及其程序设计风格，桌面检查由程序员自己进行可以节省很多的检查时间，但应避免主观片面性。
|
|
|
|
|
|
代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。
|
|
|
|
代码审查分两步：第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之牵连的其他问题，甚至涉及到模块的功能说明、模块间接口和系统总体结构的大问题，从而导致对需求的重定义、重设计和重验证，进而大大改善了软件质量。
|
|
|
|
在会前，应当给审查小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高审查的实效。
|
|
|
|
这个常见错误清单也称为检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供再审查时使用。
|
|
|
|
|
|
|
|
第一步也是把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机，即首先由测试组成员为所测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。
|
|
|
|
人们借助测试用例的媒介作用，对程序的逻辑和功能提出各种疑问，结合问题开展热烈的讨论和争议，能够发现更多的问题。
|
|
|
|
代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。
|
|
|
|
在实际使用中，代码检查能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷，而且代码检查看到的是问题本身而非征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。
|
|
|
|
代码检查可以使用测试软件进行自动化测试，以利于提高测试效率，降低劳动强度，或者使用人工进行测试，以充分发挥人力的逻辑思维能力。
|
|
|
|
|
|
. 检查变量的交叉引用表：重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列、临时变量在某条路径上的重写情况，局部变量、全局变量与特权变量的使用。
|
|
|
|
. 检查标号的交叉引用表：验证所有标号的正确性，检查所有标号的命名是否正确，转向指定位置的标号是否正确。
|
|
|
|
. 检查子程序、宏、函数：验证每次调用与所调用位置是否正确，确认每次所调用的子程序、宏、函数是否存在，检验调用序列中调用方式与参数顺序、个数、类型上的一致性。
|
|
|
|
. 等价性检查：检查全部等价变量的类型的一致性，解释所包含的类型差异。
|
|
|
|
. 常量检查：确认常量的取值和数制、数据类型，检查常量每次引用同它的取值、数制和类型的一致性。
|
|
|
|
. 标准检查：用标准检查工具软件或手工检查程序中违反标准的问题。
|
|
|
|
|
|
. 比较控制流：比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档并修正错误。
|
|
|
|
. 选择、激活路径：在程序员设计的控制流图上选择路径，再到实际的控制流图上激活这条路径。如果选择的路径在实际控制流图上不能被激活，则源程序可能有错。
|
|
|
|
. 对照程序的规格说明，详细阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，从它们的差异中发现程序的问题和错误。
|
|
|
|
. 补充文档：桌面检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。管理部门也可以通过审查桌面检查文档，了解模块的质量、完全性、测试方法和程序员的能力。
|
|
|
|
根据检查项目可以编制代码规则、规范和检查表等作为测试用例，如编码规范、代码检查规则、缺陷检查表等。
|
|
|
|
|
|
编码规范是程序编写过程中必须遵循的规则，一般会详细规定代码的语法规则、语法格式等，如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在代码检查中，需要依据被测软件的特点，选用适当的标准与规则规范。在使用测试软件进行自动化代码检查时，测试工具一般会内置许多的编码规则，例如，Parasoft公司用于C/C++语言测试的C++Test，内置了5类规则：通用规则、C++编码规则、C编码规则、Meyers-Klaus规则和自定义规则。我们需要根据编程语言以及被测程序的特点，挑选适当的规则进行检查。
|
|
|
|
例如，在测试中，可以选择下表中的规则进行自动化测试，在此基础上使用桌面检查、代码走查、代码审查等人工检查的方法仔细检查程序的结构、逻辑等方面的缺陷。
|
|
|
|
|
|
|
|
|
|
在进行人工代码检查时，代码缺陷检查表是我们用到的测试用例。
|
|
|
|
代码缺陷检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误，如下所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
②当对另一个模块的每一次调用时，全部所需的参数传送给每一个被调用的模块吗？
|
|
|
|
|
|
④对关键的被调用模块的意外情况（如丢失、混乱）有处理吗？
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对应于不同的编程语言，代码缺陷检查表的具体内容将会不同。例如，针对广泛使用的C/C++语言，可以参照下表所示的代码缺陷检查表。
|
|
|
|
|
|
|
|
|
|
|
|
|
