软件质量保证与测试 第五章 单元测试与集成测试

例1
#include <stdio.h> void main(void) { int a=1,b=2,c; c=fun1(a,b); } int fun1(int x,int y) { return x+y; }
例2
Driver Function under test
Stub
习题
为下面的函数构造一个驱动模块，并至少设计5条测 试用例。 /*计算2个整数的除法运算将结果转换为单精度输出*/ float divide(int a,int b) { float c; if(b==0) { printf(“除数不能为0!”); return 0; } c=(float)a/b; return c; }
4
5
例：C语言程序的静态测试 (1) #include<stdio.h> (2) max(float x,float y) (3) {float z; (4) z=x>y?x:y (5) return(z); (6) } (7) main() (8) {float a,b; (9) int c; (10) scanf(“%f,%f”,&a,&b); (11) c=max(a,b) (12) printf(“max is %d\n”,c); (13) }
试；
集成测试能找到所有的BUG；
6
任务１:单元独立执行路径的测试
对每一条独立执行路径进行测试，并保证每条语句 被至少执行一次。 检查的问题： 误解或用错了算符优先级 混合类型运算 变量初值错 精度不够 表达式符号错 其它
任务2:单元局部数据结构的测试
检查局部数据结构在程序执行过程中是否正确、 完整。 检查的问题： 不适合或不相容的类型说明 变量无初值 变量初始化或默认值有错 不正确的变量名或从来未被使用过 出现上溢或下溢和地址异常 其它
单元测试关注的主要内容
目标: 确保单元模块被正
确编码。 依据：详细设计描述，可 以是详细设计说明书、源 程序、单元测试计划； 过程：见右图 执行者：开发人员和测试 人员共同完成 测试方法：白盒为主，黑 盒为辅
通过单元测试的一般准则：P97
单元测试的误区
单元测试一种浪费时间的工作； 我是很棒的程序员，是不是可以不进行单元测
形式 参加人员 主要技术 方法 生成文档 目标
缺陷检查表
缺陷检查表：主要包括一些容易出错的地方和在 以往工作中遇到的典型错误，形成表格形式，目 的是防止人为的疏漏。
例：P104
5.3 动态测试
动态测试需要真正将 程序运行起来，需要 设计系列的测试用例 保证测试的完整性和 有效性。
白盒测试
黑盒测试
宜超过60～90分钟 在复审前，代码作者应该对代码进行注释 使用检查表（checklist）肯定能改进双方（作者和 复审者）的结果 验证缺陷是否真正被修复 ……
示例
走查（Walk Through）
定义：采用讲解、讨论和模拟运行的方式进行的 查找错误的活动。 注意：

