(完整版)7-软件静态测试课件.ppt

1、功能测试及工具功能测试及工具焦忭忭2017.32第七讲 静态测试静态测试概论评审需求规格说明书的测试代码检查静态分析31.1.静态静态测试概论测试概论静态的和动态的主持人主持人作者记录员列席人员内审员内审员技术专业人员用户代表不正式正式轮查 互审 走读 审查会议运行程序运行程序动态测试通常是指不执行程序而寻找代码或其他的项目文档中可能存在的错误或评估程序代码的过程。静态测试概念各种与软件相关的有必要进行测试的产物，比如各类文档、源代码等。静态测试测试对象静态测试概念静态测试对象静态测试静态测试的特点：不必动态地运行程序。可以人工进行，充分发挥人的思维优势。不需要特别的条件，容易展开。对测试人员

2、要求比较高。静态测试的主要内容：手工检查（评审）静态分析 对软件工作产品（包括代码）进行测试的一种方式。可以完全以人工的方式进行，也可以引入工具的支持来运行。可以对软件工作产品进行评审，包括需求规格说明、设计规格说明、代码、测试计划、测试规格说明、测试用例、测试脚本、用户指南或web页面等。主要检查代码和设计的一致性、代码对标准的遵循、代码的可读性、代码的逻辑表达正确性，代码的合理性92.2.评审评审一、评审评审是对软件元素或项目状态进行评估的活动，用以确定与预期结果之间的偏差和相应的改进意见，一般评审包括培训评审、预备评审、同行评审。在本节中我们重点关心同行评审。软件元素包括软件开发管理人员

3、文档软件需求、软件项目计划软件开发人员文档用例、软件设计、软件规约、数据流图、数据库和文件设计、接口、安全规约、GUI设计测试人员文档测试计划、测试用例、测试环境规约、测试数据设计、测试工具的安装和操作管理员文档安装指南、操作/管理指南最终用户文档用户指南、帮助界面、培训手册同行评审是由开发软件产品作者以外的其他人检查工作产品，以发现缺陷并寻找改进的机会 评审方法是评审参与者通常采用一行一行仔细阅读被评审对象的形式发现被测对象中的缺陷 评审的时间点一般设在工作产品到达了一个完成的里程碑并即将进入下一个开发阶段时同行评审评审过程 正式评审的阶段预备会阶段计划阶段个人准备阶段评审会议阶段返工阶段跟

4、踪结果阶段计划阶段 定义评审标准 选择人员 分配角色 为更加正式的评审类型（比如审查）制定入口和出口准则 选择需要进行评审的文档的内容 核对入口准则（针对更正式的评审类型）预备会阶段（Kick off）分发文档 向评审参与者解释评审的目标、过程和文档个人准备阶段 先行评审文档，为评审会议做准备 标注可能的缺陷、问题和建议。评审会议阶段 讨论和记录，并留下文档化的结果或会议纪要（针对更正式的评审类型）标注缺陷、提出处理缺陷的建议、对缺陷作出决策。在任何形式的会议期间或跟踪任何类型的电子通信期间检查/评价和记录问题返工阶段 修改发现的缺陷（通常由作者来进行）记录缺陷更新的状态（在正式评审中）跟踪结

5、果阶段 检查缺陷是否已得到解决 收集度量数据 核对出口准则（针对更正式的评审类型）典型的正式评审主要有下面几种角色：经理：决定是否需要进行评审，在项目计划中分派时间，判断是否已达到评审的目标。主持人：主持文档或文档集的评审活动，包括策划评审、召开会议和会议后的跟踪。假如需要，主持人可能还需要进行不同观点之间的协调。主持人通常是评审成功与否的关键。作者：待评审文档的作者或主要责任人。评审员：具有专门技术或业务背景的人员（也称为检查员（checker）或审查员（inspector），他们在必要的准备后，标识和描述被评审产品存在的问题（如缺陷）。所选择的评审员应该在评审过程中代表不同的观点和角色，并

6、且应该参与各种评审会议。记录员：记录所有的事件、问题，以及在会议过程中识别的未解决的问题。评审类型 同行评审一般包括审查、小组评审、走查、桌面评审、临时评审五种类型。同行评审越正式，发现的缺陷越多，但评审越正式，花费成本越高 这些同行评审类型的区别在于正式程度，可以从图示中看到。被评审对象越重要或者风险越高，采用的评审方式就越正式临时评审桌面评审小组审查审查正式程度高正式程度低走查审查小组评审走查桌面评审临时评审非作者等专家在内的针对特定对象进行检查以发现缺陷的过程，最正式一种“轻型审查”,可采用审查的指导方针和流程是产品的作者向一组同事说明该产品，希望获得他们的意见以满足自己的需要指除作者以

