5-单元测试省公开课一等奖全国示范课微课金奖PPT课件.pptx

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2021/10/3,#,软件测试方法和技术,-Ch.5,单元测试,Zhu.Kerry,Kerry Zhu,Zhu.Kerry,第1页,第四章回顾,Zhu.Kerry,软件质量标准,软件测试规范,CMM,思想和结构体系,建立软件测试管理和评判体系,第2页,第五章 单元测试,Zhu.Kerry,5.1,什么是单元测试,5.2,单元测试目标和任务,5.3,静态测试技术利用,5.4,动态测试技术利用,5.5,调试与评定,5.6,单元测试过程与文档管理,5.7,单元测试惯用工具介绍,第3页,5.1,什么是单元测试,测试,4,个阶段：,单元测试,集成测试,系统测试,验收测试,按阶段进行测试是一个基本测试策略,Zhu.Kerry,第4页,单元测试定义,定义,:,单元测试是对软件基本组成单元进行测试。,时机,:,普通在代码完成后由开发人员完成,QA,人员辅助,.,概念,:,模块,组件,单元,Zhu.Kerry,第5页,为何要进行单元测试,?,尽早发觉错误,错误发觉越早,成本越低,.,开发人员过于自信,后期复杂,度高,发觉处理,BUG,困难,.,检验代码是否符合设计和规范,Zhu.Kerry,12,小时,6,小时,3,小时,单元测试,集成测试,系统测试,第6页,单元测试背景,开发流程时间表与修改,Bug,代价关系图,开发结束,开发早期,修改代价,Zhu.Kerry,第7页,单元测试背景,（续）,编程过程中，每写,100,行代码会犯,150,个错误,编程与编译运行结束后，每,100,行代码中大约残留有,1-3,个,Bug,寻找与修改程序错误代价占总体开发投资,40%-80%,Bug,在整个研发流程中被发觉越早，修改代价就越低,Zhu.Kerry,第8页,5.2,单元测试目标和任务,目标,:,单元模块被正确编码,信息能否正确地流入和流出单元；,在单元工作过程中，其内部数据能否保持其完整性，包含内部数据形式、内容及相互关系不发生错误，也包含全局变量在单元中处理和影响。,在为限制数据加工而设置边界处，能否正确工作。,单元运行能否做到满足特定逻辑覆盖。,单元中发生了错误，其中犯错处理办法是否有效。,Zhu.Kerry,第9页,任务,1,：模块接口测试,检验模块接口是否正确，,c,hecklist:,输入实际参数与形式参数是否一致。,个数、属性、量纲,调用其它模块实际参数与被调模块形参是否一致。,个数、属性、量纲,全程变量定义在各模块是否一致。,外部输入、输出,文件、缓冲区、错误处理,其它,Zhu.Kerry,第10页,任务,2,：模块局部数据结构测试,检验局部数据结构完整性,Checklist:,不适合或不相容类型说明。,变量无初值。,变量初始化或默认值有错。,不正确变量名或从来未被使用过。,出现上溢或下溢和地址异常。,其它,Zhu.Kerry,第11页,任务,3,：模块边界条件测试,检验临界数据处理正确性,Checklist:,普通正当数据处理。,普通非法数据处理。,边界值内正当边界数据处理。,边界值外非法边界数据处理。,其它,Zhu.Kerry,第12页,任务,4,：模块独立执行通路测试,检验每一条独立执行路径测试。确保每条语句被最少执行一次。,Checklist:,算符优先级。,混合类型运算。,精度不够。,表示式符号。,循环条件，死循环。,其它,Zhu.Kerry,第13页,任务,5,：模块各条错误处理通路测试,预见、预设各种犯错处理是否正确有效。,Checklist:,输出犯错信息难以了解。,统计错误与实际不相符。,程序定义犯错处理前系统已介入。,异常处理不妥。,未提供足够定位犯错信息。,其它,Zhu.Kerry,第14页,Microsoft,对单元测试了解,Zhu.Kerry,第15页,单元测试详细分类,验证产品实现符合功效规格书,验证产品代码运行正确性,边缘条件测试,产品安全性测试,从已经有,Bug,增加回归测试,产品代码覆盖度测试,(Code Coverage),产品代码注射测试,(Code Injection),异常测试,Zhu.Kerry,第16页,单元测试详细分类,产品速度性能比较测试,产品极限情况测试,产品与国际标准兼容性测试,产品与以前版本操作系统，文件格式兼容测试,同一产品不一样版本共同运行兼容性测试,产品在不一样语言操作系统下运行测试,Zhu.Kerry,第17页,单元测试详细流程,测试过程从产品设计开始,Spec Review,非常主要,微软产品,Spec Review,演示,Sharepoint Server,应用,测试代码编写由软件开发设计者,(SDE),自己开始,DRT(Developer Regression Test),主要性,没有相随,DRT,，,Feature Area,不算开发完,DRT,不全部编译并,100%,经过，不允许,Check-in,测试组测试不,100%,编译并,100%,经过,0,级测试,(BVT),70%,经过,1,级测试，不允许,Check-in,Zhu.Kerry,第18页,单元测试详细流程,(,续,),测试代码主体由软件测试工程师,(SDET,STE),编写,测试从写软件测试规格书,(Test Spec),开始,Test Spec,必须经过,PM,，,Dev,与同组,Tester,共同开会研究经过,测试代码依据不一样测试情景分为,0-4,级优先级,0,级测试称为,BVT(Build Verification Test),在,Dev,主要功效实现,Check-in,前,0-1,级测试代码必须已由测试工程师完成,在,Dev,进行,Check-in,时，,0,级测试必须,100%,经过,Zhu.Kerry,第19页,单元测试详细流程,(,续,),在,Dev,进行,Check-in,时，,1,级测试必须最少有,70%,经过,Dev,进行产品代码,Check-in,Test,进行测试代码,Check-in,产品编译由,Build,团体每日进行,Test,编译由测试团体在产品编译完成后进行,测试编译完成后，由测试自动化系统进行测试,在随即代码优化与稳定时内，测试工程师编写,2-4,级测试代码，并汇报产品,Bug,，,Dev,负责修改,Bug,，稳定并优化产品,Zhu.Kerry,第20页,5.3,静态测试技术利用,静态测试技术：不运行被测试程序，对代码经过检验、阅读进行分析。,三步曲：,走查（,Walk Through,）。,审查（,Inspection,）。,评审（,Review,）,Zhu.Kerry,第21页,编码标准和规范,标准：建立起来必须恪守规则。,规范：提议最正确做法，推荐更加好方式。,实施标准和规范原因：,可靠性。,可读性和可维护性。,可移植性。,Zhu.Kerry,第22页,走查（,Walk Through,）,定义：采取讲解、讨论和模拟运行方式进行查找错误活动。,注意：,引导小组组员在走查前通读设计和编码。,限时，防止跑题。,发觉问题适当统计，防止现场修改。,检验关键点是代码是否符合标准和规范，是否有逻辑错误。,Zhu.Kerry,第23页,审查（,Inspection,）,定义：采取讲解、提问方式进行，普通有正式计划、流程和结果。主要方法采取缺点检验表。,注意：,以会议形式，制订会议目标、流程和规则，结束后要编写汇报。,按缺点检验表逐项检验。,发觉问题适当统计，防止现场修改。,发觉重大缺点，更正后会议需要重开。,检验关键点是缺点检验表，所以该表要依据项目不一样不停积累完善。,Zhu.Kerry,第24页,走查与审查比较,Zhu.Kerry,走 查,审 查,准备,通读设计和编码,应准备好需求描述文档、程序设计文档、程序源代码清单、代码编码标准和代码缺点检验表,形式,非正式会议,正式会议,参加人员,开发人员为主,项目组组员包含测试人员,主要技术方法,无,缺点检验表,注意事项,限时、不要现场修改代码,限时、不要现场修改代码,生成文档,会议统计,静态分析错误汇报,目标,代码标准规范，无逻辑错误,代码标准规范，无逻辑错误,第25页,评审（,Review,）,定义：通常在审查会后进行，审查小组依据统计和汇报进行评定。,注意：,充分审查了所要求代码，而且全部编码准则被恪守。,审查中发觉错误已全部修改。,Zhu.Kerry,第26页,5.4,动态测试技术利用,动态测试需要真正将程序运行起来，需要设计系列测试用例确保测试完整性和有效性。,白盒测试,黑盒（灰盒）测试,Zhu.Kerry,第27页,白盒测试方法,主要要逻辑驱动法和基本路径法。,语句覆盖。,判定覆盖。,条件覆盖。,判定,/,条件覆盖。,条件组合覆盖。,路径覆盖。,循环覆盖。,Zhu.Kerry,详细内容 第,14,章 软件测试用例设计,第28页,黑盒测试方法,运行单元程序有时需要基于被测单元接口，开发对应驱动模块和桩模块。,驱动模块（,drive,）,:,对底层,或子层模块进行测试所编写,调用这些模块程序。,桩模块（,stub,）：对顶层或,上层模块进行测试时所编写,替换下层模块程序。,Zhu.Kerry,第29页,黑盒惯用方法,等价类划分法,边界值分析法 三种数据：,错误推测法,-,正常数据,因果图法,-,错误数据,功效图法,-,边缘数据,另外还得考虑接口测试、性能测试、内存测试,性能分析,内存分析,Zhu.Kerry,第30页,5.6,调试与评定,调试与测试对象及采取方法有很大程度上相同，调试还用到断点控制等排错方法，但其目标却完全不一样。测试是为了找出软件中存在缺点，而调试是为了处理存在缺点。,软件单元功效与设计需求一致。,软件单元接口与设计需求一致。,能够正确处理输入和运行中错误。,在单元测试中发觉错误已经得到修改而且经过了测试。,到达了相关覆盖率要求。,完成软件单元测试汇报,Zhu.Kerry,第31页,单元测试检验表,(1),借助单元测试检验表进行评定。,案例：,单元测试检验表,单元名称,_,系统,_,结构,_,任务编号,_,首次测试日期,_,关键测试项是否已纠正,有没有任何输入参数没有使用？有没有任何输出参数没有产生？,有没有任何数据类型不正确或不一致？,有没有任何算法与,PDL,或功效需求中描述不一致？,有没有任何局部变量使用前没有初始化？,有没有任何外部接口编码错误？即调用语句、文件存取、数据库错误。,有没有任何逻辑路径错误？,该单元是否有多个入口或多个正常出口？,Zhu.Kerry,第32页,单元测试检验表,(2),额外测试项,8.,该单元中有任何地方与,PDL,与,PROLOG,中描述不一致？,9.,代码中有没有任何偏离本项目标准地方？,10.,代码中有没有任何对于用户来说不清楚错误提醒信息？,11.,假如该单元是设计为可重用，代码中是有可能妨碍重用地方？,采取动作和说明,（请用单独一页或多页。每一项动作必须指出所引用问题。）,审查结果,1.,假如上述,11,个问题答案均为,否,，那么测试经过，请在此标识而且在最终署名。,2.,假如代码存在严重问题，比如多个关键问题答案为,是,，那么程序编制者纠正这些错误，而且必须重新安排一次单元测试。,下一次单元测试日期：,_,3.,假如代码存在小缺点，那么程序编制者纠正这些错误，而且仲裁者必须安排一次跟踪会议。,跟踪会议日期：,_,测试人署名：,_,日期：,_,Zhu.Kerry,第33页,5.6,单元测试过程和文档管理,过程,:,在详细设计阶段完成单元测试计划。,建立单元测试环境，完成测试设计和开发。,执行单元测试用例，而且详细统计测试结果。,判定测试用例是否经过。,提交,单元测试汇报,。,Zhu.Kerry,第34页,单元测试文档,软件需求规格说明书,、,软件详细设计说明书,单元测试计划,单元测试计划,、,软件详细设计说明书,单元测试用例,单元测试用例,文档及,软件需求规格说明书,、,软件详细设计说明书,缺点跟踪汇报,/,缺点检验表,单元测试用例,、,缺点跟踪汇报,、,缺点检验表,单元测试检验表,评定,单元测试汇报,Zhu.Kerry,第35页,5.7,单元测试惯用工具介绍,工具分类,:,静态分析工具,代码规范审核工具,内存和资源检验工具,测试数据生成工具,测试框架工具,测试结果比较工具,测试度量工具,测试文档生成和管理工具,Zhu.Kerry,第36页,Q&A,Zhu.Kerry,第37页,