软件测试技术综述.ppt

《软件测试技术综述.ppt》由会员分享，可在线阅读，更多相关《软件测试技术综述.ppt（65页珍藏版）》请在三一办公上搜索。

1、软件测试 1,软 件 测 试闫晓薇13793888284,软件测试 2,第一章 相关背景知识软件工程相关概念,软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料,软件测试 3,软件工程定义软件工程就是为了经济地获得可靠的且能在实际机器上有效运行的软件，而建立的使用完善的工程原理（NATO：North Atlantic Treaty Organization)把系统的、规范的、可度量的途径应用与软件开发、运行和维护过程，也就是把工程应用与软

2、件；研究中提到的途径（IEEE93：Institute of Electrical and Electronic Engineers）,软件工程相关概念,软件测试 4,软件工程包括三个要素：方法、工具和过程。软件工程方法为软件开发提供了方法论。软件工程工具为软件工程方法提供了自动的或半自动的软件支撑环境。（CASE：工具产生的信息共享）软件工程过程是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。,软件工程相关概念,软件测试 5,计 划,需求分析,设 计,编 码,测 试,运行/维护,定义阶段,开发阶段,维护阶段,软件生存期的瀑布模型和软件工程过程,软件工程相关概念,软

3、件测试 6,演化模型螺旋模型喷泉模型智能模型,软件工程相关概念,软件测试 7,软件测试 8,软件测试 9,软件测试 10,软件测试面临的挑战软件缺陷的定义引起软件缺陷的因素软件测试的目的软件测试公理软件测试的原则软件测试的对象软件测试的作用测试信息流软件测试与开发各阶段的关系软件测试模型软件测试过程,第二章 软件测试的基本知识,软件测试 11,2.1 当前软件测试面临的挑战,软件测试认识的误区：软件开发完成后进行软件测试软件发布后如果发现质量问题，那是软件测试人员的错 软件测试要求不高，随便找个人都行 软件自动测试效率高，将取代软件手工测试 软件测试是测试人员的事情，与程序员无关项目进度吃紧时

4、少做些测试，时间富裕时多做测试软件测试是没有前途的工作，只有程序员才是软件高手使用了测试工具，就是进行了有效的测试存在太多的无法测试的东西测试代码可以随意写单元测试和系统测试没有什么区别 测试具有免疫性,软件测试 12,对测试工作的误解,设计-实现-测试，软件测试是开发后期的一个阶段；实际上，软件测试贯穿整个软件产品生命周期。一方面，软件测试也要经历测试计划、测试用例的设计和实现，以及测试运行一系列的阶段，因此，早在软件需求阶段，甚至更早，软件测试的工作就要开始了。另一方面，软件测试越早进行越好，因为BUG越早发现，BUG造成的影响和修改的代价就越小。而且，软件测试并不仅仅针对程序，软件的需求

5、、设计等等也要被测试。,软件测试 13,对测试工作的误解,测试是“泛型概念”（全程测试）。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住“软件缺陷具有生育能力”。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的

6、可靠性和高效性。否则自身不正，难以服人。另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。,软件测试 14,对测试工作的误解,2.如果发布出去的软件有质量问题，那是软件试人员的错；软件的质量是“做”出来的，而不是“测”出来的7.软件测试技术要求不高，比编程容易多了；很多人认为软件测试就是运行一下软件，然后看看结果对不对。但实际上，如何在有限的投入下，提高软件测试的效率和产出是一件很见功底的事情。所以，好的测试人员不仅要掌握各种测试技术和测试工具，还要具备丰富的编程经验和对BUG的敏感。另外，测试统计技术也是一项很

7、特别的技术。,软件测试 15,对测试工作的误解,8.使用了测试工具，就是进行了有效的测试；有效测试的前提条件是：该软件或者模块应该是可测试的，即：是强内聚、弱耦合、接口明确、意图明晰的软件。要想真正获取测试带来的巨大好处，并且使得测试工具能够发挥最大的效率，关键就是要使软件本身具有很好的可测试性。对于测试工具的选择，只要满足需要并能够自动运行测试用例就可以了。,软件测试 16,对测试工作的误解,9.存在太多的无法测试的东西 确实存在一些东西看起来要比另外一些东西难测试一些，但是远非无法测试由于被测试的软件本身在设计时没有考虑到可测试性的问题这种不可测试性不是由于被测试的软件内部的过紧耦合造成的

