3.1 静态测试.ppt

1、软件测试静态测试,计算机学院软件工程系 Email:Xiahui_ TelphoneQQ:79003370(不聊天),静态测试概述,定义：静态测试是基于期望属性、专业经验、通用标准来对工作件的特征进行详细检查的一种测试方法。 工作件：也就是静态测试的测试对象，是不同种类的产品交付 件，即一切项目过程文档，例如系统设计说明书、产品需求文档、开发设计文档（详细设计说明书、数据库设计说明书）、源代码以及测试文档。,静态测试和动态测试,静态测试（人工测试） 不运行程序进行测试，即检查和审阅 静态黑盒测试检查产品说明书 静态白盒测试检查代码，在不执行的条件下有条理地仔细审查软件

2、设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构分析。 动态测试（基于计算机的测试） 运行和使用软件以发现错误，即通常意义上的测试,静态测试概述,静态测试的优点 加深对项目的理解，使测试计划和测试设计质量得到提高； 使得测试用例全面、有效，从“撞问题”转变为有目的的“找问题” 提前了对项目的理解，减少了测试执行时的摸索时间，从而加快测试进度 提前发现问题（尤其是设计问题），避免项目走弯路，降低缺陷修复成本、回归测试成本以及沟通成本，同时降低项目风险，减轻测试执行时的压力,静态测试概述,实际使用中，静态代码检查比动态测试更有效率，更能快速找到缺陷。按经验估算，一般能发现30%70%的逻

3、辑设计和编码错误的缺陷。但是静态代码检查非常耗费时间，而且代码检查需要丰富的知识和经验积累。,静态白盒测试一般面临的情况是不能善始善终，因为小组会认为不太好使，费用太高，没有产出。 原因是人们认为程序员的任务就是编写代码，而任何破坏代码编写效率的事情都会减缓开发过程。,静态测试概述,静态测试的方法主要有代码检查法、静态结构分析法等。,代码检查法 包括桌面检查、代码审查、代码走查和技术评审等。主要检查代码的设计是否一致性、代码是否遵循标准性和可读性、代码的逻辑表达是否正确性、以及代 码结构是否合理性等。 静态结构分析法 一种计算机辅助的静态分析方法。主要是以图形的方式表现程序的内部结构，例如函数

4、调用关系图、函数内部控制流图。 静态分析的对象是软件 程序，程序设计语言不同，相应的静态分析工具也就不同。,代码检查法,代码检查包括 桌面检查（Desk Checking） 代码审查（Inspection） 代码走查（Walk through） 技术评审（Review） 当然在实际工作，我们完全不必要被概念所束缚住，而应根据项目的实际情况来决定采取哪种静态测试形 式，不用严格去区分到底是代码走查，代码审查和还是技术评审。,静态测试-桌面检查,桌面检查：由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析，检验，并补充相关的文档，目的是发现程序中的

5、错误。 检查内容： 变量和标识符的交叉引用 子程序、函数、宏的调用、参数 等价性检查 常量检查，常量的取值、数据类型 设计标准检查 风格检查 路径检查,静态测试-桌面检查,由于程序员熟悉自己的程序及其程序设计风格，可以节省很多的检查时间，但应避免主观片面性。这种检查应在软件开发早期实施，最好在设计编码之后、系统测试之前使用。桌面检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。管理部门也可以通过审查桌面检查文档，了解模块的质量、完全性、测试方法和开发人员的能力。,静态测试-代码审查和走查,代码审查 由若干程序

6、员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。 优点 比桌面检查更有效 一旦发现错误，通常就能在代码中对其进行精确定位，降低调试成本。 可以发现成批同一类型错误并得以修正。,静态测试-代码审查和走查,代码审查小组人员(4人组成最佳) 协调人、编码人员、模块的设计人员、一名测试专家 协调人职责 为代码审查分发材料(程序清单、设计规范)，安排进程 在代码审查过程中起主导作用 记录发现的所有错误 确保所有错误随后得到改正,静态测试-代码审查和走查,代码审查过程： (1)协调人提前把代码审查常见错误列表、设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员

7、，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。 常见错误列表：把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。,静态测试-代码审查和走查,代码审查过程： (2)召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。,协调人要确保会议高效进行，参

8、与者将注意力用于查找错误而不是修正错误。修正错误由程序员在会后完成。,会议结束后，程序员得到一份已发现错误清单。如果错误太多或程序要做根本改动，协调人可以再安排一次审查。,静态测试-代码审查和走查,会议理想时间为90-120分钟。时间越长，效率越低。 审查按150行/小时速度进行。 每次会议审查一个或几个模块或子程序。 为了使每个人都采取建设性态度，最好对审查结果进行保密，仅限于参与者内部。如果让管理人员做为考评依据，则与检查过程的目的背道而驰。,静态测试-代码检查和走查,代码审查常见错误列表 (1) 检查代码和设计的一致性； (2) 代码的可读性以及对软件设计标准的遵循情况； (3) 代码逻

