软件测试单元测试
合集下载
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
尽早发现软件缺陷,以找出动态黑盒白盒测试难以揭示或发现 的软件缺陷 为接受该软件测试的黑盒测试员进行测试设计测试案例提供思 路,他们不必了解代码细节,但是根据审查备注,可以确定有问 题或者容易存在软件缺陷的特性范围
问题:认为会减慢软件开发过程。
编码的标准和规范
标准:建立起来,经过修补和必须遵守的规则。
任务6:内存分析
内存泄漏会导致系统运行崩溃。
通过测量内存使用情况了解程序内存分配情况, 发现对内存的不正常使用,在问题出现前发现征 兆,在系统崩溃前发现内存泄漏错误;发现内存 分配错误。
5.3 静态测试技术的运用
定义:在不执行软件的条件下有条理地仔细审查软件设 计、体系结构和代码,从而找出软件缺陷的过程。有时也 称为结构分析。 作用:
审查结果
1.如果上述11个问题的答案均为"否",那么测试通过,请在此标记并且在最 后签名。 2.如果代码存在严重的问题,例如多个关键问题的答案为"是",那么程序编 制者纠正这些错误,并且必须重新安排一次单元测试。 下一次单元测试的日期:_________________________ 3.如果代码存在小的缺陷,那么程序编制者纠正这些错误,并且仲裁者必须 安排一次跟踪会议。 跟踪会议的日期:_________________________ 测试人签名:__________________ 日期:_________________
案例: 单元测试检查表
单元名称___________ 系统 _______________ 构造______________ 任务编号____________________ 初次测试日期_________________
关键测试项是否已纠正
1. 2. 3. 4. 5. 6. 7. 有无任何输入参数没有使用?有无任何输出参数没有产生? 有无任何数据类型不正确或不一致? 有无任何算法与PDL或功能需求中的描述不一致? 有无任何局部变量使用前没有初始化? 有无任何外部接口编码错误?即调用语句、文件存取、 数据库错误。 有无任何逻辑路径错误? 该单元是否有多个入口或多个正常的出口?
评审 (Review)
定义:通常在审查会后进行,审查小组根据记录 和报告进行评估。
注意:
充分审查了所规定的代码,并且全部编码准则被遵守。 审查中发现的错误已全部修改。
单元测试实例
一:基本路径测试 四:等价类划分、边界值分析 二、三:编程规范(静态检查)
五:错误推测、错误数据
5.5 调试与评估
单元测试的一般标准:
软件单元功能与设计需求一致。
软件单元接口与设计需求一致。 能够正确处理输入和运行中的错误。 在单元测试中发现的错误已经得到修改并且通过了测试。 达到了相关的覆盖率的要求。 完成软件单元测试报告
单元测试检查表 (1)
借助单元测试检查表进行评估。
信息能否正确地流入和流出单元; 在单元工作过程中,其内部数据能否保持其完整性,包括内 部数据的形式、内容及相互关系不发生错误,也包括全局变 量在单元中的处理和影响。 在为限制数据加工而设置的边界处,能否正确工作。 单元的运行能否做到满足特定的逻辑覆盖。 单元中发生了错误,其中的出错处理措施是否有效。
单元测试的定义
定义:
单元测试是对软件基本组成单元进行的测试。
时机:
一般在代码完成后由开发人员完成,QA人员辅助.
对象:
软件设计的最小单位——模块(组件、单元),z 作为单元能够实现一个特定的功能,并和其他单元 有明确的接口定义。
单元测试
目标:确保模块被正确地编码 依据:详细设计描述 过程:设计、脚本开发、执行、调试、分析结果 执行者:测试人员和开发人员 测试方法:白盒方法为主,辅以黑盒方法 评估:通过所有单元测试用例,代码没有严重缺陷。
输入数据
201,100,100 100,100,100 100,90,80 90,90,100
预期输出
空格 等边三角形 不等边三角形 等腰三角形
5.4 驱动程序和桩程序
驱动程序/驱动模块(driver),用以模拟被测
模块的上级模块。
作用:接受测试数据,把相关的数据传送给被 测模块,启动被测模块,并打印出相应的结果 。
审查 (Inspection)
定义:是最正式的审查类型,具有高度组织化,采用讲解、 提问方式进行,一般有正式的计划、流程和结果。主要方 法采用缺陷检查表。
注意:
以会议形式,制定会议目标、流程和规则,结束后要编 写报告。 发现问题适当记录,避免现场修改。 发现重大缺陷,改正后会议需要重开。 按缺陷检查表逐项检查。检查要点是缺陷检查表,所以 该表要根据项目不同不断积累完善。
编程过程中,每写100行代码会犯150个错误 编程与编译运行结束后,每100行代码中大约
残留有1-3个Bug 寻找与修改程序错误的代价占总体开发投资的 40%-80% Bug在整个研发流程中被发现的越早,修改的 代价就越低
5.2 单元测试的目标和任务
目标: 单元模块被正确编码 功能正确,结构可靠健全,并能在所有条件下正确 响应。
任务1: 模块独立执行通路测试
检查每一条独立执行路径的测试。保证每条语句 被至少执行一次。(基本路径测试)
Checklist: 算符优先级。 混合类型运算。 精度不够。 表达式符号。 循环条件,死循环。 其它
任务2: 模块局部数据结构测试
检查局部数据结构完整性
Checklist: 不适合或不相容的类型说明。 变量无初值。 变量初始化或默认值有错。 不正确的变量名或从来未被使用过。 出现上溢或下溢和地址异常。 其它
《单元测试检查表》
5. 评估 《单元测试报告》
5.7 单元测试常用工具简介
单元测试工具(xUnit工具家族)
Junit、CppUnit、NUnit、HtmlUnit等
静态检查工具 Checkstyle:对于代码规范的检查
PMD:增强代码质量和修改代码的功能 FindBug:检查二进制代码,寻找bug缺陷,并能进行优化
5.6 单元测试管理
过程:
1. 在详细设计阶段完成单元 测试计划。 2. 建立单元测试环境,完成 测试设计和开发。 3. 执行单元测试用例,并且 详细记录测试结果。 4. 判定测试用例是否通过。 5. 提交《单元测试报告》。
单元测试的文档
1. 《软件需求规格说明书》、《软件详细设计说明书》
《单元测试计划》 2. 《单元测试计划》、《软件详细设计说明书》 《单元测试用例》 3. 《单元测试用例》文档及《软件需求规格说明书》、《软件详细 设计说明书》 《缺陷跟踪报告》/《缺陷检查表》 4. 《单元测试用例》、《缺陷跟踪报告》、《缺陷检查表》
规范:建议最佳做法,推荐更好方法。 坚持编程标准和规范的原因
可靠性:事实证明按照按规范编写的代码更可靠, 软件缺陷将更少;
可读性/维护性:符合标准和规范的代码易于阅读, 理解和维护; 移植性:如果代码符合设备标准,迁移到另一个平 台就会容易,甚至没有任何障碍。
正式审查三部曲
走查 (Walk Through) 审查 (Inspection) 评审 (Review)
单元性能测试工具 SourceMonitor:为各种源代码文件测试代码的数量和性能。
走查 (Walk Through)
定义:编写代码的程序员向5人小组或其它类似 的程序员或测试员做正式表述。
注意:
审查人员应该在审查之前接到软件拷贝,在走查前 通读设计和编码,以便检查并编写备注和问题,在审 查过程中提问。 表述者现场采用讲解或模拟运行的方法解释代码如 何工作。 检查要点在于代码编写是否符合规范和标准,是否 存在逻辑错误; 限时,避免跑题。发现问题适当记录,避免现场修 改。
单元测试检查表 (2)
额外测试项
8.该单元中有任何地方与PDL与PROLOG中的描述不一致? 9.代码中有无任何偏离本项目标准的地方? 10.代码中有无任何对于用户来说不清楚的错误提示信息? 11.如果该单元是设计为可重用的,代码中是有可能妨碍重用的地方? 采取的动作和说明 (请用单独的一页或多页。每一项动作必须指出所引用的问题。)
软件测试方法和技术
- Ch.5单元测试
主讲教师:郭晓燕
第五章 单元测试
5.1 什么是单元测试 5.2 单元测试的目标和任务 5.3 静态测试 5.4 驱动程序与桩程序
5.5 调试与评估
5.6 单元测试管理 5.7 单元测试工具
5.1 什么是单元测试
测试的4个阶段:
单元测试集成测试 系统测试验收测试 按阶段进行测试是一种基本的测试策略
为何要进行单元测试?
尽早发现错误
单元测试 3小时 集成测试
错误发现越早,成本越低.
6小时 12小时
开发人员过于自信,后期复杂 度高,发现解决BUG困难.
系统测试
检查代码是否符合设计和规范
单元测试的背景
开发流程时间表与修改Bug代价的关系图
修 改 代 价
开发早期
开发结束
单元测试的背景(续)
六:性能检查
单元测试实例
白盒测试 路径测试1: path1:P(1-2-3-4-5-6-7-8-9-10)
path2:P(1-2-3-4-9-10)
用例编号 路径 输入 数据预期输出 1
2
path1100,100,100 path2201,100,100
True False
路径测试2: path1:P(11-12-13-14-23-24-25) path2:P(11-12-13-14-15-16-17-23-24-25) path3:P(11-12-13-14-15-18-19-23-24-25) path4:P(11-12-13-14-15-20-21-23-24-25) 用例编号 路径 1 path1 2 path2 3 Path3 4 Path4
桩程序/桩模块(stub),又称为存根程序,
用以模拟被测模块工作过程中所调用的模块。
作用:由被测模块调用,一般只进行很少的数 据处理,例如打印入口和返回,以便于检验被 测模块与其下级和调试是不同的。
白盒测试的目标是寻找软件缺陷; 调试的目的是修复软件缺陷。 它们在隔离软件缺陷的位置和原因上确实存在交叉现象。 测试员应该把问题缩减为能够演示软件缺陷的最简化测试案 例。在白盒测试中,甚至要包含那些值得怀疑的代码行信息。 进行调试的程序员从这里继续,判断到底是什么导致的软件 缺陷,并设法修复。 分清软件测试员和程序员的工作。 程序员编写代码,修复软件缺陷; 测试员寻找软件缺陷,可能还要编写一些代码来驱动测试, 要进行这样的底层测试,就要使用与程序员相同的工具。具 体操作方法不同
任务3: 模块接口测试
检查模块接口是否正确,checklist:
输入的实际参数与形式参数是否一致。
个数、属性、量纲
调用其他模块的实际参数与被调模块的形参是否一致。
个数、属性、量纲
全程变量的定义在各模块是否一致。
外部输入、输出
文件、缓冲区、错误处理
其它
任务4: 模块边界条件测试
走查与审查的比较
准备 走 查 通读设计和编码 审 查 应准备好需求描述文档、程序 设计文档、程序的源代码清 单、代码编码标准和代码缺 陷检查表 正式会议 项目组成员包括测试人员 缺陷检查表
形式 非正式会议 参加人员 开发人员为主 主要技术方法 无 注意事项 生成文档 目标
限时、不要现场修改代 限时、不要现场修改代码 码 会议记录 静态分析错误报告 代码标准规范,无逻辑 代码标准规范,无逻辑错误 错误
检查临界数据处理的正确性
Checklist: 普通合法数据的处理。 普通非法数据的处理。 边界值内合法边界数据的处理。 边界值外非法边界数据的处理。 其它
任务5:模块的各条错误处理通路测试
预见、预设的各种出错处理是否正确有效。
Checklist: 输出的出错信息难以理解。 记录的错误与实际不相符。 程序定义的出错处理前系统已介入。 异常处理不当。 未提供足够的定位出错的信息。 其它
问题:认为会减慢软件开发过程。
编码的标准和规范
标准:建立起来,经过修补和必须遵守的规则。
任务6:内存分析
内存泄漏会导致系统运行崩溃。
通过测量内存使用情况了解程序内存分配情况, 发现对内存的不正常使用,在问题出现前发现征 兆,在系统崩溃前发现内存泄漏错误;发现内存 分配错误。
5.3 静态测试技术的运用
定义:在不执行软件的条件下有条理地仔细审查软件设 计、体系结构和代码,从而找出软件缺陷的过程。有时也 称为结构分析。 作用:
审查结果
1.如果上述11个问题的答案均为"否",那么测试通过,请在此标记并且在最 后签名。 2.如果代码存在严重的问题,例如多个关键问题的答案为"是",那么程序编 制者纠正这些错误,并且必须重新安排一次单元测试。 下一次单元测试的日期:_________________________ 3.如果代码存在小的缺陷,那么程序编制者纠正这些错误,并且仲裁者必须 安排一次跟踪会议。 跟踪会议的日期:_________________________ 测试人签名:__________________ 日期:_________________
案例: 单元测试检查表
单元名称___________ 系统 _______________ 构造______________ 任务编号____________________ 初次测试日期_________________
关键测试项是否已纠正
1. 2. 3. 4. 5. 6. 7. 有无任何输入参数没有使用?有无任何输出参数没有产生? 有无任何数据类型不正确或不一致? 有无任何算法与PDL或功能需求中的描述不一致? 有无任何局部变量使用前没有初始化? 有无任何外部接口编码错误?即调用语句、文件存取、 数据库错误。 有无任何逻辑路径错误? 该单元是否有多个入口或多个正常的出口?
评审 (Review)
定义:通常在审查会后进行,审查小组根据记录 和报告进行评估。
注意:
充分审查了所规定的代码,并且全部编码准则被遵守。 审查中发现的错误已全部修改。
单元测试实例
一:基本路径测试 四:等价类划分、边界值分析 二、三:编程规范(静态检查)
五:错误推测、错误数据
5.5 调试与评估
单元测试的一般标准:
软件单元功能与设计需求一致。
软件单元接口与设计需求一致。 能够正确处理输入和运行中的错误。 在单元测试中发现的错误已经得到修改并且通过了测试。 达到了相关的覆盖率的要求。 完成软件单元测试报告
单元测试检查表 (1)
借助单元测试检查表进行评估。
信息能否正确地流入和流出单元; 在单元工作过程中,其内部数据能否保持其完整性,包括内 部数据的形式、内容及相互关系不发生错误,也包括全局变 量在单元中的处理和影响。 在为限制数据加工而设置的边界处,能否正确工作。 单元的运行能否做到满足特定的逻辑覆盖。 单元中发生了错误,其中的出错处理措施是否有效。
单元测试的定义
定义:
单元测试是对软件基本组成单元进行的测试。
时机:
一般在代码完成后由开发人员完成,QA人员辅助.
对象:
软件设计的最小单位——模块(组件、单元),z 作为单元能够实现一个特定的功能,并和其他单元 有明确的接口定义。
单元测试
目标:确保模块被正确地编码 依据:详细设计描述 过程:设计、脚本开发、执行、调试、分析结果 执行者:测试人员和开发人员 测试方法:白盒方法为主,辅以黑盒方法 评估:通过所有单元测试用例,代码没有严重缺陷。
输入数据
201,100,100 100,100,100 100,90,80 90,90,100
预期输出
空格 等边三角形 不等边三角形 等腰三角形
5.4 驱动程序和桩程序
驱动程序/驱动模块(driver),用以模拟被测
模块的上级模块。
作用:接受测试数据,把相关的数据传送给被 测模块,启动被测模块,并打印出相应的结果 。
审查 (Inspection)
定义:是最正式的审查类型,具有高度组织化,采用讲解、 提问方式进行,一般有正式的计划、流程和结果。主要方 法采用缺陷检查表。
注意:
以会议形式,制定会议目标、流程和规则,结束后要编 写报告。 发现问题适当记录,避免现场修改。 发现重大缺陷,改正后会议需要重开。 按缺陷检查表逐项检查。检查要点是缺陷检查表,所以 该表要根据项目不同不断积累完善。
编程过程中,每写100行代码会犯150个错误 编程与编译运行结束后,每100行代码中大约
残留有1-3个Bug 寻找与修改程序错误的代价占总体开发投资的 40%-80% Bug在整个研发流程中被发现的越早,修改的 代价就越低
5.2 单元测试的目标和任务
目标: 单元模块被正确编码 功能正确,结构可靠健全,并能在所有条件下正确 响应。
任务1: 模块独立执行通路测试
检查每一条独立执行路径的测试。保证每条语句 被至少执行一次。(基本路径测试)
Checklist: 算符优先级。 混合类型运算。 精度不够。 表达式符号。 循环条件,死循环。 其它
任务2: 模块局部数据结构测试
检查局部数据结构完整性
Checklist: 不适合或不相容的类型说明。 变量无初值。 变量初始化或默认值有错。 不正确的变量名或从来未被使用过。 出现上溢或下溢和地址异常。 其它
《单元测试检查表》
5. 评估 《单元测试报告》
5.7 单元测试常用工具简介
单元测试工具(xUnit工具家族)
Junit、CppUnit、NUnit、HtmlUnit等
静态检查工具 Checkstyle:对于代码规范的检查
PMD:增强代码质量和修改代码的功能 FindBug:检查二进制代码,寻找bug缺陷,并能进行优化
5.6 单元测试管理
过程:
1. 在详细设计阶段完成单元 测试计划。 2. 建立单元测试环境,完成 测试设计和开发。 3. 执行单元测试用例,并且 详细记录测试结果。 4. 判定测试用例是否通过。 5. 提交《单元测试报告》。
单元测试的文档
1. 《软件需求规格说明书》、《软件详细设计说明书》
《单元测试计划》 2. 《单元测试计划》、《软件详细设计说明书》 《单元测试用例》 3. 《单元测试用例》文档及《软件需求规格说明书》、《软件详细 设计说明书》 《缺陷跟踪报告》/《缺陷检查表》 4. 《单元测试用例》、《缺陷跟踪报告》、《缺陷检查表》
规范:建议最佳做法,推荐更好方法。 坚持编程标准和规范的原因
可靠性:事实证明按照按规范编写的代码更可靠, 软件缺陷将更少;
可读性/维护性:符合标准和规范的代码易于阅读, 理解和维护; 移植性:如果代码符合设备标准,迁移到另一个平 台就会容易,甚至没有任何障碍。
正式审查三部曲
走查 (Walk Through) 审查 (Inspection) 评审 (Review)
单元性能测试工具 SourceMonitor:为各种源代码文件测试代码的数量和性能。
走查 (Walk Through)
定义:编写代码的程序员向5人小组或其它类似 的程序员或测试员做正式表述。
注意:
审查人员应该在审查之前接到软件拷贝,在走查前 通读设计和编码,以便检查并编写备注和问题,在审 查过程中提问。 表述者现场采用讲解或模拟运行的方法解释代码如 何工作。 检查要点在于代码编写是否符合规范和标准,是否 存在逻辑错误; 限时,避免跑题。发现问题适当记录,避免现场修 改。
单元测试检查表 (2)
额外测试项
8.该单元中有任何地方与PDL与PROLOG中的描述不一致? 9.代码中有无任何偏离本项目标准的地方? 10.代码中有无任何对于用户来说不清楚的错误提示信息? 11.如果该单元是设计为可重用的,代码中是有可能妨碍重用的地方? 采取的动作和说明 (请用单独的一页或多页。每一项动作必须指出所引用的问题。)
软件测试方法和技术
- Ch.5单元测试
主讲教师:郭晓燕
第五章 单元测试
5.1 什么是单元测试 5.2 单元测试的目标和任务 5.3 静态测试 5.4 驱动程序与桩程序
5.5 调试与评估
5.6 单元测试管理 5.7 单元测试工具
5.1 什么是单元测试
测试的4个阶段:
单元测试集成测试 系统测试验收测试 按阶段进行测试是一种基本的测试策略
为何要进行单元测试?
尽早发现错误
单元测试 3小时 集成测试
错误发现越早,成本越低.
6小时 12小时
开发人员过于自信,后期复杂 度高,发现解决BUG困难.
系统测试
检查代码是否符合设计和规范
单元测试的背景
开发流程时间表与修改Bug代价的关系图
修 改 代 价
开发早期
开发结束
单元测试的背景(续)
六:性能检查
单元测试实例
白盒测试 路径测试1: path1:P(1-2-3-4-5-6-7-8-9-10)
path2:P(1-2-3-4-9-10)
用例编号 路径 输入 数据预期输出 1
2
path1100,100,100 path2201,100,100
True False
路径测试2: path1:P(11-12-13-14-23-24-25) path2:P(11-12-13-14-15-16-17-23-24-25) path3:P(11-12-13-14-15-18-19-23-24-25) path4:P(11-12-13-14-15-20-21-23-24-25) 用例编号 路径 1 path1 2 path2 3 Path3 4 Path4
桩程序/桩模块(stub),又称为存根程序,
用以模拟被测模块工作过程中所调用的模块。
作用:由被测模块调用,一般只进行很少的数 据处理,例如打印入口和返回,以便于检验被 测模块与其下级和调试是不同的。
白盒测试的目标是寻找软件缺陷; 调试的目的是修复软件缺陷。 它们在隔离软件缺陷的位置和原因上确实存在交叉现象。 测试员应该把问题缩减为能够演示软件缺陷的最简化测试案 例。在白盒测试中,甚至要包含那些值得怀疑的代码行信息。 进行调试的程序员从这里继续,判断到底是什么导致的软件 缺陷,并设法修复。 分清软件测试员和程序员的工作。 程序员编写代码,修复软件缺陷; 测试员寻找软件缺陷,可能还要编写一些代码来驱动测试, 要进行这样的底层测试,就要使用与程序员相同的工具。具 体操作方法不同
任务3: 模块接口测试
检查模块接口是否正确,checklist:
输入的实际参数与形式参数是否一致。
个数、属性、量纲
调用其他模块的实际参数与被调模块的形参是否一致。
个数、属性、量纲
全程变量的定义在各模块是否一致。
外部输入、输出
文件、缓冲区、错误处理
其它
任务4: 模块边界条件测试
走查与审查的比较
准备 走 查 通读设计和编码 审 查 应准备好需求描述文档、程序 设计文档、程序的源代码清 单、代码编码标准和代码缺 陷检查表 正式会议 项目组成员包括测试人员 缺陷检查表
形式 非正式会议 参加人员 开发人员为主 主要技术方法 无 注意事项 生成文档 目标
限时、不要现场修改代 限时、不要现场修改代码 码 会议记录 静态分析错误报告 代码标准规范,无逻辑 代码标准规范,无逻辑错误 错误
检查临界数据处理的正确性
Checklist: 普通合法数据的处理。 普通非法数据的处理。 边界值内合法边界数据的处理。 边界值外非法边界数据的处理。 其它
任务5:模块的各条错误处理通路测试
预见、预设的各种出错处理是否正确有效。
Checklist: 输出的出错信息难以理解。 记录的错误与实际不相符。 程序定义的出错处理前系统已介入。 异常处理不当。 未提供足够的定位出错的信息。 其它