软件测试基础和入门.ppt

软件测试基础 2 软件测试的作用软件测试的目的软件缺陷的定义引起软件缺陷的因素软件测试面临的挑战软件测试模型软件测试与开发各阶段的关系软件测试过程软件测试公理软件测试的原则软件测试的对象 软件测试的基本知识 3 软件设计与编码过程是引入缺陷的过程 而软件测试是排除软件缺陷的过程 测试不能保证软件的质量 力图通过测试提高软件的质量如同经常称体重来达到减肥的目的 如果你想减肥 不要买一个新称 而是节食 如果你想提高你软件质量的话 不是更多的测试 而是更好的开发 SteveMcConnellinCodeComplete 软件测试的作用 4 基于不同的立场 存在着两种完全不同的测试目的 从用户的角度出发 普遍希望通过软件测试暴露软件中隐藏的错误和缺陷 以考虑是否可接受该产品 从软件开发者的角度出发 则希望测试成为验证该软件已正确地实现了用户的要求 确立人们对软件质量的信心 软件测试的目的 1 5 使用人工或自动手段来运行或测定某个系统的过程 其目的在于检验它是否满足规定的需求 或是确认预期结果与实际结果之间的差别 测试的目的是检验软件是否满足了要求 IEEE软件工程标准术语 程序测试是证明程序中不存在错误的过程 测试是程序的执行过程 目的在于发现错误 一个好的测试用例在于能发现至今未发现的错误 一个成功的测试是发现了至今未发现的错误的测试 软件测试的目的 2 6 软件缺陷的正式定义 几个关于缺陷的术语 错误 Error Mistake缺陷 Defect Bug故障 Fault失效 Failure基本上所有软件问题都称为缺陷 7 软件缺陷的正式定义 软件未达到产品说明书表明的功能软件出现了产品说明书指明不会出现的错误软件功能超出产品说明书指明范围软件未达到产品说明书虽未指出但应达到的目标软件测试人员认为软件难以理解 不易使用 运行速度缓慢 或者最终用户认为不好 8 引起软件缺陷的因素 交流不够 交流上有误解或者根本不进行交流 在应用应该做什么或不应该做什么的细节 应用的需求 不清晰的情况下进行开发 软件复杂性 图形用户界面 GUI 客户 服务器结构 分布式应用 数据通信 超大型关系型数据库以及庞大的系统规模 使得软件及系统的复杂性呈指数增长 没有现代软件开发经验的人很难理解它 程序设计错误 像所有的人一样 程序员也会出错 9 引起软件缺陷的因素 需求变化 需求变化的影响是多方面的 客户可能不了解需求变化带来的影响 也可能知道但又不得不那么做需求变化的后果可能是造成系统的重新设计 设计人员的日程的重新安排 已经完成的工作可能要重做或者完全抛弃 对其他项目产生影响 硬件需求可能要因此改变 等等 如果有许多小的改变或者一次大的变化 项目各部分之间已知或未知的依赖性可能会相互影响而导致更多问题的出现 需求改变带来的复杂性可能导致错误 还可能影响工程参与者的积极性 10 引起软件缺陷的因素 时间压力 软件项目的日程表很难做到准确 很多时候需要预计和猜测 当最终期限迫近和关键时刻到来之际 错误也就跟着来了 开发人员的过分自信 没问题 这事情很容易 几个小时我就能拿出来 太多不切实际的 没问题 结果只能是引入错误代码文档贫乏 贫乏或者差劲的文档使得代码维护和修改变的异常艰辛 其结果是带来许多错误 事实上 在许多机构并不鼓励其程序员为代码编写文档 也不鼓励程序员将代码写得清晰和容易理解 相反他们认为少写文档可以更快的进行编码 无法理解的代码更易于工作的保密 写得艰难必定读的痛苦 11 当前软件测试面临的挑战 软件测试认识的误区 软件开发完成后进行软件测试软件发布后如果发现质量问题 那是软件测试人员的错软件测试要求不高 随便找个人都行软件自动测试效率高 将取代软件手工测试软件测试是测试人员的事情 与程序员无关项目进度吃紧时少做些测试 时间富裕时多做测试软件测试是没有前途的工作 只有程序员才是软件高手使用了测试工具 就是进行了有效的测试存在太多的无法测试的东西测试代码可以随意写单元测试和系统测试没有什么区别测试具有免疫性 12 设计 实现 测试 软件测试是开发后期的一个阶段 实际上 软件测试贯穿整个软件产品生命期 一方面 软件测试也要经历测试计划 测试用例的设计和实现 以及测试运行一系列的阶段 因此 早在软件需求阶段 甚至更早 软件测试的工作就要开始了 另一方面 软件测试越早进行越好 因为BUG越早发现 BUG造成的影响和修改的代价就越小 而且 软件测试并不仅仅针对程序 软件的需求 设计等等也要被测试 对测试工作的误解 13 测试是 泛型概念 全程测试 如果单纯的只将程序设计阶段后的阶段称之为软件测试的话 需求阶段和设计阶段的缺陷产生的放大效应会加大 这非常不利于保证软件质量 需求缺陷 设计缺陷也是软件缺陷 记住 软件缺陷具有生育能力 软件测试应该跨越整个软件开发流程 需求验证 自检 和设计验证 自检 也可以算作软件测试 建议称为 需求测试和设计测试 的一种 软件测试应该是一个泛型概念 涵盖整个软件生命周期 这样才能确保周期的每个阶段禁得起考验 同时测试本身也需要有第三者进行评估 信息系统审计和软件工程监理 即测试本身也应当被测试 从而确保测试自身的可靠性和高效性 否则自身不正 难以服人 另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件 软件测试是提高产品质量最直接 最快捷的手段 但决不是一个根本手段 对测试工作的误解 14 如果发布出去的软件有质量问题 那是软件试人员的错 软件的质量是 做 出来的 而不是 测 出来的7 软件测试技术要求不高 比编程容易多了 很多人认为软件测试就是运行一下软件 然后看看结果对不对 但实际上 如何在有限的投入下 提高软件测试的效率和产出是一件很见功底的事情 所以 好的测试人员不仅要掌握各种测试技术和测试工具 还要具备丰富的编程经验和对BUG的敏感 另外 测试统计技术也是一项很特别的技术 对测试工作的误解 15 8 使用了测试工具 就是进行了有效的测试 有效测试的前提条件是 该软件或者模块应该是可测试的 即 是强内聚 弱耦合 接口明确 意图明晰的软件 要想真正获取测试带来的巨大好处 并且使得测试工具能够发挥最大的效率 关键就是要使软件本身具有很好的可测试性 对于测试工具的选择 只要满足需要并能够自动运行测试用例就可以了 对测试工作的误解 16 9 存在太多的无法测试的东西确实存在一些东西看起来要比另外一些东西难测试一些 但是远非无法测试由于被测试的软件本身在设计时没有考虑到可测试性的问题这种不可测试性不是由于被测试的软件内部的过紧耦合造成的 而是和外部某些很难测试的部分耦合过紧 对测试工作的误解 17 10 测试代码可以随意写大家肯定知道测试代码是不能随意编写的 并且在编写测试代码时也不是抱着一种随意的态度 但是你编写出来的测试代码以及测试代码运行的情况却表现出了一种随意性和无序性 因为你可能并没有弄清楚测试的真正意图所在 对测试工作的误解 18 11 单元测试和系统测试没有什么区别以建筑为例单元测试可以类比为一个建筑的质检人员对建筑进行的检测 他关注的重点是建筑的内部结构 地基 框架以及墙壁是否垂直等 他的检测是要保证建筑的各个部分是正常的 安全的 换句话说 就是要保证施工满足建筑上面的质量标准 系统测试可以类比为建筑的使用者来对建筑进行的检测 首先 他认为这个建筑是满足规定的工程质量的 这是有建筑的质检人员来保证的 使用者关注的重点是住在这个建筑的中的感受 他关心建筑的外观是否美观 各个房间的大小是否合适 窗户的位置是否合适 是否能够满足家庭的需要等 对测试工作的误解 19 单元测试和系统测试之间的明确划分 没有一个通用的标准 只有通过自己的不断实践来增加这方面的经验如果一个单元测试要跨越类的边界 那么它可能应该是一个系统测试如果一个单元测试变的非常复杂 那么它可能应该是一个系统测试如果一个单元测试经常要随着用户需求的变化而改变 那么它可能应该是一个系统测试如果一个单元测试比它要测试的代码本身要难以编写 那么它可能应该是一个系统测试 对测试工作的误解 20 对测试工作的误解 13 测试具有免疫性 软件缺陷免疫性 软件缺陷与病毒一样具有可怕的 免疫性 测试人员对其采用的测试越多 其免疫能力就越强 寻找更多软件缺陷就更加困难 由数学上的概率论我们可以推出这一结论 假设一个50000行的程序中有500个软件缺陷并且这些软件错误分布时均匀的 则每100行可以找到一个软件缺陷 我们假设测试人员用某种方法花在查找软件缺陷的精力为X小时 100行 21 照此推算 软件存在500个缺陷时 我们查找一个软件缺陷需要X小时 当软件只存在5个错误时 我们每查找一个软件缺陷需要100X小时 实践证明 实际的测试过程比上面的假设更为苛刻 为此我们必须更换不同的测试方式和测试数据 该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷 因此软件测试应该尽可能的多采用多种途径进行测试 对测试工作的误解 22 软件测试的衡量标准 需求的覆盖需求追溯表 需求矩阵缺陷数量多 新缺陷重现率BUG能按照一定的测试过程稳定重现效率平均每人天发现的BUG数 5个 人天 成本少 合理的测试人力和软 硬件资源安排重用价值测试的数据或者样例可以重用 23 软件测试模型软件测试与开发各阶段的关系 软件工程相关概念 24 软件生存期的瀑布模型和软件工程过程 软件工程相关概念 25 软件测试模型 软件测试是与软件开发紧密相关的一系列有计划的系统性的活动 显然软件测试也需要测试模型去指导实践 主要介绍两个模型 V模型W模型 26 V模型 V模型是最具有代表意义的测试模型 V模型是软件开发瀑布模型的变种 它反映了测试活动与分析和设计的关系 从左到右 描述了基本的开发过程和测试行为 非常明确地标明了测试过程中存在的不同级别 并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 箭头代表了时间方向 左边下降的是开发过程各阶段 与此相对应的是右边上升的部分 即各测试过程的各个阶段 27 V模型 28 W模型 V模型存在一定的局限性 它仅仅把测试过程作为在需求分析 概要设计 详细设计及编码之后的一个阶段 容易使人理解为测试是软件开发的最后的一个阶段 主要是针对程序进行测试寻找错误 而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现 在V模型中增加软件各开发阶段应同步进行的测试 被演化为一种W模型 开发是 V 测试也是与此相重叠的 V W模型体现了 尽早地和不断地进行软件测试 的原则 29 W模型 30 W模型 相比于V模型 W模型更科学 W模型可以说是前者自然而然的发展 它强调 测试伴随着整个软件开发周期 而且测试的对象不仅仅是程序 需求 功能和设计同样要测试 测试与开发是同步进行的 从而有利于尽早地发现问题 以需求为例 需求分析一完成 我们就可以对需求进行测试 而不是等到最后才进行针对需求的验收测试 测试不仅仅是评定软件的质量 测试还可以尽可能早地找出缺陷所在 从而帮助改进项目内部的质量 31 其他开发模型 迭代增量模型 螺旋迭代模型 32 验收测试计划 系统测试计划 软件集成测试计划 交付 各测试阶段的信息依据 软件测试与开发各阶段的关系 1 33 软件开发过程是一个自顶向下 逐步细化的过程软件计划阶段定义软件作用域软件需求分析建立软件信息域 功能和性能需求 约束等软件设计把需求转化为程序逻辑流程编码把设计用某种程序设计语言转换成程序代码 软件测试与开发各阶段的关系 2 34 测试过程是依相反顺序安排的自底向上 逐步集成的过程 软件测试与开发各阶段的关系 3 35 软件测试过程 测试计划测试设计测试开发测试执行测试评估 36 软件测试过程 37 测试信息流 1 38 软件配置 软件需求规格说明 软件设计规格说明 源代码等 测试配置 测试计划 测试用例 测试程序等 测试工具 测试数据自动生成程序 静态分析程序 动态分析程序 测试结果分析程序 以及驱动测试的测试数据库等等 测试信息流 2 39 测试结果分析 比较实测结果与预期结果 评价错误是否发生 排错 调试 对已经发现的错误进行错误定位和确定出错性质 并改正这些错误 同时修改相关的文档 修正后的文档再测试 直到通过测试为止 测试信息流 3 40 通过收集和分析测试结果数据 对软件建立可靠性模型利用可靠性分析 评价软件质量 软件的质量和可靠性达到可以接受的程度 所做的测试不足以发现严重的错误 如果测试发现不了错误 可以肯定 测试配置考虑得不够细致充分 错误仍然潜伏在软件中 测试信息流 4 41 测试只能证明错误的存在 而不能表明程序中没有错误 测试的两个作用是 确定程序中缺陷的存在 有助于判断该程序在实际上是否可用 软件测试最困难的问题之一是知道何时停止测试 Whentostoptesting 自己测试自己的程序是不可能的 当一个软件被测出的缺陷数目增加时 更多的未被发现的缺陷存在的概率也随之增加 并非所有的软件缺陷都能修复 程序测试的过程具有破坏性 软件测试公理 1 42 一个好的测试用例应当是一个对以前未被发现的缺陷有高发现率的用例 而不是一个表明程序工作正确的用例 要对有效的和无效的输入状况写测试用例 测试用例要兼顾有效与无效的输入 测试用例应由测试输入数据和对应的预期输出结果这两部分组成 像做其它事情一样 测试在其一开始就必须要有一个目标 完全测试程序是不可能的 软件测试是有风险的行为 测试无法显示潜伏的软件缺陷 软件测试公理 2 43 软件测试最困难的问题之一是知道何时停止测试 发版决策依据 Whentostoptesting 每天不超过5个缺陷 没有CriticalBug 计划发版日期 市场需求 软件测试公理分析 1 44 完全测试程序是不可能的 输入量太大输出结果太多软件实现途径太多软件说明书没有客观标准 从不同的角度看 软件缺陷的标准不同 软件测试公理分析 2 45 软件测试是有风险的行为 如果决定不去测试软件所有可能的情况 那就是选择了风险 但是在上一条公理中指出 完全测试程序是不可能的 在这种情况下 又不能全部测试 不测试又会漏掉软件缺陷 怎么办 软件测试员要学会的一个主要的原则就是如何把无边际的软件出现的可能情况减少到可以控制的范围 以及如何针对风险制作出明智的抉择去粗存精 软件测试公理分析 3 46 测试无法显示潜伏的软件缺陷 软件测试工作与防疫员的工作级为相似 可以报告已发现的软件缺陷 却无法报告潜伏的软件缺陷 你可以进行测试 查找并报告软件缺陷 但是不能保证软件缺陷全部找到 唯一的办法就是继续测试 多测试 软件测试公理分析 4 47 找到的软件缺陷越多 说明软件缺陷越多 其中的原因是 程序员怠倦程序员往往范同样的错误某些软件缺陷实际上是大灾难的征兆 软件测试公理分析 5 48 并非所有的软件缺陷都能修复 没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复设计不好 软件设计耦合性太强 牵一而发动全身技术上解决不了 人的能力 开发工具 软硬件配置达不到要求需求不合理 软件测试公理分析 6 49 应该在测试工作真正开始前的较长时间内进行测试计划 Good enough原则 这是一种权衡投入 产出比的原则 测试既不要不充分 也不要过分 不充分和过分都是一种不负责任的表现 Zero bug是一种理想 Good enough是我们的原则 Pareto原则 一般情况下 在分析 设计 实验阶段的复审和测试工作能够发现和避免80 的bug 而系统的软件测试能够找出其余bug中的80 最后约5 的bug只有在用户大范围 长时间的使用后才会暴露出来 因此测试只能保证尽可能多地发现错误 不能保证发现所有的错误 软件测试的原则 1 50 应当把 尽早地和不断地进行软件测试 作为软件开发者的座右铭 问题发现得越早 解决问题的代价就越小 应该在测试真正开始之前的较长时间就制定测试计划和测试用例 所有的测试可以在代码产生前进行计划和设计 所有的测试都应追溯到用户需求 软件测试的目的在于揭示错误 而最严重的错误 从用户角度看 是那些导致程序无法满足需求的错误 测试应从 小规模 开始 逐步转向 大规模 最初的测试常常把焦点放在单个程序模块上 进