软件测试第四章单元测试_第1页
软件测试第四章单元测试_第2页
软件测试第四章单元测试_第3页
软件测试第四章单元测试_第4页
软件测试第四章单元测试_第5页
已阅读5页,还剩23页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试技术东北大学软件学院吴辰铌第四章单元测试主要内容4.1什么是单元测试4.2单元测试策略4.3单元测试分析4.4单元测试用例设计4.5单元测试过程4.6单元测试应坚持的原则4.7小结4.1什么是单元测试规格定义设计编码系统测试集成测试单元测试用户需求验收测试回归测试配置管理缺陷跟踪4.1什么是单元测试单元测试(UnitTesting)是对软件基本组成单元进行的测试,又称为模块测试。单元的基本属性:明确的功能规格定义与其它部分明确的接口定义例: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单元测试过程错误管理—缺陷的级别:致命性错误(Critical)数据丢失,数据计算错误、系统崩溃和经常死机。严重功能性错误(Serious)规定的功能没有实现或不完整、设计不合理造成性能低下,影响系统的运营。告警性错误(Moderate)不影响业务运营的功能问题。建议性错误(Suggestion,Cosmetic)软件设计和功能实现等不甚合理之处提出建议。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单元测试过程错误管理-方法:使用商业错误跟踪与管理系统TestdirectorIBMRational自行开发专用错误跟踪与管理系统4.5单元测试过程测试报告内容:1.测试活动概述6.结果描述2.测试环境描述7.意外事件3.测试资源使用情况8.遗留问题4.差异描述9.评价5.测试充分性的评价10.测试总结4.6单元测试应坚持的原则应当尽早和不断地进行软件测试。对全新的代码或修改过的代码一定要进行单元测试。被测试的对象为实现一组相关功能的代码。单元测试最好根据单元测试计划和方案进行,排除测试的随意性。当测试用例的测试结果与预期

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论