7、外只有一位评审专家对工作产品进行检查请团队内其他同事帮忙，在短时间内解决一些问题，最不正式审查流程没有审查那么正式和严格没有标准的流程可循无标准流程无标准流程每个阶段需要确定的内容会议期间读者的角色由评审组长代替过程由作者主持只有一位评审专家团队同时帮忙审查原则发现问题的数量是审查的2/3比审查发现的缺陷数量要少一半发现问题较少发现问题较少场景描述评审类型 程序员A请项目经理与其一起评审自己的代码 程序员A请程序员B帮忙Review一下他写的代码 系统关键模块设计已经完成，为了降低关键模块设计的风险，设计人员组织了一次会议，并邀请了测试人员、其他开发人员、需求人员参加会议，在会上设计人员演示并

8、详细讲解了该模块的设计，从中他也得到了与会人员广泛的意见和建议 项目经理计划对软件质量进行审查，他在项目计划中该活动安排了相应的资源和时间，并指定了特定的人员负责此事。接下来，负责人根据事先制定的评审标准，核对了相关资料并通知了相应人员进行会前准备。桌面评审临时评审走查审查 经验表明，通过包括代码审查、桌面检查、代码走查、审查和技术评审在内的静态测试能够有效地发现30%-70%的逻辑设计和编码错误，而且这种方法一次能解释一批错误，同时还能对错误进行定位。253.3.需求规格说明书的测试需求规格说明书的测试二、需求规格说明书的测试规格说明书的概要评审规格说明书的详细评审问题词语列表需求规格说明书

9、的测试需求规格说明书的测试检查方式开展时间测试目的具体方法一般采用逐行阅读说明书以发现缺陷的方式规格说明书审查方法在需求阶段规格说明书整体或者部分完成后尽早地发现缺陷，使规格说明书具有更好的可测试性静态黑盒测试概要评审和对说明书进行详细评审规格说明书的概要评审 对规格说明书进行概要评审所要达到的目的是 发现特定的缺陷，比如大的原理性问题，遗漏或过度复杂的描述等 评审时，测试人员要站在用户的角度 确保作为第一质量要素的用户要求得到满足 研究现有标准和基线 对类似的软件系统进行评审和测试规格说明书的详细评审 对规格说明书进行详细评审，可从有关属性方面着手，一个好的规格说明书应具有如下属性：完整性、

10、精确性、准确性、一致性、无二义性、相关性、可行性以及代码无关性和可测试性等 检查规格说明书的同时，要关注评审的文字和图片是否具有这样的属性 问题词语列表 测试规格说明书的时候应密切关注下面的一些词汇以及这些词汇的上下文含义是否清晰。因为这些词汇常常会带来缺陷 总是、每个、所有、没有一个、从来不等 这些词表示肯定和确定的含义,必须确认该用这些词语,或找出不该使用的理由 当然、所以、明显地、无疑、显然等 这些词有劝说人接受的意思,规格书中尽量避免 一些、有时、经常、通常、大部分、主要的、等等、类似、好、快、便宜、高效、小和稳定等 这些词可测试性差，必须进一步定义以给出确切的含义描述 有把握的、处理

11、过的、拒绝的、跳过的、去掉的等 这些词可能隐藏一些本该详细说明的功能性需求 如果.那么等 这些描述依赖于其他因素，不可取 304.4.代码检查代码检查代码检查定义代码评审开展时间测试目的具体方法是以组为单位阅读代码，是一系列规程和错误检查技术的集合代码检查输出的信息代码全部或部分完成后及早发现缺陷一般采用静态“白盒”测试的方法度量标准、易产生错误的代码、代码规则的执行、流图和调用图的分析Discovery activityFaults found/1000lines of codeRequirement review2.5Design review5.0Code review10.0Integ

12、ration test3.0Acceptance tests2.0每1000行代码各阶段发现错误的个数统计表：1.完整性检查2.一致性检查5.可预测性检查代码检查内容4.可修改性检查3.正确性检查6.健壮性检查7.可理解性检查10.可追溯性检查代码检查内容9.结构性检查8.可验证性检查11.代码标准符合性检查编码规范又称代码规则、编码规则 是对程序代码的格式、注释、标识符命名、语句使用、函数、类、程序组织、公共变量等方面的要求 开发人员书写的代码更健壮、更安全、更可靠 提高代码的可读性，使代码易于查看、理解和维护 提高代码质量最有效、最直接的手段 规范分为两个级别规则和建议 规则级的规范要求开