8、，而是和外部某些很难测试的部分耦合过紧,软件测试 17,对测试工作的误解,10.测试代码可以随意写 大家肯定知道测试代码是不能随意编写的，并且在编写测试代码时也不是抱着一种随意的态度，但是你编写出来的测试代码以及测试代码运行的情况却表现出了一种随意性和无序性。因为你可能并没有弄清楚测试的真正意图所在。样例,软件测试 18,对测试工作的误解,11.单元测试和系统测试没有什么区别 以建筑为例单元测试可以类比为一个建筑的质检人员对建筑进行的检测，他关注的重点是建筑的内部结构、地基、框架以及墙壁是否垂直等。他的检测是要保证建筑的各个部分是正常的、安全的，换句话说，就是要保证施工满足建筑上面的质量标准。

9、系统测试可以类比为建筑的使用者来对建筑进行的检测。首先，他认为这个建筑是满足规定的工程质量的，这是有建筑的质检人员来保证的。使用者关注的重点是住在这个建筑的中的感受。他关心建筑的外观是否美观、各个房间的大小是否合适，窗户的位置是否合适，是否能够满足家庭的需要等。,软件测试 19,对测试工作的误解,单元测试和系统测试之间的明确划分，没有一个通用的标准，只有通过自己的不断实践来增加这方面的经验如果一个单元测试要跨越类的边界，那么它可能应该是一个系统测试如果一个单元测试变的非常复杂，那么它可能应该是一个系统测试如果一个单元测试经常要随着用户需求的变化而改变，那么它可能应该是一个系统测试如果一个单元测

10、试比它要测试的代码本身要难以编写，那么它可能应该是一个系统测试,软件测试 20,对测试工作的误解,12.测试具有免疫性（软件缺陷免疫性）软件缺陷与病毒一样具有可怕的“免疫性”，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时/100 行。,软件测试 21,对测试工作的误解,照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件

11、只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。,软件测试 22,2.2 软件缺陷的正式定义,几个关于缺陷的术语：错误：Error缺陷：Defect、Bug故障：Fault失效：Failure,软件测试 23,2.2 软件缺陷的正式定义,软件未达到规格说明书表明的功能软件出现了规格说明书指明不会出现的错误软件功能超出规格说明书指明范围软件未达到规格说明书虽未指出但应达到

12、的目标软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好,软件测试 24,2.3 引起软件缺陷的因素,交流不够、交流上有误解或者根本不进行交流。在应用应该做什么或不应该做什么的细节(应用的需求)不清晰的情况下进行开发。软件复杂性。图形用户界面(GUI)，客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代软件开发经验的人很难理解它。程序设计错误。象所有的人一样，程序员也会出错。,软件测试 25,2.3 引起软件缺陷的因素,需求变化。需求变化的影响是多方面的，客户可能不了解需求变化带来的影响，也可能知道但

13、又不得不那么做需求变化的后果可能是造成系统的重新设计，设计人员的日程的重新安排，已经完成的工作可能要重做或者完全抛弃，对其他项目产生影响，硬件需求可能要因此改变，等等。如果有许多小的改变或者一次大的变化，项目各部分之间已知或未知的依赖性可能会相互影响而导致更多问题的出现，需求改变带来的复杂性可能导致错误，还可能影响工程参与者的积极性。,软件测试 26,2.3 引起软件缺陷的因素,时间压力。软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。开发人员的过分自信。没问题 这事情很容易几个小时我就能拿出来太多不切实际的没问题，结果只能是引入错误代

14、码文档贫乏。贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密(“写得艰难必定读的痛苦”)。,软件测试 27,软件缺陷产生的原因很多，但是最主要的原因要归咎于规格说明书,软件缺陷产生的原因,软件测试 28,软件缺陷的修复费用,软件从开始计划，编制，测试，一直到公开使用的过程中都有可能发现软件缺陷，随着时间的推移，修复软件缺陷的费用呈几何级数增长。换句话说，产品发布后修复软件缺陷的费用比项目开发早期修复费用要高出10

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

