软件测试技术综述

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