软件测试技术综述

《软件测试技术综述》由会员分享，可在线阅读，更多相关《软件测试技术综述（65页珍藏版）》请在金锄头文库上搜索。

1、 软 件 测 试闫晓薇 137938882841第一章 相关背景知识 软件工程相关概念n n软件软件是计算机系统中与硬件相互依存是计算机系统中与硬件相互依存 的另一部分，它是包括程序，数据及其的另一部分，它是包括程序，数据及其 相关文档的完整集合相关文档的完整集合n n程序程序是按事先设计的功能和性能要求是按事先设计的功能和性能要求 执行的指令序列执行的指令序列n n数据数据是使程序能正常操纵信息的数据是使程序能正常操纵信息的数据 结构结构n n文档文档是与程序开发，维护和使用有关是与程序开发，维护和使用有关 的图文材料的图文材料2软件工程定义 软件工程就是为了经济地获得可靠的且能在实际 机器

2、上有效运行的软件，而建立的使用完善的工程 原理（NATO：North Atlantic Treaty Organization ) 把系统的、规范的、可度量的途径应用与软 件开发、运行和维护过程，也就是把工程应用 与软件；研究中提到的途径（IEEE93： Institute of Electrical and Electronic Engineers ）软件工程相关概念3软件工程包括三个要素：方法、工具和过程。v 软件工程方法为软件开发提供了方法论。v 软件工程工具为软件工程方法提供了自动的或半自动的软 件支撑环境。（CASE：工具产生的信息共享）v 软件工程过程是将软件工程的方法和工具综合起

3、来以达到 合理、及时地进行计算机软件开发的目的。软件工程相关概念4计计 划划需求分析需求分析设设 计计编编 码码测测 试试运行运行/ /维护维护定义阶段定义阶段开发阶段开发阶段维护阶段维护阶段软件生存期的瀑布模型和软件工程过程软件工程相关概念5vv 演化模型演化模型vv 螺旋模型螺旋模型vv 喷泉模型喷泉模型vv 智能模型智能模型软件工程相关概念67分 析系统 设计软件 设计实 现喷泉模型8获取需求需求分析具体描述优化程序调整验证维护知识库 专家系统程序智能模型9v软件测试面临的挑战v软件缺陷的定义v引起软件缺陷的因素v软件测试的目的v软件测试公理v软件测试的原则v软件测试的对象v软件测试的作

4、用v测试信息流v软件测试与开发各阶段的关系v软件测试模型v软件测试过程第二章 软件测试的基本知识102.1 当前软件测试面临的挑战 软件测试认识的误区：v软件开发完成后进行软件测试v软件发布后如果发现质量问题，那是软件测试人员的错 v软件测试要求不高，随便找个人都行 v软件自动测试效率高，将取代软件手工测试 v软件测试是测试人员的事情，与程序员无关v项目进度吃紧时少做些测试，时间富裕时多做测试v软件测试是没有前途的工作，只有程序员才是软件高手v使用了测试工具，就是进行了有效的测试v存在太多的无法测试的东西v测试代码可以随意写v单元测试和系统测试没有什么区别v 测试具有免疫性11对测试工作的误解

5、n设计-实现-测试，软件测试是开发后期的一个阶段 ；实际上，软件测试贯穿整个软件产品生命周期。一方 面，软件测试也要经历测试计划、测试用例的设计和实 现，以及测试运行一系列的阶段，因此，早在软件需求 阶段，甚至更早，软件测试的工作就要开始了。另一方 面，软件测试越早进行越好，因为BUG越早发现，BUG造 成的影响和修改的代价就越小。而且，软件测试并不仅 仅针对程序，软件的需求、设计等等也要被测试。12对测试工作的误解测试是 “ 泛型概念 ” （全程测试）。如果单纯的只将 程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷 产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、

