软件测试技术完整教程PPT课件

第一章概述 本章要点 软件测试的发展历史 软件测试技术的分类方法 软件测试原则 软件测试的定义 软件测试同软件开发之间的关系 软件测试与开发模型 软件测试工作流程 本章目标 了解软件测试的发展历程和行业现状 掌握软件测试技术的分类 理解软件测试的目的和软件测试原则 以及了解人们对软件测试行业的错误认识 掌握软件测试中的基本定义 基本知识 理解软件开发与软件测试的关系 1 1软件测试的发展历程及现状1 1 1软件测试的发展历程20世纪50 60年代 软件仍然处于次要位置 测试理论和方法的发展比较缓慢 70年代以后 软件技术的成熟和完善使得软件测试的规模和复杂度加大 软件测试也逐渐形成了一套完整的体系 逐渐走向规范化 1 1 2软件测试的现状与一些发达国家相比 国内测试工作还存在一定的差距 国内测试人员所占比例小 但是 在软件测试实现方面都是相当的 而且向产业化方向发展 1 2什么是软件测试1 2 1软件测试的定义根据侧重点的不同 主要有以下三种观点 1 1983年IEEE将软件测试定义为 使用人工或自动手段运行或测定某个系统的过程 其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别 该定义明确地提出了软件测试以检验是否满足需求为目标 2 Myers认为 是为了发现错误而执行程序的过程 明确提出了 寻找错误 是测试目的 3 从软件质量保证的角度看 是一种重要的软件质量保证活动 其动机是通过一些经济 高效的方法 捕捉软件中的错误 从而达到保证软件内在质量的目的 测试过程中的活动包括 分析 软件 静态测试 和 运行 软件 动态测试 也有人认为软件测试 softwaretesting 就是在软件投入运行前 对软件需求分析 设计规格说明和编码的最终复审 是软件质量保证的关键步骤 软件测试有两个基本职责 即验证和确认 注意 区分软件测试和软件调试 1 2 2软件测试生命周期测试的生命周期 softwaretestinglifecycle 分为几个阶段 如图1 1所示 前三个阶段就是引入程序错误阶段 后三个阶段就是清除程序错误的阶段 图1 1测试生命周期 1 2 3软件开发与测试模型下面我们将介绍几种典型的软件开发与测试模型 一 软件开发与测试V模型在传统开发过程中测试不受重视 仅把它作为在需求分析 概要设计 详细设计及编码之后的一个阶段 尤其在瀑布模型中 如图1 2所示 在V模型中 描述了一些不同的测试级别 并说明了这些级别所对应的生命周期中不同的阶段 清楚地描述了这些测试阶段和开发过程期间的对应关系 图1 2V模型示意图 V模型适用于所有类型的开发过程 但并不一定适用于开发和测试过程的所有方面 二 软件开发与测试W模型由于各种原因 开发的每一个环节都可能产生错误 如果坚持各个阶段的技术评审 就能够尽早发现和预防错误 图1 3为软件开发与测试的W模型 形象地说明了软件测试与开发的这种同步性 图1 3W模型示意图 应用该模型的优点在于 每个软件开发活动结束后就可以执行相应的测试 如 在需求分析结束后 就可以进行需求分析测试 三 软件开发与测试H模型与前两种模型相比 H模型充分地体现了测试过程 如图1 4所示的H模型揭示了 1 软件测试不仅仅指测试的执行 还包括很多其他的活动 2 软件测试是一个独立的流程 贯穿产品的整个开发周期 与其它流程并发进行 3 软件测试要尽早准备 尽早执行 图1 4H模型示意图 4 软件测试根据被测物的不同是分层次的 不同层次的测试活动可以是按照某个次序先后进行的 但也可能是反复的 1 2 4与软件测试相关的术语1 错误 Error 程序员在编写代码时会出错 我们把这种错误称之为bug 随着开发过程的进行 错误会不断的放大 2 缺陷 Default 缺陷是错误的结果 更精确的说是错误的表现 3 失效 Failure 在缺陷运行时 常常会发生失效的情况 一种是过错缺陷对应的失效 一种是遗漏缺陷对应的失效 4 测试 Test 测试是一项采用测试用例执行软件的活动 在这项活动中某个系统或组成的部分将在特定的条件下运行 然后要观察并记录结果 以便对系统或组成部分进行评价 5 测试用例 TestCase 测试用例是为特定的目的而设计的一组测试输入 执行条件和预期的结果 6 回归测试 Regressiontesting 回归测试的目的是为了测试由于修正缺陷而更新的应用程序 以确保彻底修正了上一个版本的缺陷 并且没有引入新的软件缺陷 1 3软件测试技术分类从不同的角度 可以把软件测试技术分成不同种类 如 一 从是否需要执行被测软件的角度 可分为静态测试和动态测试 那些不利用计算运行被测程序 而是通过其他手段达到测试目的的方法称作静态测试 下面我们对这几种静态测试分别加以介绍 代码检查 代码走查 桌面检查 同行评分下面我们将要介绍的黑盒测试和白盒测试就属于动态测试 二 从软件测试用例设计方法的角度 可分为黑盒测试 Black BoxTesting 和白盒测试 White BoxTesting 三 按照软件测试的策略和过程分类 软件测试可分为单元测试 UnitTesting 集成测试 IntegrationTesting 确认测试 ValidationTesting 系统测试 SystemTesting 和验收测试 VerificationTesting 1 4软件测试的目的测试真正的目的是使我们通过对软件错误的原因和分布进行归纳 来发现并排除当前软件产品的缺陷 对在需求和设计过程中存在的问题查缺补漏 从而确保软件产品的质量 G Myers给出了关于测试的一些规则 我们也可以把这些规则看作是测试的目标 1 软件测试是为了发现错误而执行程序的过程 2 测试是为了证明程序有错 而不是证明程序无错 3 一个好的测试用例在于他能发现至今未发现的错误 4 一个成功的测试是发现了至今未发现的错误的测试 这里要强调的一点是 软件测试不只是软件测试人员的工作 也是软件开发人员和软件使用者的工作 1 5软件测试的原则1 5 1尽早地和不断地进行软件测试IBM的研究结果表明 缺陷存在放大趋势 图1 5表示了缺陷放大模型大致状况 图1 5缺陷放大模型 由此可见 问题发现越早 解决问题的代价就越小 这是软件开发过程中的黄金法则 1 5 2不可能完全的测试对一个程序进行完全测试就是意味着在测试结束之后 再也不会发现其它的软件错误了 其实 这是不可能的 主要原因有以下几点 一 不可能测试程序对所有可能输入的响应 二 不可能测试到程序每一条可能的执行路径三 无法找出所有的设计错误四 不能采用逻辑来证明程序的正确性 1 5 3增量测试 由小到大 图1 7测试资源关系图 由小到大 指的是软件测试的粒度 无论是传统的软件测试还是面向对象的软件测试都要遵循这样的原则 如图1 7所示 多个单元组合过渡到集成测试阶段 集成测试阶段过渡到更高级别的系统测试阶段 虚线是各个测试阶段的发布基线 随着测试的逐步深入 范围的逐步扩大 测试时间 可用资源也随之增大 1 5 4避免测试自己的程序避免程序员测试自己的代码的主要原因归纳如下 1 程序员轻易不会承认自己写的程序有错误 2 程序员的测试思路有局限性 在做测试时很容易受到编程思路的影响 3 多数程序员没有严格正规的职业训练 缺乏专业测试人员的意识 4 程序员没有养成错误跟踪和回归测试的习惯 1 5 5设计周密的测试用例软件测试的本质就是针对要测试的内容确定一组测试用例 测试用例至少应该包括如下几个基本信息 1 在执行测试用例之前 应满足的前提条件 2 输入 合理的 不合理的 3 预期输出 包括后果和实际输出 图1 8显示了一个典型的测试用例所应该具有的基本信息 图1 8典型的测试用例信息 测试用例是测试工作的核心 应该尽量设计的周密细致 这样才能更好的保证测试工作的质量 下面举例来说明这一点 以一个实现登录功能的小程序为例 它允许用户选择城市和地区 输入自己的账号和密码 如图1 9所示 通过Alt F4组合键和 Exit 按钮来终止程序 Tab键在区域中间移动 图1 9登录窗口 下面根据组成页面的具体元素 分别从几个方面做了一些比较全面的测试用例 1 下拉框和输入框测试用例表1 1下拉框和输入框测试用例 2 功能测试 表1 2功能测试用例 3 各种错误数据的测试表1 3错误数据的测试用例 4 特殊测试表1 4特殊测试用例 1 5 6注意错误集中的现象软件缺陷的 扎堆 现象的常见形式 1 对话框的某个控件功能不起作用 可能其他控件的功能也不起作用 2 某个文本框不能正确显示双字节字符 则其他文本框也可能不支持双字节字符 3 联机帮助某段文字的翻译包含了很多错误 与其相邻的上下段的文字可能也包含很多的语言质量问题 4 安装文件某个对话框的 上一步 或 下一步 按钮被截断 则这两个按钮在其他对话框中也可能被截断 1 5 7确认BUG的有效性有时候测试人员提交的BUG并不是真正的BUG 图1 10具体地描述了无效BUG的来源 一般由A测试人员发现的BUG 一定要由另外一个B测试人员来进行确认 如果发现严重的BUG可以召开评审会进行讨论和分析 图1 10无效BUG来源构成图 1 5 8合理安排测试计划合理的测试计划有助于测试工作顺利有序地进行 因此要求在对软件进行测试之前所作的测试计划中 应该结合了多种针对性强的测试方法 列出所有可使用资源 建立一个正确的测试目标 要本着严谨 准确的原则 周到细致地做好测试前期的准备工作 避免测试的随意性 尤其是要尽量科学合理地安排测试时间 图1 11错误依赖关系 1 5 9回归测试 这些错误之间存在单纯的依赖或者复杂的多重依赖关系 如图1 11所示 其中 a 图中的A B关系表达为 A错误依赖于B错误的关闭而关闭 如果多了一条路径 如 b 图中A B C关系 A错误依赖于B错误和C错误的同时关闭而关闭 c 图是 a 和 b 的复合方式 因程序中的错误存在着一对多 多对多的复杂关系而变得难以处理 并且有些错误关联和依赖关系处于隐性状态 1 5 10测试结果的统计和分析只有对这些输出信息进行深入地统计 分析和比较 才能够正确的鉴别测试后输出的数据 给出清晰的错误原因分析报告 当输出的信息很庞大时 我们可以借助专业的测试工具 1 5 11及时更新测试事实上 有可能导致测试失败的原因还有很多 可大致归纳为如下几点 1 测试团队管理者失职 2 测试团队中沟通不好 3 测试团队和项目团队沟通不良 4 测试过程中 执行角色无准确定义 5 测试团队缺乏良好的培训 1 6软件测试工作流程一般的软件测试总体工作流程如图1 12所示 图1 12软件测试工作总体流程图 1 需求阶段需求阶段是软件测试活动的前提 需求阶段测试工作流程如图1 13所示 图1 13需求阶段测试活动流程图 2 设计 编码阶段测试工作流程 图1 14设计 编码阶段测试流程图 这一环节以模块为单位循环 单元测试方案制定 编码 单元测试是否通过 测试抽检是否通过 重新编写没有通过单元测试和测试抽检的代码 最终形成一份单元测试总结报告 具体流程如图1 14所示 3 集成测试 系统测试和验收测试阶段该测试阶段流程如图1 15所示 图1 15集成测试 系统测试和验收测试阶段流程图 1 7软件测试中的误区误区1调试和测试是一样的误区2软件测试在软件开发过程中并不重要误区3在软件开发结束之后进行测试误区4过分依赖Beta测试误区5过分依赖自动化测试误区6测试是可穷尽的误区7测试是证明软件的正确性误区8可以忽略测试的设计1 8一个贯穿全文的例子 电厂两票管理系统 1 8 1系统简介操作票 工作票 简称两票 是 电业 电厂 安全工作规程 中的核心内容之一 对保证电业安全生产具有重要的作用 操作票是保证正确电气倒闸 热机 操作的重要环节和前提条件 使用操作票的目的是为了保障人身与设备的安全 确保电气设备倒闸操作的正确性 防止电气误操作事故发生 工作票是保证电气 电厂设备 检修工作安全的重要措施 是检修人员在运行设备上或运行区域内进行检修和试验工作 以及做可能影响设备的正常运行或备用状态的其它工作的重要书面依据 两票 的办理过程基本上都是开票 各部门负责人或三种人审批签字 工作结束 部门或厂部检查审核这样的一种线性办理过程 电力部门分为水电 火电 供电三种类型 各厂 局要处理的两票类型通常有 水电厂 电气一种工作票 电气二种工作票 水力机械工作票 一级动火工作票 二级动火工作票 电气倒闸操作票 继保安措票 脚手架工作单 水力机械操作票 溢洪闸门操作票火电厂 电气一种工作票 电气二种工作票 水力机械工作票 一级动火工作票 二级动火工作票 电气倒闸操作票 继保安措票 脚手架工作单 热力工作票供电局 电气一种工作票 电气二种工作票 水力机械工作票 一级动火工作票 二级动火工作票 电气倒闸操作票 继保安措票 脚手架工作单 一种工作票 线路二种工作票 为了使读者更好的了解两票系统以及后面各章节的内容 在这里对一些电力系统专业术语作如下解释 一次图 电气主接线是由高压电器通过连接线 按其功能要求组成接受和分配电能的电路 成为传输强电流 高电压的网络 故又称为一次接线 那么用规定的设备文字和图形符号并按工作顺序排列 详细地表示电气设备或成套装置的全部基本组成和连接关系的单线接线图 成为主接线电路图 这里简称为一次图 二次图 在电力系统中 凡监视 控制 测量以及起保护作用的设备 如机电保护 控制和信号装 置等 皆属于二次设备 二次接线就是由二次设备构成的回路 这里我们就把二次设备接线图简称为二次图 分厂 发电厂通常由多个分厂组成 其中电气分厂 汽机分厂和锅炉分厂是发电厂的几个重要的分厂 电气设备 为满足生产的需要 发电厂中安装有各种设备 通常把生产和分配电能的设备称为一次设备 具体包括如下几种 生产和转换电能的设备 接通或断开电路的开关电器 限制故障电流和防御过电压的电气 接地装置 载流导体 此外还有一些对一次设备进行测量 控制 监视和保护用的二次设备 如 仪用互感器 机电保护及自动装置 直流电源设备等 在本书中提到的刀闸 开关等设备就属于电气设备 五妨 规则 电力系统的倒闸操作具有前后顺序和严格的逻辑规则 五防 规则就是根据电气运行人员多年的运行经验 总结出来的倒闸操作规则 如下 1 防止误分合断路器 防止带地线合刀闸2 防止带负荷拉合隔离开关 3 防止带电挂接地线或接地刀闸 4 防止带接地线或合接地刀闸送电 5 防止误入带电间隔 1 8 2系统运行环境客户端平台 windows98 2000 windowsNTworkstation Linux等所有具有支持JAVA的浏览器系统 服务器端平台 windows2000server windowsNTServer Linux UNIX等所有支持JAVABean的系统平台 数据库服务器 Oracle数据库或SQLServer2000数据库或ACCESS数据库 Web服务器 Tomcat5 0 1 8 3系统总体结构两票系统主要由两部分构成 即 操作票子系统和工作票子系统 整个系统的总体结构如图1 16所示 1 8 4系统功能 略 图1 16两票系统总体结构图 本章小结本章介绍了软件测试发展的历程 以及其在国内的发展状况 随着软件开发过程和开发技术的不断改进 软件测试理论和方法也在不断完善 测试工具也在蓬勃发展 通过本章的论述 可以了解到软件测试已经不再只是进行简单的程序逻辑检查 而是一个伴随着整个软件开发过程的活动 测试对象也不仅仅是程序代码 而开发过程中产生的所有软件产品 甚至是产品使用说明也包括在内 测试过程中为了更好的保证软件测试的质量 首先要遵循一定的测试原则 最为重要的就是应该尽早的进行测试 其次 正确处理开发与测试之间的关系 更好的把开发与测试过程集成到一起 从而提高测试效率 节约测试成本 本章所介绍的几种软件开发与测试模型 如 V模型 W模型和H模型 三种模型在不同程度上反映了软件开发与软件测试的关系 其中 V模型非常明确地标明了测试过程中存在的不同级别 并且清楚地描述了测试和开发过程中各阶段的对应关系 而W模型作为V模型的改进 更好地体现了软件开发与软件测试工作的同步性 更为明确地指出测试的对象不仅仅是程序本身 而且包括需求分析 概要设计和详细设计说明书 强调了软件测试是软件开发过程中的一项重要的工作 贯穿于整个软件开发过程 H模型则从微观的角度来看待软件测试过程 最后一个做好测试工作的关键因素就是精心的组织和安排软件测试的工作流程 本章把测试工作分为几个阶段 分别阐述了通用的测试工作流程 但要求读者在工作中 根据每个项目的具体情况制定可行的测试流程 各种测试技术是软件测试工作的敲门砖 本章从不同的角度介绍了软件测试技术的分类 从是否需要执行被测软件的角度 可分为静态测试 StaticTesting 和动态测试 DynamicTesting 从测试用例设计的角度 可分为黑盒测试和白盒测试 按照软件测试过程和测试策略 可分为单元测试 集成测试和系统测试 另外 本章还专门介绍了目前在实际工作中对软件测试的错误认识 希望读者能够明确软件测试的目的 正确的认识软件测试工作的必要性和重要性 习题名词解释 软件测试错误缺陷失效测试用例回归测试静态测试动态测试黑盒测试白盒测试单元测试集成测试系统测试简述软件测试发展的过程 从不同角度描述软件测试的现状 测试的生命周期可以分为几个阶段 简单描述各阶段需要完成的任务 什么是V模型 简述V模型在软件测试过程中的作用 以及在V模型中各个测试阶段和开发过程的对应关系 请概括一下静态测试和动态测试 以及黑盒测试与白盒测试的不同点 分别描述一下 需求阶段 设计 编码阶段 集成系统验收测试的软件测试流程 列举软件测试的目的 列举软件测试的十项原则 列举软件测试的误区 第二章软件测试基础 本章要点 软件测试基础知识 白盒测试和黑盒测试的定义 常见的白盒和黑盒测试设计技术 白盒测试与黑盒测试的区别 测试计划和测试报告的编制 测试用例的定义和编制方法 本章目标 掌握有关测试的一些数学知识 包括集合 函数和图论基础等 理解并掌握白盒测试和黑盒测试 以及二者的优缺点和各自的应用范围 能够熟练使用几种常见测试用例设计技术 了解测试计划和测试文档的作用 以及应该包含的内容和制定方法 了解测试报告的基本内容 以及测试用例的基本内容和编制方法 2 1用于测试的离散数学和图论基础一般而言 在功能性测试中 通常要用到离散数学知识 而在结构性测试领域中 则要用到一些关于图论的知识 2 1 1集合论集合论可分为 自然和不言自明两种 自然的集合论把集合看作是基本术语 我们把集合看作一个单位 或一个整体引用多个事物 集合的表示法有以下两种 1 将集合所有元素一一列出的表示法叫做 枚举法 但有时也可以只列出一部分元素 2 用一个集合所具有的共同性质来刻画这个集合 2 1 2函数简而言之 函数是将唯一的输出值赋予每一输入的 法则 2 1 3关系通俗的讲 关系就是客观世界一定范围的对象之间的某种特定联系 集合之间的关系定义 给定两个集合A和B 关系R是笛卡儿积A B的一个子集 如果希望描述整个关系 则通常只写R A B 对于特定元素ai A bi B 我们记做aiRbi 关系的表示关系表示事物之间的某种联系 二元关系表示两个事物之间的关系 如果把这两个事物分别放在一边 如果某两个元素有关系 那么就在它们之间画一条有向线 用这种方式表示关系 称作关系图 这里我们必须对 势 进行解释 势在用于集合时 是指集合中的元素的个数 定义 给定两个集合A和B 一个关系R A B 关系R的势是 1 一对一势2 多对一势3 一对多势4 多对多势单个集合上的关系首先 我们对关系进行定义 设A是一个集合 R A A是定义在A上的一个关系 R 关系具有四个特殊属性 定义 关系R A A是 1 自反的2 对称的 3 反对称的4 传递的2 1 4命题逻辑凡是能分辨其真假的语句都叫做命题 我们通常采用小写字母p q和r表示命题 命题逻辑有着和集合论相似的操作 表达式和标识 命题的真值只有两种 T代表真 而F代表假 命题公式的分类 如果命题公式A在任意的真值赋值函数t U 0 1 下的真值t A 都为1 则称命题公式A为永真式 tautology 或称重言式 如果命题A在任意的真值赋值函数下的真值都为0 则称A为矛盾式 contradiction 如果A不是矛盾式 则称为可满足式 2 1 5概率论概率是随机事件发生的可能性的数量指标 在独立随机事件中 如果某一事件在全部事件中出现的频率 在更大的范围内比较明显的稳定在某一固定常数附近 就可以认为这个事件发生的概率为这个常数 对于任何事件的概率值一定介于0和1之间 2 1 6用于测试的图测试中使用两种基本图 无向图和有向图 这里我们给出一些概念 图 又叫做线性图 是一种由两种集合定义的抽象数据结构 即一个节点集合和一个构成节点之间连接的集合 图中节点的度是以该节点作为端点的边的条数 在本节中将介绍的三种图 程序图 有限状态机 状态图 1 程序图 经过改进的程序图定义 节点要么是整个语句 要么是语句的一部分 边表示控制流 从节点i到节点j有一条边 当且仅当对应节点j的语句或语句的一部分 可以立即在节点i对应的语句或语句的一部分之后执行 程序的有向图公式化能够非常准确地描述程序的测试方面的问题 基本结构化程序设计的构造 例如 串行 选择和循环等可以用如图2 1所示的有向图表示 图2 1结构化程序设计构造的有向图 2 有限状态机有限状态机已经成为需求规格说明的一种相当标准的表示方法 有限状态机是一种有向图 其中状态是节点 转移是边 图2 2是一个简单的自动柜员机 SATM 系统 该图描述了用于个人标识编号PIN尝试部分的有限状态机 这种机器包含5个状态 空闲 等待第一次PIN尝试等等 和8个用边表示的转移 转移上的标签所遵循的规则是 分子 是引起转移的事件 分母 是与该转移关联的行为 图2 2用于PIN尝试的有限状态机 3 状态图状态图现在被Rational公司选为统一建模语言 即UML的控制模型 图2 3状态图的团点Harel使用与方法无关的术语 团点 表示状态图的基本构建块 在图2 3中 团点A包含两个团点B和C 通过边连接 团点A通过边与团点D连接 根据Harel的意图 我们可以把团点解释为状态 把边解释为转移 在图2 4中 状态A是初始状态 当进入到这个状态时 也进入低层状态B 当进入某个状态时 我们可以认为该状态是活动的 这可与Petri网中的被标记地点类比 状态图工具采用色彩表示哪个状态活动的 并等效于Petri网中的标记地点 图2 4中有一些微妙的地方 从状态A转移到状态D初看起来是有歧义的 因为它没有区分状态B和C 约定是 边必须开始和结束于状态的周围 如果状态包含子状态 就像图中的A一样 边会 引用 所有的子状态 因此 从A到D的边意味着转移可以从状态B或从状态C发生 如果有从状态D到状态A的边 如图2 5所示 则用B来表示初始状态这个事实 意味着转移实际上是从状态D到状态B 这种约定可以大大减缓有限状态机向 空心代码 发展的趋势 图2 4状态图中的初始状态 图2 5进入自状态的默认入口 我们最后要讨论的一个状态图的特性就是并发状态图概念 图2 6中状态D的虚线用于表示状态D实际上引用两个并发状态E和F 图2 6并发状态 2 2白盒测试白盒测试是一种可视的测试软件的方法 即它把测试对象看作一个透明的盒子 测试人员要了解程序结构和处理过程 按照程序内部逻辑测试程序 检查程序中的每条通路是否按照预定要求正确工作 白盒测试的过程如图2 7所示 图2 7白盒测试过程示意图 那么 在对被测软件进行白盒测试时 主要对程序进行哪些方面的检查呢 有如下几点 保证一个模块中的所有独立执行路径至少测试一次 对所有逻辑判定取值 true 和 false 的两种情况都至少测试一次 在循环边界和运行界限内执行循环体 测试内部数据结构的有效性 在软件测试领域 有六种基本的测试类型 单元测试 集成测试 功能测试 系统测试 可接受性测试 回归测试和Beta测试 白盒测试可以用在其中的三种测试类型中 1 单元测试 2 集成测试3 回归测试2 2 1白盒测试与调试的异同白盒测试和调试有哪些不同点呢 1 从承担的任务来看 白盒测试同其他类型测试一样 它的任务是发现所开发的项目中的缺陷 但是 调试不属于测试 其任务是纠正软件中的缺陷 2 从最终的结果来看 白盒测试有预知的结果 不可预知的只是程序是否通过测试 并且成功测试的结果是发现错误的症状 从而引起调试的进行 而调试的结果是消除项目中的错误 3 从执行的过程来看 测试是一个发现错误 改正错误 重新测试的过程 而调试是一个推理过程 4 从准备工作来看 测试从已知的条件开始 使用预先定义的程序 调试一般是以不可知的内部条件开始 做统一性调试 5 从执行的计划性来看 测试是有计划的并要进行测试设计 而调试则不受时间约束 6 从执行的人员来看 测试经常是由独立的测试组在不了解软件设计的条件下完成的 而调试必须由程序员来完成 7 从所使用的工具来看 大多数白盒测试的执行和设计可有工具支持 而调试程序员能利用的工具主要是调试器 2 2 2白盒测试的用例设计白盒测试用例设计技术就是研究如何用最少的测试用例最大限度地发现软件中的错误 目前主要有基本路径测试 等价类划分 边界值分析测试 覆盖测试 循环测试 数据流测试 程序插桩测试 变异测试等等方法 下面主要对几种常见的方法加以介绍 一 基本路径测试二 等价类划分 边界值分析 Equivalencepartitioning boundaryvalueanalysis 三 控制流 覆盖测试 Control flow CoverageTesting 方法覆盖方法覆盖可用于衡量测试用例所覆盖的方法的百分比 语句覆盖 StatementCoverage 语句覆盖是一种衡量测试所覆盖的程序语句百分比的措施 通过测试应该达到100 程序语句覆盖的目标 可以标识圈数 然后执行最少的一组测试用例就可以达到语句覆盖的目标 判断 分支覆盖判断 分支覆盖是为了衡量在测试过程中覆盖了多少个程序中的布尔表达式 图2 11各种循环图 四 循环测试是一种白盒测试技术 注重于循环构造的有效性 n循环结构测试用例的设计循环可以划分为以下几种模式 如图2 11 可以使用如下方法设计循环测试用例 一 简单循环 二 嵌套循环 三 串接循环 四 无结构循环 五 数据流测试 六 程序插装 程序插装 ProgramInstrumentation 是指在程序中设置断点或打印语句 在执行过程中了解程序的一些动态特性 七 变异测试变异测试 MutationTesting 的提出始于70年代末期 是一种错误驱动测试 即针对某类特定程序错误而进行的测试 也是一种比较成熟的排错性测试方法 排错性测试方法的基本思想是通过检验测试数据集的排错能力来判断软件测试的充分性 2 2 3白盒测试举例 略 2 3黑盒测试黑盒测试也称作功能测试和行为测试 主要是根据功能需求来测试程序是否按照预期工作 黑盒测试的目的是尽量发现代码所表现的外部行为的错误 主要有以下几类 功能不正确或不完整 接口错误 接口所使用的数据结构错误 行为或性能错误 初始化和终止错误 黑盒测试的示意图如图2 14所示 从图2 14中 我们可以看出黑盒测试只考虑程序的输入和输出 无须考虑程序的内部代码 图2 14黑盒测试示意图 2 3 1黑盒测试和白盒测试的异同本书归纳出以下几点 执行测试人员不同黑盒测试通常由用户以及非开发人员来进行 而白盒测试通常要有了解软件内部结构的开发人员来做 测试覆盖目标不同如果我们用一个盒子来代替整个软件系统 那么黑盒测试可以看成是一种系统测试 而对盒子内部的多个单元的测试就可以称作为白盒测试 另外一种区别就是 二者的覆盖目标不同 黑盒测试的目标是覆盖所有的用户需求 而白盒测试的目标是覆盖所有的代码 3 测试动机不同有效的安全测试有时也需要详细了解代码以及系统结构 此时把这些技术称作白盒测试 另外一种风险测试的目标可能就只是测试软件是否能够为用户提供预期输出 可用性测试就是如此 所以被称作黑盒测试 4 测试方法不同一个最普通的区别就是行为测试设计是基于功能需求来定义测试 而结构测试则是基于代码本身来定义测试的 这就是两种设计测试的方法 因为行为测试是基于外部功能定义的 所以称作黑盒测试 结构测试则是基于代码内部结构来定义的 所以称作白盒测试 5 评估测试方法不同一些技术是使用代码工具来跟踪软件内部的工作过程 因此称为白盒测试技术 与之相比 黑盒测试技术只是简单的观察程序的正常输出 2 3 2黑盒测试的用例设计常用的黑盒测试用例设计方法主要有以下几种 功能图分析方法 等价类划分方法 边界值分析方法 错误推测方法 因果图方法 判定表驱动分析方法 正交实验设计方法和功能图分析方法等 下面对上述方法分别作以简要介绍 一 基于用户需求的测试黑盒测试用例就是基于用户需求的 也是从研究客户需求工作开始的 二 对等区间划分对等区间划分是一种黑盒测试方法 该方法也称为等价类划分 是一种设计测试用例的非常形式化的方法 三 边界值分析法边界值分析方法是对等价类划分方法的补充 长期的测试工作经验告诉我们 大量的错误是发生在输入或输出范围的边界上 而不是发生在输入输出范围的内部 四 状态转换测试状态转换测试适用于软件被设计成一个状态机或实现了一种被建模成一种状态机的情况 可以设计测试用例测试状态间转换 测试用例创建引起转换的事件 可以设计负面测试的测试用例用于测试状态与事件的非法组合 五 分支测试在分支测试中 测试用例用于测试单元的控制流分支或决策点 通常用于实现决策覆盖 DecisionCoverage 的测试目标 六 错误推测法错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误 借助边界值分析等方法有针对性的设计测试用例的方法 七 因果图方法因果图方法适合于检查程序输入条件的各种组合情况 使用该方法首先要理解软件所表示的对象及其关系 然后 定义一组保证 所有对象与其他对象都具有所期望的关系 的测试序列 2 3 3黑盒测试举例 略 2 4白盒测试和黑盒测试的比较1 白盒测试只关注软件产品的测试 不能够确保产品已经实现了规格说明中的所有功能 黑盒测试则只关注规格说明中的功能测试 不能够保证已经实现的各个部分都被测试到 2 与黑盒测试相比 白盒测试的成本要高一些 3 黑盒测试故意不考虑控制结构 而只注意信息域 白盒测试只考虑测试软件产品 它不保证完整的需求规格是否被满足 黑盒测试是一种确认技术 回答 我们在构造一个正确的系统吗 白盒测试是一种验证技术 回答 我们在正确地构造一个系统吗 总之 建议测试人员在进行测试的过程中 可以考虑先使用黑盒测试 然后统计相应的覆盖率 再设计适当的白盒测试用例作为补充以保证测试的完整性 2 4 1白盒测试的优缺点1 优点 可构成测试数据对特定程序部分测试 可以检测代码中的每条分支和路径 揭示隐藏在代码中的错误 对代码的测试比较彻底 有较多工具支持 有一定的充分性度量手段 2 缺点工作量大 成本高 通常只用于单元测试 有应用局限 无法检测代码中遗漏的路径和数据敏感性错误 不能验证规格说明的正确性 无法对规格说明中未实现的部分进行测试 不易生成测试数据 通常 2 4 2黑盒测试的优缺点优点对于较大的代码单元来说 效率高 测试人员不需要了解实现的细节 包括具体的编程语言 测试员和程序员可以由不同的人员来担任 从用户的角度进行测试 容易被理解和接受 有助于暴露任何规格不一致或有歧义的问题 测试用例的设计可以在规格说明完成之后马上进行 容易入手生成测试数据 适用于各阶段测试 缺点实际上 只有一小部分可能的输入被测试到 某些代码得不到测试 如果没有清晰 简洁的规格说明 难以设计测试用例 如果测试人员不知道开发人员已经执行过该测试用例 会存在不必要的重复测试 会有很多程序路径没有被测试到 不能直接针对可能隐蔽了许多问题的特定程序段进行测试 如果规格说明有误 则无法发现 不易进行充分性测试 2 4 3灰盒测试灰盒测试介于白盒测试和黑盒测试之间 是现代测试的一种理念 就是指 在白盒测试中交叉使用黑盒测试的方法 在黑盒测试中交叉使用白盒测试的方法 2 5测试方法的选择一 单元测试测试方法 白盒测试参考规范 详细设计说明和代码结构二 集成测试测试方法 黑盒和白盒测试参考规范 详细设计说明和概要设计说明 2 6测试计划与测试文档最常见的测试文档包括测试计划 测试规范 测试用例和测试时发现缺陷后要写的 缺陷报告 等 那么 测试计划和测试文档在测试过程中能够发挥什么样的作用呢 1 测试文档有助于测试任务的完成 2 使用测试文档可以更好的协调测试任务与测试过程 3 测试文档为测试项目的组织 规划与管理提供了一个架构 2 6 1测试计划的制定为了给读者一个宏观的认识 首先请看测试计划活动图 如图2 20所示 在制定测试计划过程中 核心活动就是 一 确定测试策略通常 可以采用以下几个方法来制定测试策略 1 确定测试的范围2 确定测试的方法3 确定测试标准和质量检查点4 确定自动化测试策略二 确定测试系统 硬件和软件 1 测试架构测试架构指的就是测试用例的组织结构 图2 20测试计划活动 2 测试工具3 测试环境测试环境的组成包括物理测试设施 产品运行的操作系统 产品运行的计算平台等 4 测试配置情况需要排列配置的优先级 然后决定哪些配置需要全面测试 哪些可以进行部分测试 三 预估测试工作量 资源和时间进度计划 对项目进行预估有5个准备步骤 1 确定要完成的任务 2 确定每项任务所需的工作量和整个测试生命周期的工作量 3 确定完成每项任务以及整个测试生命周期所需的时间 4 为测试工作建立详细的时间进度计划和里程碑表 5 评估时间进度风险并准备缓解风险计划 四 准备并复查测试计划文档 1 测试计划格式2 测试计划复查2 6 2测试报告测试报告是测试阶段最后的文档产出物 优秀的测试经理应该具备良好的文档编写能力 一 份详细的测试报告包含足够的信息 包括产品质量和测试过程的评价 测试报告基于测试中的数据采集以及对最终测试结果的分析 2 6 3测试用例的编制本节我们首先讨论几个和测试用例相关的几个问题 然后探讨如何编制一个有效的测试用例 一 为什么做测试用例主要原因有如下几点 完全测试是不可能的 输入量太大 输出结果太多 软件实现途径太多 软件说明书没有客观标准 从不同角度看 软件缺陷的标准不同 二 什么是测试用例 比较通常的说法是 为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据 称之为测试用例 三 使用测试用例的好处 在开始实施测试之前设计好测试用例 可以避免盲目测试并提高测试效率 测试用例的使用令软件测试的实施重点突出 目的明确 在软件版本更新后只需修正少部分的测试用例便可展开测试工作 降低工作强度 缩短项目周期 功能模块的通用化和复用化使软件易于开发 而 用于功能模块测试的测试用例的通用化和复用化则会使软件测试易于开展 并随着测试用例的不断精化其效率也不断攀升 四 测试用例在软件测试中的作用 指导测试的实施 规划测试数据的准备 评估测试结果的度量基准 分析缺陷的标准 编写测试脚本的 设计规格说明书 五 测试用例文档的编制首先 在编写测试用例之前需要准备以下几个编写的依据 需求说明以及相关文档 相关的设计说明 概要设计 详细设计等 与开发组交流对需求理解的记录 可以是开发人员的一个解释 已经基本成型的UI 可以有针对性地补充一些用例 其次 编写测试用例文档应有文档模板 须符合内部的规范要求 最后一点就是 测试用例文档应该由简介和测试用例两部分组成 那么 下面从测试用例的设置 设计 评审 修改以及管理等几方面来详细讨论测试用例文档的编制问题 1 测试用例的设置2 测试用例的设计测试用例可以分为基本事件 备选事件和异常事件 软件测试常用的设计测试用例的基本方法有 等价类划分法 边界值分析法 错误推测法 因果图法 逻辑覆盖法等 视软件的不同性质采用不同的方法 如何灵活运用各种基本方法来设计完整的测试用例 并最终实现暴露隐藏的缺陷 则要凭测试设计人员的丰富经验和精心设计 3 测试用例的评审 4 测试用例的修改更新5 测试用例的管理测试管理软件的主要功能有三个 能将测试用例文档的关键内容 可供测试实施时及时输入测试情况 最终实现自动生成测试结果文档 本章小结在功能性测试中 我们通常使用离散数学 而涉及到结构性测试的领域 我们则会用到关于图论的知识 使用这两方面的知识 有助于我们更精确的描述软件测试 减少对测试过程的误解 白盒测试与黑盒测试则是软件测试工作中设计测试用例的两个主要的方法 在实际测试过程中 如果黑盒测试是足够充分的 那么白盒测试就没有必要 但是 足够充分 只是一种理想状态 例如 真的是所有功能点都测试了吗 程序的功能点是人为的定义 常常是不全面的 各个输入数据之间 有些组合可能会产生问题 怎样保证这些组合都经过了测试 难于衡量测试的完整性是黑盒测试的主要缺陷 而白盒测试恰恰具有易于衡量测试完整性的优点 两者之间具有极好的互补性 白盒测试主要是针对程序的逻辑结构设计测试用例 用逻辑覆盖率来衡量测试的完整性 逻辑单位主要有 语句 分支 条件 条件值 条件值组合 路径 语句覆盖就是覆盖所有的语句 其他类推 另外还有一种判定条件覆盖 其实是分支覆盖与条件覆盖的组合 在此不作讨论 跟条件有关的覆盖就有三种 条件覆盖是指覆盖所有的条件表达 即所有的条件表达式都计算了 不考虑计算结果 条件值覆盖是指覆盖条件的所有可能取值 即每个条件的取真值和取假值都要计算一次 条件值组合覆盖是指覆盖所有条件取值的所有可能组合 效率比较高且完整性也足够的测试要求一般是这样的 完成功能测试 完成语句覆盖 条件覆盖 分支覆盖 路径覆盖 读者可能认为这似乎是不可能的要求 要达到这种测试完整性 其测试成本是不可想象的 但是通过使用一些工具 可以在较低的成本下达到这种测试要求 精心的测试计划是做好软件测试的关键步骤 因此应该根据需求的变更随时修改测试计划 全面地测试文档 能够为测试工作提供更好的支持 因此在测试的过程中应该给测试计划的制定和测试文档的编写工作以足够的重视 习题请列出下列集合的所有元素 1 大于4并小于28的所有素数的集合 2 大于38并小于70的所有素数的集合 调试会遇到哪些困难 白盒测试与调试有哪些相同点和不同点 请阐述白盒测试用例设计的各种方法 请阐述黑盒测试用例设计的各种方法 比较白盒测试与黑盒测试各自的优缺点 制定测试计划的主要步骤有哪些 如何确定测试范围 为什么要提交测试报告 编写测试用例的依据有哪些 第三章单元测试 本章要点 单元测试的定义 单元测试同集成测试和系统测试的区别 单元测试环境的组成 单元测试的分析方法 单元测试的用例设计方法 单元测试的过程 单元测试举例 本章目标 掌握单元测试的概念 了解单元测试的误区 了解单元测试与集成测试和系统测试的区别 掌握单元测试的策略 掌握单元测试分析的方法 掌握单元测试用例设计方法 3 1单元测试概述通常而言 单元测试是在软件开发过程中要进行的最低级别的测试活动 或者说是针对软件设计的最小单位 程序模块 进行正确性检验的测试工作 其目的在于发现每个程序模块内部可能存在的差错 在单元测试活动中 软件的独立单元将在与程序的其他部分相隔离的情况下进行测试 主要工作分为两个步骤 人工静态检查和动态执行跟踪 单元测试的分工大致如下 一般由开发组在一般由开发组在开发组组长监督下进行 保证使 用合适的测试技术 根据单元测试计划和测试说明文档中制定的要求 执行充分的测试 由编写该单元的开发组中的成员设计所需要的测试用例 测试该单元并修改缺陷 3 1 1单元测试误区1 单元测试是一种浪费时间的工作2 单元测试只能证明代码做了什么3 我是个很棒的程序员 我是不是可以不进行单元测试 4 集成测试能捕捉到所有的Bug5 单元测试的成本效率不高 其实 在经过了单元测试之后 系统集成过程将会大大地简化 3 1 2单元测试与集成测试区别单元测试与集成测试的主要区别在于测试的对象不同 单元测试对象是实现具体功能的单元 一般对应详细设计中所描述的设计单元 集成测试是针对概要设计所包含的模块以及模块组合进行的测试 单元测试所使用的主要测试方法是基于代码的白盒测试 而集成测试所使用的主要测试方法是基于功能的黑盒测试 因为集成测试要在所有要集成的模块都通过了单元测试之后才能进行 也就是说在测试时间上 集成测试要晚于单元测试 所以单元测试的好坏直接影响着集成测试 单元测试的工作内容包括模块内程序的逻辑 功能 参数传递 变量引用 出错处理 需求和设计中有具体的要求等方面测试 集成测试的工作内容主要是验证各个接口 接口之间的数据传递关系 模块组合后能否达到预期效果 虽然单元测试和集成测试有一些区别 但是二者之间也有着千丝万缕的联系 目前集成测试和单元测试的界限趋向模糊 3 1 3单元测试与系统测试区别单元测试与系统测试的区别不仅仅在于测试的对象和测试的层次的不同 最重要的区别是测试性质不同 在单元测试过程中 单元测试的执行早于系统测试 测试的是软件单元的具体实现 内部逻辑结构以及数据流向等 系统测试属于后期测试 主要是根据需求规格说明书进行的 是从用户角度来进行的功能测试和性能测试等等 证明系统是否满足用户的需求 单元测试中发现的错误容易进行定位 并且多个单元测试可以并行进行 而系统测试发现的错误比较难定位 3 2单元测试环境由于一个模块或一个方法 Method 并不是一个独立的程序 在考虑测试它时要同时考虑它和外界的联系 因此要用到一些辅助模块 来模拟与所测模块相联系的其他模块 一般把这些辅助模块分为两种 1 驱动模块 driver 相当于所测模块的主程序 2 桩模块 stub 用于代替所测模块调用的子模块 那么 所测模块和与它相关的驱动模块及桩模块共同构成了一个 测试环境 如图3 2所示 图3 2单元测试环境 3 3单元测试策略单元测试涉及到的测试技术通常有 针对被测单元需求的功能测试 用于代码评审和代码走读的静态测试 白盒测试 状态转换测试和非功能测试 为了提高单元测试的质量 只了解这些单元测试技术还远远不够 还要选择合适的测试策略 在选择测试策略时 主要考虑如下3种方式 自顶向下 TopDownUnitTesting 的单元测试策略 自底向上的单元测试策略 BottomupUnitTesting 和孤立的单元测试策略 3 3 1自顶向下的单元测试策略一 步骤 1 从最顶层开始 把顶层调用的单元做成桩模块 2 对第二层测试 使用上面已测试的单元做驱动模块 3 依次类推 直到全部单元测试结束 二 优点 可以在集成测试之前为系统提供早期的集成途径 三 缺点 单元测试被桩模块控制 随着单元测试的不断进行 测试过程也会变得越来越复杂 测试难度以及开发和维护的成本都不断增加 要求的低层次的结构覆盖率也难以得到保证 由于需求变更或其他原因而必须更改任何一个单元时 就必须重新测试该单元下层调用的所有单元 低层单元测试依赖顶层测试 无法进行并行测试 使测试进度受到不同程度的影响 延长测试周期 四 总结 从上述分析中 不难看出该测试策略