软件测试的基本理论和方法ppt课件.ppt

软件测试培训 测试的基本理论及方法 1 测试的基本理论及方法 对软件测试的误解如何理解软件测试软件测试的定义软件测试的对象测试的目的软件测试的分类测试类型的解释黑盒测试的几种典型方法测试的分类与比较 测试流程测试规范软件测试的文档和模版软件系统的主要测试内容及技术WEB应用的测试测试工作中需要注意的问题企业的测试策略关于测试的几个问题 2 对软件测试的误解 如果发布出去的软件有质量问题 那是软件测试人员的错 软件测试技术要求不高 至少比编程容易多了 软件测试随便找一个能力差的人就能做 有时间就多测试一些 来不及就少测试一些 软件测试是测试人员的事 与开发人员无关 设计 实现 测试 软件测试是开发后期的一个阶段 3 如何理解软件测试 软件测试是一种有效的提高软件质量的手段 但即使在投入上有所保证 测试也不能百分百发现所有质量隐患 况且软件质量并不仅仅是测试出来的 很多人认为软件测试就是运行一下软件 看看结果对不对 但实际上 如何在有限的投入下 提高软件测试的效率和产出是一件很见功底的事 好的测试人员不仅要掌握各种测试技术 还要具备丰富的编程经验和对BUG的敏感 测试的复杂之处 除了测试技术问题之外 还有测试管理问题 测试不是可有可无 随心所欲的 规范化的软件开发需要对软件测试早做计划 分配必要的时间 人力和财力等资源 并将其作为项目管理的一个部分加以控制和协调 开发和测试是软件项目相辅相成的两个过程 人员间的交流 协作和配合是提高整体效率的重要因素 4 软件产品开发完毕 再进行测试的观念是有悖于生命周期理论的 软件产品质量问题越晚发现 修复的代价越大 5 一些常识和经验之谈测试能提高软件的质量 但是提高质量不能依赖测试 测试只能证明缺陷存在 不能证明缺陷不存在 彻底地测试 难以成为现实 要考虑时间 费用等限制 不允许无休止地测试 我们应当祈祷 软件的缺陷在产品被淘汰之前一直没有机会发作 测试的主要困难是不知道如何进行有效地测试 也不知道什么时候可以放心地结束测试 每个开发人员应当测试自己的程序 份内之事 但是不能作为该程序已经通过测试的依据 所以项目需要独立测试人员 80 20原则 80 的缺陷聚集在20 的模块中 经常出错的模块改错后还会经常出错测试应当循序渐进 不要企图一次性干完 注意 欲速则不达 6 软件测试的定义 软件测试是为了发现错误而执行程序的过程软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例 即输入数据及其预期的输出结果 并利用这些测试用例去运行程序 以发现程序错误的过程软件测试就是在软件投进运行前 对软件需求分析 设计规格说明和编码的终极复审 是软件质量保证的关键步骤 7 软件测试不等于程序测试 软件测试贯穿于软件定义和开发的整个期间 需求分析 概要设计 详细设计 以及程序编码等各个阶段所得到的文档 包括需求规格说明 概要设计规格说明 详细设计规格说明以及源程序 都是软件测试的对象 软件测试的对象 8 软件生存各个阶段间的确认和验证 9 软件配置 包括软件需求规格说明 软件设计规格说明 源代码等 测试配置 包括测试计划 测试用例 测试驱动程序等 实际上 在整个软件工程过程中 测试配置只是软件配置的一个子集 测试工具 为提高软件测试效率 可使用测试工具支持测试工具 例如 测试数据自动生成程序 测试结果分析程序等 10 测试的目的 关于测试的目的 一般的观点认为 测试主要是为了查找软件中存在的错误 实际上 软件测试的目的不仅于此 具体如下 验证需求与设计的正确性 发现软件存在的错误 为软件开发商 用户确立关于软件质量的信心 11 软件测试的分类 软件测试是一项复杂的系统工程 从不同的角度考虑可以有不同的划分方法 对测试进行分类是为了更好的明确测试的过程 了解测试究竟要完成哪些工作 尽量做到测试的全面性 12 13 测试类型的解释 14 15 16 17 黑盒测试的几种典型方法 18 测试的分类与比较 黑盒测试与白盒测试的比较白盒测试 关心软件内部设计和程序实现 主要测试依据是设计文档黑盒测试 不关心软件内部 只关心输入输出 主要测试依据是需求文档 19 不同阶段测试作用的比较单元测试 集成测试 系统测试 验收测试 是 从小到大 由内至外 循序渐进 的测试过程 体现了 分而治之 的思想 单元测试的粒度最小 一般由开发小组采用白盒方式来测试 主要测试单元是否符合 设计 集成测试界于单元测试和系统测试之间 起到 桥梁作用 一般由开发小组采用白盒加黑盒的方式来测试 既要验证 设计 又要验证 需求 系统测试的粒度最大 一般由独立测试小组采用黑盒方式来测试 主要测试系统是否符合 需求规格说明书 验收测试与系统测试非常相似 主要区别是测试人员不同 验收测试由用户执行 20 开发与测试的V型关系如果软件开发过程采用严格的瀑布模型 那么开发与测试有 V 型的对应关系 21 测试流程 测试流程第一步 制定测试计划 该计划被批准后转向第二步 第二步 设计测试用例 该用例被批准后转向第三步 第三步 如果满足 启动准则 那么执行测试 第四步 撰写测试报告 第五步 消除软件缺陷 如果满足 完成准则 那么正常结束测试 22 测试的信息流测试信息流如下图所示 23 软件测试的策略在软件工程中 测试过程应该按4个步骤进行 即单元测试 组装 集成 测试 确认测试和系统测试 下图给出了软件测试经历的4个步骤 24 测试规范 测试启动准则同时满足以下条件 允许开始测试 1 测试计划已经制定并且通过了审批 2 测试用例已经设计并且通过了审批 3 被测试对象已经开发完毕并等待测试 4 被测试对象基本满足需求需要 测试完成准则对于非严格系统可以采用 基于测试用例 的准则 同时满足以下条件允许结束测试 1 功能性测试用例通过率达到100 2 非功能性测试用例通过率达到90 时 对于严格系统 应当补充 基于测试期缺陷密度 的规则 3 相邻n个CPU小时内 测试期缺陷密度 全部低于某个值m 例如n大于10 m小于等于1 25 软件测试的文档和模版 测试计划 指明范围 方法 资源 以及相应测试活动的时间进度安排表的文档 一个测试计划应包括 产品基本情况描述 测试需求说明 测试策略描述 测试资源配置 计划表 问题跟踪报告 停测标准 风险分析等 测试方案 指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档 测试方案一般主要包括以下几个方面 测试配置要求 软件结构介绍 各测试阶段测试用例等 测试用例 指明为完成一个测试项的测试输入 预期结果 预期执行条件等因素的文档 测试用例文档结构一般包含以下几个方面 编写目的 被测对象分析 测试预置条件 测试用例列表 测试用例 测试报告 指明执行测试结果的文档 26 测试计划 测试计划一般从测试的目的 范围 背景 测试策略 测试人员的组织 测试启动准则与结束准则 以及测试任务 测试中可能遇到的问题与对策等多方面来写测试计划 测试计划的目的收集并分析被测软件的需求情况 细化待测的需求 如动态需求 性能需求等 尽量量化测试需求 并给出测试标准 制定停测标准 控制测试成本 合理配置测试资源 评估测试风险 尽量避免或减少风险带来的损失 测试计划内容定义测试需求需要考虑的测试内容 软件功能 用户界面 软件性能 配置测试 安装卸载测试 安全性测试等 测试设计的目标 定义手动测试过程 自动测试过程 选择适当的测试用例 组织测试过程信息 并传递给测试开发人员 27 评审测试计划涉及评审的问题评审测试的开始时间是否会延期有没有抵触评审的角色一段时间内是否很难得到工作的检查信息更换工具有可能导致他们反感评审工作评审结果可能会影响对个人的工作评价对于最终成品的检查项目的需求规格说明书软件返工 维护的文档升级后的技术文档被更改的源程序测试计划用户手册 包括在线帮助 28 测试方案 测试方案的目的根据测试计划 规划测试内容 并且详细制定被测需求的测试方法 测试方案内容确定测试手段 确定在各个阶段使用何种测试方法 测试通过准则界定 各测试阶段所用测试用例 如单元测试阶段 集成测试阶段等 29 测试用例 测试用例设计方法一般的测试用例设计方法有等价类 边界值 错误推断 因果图 比较测试法 决策表等 测试用例文档结构测试用例文档结构一般包含以下几个方面 编写目的 被测对象分析 测试预置条件 测试用例列表 测试用例 被测对象分析对每个被测对象的分析描述 描述影响被测对象行为的各个因素 及其各个因素可能的取值 测试预置条件描述执行本测试用例需要预置的条件 例如数据库中需要存在什么数据 需要配置什需要处于什么状态 30 测试用例测试用例主要包括如下内容 描述测试用例类别 功能 容错 性能等测试用例编号被测对象名称子功能名称测试阶段测试目标 功能验证 容错处理 输入数据及操作步骤 需要描述每个步骤使用什么命令 需要什么操作 需要什么样的输入数据 对于输入数据需要具体说明数据格式以及内容预期结果测试用力注意事项如果测试用例执行有特殊要求 必须说明 测试用例要覆盖到所有需求 且与需求保持一致 测试用例之间不重复 无冗余 每个测试用例都描述正确 每个测试用例要保证测试执行者在每次测试时依照同样的环境 同样的步骤 同样的数据进行测试 保证不同的测试执行者的测试执行过程一致 或者同一个测试执行者在多次的测试执行中保持一致 31 测试用例 测试报告的目的总结当前的软件测试工作 对被测软件的版本质量作出评估 给产品能否发布一个参考值 测试报告里的内容其实不复杂 重点是我们如何对当前的测试版本进行分析 一般地我们从下面几个方面分析 缺陷分布 所谓缺陷分布 就是统计软件产品中缺陷的分布情况 看哪些功能模块存在的缺陷较多 缺陷修复情况 缺陷修复情况同样是我们测试报告中必不可少的一个分析点 通过缺陷的修复情况 我们来决定测试是否终止 遗留缺陷 遗留缺陷是对当前测试版本中尚未解决的缺陷进行的分析统计 通过分析得知 哪些问题没有解决 是什么原因 这些问题对软件的质量影响有多大等 质量评估 质量评估是测试组对被测对象质量的一个综合的总结 32 软件系统的主要测试内容及技术 接口与路径测试功能测试健壮性测试性能测试用户界面测试信息安全测试压力测试可靠性测试安装 反安装测试 33 接口与路径测试数据一般通过接口输入和输出 所以接口测试是白盒测试的第一步 每个接口可能有多个输入参数 每个参数有 典型值 边界值 异常值 之分 所以输入的组合数可能并不少 根据接口的定义 可以推断某种输入应当产生什么样的输出 输出包括函数的返回值和输出参数 如果实际输出与期望的输出不一致 那么说明程序有错误 白盒方式的接口测试和黑盒方式的功能测试 其方法十分相似 一个函数体内的语句可能只有十几条 但逻辑路径可能有成千上万条 想遍历测试几乎是不可能的 不测试或者胡乱找几条路径测试却又不行 对于非严格系统而言 在分析路径方面花费很多精力是不值得的 我认为在构造接口测试的同时已经建立了测试路径 因为每一种输入将产生唯一的输出 输入与输出之间的路径也是唯一的 由于接口测试中的输入是有代表性的 因此相应的路径也具有代表性 用不着费煞苦心地去找测试路径 路径测试的检查表数据类型 变量值 逻辑判断 循环 内存管理 文件I O 错误处理由于接口测试是枚举的 有可能漏掉某些状况 导致一些重要的路径没有被测试 预防措施有 观察是否有程序语句从来没有被执行过 如果发生这种情况 要么是程序有错误 存在无用的代码 要么是接口测试不充分 漏掉了一些路径 要特别留意函数体内的错误处理程序块 如果存在的话 这是最易被人疏忽的路径 隐患最多 34 接口与路径测试用例的参考模板 35 功能测试功能测试的基本方法是构造一些合理输入 在需求范围之内 检查输出是否与期望的相同 如果两者不一致 即表明功能有误 也有例外的情况 如 需求规格说明书 中的某个功能写错了 而实际上软件的功能却是正确的 这时要更改的是 需求规格说明书 功能测试看起来比较简单 只要看得懂 需求规格说明书 谁都会做 难点在于如何构造有效的输入 由于输入空间通常是无限的 穷举测试显然行不通 那么随便输入一些东西 碰运气行不行 功能测试有两种比较好的测试方法 等价划分法和边界值分析法 等价划分是指把输入空间划分为几个 等价区间 在每个 等价区间 中只需要测试一个典型值就可以了 等价划分法来源于人们的直觉与经验 可令测试事半功倍 缺陷遗漏在角落里 聚集在边界上 边界值测试法是对等价划分法的补充 如果A和B是输入空间的边界值 那么除了典型值外还要用A和B作为测试用例 例如测试函数 凭直觉 等价区间应是 0 1 和 1 可取典型值x 0 5以及x 2 0进行 等价划分 测试 再取x 0以及x 1进行 边界值 测试 36 功能测试用例的参考模板 37 健壮性测试健壮性是指在异常情况下 软件还能正常运行的能力 健壮性有两层含义 一是容错能力 二是恢复能力 容错性测试通常构造一些不合理的输入来引诱软件出错 例如 1 输入错误的数据类型 如 猴 年 马 月 2 输入定义域之外的数值 如上海人常说的 十三点 粗暴一些方式俗称 大猩猩 测试法 除了不能拳打脚踢嘴咬外 什么招术都可以使出来 例如在测试客户机 服务器模式的软件时 把网络线拔掉 造成通信异常中断 恢复测试重点考察以下几项 1 系统能否重新运行 2 有无重要的数据丢失 3 是否毁坏了其它相关的软件硬件 38 目标当在进行安装或组装操作过程中 文件丢失时或发生意外后系统有能力重新进行操作如何使用程序的安装 运行方式 工具的使用和关键技术经过足够的评估系统开发完毕后 介绍一下发生失败后的处理过程例子人为的使一个系统在安装或者组装过程中产生错误什么时间去使用当操作的连续性是个重点的时候 39 健壮性测试用例的参考模板 40 性能测试性能测试即测试软件处理事务的速度 一是为了检验性能是否符合需求 二是为了得到某些性能数据供人们参考 例如用于宣传 有时人们关心测试的 绝对值 如数据送输速率是每秒多少比特 有时人们关心测试的 相对值 如某个软件比另一个软件快多少倍 在获取测试的 绝对值 时 我们要充分考虑并记录运行环境对测试的影响 例如网络环境 计算机主频 总线结构和外部设备都可能影响软件的运行速度 性能测试的一些注意事项 不要试图让人拿着钟表去测时间 应当编写一段程序用于计算时间以及相关数据 应当测试软件在标准配置和最低配置下的性能 为了排除干扰 应当关闭那些消耗内存 占用CPU的其它应用软件 如杀毒软件 不同的输入情况会得到不同的性能数据 应当分档记录 例如传输文件的容量从100K到1M可以分成若干等级 由于环境的波动 同一种输入情况在不同的时间可能得到不同的性能数据 可以取其平均值 41 目标确定系统达到了希望达到的性能水平如何使用使用软件和硬件的监视器使用模拟的监控模型 对关心的性能指标进行监控创建一个小程序例子计算通信的时间单位时间处理的信息量 42 用户界面测试绝大多数软件拥有图形用户界面 图形用户界面的测试重点是正确性 易用性和视觉效果 在评价易用性和视觉效果时 主观性非常强 应当考虑多个人的观点 用户界面测试用例的参考模板 43 信息安全测试信息安全性 security 是指防止系统被非法入侵的能力 既属于技术问题又属于管理问题 信息安全性测试有如下步骤 为非法入侵设立目标 例如 盗窃某个文件 或 更改数据库记录 等 邀请 或悬赏 一些人扮演黑客 让他们想尽办法入侵系统 实现 目标 如果有人成功了 请他详述入侵的过程 别忘了给予奖励 目标安全性的缺陷很难被发现大多诉的情况下组织能够防止一般性的破坏者如何使用对安全性的需求进行审评分析与安全性有关的处理流程转包给专业的人员例子定义了被保护的资源 权限进行了控制 日志文件和审查追踪是可能的什么时间使用当被保护的资源对于组织具有重要的价值的时候 44 信息安全性测试用例的参考模板 45 压力测试压力测试也叫负荷测试 即获取系统能正常运行的极限状态 了解 极限 是很有价值的 例如潜艇下潜极限深度 压力测试的主要任务是 构造正确的输入 使劲折腾系统却让它刚好不瘫痪 压力测试的一个变种是敏感测试 在某种情况下 微小的输入变动会导致系统的表现 如性能 发生急剧的变化 敏感测试目的是发现什么样的输入可能会引发不稳定现象 目标模拟出实际用户环境怎么用产生测试数据测试组模拟用户处理被创建的数据例子确定是否分配了足够的磁盘空间通讯的容量是否足够测试系统过载的情况什么时间使用当关于容量的信息不确定的时候 46 压力测试用例的参考模板 47 可靠性测试可靠性是指在一定的环境下 在给定的时间内 系统不发生故障的概率 由于软件不像硬件那样可以 加速老化 按此定义 软件可靠性测试可能会花费很长时间 比较实用的办法是 让用户使用该系统 记录每一次发生故障的时刻 计算出相邻故障的时间间隔 注意要去掉非工作时间 这样我们可以方便地统计出不发生故障的 最小时间间隔 最大时间间隔 和 平均时间间隔 其中 平均时间间隔 会让人们大体了解到系统 可靠 的程度 48 可靠性测试用例的参考模板 49 安装 反安装测试安装 反安装测试的目的 避免 大风浪都挺过来了 却在阴沟里翻了船 目前市面上有非常流行的 专门制作安装 反安装程序的一些工具 如InstallShelled 制作安装 反安装程序不再是件难事 关键是不要麻痹大意 主要测试工作 1 至少在标准配置和最低配置两种环境下测试 2 如果有安装界面 应当尝试各种选项 如选择 全部 部分 升级 等 50 安装 反安装测试用例的参考模板 51 WEB应用的测试 一 功能测试1 链接测试链接是Web应用系统的一个主要特征 它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段 链接测试可分为三个方面 首先 测试所有链接是否按指示的那样确实链接到了该链接的页面 其次 测试所链接的页面是否存在 最后 保证Web应用系统上没有孤立的页面 所谓孤立页面是指没有链接指向该页面 只有知道正确的URL地址才能访问 链接测试可以自动进行 现在已经有许多工具可以采用 链接测试必须在集成测试阶段完成 也就是说 在整个Web应用系统的所有页面开发完成之后进行链接测试 2 表单测试当用户给Web应用系统管理员提交信息时 就需要使用表单操作 例如用户注册 登陆 信息提交等 在这种情况下 我们必须测试提交操作的完整性 以校验提交给服务器的信息的正确性 例如 用户填写的出生日期与职业是否恰当 填写的所属省份与所在城市是否匹配等 如果使用了默认值 还要检验默认值的正确性 如果表单只能接受指定的某些值 则也要进行测试 例如 只能接受某些字符 测试时可以跳过这些字符 看系统是否会报错 52 3 Cookies测试Cookies通常用来存储用户信息和用户在某应用系统的操作 当一个用户使用Cookies访问了某一个应用系统时 Web服务器将发送关于用户的信息 把该信息以Cookies的形式存储在客户端计算机上 这可用来创建动态和自定义页面或者存储登陆等信息 如果Web应用系统使用了Cookies 就必须检查Cookies是否能正常工作 测试的内容可包括Cookies是否起作用 是否按预定的时间进行保存 刷新对Cookies有什么影响等 4 设计语言测试Web设计语言版本的差异可以引起客户端或服务器端严重的问题 例如使用哪种版本的HTML等 当在分布式环境中开发时 开发人员都不在一起 这个问题就显得尤为重要 除了HTML的版本问题外 不同的脚本语言 例如Java javascript ActiveX VBScript或Perl等也要进行验证 5 数据库测试在Web应用技术中 数据库起着重要的作用 数据库为Web应用系统的管理 运行 查询和实现用户对数据存储的请求等提供空间 在Web应用中 最常用的数据库类型是关系型数据库 可以使用SQL对信息进行处理 在使用了数据库的Web应用系统中 一般情况下 可能发生两种错误 分别是数据一致性错误和输出错误 数据一致性错误主要是由于用户提交的表单信息不正确而造成的 而输出错误主要是由于网络速度或程序设计问题等引起的 针对这两种情况 可分别进行测试 53 二 性能测试1 连接速度测试用户连接到Web应用系统的速度根据上网方式的变化而变化 他们或许是电话拨号 或是宽带上网 当下载一个程序时 用户可以等较长的时间 但如果仅仅访问一个页面就不会这样 如果Web系统响应时间太长 例如超过5秒钟 用户就会因没有耐心等待而离开 另外 有些页面有超时的限制 如果响应速度太慢 用户可能还没来得及浏览内容 就需要重新登陆了 而且 连接速度太慢 还可能引起数据丢失 使用户得不到真实的页面 2 负载测试负载测试是为了测量Web系统在某一负载级别上的性能 以保证Web系统在需求范围内能正常工作 负载级别可以是某个时刻同时访问Web系统的用户数量 也可以是在线数据处理的数量 例如 Web应用系统能允许多少个用户同时在线 如果超过了这个数量 会出现什么现象 Web应用系统能否处理大量用户对同一个页面的请求 54 3 压力测试负载测试应该安排在Web系统发布以后 在实际的网络环境中进行测试 因为一个企业内部员工 特别是项目组人员总是有限的 而一个Web系统能同时处理的请求数量将远远超出这个限度 所以 只有放在Internet上 接受负载测试 其结果才是正确可信的 进行压力测试是指实际破坏一个Web应用系统 测试系统的反映 压力测试是测试系统的限制和故障恢复能力 也就是测试Web应用系统会不会崩溃 在什么情况下会崩溃 黑客常常提供错误的数据负载 直到Web应用系统崩溃 接着当系统重新启动时获得存取权 压力测试的区域包括表单 登陆和其他信息传输页面等 55 三 可用性测试1 导航测试导航描述了用户在一个页面内操作的方式 在不同的用户接口控制之间 例如按钮 对话框 列表和窗口等 或在不同的连接页面之间 通过考虑下列问题 可以决定一个Web应用系统是否易于导航 导航是否直观 Web系统的主要部分是否可通过主页存取 Web系统是否需要站点地图 搜索引擎或其他的导航帮助 在一个页面上放太多的信息往往起到与预期相反的效果 Web应用系统的用户趋向于目的驱动 很快地扫描一个Web应用系统 看是否有满足自己需要的信息 如果没有 就会很快地离开 很少有用户愿意花时间去熟悉Web应用系统的结构 因此 Web应用系统导航帮助要尽可能地准确 导航的另一个重要方面是Web应用系统的页面结构 导航 菜单 连接的风格是否一致 确保用户凭直觉就知道Web应用系统里面是否还有内容 内容在什么地方 Web应用系统的层次一旦决定 就要着手测试用户导航功能 让最终用户参与这种测试 效果将更加明显 2 图形测试在Web应用系统中 适当的图片和动画既能起到广告宣传的作用 又能起到美化页面的功能 一个Web应用系统的图形可以包括图片 动画 边框 颜色 字体 背景 按钮等 图形测试的内容有 1 要确保图形有明确的用途 图片或动画不要胡乱地堆在一起 以免浪费传输时间 Web应用系统的图片尺寸要尽量地小 并且要能清楚地说明某件事情 一般都链接到某个具体的页面 2 验证所有页面字体的风格是否一致 3 背景颜色应该与字体颜色和前景颜色相搭配 4 图片的大小和质量也是一个很重要的因素 一般采用JPG或GIF压缩 56 3 内容测试内容测试用来检验Web应用系统提供信息的正确性 准确性和相关性 信息的正确性是指信息是可靠的还是误传的 例如 在商品价格列表中 错误的价格可能引起财政问题甚至导致法律纠纷 信息的准确性是指是否有语法或拼写错误 这种测试通常使用一些文字处理软件来进行 例如使用MicrosoftWord的 拼音与语法检查 功能 信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口 也就是一般Web站点中的所谓 相关文章列表 4 整体界面测试整体界面是指整个Web应用系统的页面结构设计 是给用户的一个整体感 例如 当用户浏览Web应用系统时是否感到舒适 是否凭直觉就知道要找的信息在什么地方 整个Web应用系统的设计风格是否一致 对整体界面的测试过程 其实是一个对最终用户进行调查的过程 一般Web应用系统采取在主页上做一个调查问卷的形式 来得到最终用户的反馈信息 对所有的可用性测试来说 都需要有外部人员 与Web应用系统开发没有联系或联系很少的人员 的参与 最好是最终用户的参与 57 四 客户端兼容性测试1 平台测试市场上有很多不同的操作系统类型 最常见的有Windows Unix Macintosh Linux等 Web应用系统的最终用户究竟使用哪一种操作系统 取决于用户系统的配置 这样 就可能会发生兼容性问题 同一个应用可能在某些操作系统下能正常运行 但在另外的操作系统下可能会运行失败 因此 在Web系统发布之前 需要在各种操作系统下对Web系统进行兼容性测试 2 浏览器测试浏览器是Web客户端最核心的构件 来自不同厂商的浏览器对Java javascript ActiveX plug ins或不同的HTML规格有不同的支持 例如 ActiveX是Microsoft的产品 是为InternetExplorer而设计的 javascript是Netscape的产品 Java是Sun的产品等等 另外 框架和层次结构风格在不同的浏览器中也有不同的显示 甚至根本不显示 不同的浏览器对安全性和Java的设置也不一样 测试浏览器兼容性的一个方法是创建一个兼容性矩阵 在这个矩阵中 测试不同厂商 不同版本的浏览器对某些构件和设置的适应性 58 五 安全性测试Web应用系统的安全性测试区域主要有 1 现在的Web应用系统基本采用先注册 后登陆的方式 因此 必须测试有效和无效的用户名和密码 要注意到是否大小写敏感 可以试多少次的限制 是否可以不登陆而直接浏览某个页面等 2 Web应用系统是否有超时的限制 也就是说 用户登陆后在一定时间内 例如15分钟 没有点击任何页面 是否需要重新登陆才能正常使用 3 为了保证Web应用系统的安全性 日志文件是至关重要的 需要测试相关信息是否写进了日志文件 是否可追踪 4 当使用了安全套接字时 还要测试加密是否正确 检查信息的完整性 5 服务器端的脚本常常构成安全漏洞 这些漏洞又常常被黑客利用 所以 还要测试没有经过授权 就不能在服务器端放置和编辑脚本的问题 59 测试工作中需要注意的问题 了解开发人员的测试心理测试的目的是找出尽可能多的缺陷 所以测试是 破坏性 的 而开发却是 建设性 的 开发人员总是喜欢欣赏程序的成功之处 而不愿看到失败之处 让开发者去做 蓄意破坏 的测试 就象杀自己的孩子一样难以接受 开发者对自己的程序印象深刻 并总以为是正确的 自信是应该的 倘若在设计时就存在理解错误 或因不良的编程习惯而流下了隐患 他本人很难发现这类错误 开发者对自己的程序的功能 接口十分熟悉 他自己几乎不可能因为使用不当而引发错误 这与大众用户的情况不太相似 所以测试自己的程序不具备典型性 结论 开发人员应当测试自己的程序 这是他分内的工作 但是开发人员在测试自己的程序时 很难做到客观 公正 所以自我测试不具有说服力 60 不同测试阶段的测试依据 人员 方式及内容接口与路径测试 功能测试 健壮性测试 性能测试 用户界面测试 安全性测试 压力测试 可靠性测试 安装 反安装测试 61 如何组织测试人员 应当视企业的人力资源而定条件特别好的公司 可以为每一个开发人员分配一名独立的测试人员 这样的测试人员职业化程度很高 可以完成单元测试 集成测试和系统测试工作 能够实现开发与测试同步进行 条件比较好的公司 可以设置一个独立的测试小组 该测试小组轮流参加各个项目的系统测试 而单元测试 集成测试工作由项目的开发小组承担 条件一般的公司 养不起独立的测试小组 单元测试 集成测试工作由项目开发小组承担 当项目进展到系统测试阶段 可以从项目外抽调一些人员 加上开发人员 临时组织系统测试小组 条件比较差的公司 也许只有一个项目和为数不多的一些开发人员 那么就让开发人员一直兼任测试人员的角色 相互测试对方的程序 如果人员实在太少了 只好让开发者测试自己的程序 有测试总比没有测试好吧 62 避免开发人员与测试人员产生矛盾开发人员不能很好地测试自己的程序是因为做不到 无情 但如果测试人员真的做到了 无情 却会引起开发人员的愤怒 遭人白眼 由于开发与测试存在 对立 关系 开发人员与测试人员很容易产生矛盾 这对项目而言是一种伤害 开发人员的注意事项 1 不要敌视测试人员 要理解测试的目的就是发现缺陷 是测试人员的工作职责 不要以为测试人员吃饱了没事干 存心找茬 2 不要轻视测试人员 别说人家技术水平差 不配搞开发只好搞测试 测试人员的注意事项 1 发现缺陷时不要嘲笑开发人员 别说他的程序真臭 到处是Bug 2 在开发人员压力太大时或心情不好时不要火上浇油 发现缺陷时别大声嚷嚷 3 不要相互指责 嘲讽 抱怨对方 尽量不要相互讽刺对方 例如 A对B说 你唯一的特点就是无能 B对A说 你唯一的特点就是粗鲁 还要注意的是 如果测试人员与开发人员的关系非常好 可能会导致在测试的时候 手下留情 这对项目也是一种伤害 63 企业的测试策略 理念 企业的主要目的是获取利润 降低测试成本也是盈利的一种方式 用较低的代价实现有效的测试 不应为了追求完美的测试而不失一切代价 如何合理地减少测试工作量减少冗余的测试白盒测试与黑盒测试的方式虽然不同 但往往有 异曲同工 之妙 在很多地方 白盒测试与黑盒测试会产生一模一样的效果 或者能推理出来 这样的测试是冗余的 在集成测试 系统测试阶段 可能要执行多次 回归测试 每一次 回归测试 都会存在不少的冗余 应当设法剔除不必要的重复测试工作 减少无价值的测试无价值的测试通常是由于不懂得测试技术引起的 例如功能测试 在等价区间之中 本来只要测试一个典型的输入就行了 如果有人在此区间测试了100次 那么其中99次就是无价值的 如何 偷工减料 有一些 短 平 快 的项目 经费本来就少 用户对质量要求也马马虎虎 为了能多挣一点钱 开发方不得不采用 偷工减料 的方式来降低测试代价 偷工减料的途径无非就是减少测试的内容和频度 但不能砍得太狠 否则软件拿不出手 基本方法是找出软件中需要优先测试的部分 其它次要部分可以忽略或将来再测试 64 偷工减料 方法的测试优先级 哪些功能是软件的特色 哪些功能是用户最常用的 如果系统可以分块卖的话 哪些功能块在销售时最昂贵 哪些功能出错将导致用户不满或索赔 哪些程序是最复杂 最容易出错的 哪些程序是相对独立 应当提前测试的 哪些程序最容易扩散错误 哪些程序是全系统的性能瓶颈所在 哪些程序是开发者最没有信心的 65 测试何时结束 一 基于测试用例的规则先构造测试用例 并请有关人员进行评审 在测试过程中 当测试用例的不通过率达到20 时 则拒绝继续测试 待开发人员修正软件后再进行测试 当功能性测试用例通过率达到100 非功能性测试用例通过率达到90 时 允许正常结束测试 该规则的优点是适用于所有的测试阶段 缺点是太依赖于测试用例 如果测试用例非常糟糕 那么该规则就失效了 二 基于 测试期缺陷密度 的规则把测试一个CPU小时发现的缺陷数称为 测试期缺陷密度 绘制 测试时间 缺陷数 的关系图 如果在相邻n个CPU小时内 测试期缺陷密度 全部低于某个值m时 则允许正常结束测试 例如n大于10 m小于等于1 该规则比较适用于系统测试阶段 三 基于 运行期缺陷密度 的规则把软件运行一个CPU小时发现的缺陷数称为 运行期缺陷密度 绘制 运行时间 缺陷数 的关系图 如果在相邻n个CPU小时内 运行期缺陷密度 全部低于某个值m时 则允许正常结束测试 例如n大于100 m小于等于1 该规则比较适用于验收测试阶段 即客户试运行软件期间 66 需求经常变更怎么办需求变更可能会让项目所有