6、设计缺 陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨 越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作 软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一 个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得 起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工 程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效 性。否则自身不正，难以服人。 另外还需指出的是软件测试是提高软件产品质量的必要条 件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决 不是一个根本手段。13对测试工作的误解2.

7、如果发布出去的软件有质量问题，那是软件试人员 的错； 软件的质量是“做”出来的，而不是“测”出来的7. 软件测试技术要求不高，比编程容易多了；很多人认为软件测试就是运行一下软件，然后看看结果 对不对。但实际上，如何在有限的投入下，提高软件测试 的效率和产出是一件很见功底的事情。所以，好的测试人 员不仅要掌握各种测试技术和测试工具，还要具备丰富的 编程经验和对BUG的敏感。另外，测试统计技术也是一项很 特别的技术。14对测试工作的误解8. 使用了测试工具，就是进行了有效的测试；有效测试的前提条件是：n该软件或者模块应该是可测试的，即：是强内 聚、弱耦合、接口明确、意图明晰的软件 。n要想真正获取

8、测试带来的巨大好处，并且使得 测试工具能够发挥最大的效率，关键就是要使软件 本身具有很好的可测试性。 n对于测试工具的选择，只要满足需要并能够自 动运行测试用例就可以了。 只有提高了自身团队内在的素质， 外在的工具才能够发挥作用。 15对测试工作的误解9. 存在太多的无法测试的东西确实存在一些东西看起来要比另外一些 东西难测试一些，但是远非无法测试n由于被测试的软件本身在设计时没有考 虑到可测试性的问题n这种不可测试性不是由于被测试的软件 内部的过紧耦合造成的，而是和外部某些很 难测试的部分耦合过紧16对测试工作的误解10. 测试代码可以随意写大家肯定知道测试代码是不能随意编 写的，并且在编写

9、测试代码时也不是抱着一种 随意的态度，但是你编写出来的测试代码以及 测试代码运行的情况却表现出了一种随意性和 无序性。因为你可能并没有弄清楚测试的真正 意图所在。 n样例17对测试工作的误解 11. 单元测试和系统测试没有什么区别以建筑为例n单元测试可以类比为一个建筑的质检人员对建 筑进行的检测， 他关注的重点是建筑的内部结构 、地基、框架以及墙壁是否垂直等。他的检测是要 保证建筑的各个部分是正常的、安全的，换句话说 ，就是要保证施工满足建筑上面的质量标准。 n系统测试可以类比为建筑的使用者来对建筑进 行的检测。首先，他认为这个建筑是满足规定的工 程质量的，这是有建筑的质检人员来保证的。使用

10、者关注的重点是住在这个建筑的中的感受。他关心 建筑的外观是否美观、各个房间的大小是否合适， 窗户的位置是否合适，是否能够满足家庭的需要等 。18对测试工作的误解n单元测试和系统测试之间的明确划分，没有一个通 用的标准，只有通过自己的不断实践来增加这方面的经 验n如果一个单元测试要跨越类的边界，那么它可 能应该是一个系统测试n如果一个单元测试变的非常复杂，那么它可能 应该是一个系统测试n如果一个单元测试经常要随着用户需求的变化 而改变，那么它可能应该是一个系统测试n如果一个单元测试比它要测试的代码本身要难 以编写，那么它可能应该是一个系统测试 19对测试工作的误解12. 测试具有免疫性（软件缺陷

11、免疫性） 软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测 试人员对其采用的测试越多，其免疫能力就越强，寻找更多软 件缺陷就更加困难。由数学上的概率论我们可以推出这一结论 。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件 错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们 假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。20对测试工作的误解照此推算，软件存在 500 个缺陷时，我们 查找一个软件缺陷需要 X 小时，当软件只存在 5 个错 误时，我们每查找一个软件缺陷需要 100X 小时。实践 证明，实际的测试过程比上面的假设更为苛刻，为此

