第四章执行测试(2).ppt_第1页
第四章执行测试(2).ppt_第2页
第四章执行测试(2).ppt_第3页
第四章执行测试(2).ppt_第4页
第四章执行测试(2).ppt_第5页
已阅读5页,还剩57页未读 继续免费阅读

下载本文档

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

文档简介

1 4 2执行系统测试 系统测试是针对整个产品系统进行的测试 系统测试的目的是验证系统是否满足了需求规格的定义 找出与需求规格不相符合或与之矛盾的地方 系统测试的对象不仅包括需要测试的产品系统的软件 还要包含软件所依赖的硬件 外设甚至包括某些数据 某些支持软件及其接口等 2 4 2 1系统测试流程 3 系统测试进入标准在测试计划中定义 包括 测试计划和测试系统完成否 单元和集成测试完成否 报告测试结果包括 测试状态报告测试结果报告 系统测试结束标准在测试计划中定义 包括 所有定义的测试执行吗 符合测试通过 失败准则吗 4 软件运行存在三种环境 开发环境 测试环境 用户环境 开发环境往往与用户环境有所差别 一个规划良好的测试环境总很接近于用户环境 测试环境在测试计划和测试用例中事先定义和规划 4 2 2建立系统测试环境 测试环境 用户环境 测试环境适合与否 会严重影响测试结果的真实性和正确性 5 建立系统测试环境 建立测试环境包括 硬件环境 软件环境 网络环境 测试环境如何规划 分析用户环境中哪些配置可能对软件有所影响 在此基础上建立测试环境 6 某软件是一个运行在Windows下的桌面应用软件 可以完成数据文件备份与恢复功能 该软件支持Windows98及以上的各个Windows版本 可以将文件备份到CD刻录机 DVD刻录机 USB移动硬盘 建立系统测试环境 如何考虑测试环境 7 建立系统测试环境 软件环境操作系统 不同版本的Windows系统 例如包括Windows98 Windows98SE WindowsME Windows2000Professional Windows2000Server WindowsXPHomeEdition WindowsXPProfessional等 其中 WindowsXPHomeEdition Windows2000Professional包括了英文和简体中文版本 硬件环境多种CD DVD刻录机 如三中CD刻录机 IDE接口内置式 SCSI接口内置式 USB接口外置式 带有CD刻录功能的DVD Combo DVD刻录机Usb移动硬盘 8 建立系统测试环境 建立测试环境需要考虑 计算机平台操作系统浏览器软件支持平台外围设备网络环境数据环境其他专用环境 9 计算机平台 计算机平台可以考虑 CPU速度 内容容量 硬盘 显示卡等 一般在软件需求中列出软件对平台的最低配置要求 在搭建测试平台时 一般需要考虑 最低配置常见配置理想配置 10 操作系统 软件一般都声明支持的操作系统Windows平台本身有多个版本 而每个版本都包括了几个系列 以及不同语言 测试人员需要了解不同版本操作系统之间的差异 Linux平台有不同公司开发的更多的版本 测试时首先关注软件所要求的Linux核心版本 其他可能的操作系统 Unix MacOS 嵌入式操作系统 11 浏览器 基于Web的应用系统 需对各种流行的浏览器环境进行测试 不同的操作系统下 浏览器有不同选择 Windows平台下常用 IE FireFox 腾讯TT浏览器等Linux平台下Opera netscape Mozilla等 12 软件支持平台 典型的支持平台主要包括 Java虚拟机 数据库 应用服务器 第三方控件 浏览器插件 13 外围设备不同的软件系统需要不同的外围设备 在多种外围设备上进行测试 需要大量的时间和费用 一般选择设备的几款主流型号进行测试 网络环境网络访问方式网络速度防火墙 14 如何配置测试环境 假如某个软件需要测试两种浏览器 IE和FireFox 四种操作系统 Windows98 WindowsME Windows2000 WindowsXP 三种CPU IntelPIII1G IntelP42 8G AMDAlthonXP2600 两种内存配置 256M 512M 两种网络连接方式 拨号网络 ADSL宽带接入 要测试多少种环境 15 如何配置测试环境 搭建测试环境 需考虑配置的优先级使用的频度或范围失效的可能性能最大限度模拟真实环境 根据以上指标 给出测试环境的优先级 16 建立测试环境的步骤安装应用程序安装和开发测试工具 如果需要 设置专用文件 包括将这些文件与测试所需的数据相对应建立与应用程序通信的实用程序 17 执行测试用例后的两种结果 4 2 3报告测试结果 实际结果与预期结果相符 pass实际结果与预期结果不符 fail 对于发现的错误 缺陷 要填写错误报告单 也称为缺陷报告单 18 好的缺陷报告应该具有以下特征 书面的已编号的简单的 易于理解的可重现的具有合适的分类信息 19 一 缺陷的分类 缺陷可以按照不同的方式进行分类 按照缺陷等级分类按照缺陷处理优先级分类按照缺陷原因分类 20 软件缺陷等级 按照缺陷的严重程度 影响程度的不同 软件缺陷可以被分为不同的等级 也可称为 缺陷严重程度 缺陷严重等级 21 软件缺陷等级 所谓 严重性 指的是在测试条件下 一个错误 缺陷 在系统中的影响 主要包括以下五种 P95致命错误 缺陷 1级 影响全局的死机 通信中断 重要业务不能完成 例如 程序引起的死机或非法退出 死循环 数据库死锁 功能错误等 有时也称为高等级错误 严重错误 缺陷 2级 规定的功能没有实现或不完整或产生错误结果 设计不合理造成性能低下 影响系统的运营 使系统不稳定 或破坏数据等 一般错误 缺陷 3级 不影响主要功能使用 或者有替代的方式完成用户需要的功能 例如操作界面错误 打印内容 格式错误 数据库表中有多余的空字段 删除操作未给出提示等 轻微错误 缺陷 4级 通常指界面拼写错误或用户使用不方便等小问题或需要完善的问题 例如 界面不规范 未给出操作时间提示 未使用行业术语等 改进建议 5级 改进建议一般指软件中值得改良的地方 22 缺陷处理优先级一般分为 立即解决 要求开发人员立即修复 此错误阻止进一步测试 需要立即修复 高优先级 此错误在产品发布前必须修复 否则会影响软件的发布和使用正常排队 应该修复 如果时间允许 应该修复此错误 缺陷 低优先级 考虑修复 此错误即使不修复 也可以发布 23 严重程度与优先级的关系 一般地 严重程度高的软件缺陷具有较高的优先级 Q 严重程度与优先级成正比吗 严重程度高的Bug其优先级就高吗 不一定 例如 1 如果某个严重的软件缺陷只在非常极端的条件下产生 则没有必要马上解决 2 如果修正一个软件缺陷 需要重新修改软件的整体架构 可能会产生更多潜在的缺陷 而且软件由于市场的压力必须尽快发布 此时即使缺陷的严重性很高 是否需要修正 需要全盘考虑 严重程度低优先级不一定低 例如 如果是软件名称或公司名称的拼写错误 虽然说其属于界面错误 严重程度不高 但是其关系到软件和公司的市场形象 必须尽快修正 在实际测试中 要视具体情况来判断 24 程序员在面对一系列错误 缺陷 的时候 一般情况下 需要先修改错误 缺陷 等级高的 但并不都如此 优先级 抓住了在严重程度中没有考虑的重要程度因素 严重性等级由测试人员决定 而优先级则由项目经理设置 注意 25 软件缺陷产生的原因主要包括 需求分析不完善造成软件不满足用户要求软件设计错误造成运行错误程序员编写代码过程中引入错误 缺陷原因 根据缺陷发生的原因对缺陷进行分类可以帮助软件项目开发组总结开发过程的薄弱环节 给今后的软件项目开发提供经验数据 26 还可以按照缺陷的发生位置进行分类 便于识别出经常出问题的软件模块 确定责任人 通过缺陷发生位置的统计可以帮助软件项目组进行软件质量分析 便于今后进一步的质量改进 27 二 缺陷报告的内容 对缺陷的描述主要包含以下内容 缺陷报告基本信息缺陷描述测试环境说明其它附件 详细内容见P96 28 缺陷报告的基本信息主要包括 缺陷编号软件名称和版本号缺陷的严重程度缺陷概要报告人发现缺陷的时间承办人缺陷的优先级缺陷状态注释 29 缺陷描述 缺陷描述的详细程度直接影响开发人员对缺陷的修复 描述要尽可能地详细 测试环境说明其他附件 若发现缺陷的过程中 使用了其他的输入文件或为了说明缺陷使用的屏幕复制文件 应该附上 30 缺陷报告实例 31 报告软件缺陷的基本要求是准确 简洁 完整 规范 三 报告缺陷的技巧 编写高效的报告 需要做到以下几点 要重点说明让问题重现的步骤和方法分析错误 缺陷 用最少的但最必要的步骤描述写出的报告应该完备 易读而且没有敌意不要轻易猜测错误 缺陷 的原因进行演示和使用文件附件立即记录错误 缺陷 当一个错误 缺陷 发生的时候 测试人员应立刻停止正在做的任何操作并记录不要遗漏 即使是小缺陷 32 缺陷报告中的常见问题 在报告中说 不好用 所报告内容毫无意义在报告中用户没有提供足够的信息在报告中提供了虚假信息所报告的问题是由于用户的过失而产生的所报告的问题是由于其他程序的错误而产生的所报告的问题是由于网络错误而产生的 33 如何描述软件缺陷 34 在缺陷报告中 核心的内容是 缺陷描述 优秀的缺陷描述主要由三个基本部分组成 摘要 重建步骤和隔离 摘要 又叫主题或标题 是关于bug的一两句话的描述 强调它对顾客或系统用户的影响 重建步骤 提供了如何重复这个bug的精确描述 隔离 是指测试人员收集的结果和信息 以确认bug确实是一个问题 并标识那些影响到bug表现的要素 35 测试人员在报告缺陷时需注意以下方面 描述清楚 精确 简洁内容详细描述事实而不是推测报告缺陷如何重现妥善处理间歇性bug在递交前检查 36 缺陷报告分析 一 冗长混乱的bug报告 37 缺陷报告分析 二 含糊不清的bug报告 38 缺陷报告分析 三 优秀的bug报告 39 缺陷报告的读者主要有两种 开发人员和项目管理者开发人员 关注的是Bug的详细描述 即Bug的重现步骤 项目管理者 主要关注Bug的概述和严重程度 优先级 关注整个系统中各种严重级别Bug的分部比例 40 1 确保重现Bug 在提交Bug之前一定要确保Bug能够重现 对于严重程度较高的Bug 一般要重复测试2次以上 对于随机产生的Bug 要在其他机器上测试一下 看看是否是自己机器的原因 注意 不可再现的缺陷也需要引起重视 2 要用最少且必要的步骤描述Bug 使用最少且必要的步骤 减少开发人员定位问题的时间 例如 3 简洁 准确 完整站在开发人员的角度上思考问题 要确保开发人员拿到缺陷报告后马上就能够定位问题 而不会产生理解上的歧义 因此错误概述和错误描述要注意简洁 准确 完整 尽量使用业界惯用的表达术语和表达方法 不要出现拼写和语法错误 4 尽量一个Bug一个报告若一个报告中有多个Bug 则不便于分配Bug和回归测试 提交缺陷报告的注意事项 41 每日构造 每日构造指开发方 测试方 项目管理方协同工作 跟踪 解决和终结报告的软件缺陷 每日推出一个新的系统版本 使系统版本越来越稳定 直到交付最终的系统版本 根据麦肯锡公司的调查 在100家企业中 94 的成功企业采用每日构造 在系统测试阶段 通过每日构造 会产生一系列的版本 有的公司对其赋予不同的名字 作为项目里程碑的标志 1 Alpha版 内部测试版 2 Beta版 外部测试版 3 RC版 ReleaseCandidate 发行候选版 4 RTM版 ReleasetoManufacture 交付生产版软件的DEMO版也是指的测试版 42 报告中需要重现缺陷吗 43 有时候 程序员阅读缺陷报告即可知道缺陷的位置和原因 如何修复 但是多数情况下 重现缺陷是必须的 否则无法确定缺陷的位置 原因 44 四 缺陷的重现 为什么需要重现缺陷 如果不能重现缺陷 程序员可能不能理解到底发生了什么 程序员需要知道缺陷发生的步骤 对程序进行动态调试 以修复问题 如果程序员不能亲眼看到问题 有时候程序员会对软件缺陷报告置之不理 45 所有的缺陷都能重现吗 46 当测试人员发现一个缺陷时 他所看到的只是现象 并不是根源 当所发现的缺陷不能被重现时 测试人员应重复发现缺陷时的操作环境和操作步骤 软件缺陷是不会间歇发生的 即使出现概率很小 但一旦满足了确切的条件 缺陷会再次显现出来 任何缺陷都应该是可重现的 47 为什么我无法重现缺陷 48 有很多原因使测试人员不能立即重现某个缺陷 测试的时间节奏出现变化缺陷依赖于特定执行顺序缺陷造成的影响导致无法重现缺陷与内存内容相关仅仅在初次运行时出现缺陷间歇性的硬件故障与时间相关的缺陷缺陷依赖于资源缺陷由长期积累形成在测试的中途 有人输入了新数据而测试人员不知道 49 4 2 4管理软件缺陷 管理软件缺陷是测试工作的一个重要部分 管理软件缺陷主要是对缺陷进行跟踪 确保每个被发现的缺陷都能够及时得到处理 软件测试缺陷跟踪管理系统可以实现缺陷跟踪管理 是管理软件测试缺陷的专用数据库系统 能够高效率地完成软件缺陷的报告 验证 修改 查询 统计 存储等任务 50 对缺陷的跟踪需要达到以下的目标 确保每个被发现的缺陷都能够被解决 解决不一定是被修正 也可能是其他处理方式 但对每个被发现的缺陷的处理方式必须能够在开发组织中达到一致 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段决定测试过程是否结束有很多种方式 通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式收集缺陷数据并在其上进行数据分析 作为组织的过程财富 51 缺陷处理流程 最简单的 最简单的Bug处理流程 实际上 不同公司的Bug处理流程一般是不同的 同一公司的不同项目的Bug处理流程也不尽相同 首先测试人员发现并提交一个Bug 此时Bug的状态为新建 New 确认bug并将状态修改为开放 Open 然后测试人员将该Bug分配给相应的开发人员 并且开发人员接受 Bug的状态变为已分配 Assigned 然后开发人员修改这一Bug 修改完成后 将Bug的状态变为已解决 Fixed 并将新版本提交给测试人员 然后测试人员对新版本进行回归测试 如果该Bug确实被修改掉 则将Bug的状态修改为已关闭 Closed 如果未通过回归测试 则发给开发人员让其继续修改 52 缺陷处理流程 bug的各种状态 更复杂的bug处理流程 1 发现Bug并确认bug 测试人员将其设置为开放 Open 状态 2 项目经理确定该bug的处理负责人后 将其标记为已分配 Assigned 状态 3 若bug无法重现或报告不清楚 则项目经理修改为被拒绝 Rejected 测试人员纠正后再次提交 4 若bug有可能是误报或问题很微小因而存在争议 项目经理可能设置为 忽略 Igonred 状态 5 开发人员解决了该Bug 将状态修改为解决 Fixed 并发给测试人员回归测试 6 测试人员对Bug进行回归测试 若确实解决 将状态修改为关闭 Closed 否则的话则发给开发人员重新修改 Reopen 53 软件缺陷状态包括 开放 Open 已分配 Assigned 被拒绝 Rejected 被忽略 Ignored 修复 Fixed 关闭 Closed 54 缺陷处理流程 bug的各种状态 更复杂的bug处理流程

温馨提示

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

评论

0/150

提交评论