资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,1,测试基础,静态测试,测试基础 静态测试,概述,评审,代码检查,2,测试基础 静态测试,静态测试,该方法是指在不真正运行被测试程序的情况下检查程序的运行情况,只对被测对象,(,设计或代码,),进行特性分析。,因此,静态测试常称为,“,分析,”,,静态分析是对被测对象进行特性分析的一些方法的总称。,主要特征,不动态运行程序;,充分发挥人的思维优势;,易开展,不需特别条件,但可能非常耗时;,对测试人员要求较高,要有编程经验,需要有知识和经验的积累,能发现问题本身而非征兆。,3,测试基础 静态测试,为什么要静态测试,因软件的复杂性,可能导致软件结构不够合理、混乱,代码编写不够规范,内部存在一些不易察觉的错等,使软件运行出错,维护不便。,静态测试内容,主要包括:各阶段的文档评审、代码检查、代码度量等。,静态测试可由人工进行,也可借助软件工具自动进行。,可以做静态分析的工具很多,出名的有,LOGICSCOPE,,,C+,TEST,,,LDRA,TESTBED,,,PRQA,C/C+,,,MACABE,IQ,,以及,Rational,的,Purify,、,Quantify,和,PureCoverage,等,4,测试基础 静态测试,概述,评审,代码检查,5,静态测试,评审,评审是对所有人工静态分析和具体文档检查技术的通称。,评审对象:开发项目中所有文档及项目外有价值的文档。,如:合同、需求定义、设计规格说明、程序代码、测试计划和手册等。,评审是一种保证质量的方法,评审的积极作用,可降低消除缺陷的成本,可缩短开发时间,可减少动态测试时间和成本,可减少系统安装后的变更申请,降低系统运行故障率,检查团对活动,改进团队成员的工作方法,6,静态测试,评审潜在的问题,注意不要使作者感到严格检查是针对他人而非他提交的文档。,评审的成本和收益,评审的成本大概占整个开发预算的,10%15%,包括评审过程、评审分析和过程改进的工作量。估计节约的成本约为,14%25%,。(,参见:,Bush,M.,“,Software Quality:The use of formal inspections at the Jet Propulsion Laboratory,”,,Proceedings,of,the,12,th,ICSE,IEEE,1990,pp,196-199.,),如评审有效,应能发现,70%,以上的文档缺陷。(,参见:,Gilb,,,T.,,,Graham,D.,;,Software,Inspections,,,Addison-wesley,1996,),7,静态测试,能促使评审成功的因素(,IEEE,1028,建议),每次评审都事先定于一个明确的目标;,根据每个人的知识和技能水平选择合适的评审参与者。,8,静态测试,通用评审过程(,参考:,IEEE,1028,),评审活动分,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.:Handbook,of,Walkthroughs,Inspections,and,Technical,Reviews:Evaluating,Programs,Projects,and,Products,3,rd,ed.,Dorset,House,1990,),15,测试基础 静态测试,概述,评审,代码检查,16,静态测试,代码检查,主要检查代码和设计的一致性,代码对标准的遵循、可读性,代码的逻辑表达的正确性,代码结构的合理性等方面;以期发现违背编程标准或编程风格问题,程序中不安全、不明确和模糊部分,程序中不可移植部分等。,代码检查在编译和动态测试前进行,在检查前,应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。,代码检查包括:,桌面检查、代码审查、代码走查,等。,17,18,静态测试,桌面检查(,Desk Checking,),由程序员自查。程序员在程序通过编译之后,进行单元测试设计之前,对源程序代码进行分析,检验,并补充相关文档。检查项目有:,检查变量的交叉引用表,重点是未说明的变量和违反了类型规定的变量;,逐个检查变量的引用、变量的使用序列;,临时变量在某条路径上的重写情况;,局部变量、全局变量与特权变量的使用;,19,静态测试,-,桌面检查,检查标号的交叉引用表,检查验证所有标号的正确性:命名是否正确;转向指定位置的标号是否正确。,检查子程序、宏、函数,验证每次调用与被调用位置是否正确;,被调用的子程序、宏、函数是否存在;,检验调用序列中调用方式与参数顺序、个数、类型上的一致性。,等值性检查,检查全部等价变量的类型的一致性,解释所包含的类型差异。,20,静态测试,常量检查,确认每个常量的取值和数制、数据类型;,检查常量每次引用同它的取值、数制和类型的一致性;,标准检查,检查违反标准的问题。,比较控制流,比较由程序员设计的控制流图和由实际程序生成的控制流图,寻找和解释每个差异,修改文档和校正错误。,21,静态测试,选择、激活路径,在程序员设计的控制流图上选择路径,再到实际的控制流图上激活这条路径。如果选择的路径在实际控制流图上不能激活,则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查,即桌前检查应至少是语句覆盖。,风格检查,检查在程序设计风格方面发现的问题。,对照程序的规格说明,详细阅读源代码,程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则,仔细地阅读源代码,逐字逐句进行分析和思考,比较实际的代码和期望的代码,从它们的差异中发现程序的问题和错误。,22,静态测试,补充文档,桌前检查的文档是一种过渡性的文档,不是公开的正式文档。通过编写文档,也是对程序的一种下意识的检查和测试,可以帮助程序员发现和抓住更多的错误。,这种桌前检查,由于程序员熟悉自己的程序和自身的程序设计风格,可以节省很多的检查时间,但应避免主观片面性。,23,静态测试,代码审查(,Code Reading Review,),代码审查是由若干程序员和测试员组成一个会审小组,通过阅读、讨论和争议,对程序进行静态分析的过程。代码审查分两步:,第一步,小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员,作为评审的依据。小组成员在充分阅读这些材料之后,进入审查的第二步。,第二步:召开程序审查会。在会上,首先由程序员逐句讲解程序的逻辑。在此过程中,程序员或其他小组成员可以提出问题,展开讨论,审查错误是否存在。实践表明,程序员在讲解过程中能发现许多原来自己没有发现的错误,而讨论和争议则促进了问题的暴露。,24,静态测试,在会前,应当给会审小组每个成员准备一份常见错误的清单,把以往所有可能发生的常见错误罗列出来,供与会者对照检查,以提高会审的实效。这个常见错误清单也叫做检查表,它把程序中可能发生的各种错误进行分类,对每一类列举出尽可能多的典型错误,然后把它们制成表格,供在会审时使用。,下面列出了代码检查应查找的问题,25,静态测试,源代码格式:是否符合编程标准或规范?,程序语句的使用,数据引用错误,数据声明错误,计算错误,比较错误,接口错误,控制流程错误,输入输出错误,逻辑和性能,维护性和可靠性,26,静态测试,走查(,Walkthroughs,),走查与代码会审基本相同,其过程分为两步。,第一步也把材料先发给走查小组每个成员,让他们认真研究程序,然后再开会。开会的程序与代码会审不同,不是简单地读程序和对照错误检查表进行检查,而是让与会者,“,充当,”,计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例,提交给走查小组。走查小组开会,集体扮演计算机角色,让测试用例沿程序的逻辑运行一遍,随时记录程序的踪迹,供分析和讨论用。,第二步 人们借助于测试用例的媒介作用,对程序的逻辑和功能提出各种疑问,结合问题开展热烈的讨论和争议,能够发现更多的问题。,走查时注意时限(避免跑题,不针对某问题无休止讨论)和避免现场修改。,
展开阅读全文