12、我 们必须更换不同的测试方式和测试数据。该例子还说明 了在软件测试中采用单一的方法不能高效和完全的针对 所有软件缺陷，因此软件测试应该尽可能的多采用多种 途径进行测试。212.2 软件缺陷的正式定义几个关于缺陷的术语：v错误：Errorv缺陷：Defect、Bugv故障：Faultv失效：Failure222.2 软件缺陷的正式定义v软件未达到规格说明书表明的功能v软件出现了规格说明书指明不会出现的错误v软件功能超出规格说明书指明范围v软件未达到规格说明书虽未指出但应达到的 目标v软件测试人员认为软件难以理解、不易使用 、运行速度缓慢，或者最终用户认为不好232.3 引起软件缺陷的因素v交流不

13、够、交流上有误解或者根本不进行交流。在应用应该做什么或不应该做什么的细节(应用 的需求)不清晰的情况下进行开发。 v软件复杂性。图形用户界面(GUI)，客户/服务器结构，分布 式应用，数据通信，超大型关系型数据库以及庞大的系 统规模，使得软件及系统的复杂性呈指数增长，没有现 代软件开发经验的人很难理解它。 v程序设计错误。象所有的人一样，程序员也会出错。 242.3 引起软件缺陷的因素v需求变化。需求变化的影响是多方面的，客户可能不了解需 求变化带来的影响，也可能知道但又不得不那么做需求 变化的后果可能是造成系统的重新设计，设计人员的日 程的重新安排，已经完成的工作可能要重做或者完全抛 弃，对

14、其他项目产生影响，硬件需求可能要因此改变， 等等。如果有许多小的改变或者一次大的变化，项目各 部分之间已知或未知的依赖性可能会相互影响而导致更 多问题的出现，需求改变带来的复杂性可能导致错误， 还可能影响工程参与者的积极性。 252.3 引起软件缺陷的因素v时间压力。 软件项目的日程表很难做到准确，很多时候需要预计和猜测 。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。 v开发人员的过分自信。没问题这事情很容易几个小时我就能拿出来太多不切实际的没问题，结果只能是引入错误v代码文档贫乏。贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其 结果是带来许多错误。事实上，在许多机构并不鼓励其程

15、序员为代码编 写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少 写文档可以更快的进行编码，无法理解的代码更易于工作的保密(“写 得艰难必定读的痛苦”)。 26软件缺陷产生的原因很多，但是最主要的原因要归咎于规格说明书软件缺陷产生的原因27软件缺陷的修复费用软件从开始计划，编制，测软件从开始计划，编制，测 试，一直到公开使用的过程中都有可能试，一直到公开使用的过程中都有可能 发现软件缺陷，随着时间的推移，修复发现软件缺陷，随着时间的推移，修复 软件缺陷的费用呈几何级数增长。换句软件缺陷的费用呈几何级数增长。换句 话说，产品发布后修复软件缺陷的费用话说，产品发布后修复软件缺陷的费用

16、比项目开发早期修复费用要高出比项目开发早期修复费用要高出1010100100 倍，甚至更高。倍，甚至更高。28修改代价随时间的变化规律开发流程时间表与修改Bug代价的关系图开发结束开发结束开发早期开发早期修改代价修改代价29基于不同的立场，存在着两种完全不同的测试目 的：v从用户的角度出发，普遍希望通过软件测试暴露 软件中隐藏的错误和缺陷，以考虑是否可接受该产品 。v从软件开发者的角度出发，则希望测试成为验证 该软件已正确地实现了用户的要求，确立人们对软件 质量的信心。2.4 软件测试的目的130v“使用人工或自动手段来运行或测定某个 系统的过程，其目的在于检验它是否满足规定 的需求，或是确认预期结果与实际结果之间的 差别。”测试的目的是检验软件是否满足 了要求 ( IEEE 软件工程标准术语 ) v“程序测试是证明程序中不存在错误的过 程” 2.4 软件测试的目的231Myers软件测试目的：(1) 测试是程序的执行过程，目的在于发现 错误；(2) 一个好的测