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

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