引导小组成员在走查前通读设计和编码。 限时，避免跑题 发现问题适当记录，避免现场修改
1.空指针保护案例分析
5.4 代码评审案例分析
2.格式化数字错误案例分析
5.4 代码评审案例分析
3.字符串或数组越界案例分析
5.4 代码评审案例分析
4.其它案例
没有合理的关闭资源导致系统性能下降或最终崩溃
P.111(5.4.4)
不当使用synchronized导致系统性能下降或最终崩溃
P.113(5.4.5)
5.5 单元测试的结束
程序调试与测试的区别： 调试与测试的对象及采用的方法有很大程度上的相似，调试 还用到断点控制等排错方法，但其目的却完全不同。测试是为 了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。
单元测试的停止准则： （1）软件单元功能与设计需求一致； （2）软件单元接口与设计需求一致； （3）能够正确处理输入和运行中的错误； （4）在单元测试中发现的错误已经修改并通过了测试； （5）达到了相关的覆盖率的要求； （6）完成软件单元测试报告；
任务３:单元接口测试
检查单元接口是否正确 检查的问题： 输入的实际参数与形式参数是否一致(个数、 属性、量纲) 调用其他模块的实际参数与被调模块的形参个 数、属性、量纲是否一致。 全程变量的定义在各模块是否一致。 外部输入、输出 文件、缓冲区、错误处理 其它
任务４:单元边界条件的测试
7.
该单元是否有多个入口或多个正常的出口？
单元测试检查表 (2)
额外测试项 8.该单元中有任何地方与PDL与PROLOG中的描述不一致？ 9.代码中有无任何偏离本项目标准的地方？ 10.代码中有无任何对于用户来说不清楚的错误提示信息？ 11.如果该单元是设计为可重用的，代码中是有可能妨碍重用的地方？ 采取的动作和说明 （请用单独的一页或多页。每一项动作必须指出所引用的问题。）
5. SourceMonitor检测代码复杂度 6. 开源的单元测试工具 7. 商业的单元测试工具
单元测试工具种类
代码规则/风格检查工具 内存资源泄漏检查工具
代码覆盖率检查工具
代码性能检查工具
单元测试工具列表
5.6.1 JUnit
Junit（http://www.junit.org）是一款功能强大的开源的 Java单元测试工具，由Erich Gamma和Kent Beck两个人共 同开发完成。 准确地说，JUnit是一个测试框架，是单元测试框架体系 xUnit的一个实例。
灰盒测试
驱动程序和桩程序
运行单元程序有时需要基于被测单元的接口，开发 相应的驱动程序和桩程序。
驱动程序（drive）:所测
模块的主程序。它接收测 试数据，把这些数据传递 给所测试模块，最后再输 出测试结果。当被测试模 块能完成一定功能时，也 可以不要驱动模块。 桩程序（stub）：对顶层 或上层模块进行测试时所 编写的替代下层模块的程 序。
单元测试的过程有5个 步骤： （1）在详细设计阶段 完成单元测试计划； （2）建立单元测试环 境，完成测试设计 和开发； （3）执行单元测试用 例，并详细记录测 试结果； （4）判定测试用例是 否通过； （5）提交《单元测试 报告》。
单元测试 的过程
单元测试的过程与文档管理
时间
计划 详细设计 阶段 阶段后
阅读
Java编程规范：P100-102
5.2.2 代码评审
方法——三步曲：
互查（Peer Review） 走查（Walk Through）
审查（Inspection）
互查
一次检查少于200～400行代码 努力达到一个合适的检查速度：300～500LOC/
hour
有足够的时间、以适当的速度、仔细地检查，但不
审查结果 1.如果上述11个问题的答案均为"否"，那么测试通过，请在此标记并且在最后签 名。 2.如果代码存在严重的问题，例如多个关键问题的答案为"是"，那么程序编制者 纠正这些错误，并且必须重新安排一次单元测试。 下一次单元测试的日期：_________________________ 3.如果代码存在小的缺陷，那么程序编制者纠正这些错误，并且仲裁者必须安排 一次跟踪会议。 跟踪会议的日期：_________________________ 测试人签名：__________________ 日期：_________________
软件测试方法和技术
第5章 单元测试与集成测试
第五章 单元测试与集成测试
5.1 单元测试的目标和任务
5.2 单元的静态测试
5.3 驱动程序和桩程序
5.4 单元测试工具
5.5 集成测试
5.1 单元测试的目标和任务
为何要进行单元测试?
尽早发现错误

