第三章-单元测试-STMT

软件测试基础教程第三章单元测试[e-mail]第二章回顾①测试心理学②测试的基本原理第三章单元测试3.1什么是单元测试3.2单元测试的目标和任务3.3静态测试技术的运用3.4动态测试技术的运用3.5调试与评估3.6单元测试的过程与文档管理3.7单元测试的常用工具简介3.1什么是单元测试测试的4个阶段：单元测试集成测试系统测试验收测试按阶段进行测试是一种基本的测试策略单元测试的定义定义:单元测试是对软件基本组成单元进行的测试。时机:一般在代码完成后由开发人员完成,QA人员辅助.概念:模块,组件,单元为何要进行单元测试?尽早发现错误错误发现越早,成本越低.开发人员过于自信,后期复杂度高,发现解决BUG困难.检查代码是否符合设计和规范12小时6小时3小时单元测试集成测试系统测试3.2单元测试的目标和任务目标:单元模块被正确编码信息能否正确地流入和流出单元；在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。在为限制数据加工而设置的边界处，能否正确工作。单元的运行能否做到满足特定的逻辑覆盖。单元中发生了错误，其中的出错处理措施是否有效。任务1：模块接口测试检查模块接口是否正确Checklist:输入的实际参数与形式参数是否一致。个数、属性、量纲调用其他模块的实际参数与被调模块的形参是否一致。个数、属性、量纲全程变量的定义在各模块是否一致。外部输入、输出文件、缓冲区、错误处理其它任务2：模块局部数据结构测试检查局部数据结构完整性Checklist:不适合或不相容的类型说明。变量无初值。变量初始化或默认值有错。不正确的变量名或从来未被使用过。出现上溢或下溢和地址异常。其它任务3：模块边界条件测试检查临界数据处理的正确性Checklist:普通合法数据的处理。普通非法数据的处理。边界值内合法边界数据的处理。边界值外非法边界数据的处理。其它任务4：模块独立执行通路测试检查每一条独立执行路径的测试。保证每条语句被至少执行一次。Checklist:算符优先级。混合类型运算。精度不够。表达式符号。循环条件，死循环。其它任务5：模块的各条错误处理通路测试预见、预设的各种出错处理是否正确有效。Checklist:输出的出错信息难以理解。记录的错误与实际不相符。程序定义的出错处理前系统已介入。异常处理不当。未提供足够的定位出错的信息。其它5.3静态测试技术的运用静态测试技术：不运行被测试程序，对代码通过检查、阅读进行分析。三步曲：走查（WalkThrough）。审查（Inspection）。评审（Review）编码的标准和规范标准：建立起来必须遵守的规则。规范：建议最佳做法，推荐更好方式。实施标准和规范的原因：可靠性。可读性和可维护性。可移植性。走查（WalkThrough）定义：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。注意：引导小组成员在走查前通读设计和编码。限时，避免跑题。发现问题适当记录，避免现场修改。检查要点是代码是否符合标准和规范，是否有逻辑错误。审查（Inspection）定义：采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。注意：以会议形式，制定会议目标、流程和规则，结束后要编写报告。按缺陷检查表逐项检查。发现问题适当记录，避免现场修改。发现重大缺陷，改正后会议需要重开。检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。走查与审查的比较走查审查准备通读设计和编码应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表形式非正式会议正式会议参加人员开发人员为主项目组成员包括测试人员主要技术方法无缺陷检查表注意事项限时、不要现场修改代码限时、不要现场修改代码生成文档会议记录静态分析错误报告目标代码标准规范，无逻辑错误代码标准规范，无逻辑错误评审（Review）定义：通常在审查会后进行，审查小组根据记录和报告进行评估。注意：充分审查了所规定的代码，并且全部编码准则被遵守。审查中发现的错误已全部修改。3.4动态测试技术的运用动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。白盒测试黑盒（灰盒）测试白盒测试方法主要有逻辑驱动法和基本路径法。语句覆盖。判定覆盖。条件覆盖。判定/条件覆盖。条件组合覆盖。路径覆盖。循环覆盖。黑盒测试方法运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。黑盒常用方法等价类划分法边界值分析法三种数据：错误推测法--正常数据因果图法--错误数据功能图法--边缘数据另外还得考虑接口测试、性能测试、内存测试性能分析内存分析3.6调试与评估调试与测试的对象及采用的方法有很大程度上的相似，调试还用到断点控制等排错方法，但其目的却完全不同。测试是为了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。软件单元功能与设计需求一致。软件单元接口与设计需求一致。能够正确处理输入和运行中的错误。在单元测试中发现的错误已经得到修改并且通过了测试。达到了相关的覆盖率的要求。完成软件单元测试报告单元测试检查表(1)借助单元测试检查表进行评估。案例：单元测试检查表单元名称___________系统_______________构造______________任务编号____________________初次测试日期_________________关键测试项是否已纠正1.有无任何输入参数没有使用？有无任何输出参数没有产生？2.有无任何数据类型不正确或不一致？3.有无任何算法与PDL或功能需求中的描述不一致？4.有无任何局部变量使用前没有初始化？5.有无任何外部接口编码错误？即调用语句、文件存取、数据库错误。6.有无任何逻辑路径错误？7.该单元是否有多个入口或多个正常的出口？单元测试检查表(2)额外测试项8.该单元中有任何地方与PDL与PROLOG中的描述不一致？9.代码中有无任何偏离本项目标准的地方？10.代码中有无任何对于用户来说不清楚的错误提示信息？11.如果该单元是设计为可重用的，代码中是有可能妨碍重用的地方？采取的动作和说明（请用单独的一页或多页。每一项动作必须指出所引用的问题。）审查结果1.如果上述11个问题的答案均为否，那么测试通过，请在此标记并且在最后签名。2.如果代码存在严重的问题，例如多个关键问题的答案为是，那么程序编制者纠正这些错误，并且必须重新安排一次单元测试。下一次单元测试的日期：_________________________3.如果代码存在小的缺陷，那么程序编制者纠正这些错误，并且仲裁者必须安排一次跟踪会议。跟踪会议的日期：_________________________测试人签名：__________________日期：_________________3.6单元测试的过程和文档管理过程:1.在详细设计阶段完成单元测试计划。2.建立单元测试环境，完成测试设计和开发。3.执行单元测试用例，并且详细记录测试结果。4.判定测试用例是否通过。5.提交《单元测试报告》。单元测试的文档1.《软件需求规格说明书》、《软件详细设计说明书》《单元测试计划》2.《单元测试计划》、《软件详细设计说明书》《单元测试用例》3.《单元测试用例》文档及《软件需求规格说明书》、《软件详细设计说明书》《缺陷跟踪报告》/《缺陷检查表》4.《单元测试用例》、《缺陷跟踪报告》、《缺陷检查表》《单元测试检查表》5.评估《单元测试报告》3.7单元测试常用工具简介工具分类:静态分析工具代码规范审核工具内存和资源检查工具测试数据生成工具测试框架工具测试结果比较工具测试度量工具测试文档生成和管理工具Q&A