软件测试技术604页PPT.ppt_第1页
软件测试技术604页PPT.ppt_第2页
软件测试技术604页PPT.ppt_第3页
软件测试技术604页PPT.ppt_第4页
软件测试技术604页PPT.ppt_第5页
已阅读5页,还剩599页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试技术 第1章软件工程与软件测试 1 1软件工程1 2软件质量1 3软件测试1 4软件测试人员的基本素质 严格地说 软件工程是应用计算机科学 数学及管理科学等原理开发软件的工程 通俗地说 软件工程是实现一个大型程序的一套原则方法 即按工程化的原则和方法组织软件开发工作 软件测试是软件工程的一个重要环节 相当于工程领域中的质量检验部分 是确保软件工程质量的重要手段 1 1软件工程 1 1 1软件工程的目标及其一般开发过程一个软件产品从形成概念开始 经过开发 使用和维护 直到最后退出使用的全过程称为软件生存周期 软件生存周期根据软件所处的状态 以及软件开发活动的目的和任务 可划分为若干个阶段 一般软件生存周期包括软件定义 软件开发以及软件使用与维护3个部分 1 软件定义可行性分析的任务是了解用户的要求及实现环境 从技术 经济和社会等几个方面研究并论证软件系统的可行性 需求分析的任务是确定所要开发软件的功能需求 性能需求和运行环境约束 编制软件需求规格说明 软件系统的确认测试准则 软件的性能需求包括软件的适应性 安全性 可靠性 可维护性错误处理等 2 软件开发软件开发是按照需求规格说明的要求 由抽象到具体 逐步生成软件的过程 软件开发一般由设计 实现和测试等阶段组成 3 软件使用和维护软件的使用是在软件通过测试后 将软件安装在用户确定的运行环境中移交给用户使用 软件的维护是对软件系统进行修改或对软件需求变化做出反应的过程 1 1 2软件过程模型软件开发过程中存在各种复杂因素 为了解决由此而带来的种种问题 软件开发者们经过多年的摸索 给出了多种实现软件工程的方式 软件过程模型 如瀑布过程模型 螺旋过程模型和增量过程模型等 1 瀑布过程模型瀑布过程模型反映了人们早期对软件工程的认识水平 是人们所熟悉的一种线性思维的体现 瀑布过程模型强调阶段的划分及其顺序性 各阶段工作及其文档的完备性 是一种严格线性的 按阶段顺序的 逐步细化的开发模式 如图1 1所示 图1 1瀑布过程模型 2 螺旋过程模型螺旋过程模型的基本思路是 依据前一个版本的结果构造新的版本 这个不断重复迭代的过程形成了一个螺旋上升的路径 如图1 2所示 图1 2螺旋过程模型 3 增量过程模型有些时候可能会用一种几乎连续的过程小幅度地推进项目 这就是增量过程模型 如图1 3所示 图1 3增量过程模型 1 2软件质量 软件质量是软件的生命 它直接影响软件的使用与维护 通常软件质量由以下几方面进行评价 软件需求是衡量软件质量的基础 不符合需求的软件就不具备质量 设计的软件应在功能 性能等方面都符合要求 并能可靠地运行 软件结构良好 易读 易于理解 并易于修改 维护 软件系统具有友好的用户界面 便于用户使用 软件生存周期中各阶段文档齐全 规范 便于配置 管理 1 2 1质量与质量模型软件的质量因素很多 如正确性 精确性 可靠性 容错性 性能 效率 易用性 可理解性 简洁性 可复用性 可扩充性 兼容性等 软件质量因素也称为软件质量特性 反映了质量的本质 讨论一个软件的质量 问题最终要归结到定义软件的质量特性 面对众多的质量因素如何取折衷 这实际上就是区分质量因素对软件质量影响程度轻重的问题 这个问题已经有了解决方案 即软件质量模型 图1 4所示为ISO IEC9126 1991标准规定的软件质量度量模型 它由3层组成 其中第1层称为质量特性 第2层称为质量子特性 第3层称为度量 图1 4ISO软件质量度量模型 软件质量评价的目的是为了直接支持开发并获得能满足用户要求的软件 最终目标是保证产品能提供所要求的质量 即满足用户明确的和隐含的要求 软件产品的一般评价过程是 确定评价需求 然后规定 设计和执行评价 如图1 5所示 图1 5软件评价过程 1 2 2软件质量保证为了在软件开发过程中保证软件的质量 软件的质量保证活动应贯穿整个软件生存周期的每一个阶段 软件的质量保证的措施主要有检查 评审和测试 如图1 6所示 软件质量保证的工作从项目一开始就应介入 图1 6质量保证活动 1 3软件测试 1 3 1软件测试的定义及目的简单地说 软件测试就是为了发现错误而执行程序的过程 在IEEE提出的软件工程标准术语中 软件测试被定义为 使用人工和自动手段来运行或测试某个系统的过程 其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别 软件测试是与软件质量密切联系在一起的 归根结底 软件测试是为了保证软件质量 软件测试是一个找错的过程 软件测试的过程亦是程序运行的过程 程序运行需要数据 为测试设计的数据称为测试用例 测试用例的设计原则是尽可能暴露程序中的错误 软件是由人来完成的 所有由人做的工作都不会是完美无缺的 软件开发是个很复杂的过程 期间很容易产生错误 无论是软件从业人员 专家和学者做了多大的努力 软件错误仍然存在 因而大家也得到了一种共识 软件中残存着错误 这是软件的一种属性 是无法改变的 所以通常说软件测试的目的就是为了发现尽可能多的缺陷 并期望通过改错来把缺陷统统消灭 以期提高软件的质量 一个成功的测试用例在于发现了至今尚未发现的缺陷 软件测试的目的是以最少的人力 物力和时间找出软件中潜在的各种错误和缺陷 通过修正各种错误和缺陷提高软件质量 回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险 1 3 2软件测试信息流为进一步说明软件测试的过程 这里给出软件测试的信息流示意图 如图1 8所示 图1 8软件测试信息流 1 3 3软件测试与软件开发过程的关系对于软件测试与软件开发过程之间的关系 套用固定的模型不是聪明之举 比如 程序设计 与 测试 之间的关系 习惯上总以为程序设计在先 测试在后 如图1 9 a 所示 而对于一些复杂的程序 将测试分为同步测试与总测试更有效 如图1 9 b 所示 图1 9程序设计与测试的关系 现在还有一种全新的软件开发模式 以测试驱动软件开发 总的思想是 软件测试是贯穿于软件开发过程的 软件生存周期的各个阶段中都少不了相应的测试 软件生存周期各个阶段的测试分别对应于软件测试过程中的单元测试 集成测试 系统测试和确认测试 如图1 10所示 这种对应关系有利于软件开发过程的管理和软件质量的控制 图1 10软件测试与软件开发的关系 1 3 4软件测试与质量保证的区别1 质量保证质量保证 QA 工作通过预防 检查与改进来保证软件质量 QA采用 全面质量管理 和 过程改进 的原理开展质量保证工作 2 软件测试测试虽然也与开发过程紧密相关 但关心的不是过程的活动 而是对过程的产物以及开发出的软件进行剖析 测试人员要 执行 软件 对过程中的产物 开发文档和源代码进行走查 运行软件 以找出问题 报告质量 测试人员必须假设软件存在潜在的问题 测试中所做的操作是为了找出更多的问题 而不仅仅是为了验证每一件事是正确的 对测试中发现的问题的分析 追踪与回归测试也是软件测试中的重要工作 因此软件测试是保证软件质量的一个重要环节 软件质量保证活动与软件测试的关系可用图1 11说明 图1 11软件质量保证活动与测试的关系 1 3 5软件测试的发展历程及趋势软件测试是伴随着软件的产生而产生的 有了软件的生成和运行就必然有软件测试 在早期的软件开发过程中 测试的含义比较窄 将测试等同于 调试 目的是纠正软件中已经知道的故障 常常由软件开发人员自己完成这部分工作 对测试的投入极少 测试介入得也晚 常常是等到形成代码 产品已经基本完成时才进行测试 直到1957年 软件测试才开始与调试区别开来 成为一种发现软件缺陷的活动 直到20世纪80年代早期 质量 的号角才开始吹响 软件测试的定义发生了改变 测试不单纯是一个发现错误的过程 而且包含软件质量评价的内容 软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题 制定了各类标准 包括IEEE标准 美国ANSI标准和ISO国际标准 20世纪90年代 测试工具终于盛行起来 到了2002年 Rich和Stefan在 系统的软件测试 一书中对软件测试做了进一步定义 测试是为了度量和提高被测软件的质量 对测试软件进行工程设计 实施和维护的整个生命周期过程 这些经典论著对软件测试研究的理论化和体系化产生了巨大的影响 近20年来 随着计算机和软件技术的飞速发展 软件测试技术的研究也取得了很大的突破 测试专家总结了很好的测试模型 如著名的V模型 在单元测试 自动化测试等方面涌现了大量优秀的软件测试工具 虽然软件测试技术的发展很快 但是其发展速度仍落后于软件开发技术的发展速度 使得软件测试在今天面临着很大的挑战 主要体现在以下几个方面 软件在国防现代化 社会信息化和国民经济信息化领域中的作用越来越重要 由此产生的测试任务越来越繁重 软件规模越来越大 功能越来越复杂 如何进行充分而有效的测试成为难题 面向对象的开发技术越来越普及 但是面向对象的测试技术却刚刚起步 对分布式系统的整体性能还不能进行很好的测试 对实时系统缺乏有效的测试手段 随着安全问题的日益突出 对信息系统的安全性如何进行有效的测试与评估 成为世界性难题 根据国内外软件测试的发展现状 可以看到软件测试有以下的发展趋势 测试工作将进一步前移 软件架构师 开发工程师 QA人员 测试工程师将进行更好的融合 测试职业将得到充分的尊重 设置独立的软件测试部门将成为越来越多的软件公司的共识 软件测试部门将和开发部 质量保证部一样作为一个重要的独立部门存在 测试外包服务将快速增长 和软件开发外包一样 软件测试外包将成为全球化的一种趋势 可以利用职业测试专家队伍与机构为自己的产品进行测试 而且可以节省测试费用 1 4软件测试人员的基本素质 软件测试人员应具备下列基本素质 1 具有良好的计算机编程基础2 具有创新精神和超前意识3 不懈努力 追求完美4 具有整体观念 对细节敏感5 团队合作精神 第2章软件测试的基本知识 2 1软件测试贯穿于整个的软件开发生命周期2 2测试模型2 3软件测试的分类2 4软件测试的原则2 5软件测试策略2 6软件测试流程2 7测试的成功经验 2 1软件测试贯穿于整个的软件开发生命周期 2 1 1软件测试中使用的各种术语 软件错误 软件缺陷 软件故障 软件失效 2 1 2软件测试贯穿于整个的软件开发生命周期20世纪70年代中期以来 形成了软件开发生命周期的概念 测试工作应该着眼于整个软件开发生命周期 特别是着眼于编码以前各开发阶段的工作来保证软件的质量 也就是说 测试应该从软件开发生命周期的第一个阶段开始 并贯穿于整个的软件开发生命周期 谈到测试 首先是为什么要进行测试的问题 所有的测试都是为了发现和消除软件的缺陷 明确为什么要进行软件测试的问题之后 就需要明确测试什么的问题 软件的开发有其自己的生命周期 在整个软件生命周期中 软件都有各自的相对于各生命周期的阶段性的输出结果 其中也包括需求分析 概要设计 详细设计及程序编码等各阶段所产生的文档 包括需求规格说明 概要设计规格说明 详细设计规格说明以及源程序 而所有这些输出结果都应成为被测试的对象 随着人们对软件工程化的重视以及软件规模的日益扩大 软件分析 设计的作用越来越突出 而且有资料表明 60 以上的软件错误并不是程序错误 而是分析和设计错误 因此 做好软件需求和设计阶段的测试工作就显得非常重要 这就是传统的测试概念的扩大化 从而提出了软件全生命周期测试的概念 测试过程包括了软件开发生命周期的每个阶段 在需求阶段 重点要确认需求定义是否符合用户的需要 在设计和编程阶段 重点要确定设计和编程是否符合需求定义 在测试和安装阶段 重点是审查系统执行是否符合系统规格说明 在维护阶段 要重新测试系统 以确定更改的部分和没有更改的部分是否都正常工作 2 1 3软件测试的手段1 验证和确认通常在测试中 使用验证来检查中间可交付的结果 使用确认来评估可执行代码的性能 一般来说 验证回答这样的问题 是否建立了正确的系统 而确认回答的问题是 建立的系统是否正确 所谓验证 是指如何决定软件开发的每个阶段 每个步骤的产品是否正确无误 并与其前面的开发阶段和开发步骤的产品相一致 验证工作意味着在软件开发过程中开展一系列活动 旨在确保软件能够正确无误地实现软件的需求 所谓确认 是指如何决定最后的软件产品是否正确无误 2 功能和结构测试当测试人员测试项目小组的解决方案时 将利用验证和确认技术完成功能和结构测试 功能测试通常也被称为黑盒测试 因为测试案例中都不涉及系统的内部逻辑 相反 结构测试通常被称为白盒测试 因为系统的内部逻辑常被用于假想的测试案例 结构测试主要使用验证技术 如上所述 测试人员用验证技术 通过评审系统的结构和逻辑来确认系统的合理性 而确认要严格应用于物理测试 来确定是否产生了预期的结果 执行结构测试将主要使用验证技术 而执行功能测试则主要使用确认技术 2 2测试模型 就像软件开发有过程模型一样 测试也有测试模型 描述以上测试过程的就是测试模型 最具有代表意义的测试模型称为V模型 V模型如图2 1所示 图2 1V模型示意图 在开发过程中 从需求阶段到编码阶段 主要是采用验证手段进行测试 如需求评审 设计评审 代码走查以及代码审查等 从而完成对开发的中间结果的正确性的评估 编码完成并经过代码审查等测试之后 此时的测试主要在软件的可执行模式下进行 即利用确认手段进行测试 确认测试包括单元测试 集成测试 系统测试以及用户验收测试等 其相应的关系如图2 2所示 图2 2V模型中的测试 2 3软件测试的分类 按照不同的分类方法 软件测试可分为以下几种类型 1 按照开发阶段划分按照开发阶段划分 软件测试可分为单元测试 集成测试 系统测试和验收测试 2 按照测试实施组织划分按照测试实施组织划分 软件测试可分为开发方测试 用户测试 测试 和第三方测试 3 按照测试技术划分按照测试技术划分 软件测试可分为白盒测试和黑盒测试 也可分为静态测试和动态测试 2 4软件测试的原则 软件测试的原则尚没有标准的说法 大多是经验之谈 一般有下面几条可作为测试的基本原则 1 所有的测试都应追溯到用户需求 2 应当把 尽早地和不断地进行软件测试 作为软件测试者的座右铭 3 设计时应完成测试计划 详细的测试用例定义可在设计模型确定后开始 测试可在代码产生之前进行计划和设计 4 pareto原则 测试发现的错误中80 很可能起源于20 的模块中 应孤立这些疑点模块 进行重点测试 5 完全测试是不可能的 测试需要终止 6 应由独立的第三方来构造测试 7 充分注意测试中的群集现象 8 要尽量避免测试的随意性 9 兼顾合理的输入和不合理的输入数据 10 程序修改后要回归测试 11 应长期保留测试用例 直至系统废弃 2 5软件测试策略 软件测试策略描述软件测试活动的总体方法和目标 为了检验开发的软件能否符合规格说明书的要求 测试活动可以采用各种不同的策略 这些策略的区别在于它们表明了不同的出发点 不同的思路以及采用不同的手段和方法 具体地说 包括要使用的测试技术和工具 测试完成标准 影响资源分配的特殊考虑等 通常 制定软件测试策略要考虑如下的内容 1 要使用的测试方法 2 确定质量风险 3 测试完成和测试成功所采用的评价标准 4 有关资源要求或涉及进度的特殊考虑 5 测试类型 评估标准以及测试方法 6 确定资源 在软件测试策略所包含的内容中最主要的部分有两个 一是要进行的测试过程 另外一个就是要执行的测试类型 1 测试过程共分为以下4个过程 单元测试 集成测试 系统测试 验收测试 2 测试类型对于测试类型的说法多种多样 最多的能有30多种测试类型 而实际工作中很多测试是互相包含的 按照企业中实际工作需要 测试主要包含下面的类型 功能测试 健壮性测试 接口测试 强度测试 压力测试 性能测试 用户界面测试 安全测试 可靠性测试 安装 反安装测试 11 文档测试12 恢复测试13 兼容性测试14 测试15 测试 2 6软件测试流程 软件测试工作必须要通过制定测试计划 设计测试 实施测试 执行测试 评估测试几个阶段来完成 其流程如图2 4所示 图2 4软件测试流程 2 6 1制定测试计划测试计划是对每个产品 或是对各个开发阶段的产品开展测试的策略 计划的目的是用来识别任务 分析风险 规划资源和确定进度 计划并不是一张时间进度表 而是一个动态的过程 最终以系列文档的形式确定下来 拟定软件测试计划需要测试项目管理人员的积极参与 这是因为主项目计划已经确定了整体项目的一个时间框架 软件测试作为阶段工作必须服从计划和资源上的约定 一般来说 一个完整的测试计划应该包含以下几个方面 1 对测试范围 即测试活动需要覆盖的范围 的界定 2 风险的确定 3 资源的规划 4 时间表的制定 2 6 2设计测试设计测试阶段要设计测试用例和测试过程 要保证测试用例完全覆盖测试需求 设计测试阶段最重要的是如何将测试需求分解 如何设计测试用例 1 如何对测试需求进行分解对测试需求进行分解需要反复检查并理解各种信息 和用户交流 理解他们的要求 可以按照以下步骤执行 1 确定软件提供的主要任务 2 对每个任务 确定完成该任务所要进行的工作 3 确定从数据库信息引出的计算结果 4 对于对时间有要求的交易 确定所要的时间和条件 5 确定会产生重大意外的压力测试 包括内存 硬盘空间 高的交易率 6 确定应用需要处理的数据量 7 确定需要的软件和硬件配置 8 确定其他与应用软件没有直接关系的商业交易 9 确定安装过程 10 确定没有隐含在功能测试中的用户界面要求 2 如何设计测试用例测试用例一般指对一项特定的软件产品进行测试任务的描述 体现测试方案 方法 技术和策略 值得提出的是 测试数据都是从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的 测试用例是软件测试系统化 工程化的产物 而测试用例的设计一直是软件测试工作的重点和难点 设计测试用例即设计针对特定功能或组合功能的测试方案 并编写成文档 测试用例应该体现软件工程的思想和原则 传统的测试用例文档编写有两种方式 一种是填写操作步骤列表 将在软件上进行的操作步骤一步一步详细记录下来 包括所有被操作的项目和相应的值 另一种是填写测试矩阵 将被操作项作为矩阵中的一个字段 而矩阵中的一条条记录 则是这些字段的值 评价测试用例的好坏有以下两个标准 是否可以发现尚未发现的软件缺陷 是否可以覆盖全部的测试需求 2 6 3实施测试实施测试是指准备测试环境 获得测试数据 开发测试规程 以及为该过程挑选和准备辅助测试工具的过程 1 准备测试环境 1 测试技术准备 2 配置软件 硬件环境 3 人员 2 获得测试数据需要测试的常见情形如下 1 正常事务的测试 2 使用无效数据的测试 创建测试数据时主要考虑如下步骤 识别测试资源 识别测试情形 排序测试情形 确定正确的处理结果 创建测试事务 确定实际的测试数据时 必须说明处理测试数据的以下4个属性 1 深度 2 宽度 3 范围 4 结构 3 测试脚本概要所谓脚本 是完整的一系列相关终端的活动 一般测试脚本有5个级别 分别是 单元脚本 用于测试特定单元 模块的脚本 并发脚本 用于当两个或多个用户同时访问同一文件时测试的脚本 集成脚本 用于确定各模块是否可以前当连接 回归脚本 用于确定系统未改变的部分在系统改变时是否改变 强度 性能脚本 用于验证系统在被施加大量事务时的性能 1 测试脚本的结构为了提高测试脚本的可维护性和可复用性 必须在执行测试脚本之前对它们进行构建 2 记录技术为使测试脚本获得更高的可维护性 应该以最不易受测试对象变化影响的方式来记录测试脚本 3 数据驱动的测试许多测试过程包括在给定的数据输入屏幕内输入几组字段数据 检查字段确认功能 错误处理等 4 测试脚本同步和时间安排当进行重点测试时 通常需要同步测试脚本以便它们在预先确定的时间启动 5 测试和调试测试脚本在记录测试脚本的同一测试软件上执行这些最近记录的测试脚本时 不应该发生任何错误 4 辅助测试工具为了实施高效的测试工作 还需要有高效 好用的辅助工具 做软件测试通常需要以下一些基本工具 优秀的办公处理软件 秒表 错误跟踪系统 自动测试工具 软件分析工具 好的操作系统 多样化平台 2 6 4执行测试执行测试是执行所有的或选定的一些测试用例 并观察其测试结果的过程 尽管为执行测试所做的准备和计划工作会贯穿于软件开发生命周期之中 但是执行测试往往都会在软件开发生命周期的末期 或者接近末期进行 即在编码完成之后进行 由于测试过程一般分成代码审查 单元测试 集成测试 系统测试和验收测试几个阶段 尽管这些阶段在实现细节方面都不相同 但其工作流程方面却是一致的 执行测试的过程由以下4个部分组成 输入 要完成工作所必须的入口标准或可交付的结果 执行过程 从输入到输出的过程或工作任务 检查过程 确定输出是否满足标准的处理过程 输出 推出标准或工作流程产生的可交付的结果 执行测试过程如图2 5所示 图2 5执行测试过程 2 6 5评估测试软件测试的主要评测方法包括测试覆盖和质量评测 测试覆盖是对测试完全程度的评测 它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的 质量评测是对测试对象 系统或测试的应用程序 的可靠性 稳定性以及性能的评测 它建立在对测试结果的评估和对测试过程中确定的变更请求 缺陷 分析的基础上 1 覆盖评测覆盖指标提供了 测试的完全程度如何 这一问题的答案 最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖 简而言之 测试覆盖是就需求 基于需求的 或代码的设计 实施标准 基于代码的 而言的完全程度的任意评测 如用例的核实 基于需求的 或所有代码行的执行 基于代码的 2 质量评测测试覆盖的评估提供对测试完全程度的评测 在测试过程中已发现缺陷的评估提供了最佳的软件质量指标 3 性能评测评估测试对象的性能行为时 可以使用多种评测 这些评测侧重于获取与行为相关的数据 如响应时间 计时配置文件 执行流 操作可靠性和限制 2 7测试的成功经验 为了减少系统的开发费用 越早测试越好 这是多年来软件行业的一个成功经验 即在整个软件开发生命周期中通过各种软件工程技术尽量早地完成各种软件测试任务 首先 软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程 在软件开发生命周期中 软件是通过迭代来不断加以完善的 在这种环境中 对于每个作为测试目标的工作版本 测试的生命周期还都必须具有一种迭代方法 对于针对每个工作版本执行的测试 都做出了增补和改进 并累积为一个测试体 用于后续阶段的回归测试 通过迭代是软件开发把原来的整个软件开发生命周期分成多个迭代周期 在每个迭代周期都进行测试 这样在很大程度上提前了软件系统测试发生的时间 这可以在很大程度上降低项目风险和项目开发成本 第3章软件测试的方法和技术 3 1软件测试方法概述3 2白盒测试3 3黑盒测试3 4测试用例设计 3 1软件测试方法概述 软件测试的种类大致可分为人工测试和基于计算机的测试 而基于计算机的测试又可分为黑盒测试和白盒测试 1 黑盒测试黑盒测试是根据软件产品的功能设计规格 在计算机上进行测试 以证实每个已经实现的功能是否符合要求 黑盒测试意味着测试要在软件的接口处进行 2 白盒测试白盒测试是根据软件产品的内部工作过程 在计算机上进行测试 以证实每种内部操作是否符合设计规格要求 所有内部成分是否已经过检查 白盒测试把测试对象看做一个打开的盒子 允许测试人员利用程序内部的逻辑结构及有关信息 设计或选择测试用例 对程序所有逻辑路径进行测试 通过在不同点检查程序的状态 确定实际的状态是否与预期的状态一致 3 2白盒测试 白盒测试也称为结构测试或逻辑驱动测试 前提是知道产品内部工作过程 可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行 按照程序内部的结构测试程序 检验程序中的每条通路是否都能够按预定要求正确工作 而不管产品的功能 主要用于软件验证 白盒测试方法又可分为静态测试和动态测试 静态测试是一种不通过执行程序而进行测试的技术 其关键功能是检查软件的表示和描述是否一致 没有冲突或者没有歧义 它瞄准的是纠正软件系统在描述 表示和规格上的错误 是任何进一步测试的前提 而动态测试需要软件的执行 当软件系统在模拟的或真实的环境中执行之前 之中和之后 对软件系统行为的分析是动态测试的主要特点 它显示了一个系统在检查状态下是正确还是不正确 白盒测试的动态测试要根据程序的控制结构设计测试用例 其原则是 1 保证一个模块中的所有独立路径至少被使用一次 2 对所有逻辑值均需测试true和false 3 在上下边界及可操作范围内运行所有循环 4 检查内部数据结构以确保其有效性 下面将介绍几种实用的白盒测试用例设计方法 包括程序插桩 逻辑覆盖 基本路径测试等 3 2 1程序插桩在软件动态测试中 程序插桩是一种基本的测试手段 有着广泛的应用 1 方法简介程序插桩方法是借助往被测程序中插入操作 来实现测试目的的方法 如果我们想要了解一个程序在某次运行中所有可执行语句被覆盖的情况 或是每个语句的实际执行次数 最好的办法是利用插桩技术 这里仅以计算整数X和整数Y的最大公约数程序为例 说明插桩方法的要点 图3 3给出了这一程序的流程图 图3 3插桩后求最大公约数程序的流程图 设计插桩程序时需要考虑的问题包括 探测哪些信息 在程序的什么部位设置探测点 需要设置多少个探测点 2 断言语句在程序中特定部位插入某些用以判断变量特性的语句 使得程序执行中这些语句得以证实 从而使程序的运行特性得到证实 我们把插入的这些语句称为断言 这一做法是程序正确性证明的基本步骤 尽管算不上严格的证明 但方法本身仍然是很实用的 下面以求两个非负数NUM和DEN之商的Wensley迭代算法为例 对断言语句的作用做一简要说明 图3 5计算非负数之商的迭代程序 图3 6插入断言后的迭代程序 3 2 2逻辑覆盖逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术 是通过对程序逻辑结构的遍历实现程序的覆盖 它是一系列测试过程的总称 这组测试过程逐渐进行越来越完整的通路测试 这一方法要求测试人员对程序的逻辑结构有清楚的了解 甚至要能掌握源程序的所有细节 它属于动态测试 从覆盖源程序语句的详细程度分析 逻辑覆盖标准有语句覆盖 判定覆盖 条件覆盖 条件判定组合覆盖 多条件覆盖和修正条件判定覆盖 为便于理解 使用如下所示的程序 图3 7所示的是其流程图 图3 7参考例子流程图 intfunction1 boola boolb boolc intx x 0 if a 1 语句覆盖为了暴露程序中的错误 程序中的每条语句至少应该执行一次 所以 语句覆盖的含义是 选择足够多的测试数据 使被测程序中每条语句至少执行一次 2 判定覆盖比语句覆盖稍强的覆盖标准是判定覆盖 按判定覆盖准则进行测试是指 设计若干测试用例 运行被测程序 使得程序中每个判断的取真分支和取假分支至少经历一次 即判断的真假值均曾被满足 判定覆盖又称为分支覆盖 3 条件覆盖在设计程序中 一个判定语句是由多个条件组合而成的复合判定 条件覆盖的含义是 构造一组测试用例 使得每一判定语句中每个逻辑条件的可能值至少满足一次 4 条件判定组合覆盖条件判定组合覆盖的含义是 设计足够的测试用例 使得判定中每个条件的所有可能 真 假 至少出现一次 并且每个判定本身的判定结果 真 假 也至少出现一次 5 多条件覆盖多条件覆盖也称为条件组合覆盖 它的含义是 设计足够的测试用例 使得每个判定中条件的各种可能组合都至少出现一次 显然满足多条件覆盖的测试用例是一定满足判定覆盖 条件覆盖和条件判定组合覆盖的 6 修正条件判定覆盖它要求满足两个条件 首先 每一个程序模块的入口和出口点都要考虑至少被调用一次 每个程序的判定到所有可能的结果值要至少转换一次 其次 程序的判定被分解为通过逻辑操作符 and or 连接的bool条件 每个条件对于判定的结果值是独立的 7 测试覆盖准则 1 Foster的ESTCA覆盖准则前面所介绍的逻辑覆盖其出发点似乎是合理的 所谓 覆盖 就是想要做到全面而无遗漏 但是 事实表明 它并不能真的做到无遗漏 K A Foster从测试工作实践的教训出发 吸收了计算机硬件的测试原理 提出了一种经验型的测试覆盖准则 2 Woodward等人的层次LCSAJ覆盖准则Woodward等人曾经指出结构覆盖的一些准则 如分支覆盖或路径覆盖 都不足以保证测试数据的有效性 为此 他们提出了一种层次LCSAJ覆盖准则 3 2 3基本路径测试上节的例子是个比较简单的程序段 只有两条路径 但在实际问题中 即使一个不太复杂的程序 其路径的组合都是一个庞大的数字 如果把覆盖的路径数压缩到一定限度内 例如 程序中的循环体只执行零次和一次 就成为基本路径测试 设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次 1 程序的控制流图控制流图是描述程序控制流的一种图示方式 其中基本的控制结构对应的图形符号如图3 8所示 在图3 8所示的图形符号中 圆圈称为控制流图的一个结点 它表示一个或多个无分支的语句或源程序语句 图3 8控制流图的图形符号 图3 9 a 所示的是一个程序的流程图 它可以映射成图 b 所示的控制流图 图3 9程序流程图和对应的控制流图 2 计算程序环路复杂性进行程序的基本路径测试时 程序的环路复杂性给出了程序基本路径集合中的独立路径条数 这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界 所谓独立路径 是指包括若干未曾处理的语句或条件的一条路径 基本路径集不是惟一的 对于给定的控制流图 可以得到不同的基本路径集 通常环路复杂性可用以下3种方法求得 将环路复杂性定义为控制流图中的区域数 设E为控制流图的边数 N为图的结点数 则定义环路的复杂性为V G E N 2 若设P为控制流图中的判定结点数 则有V G P 1 3 基本路径测试法步骤基本路径测试法适用于模块的详细设计及源程序 其主要步骤如下 以详细设计或源代码作为基础 导出程序的控制流图 计算得到的控制流图G的环路复杂性V G 确定线性无关的路径的基本集 生成测试用例 确保基本路径集中每条路径的执行 3 2 4程序的静态测试1 源程序静态分析在静态结构分析中 测试者通过使用测试工具分析程序源代码的系统结构 数据结构 数据接口 内部控制逻辑等内部结构 生成函数调用关系图 模块控制流图 内部文件调用关系图 子程序表 宏和函数参数表等各类图形图表 可以清晰地标识整个软件系统的组成结构 使其便于阅读与理解 然后可以通过分析这些图表 检查软件有没有存在缺陷或错误 通常采用以下一些方法进行源程序的静态分析 1 生成各种引用表 标号交叉引用表 变量交叉引用表 子程序 宏 函数 引用表 等价表 常数表 2 错误静态分析错误静态分析主要用于确定在源程序中是否有某类错误或 危险 结构 类型和单位分析 引用分析 表达式分析 接口分析 2 人工测试静态分析中进行人工测试的主要方法有桌前检查 代码审查和走查 经验表明 使用这种方法能够有效地发现30 70 的逻辑设计和编码错误 1 桌前检查由程序员自己检查自己编写的程序 程序员在程序通过编译之后 进行单元测试设计之前 对源程序代码进行分析 检验 并补充相关的文档 目的是发现程序中的错误 2 代码审查代码审查是由若干程序员和测试员组成一个审查小组 通过阅读 讨论和争议 对程序进行静态分析的过程 代码审查分两步 第一步 小组负责人提前把设计规格说明书 控制流程图 程序文本及有关要求 规范等分发给小组成员 作为审查的依据 小组成员在充分阅读这些材料后 进入审查的第二步 召开程序审查会 3 走查走查与代码审查基本相同 其过程分为两步 第一步也把材料先发给走查小组每个成员 让他们认真研究程序 然后再开会 开会的程序与代码审查不同 不是简单地读程序和对照错误检查表进行检查 而是让与会者 充当 计算机 即首先由测试组成员为被测程序准备一批有代表性的测试用例 提交给走查小组 走查小组开会 集体扮演计算机角色 让测试用例沿程序的逻辑运行一遍 随时记录程序的踪迹 供分析和讨论用 3 2 5其他白盒测试方法简介1 域测试域测试是一种基于程序结构的测试方法 域测试正是在分析输入域的基础上 选择适当的测试点以后进行测试的 2 符号测试符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据 而且包括符号值 这一方法也因此而得名 3 Z路径覆盖分析程序中的路径是指检验程序从入口开始 执行过程中经历的各个语句 直到出口 4 程序变异程序变异方法是一种错误驱动测试 所谓错误驱动测试方法 是指该方法是针对某类特定程序错误的 经过多年的测试理论研究和软件测试的实践 人们逐渐发现要想找出程序中所有的错误几乎是不可能的 比较现实的解决办法是将错误的搜索范围尽可能地缩小 以利于专门测试某类错误是否存在 错误驱动测试主要有两种 即程序强变异和程序弱变异 最后 归纳一下白盒测试中各种测试方法的应用策略 在白盒测试中 可以使用各种测试方法的综合策略如下 1 在测试中 应尽量先使用工具进行静态结构分析 2 测试中可采取先静态后动态的组合方式 先进行静态结构分析 代码检查 再进行覆盖率测试 3 利用静态分析的结果作为导引 通过代码检查和动态测试的方式对静态发现结果进行进一步的确认 使测试工作更为有效 4 覆盖率测试是白盒测试的重点 一般可使用基本路径测试法达到语句覆盖标准 对于软件的重点模块 应使用多种覆盖率标准衡量代码的覆盖率 5 在不同的测试节点 测试的侧重点不同 在单元测试阶段 以代码检查 逻辑覆盖为主 在集成测试阶段 需要增加静态结构分析等 在系统测试阶段 应根据黑盒测试的结果 采取相应的白盒测试 3 3黑盒测试 黑盒测试也称功能测试或数据驱动测试 前提是已知产品所具有的功能 通过测试来检测每个功能是否都正常使用 黑盒测试方法主要有等价类划分 边界值分析 因果图 错误推测 功能图法等 主要用于软件确认测试 3 3 1等价类划分法等价类划分是一种典型的黑盒测试方法 使用这一方法时 完全不考虑程序的内部结构 只依据程序的规格说明来设计测试用例 由于不可能用所有可以输入的数据来测试程序 而只能从全部可供输入的数据中选择一个自己进行测试 如何选择适当的子集 使其尽可能多地发现错误 解决的办法之一就是等价类划分 首先 把数目极多的输入数据 包括有效的和无效的 划分为若干等价类 而所谓等价类 是指某个输入域的子集合 在该子集合中 各个输入数据对于揭露程序中的错误都是等效的 并合理地假定 测试某等价类的代表值就等价于对这一类其他值的测试 因此 可以把全部输入数据合理划分为若干等价类 在每一个等价类中取一个数据作为测试的输入条件 就可用少量代表性测试数据 取得较好的测试结果 等价类的划分有以下两种不同的情况 有效等价类 无效等价类 划分等价类的原则如下 按区间划分 按数值划分 按数值集合划分 按限制条件或规则划分 在确立了等价类之后 建立等价类表 列出所有划分出的等价类 如表3 6所示 再从划分出的等价类中按以下原则选择测试用例 为每一个等价类规定一个惟一的编号 设计一个新的测试用例 使其尽可能多地覆盖尚未覆盖的有效等价类 重复这一步骤 直到所有的有效等价类都被覆盖为止 设计一个新的测试用例 使其仅覆盖一个无效等价类 重复这一步骤 直到所有的无效等价类都被覆盖为止 3 3 2边界值分析法人们从长期的测试工作经验得知 大量的错误是发生在输入或输出范围的边界上 而不是在输入范围的内部 因此针对各种边界情况设计测试用例 可以查出更多的错误 使用边界值分析方法设计测试用例 首先应确定边界情况 选择测试用例的原则如下 如果输入条件规定了值的范围 则应该取刚达到这个范围的边界值 以及刚刚超过这个范围边界的值作为测试输入数据 如果输入条件规定了值的个数 则用最大个数 最小个数 比最大个数多1个 比最小个数少1个的数作为测试数据 根据规格说明的每一个输出条件 使用规则1 根据规格说明的每一个输出条件 使用规则2 如果程序的规格说明给出的输入域或输出域是有序集合 如有序表 顺序文件等 则应选取集合的第一个和最后一个元素作为测试用例 如果程序用了一个内部结构 应该选取这个内部数据结构的边界值作为测试用例 分析规格说明 找出其他可能的边界条件 3 3 3错误推测法人们也可以靠经验和直觉推测程序中可能存在的各种错误 从而有针对性地编写检查这些错误的例子 这就是错误推测法 错误推测法的基本想法是 列举出程序中所有可能有的错误和容易发生错误的特殊情况 根据它们选择测试用例 3 3 4因果图法因果图方法最终生成的就是判定表 它适合于检查程序输入条件的各种组合情况 利用因果图生成测试用例的基本步骤如下 分析软件规格说明的描述中哪些是原因 哪些是结果 原因是输入条件或输入条件的等价类 结果是输出条件 分析软件规格说明描述中的语义 找出原因与结果之间 原因与原因之间对应的关系 根据这些关系 画出因果图 标明约束条件 由于语法或环境的限制 有些原因和结果的组合情况是不可能出现的 为表明这些特定的情况 在因果图上使用若干标准的符号标明约束条件 把因果图转换成判定表 为判定表中的每一列设计测试用例 通常在因果图中 用Ci表示原因 Ei表示结果 其基本符号如图3 12所示 图3 12因果图的基本符号 对于黑盒测试方法来说 以上4种方法是基本的测试方法 除此之外还有判定表驱动法 正交试验法 功能图法和场景法等 在实际测试中 往往是综合使用各种方法才能有效地提高测试效率和测试覆盖率 这就需要认真掌握这些方法的原理 积累更多的测试经验 以有效地提高测试水平 以下是各种测试方法选择的综合策略 可供读者在实际应用过程中参考 首先进行等价类划分 包括输入条件和输出条件的等价划分 将无限测试变成有限测试 这是减少工作量和提高测试效率最有效的方法 在任何情况下都必须使用边界值分析方法 经验表明 用这种方法设计出的测试用例发现程序错误的能力最强 可以用错误推测法追加一些测试用例 这需要依靠测试工程师的智慧和经验 对照程序逻辑 检查已设计出的测试用例的逻辑覆盖程度 如果没有达到要求的覆盖标准 应当再补充足够的测试用例 如果程序的功能说明中含有输入条件的组合情况 则一开始就可选用因果图法和判定表驱动法 对于参数配置类的软件 要用正交试验法选择较少的组合方式达到最佳效果 功能图法也是很好的测试用例设计方法 我们可以通过不同时期条件的有效性设计不同的测试数据 对于业务流清晰的系统 可以利用场景法贯穿整个测试案例过程 在案例中综合使用各种测试方法 3 3 5场景法现在的软件几乎都是用事件触发来控制流程的 事件触发时的情景便形成了场景 而同一事件不同的触发顺序和处理结果就形成事件流 这种在软件设计方面的思想也可以引入到软件测试中 可以比较生动地描绘出事件触发时的情景 有利于测试设计者设计测试用例 同时使测试用例更容易理解和执行 用例场景用来描述流经用例的路径 从用例开始到结束遍历这条路径上所有基本流和备选流 1 基本流和备选流如图3 14所示 图中经过用例的每条路径都用基本流和备选流来表示 直黑线表示基本流 是经过用例的最简单的路径 备选流用不同的色彩表示 一个备选流可能从基本流开始 在某个特定条件下执行 然后重新加入基本流中 如备选流1和3 也可能起源于另一个备选流 如备选流2 或者终止用例而不再重新加入到某个流 如备选流2和4 图3 14基本流和备选流 2 ATM例子 1 例子描述图3 15所示是ATM例子的流程示意图 图3 15ATM流程示意图 2 场景设计表3 8所示是生成的场景 3 用例设计对于这7个场景中的每一个场景都需要确定测试用例 可以采用矩阵或决策表来确定和管理测试用例 下面显示了一种通用格式 其中各行代表各个测试用例 而各列则代表测试用例的信息 本示例中 对于每个测试用例 存在一个测试用例ID 条件 或说明 测试用例中涉及的所有数据元素 作为输入或已经存在于数据库中 以及预期结果 4 数据设计一旦确定了所有的测试用例 则应对这些用例进行复审和验证以确保其准确且适度 并取消多余或等效的测试用例 测试用例一经认可 就可以确定实际数据值 在测试用例实施矩阵中 并且设定测试数据 如表3 10所示 3 4测试用例设计 3 4 1测试用例的基本概念简单地说 测试用例就是设计一个情况 软件程序在这种情况下 必须能够正常运行并且达到程序所设计的执行结果 如果程序在这种情况下不能正常运行 而且这种问题会重复发生 那就表示已经测出软件有缺陷 这时候就必须将这个问题标示出来 并且输入到问题跟踪系统内 通知软件开发人员 软件开发人员接到通知后 将问题修改完成于下一个测试版本内 测试工程师取得新的测试版本后 必须利用同一个测试用例来测试这个问题 确保该问题已修改完成 在测试时 不可能进行穷举测试 为了节省时间和资源 提高测试效率 必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试 使用测试用例的好处主要体现在以下几个方面 在开始实施测试之前设计好测试用例 可以避免盲目测试并提高测试效率 测试用例的使用令软件测试的实施重点突出 目的明确 在软件版本更新后只需修正少部分的测试用例便可开展测试工作 降低工作强度 缩短项目周期 功能模块的通用化和复用化使软件易于开发 而测试用例的通用化和复用化则会使软件测试易于开展 并随着测试用例的不断精化其效率也不断提高 测试用例主要有如下几种 功能测试用例 包含功能测试 健壮性测试 可靠性测试 性能测试用例 包含性能测试 压力测试 强度测试 集成测试用例 包含接口测试 健壮性测试 可靠性测试 安全测试用例 安全测试用例 用户界面测试用例 用户界面测试用例 少量功能测试用例 安装 反安装测试用例 安装 反安装测试用例 测试种类 阶段和用例的关系如表3 11所示 测试工作和开发通常一同进行 所以在完成测试计划编写后 就可以进行用例的编写工作了 测试和开发的对应关系如表3 12所示 3 4 2测试用例的设计步骤测试按照阶段分为单元测试 集成测试以及系统测试 而各阶段都有相应的测试用例 这里 以单元测试的用例设计为依据来说明测试用例的设计步骤 单元测试说明实际上由一系列单元测试用例组成 每个测试用例应该包含以下4个关键元素 被测单元模块初始状态声明 即测试用例的开始状态 仅适用于被测单元维持了调用间状态的情况 被测单元的输入 包含由被测单元读入的任何外部数据值 该测试用例实际测试的代码 用被测单元的功能和测试用例设计中使用的分析来说明 如单元中哪一个决策条件被测试 测试用例的期望输出结果 测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义 下面说明测试用例的设计步骤 1 步骤1 使被测单元运行这个阶段适合的技术有 模块设计导出的测试 对等区间划分 2 步骤2 正面测试 PositiveTesting 这个阶段适合的技术有 设计说明导出的测试 等价类分析 状态转换测试 3 步骤3 负面测试 NegativeTesting 这个阶段适合的技术有 错误猜测 边界值分析 内部边界值测试 状态转换测试 4 步骤4 需求中其他测试特性用例设计这个阶段适合的技术有 设计说明导出的测试 5 步骤5 覆盖率测试用例设计这个阶段适合的技术有 分支测试 条件测试 数据定义 使用测试 状态转换测试 其中 和 均属于逻辑覆盖范畴 6

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论