软件测试基础和入门演示教学

《软件测试基础和入门演示教学》由会员分享，可在线阅读，更多相关《软件测试基础和入门演示教学（58页珍藏版）》请在金锄头文库上搜索。

1、软件测试基础,2,软件测试的作用 软件测试的目的 软件缺陷的定义 引起软件缺陷的因素 软件测试面临的挑战 软件测试模型 软件测试与开发各阶段的关系 软件测试过程 软件测试公理 软件测试的原则 软件测试的对象,软件测试的基本知识,3,软件设计与编码过程是引入缺陷的过程，而软件测试是排除软件缺陷的过程。 测试不能保证软件的质量。力图通过测试提高软件的质量如同经常称体重来达到减肥的目的。如果你想减肥，不要买一个新称，而是节食。如果你想提高你软件质量的话，不是更多的测试，而是更好的开发。 -SteveMcConnellinCodeComplete,软件测试的作用,4,基于不同的立场，存在着两种完全不同

2、的测试目的： 从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。 从软件开发者的角度出发，则希望测试成为验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。,软件测试的目的1,6,软件缺陷的正式定义,几个关于缺陷的术语： 错误：Error、Mistake 缺陷：Defect、Bug 故障：Fault 失效：Failure 基本上所有软件问题都称为缺陷,7,软件缺陷的正式定义,软件未达到产品说明书表明的功能 软件出现了产品说明书指明不会出现的错误 软件功能超出产品说明书指明范围 软件未达到产品说明书虽未指出但应达到的目标 软件测试人员认为软件难以

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

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

5、修改变的异常艰辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密(“写得艰难必定读的痛苦”)。,11,当前软件测试面临的挑战,软件测试认识的误区： 软件开发完成后进行软件测试 软件发布后如果发现质量问题，那是软件测试人员的错 软件测试要求不高，随便找个人都行 软件自动测试效率高，将取代软件手工测试 软件测试是测试人员的事情，与程序员无关 项目进度吃紧时少做些测试，时间富裕时多做测试 软件测试是没有前途的工作，只有程序员才是软件高手 使用了测试工具，就是进行了有

6、效的测试 存在太多的无法测试的东西 测试代码可以随意写 单元测试和系统测试没有什么区别 测试具有免疫性,12,设计-实现-测试，软件测试是开发后期的一个阶段； 实际上，软件测试贯穿整个软件产品生命期。一方面，软件测试也要经历测试计划、测试用例的设计和实现，以及测试运行一系列的阶段，因此，早在软件需求阶段，甚至更早，软件测试的工作就要开始了。另一方面，软件测试越早进行越好，因为BUG越早发现，BUG造成的影响和修改的代价就越小。而且，软件测试并不仅仅针对程序，软件的需求、设计等等也要被测试。,对测试工作的误解,13,测试是 “ 泛型概念 ” （全程测试）。如果单纯的只将程序设计阶段后的阶段称之为

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

8、产品质量最直接、最快捷的手段，但决不是一个根本手段。,对测试工作的误解,14,如果发布出去的软件有质量问题，那是软件试人员的错；软件的质量是“做”出来的，而不是“测”出来的 7. 软件测试技术要求不高，比编程容易多了； 很多人认为软件测试就是运行一下软件，然后看看结果对不对。但实际上，如何在有限的投入下，提高软件测试的效率和产出是一件很见功底的事情。所以，好的测试人员不仅要掌握各种测试技术和测试工具，还要具备丰富的编程经验和对BUG的敏感。另外，测试统计技术也是一项很特别的技术。,对测试工作的误解,15,8. 使用了测试工具，就是进行了有效的测试； 有效测试的前提条件是： 该软件或者模块应该是

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

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

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

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

13、。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。,对测试工作的误解,22,软件测试的衡量标准,需求的覆盖 需求追溯表/需求矩阵 缺陷数量 多、新 缺陷重现率 BUG能按照一定的测试过程稳定重现 效率 平均每人天发现的BUG数（5个/人天） 成本 少。合理的测试人力和软、硬件资源安排 重用价值 测试的数据或者样例可以重用,23,软件测试模型 软件测试与开发各阶段的关系,软件工程相关概念,24,软件生存期的瀑布模型和软件工程过程,软件工程相关概念,25,软件测试模型,软件测试是与软件开发紧密相关的一系列有计划的系统性的活动

14、，显然软件测试也需要测试模型去指导实践 。 主要介绍两个模型： V模型 W模型,26,V模型,V模型是最具有代表意义的测试模型 。 V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系 。 从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。 箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。,27,V模型,28,W模型,V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是

15、软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现。 在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型。 开发是“V”，测试也是与此相重叠的“V”。 W模型体现了“尽早地和不断地进行软件测试”的原则。,29,W模型,30,W模型,相比于V模型，W模型更科学。W模型可以说是前者自然而然的发展，它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。 测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验

16、收测试。 测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。,31,其他开发模型,迭代增量 模型,螺旋迭代 模型,32,验收测试计划,系统测试计划,软件集成 测试计划,交 付,各测试阶段的信息依据：,软件测试与开发各阶段的关系-1,33,软件开发过程是一个自顶向下，逐步细化的过程 软件计划阶段定义软件作用域 软件需求分析建立软件信息域、功能和性能需求、约束等 软件设计把需求转化为程序逻辑流程 编码把设计用某种程序设计语言转换成程序代码,软件测试与开发各阶段的关系-2,34,测试过程是依相反顺序安排的自底向上，逐步集成的过程。,软件测试与开发各阶段的关系-3,35,软件测试过程,测试计划 测试设计 测试开发 测试执行 测试评估,36,软件测试过程,37,测试信息流1,38,软件配置：软件需求规格说明、软件设计规格说明、源代码等； 测试配置：测试计划、测试用例、测试程序等； 测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序