错误发现越早,成本越低. 发现问题比较容易 修正问题更容易
5.2 静态测试技术的运用
静态测试技术是单元测试中最重要的手段之一， 适用于新开发的和重用的代码。
通常在代码完成并无错误地通过编译或汇编后
进行，采用工具扫描分析、代码评审等方法。
5.2 静态测试技术的运用
静态测试是指不实际运行被测软件，而只是 静态地检查程序代码、界面或文档中可能存在 的错误的过程。 （1）代码测试：主要测试代码是否符合相应 的标准和规范 （2）界面测试：主要测试软件的实际界面与 需求中的说明是否相符 （3）文档测试：主要测试用户手册和需求说 明是否真正符合用户的需求 这里着重介绍代码测试。
单元测试检查表 (1)
借助单元测试检查表进行评估。
案例：
单元测试检查表
单元名称___________ 系统 _______________ 构造______________ 任务编号____________________ 初次测试日期_________________
关键测试项是否已纠正 1. 有无任何输入参数没有使用？有无任何输出参数没有产生？ 2. 有无任何数据类型不正确或不一致？ 3. 有无任何算法与PDL或功能需求中的描述不一致？ 4. 有无任何局部变量使用前没有初始化？ 5. 有无任何外部接口编码错误？即调用语句、文件存取、 数据库错误。 6. 有无任何逻辑路径错误？
检查边界数据处理的正确性 检查的问题： 普通合法数据的处理。 普通非法数据的处理。 边界值内合法边界数据的处理。 边界值外非法边界数据的处理。 其它
任务5: 单元容错性测试
预设的各种出错条件的处理是否正确有效。 检查的问题： 输出的出错信息难以理解 记录的错误与实际不相符 异常处理不当 未提供足够的定位出错的信息 其它
检查要点是代码是否符合标准和规范，是否有 逻辑错误
审查（Inspection）

以会议形式，制定目标、流程和规则


按缺陷检查表（不断完善）逐项检查
发现问题适当记录，避免现场修改
发现重大缺陷，改正后会议需要重开。
走查与审查的比较
准备 走 查 审 查 通读设计和编码 事先准备Spec、程序设计 文档、源代码清单、代码 缺陷检查表等 非正式会议 正式会议 开发人员为主 项目组成员包括测试人员 无 缺陷检查表 会议记录 代码标准规范 无逻辑错误 静态分析错误报告 代码标准规范 无逻辑错误
5.2.1 编码的标准和规范
标准： 建立起来必须遵守的规则 规范： 建议最佳做法，推荐更好方式 实施代码规范的原因： 可靠性 可读性和可维护性 可移植性
C语言编码规范
规范 规范内容 编号 1 一行代码只做一件事情 2 3 代码行的最大长度宜控制在70-80个字 函数与函数之间，说明语句和执行语句 之间最好加空行 在程序开头加注释，说明基本信息；在 重要函数处加注释，说明其功能 不要漏掉函数的参数和返回值，如果没 有，用void表示 是否 通过
习题解答
第一步： 构造驱动模块如下： void main(void) { int x; int y; float z; scanf(“%d%d”,&x,&y); z=divide(x,y); printf(“%f”,z); }
习题解答
第二步：编写5条测试用例，如下表所示：
5.4 代码评审案例分析
测试用例的编 写 驱动模块、桩 模块的设计 执行测试用例 记录缺陷
单元测试用例
《缺陷跟踪报 告》
评估 阶段
完备性评估 代码覆盖率评 估
《单元测试报 告》
5.6 单元测试常用工具简介
1. JUnit介绍
2. 在Eclipse中JUnit应用举例
3. Junit+Ant构建自动的单元测试
4. CheckStyle/PMD与FindBug的使用
依据
《软件需求规格说明 书》《详细设计说明 书》
任务
制定测试计划
成果
单元测试计划
设计 《单元测 阶段 试计划》 提交后 执行 编码完成 阶段 后
《单元测试计划》 《软件详细设计说明 书》 《单元测试用例》 《软件需求规格说明 书》《详细设计说明 书》
《单元测试用例》 《缺陷跟踪报告》 《缺陷检查表》
检查代码是否符合设计和规范，有利于将来代
ຫໍສະໝຸດ Baidu
码的维护
5.1 单元测试的目标和任务
定义
单元测试是对软件基本的组成单元进行独立的 测试。
时机
单元测试和编码是同步进行，但在TDD中，强 调测试在先，编码在后。单元测试一般由开发人 员完成,QA人员辅助。
单元
一个最小的单元应该有明确的功能、接口定义 而且可以清析地与其他单元区分开。