培训教材—软测试基础PPT课件.ppt

软件测试基础知识 1 课程内容 软件测试背景什么是软件测试软件测试的流程软件测试工具 RationalTest 2 课程目标 了解软件测试工程师的职业要求及特点掌握软件测试的基本概念熟悉常用的软件测试类型熟悉软件测试的工作流程和阶段划分了解软件自动化测试理解软件测试与软件开发的相互关系 3 你以前接触过软件测试工作么 你认为软件测试人员是做什么的 小插曲 4 英特尔奔腾CPU计算机芯片被发现有浮点除法软件缺陷 1994英特尔的1 13MHZ奔腾III处理器可能导致运行程序被挂起 计算机生产商召回已经交付用户的PC机 2000 臭名昭著的软件错误案例 5 爱国者导弹防御系统一个小的系统时钟错误 导致在多哈袭击战中 系统被拖延100多个小时 1991美国航天局火星极地登陆由于确定何时关闭推进器的程序中某一个数据位被以外修改 飞船在试图登陆火星表面失踪 1999 臭名昭著的软件错误案例 6 软件未达到产品设计规范表明的功能 软件出现了产品设计规范指明不会出现的错误 软件功能超出产品设计规范指明的范围 软件未达到产品设计规范虽未指出但应达到的目标 软件测试人员认为软件难以理解 不易使用 运行速度慢 或者最终用户认为不好 什么是软件缺陷 7 为什么会出现软件缺陷 8 软件缺陷的修复费用 9 软件测试人员究竟做些什么 目标 尽可能早的发现软件缺陷 并确保其得以修复 10 小插曲 大家有愿意做测试工作的么 不愿意的原因 A 测试工作太枯燥 B 测试工作不需要什么技术 只有技术水平低的人才去做 C 测试工作没有创造性 我喜欢有创造的开发工作 D 做测试工作 发展空间不大 选择比较少 E 测试人员工资比开发人员低F 其它 11 优秀的软件测试人员应该具备的素质 软件测试员的一个基本素质是 打破沙锅问到底软件测试员应具备的素质 1 探索精神 软件测试员不会害怕进入陌生环境 2 故障排除能手 软件测试员善于发现问题的症结 喜欢猜谜 3 不懈努力 软件测试员总是不停尝试 他们可能会碰到转瞬即逝或者难以重建的软件缺陷 他们不会心存侥幸 而是尽一切可能去寻找 12 优秀的软件测试人员应该具备的素质 4 创造性 想出富有创意甚至超常的手段来寻找软件缺陷 5 追求完美 他们力求完美 但是知道某些无法企及时 不去苛求 而是尽力接近目标 6 判断准确 软件测试员要决定测试内容 测试时间 以及看到的问题是否算作真正的缺陷 7 老练稳重 软件测试员不害怕坏消息 8 说服力 软件测试员要善于表达观点 表明软件缺陷为何必须修复 并通过实际演示力陈诉观点 13 怎样成为优秀的软件测试人员 软件测试工程师 14 软件测试人员的发展阶段和机会 初级软件测试工程师 软件测试工程师 项目软件测试经理 测试经理 项目经理 高级软件测试工程师 系统工程师 15 测试工作太枯燥 没有创造性 测试工作枯燥 喜欢看推理侦探小说么 测试的过程其实也和推理破案的过程一样的有趣 当进行了严密的推理终于发现一个大缺陷后 会很有成就感 没有创造性 测试也需要创造 新的测试方法 新的自动化测试工具 创造机会很多 16 成功的秘密 强烈的动机 坚定的信念 做三件事 强烈的愿望 确定的目标我最想做什么样的人 我一定要做得最好 坚信我的选择是正确的我要坚持不懈 做别人不去做的事做别人不敢去做的事做别人做不到的事 17 课程内容 软件测试背景什么是软件测试 软件测试的流程测试用例及其设计方法软件测试工具 RationalTest 18 你对软件测试的理解 小插曲 19 对软件测试的错误理解 如果发布出去的软件有质量问题 那是软件测试人员的错 软件测试技术要求不高 至少比编程容易多了 软件测试是测试人员的事 与开发人员无关 设计 实现 测试 软件测试是开发后期的一个阶段 测试出没有故障 说明我们的软件没有缺陷 20 什么是软件测试 软件测试的定义软件测试的对象软件测试的目的软件测试分类和比较软件测试的内容 21 软件测试的定义 软件测试 Softwaretesting 是软件生存期中的一个重要阶段 是软件质量保证的关键步骤 通俗地讲 软件测试就是在软件投入运行前 对软件需求分析 设计规格说明和编码进行最终复审的活动 1983年IEEE提出的软件工程术语中给软件测试下的定义是 使用人工或自动的手段来运行或测定某个软件系统或系统部件的过程 其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别 22 软件测试的对象 软件测试不等于程序测试 软件测试贯穿于软件定义和开发的整个期间 需求分析 概要设计 详细设计 以及程序编码等各个阶段所得到的文档 包括需求规格说明 概要设计规格说明 详细设计规格说明以及源程序 都是软件测试的对象 23 软件测试的对象 24 软件测试的目的 基于不同的立场 存在着两种完全不同的测试目的 从用户 测试人员 的角度出发 普遍希望通过软件测试暴露软件中隐藏的错误和缺陷 以考虑是否可接受该产品 从软件开发者的角度出发 则希望测试成为表明软件产品中不存在错误的过程 验证该软件已正确地实现了用户的要求 确立人们对软件质量的信心 25 软件测试的目的 想以最少的时间和人力 系统地找出软件中潜在的各种错误和缺陷 如果我们成功地实施了测试 我们就能够发现软件中的错误 测试的附带收获是 它能够证明软件的功能和性能与需求说明相符合 实施测试收集到的测试结果数据为可靠性分析提供了依据 测试不能表明软件中不存在错误 它只能说明软件中存在错误 26 软件测试的原则 测试的目的在于发现错误 应尽早地和不断地进行测试充分注意测试中的群集现象经验表明 测试后程序中残存的错误数目与该程序中已发现的错误数目成正比 所有的测试都应可追溯到客户需求穷举测试是不可能的严格执行测试计划 排除测试的随意性 应当对每一个测试结果做全面检查 妥善保存测试计划 测试用例 出错统计和最终分析报告 为维护提供方便 27 软件测试的分类 28 软件测试的分类 29 软件测试的分类与比较 测试方式白盒测试 关心软件内部设计和程序实现 主要测试依据是设计文档黑盒测试 不关心软件内部 只关心输入输出 主要测试依据是需求文档 30 软件测试的分类与比较 黑盒测试与白盒测试的比较 31 软件测试的分类与比较 测试阶段单元测试 集成测试 系统测试 验收测试 是 从小到大 由内至外 循序渐进 的测试过程 体现了 分而治之 的思想 单元测试的粒度最小 一般由开发小组采用白盒方式来测试 主要测试单元是否符合 设计 集成测试界于单元测试和系统测试之间 起到 桥梁作用 一般由开发小组采用白盒加黑盒的方式来测试 既要验证 设计 又要验证 需求 系统测试的粒度最大 一般由独立测试小组采用黑盒方式来测试 主要测试系统是否符合 需求规格说明书 验收测试与系统测试非常相似 主要区别是测试人员不同 验收测试由用户执行 32 软件测试的内容 测试内容接口与路径测试 功能测试 健壮性测试 性能测试 用户界面测试 安全性测试 压力测试 可靠性测试 安装 反安装测试 33 回顾一下 软件测试人员的目标软件测试的对象软件测试的目的软件测试的分类软件测试的内容 34 回头再看看对软件测试的错误理解 如果发布出去的软件有质量问题 那是软件测试人员的错 测试有助于提高软件的质量 但高质量的软件不是测试出来的 软件测试技术要求不高 至少比编程容易多了 好的测试人员不仅要掌握各种测试技术 还要具备丰富的编程经验和对BUG的敏感 测试的复杂之处 除了测试技术问题之外 还有测试管理问题 35 回头再看看对软件测试的错误理解 开发人员参与的测试有单元测试和集成测试 软件测试是测试人员的事 与开发人员无关 设计 实现 测试 软件测试是开发后期的一个阶段 测试出没有故障 说明我们的软件没有缺陷 测试是贯穿与软件项目的整个过程应该尽早开始测试 测试只能说明故障存在 不能说明故障不存在 36 课程内容 软件测试背景什么是软件测试 软件测试的流程测试用例及其设计方法软件测试工具 RationalTest 37 LifeCycleTesting测试生命周期 UserRequirement softwareRequirement Design ProgramUnitDesign Coding UnitTesting IntegrationTesting SystemTesting AcceptanceTesting Prepareplan Verify Prepareplan Verify Prepareplan Verify 38 Plan Analysis Design Coding Test Deliver TestCaseDesign TestDevelopment TestPlanning TestExecution Evaluation SpiralTestingProcess 39 InformationGathering TestPlanning TestCaseDesign TestDevelopment TestEvaluation Execution PrepareforNextSpiral System AcceptanceTesting SummaryReport plan do check act Steps interimreports Iterative SpiralTestingProcess 40 测试的文档 测试计划 指明范围 方法 资源 以及相应测试活动的时间进度安排表的文档 测试方案 指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档 测试用例 指明为完成一个测试项的测试输入 预期结果 预期执行条件等因素的文档 测试规程 指明执行测试时测试活动序列的文档 测试报告 指明执行测试结果的文档 41 课程内容 软件测试背景什么是软件测试 软件测试的流程测试用例及其设计方法软件测试工具 RationalTest 42 什么是测试用例 所谓的测试用例就是将软件测试的行为活动 做一个科学化的组织归纳 软件测试是有组织性 步骤性和计划性的 而设计软件测试用例的目的 就是为了能将软件测试的行为转换为可管理的模式 软件测试是软件质量管理中最实际的行动 同时也是耗时最多的一项 基于时间因素的考虑 软件测试行为必须能够加以量化 才能进一步让管理阶层掌握所需要的测试过程 而测试用例就是将测试行为具体量化的方法之一 43 不同阶段的测试用例 44 测试用例的基本要素 目的前提条件输入数据或动作期望的响应各种环境设置对应的需求 45 测试用例内容 实施一次测试而向被测系统提供的输入数据 操作或各种环境设置 对交互式系统 软件交互执行过程的控制也是一种测试用例 测试用例的设计与生成是依据测试大纲对其中每个测试项目的进一步实例化 比如 对于一个输入项的测试 应当设计一组测试数据 包括合法的 边界的和非法的数据等 46 测试用例设计的基本准则 测试用例的代表性 能够代表并覆盖各种合理的和不合理 合法的和非法的 边界的和越界的 以及极限的输入数据 操作和环境设置等 测试结果的可判定性 即测试执行结果的正确性是可判定的 每一个测试用例都应有相应的期望结果 测试结果的可再现性 即对同样的测试用例 系统的执行结果应当是相同的 47 黑盒测试用例的设计方法 具体的黑盒测试用例设计方法包括等价类划分法 边界值分析法 场景法 错误推测法 因果图法 判定表驱动法 正交试验设计法 功能图法等 这些方法是比较实用的 但采用什么方法 在使用时自然要针对开发项目的特点对方法加以适当的选择 48 等价类划分法 等价类划分 是一种典型的黑盒测试方法 用这一方法设计测试用例完全不考虑程序的内部结构 只根据对程序的需求和说明 即需求规格说明书 由于穷举测试工作量太大 以致于无法实际完成 促使我们在大量的可能数据中选取其中的一部分作为测试用例 49 等价类划分法 假设一个程序P有输入量X和Y及输出量Z 在字长为32位的计算机上运行 若X Y取整数 按黑盒方法进行穷举测试 可能采用的测试数据组 232 232 264如果测试一组数据需要1毫秒 一年工作365 24小时 完成所有测试需5亿年 50 等价类划分法 等价类划分法是把程序的输入域划分成若干部分 然后从每个部分中选取少数代表性数据当作测试用例 每一类的代表性数据在测试中的作用等价于这一类中的其他值 也就是说 如果某一类中的一个例子发现了错误 这一等价类中的其他例子也能发现同样的错误 反之 如果某一类中的一个例子没有发现错误 则这一类中的其他例子也不会查出错误 51 划分等价类和列出等价类表 把全部输入数据合理划分为若干等价类 在每一个等价类中取一个数据作为测试的输入条件 就可以用少量代表性的测试数据取得较好的测试结果 等价类划分有两种不同的情况 有效等价类 是指对于程序的规格说明来说是合理的 有意义的输入数据构成的集合 利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能 无效等价类 与有效等价类的定义恰巧相反 52 建立等价类表 在确立了等价类之后 建立等价类表 列出所有划分出的等价类 53 确定测试用例 根据已列出的等价类表 按以下步骤确定测试用例 为每个等价类规定一个唯一的编号 设计一个新的测试用例 使其尽可能多地覆盖尚未覆盖的有效等价类 重复这一步 最后使得所有有效等价类均被测试用例所覆盖 设计一个新的测试用例 使其只覆盖一个无效等价类 重复这一步使所有无效等价类均被覆盖 54 举例 根据下面给出的规格说明 利用等价类划分的方法 给出足够的测试用例 一个程序读入3个整数 把这三个数值看作一个三角形的3条边的长度值 这个程序要打印出信息 说明这个三角形是不等边的 是等腰的 还是等边的 55 举例 我们可以设三角形的3条边分别为A B C 如果它们能够构成三角形的3条边 必须满足 A 0 B 0 C 0 且A B C B C A A C B 如果是等腰的 还要判断A B 或B C 或A C 如果是等边的 则需判断是否A B 且B C 且A C 56 举例 57 举例 58 边界值分析法 由测试工作的经验得知 大量的错误是发生在输入或输出范围的边界上 而不是在输入范围的内部 因此针对各种边界情况设计测试用例 可以查出更多的错误 边界值分析是一种补充等价划分的测试用例设计技术 它不是选择等价类的任意元素 而是选择等价类边界的测试用例 实践证明为检验边界附近的处理专门设计测试用例 常常取得良好的测试效果 59 边界值设计原则 对边界值设计测试用例 应遵循以下几条原则 如果输入条件规定了值的范围 则应取刚达到这个范围的边界的值 以及刚刚超越这个范围边界的值作为测试输入数据 如果输入条件规定了值的个数 则用最大个数 最小个数 比最小个数少一 比最大个数多一的数作为测试数据 如果程序的规格说明给出的输入域或输出域是有序集合 则应选取集合的第一个元素和最后一个元素作为测试用例 分析规格说明 找出其他可能的边界条件 60 其他一些边界条件 另一种看起来很明显的软件缺陷来源是当软件要求输入时 比如在文本框中 不是没有输入正确的信息 而是根本没有输入任何内容 单单按了Enter键 这种情况在产品说明书中常常忽视 程序员也可能经常遗忘 但是在实际使用中却时有发生 正确的软件通常应该将输入内容默认为合法边界内的最小值或者合法区间内某个合理值 否则返回错误提示信息 61 场景法 现在的软件几乎都是用事件触发来控制流程的 事件触发时的情景便形成了场景 而同一事件不同的触发顺序和处理结果就形成事件流 这种在软件设计方面的思想也可引入到软件测试中 可以比较生动地描绘出事件触发时的情景 有利于测试设计者设计测试用例 同时使测试用例更容易理解和执行 62 场景法 提出这种测试思想的是Rational公司 并在RUP2000 RationalUnifiedProcess 中文版当中有其详尽的解释和应用 用例场景用来描述流经用例的路径 从用例开始到结束遍历这条路径上所有基本流和备选流 63 基本流和备选流 右图中经过用例的每条路径都用基本流和备选流来表示 直黑线表示基本流 是经过用例的最简单的路径 备选流用不同的彩色表示 一个备选流可能从基本流开始 在某个特定条件下执行 然后重新加入基本流中 如备选流1和3 也可能起源于另一个备选流 如备选流2 或者终止用例而不再重新加入到某个流 如备选流2和4 64 基本流和备选流 按照上图中每个经过用例的路径 可以确定以下不同的用例场景 场景1基本流场景2基本流备选流1场景3基本流备选流1备选流2场景4基本流备选流3场景5基本流备选流3备选流1场景6基本流备选流3备选流1备选流2场景7基本流备选流4场景8基本流备选流3备选流4注 为方便起见 场景5 6和8只考虑了备选流3循环执行一次的情况 65 测试方法选择的综合策略 以下是各种测试方法选择的综合策略 可在实际应用过程中参考 首先进行等价类划分 包括输入条件和输出条件的等价划分 将无限测试变成有限测试 这是减少工作量和提高测试效率的最有效方法 在任何情况下都必须使用边界值分析方法 经验表明用这种方法设计出测试用例发现程序错误的能力最强 66 测试方法选择的综合策略 对照程序逻辑 检查已设计出的测试用例的逻辑覆盖程度 如果没有达到要求的覆盖标准 应当再补充足够的测试用例 对于业务流清晰的系统 可以利用场景法贯穿整个测试案例过程 在案例中综合使用各种测试方法 67 课程内容 软件测试背景