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

《软件质量保证与测试第五章单元测试与集成测试精要》由会员分享，可在线阅读，更多相关《软件质量保证与测试第五章单元测试与集成测试精要（76页珍藏版）》请在金锄头文库上搜索。

1、 软件测试方法和技术 第5章 单元测试与集成测试 第五章 单元测试与集成测试 5.1 单元测试的目标和任务 5.2 单元的静态测试 5.3 驱动程序和桩程序 5.4 单元测试工具 5.5 集成测试 为何要进行单元测试? p尽早发现错误 l 错误发现越早,成本越低. l 发现问题比较容易 l 修正问题更容易 p检查代码是否符合设计和规范，有利于将来代 码的维护 5.1 单元测试的目标和任务 5.1 单元测试的目标和任务 p定义 单元测试是对软件基本的组成单元进行独立的 测试。 p时机 单元测试和编码是同步进行，但在TDD中，强 调测试在先，编码在后。单元测试一般由开发人 员完成,QA人员辅助。

2、p单元 一个最小的单元应该有明确的功能、接口定义 而且可以清析地与其他单元区分开。 单元测试关注的主要内容 p目标: 确保单元模块被正 确编码。 p依据：详细设计描述，可 以是详细设计说明书、源 程序、单元测试计划； p过程：见右图 p执行者：开发人员和测试 人员共同完成 p测试方法：白盒为主，黑 盒为辅 通过单元测试的一般准则：P97 单元测试的误区 6 p单元测试一种浪费时间的工作； p我是很棒的程序员，是不是可以不进行单元测 试； p集成测试能找到所有的BUG； 任务:单元独立执行路径的测试 对每一条独立执行路径进行测试，并保证每条语句 被至少执行一次。 检查的问题： p 误解或用错了算

3、符优先级 p 混合类型运算 p 变量初值错 p 精度不够 p 表达式符号错 p 其它 任务2:单元局部数据结构的测试 检查局部数据结构在程序执行过程中是否正确、 完整。 检查的问题： p 不适合或不相容的类型说明 p 变量无初值 p 变量初始化或默认值有错 p 不正确的变量名或从来未被使用过 p 出现上溢或下溢和地址异常 p 其它 任务:单元接口测试 检查单元接口是否正确 检查的问题： p输入的实际参数与形式参数是否一致(个数、 属性、量纲) p调用其他模块的实际参数与被调模块的形参个 数、属性、量纲是否一致。 p全程变量的定义在各模块是否一致。 p外部输入、输出 p文件、缓冲区、错误处理 p

4、其它 任务:单元边界条件的测试 检查边界数据处理的正确性 检查的问题： p 普通合法数据的处理。 p 普通非法数据的处理。 p 边界值内合法边界数据的处理。 p 边界值外非法边界数据的处理。 p 其它 任务5: 单元容错性测试 预设的各种出错条件的处理是否正确有效。 检查的问题： p 输出的出错信息难以理解 p 记录的错误与实际不相符 p 异常处理不当 p 未提供足够的定位出错的信息 p 其它 5.2 静态测试技术的运用 静态测试技术是单元测试中最重要的手段之一 ，适用于新开发的和重用的代码。 通常在代码完成并无错误地通过编译或汇编后 进行，采用工具扫描分析、代码评审等方法。 5.2 静态测试

5、技术的运用 静态测试是指不实际运行被测软件，而只是 静态地检查程序代码、界面或文档中可能存在 的错误的过程。 （1）代码测试：主要测试代码是否符合相应 的标准和规范 （2）界面测试：主要测试软件的实际界面与 需求中的说明是否相符 （3）文档测试：主要测试用户手册和需求说 明是否真正符合用户的需求 这里着重介绍代码测试。 5.2.1 编码的标准和规范 标准： p 建立起来必须遵守的规则 规范： p 建议最佳做法，推荐更好方式 实施代码规范的原因： p 可靠性 p 可读性和可维护性 p 可移植性 C语言编码规范 规范规范 编号编号 规范内容规范内容是否是否 通过通过 1 1 一行代码只做一件事情一