16、软件工程标准术语)“程序测试是证明程序中不存在错误的过程”,2.4 软件测试的目的2,软件测试 32,Myers软件测试目的：(1)测试是程序的执行过程，目的在于发现错误；(2)一个好的测试用例在于能发现至今未发现的错误；(3)一个成功的测试是发现了至今未发现的错误的测试。,2.4 软件测试的目的3,软件测试 33,测试只能证明错误的存在，而不能表明程序中没有错误。测试的两个作用是：确定程序中缺陷的存在；有助于判断该程序在实际上是否可用。软件测试最困难的问题之一是知道何时停止测试(When to stop testing?)自己测试自己的程序是不可能的。当一个软件被测出的缺陷数目增加时，更多的

17、未被发现的缺陷存在的概率也随之增加。并非所有的软件缺陷都能修复。程序测试的过程具有破坏性,2.5 软件测试公理1,软件测试 34,一个好的测试用例应当是一个对以前未被发现的缺陷有高发现率的用例，而不是一个表明程序工作正确的用例。要对有效的和无效的输入状况写测试用例。（测试用例要兼顾有效与无效的输入）测试用例应由测试输入数据和对应的预期输出结果这两部分组成。像做其它事情一样，测试在其一开始就必须要有一个目标。完全测试程序是不可能的。软件测试是有风险的行为。测试无法显示潜伏的软件缺陷。,2.5 软件测试公理2,软件测试 35,3.软件测试最困难的问题之一是知道何时停止测试,发版决策依据：When

18、to stop testing？每天不超过5个缺陷；没有Critical Bug；计划发版日期；市场需求。,软件测试 36,5.找到的软件缺陷越多，说明软件缺陷越多,其中的原因是：程序员怠倦程序员往往范同样的错误某些软件缺陷实际上是大灾难的征兆,软件测试 37,6.并非所有的软件缺陷都能修复,没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复设计不好，软件设计耦合性太强，牵一而发动全身技术上解决不了，人的能力，开发工具，软硬件配置达不到要求需求不合理,软件测试 38,12.完全测试程序是不可能的,输入量太大输出结果太多软件实现途径太多软件说明书没有客观标准。从不同的角度看，软件缺陷的标准

19、不同,软件测试 39,13.软件测试是有风险的行为,如果决定不去测试软件所有可能的情况，那就是选择了风险。但是在上一条公理中指出：完全测试程序是不可能的。在这种情况下，又不能全部测试，不测试又会漏掉软件缺陷，怎么办？软件测试员要学会的一个主要的原则就是如何把无边际的软件出现的可能情况减少到可以控制的范围，以及如何针对风险制作出明智的抉择去粗存精。,软件测试 40,14.测试无法显示潜伏的软件缺陷,软件测试工作与防疫员的工作级为相似，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷。你可以进行测试，查找并报告软件缺陷，但是不能保证软件缺陷全部找到。唯一的办法就是继续测试，多测试。,软件测试 4

20、1,应该在测试工作真正开始前的较长时间内进行测试计划；Good-enough原则：这是一种权衡投入产出比的原则，测试既不要不充分，也不要过分。不充分和过分都是一种不负责任的表现。Zero-bug是一种理想，Good-enough是我们的原则。Pareto原则：一般情况下，在分析、设计、实验阶段的复审和测试工作能够发现和避免80的bug，而系统的软件测试能够找出其余bug中的80。最后约5%的bug只有在用户大范围、长时间的使用后才会暴露出来。因此测试只能保证尽可能多地发现错误，不能保证发现所有的错误。,2.6 软件测试的原则-1,软件测试 42,1.应当把“尽早地和不断地进行软件测试”作为软件

21、开发者的座右铭，问题发现得越早，解决问题的代价就越小。应该在测试真正开始之前的较长时间就制定测试计划和测试用例所有的测试可以在代码产生前进行计划和设计。2.所有的测试都应追溯到用户需求。软件测试的目的在于揭示错误，而最严重的错误（从用户角度看）是那些导致程序无法满足需求的错误。3.测试应从“小规模”开始，逐步转向“大规模”。最初的测试常常把焦点放在单个程序模块上，进一步的测试重点转向模块的集成，最后在整个系统中寻找错误。这也是软件测试的常用策略。,2.6 软件测试的原则-2,软件测试 43,4.严格执行测试计划，排除测试的随意性。5.应当对每一个测试结果做全面检查。这是一条最明显的原则，但常常

