4测试基础静态测试PPT资料.ppt

4测试基础静态测试PPT资料.ppt

《4测试基础静态测试PPT资料.ppt》由会员分享，可在线阅读，更多相关《4测试基础静态测试PPT资料.ppt（26页珍藏版）》请在冰豆网上搜索。

开发项目中所有文档及项目外有价值的文档。

如：

合同、需求定义、设计规格说明、程序代码、测试计划和手册等。

评审是一种保证质量的方法评审的积极作用可降低消除缺陷的成本可缩短开发时间可减少动态测试时间和成本可减少系统安装后的变更申请降低系统运行故障率检查团对活动，改进团队成员的工作方法,6,静态测试,评审潜在的问题注意不要使作者感到严格检查是针对他人而非他提交的文档。

评审的成本和收益评审的成本大概占整个开发预算的10%15%,包括评审过程、评审分析和过程改进的工作量。

估计节约的成本约为14%25%。

（参见：

BushM.“SoftwareQuality:

TheuseofformalinspectionsattheJetPropulsionLaboratory”，Proceedingsofthe12thICSE,IEEE1990,pp196-199.）如评审有效，应能发现70%以上的文档缺陷。

Gilb，T.，Graham,D.；

SoftwareInspections，Addison-wesley,1996）,7,静态测试,能促使评审成功的因素（IEEE1028建议）每次评审都事先定于一个明确的目标；

根据每个人的知识和技能水平选择合适的评审参与者。

8,静态测试,通用评审过程（参考：

IEEE1028）评审活动分6个步骤：

计划、概述、准备、检查（评审会议）、返工和跟踪。

计划要评审的文档；

评审技术；

估算评审工作量；

评审检查点；

组建评审团队；

确保文档处于一个可评审状态；

会议的时间和地点（如有的话）等。

概述（开工会）为参加评审的人提供所有必需信息。

准备评审人必须各自为评审会议做准备。

9,静态测试,检查（评审会议）会议应有主持人。

目的除了发现缺陷外，还包括判断评审对象是否满足需求以及是否符合标准。

评审会议的一些通用准则：

1）评审会议的时间限制在2小时内；

2）如有评审人缺席或准备不充分，主持人有权取消或中止会议；

3）检查对象是被提交的文档，而非作者；

评审人必须注意他们的言语及表达方式作者不应为自己或文档辩护4）主持人不应同时作为评审人；

10,静态测试,检查（评审会议）（续）5）不讨论常见的风格问题（方针之外的问题）；

6）开发方案和对应的讨论不是评审团队的任务；

7）每个评审人员必须有机会充分表达他们的论点；

8）会议纪要必须完整表达评审人的意见；

9）问题不应以命令的形式写给作者；

10）问题必须划分为不同的权重：

严重缺陷、重要缺陷、一般缺陷、好的；

11）评审团队应对评审对象给出最后意见：

接受（无需修改）有条件接受（需修改，但不需进一步评审）不接受（需进一步评审或其他的检查）,11,静态测试,检查（评审会议）（续）12）要有会议纪要及总结包括会议中讨论的问题或发现问题的列表，评审总结报告等。

返工经理决定接受评审团队意见修正缺陷，或选择另外的方法（经理必须对此全权负责）跟踪专人跟踪缺陷的修改。

12,静态测试,评审角色和职责经理确保文档、必需的资源可用，同时选择评审人；

经理不一定得是管理层人员（导致大家“人心恍惚”）主持人管理评审有关的工作：

计划、准备并保证评审有序进行且满足它的目标，收集评审数据、发布评审报告等。

作者文档的创建者，如为多人，应是主要负责人。

不要把针对文档的问题看作是对其人的批评，作者必须明白评审只是用来帮助改进产品。

（接下页）,13,静态测试,角色和职责评审人通常最多5个。

他们应能识别并描述评审对象中存在的问题。

为保证有效的覆盖率，可给评审人分配制定的评审主题。

记录员记录所有的发现：

问题、采取的措施、决定和建议等。

文字应简短和准确。

最好由文档作者来担当。

14,静态测试,评审失败的可能原因：

需要的人没空或不具备必须的资格和技术技能。

管理层在资源计划时不准确的估计准备不足。

文档不足缺少管理层支持（在下述文献中详细描述了解决这些问题的方法：

Freedman,D.P.,Weinberg,G.M.:

HandbookofWalkthroughs,Inspections,andTechnicalReviews:

EvaluatingPrograms,Projects,andProducts,3rded.,DorsetHouse,1990）,15,测试基础静态测试,概述评审代码检查,16,静态测试,代码检查主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；

以期发现违背编程标准或编程风格问题，程序中不安全、不明确和模糊部分，程序中不可移植部分等。

代码检查在编译和动态测试前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。

代码检查包括：

桌面检查、代码审查、代码走查等。

17,18,静态测试,桌面检查（DeskChecking）由程序员自查。

程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析，检验，并补充相关文档。

检查项目有：

检查变量的交叉引用表重点是未说明的变量和违反了类型规定的变量；

逐个检查变量的引用、变量的使用序列；

临时变量在某条路径上的重写情况；

局部变量、全局变量与特权变量的使用；

19,静态测试-桌面检查,检查标号的交叉引用表检查验证所有标号的正确性：

命名是否正确；

转向指定位置的标号是否正确。

检查子程序、宏、函数验证每次调用与被调用位置是否正确；

被调用的子程序、宏、函数是否存在；

检验调用序列中调用方式与参数顺序、个数、类型上的一致性。

等值性检查检查全部等价变量的类型的一致性，解释所包含的类型差异。

20,静态测试,常量检查确认每个常量的取值和数制、数据类型；

检查常量每次引用同它的取值、数制和类型的一致性；

标准检查检查违反标准的问题。

比较控制流比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档和校正错误。

21,静态测试,选择、激活路径在程序员设计的控制流图上选择路径，再到实际的控制流图上激活这条路径。

如果选择的路径在实际控制流图上不能激活，则源程序可能有错。

用这种方法激活的路径集合应保证源程序模块的每行代码都被检查，即桌前检查应至少是语句覆盖。

风格检查检查在程序设计风格方面发现的问题。

对照程序的规格说明，详细阅读源代码程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则，仔细地阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，从它们的差异中发现程序的问题和错误。

22,静态测试,补充文档桌前检查的文档是一种过渡性的文档，不是公开的正式文档。

通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。

这种桌前检查，由于程序员熟悉自己的程序和自身的程序设计风格，可以节省很多的检查时间，但应避免主观片面性。

23,静态测试,代码审查（CodeReadingReview）代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。

代码审查分两步：

第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。

小组成员在充分阅读这些材料之后，进入审查的第二步。

第二步：

召开程序审查会。

在会上，首先由程序员逐句讲解程序的逻辑。

在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。

实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。

24,静态测试,在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。

这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。

下面列出了代码检查应查找的问题,25,静态测试,源代码格式：

是否符合编程标准或规范？

程序语句的使用数据引用错误数据声明错误计算错误比较错误接口错误控制流程错误输入输出错误逻辑和性能维护性和可靠性,26,静态测试,走查（Walkthroughs）走查与代码会审基本相同，其过程分为两步。

第一步也把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。

开会的程序与代码会审不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机。

即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。

走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。

第二步人们借助于测试用例的媒介作用，对程序的逻辑和功能提出各种疑问，结合问题开展热烈的讨论和争议，能够发现更多的问题。

走查时注意时限（避免跑题，不针对某问题无休止讨论）和避免现场修改。