ch9静态测试技术.ppt
《ch9静态测试技术.ppt》由会员分享,可在线阅读,更多相关《ch9静态测试技术.ppt(93页珍藏版)》请在三一办公上搜索。
1、-静态测试技术,软件测试与质量保证,软件测试与质量保证,董瑞志常熟理工学院计算机科学与工程学院http:/Email:,内容提要,静态测试技术桌面检查代码审查代码走查技术评审静态测试的内容需求定义的静态测试设计文档的静态测试源代码的静态测试程序静态分析检查表,静态测试的定义,不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。静态测试可以手工进行,也可以借助软件工具自动进行。,静态测试的特点,静态测试不必动态的执行程序,也就是不必进行测试用例设计和结果判读等工作;静态测试可以由人手工方式进行,充分发挥人的优势,行之有效。解铃还须系铃人,由于人的思维及交流障碍而造成的逻辑错误,有人通过
2、逻辑思维去解决,是一种非常有效的方法;特别是在充分利用人思维互补的情形,检验出错误的水平非常高。静态测试实施不需要特别条件,容易开展,静态测试的内容,主要由人工进行 代码审查(Code Inspection)代码走查(Walkthrough)桌面检查技术审查主要由软件工具自动进行的静态分析 广义的理解,还包括软件需求分析和设计阶段的技术评审,代码审查和代码走查,由若干程序员与测试员组成一个小组,集体阅读并讨论程序,或者用“脑”执行并检查程序的过程 分两步完成 预先作一定的准备工作 然后举行会议进行讨论 会议的主题是发现错误而不是纠正错误,桌面检查,程序员阅读自己所编的程序 缺点:第一,由于心理
3、上的原因,容易对自己的程序的偏爱,没有发现错误的欲望(这和已经知道了程序错了读程序找错误所在极为不同)第二,由于人的思维定势,有些习惯性的错误自己不易发现 第三,如果根本对功能理解错了,自己不易纠正 所以这种方法效率不高,可作为个人自我检查程序中明显的疏漏或笔误,代码审查与代码走查的优点,不仅比桌面检查优越得多,而且与动态测试的方法相比也有很多优点 第一,使用这种方法测试,一旦发现错误,就知道错误的性质和位置,因而调试所花费的代价低 第二,使用这种方法一次能揭示一批错误,而不是一次只揭示一个错误又,如果使用动态测试,通常仅揭示错误的征兆。程序不终止运行,而对错误的性质和位置还得逐个查找。,代码
4、审查与代码走查的效果,经验表明,使用这种方法能够优先的发现3070的逻辑设计和编码错误IBM使用代码审查方法表明,错误的检测效率高达全部查出错误的80Myers的研究发现代码审查和代码走查平均查出全部错误的70%,代码审查、代码走查与动态测试相互补充,研究表明使用代码审查和代码走查发现某类错误比用动态测试更有效,而对另一类错误情况正好相反由此可见代码审查和代码走查方法与动态测试结合,测试效果更佳。,代码审查的测试内容,检查代码和设计的一致性检查代码对标准的遵循、可读性检查代码的逻辑表达的正确性检查代码结构的合理性,代码审查的组成和方式,代码审查由一组程序和错误检查技术组成以代码审查组方式组织,
5、代码审查组,通常由四人组成,其中一人为组长 组长是关键,最好是一个称职的程序员,但不是被测试程序的编写者,也不需要对所检查的程序很熟悉,但需要较强的组织协调和语言能力 组长的职责包括分配资料、安排计划、主持开会、记录并保存被发现的错误 其余成员包括资深程序员、程序编写者与专职测试人员 根据测试的组织方式(如内部测试和独立测试)不同,代码审查小组组成可以调节,但组长角色不能变动,代码审查的步骤,准备程序阅读审查会议跟踪及报告,准备,组长提前把程序目录表和设计说明书等材料分配给小组成员小组成员熟悉这些材料由被测程序的设计和编码人员向审查组详细说明所准备的材料,特别是代码的主要功能与功能间的关系,程
6、序阅读,审查组人员仔细阅读代码和相关材料对照代码审查单标出明显缺陷及错误,审查会议,审查会由组长主持首先由程序员逐句阐明程序的逻辑,在此过程中可由程序员或其他小组成员提出问题,追踪错误是否存在经验证明在上述阐述过程中,有很多错误由讲述程序者而不是其他小组成员发现大声地朗读程序给听众,这样简单的工作是有效的错误检测技术然后利用代码审查单来分析讨论组长负责讨论沿着建设性的方向前进,而其他人则集中注意力发现错误,但不去纠正错误,跟踪和报告,会后把发现的错误登记造表并交给程序开发人员如果发现错误较多或发现重大错误,那么在改正之后,组长要再次组织审查会议为了改进以后的审查工作,对错误登记表也要分析,归类
7、和精炼,以第三方测试的方式进行代码审查,应就发现的缺陷及错误与软件开发人员讨论避免由于理解不一致产生问题,形成共同认可的审查结果,审查会议的时间,大约以1.52小时为宜审查会需要高度集中注意力,时间太长反而容易使效率降低每次会议可能处理一个或几个模块,代码审查单,代码审查单是代码审查过程所用的主要技术通常是把程序设计及编码中可能发生的各种错误进行分类,对每一类列举出尽可能多的典型错误,然后制成表格其它测试中发现的错误也要及时归入代码审查单,形成某一类型软件针对性的代码审查单,以供审查时使用,的代码审查单(部分),数据引用错误是否引用了未赋值或者未初始化的变量?所有的数组引用,其下标值是否都在各
8、自的相应维数定义界内?所有的数组引用,每一个下表是否是整数值?所有引用的指针或变量当前是否已经分配储存了?(即是否存在“悬挂引用”的问题)在检索操作或下标引用数组时,是否存在“差1”的错误?,To be continue,的代码审查单(部分),数据说明错误所有变量是否都显示地说明了?是否每个变量都赋予正常的长度、类型和存储分类?变量的初始化和它的存储类型是否有矛盾?,To be continue,的代码审查单(部分),计算错误 是否使用过非一致的数据类型的变量进行运算?是否存在混合运算?赋值语句的目标变量是否比其右边的表达式小,代码审查单的其他内容,还可以包括编程风格、标准、规范的符合性方面的
9、内容 在代码审查单的错误登记表中,应写明所查出的错误的类型、错误类别、错误的严重程度、错误的位置、错误的原因等信息。,阅读的方法,要仔细阅读需求设计等文档,特别是了解软件的整体物理意义、应用背景以及在大系统中的地位对大型软件而言,这些信息会在阅读程序时有效地帮助读者从一定的高度审视,而不是停留在逐行扫描代码有些错误要有整体观才能发现,阅读结构化代码的两种方法,追踪通过每个子程序的主要逻辑行,主要逻辑行全部跟踪完,然后开始跟踪第二条路径相当于深度优先遍历。按排列顺序追踪代码,从主要行开始,然后检查较低层的程序段相当于广度优先遍历,两种阅读方法的综合使用,这两种方式的差别在于何时进入下层模块,选择
10、那种方式要视具体程序特点而定广度优先遍历有助于很快地了解程序的全貌深度优先适于详细查阅功能处理步骤应综合使用上述两种方法,在头一两遍阅读时,采用广度优先,然后用深度优先,程序阅读的次数,Beizer提出至少要读程序4次,分别针对印刷错误、数据结构、控制流和处理4次阅读要比读一次能更快、更容易、更可靠的完成任务,代码审查的辅助工具,汇编或编译器生成的交叉引用表(变量、标号、子程序)逆向工程工具(例如从源代码生成流程图)带有快速查找的编辑器,代码走查,代码走查与代码审查相似,它也是由一组程序和错误检查技术组成,只是程序和错误检查技术不完全相同。,代码走查组,代码走查以小组方式进行 代码走查组包括
11、组长,类似代码审查组长 秘书,负责记录发现的错误,要有一定水平 测试人员,应是具有经验的程序设计人员,或精通程序设计语言的人员,或从未介入被测试程序的设计工作的技术人员(这样的人没有被已有的设计框住),没有约束,比较容易发现问题。,代码走查的过程,与代码审查过程相似先把材料交给每个小组人员,让他们认真研究程序,然后再召开代码走查会议。,代码走查会议的内容,与代码审查不同,不是读程序和使用代码审查单,而是由被指定的作为测试员的小组成员提供若干测试用例(程序的输入数据和期望的输出结果),让参加会的成员当计算机,在会议上对每个测试用例用头脑来执行程序,也就是用测试用例沿程序逻辑走一遍,并由测试人员讲
12、述程序执行过程,在纸上或黑板上监视程序状态(变量的值)每次开会时间以12小时为宜,但不允许中断如果发现问题由秘书记下来,中间不讨论任何纠错问题,主要是发现错误,测试用例在代码走查中的作用,代码走查中,测试用例并不是关键,也并不是仅想验证这几个测试用例运行是否正确,人脑毕竟比计算机慢太多这里测试用例是作为怀疑程序逻辑与计算错误的启发点,在随测试实例游历程序逻辑时,在怀疑程序的过程中发现错误这样,比几个测试用例本身直接发现的错误要多得多,代码走查中的缺点,代码走查使用测试用例启发检测错误,人们注意力会相对集中在随测试用例游历的程序逻辑路径上,不如代码审查检查的范围广,错误覆盖面全。,技术评审,综合
13、运用走查和审查技术,逐页、逐节地检查软件开发前期需求分析和设计的文档,对软件的需求,设计结构等方面提出问题评审也被当作一种管理工具,经过评审不仅可以提高各阶段软件产品的质量,还可以收集到一些有关该软件产品质量的数据技术评审属于广义的测试范畴,也是一种质量保证手段软件开发过程中每个阶段的评审都必须十分正规的,严格的加以定义,并根据规程实施。,静态测试的内容,针对不同的软件中间产品,静态测试的内容也不尽相同;对不同的文档进行静态测试的内容可以体现在对特定文档的测试对照条例中。下面以软件开发过程中的几个有代表性的主要文档和代码,列举静态测试的对照条例,以说明静态测试的内容:,需求定义的静态测试对照条
14、例,对需求定义的测试着重于测试对用户需求的描述和解释是否完整、准确;下面是根据有关标准整理而成的对需求定义进行静态测试的对照条例。我们把这些条例按照所测试的软件质量因素分成10组:,To be continue,需求定义的静态测试对照条例,兼容性界面需求是否使软硬件系统具有兼容性?,需求定义的静态测试对照条例,完备性需求定义是否包含了有关文件(指质量手册、质量计划以及其它有关文件)中所规定的需求定义所应该包含的所有内容?需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求?功能性需求是否覆盖了所有非正常情况的处理?是否对各种操作模式(如正常、非正常、有干扰等等)下的环境条件都作了
15、规定?是否对所有功能与时间有关的方面都作了考虑?是否识别出了所有与时间因素有关的功能?它们的时间准则是否都说明了?时间准则的最大、最小执行时间是否都定义了?是否识别并定义了在将来可能会变化的需求?,需求定义的静态测试对照条例,完备性(续)是否定义了系统所有的输入?是否标识清楚了系统输入的来源?是否识别出了系统的输出?是否说明了系统输入、输出的类型?是否说明了系统输入、输出的值域、单位、格式等等?是否说明了如何进行系统输入的合法性检查?是否定义了系统输入、输出的精度?是否定义了系统性能的各个方面?在不同负载情况下,系统的生产率如何?在不同的情况下,系统的响应时间如何?系统对软件、硬件或电源故障必
16、须作什么样的反应?是否充分地定义了关于人机界面的需求?,需求定义的静态测试对照条例,一致性各个需求之间是否一致?是否有冲突和矛盾?所规定的模型、算法和数值方法是否相容?是否使用了标准的术语和定义形式?需求是否与其软硬件操作环境相容?是否说明了软件对其系统和环境的影响?是否说明了环境对软件的影响?,需求定义的静态测试对照条例,正确性需求定义是否满足标准的要求?算法和规则是否有科技文献或其它文献作为基础?有哪些证据说明用户提供的规则或规定是正确的?是否定义了对在错误、危险分析中所识别出的各种故障模式和错误类型所需的反应?是否参照了有关的标准?是否对每一个需求都给出了理由?理由是否充分?对设计和实现



- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ch9 静态 测试 技术

链接地址:https://www.31ppt.com/p-5421554.html