6、行代码只做一件事情 2 2 代码行的最大长度宜控制在代码行的最大长度宜控制在70-8070-80个字个字 3 3 函数与函数之间，说明语句和执行语句函数与函数之间，说明语句和执行语句 之间最好加空行之间最好加空行 4 4 在程序开头加注释，说明基本信息；在在程序开头加注释，说明基本信息；在 重要函数处加注释，说明其功能重要函数处加注释，说明其功能 5 5 不要漏掉函数的参数和返回值，如果没不要漏掉函数的参数和返回值，如果没 有，用有，用voidvoid表示表示 例：C语言程序的静态测试 (1) #include (2) max(float x,float y) (3) float z; (4)

7、 z=xy?x:y (5) return(z); (6) (7) main() (8) float a,b; (9) int c; (10) scanf(“%f,%f”, (11) c=max(a,b) (12) printf(“max is %dn”,c); (13) 阅读 Java编程规范：P100-102 方法三步曲： p互查（Peer Review） p走查（Walk Through） p审查（Inspection） 5.2.2 代码评审 p一次检查少于200400行代码 p努力达到一个合适的检查速度：300500LOC/ hour p有足够的时间、以适当的速度、仔细地检查，但不 宜超

8、过6090分钟 p在复审前，代码作者应该对代码进行注释 p使用检查表（checklist）肯定能改进双方（作者和 复审者）的结果 p验证缺陷是否真正被修复 p 互查 示例 走查（Walk Through） 定义：采用讲解、讨论和模拟运行的方式进行的 查找错误的活动。 注意： p 引导小组成员在走查前通读设计和编码。 p 限时，避免跑题 p 发现问题适当记录，避免现场修改 p 检查要点是代码是否符合标准和规范，是否有 逻辑错误 审查（Inspection） p 以会议形式，制定目标、流程和规则 p 按缺陷检查表（不断完善）逐项检查 p 发现问题适当记录，避免现场修改 p 发现重大缺陷，改正后会议

9、需要重开。 走查与审查的比较 走 查审 查 准备通读设计和编码 事先准备Spec、程序设计 文档、源代码清单、代码 缺陷检查表等 形式非正式会议正式会议 参加人员开发人员为主项目组成员包括测试人员 主要技术 方法 无缺陷检查表 生成文档会议记录静态分析错误报告 目标代码标准规范 无逻辑错误 代码标准规范 无逻辑错误 缺陷检查表 缺陷检查表：主要包括一些容易出错的地方和在 以往工作中遇到的典型错误，形成表格形式，目 的是防止人为的疏漏。 例：P104 5.3 动态测试 动态测试需要真正将 程序运行起来，需要 设计系列的测试用例 保证测试的完整性和 有效性。 p 白盒测试 p 黑盒测试 p 灰盒测

10、试 驱动程序和桩程序 p驱动程序（drive）:所测 模块的主程序。它接收测 试数据，把这些数据传递 给所测试模块，最后再输 出测试结果。当被测试模 块能完成一定功能时，也 可以不要驱动模块。 p桩程序（stub）：对顶层 或上层模块进行测试时所 编写的替代下层模块的程 序。 运行单元程序有时需要基于被测单元的接口，开发 相应的驱动程序和桩程序。 #include void main(void) int a=1,b=2,c; c=fun1(a,b); int fun1(int x,int y) return x+y; 例1 例2 Driver Stub Function under test

11、为下面的函数构造一个驱动模块，并至少设计5条测 试用例。 /*计算2个整数的除法运算将结果转换为单精度输出*/ float divide(int a,int b) float c; if(b=0) printf(“除数不能为0!”); return 0; c=(float)a/b; return c; 习题 第一步： 构造驱动模块如下： void main(void) int x; int y; float z; scanf(“%d%d”, z=divide(x,y); printf(“%f”,z); 习题解答 第二步：编写5条测试用例，如下表所示： 习题解答 1.空指针保护案例分析 5.4

12、代码评审案例分析 2.格式化数字错误案例分析 5.4 代码评审案例分析 3.字符串或数组越界案例分析 5.4 代码评审案例分析 4.其它案例 p 没有合理的关闭资源导致系统性能下降或最终崩溃 P.111(5.4.4) p 不当使用synchronized导致系统性能下降或最终崩溃 P.113(5.4.5) 5.4 代码评审案例分析 5.5 单元测试的结束 程序调试与测试的区别： 调试与测试的对象及采用的方法有很大程度上的相似，调试 还用到断点控制等排错方法，但其目的却完全不同。测试是为 了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。 单元测试的停止准则： （1）软件单元功能与设计需求一致

13、； （2）软件单元接口与设计需求一致； （3）能够正确处理输入和运行中的错误； （4）在单元测试中发现的错误已经修改并通过了测试； （5）达到了相关的覆盖率的要求； （6）完成软件单元测试报告； 单元测试检查表 (1) 单元测试检查表 单元名称_ 系统 _ 构造_ 任务编号_ 初次测试日期_ 关键测试项是否已纠正 1.有无任何输入参数没有使用？有无任何输出参数没有产生？ 2.有无任何数据类型不正确或不一致？ 3.有无任何算法与PDL或功能需求中的描述不一致？ 4.有无任何局部变量使用前没有初始化？ 5.有无任何外部接口编码错误？即调用语句、文件存取、 数据库错误。 6.有无任何逻辑路径错误？

14、7.该单元是否有多个入口或多个正常的出口？ 借助单元测试检查表进行评估。 案例： 单元测试检查表 (2) 额外测试项 8.该单元中有任何地方与PDL与PROLOG中的描述不一致？ 9.代码中有无任何偏离本项目标准的地方？ 10.代码中有无任何对于用户来说不清楚的错误提示信息？ 11.如果该单元是设计为可重用的，代码中是有可能妨碍重用的地方？ 采取的动作和说明 （请用单独的一页或多页。每一项动作必须指出所引用的问题。） 审查结果 1.如果上述11个问题的答案均为“否“，那么测试通过，请在此标记并且在最后签 名。 2.如果代码存在严重的问题，例如多个关键问题的答案为“是“，那么程序编制者 纠正这些

15、错误，并且必须重新安排一次单元测试。 下一次单元测试的日期：_ 3.如果代码存在小的缺陷，那么程序编制者纠正这些错误，并且仲裁者必须安排 一次跟踪会议。 跟踪会议的日期：_ 测试人签名：_ 日期：_ 单元测试 的过程 单元测试的过程有5个 步骤： （1）在详细设计阶段 完成单元测试计划 ； （2）建立单元测试环 境，完成测试设计 和开发； （3）执行单元测试用 例，并详细记录测 试结果； （4）判定测试用例是 否通过； （5）提交单元测试 报告。 单元测试的过程与文档管理 时间依据任务成果 计划 阶段 详细设计 阶段后 软件需求规格说明 书详细设计说明 书 制定测试计划单元测试计划 设计 阶段 单元测 试计划 提交后 单元测试计划 软件详细设计说明书 测试用例的编 写 驱动模块、桩 模块的设计 单元测试用例 执行 阶段 编码完成 后 单元测试用例 软件需求规格说明书 详细设计说明书 执行测试用例 记录缺陷 缺陷跟踪报 告 评估 阶段 单元测试用例 缺陷跟踪报告缺 陷检查表 完备性评估 代码覆盖率评 估 单元测试报 告 5.6 单元测试常用工具简介 1. JUnit介绍 2. 在Eclipse中JUnit应用举例 3. Junit