软件测试单元测试
合集下载
- 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: 输出的出错信息难以理解。 记录的错误与实际不相符。 程序定义的出错处理前系统已介入。 异常处理不当。 未提供足够的定位出错的信息。 其它