13、发人员必须要遵守 建议级的规范开发人员应尽量遵守格式注释标识符命名对代码书写格式的要求程序中的注释是程序与日后程序读者之间通信的重要手段对标识符和文件的命名要求语句使用函数类对具体程序语句的使用要求明确函数功能等为每一个类显示定义缺省构造函数等程序组织源文件中不要有类的声明等375.5.静态分析静态分析代码的自动分析需要用到代码分析工具 代码自动分析的结果可以对照着需求和设计文档以及编码进行检查，主要进行 程序逻辑和编码检查 一致性检查 接口分析 I/O规格说明分析 数据流 变量类型检查 模块分析等 分析的结果可以作为动态测试和其他测试的必要准备代码自动分析的主要内容 生成引用表 标号交叉引用

14、表、变量交叉引用表、子程序、宏和函数表、等价表、常数表等 进行程序错误分析 变量类型和单位分析、引用分析以及表达式分析 接口分析 检查形参与实参在类型、数量、维数、顺序、使用上的一致性 检查全局变量和公共数据区在使用上的一致性 代码结构分析程序的理解是程序质量的度量、评估的基础 代码的结构形式是“白盒”测试的主要依据 研究表明程序员38%的时间花费在理解软件系统上 因为代码以文本格式被写入多重文件中，这是很难阅读理解的，需要其它一些东西来帮助人们阅读理解，如各种图表等在代码结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、内部控制逻辑等内部结构 生成函数调用关系图、模块控制

15、流图、模块数据流图、内部文件调用关系图、子程序表、宏和函数参数表等各类图形图表 可以清晰地标识整个软件系统的组成结构，使其便于阅读和理解 可以通过分析这些图表，检查软件有没有存在缺陷或错误代码结构分析函数调用关系图 函数调用关系图或程序调用关系图（被调用）是对源程度中函数调用关系的一种静态描述 在函数调用图中，节点表示函数，边表示函数之间调用关系 函数调用图在软件工作领域有广泛的应用，如编译优化，过程间数据流分析，回归测试，程序理解等函数调用关系图代码代码结构分析结构分析主要问题：程序层次性较差 存在直接和间接的递归调用 重要资源被众多模块使用代码结构分析模块控制流图与程序流程图相类似，显示了

16、一个函数的内部逻辑结构。-由许多节点和连接节点的边组成，节点代表一条或数条语句，边代表节点间控制流向。-可以直观地反映出一个函数的内部逻辑结构，通过检查这些模块控制流图，能够很快发现软件的错误与缺陷。模块控制流图代码结构分析主要问题：死代码 使用了GOTO语句 代码重复 开关语句结构有问题代码结构分析模块数据流图 在单元测试中，数据仅仅在一个模块或者一个函数中流动 但数据流的通路往往涉及多个集成模块，甚至于整个软件 我们有必要进行数据流的分析，尽管它非常耗时 数据流分析技术最早被用于编译优化，目前在程序测试、程序理解、程序验证、程序调试以及程序分片等许多领域，数据流都有着广泛的应用 特别是近年

17、来数据流分析方法在确认系统中也得到成功应用 用以查找如引用未定义变量等程序错误 也可以用来查找对以前未曾使用的变量再次赋值等数据流异常的情况 找出这些错误是很重要的，因为这常常是常见程序错误的表现形式 如错拼名字、名字混淆或是丢失了语句代码结构分析控制流图及其定义和引用的变量1234101175689节点节点被定义变量被定义变量被引用变量被引用变量1X,Y,Z2XW,Y3X,Y4Y,Z5YV,Y6ZV,Z7VX8WY9ZV10ZZ11Z代码安全性检查代码安全性是指代码运行或被别人调用时产生错误的容易程度 如C+，它规定了严格的语法，然而又有其灵活性 这种灵活性增加了程序的不可预见性，有可能导致

18、故障的发生，致使代码的安全性变差 指针的指向发生错误，则直接导致结果错误 指针的指向越界，可能导致缓冲区溢出，很多病毒就是利用缓冲区溢出对电脑进行攻击的 C+提供的很多函数没有对参数范围进行限制和检查，这也很容易导致错误的发生 代码安全性检查或静态错误分析主要用于确定在源程序中是否有某类错误或“危险/不安全”的结构 一般可借助工具来对代码的安全性检查代码安全性检查（续）代码安全性是指代码运行或被别人调用时产生错误的容易程度 代码安全性检查或静态错误分析主要用于确定在源程序中是否有某类错误或“危险/不安全”的结构对代码进行安全性检查大致有四种方法:对变量类型和单位进行检查对变量引用进行检查对表达式运算进行检查接口分析代码安全性检查（续）代码安全性检查关注的错误：坏的存储分配 内存泄漏 指针引用 约束检查 变量未初始化 错误逻辑结构 其他 THE END