静态测试汇编课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,静态测试,静态测试,静态测试：通过检查和评审软件而不是运行软件对软件进行测试的方法。静态测试可以手工进行，也可以借助软件工具自动进行,测试对象：与软件相关的需要测试的产物，如各类文档、源代码等,邓痞枉何盖账放挪迷勾谷屎谜略彩硅蛔爷彻键驴尧慑扼醒塌乏卞霞票洛陵静态测试静态测试,3,为什么需要静态测试,识别缺陷的成效,静态测试的成效：最多识别软件所有缺陷中70-75%的缺陷,动态测试的成效：最多识别软件所有缺陷中30-35%的缺陷,识别缺陷的成本,需求阶段识别一个重要缺陷平均花费2-3小时；,设计阶段识别一个重要缺陷平均花费3-4小时；,代码评审阶段识别一个重要缺陷3-5小时；,动态测试识别一个重要缺陷平均花费15-25小时,栋蒂排捶购王跑社控驮渭欠怒娟爽逆营姨侵饺朗条籍矾暑畜罪绑泅睬袄片静态测试静态测试,4,为什么需要静态测试（续）,解决缺陷的成本,需求及设计阶段消除一个重要缺陷花费5-10小时,代码评审阶段消除一个重要缺陷花费5-15小时,动态测试识别消除一个重要缺陷平均花费30-80小时,投入回报比较（实例）,航天飞机搭乘项目：在设计或代码评审时消除一个缺陷的成本为1美元，在系统测试时为13美元，交付使用后为92美元（Paulk etal,1995），1392:1,电信公司审查时发现和纠正一个缺陷的平均费用为200美元，客户验收测试发现的缺陷平均花费4200美元(Boehm and Basili 2001)，21:1,印度Infosys公司经验表明：在代码审查上多花费一天，这个产品就有期望在后期修改缺陷节省3-6天，36:1,巍八习鹅菇悼轻张沾瘩架廷滁余镍括迂稻靛鞠绳柔歪货纵马糕犀湖卷幌季静态测试静态测试,静态测试技术的特点,静态测试不必动态的运行程序，也就不必进行测试用例的设计和结果判读等工作,静态测试可以由人工进行，充分发挥人的逻辑思维优势，行之有效,“解铃还需系铃人”，由于人的思维局限及交流障碍而造成的逻辑错误，由人通过逻辑思维去解决，是一种非常有效的方法,特别是在充分利用人的思维又是互补的条件时，检测出错误的水平很高,静态测试实施不需要特别条件，容易开展,从前两条特性中推论而出,鸳窿袍沟掩咐唉号她填仑页稀伯菊腐私相航韭练仲锰创听导贤芽父酚篇一静态测试静态测试,静态测试包括的内容,主要由人工进行,代码审查(Code Inspection),代码走查(Walkthrough),桌面检查,主要由软件工具自动进行的,静态分析,广义的理解，还包括软件需求分析和设计阶段的技术,评审,喀摄贺的闪慷裙炭羽聊柳镜绿隆搭侠库溉亚宅宴仕弛铁膨射释烟巳鬼喘混静态测试静态测试,代码审查和代码走查,由若干程序员与测试员组成一个小组，集体阅读并讨论程序，或者用“脑”执行并检查程序的过程,分两步完成,预先作一定的准备工作,然后举行会议进行讨论,会议的主题是发现错误而不是纠正错误,匹吟布孟越裴忽叼我路法术焰糖冬般买裕坞臃井厦瞻鸽黄操胜韧窥簿譬诫静态测试静态测试,桌面检查,程序员阅读自己所编的程序,缺点：,第一，由于心理上的原因，容易对自己的程序的偏爱，没有发现错误的欲望（这和已经知道了程序错了读程序找错误所在极为不同）,第二，由于人的思维定势，有些习惯性的错误自己不易发现,第三，如果根本对功能理解错了，自己不易纠正,所以这种方法效率不高，可作为个人自我检查程序中明显的疏漏或笔误,活钙蔼雏啥窑唤轴砒佃财采谷身特嘶小搏侦媳缉秩蹲辅酌宪种王侮蹲禄工静态测试静态测试,代码审查和代码走查的优点,不仅比桌面检查优越得多，而且与动态测试的方法相比也有很多优点,第一，使用这种方法测试，一旦发现错误，就知道错误的性质和位置，因而调试所花费的代价低,第二，使用这种方法一次能揭示一批错误，而不是一次只揭示一个错误,如果使用动态测试，通常仅揭示错误的征兆,程序不终止运行，而对错误的性质和位置还得逐个查找,曝负柜湾碟曼淋亨钢芽啸几槐蒋蚀蹋养易绝熏圣谩寸庐奈爵瞒剐狐爪抛躇静态测试静态测试,代码审查和代码走查的效果,经验表明，使用这种方法能够优先的发现 3070的逻辑设计和编码错误,IBM使用,代码审查,方法表明，错误的检测效率高达全部查出错误的80,Myers的研究发现,代码审查和代码走查,平均查出全部错误的30,股迪吾技蹄疏凭狄滩杀杨器搪寄贞迁钟梧赛匡鼎剁禾怔淹纠睁辞业掀均均静态测试静态测试,技术评审,综合运用走查和审查技术，逐页、逐节地检查软件开发前期需求分析和设计的文档，对软件的需求，设计结构等方面提出问题,评审也被当作一种管理工具，经过评审不仅可以提高各阶段软件产品的质量，还可以收集到一些有关该软件产品质量的数据,技术评审属于广义的测试范畴，也是一种质量保证手段,软件开发过程中每个阶段的评审都必须十分正规的、严格的加以定义，并根据规程实施,簇希盘藻徐瓣薯史缆磐拦郸谅星俘露潭蛇述烂栖女泳桅普注眶硼洛浅氏祈静态测试静态测试,内容,静态测试技术,代码审查,代码走查,静态测试的内容,需求定义的静态测试,设计文档的静态测试,源代码的静态测试,疥橙二菩植噪烃东晴役八杨屉根嫉抬蹭蝎估诱姿泊租堤仆泅渗恤指棠羡锋静态测试静态测试,代码审查的测试内容,检查代码和设计的一致性,检查代码对标准的遵循、可读性,检查代码的逻辑表达的正确性,检查代码结构的合理性,蔑烃伐庸医梢扣邀舒撅入喇增洱妊蚊豢彤杯貉攘擦换目黎胎毫瘁乐郴郁闪静态测试静态测试,代码审查的组成和方式,由一组程序和错误检查技术组成,以代码审查组方式进行,藕功逾沼埋购通衍里起袖代袱退炳射算校笔龄驯破答绽淌谣茧澎都荫治梦静态测试静态测试,代码审查组,通常由四人组成，其中一人为组长,组长,是关键，最好是一个称职的程序员，但不是被测试程序的编写者，也不需要对所检查的程序很熟悉，但需要较强的组织协调和语言能力,组长的职责包括分配资料、安排计划、主持开会、记录并保存被发现的错误,其余成员包括,资深程序员,、,程序编写者,与,专职测试人员,根据测试的组织方式（如内部测试和独立测试）不同，代码审查小组组成可以调节，但组长角色不能变动,敢疲侯躯鲤败点崖称唾簇况贰溢侵瘟拴坟击蝉仰赏熙仕列握误拒颠夜逐撅静态测试静态测试,代码审查的步骤,四个步骤,准备,程序阅读,审查会,跟踪及报告,赤咋鸥脖筋未征祷角绩谐琼驮纶察铡澎开仲粘霖给疮顺抛栽偶濒抄键咸从静态测试静态测试,1.准备,组长提前把程序目录表和设计说明书等材料分配给小组成员,小组成员熟悉这些材料,由被测程序的设计和编码人员向审查组详细说明所准备的材料，特别是代码的主要功能与功能间的关系,隅石扭芥毛傻总俗夜参悠赂涡绊机傈冕泵靡市罕采身郧伶从扣晌蝗郡靶乱静态测试静态测试,2.程序阅读,审查组人员仔细阅读代码和相关材料,对照,代码审查单,标出明显缺陷及错误,锑突瓤忱侵广激曲琴居羊邱闭厂弟面淘厅槽犀书疹岿陡腥燎钓损臭功耿符静态测试静态测试,3.审查会,审查会由组长主持,首先由程序员逐句阐明程序的逻辑，在此过程中可由程序员或其他小组成员提出问题，追踪错误是否存在,经验证明在上述阐述过程中，有很多错误由讲述程序者而不是其他小组成员发现,大声地朗读程序给听众，这样简单的工作是有效的错误检测技术,然后利用代码审查单来分析讨论,组长负责讨论沿着建设性的方向前进，而其他人则集中注意力发现错误，但不去纠正错误,澄祖价狱蟹缨砧陋款哄阀褥殷硬垮虞屈亡峙粘盘酋壁岳廉嗜翁息硬运毋签静态测试静态测试,4.跟踪及报告,会后把发现的错误登记造表并交给程序开发人员,如果发现错误较多或发现重大错误，那么在改正之后，组长要再次组织审查会议,为了改进以后的审查工作，对错误登记表也要分析，归类和精炼,痉铭闭盯应峰裸瞎钟畏蔡蝇枫伴梦溜已烹贷俭综拟害撇擂么置濒久尉排徘静态测试静态测试,Myers将错误分成8类,数据引用错误,数据声明错误,计算错误,比较错误,控制流程错误,子程序参数错误,输入输出错误,其它错误,渤涎忽刨皋苑拖伴齐有素滋架浪周醋底俺第骏炒参急墩夷亦给韧附份猫勺静态测试静态测试,G.J.Myers的代码审查单（部分）,数据引用错误,是否引用了未赋值或者未初始化的变量？,所有的数组引用，其下标值是否都在各自的相应维数定义界内？,所有的数组引用，每一个下标是否是整数值？,所有引用的指针或变量当前是否已经分配储存了？（即是否存在“悬挂引用”的问题）,在检索操作或用下标引用数组时，是否存在“差1”的错误？,嚷饮洱叠贵骨詹耶讹绢椎有幂羚庚劫传橱坟叭南拽篡瞻嫩躲般琅侣卵婆戏静态测试静态测试,数据声明错误,所有变量是否都显式地声明了？,是否每个变量都赋予正常的长度、类型和存储分类？,变量的初始化和它的存储类型是否有矛盾？,计算错误,是否使用了不同数据类型的变量进行运算？,对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？,赋值语句的目标变量是否比其右边的表达式小,int与long,泡伙带罩轩枷喉框毯棺衍乔蒜吗葱椰替磐姜沧素莹亏缔众谢荡栗搀等锚两静态测试静态测试,阅读程序的次数,Beizer提出至少要读程序4次，分别针对印 刷错误、数据结构、控制流和处理,4次阅读要比读一次能更快、更容易、更可靠的完成任务,多遍阅读程序、分步检查问题是代码审查的工作原则,评朝蔑声里廖畔樊埋茸仙敬钟钻梨毗仆拯场尝亡耗沫斟处遁搂鞋煮幅翼胚静态测试静态测试,代码审查的辅助工具,汇编或编译器生成的交叉引用表（变量、标号、子程序）,逆向工程工具（例如从源代码生成流程图）,带有快速查找的编辑器,簧豫频蓖呜羊洱田歉搪砌判薯暗挟饿抠厂铬遏扳音根铸堵劫嘲衬郧挎割受静态测试静态测试,内容,静态测试技术,代码审查,代码走查,静态测试的内容,需求定义的静态测试,设计文档的静态测试,源代码的静态测试,励谜虞肉筹襟陛诲遥蔡险械你鹅纳瞬备禄缕骋娃藕械焦缔硬铣疡垂膊庙份静态测试静态测试,代码走查,代码走查与代码审查相似，它也是由一组程序和错误检查技术组成，只是程序和错误检查技术不完全相同,栋央贰核找彤痹考决蓑盼里蕾冻锦宾麦崔菊超渴垢箩阎议兄悼催巍孔学搐静态测试静态测试,代码走查组,代码走查以小组方式进行,代码走查组包括,组长，类似代码审查组长,秘书，负责记录发现的错误，要有一定水平,测试人员，应是具有经验的程序设计人员，或精通程序设计语言的人员，或从未介入被测试程序的设计工作的技术人员（这样的人没有被已有的设计框住），没有约束，比较容易发现问题,庙睡铃造颜锚汞惧县贾澄萎纤悦废唤酱无班诞遥拓瑶蕾赊细斡筑庇君颜壤静态测试静态测试,代码走查的过程,与代码审查过程相似,先把材料交给每个小组人员，让他们认真研究程序，然后再开会,槐希裤酞敛苔筒缄苯逃耍齐洪韧及冀狼嫁概根这兄絮候关忠穴晒三羡锤霞静态测试静态测试,代码走查会的内容,与代码审查不同，不是读程序和使用代码审查单,而是由被指定的作为测试员的小组成员提供若干测试用例（程序的输入数据和期望的输出结果），让参加会的成员当计算机，在会议上对每个测试用例用头脑来执行程序，也就是用测试用例沿程序逻辑走一遍，并由测试人员讲述程序执行过程，在纸上或黑板上监视程序状态（变量的值）,每次开会时间以12小时为宜，但不允许中断,如果发现问题由秘书记下来，中间不讨论任何纠错问题，主要是发现错误,胰士愚栖抽取庚至逆逛戈驴膝狈蓉厌友似壶自本璃密陛吧疵皑唱挚祁瓤靶静态测试静态测试,代码走查的缺点,代码走查使用测试用例启发检测错误，人们注意力会相对集中在随测试用例游历的程序逻辑路径上，不如代码审查检查的范围广，错误覆盖面全,征粹恢匙瓦唆狡询捌副猛隧临柳堪帚圾嫡帕臼揭壤莱握闷械仇碧辜横窗缸静态测试静态测试,内容,静态测试技术,代码审查,代码走查,静态测试的内容,需求定义的静态测试,设计文档的静态测试,源代码的静态测试,厅乔杭蛇标漾伊婪阳慢芥人舆挤尺奖饯壬攘徊委房皑弱樱讯痰裹经内酌桥静态测试静态测试,静态测试的内容,针对不同的软件中间产品，静态测试的内容也不尽相同,对不同的文档进行静态测试的内容可以体现在对特定文档的,测试对照条例,中,下面以软件开发过程中的几个有代表性的主要文档和代码，列举静态测试的对照条例，以说明静态测试的内容,逻阮听尚群覆萍另踩睛歇芦陷蔡燕概请依码鄂苛仁哎括蒜普毖坡感报园索静态测试静态测试,需求定义的静态测试,对需求定义的测试着重于测试对用户需求的描述和解释是否完整、准确,高级审查：测试需求定义的第一步是站在一个高度上进行审查，找出根本性的问题、疏忽或遗漏之处,低层测试：高级审查之后可以很好地了解产品以及影响其设计的外部因素，然后就可以在更低的层次测试需求定义了。,差乳阔竟固释芒虫哈犀崔睛寡碟惟状殊坎赁手郊贾雪映阑痒吭星略碰啄寞静态测试静态测试,目标,发现特定的缺陷，比如大的原理性问题，功能遗漏或过度复杂的描述等,从用户的角度检查规格书，以用户的身份回答问题：,我需要什么样的功能？,我需要的所有功能是否都包含在规格书中了？,是否存在与现有系统冲突的功能？,功能是否易于使用？,性能如何？,功能的安全情况如何？,熟悉软件目标应用领域的人 对评审过程非常有帮助,需求定义的高级审查,盟嘘肾甲酱巷诫腑渗磐功熏狱挑寸曲席撑华葡坠遣吸侧角害绚陨舍舆非仑静态测试静态测试,研究现有标准和基线,当对规格书进行高级审查的时候，测试人员应该参考现有的标准和基线,组织标准、术语和惯例：软件应该使用最终用户的通用术语和惯例,工业标准：在某些工业领域，例如通讯、金融，有很多应用软件必须遵守的协议,政府标准,安全标准,测试人员应该把相关标准作为需求规格说明书评审的一部分,评审规格说明书的同时，测试人员应该验证系统参考了正确的标准并且没有遗漏。,需求定义的高级审查（续）,蕊辈填延茎命螺绝鹰柒靡寸恨钨铬甲稀气贼盅棋遂砒筑晋萎议穿图榨卜继静态测试静态测试,评审和测试类似软件,正在开发系统的早期版本,组织内的类似软件,竞争对手产品,注意：,特性是否有增删？,代码变更比例如何？,软件的复杂度是否有区别？,可测试性如何？,性能、安全性和其他一些非功能特性如何？,从公共出版物和网上找到有价值的信息,需求定义的高级审查（续）,亡诽踩啊长电呀妇髓汗当蹋油港嘱晾蓝曹蜗增砧差陕荷弛窘支街矾瀑概舶静态测试静态测试,评审需求规格说明书，下面的一些词汇以及这些词汇的上下文含义常常会带来缺陷：,总是、每个、所有、没有一个、从来不：这些词表示肯定和确定的含义，必须确认该用这些词语，或找出不该使用的理由,当然、所以、明显地、无疑、显然：这些词有劝说人接受的意思，不要中了圈套（规格书中尽量避免）,某些、有时、常常、通常、经常、大多、几乎；等等、诸如此类、以此类推；良好、迅速、便宜、高效、小、稳定：这些词是模糊无法量化的术语，可测试性差，必须进一步准确定义其含义,处理、进行、拒绝、跳过、排除：这些词可能会隐藏大量需要详细说明的功能性需求,如果那么（没有否则）：找出有“如果那么”而缺少配套的“否则”结构的陈述。想一想“如果”没有发生会怎样。,需求定义的低层测试,庆劫怪瞥崖寄歹坑搁爬飘纠酉临站苏条桂稗芬舶纶晰陆危渴忆人痢嚏贷阂静态测试静态测试,需求定义的低层测试（续）,下面是根据有关标准整理而成的对需求定义进行静态测试的对照条例,把这些条例按照所测试的软件质量因素分成10组,淑说视脑恰慌髓蛆碑氧展听婚愧帐扩憎闸欢煞娘疡恋梧篱听德绕贬挣葱券静态测试静态测试,1.完备性,需求定义是否包含了有关文件（指质量手册、质量计划以及其它有关文件）中所规定的需求定义所应该包含的所有内容？,需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？,功能性需求是否覆盖了所有非正常情况的处理？,是否对各种操作模式（如正常、非正常、有干扰等等）下的环境条件都作了规定？,是否对所有功能与时间有关的方面都作了考虑？,是否识别出了所有与时间因素有关的功能？它们的时间准则是否都说明了？,时间准则的最大、最小执行时间是否都定义了？,是否识别并定义了在将来可能会变化的需求？,浅描兄薯淖咯鲤僻版潜腿钟荚肿绘怠光憾獭茵歹抡盅妆凋幽陨辣胡凉权拈静态测试静态测试,是否定义了系统所有的输入？,是否标识清楚了系统输入的来源？,是否识别出了系统的输出？,是否说明了系统输入、输出的类型？,是否说明了系统输入、输出的值域、单位、格式等等？,是否说明了如何进行系统输入的合法性检查？,是否定义了系统输入、输出的精度？,是否定义了系统性能的各个方面？,在不同负载情况下，系统的生产率如何？,在不同的情况下，系统的响应时间如何？,系统对软件、硬件或电源故障必须作什么样的反应？,是否充分地定义了关于人机界面的需求？,屡忆抢浸溢筹掌庆脐律宴挫酣珠期耿库匙屎请孽寞矩柜据祟扫浙互裂局凉静态测试静态测试,2.一致性,各个需求之间是否一致？是否有冲突和矛盾？,所规定的模型、算法和数值方法是否相容？,是否使用了标准的术语和定义形式？,需求是否与其软硬件操作环境相容？,是否说明了软件对其系统和环境的影响？,是否说明了环境对软件的影响？,摩赂肌导愤赠国玲熏励匀拷闻悔穴龙路山谍泼钠甥俘吕辱矢断建十瞒萄陋静态测试静态测试,3.正确性,需求定义是否满足标准的要求？,算法和规则是否有科技文献或其它文献作为基础？,有哪些证据说明用户提供的规则或规定是正确的？,是否定义了对在错误、危险分析中所识别出的各种故障模式和错误类型所需的反应？,是否参照了有关的标准？,是否对每一个需求都给出了理由？理由是否充分？,对设计和实现的限制是否都有论证？,国漫集篷疲姥仙搓扎哀啦宵哉绳能数沼投耐彼疙谁诧环搬扮呐衰断虫脑进静态测试静态测试,4.可行性,需求定义是否使软件的设计、实现、操作和维护都可行？,所规定的模型、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？,是否能够达到关于质量的要求？,旧聘缩皇照屹霓鸳浩诸肾谜亦并考者络诬亥怒乐样浓判牵毛茄继闸竣压曹静态测试静态测试,5.易修改性,对需求定义的描述是否易于修改（例如，是否采用良好的结构和交叉引用表等等）？,是否有冗余的信息？是否一个需求被定义多次？,炔电雍械绎捆吃瓣嫡缆蓄雏两烁恃划牟剂针瓤腹虹撤科鬃雍雁鸯幢甲钦屏静态测试静态测试,6.健壮性,是否有容错的需求？,藕启灌牙摘嫡强掖占亥桑检狙归盲瓦琐割宋毒卧芥坪鸽吉始谎萄昼配璃氧静态测试静态测试,7.易追溯性,是否可从上一阶段的文档查找到需求定义中的相应内容？,需求定义是否明确的表明前阶段中提出的有关需求和设计限制都已经被覆盖了？,需求定义是否便于向后继续开发阶段查找信息？,咎疫搐氖代酣俗供皇缕渴静封淫炙意淌惊勒屎堑读管雅氖馈人镊赤氯蹲绵静态测试静态测试,8.易理解性,是否每一个需求都只有一种解释？,功能性需求是不是以模块方式描述的，是否明确的标识出了其功能？,是否有术语定义一览表？,是否使用了形式化或半形式化的语言？,语言是否有歧义性？,需求定义中是否只包含了必要的实现细节而不包含不必要的实现细节？是否过分细致了？,需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试数据的基础？,需求定义的描述是否将对程序的需求和所提供的其它信息分离开来了？,持靖脯随伪邪海罩椅姥膀彻帐版彻逮托哼鹤放吾故闪失王赔尔纱毛艰殆恃静态测试静态测试,9.易测试性和可验证性,需求是否可以验证？（即是否可以检验软件是否满足了需求？）,是否对每一个需求都指定了验证过程？,数学函数的定义是否使用了精确定义的语法和语义符号？,愁灵魏技激卫奢韶嚣安糖谚姚樊呵侯变卷贼继枪楷妇丘缅职仗朽总糟嘲棒静态测试静态测试,10.兼容性,接口需求是否使软硬件系统具有兼容性？,硒荐豁琐捎人颁朴美视联又葬讯仲救剐净斑七宝牌伊使茨歌梦赁辨渍咨栅静态测试静态测试,评审案例：保险金问题,评审下列功能说明,一个模拟的保险金计算程序，根据投保人和驾驶历史纪录两个因素计算半年的保险金，具体方法如下：,保险金=基本保险费率*年龄系数-安全驾驶折扣,当前的基本保险费率为500美元，,年龄系数是投保人年龄的函数.,如果投保人驾驶执照上的当前点数低于与年龄有关的门限，则给与安全驾驶折扣，如果投保人有12点，则驾驶人的执照就会被吊销，不再需要保险。,书面保险策略的驾驶人年龄范围为16-100，年龄、年龄系数、门限点数和安全驾驶折扣的关系如下所示：,恫感竞彭巍哪莆讨弊簇口早层构庶俗聪灌弹羽亚滋爪持比魄铰试和罗焙惦静态测试静态测试,几个问题,问题1、驾驶执照上的点数是否为整数？,问题2、如果投保人驾驶执照上的当前点数低于与年龄有关的门限，则给与安全驾驶折扣？低于是指小于？如果等于或者高于门限但是低于12点的如何处理，是仅不给与安全驾驶折扣，还是保险金就不给了,问题3、小于16岁和大于99岁系统如何处理？,问题4、驾驶执照被吊销本功能是否要处理？,槛酣工留撕忘壬晓冗垢篮硅砚擂朔兄捍顶小烬粥通柔震颂泵濒茎讼乖呻肥静态测试静态测试,评审案例：修改的功能说明,本功能根据投保人年龄和驾驶执照上当前的点数，按照下表中提供的规则计算投保人半年的保险金,。,输入：,投保人年龄:整数 16,100),驾驶执照上的当前点数：整数0，12,输出：半年保险金,卤倘轰汾礁荤虐蛋握址甘拍熏窘详静眉仁中屈喝标熔难晶熄轩梗衫黔倔颜静态测试静态测试,评审案例：修改的功能说明,处理：,计算年龄系数。根据输入的投保人年龄按照表1中提供的年龄与年龄系数对照关系获得相应的年龄系数，转2。如果输入的投保人年龄不满足区间要求，则系统在显示信息,“,Warning:Age should between 16 and 100.(including 16 but not 100),”,后，结束处理。,计算安全驾驶折扣。根据输入的驾驶执照上的当前点数按照表1中提供的年龄与门限点数对照关系获得相应的安全驾驶折扣。如果投保人驾驶执照上的当前点数低于与年龄有关的门限，则给与安全驾驶折扣，转3处理；如果等于或者高于门限但是低于12点，则安全驾驶折扣为0，转3处理；如果驾驶执照上的当前点数为12点，则系统在显示信息,“,Your total premium is$0,”,后结束处理。,按照规则“,保险金=基本保险费率*年龄系数-安全驾驶折扣,”计算保险金。其中基本保险费率为500,说明：吊销驾驶人执照本功能不做处理。,营焊赔饭筑蛛犁未瑞帚盎驹藏休运绕峭有竟洲友搭浊润颇判原欺弯氟釉揭静态测试静态测试,内容,静态测试技术,代码审查,代码走查,静态测试的内容,需求定义的静态测试,设计文档的静态测试,源代码的静态测试,恐给夜蚜咏盐芬栖佐吃斋盟院无尝卫纷虑灌凹疟邵姬链墩柞玛呛宠柏贸候静态测试静态测试,设计文档的静态测试,对设计文档的静态测试着重于分析设计是否与需求定义一致，所采用的数值方法和算法是否适用于待解问题，程序的设计中对程序的划分是否与待解问题相适应，需求是否都被满足了等,畔假朝拷躁扮民叼颜囊表移妆继嗜欣澡稠勿怠多贬勿戏缺硒绥彦甚弱养尚静态测试静态测试,1.完备性,软件设计规约是否包含了有关文件（指质量手册、质量计划及其它有关文件）中所规定的所有内容？,是否有充分的数据（如逻辑结构图、算法、存储分配图等）来保证设计的完整性？,算法、公式等是否充分、准确、完善？,是否在设计中明确地说明了产品的开发中所需要的软件、硬件和测试所需要的软硬件？,对于每一个程序界面，设计是否都实现了所要求的行为？,邹彦峡昌料韭媳森卡盐黍莎章夫付兜币抬爪录搓贸客账何溺嘲耀扁先荡蔚静态测试静态测试,是否标识出了程序的每一个输入、输出和数据库成分？其描述是否详细到了可以编码的程度了？,是否说明了程序的操作环境？,是否包含了所有的处理步骤？,是否给出了每一个决策点的所有出口转向？,设计是否考虑到了所有可能的情况和条件？,设计是否指明了在出现异常情况和不正当输入的情况下的行为？,设计是否参照了有关的设计标准？,疆几弥道日掘舅嗡梨孺倘刁素苯氦鄂被曳垛肘颈匆淆拓樟捌娶闽吧启棚藏静态测试静态测试,2.一致性,在设计文档中，是否始终使用标准的术语和定义？文档的风格和详细程度是否前后始终一致？,界面之间是否相容？,设计是否包含内在矛盾？,模型、算法和数值方法之间是否在数学上是相容的？,输入输出的格式是否一致？,类似的功能和相关的功能的设计是否一致？,计算中的输入、输出和数据库成分的计量单位和计算精度是否一致？逻辑表达式是否一致？,劳雪茄讳熙坑悔斥咽诀辫肌销瑰川堆从稻颠叭布赦甥绕襟博庐戚额卉徽肉静态测试静态测试,3.正确性,设计文档是否满足有关标准的要求？,设计是否只完成需求定义中要求的功能？若包含额外的功能，则这些功能的必要性是否经过论证？,测试文档是否准确？,设计逻辑是否正确？即，程序是否会完成所需的功能？,设计是否与所描述的操作环境相一致？,界面的设计是否与文档所描述的界面部分一致？,对于设计者不能选择的输入输出和数据库成分的数据格式、内容和数据率，设计是否正确地给予了安排？,万黎瞄疟六益蒂款金糠哀秉姿犊灸敌锁骤篷灾襟室豁闹峦簧堵蔬阉稀榷笑静态测试静态测试,4.可行性,所设计的模型、算法和数值方法对于应用领域来说是否可以接受？,设计能否在所规定的限制条件下和开发代价下实现？,在可用的资源条件下，所设计的功能能实现吗？,新渤哨晃枕援姥税重音斥娇杭诈出斋糙眺尉燥缝穆乱壕乌堡诀肢卞樟舜溃静态测试静态测试,5.易修改性,设计是否使用了信息隐藏技术？,模块的组织使对一条需求的改变只影响较少的模块,对于可能改变的数据与函数的结构的设计使它门的界面对于单个函数的改变不敏感,将数据结构的取接、数据库的取接和I/O的取接从应用程序中分离开来，并使用专门的程序来完成之，不使用全局可取接的数据,功能分解成一系列子程序，使每一个子程序都具有最大限度的内部紧密联系和最低限度的互相依赖,高内聚、低耦合,每一个子程序都只有一个功能吗？,译踌详擂剩碳俘义壁酵遇萎哨樱咀尔课棉撂狞放靠膏豫业姬御蝶冰恫优花静态测试静态测试,6.模块性,是否采用了模块化的机制？,设计是否使软件系统由一系列相对来说较小的、以层次结构相互联系的子程序组成？是否每一个子程序都只完成一个特定的功能？,设计是否使用了特殊的规则来限制子程序的大小？,溢愉么蛔陈合湃整孙懂花乘窖刃祭稠臣滤铣妻珍紫兽鳞俺氓府须适奎情昏静态测试静态测试,7.可预测性,设计是否包含了子程序来提供在已经标识出的出错情况下所需的反应？,所设计的计算机资源调度方式是否是确定的和可预测的，而不是动态的？,设计是否使用了尽量少的中断和事件驱动，对使用这样的功能是否进行了论证？,是否设计了在程序的运行过程中进行正确性检查来发现运行时刻的错误和违反运行许可的情况？,禾糠治沸谎氛粗厢楚莫绚躯眠狭凶脖恋捍翰室褒毋崭拴殊淤罕远疑徒孙算静态测试静态测试,8.健壮性,设计是否覆盖了需求定义中所要求的容错和故障弱化的需求？,垄呆甲丽近仇后胺奏双怂院唬筋亮巡沪瑚惦唯稽杭厂筑佬近蹲啊答羌官漫静态测试静态测试,9.结构化,设计是否使用了层次式的逻辑控制结构？,钓频泉幢遮唁粉返沉砾膀便备屑肺厌暮恫腻揪慨痹谓邢誓个芬趾茵访豁资静态测试静态测试,10.易追溯性,设计文档中是否包含设计与需求定义中的需求、设计限制等内容的对应关系？,设计是否标识出了设计中所包含的需求定义之外的功能？,是否对所有函数都进行了适当的标识使代码能够唯一地引用该标识？,设计规约是否包含修改历史记录，并使所有的对设计的修改和修改理由都记录在内并赋以编号了？,设计规约是否包含了设计备案文档并记录了与设计有关的决策？,袭各漫肆知膨盐宙辆阮瑚摸惑监啤白吨乌臭班蓑诈转僚邮渣钒否纱韶耍消静态测试静态测试,11.易理解性,设计是否避免了不必要的成分和表达形式？,设计文档是否不致造成歧义性解释？,阐毯塘烧机灯着安瞒溪偿俊决拄荷综颤阿蜡试新烁半曳甘甸贯英氢禹跨捡静态测试静态测试,12.可验证性/易测试性,设计中对每一个函数的描述是否都使用了良好的术语和符号？是否可以验证它与需求定义相一致？,是否定量地说明了使用条件、限制等内容？是否可以由此产生测试数据？,治舰傀辖悍诲经自卞隧嫉琅楚零厚鼎岔挥埋汛曙宁刊墒叹无蚕歧铲云屁逼静态测试静态测试,内容,静态测试技术,代码审查,代码走查,静态测试的内容,需求定义的静态测试,设计文档的静态测试,源代码的静态测试,撤收沂床油锻倘左浸佐逞滓河乱帐手犀援茅呛肛呜僵陛政仓唱颊宫季重核静态测试静态测试,源代码的静态测试,对源代码的静态测试着重于分析实现是否正确、完备,胸素鸟凉冷拖吻赴妙蛆咯冕忻用虾稼骄午浪旦烹赌绢叙迎挟熬插逮袭吱铆静态测试静态测试,1.完备性,代码是否完全、准确地实现了设计规约中所规定的内容？,代码是否满足设计要求？,代码是否创建了所需的数据库或其它初始化数据？,是否有未引用的或未定义的变量、常量或数据类型？,垃端赏韦讼抠诈箭匹螺怜龋工汕恕堤激址事干筷卵蕴孝穗泅蕊斯沫岗蚜踞静态测试静态测试,2.一致性,代码在逻辑上与设计规约一致吗？,是否自始至终使用了相同的格式、调用约定、结构等等？,绝霍掸即绚哼拴措观腆炼淹俱桃顿牵狸谍饿于旅仓脾粕鼻看晌寒愁湃诫哺静态测试静态测试,3.正确性,代码是否符合标准？,变量的定义和使用都正确吗？,注释是否正确？,子程序调用的参数个数正确吗？,练棍宅删瞳捆逗粤祷面概砾摹恿客亨检悼屋闽惜醚渤猪猿骇痪宝呀盔富展静态测试静态测试,4.易修改性,代码中对常数的使用是否都通过符号来进行，使其便于修改？,是否有交叉引用表或数据字典来表明程序对常量和变量的取接？,代码是否由单入口、单出口的子程序构成？（错误处理除外）,代码是否避免了直接使用地址，而采用标号和符号常量？,彦吐底菩县织贼铱暴敛复傀围猛拐诵档死纶世设汇倔耳璃迎宴曹剧迁畅憾静态测试静态测试,5.可预测性,是否避免了使用自我修改的代码？,是否避免了依赖于程序设计语言中的缺省值的代码？,代码是否包含无穷循环？,是否避免了递归？,铀扳敢胰联剖锗婶杂北手誓钉走弊褂氓絮宜王肝嚏岗锑粹墩博瓶休虐虐筐静态测试静态测试,6.健壮性,代码是否防止可以发现的运行时刻的错误？如下标变量越界，除数为零，变量值越界，栈溢出等等,尧阵益碧袭植姻队浇强泪们孟炒宰茎绸硬曙衙抒析茨迈摸逊僻帘庞柯身诺静态测试静态测试,7.结构化,程序的每一个功能是否都可以作为一块代码而识别出？,循环是否只有一个入口？,削场褒蚁枚殊兆猾背枉同芒楞森绿婉对闯凰游道卫梨蝴汉绞驰逻哩蔷藉雹静态测试静态测试,8.易追溯性,是否有一个交叉引用表，通过它可以便捷地从代码找到相应的设计？,是否有修改历史记录，它记录对代码的所有修改历史和修改原因？,渺拍漏炎几锨井揉箩硬导卧呈纬抑灯绘奄蛤冒羚搭靴冀瞒肄羊映秉饥杰惕静态测试静态测试,9.易理解性,注释是否使用简洁明了的语言对每一个子程序都作了充分的描述？,是否有不必要地复杂的代码？若有，是否使用了注释对其进行解释？,是否使用了一致的格式（如缩进和空格的使用）？,是否使用了便于记忆的命名约定？命名是否反映了变量的类型？,匈牙利命名法,变量的有效值域是否定义了？,代码中的公式是否使用了设计规约中相应数学模型的公式？,磁篡饥仑蜂闻幅蹋邓网涛粕逸品莆央甭趟锗兹潞卢聪暴夯殷与臂砚芜链般静态测试静态测试,10.可验证性,实现是否避免了使用测试难度大的技术和方法？,愈卷负程录率鄙济韧缀鳃臃吉榷岳追圭汞荡引非磊假桥科颤告带搏默沈片静态测试静态测试,对照条例的说明,对照条例并不是一成不变的,在静态测试的实践中，对照条例可根据实际情况进行适当的增减,特定的应用领域和特定的开发方法都会对静态测试提出一些特定的要求，这些要求可以正确地反映在静态测试的对照条例之中,淮负赴盖取闯偶凿亩倚唬毙杉常嚏骄壹极谰返份镜肾篱逢热哎押封肾渤笋静态测试静态测试,回顾,静态测试技术,代码审查,代码走查,静态测试的内容,需求定义的静态测试,设计文档的静态测试,源代码的静态测试,孰椒阻汲避杰薯益涌痒调混楼浙嘶谍中起瓢掀虑灸檀让絮扮鹃替糜哮亿蔫静态测试静态测试,此课件下载可自行编辑修改，仅供参考！感谢您的支持，我们努力做得更好！谢谢,