22、被忽略。有些错误的征兆在输出实测结果时就已明显地表露出来了，但如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。6.妥善保存测试计划、测试用例、出错统计和测试分析报告，为维护提供方便测试是需要维护的。,2.6 软件测试的原则-3,软件测试 44,软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。,2.7 软件测试的对象1,软件测试 45,为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。确认(Validation

23、)，是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。需求规格说明的确认程序的确认(静态确认、动态确认)验证(Verification)，试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。,2.7 软件测试的对象2,软件测试 46,验证和确认-1,验证（Verification）：在软件生存期各个阶段，验证是指检测各个阶段结束时的工作产品是否满足对上一阶段的结束后的工作产品所定义的规格的验证过程。,软件测试 47,验证和确认-2,确认（Validation）:在软件生存周期各个阶段，确认是指检测各个阶段结束时的工作产品是否满足在软件生存周期初期在系统

24、需求文档中描述的各项软件规格的确认过程。,软件测试 48,“验证”工作内容,“确认”工作内容,软件测试 49,软件设计与编码过程是引入缺陷的过程，而软件测试是排除软件缺陷的过程。测试不能保证软件的质量。力图通过测试提高软件的质量如同经常称体重来达到减肥的目的。如果你想减肥，不要买一个新称，而是节食。如果你想提高你软件质量的话，不是更多的测试，而是更好的开发。-SteveMcConnellinCodeComplete,2.8 软件测试的作用1,软件测试 50,软件测试的衡量标准,需求的覆盖需求追溯表/需求矩阵缺陷数量多、新缺陷重现率BUG能按照一定的测试过程稳定重现效率平均每人天发现的BUG数（

25、5个/人天）成本少。合理的测试人力和软、硬件资源安排重用价值测试的数据或者样例可以重用,软件测试 51,2.9 测试信息流1,软件测试 52,软件配置：软件需求规格说明、软件设计规格说明、源代码等；测试配置：测试计划、测试用例、测试程序等；测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。,2.9 测试信息流2,软件测试 53,测试结果分析：比较实测结果与预期结果，评价错误是否发生。排错(调试)：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档再测试：直到通过测试为止。,2.9 测试信息流3,

26、软件测试 54,通过收集和分析测试结果数据，对软件建立可靠性模型利用可靠性分析，评价软件质量：软件的质量和可靠性达到可以接受的程度；所做的测试不足以发现严重的错误；如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。,2.9 测试信息流4,软件测试 55,软件开发过程是一个自顶向下，逐步细化的过程软件计划阶段定义软件作用域软件需求分析建立软件信息域、功能和性能需求、约束等软件设计把需求转化为程序逻辑流程编码把设计用某种程序设计语言转换成程序代码,2.10 软件测试与开发各阶段的关系2,软件测试 56,验收测试计划,系统测试计划,软件集成测试计划,交 付,各测试阶段

27、的信息依据：,2.10 软件测试与开发各阶段的关系1,软件测试 57,测试过程是依相反顺序安排的自底向上，逐步集成的过程。,2.10 软件测试与开发各阶段的关系3,软件测试 58,2.11 软件测试过程模型,软件测试是与软件开发紧密相关的一系列有计划的系统性的活动，显然软件测试也需要测试模型去指导实践。主要介绍两个模型：V模型 W模型,软件测试 59,V模型,V模型是最具有代表意义的测试模型。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系。从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对

28、应关系。箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。,软件测试 60,V模型,用户需求,需求分析与系统设计,概要设计,详细设计,编码,单元测试,集成测试,确认测试与系统测试,验收测试,软件测试 61,W模型,V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型。开发是“V”，测试也是与此相重叠的“V

29、”。W模型体现了“尽早地和不断地进行软件测试”的原则。,软件测试 62,W模型,用户需求,需求分析与系统设计,概要设计,详细设计,编码,单元测试,集成测试,确认测试与系统测试,验收测试,交付,实施,集成,用户需求V&V验收测试设计,需求分析与系统设计V&V确认与系统测试设计,概要设计V&V集成测试设计,详细设计V&V单元测试设计,软件测试 63,W模型,相比于V模型，W模型更科学。W模型可以说是前者自然而然的发展，它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。,软件测试 64,2.12 软件测试过程,测试计划测试设计测试开发测试执行测试评估,软件测试 65,软件测试过程,