9、辑表达的正确性； (4) 代码结构的合理性； (5) 程序中不安全、不明确和模糊的部分； (6) 编程风格方面的问题等。,静态测试-常见错误列表,针对代码的常见错误列表 数据引用错误 数据声明错误 运算错误 比较错误 控制流程错误 接口错误 输入输出错误 其它检查,针对代码的常见错误列表,1.数据引用错误 变量使用前是否赋值或初始化？ 容易引起变量使用错误，特别是对于指针或引用变量。 在java中要求变量在使用前必须初始化。 数组下标的范围和类型 是否存在下标越界错误，下表类型是否为整型。 通过指针引用的内存单元是否存在（虚调用）？ 如在函数返回局部变量的指针或引用时会产生虚调用错误。 被引用

10、的变量或内存的属性是否与编译器预期的一致？ 如A类型的指针或引用是否指向的是非A类型对象。,针对代码的常见错误列表,2.数据声明错误 是否所有变量都已声明？ 绝大多数编程语言要求变量先定义后使用，可保证变量使用的安全性。 默认的属性（默认值）是否正确？ 变量的初始化是否正确？变量的初始化是否与其存储空间的类型一致？ 是否每个变量都有正确的长度、类型和存储类别？ 是否存在相似名称的变量？,3.运算错误 是否存在非算术变量之间的运算？ 是否存在混合模式的运算？（ int与float类型，例） 是否存在不同字长变量之间的运算？（int与long类型） 目标变量大小是否小于所赋值的大小？（精度损失或越

11、界错误） 中间结果是否上溢或下溢？ 是否存在除0错误？ 操作符的优先顺序是否正确？ 整数除法是否正确？（精度问题，如2*（i/2）=i）,针对代码的常见错误列表,针对代码的常见错误列表,int x = 1; int y = 2; float z = 0; z = x/y; System.out.println (z = z); OUTPUT: z = 0,针对代码的常见错误列表,4.比较错误 是否有不同类型数据的比较运算？（如日期与数字） 是否有混合模式或不同长度数据的比较运算？ 比较运算符是否正确？（如至多、至少，不小于） 布尔表达式（与、或、非）是否正确？ 比较运算符是否与布尔表达式相混合

12、？（如2z)）,5.控制流程错误 是否所有循环都能终止？（循环结束条件是否能满足以及递归的终止条件是否能满足。） 是否存在由于入口条件不满足而跳过循环体？（do-while循环，例） 是否存在仅差一个的循环错误？（如for(int i=0;i=10;i+)） 程序结构中括号是否匹配、if,else是否匹配、do,while是否匹配、try,catch是否匹配等。,针对代码的常见错误列表,针对代码的常见错误列表,for (i=x ; i=z; i+) . while (NOTFOUND) . ,针对代码的常见错误列表,6.接口错误 形参和实参的数量是否相等？ 形参的属性是否与实参的属性相匹配？

13、形参的属性是否与实参的顺序相匹配？ 形参的单位是否和实参匹配？（属逻辑错误） 是否改变了某个仅作为输入值的形参？（C+中的const关键字） 全局变量的定义是否一致？,7.输入输出错误 文件属性是否正确？ 打开文件的语句是否正确？ 缓冲区、内存大小是否足够来保留程序将读取的文件？ 文件在使用前是否打开？ 文件在使用后是否关闭了？ 文件结束条件是否本正确处理？ 是否处理了IO错误？ 打印或输出的文本信息中是否存在拼写或语法错误？即输出结果正确性。,针对代码的常见错误列表,针对代码的常见错误列表,8.其他检查 是否存在未引用过的变量？ 每个变量的属性和赋予的默认值是否一致？ 编译通过的程序是否存在

14、“警告”或“提示”信息？ 程序或模块是否对输入的合法性进行了检查？（如三角形的边的合法性） 程序是否遗漏了某个功能？,静态测试-代码走查,走查与代码会审基本相同，其过程分为两步。 (1)把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码会审不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。 (2)人们借助于测试用例的媒介作用，对程序的逻辑和功能提出各种疑问，结合问题开展

15、热烈的讨论和争议，能够发现更多的问题。,静态测试-评审,它更为正式，且将管理作为它的一个组成部分。审查的目的是为管理者、用户和其他希望开发过程满足适当要求的人提供依据。在评审中，开发人员提供信息以说明开发是按预算和计划进行的，且产生了期望的结果。评审将功能放置在监督级，而不仅仅是技术级。评审更重视产品的质量，而不仅仅是验证其正确性。 评审组常常关注开发策略和开发过程，及合理的假设。评审还验证是否使用了合适的建模方法，以及结果模型的文档是否规范。,静态测试-静态结构分析法,在静态结构分析中，测试人员通常通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形、图表，清晰地标识整个软件的组成结构。 通过分析这些图表，包括控制流分析、数据据流分析、接口分析、表达式分析等，使其便于阅读与理解，然后可以通过分析这些图表，检查软件有没有存在缺陷或错误。,静态测试-静态结构分析法,静态结构分析法通常采用以下一些方法进行源程序的静态分析： (1) 通过生成各种图表，来帮助对源程序的静态分析 标识符交叉引用表 变量交叉引用表 子程序（宏、函数）引用表 等价表 常数表,静态测试-静态结构分析法,常用的的各种关系图、控制流图主要有：