单元测试分析与设计(ppt 31页).ppt

1、第四章 单元测试,4.1 什么是单元测试,规格定义,设计,编码,系统测试,集成测试,单元测试,用户需求,验收测试,回 归 测 试,配置管理,缺陷跟踪,4.1 什么是单元测试,单元测试（Unit Testing）是对软件基本组成单元进行的测试，单元的基本属性： 明确的功能； 规格定义； 与其他部分明确的接口定义； 例：C+中的public的成员函数，单独的函数或类；,4.1 什么是单元测试,单元测试的目的： 验证代码是否与设计相符； 跟踪需求和设计的实现； 发现设计和需求中存在的错误； 发现编码过程中引入的错误；,4.1 什么是单元测试,为什么进行单元测试？ 单元测试浪费了太多时间； 单元测试仅

2、仅是证明这些代码做了些什么； 我是个很棒的程序元，我可以不进行单元测试； 不管怎样，集成测试将会抓住所有的bug； 它的成本效率不高；,4.2 单元测试策略,桩模块（Stub）：用以模拟被测模块工作过程中所调用的模块，他们一般只进行很少的数据处理，例如打印入口和返回； 驱动模块（Driver）：用以模拟被测模块的上级模块，它接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印相应的结果；,4.2 单元测试策略,由顶向下的单元测试策略； - 先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块，其次对第二层进行测试，使用上面已测试的单元做驱动模块，以此类推； 由底向上的单元测试策略；

3、 - 先对模块调用层次图上最底层的模块进行单元测试，为该模块建立驱动模块，其次对上一层做单元测试，下面测试过的模块做桩模块，以此类推； 孤立测试 - 不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块；,4.3 单元测试分析,单元测试所考虑的方面：,模块,模块接口,局部数据结构,出错处理,独立路径,边界条件,4.3 单元测试分析,模块接口： 调用所测模块时的输入参数与模块的形参在个数、属性、顺序上是否匹配； 参数与变量的属性、单位是否一致； 全局变量的定义在每个模块中是否一致； - 是否修改只是作为输入值的变量； 有没有把常数当变量来传送； 调用内部函数时，变量的个数、属性和次

4、序是否正确；,4.3 单元测试分析,局部数据结构： 检查不正确或不一致的数据类型说明； 使用尚未赋值或尚未初始化的变量； 错误的初始值或错误的默认值； 变量名拼写错误或书写错误； 不一致的数据类型； 上溢、下溢或地址错误；,4.3 单元测试分析,独立路径： 误解或不正确的算术优先级； 运算方式错误； 不同数据类型的比较； 不正确的逻辑运算符或优先次序； 错误或不可能的循环终止条件； 不恰当的修改了循环变量； 因浮点数运算精度问题而造成的两值比较不等；,4.3 单元测试分析,出错处理： 出错的描述难以理解； 出错的描述不足以对错误定位和确定出错的原因； 显示的错误与实际的错误不符； 对错误条件的

5、处理不正确； 在对错误进行处理之前，错误条件已经引起系统的干预； 遗漏的错误处理；,4.3 单元测试分析,边界条件： 循环条件； 控制流中刚好等于、大于、小于确定的比较值时出现错误的可能性；,4.4 单元测试用例设计,为正向测试设计用例； - 验证设计说明书所对应的功能项或性能指标能否兑现； 为逆向测试设计用例； - 验证被测的软件单元有没有做它不应该做的事情； 为满足特殊需求设计用例； 为代码覆盖设计用例； 为覆盖率指标完成设计用例；,4.4 单元测试用例设计,主要采用的方法： 等价类划分； 边界值分析； 定义/使用测试； 路径测试；,4.5 单元测试过程,针对测试目标，规定测试任务、资源分

6、配、人员角色、进度安排等。,根据测试计划，设计测试用例，包括：测试步骤、测试场景、测试代码、测试数据(包括预期结果)。,根据测试计划，配置测试环境，并手动或者自动执行测试设计。,根据测试计划，忠实地记录测试执行的过程和结果。,分析测试记录，如果发现与预期结果不同，确定并重现缺陷。,检查测试设计是否全部执行完毕，缺陷是否全部关闭。,记录、分发、评估、关闭缺陷报告。,分析测试过程和缺陷报告，评估测试质量和测试效果，给出是否通过测试的建议。,4.5 单元测试过程,测试文档：,测试计划文档,测试用例文档,测试记录文档,缺陷跟踪报告,测试总结报告,4.5 单元测试过程,测试计划内容： 概要：明确测试目的

7、和主要任务，被测系统的简单描述，被测系统依赖的其它系统描述 领域：定义测试和不需要测试的内容，描述与测试计划相关的重要术语和缩略语，测试场所 建议的重大事件时间表：列出阶段性进度 转换标准：允许系统进入一个特定的测试阶段所必须具备的条件。定义可能会导致测试执行挂起的状态和事件。说明如何决定测试何时可以结束 测试配置和环境： 测试执行：测试人员与分工，错误管理，测试周期等；,4.5 单元测试过程,测试计划内容： 风险和意外事故：意外事件的对策 更改记录：到目前为止对测试计划本身所作的更改和修订。内容可包括：编号、更改人、更改内容、修订的发布时间等。 参考文档：测试计划引用的其他文档。如: 需求规

8、范、设计规范、操作手册、标准、其他相关信息。,4.5 单元测试过程,测试方案内容： 概要 被测试特性：进一步明确和细化被测试的特性 测试需求：分析和明确功能等各方面的测试需求 测试方法：拟采用的具体测试技术和方法 需求规范追踪：把测试需求转化为测试设计 测试用例集描述：对测试用例分层次说明 更改记录 参考文档,4.5 单元测试过程,测试用例内容：,4.5 单元测试过程,错误管理-缺陷的级别： 致命性错误（Critical） 数据丢失，数据计算错误、系统崩溃和非常死机 严重功能性错误(Serious) 规定的功能没有实现或不完整、设计不合理造成性能低下，影响系统的运营 告警性错误(Moderat

9、e) 不影响业务运营的功能问题 建议性错误(Suggestion,Cosmetic) 软件设计和功能实现等不甚合理之处提出建议,4.5 单元测试过程,错误管理-修改级别： 高 中 低,4.5 单元测试过程,错误管理-错误描述：,4.5 单元测试过程,错误管理-错误跟踪：,4.5 单元测试过程,错误管理-错误分发： 项目管理者 测试管理者 被分配修改错误的人 组件代码的编写人 测试小组中的其他成员,4.5 单元测试过程,错误管理-益处： 有利于缺陷的清楚传达 依据错误的相对和绝对重要性来修复问题 对错误实现全生命周期管理 当错误变化时相关人员及时获悉新的信息 错误的统计分析报告提供更多的信息,4.5 单元测试过程,错误管理-方法： 使用商业错误跟踪与管理系统 - testdirector - IBM Rational 自行开发专用错误跟踪与管理系统 - NEUSOFT bugbase,4.5 单元测试过程,测试报告内容：,4.6 单元测试应坚持的原则,应当尽早和不断地进行软件测试； 对全新的代码或修改过的代码一定要进行单元测试； 被测试的对象为实现一组相关功能的代码； 单元测试最好根据单元测试计划和方案进行，排除测试的随意性； 当测试用例的测试结果与预期结果不一致时，单