单元测试分析与设计

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第四章 单元测试,4.1 什么是单元测试,规格定义,设计,编码,系统测试,集成测试,单元测试,用户需求,验收测试,回,归,测,试,配置管理,缺陷跟踪,4.1 什么是单元测试,单元测试（Unit Testing）,是对软件基本组成单元进行的测试，单元的基本属性：,明确的功能；,规格定义；,与其他部分明确的接口定义；,例：C+中的public的成员函数，单独的函数或类；,4.1 什么是单元测试,单元测试的目的：,验证代码是否与设计相符；,跟踪需求和设计的实现；,发现设计和需求中存在的错误；,发现编码过程中引入的错误；,4.1 什么是单元测试,为什么进行单元测试？,单元测试浪费了太多时间；,单元测试仅仅是证明这些代码做了些什么；,我是个很棒的程序元，我可以不进行单元测试；,不管怎样，集成测试将会抓住所有的bug；,它的成本效率不高；,4.2 单元测试策略,桩模块（Stub）,：用以模拟被测模块工作过程中所调用的模块，他们一般只进行很少的数据处理，例如打印入口和返回；,驱动模块（Driver）,：用以模拟被测模块的上级模块，它接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印相应的结果；,4.2 单元测试策略,由顶向下的单元测试策略；,-先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块，其次对第二层进行测试，使用上面已测试的单元做驱动模块，以此类推；,由底向上的单元测试策略；,-先对模块调用层次图上最底层的模块进行单元测试，为该模块建立驱动模块，其次对上一层做单元测试，下面测试过的模块做桩模块，以此类推；,孤立测试,-不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块；,4.3 单元测试分析,单元测试所考虑的方面：,模块,模块接口,局部数据结构,出错处理,独立路径,边界条件,4.3 单元测试分析,模块接口：,调用所测模块时的输入参数与模块的形参在个数、属性、顺序上是否匹配；,参数与变量的属性、单位是否一致；,全局变量的定义在每个模块中是否一致；,-是否修改只是作为输入值的变量；,有没有把常数当变量来传送；,调用内部函数时，变量的个数、属性和次序是否正确；,4.3 单元测试分析,局部数据结构：,检查不正确或不一致的数据类型说明；,使用尚未赋值或尚未初始化的变量；,错误的初始值或错误的默认值；,变量名拼写错误或书写错误；,不一致的数据类型；,上溢、下溢或地址错误；,4.3 单元测试分析,独立路径：,误解或不正确的算术优先级；,运算方式错误；,不同数据类型的比较；,不正确的逻辑运算符或优先次序；,错误或不可能的循环终止条件；,不恰当的修改了循环变量；,因浮点数运算精度问题而造成的两值比较不等；,4.3 单元测试分析,出错处理：,出错的描述难以理解；,出错的描述不足以对错误定位和确定出错的原因；,显示的错误与实际的错误不符；,对错误条件的处理不正确；,在对错误进行处理之前，错误条件已经引起系统的干预；,遗漏的错误处理；,4.3 单元测试分析,边界条件：,循环条件；,控制流中刚好等于、大于、小于确定的比较值时出现错误的可能性；,4.4 单元测试用例设计,为正向测试设计用例；,-验证设计说明书所对应的功能项或性能指标能否兑现；,为逆向测试设计用例；,-验证被测的软件单元有没有做它不应该做的事情；,为满足特殊需求设计用例；,为代码覆盖设计用例；,为覆盖率指标完成设计用例；,4.4 单元测试用例设计,主要采用的方法：,等价类划分；,边界值分析；,定义/使用测试；,路径测试；,4.5 单元测试过程,测试计划,测试设计,测试执行,测试记录,分析,测试总结,完毕,缺陷跟踪,针对测试目标，规定测试任务、资源分配、人员角色、进度安排等。,根据测试计划，设计测试用例，包括：测试步骤、测试场景、测试代码、测试数据(包括预期结果)。,根据测试计划，配置测试环境，并手动或者自动执行测试设计。,根据测试计划，忠实地记录测试执行的过程和结果。,分析测试记录，如果发现与预期结果不同，确定并重现缺陷。,检查测试设计是否全部执行完毕，缺陷是否全部关闭。,记录、分发、评估、关闭缺陷报告。,分析测试过程和缺陷报告，评估测试质量和测试效果，给出是否通过测试的建议。,4.5 单元测试过程,测试文档：,测试计划,测试设计,测试执行,测试记录,分析,测试总结,完毕,缺陷跟踪,测试计划文档,测试用例文档,测试记录文档,缺陷跟踪报告,测试总结报告,4.5 单元测试过程,测试计划内容：,概要：,明确测试目的和主要任务，被测系统的简单描述，被测系统依赖的其它系统描述,领域：定义测试和不需要测试的内容，描述与测试计划相关的重要术语和缩略语，测试场所,建议的重大事件时间表：列出阶段性进度,转换标准：,允许系统进入一个特定的测试阶段所必须具备的条件。定义可能会导致测试执行挂起的状态和事件。说明如何决定测试何时可以结束,测试配置和环境：,测试执行：测试人员与分工，错误管理，测试周期等；,4.5 单元测试过程,测试计划内容：,风险和意外事故：,意外事件的对策,更改记录：,到目前为止对测试计划本身所作的更改和修订。内容可包括：编号、更改人、更改内容、修订的发布时间等。,参考文档：测试计划引用的其他文档。如:需求规范、设计规范、操作手册、标准、其他相关信息。,4.5 单元测试过程,测试方案内容：,概要,被测试特性：进一步明确和细化被测试的特性,测试需求：分析和明确功能等各方面的测试需求,测试方法：拟采用的具体测试技术和方法,需求规范追踪：把测试需求转化为测试设计,测试用例集描述：对测试用例分层次说明,更改记录,参考文档,4.5 单元测试过程,测试用例内容：,1 用例编号,10用例类别,2 用例名称,11用例状态,3 测试目的,12用例设计人,4 输入数据,13创建时间,5 测试步骤,14用例评审人,6 测试脚本,15评审时间,7 预期结果,16评审结果,8 响应时间,17执行结果,9 实际输出,18相关模块,4.5 单元测试过程,错误管理-缺陷的级别：,致命性错误（Critical）,数据丢失，数据计算错误、系统崩溃和非常死机,严重功能性错误(Serious),规定的功能没有实现或不完整、设计不合理造成性能低下，影响系统的运营,告警性错误(Moderate),不影响业务运营的功能问题,建议性错误(Suggestion,Cosmetic),软件设计和功能实现等不甚合理之处提出建议,4.5 单元测试过程,错误管理-修改级别：,高,中,低,4.5 单元测试过程,错误管理-错误描述：,1 分配给错误的ID号,2 提交错误的时间,3 错误提交人,4 版本号,发生错误的子系统或模块,5 错误发生的条件,6 对错误的详细描述,7 所使用的测试用例号,8 错误被发现的数据库,9 使用的机器号,10 错误的重要性,11 错误的改正优先级,12发生错误的子系统或模块及相关的模块,13 错误是否易再现,14 其他,4.5 单元测试过程,错误管理-错误跟踪：,1 错误负责人,6 错误改正后需要重新做的测试,2 严重性,7 改正错误所影响的组件,3 优先级,8 目前错误的状态,4 估计改正错误的日期,9 错误类别,5 估计改正错误所要花费的时间,10 解决办法,4.5 单元测试过程,错误管理-错误分发：,项目管理者,测试管理者,被分配修改错误的人,组件代码的编写人,测试小组中的其他成员,4.5 单元测试过程,错误管理-益处：,有利于缺陷的清楚传达,依据错误的相对和绝对重要性来修复问题,对错误实现全生命周期管理,当错误变化时相关人员及时获悉新的信息,错误的统计分析报告提供更多的信息,4.5 单元测试过程,错误管理-方法：,使用商业错误跟踪与管理系统,-testdirector,-IBM Rational,自行开发专用错误跟踪与管理系统,-NEUSOFT bugbase,4.5 单元测试过程,测试报告内容：,1 测试活动概述,6 结果描述,2 测试环境描述,7 意外事件,3 测试资源使用情况,8 遗留问题,4 差异描述,9 评价,5 测试充分性的评价,10 测试总结,4.6 单元测试应坚持的原则,应当尽早和不断地进行软件测试；,对全新的代码或修改过的代码一定要进行单元测试；,被测试的对象为实现一组相关功能的代码；,单元测试最好根据单元测试计划和方案进行，排除测试的随意性；,当测试用例的测试结果与预期结果不一致时，单元测试的执行人员需如实记录实际的测试结果；,当测试计划中的结束标准达到时，单元测试结束；,项目管理者保证测试用例经过审核；,当程序进行了修改，测试执行人员执行回归测试以保证对发现错误的修改没有引入新的错误；,小结,单元测试的定义、目的；,单元测试的内容；,如何进行单元测试用例设计；,单元测试应遵循的原则；,演讲完毕，谢谢观看！,内容总结,第四章 单元测试。单元测试（Unit Testing）是对软件基本组成单元进行的测试，单元的基本属性：。例：C+中的public的成员函数，单独的函数或类。检查不正确或不一致的数据类型说明。出错的描述不足以对错误定位和确定出错的原因。在对错误进行处理之前，错误条件已经引起系统的干预。-验证被测的软件单元有没有做它不应该做的事情。根据测试计划，配置测试环境，并手动或者自动执行测试设计。分析测试记录，如果发现与预期结果不同，确定并重现缺陷。检查测试设计是否全部执行完毕，缺陷是否全部关闭。记录、分发、评估、关闭缺陷报告。转换标准：允许系统进入一个特定的测试阶段所必须具备的条件。更改记录：到目前为止对测试计划本身所作的更改和修订。参考文档：测试计划引用的其他文档。如:需求规范、设计规范、操作手册、标准、其他相关信息。被测试特性：进一步明确和细化被测试的特性。测试需求：分析和明确功能等各方面的测试需求。演讲完毕，谢谢观看,