第2部分：软件测试技术.ppt

* 1 动态白盒测试/结构测试 查看并使用代码的内部结构设计和执行程序 动态：执行软件 白盒：洞察软件内部/代码、观察其运行情况 了解程序内部结构和软件工作方式有助于更好的设计测试用例进行更有效的测试 * 2 动态白盒测试??调试 共同点：查看代码和处理软件缺陷 不同点：目标不同 动态白盒测试：寻找软件缺陷 调试：修复软件缺陷 * 3 分段测试 尽早找出软件缺陷 团队合作、模块化设计、单元?集成?系统 单元测试?集成测试 容易隔离软件缺陷，且测试工作可同时进行（如同时测试多个模块） 单元级测试：缺陷在该单元内部 集成级测试：缺陷大多在模块之间的交互 * 单元测试 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。 目标：接口、数据结构、边界、覆盖、逻辑 * 单元测试 单元测试的被测对象是程序单元，而程序单元不是一个独立可运行的程序，同时在对每个单元进行单元测试时，也不能完全忽视它们和周围模块的相互关系。 两种辅助测试模块：驱动模块和桩模块。 驱动模块用以模拟被测模块的上层模块，测试执行时由驱动模块调用被测模块使其运行； 桩模块模拟被测模块执行时所调用的模块，测试执行时桩模块使被测模块能完整闭合地运行。 驱动模块 被测模块 桩模块 桩模块 桩模块 测试用例 测试结果 * 单元测试实例（P81） 确定待测模块是底层模块还是控制模块 分析说明书，确定应该采用的黑盒子测试用例 根据白盒知识增减测试用例 * 集成测试 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。在此过程当中应注意的问题： 在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失； 一个模块的功能是否会对另一个模块的功能产生不利的影响； 各个子功能组合起来，能否达到预期要求的父功能； 全局数据结构是否有问题； 单个模块的误差累积起来，是否会放大到不能接受的程度； 在单元测试的同时可进行组装测试； 发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。 * 集成方案 一次性组装/非增值式组装 增值式组装 自顶向下 自底向上 混合增值式 * 4 数据范围 数据流：调试，跟踪变量，适时修改测试用例 错误强制：强制显示错误提示信息 许多错误情况难以建立，如果只是想测试错误提示信息是否正确，那么使用错误强制是最有效的查看方式 。 * 5 代码范围 代码范围分析器（P87 图7-10） 获取哪些部分被执行、哪些部分未执行的统计结果 测试案例没有覆盖软件的哪些部分 哪些测试案例是多余的 需要建立什么样的新测试案例 程序语句和代码行范围（语句覆盖） 分支范围（分支覆盖） 条件范围（条件覆盖） * 总结 黑盒测试、白盒测试 白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档 黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档 静态测试、动态测试 静态黑盒测试（第4章） 动态黑盒测试（第5章） 静态白盒测试（第6章） 动态白盒测试（第7章） * 问题：有了“黑盒”测试为什么还要“白盒”测试？ 黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。 白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。 尽早的发现软件缺陷。 白盒测试可以观察程序代码内部结构和逻辑，可以审查代码的质量，如：代码的可读性、可维护性、可重用性等。 * * * * * * * * 桌面检查：这是一种传统的检查方法，由程序员检查自己编写的程序。 代码审查：由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步：第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。在会上，首先由程序员逐句简介程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。 走查：与代码审查基本相同，分为两步，第一步也是把材料分给走查小组的每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机，即首先由测试组成员为所测试程序准备一批有代表性的测