软件测试工程师培训测试技术基础

软件测试工程师培训测试技术基础,您的问题,混乱的测试理论和测试技术怎样体系化？实用先进的测试技术有哪些？如何保证测试的质量？如何做好测试人员的绩效评估？需求频繁变更，测试如何更应对？在时间短、人员少、技术薄弱的情况下如何完成测试任务？面向业务的功能测试做得满足要求了吗？信息系统的性能测试、故障诊断以及性能调优如何实施？自动化的测试工具怎样使用,我们的目标,帮你解决困惑的问题；将看书与应用的差距拉短；向你传授先进的技术与方法；将测试理论和测试技术体系化；大量的典型案例活用测试技术；将测试管理与测试技术相结合；实践模拟最快的掌握自动化测试方法；搭建不同层面的交流与沟通平台；将培训的东西固化以及应用起来,培训内容,第一章 软件测试的发展第二章 软件测试的定义第三章 软件测试的模型第四章 广义的软件测试第五章 测试方法第六章 测试策略第七章 测试实施,第一章 软件测试的发展,20世纪60年代（软件工程建立前），为表明程序正确而进行测试。1972年， Bill Hetzel 在North Carolina大学举行第一次以软件测试为主题的正式会议。1979年， Glenford MyersThe Art of Software Testing提出测试的目的是证伪。,第一章 软件测试的发展,1981年，Bill Hetzel开设“Structured Software Testing”公共课。1988年David Gelperin & Bill Hetzel 在“Communications of the ACM”发表“The Growth of Software Testing”，介绍系统化的测试和评估流程。70年代后期至80年代中期开始建立的QA/SQA部门及其演化。,第一章 软件测试的发展,1996年提出的测试能力成熟度TCMM（Testing Capability Maturity Model）、测试支持度TSM（Testability Support Model）、测试成熟度TMM（Testing Maturity Model）。,第二章 软件测试的定义,2.1 软件生存周期2.2 软件测试的概念2.3 软件测试的对象2.4 软件测试的分类2.5 软件测试的目的2.6 软件测试的原则,2.1 软件生存周期,软件生存周期：项目规划、需求定义和需求分析、软件设计、程序编码、软件测试、运行维护。,2.1 软件生存周期,2.2 软件测试的概念,软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。,2.2 软件测试的概念,定义1：使用人工或自动化手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是发现预期结果与实际结果之间的差别。,2.2 软件测试的概念,定义2：软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（包括输入数据与预期输出结果），并利用这些测试用例运行软件，以发现软件错误的过程。,2.2 软件测试的概念,软件测试在软件生存期中，跨越两个阶段：一个是编码与单元测试阶段，另一个是综合测试阶段，即测试阶段。,2.3 软件测试的对象,软件测试不等于程序测试。软件测试贯串于软件定义和开发的整个期间。需求规格说明、概要设计规格说明、详细设计规格说明、程序都是软件测试的对象。,2.4 软件测试的分类,按测试用例设计方法：白盒测试、黑盒测试。按测试策略和过程：单元测试、集成测试、确认测试、系统测试、验收测试。按实施对象：企业内部测试、最终用户测试、第三方测试。,2.5 软件测试的目的,证明程序的正确性除非仅处理有限种情况检查系统是否满足需求期望目标发现程序错误直接目标,2.5 软件测试的目的,测试的目的是寻找错误，并且是尽最大可能找出最多的错误。观点1：好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。观点2：成功的测试是发现了至今为止尚未发现的错误的测试。,2.5 软件测试的目的,软件错误软件缺陷软件故障软件失效软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。软件缺陷是存在于软件之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。此时若无适当措施（容错）加以及时处理，便产生软件失效。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。,2.5 软件测试的目的,软件错误软件缺陷软件故障软件失效软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有及时的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。,2.5 软件测试的目的,测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。,2.5 软件测试的目的,测试是以评价一个程序或者系统属性为目标的一种活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求，为用户选择与接受软件提供有力的依据。,2.5 软件测试的目的,通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。同时通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。,2.5 软件测试的目的,验证用户需求,发现软件缺陷,目的：在软件分发到最终用户手中之前，发现并解决软件缺陷,2.6 软件测试的原则,所有的软件测试都应追溯到用户需求。尽早地和不断地进行软件测试。避免测试自己的程序。执行测试计划，排除随意性。增量测试，由小到大。周密的测试用例（输入条件（合理、不合理）、预期输出结果）。,2.6 软件测试的原则,充分注意群集现象。问题的互相确认。完全测试是不可能的，测试需要终止。回归测试。出错统计和分析。妥善保存一切测试过程文档。,第三章 软件测试的模型,3.1 V模型3.2 W模型3.3 H模型3.4 其他模型3.5 模型的指导意义,3.1 V模型,制定测试案例,评审,用户,需求获取,需求定义,需求分析,需求分析书,概要设计,概要设计书,详细设计,详细设计书,编码,程序,单元测试,已测试模块,集成测试,已集成软件,确认测试,已确认软件,系统测试,软件产品,可交付软件,3.1 V模型应用,需求、功能、设计和编码的开发活动随时间而进行，而相应的测试活动（即针对需求、功能、设计和编码的测试）开展的次序正好相反。成功应用V模型的关键因素是设计测试案例的时机。,3.1 V模型问题,测试是开发之后的一个阶段。测试的对象就是程序本身。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。,3.2 W模型,需求分析,需求测试,概要设计,功能测试,详细设计,设计测试,集成,集成测试,确认,确认测试,交付,系统测试,编码,单元测试,3.2 W模型应用,测试伴随整个开发周期。测试对象不仅是程序，还包括需求和设计。相应开发活动完成，即可执行测试（例如：需求分析完成，即可对需求进行测试） 。,3.2 W模型应用,需求测试关注重点：兼容性完备性一致性正确性可行性易修改性健壮性易理解性易测试性和可验证性,3.2 W模型应用,设计测试关注重点：完备性一致性正确性可行性易修改性模块性可预测性健壮性结构化易追溯性易理解性易测试性和可验证性,3.2 W模型问题,W模型未解决V模型中的部分问题：需求、设计、编码串行进行，无法并行工作。未将测试流程的完整性表示出来。,3.3 H模型,测试流程：测试准备活动：测试计划、测试设计、测试开发。测试执行活动：测试运行、测试评估。,测试准备,测试执行,测试流程,其他流程（如设计流程）,测试就绪点,3.3 H模型应用,测试不仅仅是测试执行，还包括其他活动。测试是一个独立流程，贯穿产品整个周期，于其他流程并发进行。测试要尽早准备，尽早执行。,3.3 H模型意义,测试准备和测试执行分离，有利于资源调配。降低成本，提高效率。充分体现测试过程（不是技术）的复杂性。有组织、结构化的独立流程，有助于跟踪测试投入的流向。,3.4 其他模型X模型,3.4 其他模型X模型,X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试。此后将进行频繁的交接，通过集成最终合成为可执行的程序。这一点在图的右上方得以体现。这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。X模型还定位了探索性测试，即图中右下方所示。,3.4 其他模型X模型,对V模型提出质疑，也因为V模型基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。因为在实际中，很多项目缺乏足够的需求，V模型还是从需求处理开始。质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。,3.4 其他模型前置模型,3.4 其他模型前置模型,开发和测试相结合：前置测试模型将开发和测试的生命周期整合在一起。对每一个交付内容进行测试：每一个交付的开发结果都必须通过一定的方式进行测试。在设计阶段进行测试计划和测试设计：设计阶段是做测试计划和测试设计的最好时机。,3.4 其他模型前置模型,测试和开发结合在一起：将测试执行和开发结合在一起，并在开发阶段以编码-测试-编码-测试的方式来体现。让验收测试和技术测试保持相互独立：验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。,3.5 模型的指导意义,测试的活动应该与软件开发同步进行。测试的对象不仅仅是程序，还包括需求和设计。及早发现软件的缺陷可降低软件开发成本。,第四章 广义的软件测试,4.1 确认、验证与测试4.2 确认、验证的目的4.3 确认、验证与测试的关系4.4 软件质量保证与软件测试,4.1 确认、验证与测试,广义的软件测试是由确认、验证、测试3个方面组成。确认：评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。验证：检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。测试：与狭隘的测试概念统一。,4.2 确认、验证的目的,确认：想证实在一个给定的外部环境中软件的逻辑正确性。验证：试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。,4.2 确认、验证的目的,确认：保证所生产的软件可追溯到用户需求的一系列活动。（生产的软件是否正确）验证：保证软件正确地实现了特定功能的一系列活动。（生产软件的步骤是否正确）,4.3 确认、验证与测试的关系,确认主要体现在计划阶段、需求分析阶段，也会出现在测试阶段；验证主要体现在设计阶段、编码阶段；测试主要体现在编码阶段和测试阶段。确认、验证与测试是相辅相成的。确认产生验证和测试的标准，验证和测试帮助完成确认。,4.4 软件质量保证与软件测试,软件质量保证软件测试；软件质量保证软件测试软件质量保证：通过预防、检查与改进来保证软件质量，是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求,4.4 软件质量保证与软件测试,软件质量保证：着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析找出问题或评估软件测试：关心的不是过程的活动，是对过程的产物以及开发出的软件进行剖析,4.4 软件质量保证与软件测试,软件质量保证：采用“全面质量管理”和“过程改进”的原理开展质量保证工作 软件测试：对过程中的产物开发文档和源代码进行走查、运行软件以找出问题，报告质量,第五章 测试方法,5.1 测试方法的分类5.2 白盒测试5.3 黑盒测试5.4 白盒测试与黑盒测试的比较,5.1 测试方法的分类,两种测试方法从不同的角度出发，反映了软件的不同侧面。,5.1 测试方法的分类,任何工程产品都可以使用以下的两种方法进行测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经过检查。（白盒测试）。已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。（黑盒测试）。,5.2 白盒测试,白盒测试的前提是可以把程序看成装在一个透明的白盒子里，也就是完全了解程序结构和处理过程。白盒测试按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。白盒测试又称结构测试。,5.2 白盒测试,5.2 白盒测试,典型白盒测试方法静态分析动态测试,5.2 白盒测试,使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次。对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次。在循环的边界和运行界限内执行循环体。测试内部数据结构的有效性等。,5.2 白盒测试,5.3 黑盒测试,黑盒测试法把程序看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用。黑盒测试又称功能测试。,5.3 黑盒测试,5.3 黑盒测试,典型黑盒测试方法 等价类划分 因果图 边界值分析,5.3 黑盒测试,黑盒主要是为了发现以下几类错误：是否有不正确或遗漏了的功能？在接口上，输入能否正确地接受？能否输出正确的结果？是否有数据结构错误或外部信息（例如数据文件）访问错误？性能上是否能够满足要求？是否有初始化或终止性错误？,5.3 黑盒测试,5.4 白盒测试与黑盒测试的比较,5.4 白盒测试与黑盒测试的比较,黑盒测试与白盒测试能够发现的错误,第六章 测试策略,6.1 测试的过程6.2 测试的数据流6.3 单元测试6.4 集成测试6.5 确认、系统与验收测试6.6 回归测试6.7 测试与调试,6.1 测试的过程,测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试以及每个阶段内在进行的测试种类。测试策略包括：要使用的测试技术和工具测试完成标准影响资源分配的特殊考虑（例如外部接口、模拟物理损坏、安全性威胁）,6.1 测试的过程,集成测试,确认测试,系统测试,已集成的软件,已确认的软件,可交付的软件,测试通过的模块,验收测试,6.2 测试的数据流,测试,结果分析,排错,可靠性分析,回归测试,6.3 单元测试,单元测试又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。软件单元测试的目的是检测程序模块对详细设计说明书的符合程度；软件单元测试依据是单元测试计划。,6.3 单元测试,软件单元测试由测试工程师编制测试用例进行测试，及针对程序模块进行多次循环反复的单元测试，并将测试结果记录在针对单元测试的软件测试报告上。若程序模块通过单元测试，则按配置管理规范所规定的标识方法进行标识。,6.3 单元测试设计,测试模型驱动模块：相当于所测模块的主程序。桩模块：也叫做存根模块。用以代替所测模块调用的子模块。,6.3 单元测试设计,考虑方面模块接口测试局部数据测试独立路径测试出错处理测试边界条件测试,模块接口,独立路径,边界条件,局部数据,模块,出错处理,6.3 单元测试设计,原则为模块正常运行设计为正向测试设计为逆向测试设计为满足特殊需求设计为代码覆盖设计,6.3 单元测试执行,检查编码是否遵循软件编程规范和标准。自动或手动分析程序。设计测试用例并运行。错误跟踪分析。,6.3 单元测试完成,6.4 集成测试,软件集成测试又称组装测试，即对程序模块采用一次性或增值方法组装起来，对系统的接口进行正确性检验的测试工作。软件集成测试的目的是检测程序对概要设计说明书的符合程度；软件集成测试依据是和集成测试计划。,6.4 集成测试,测试人员应提交针对软件集成测试的软件测试报告，项目经理负责对软件集成测试结果的进行确认。通过集成测试，则按配置管理规范所规定的标识方法进行标识。,6.4 集成测试设计,集成测试，通常是在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。一个模块的功能是否会对另一个模块的功能产生不利的影响。各个子功能组合起来，能否达到预期要求的父功能。全局数据结构是否有问题。单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。模块间是否存在时序问题（实时系统）与资源竞争。,6.4 集成测试设计组装方法,一次性组装/整体拼装：使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。可以并行调试所有模块，因此充分利用人力，加快工作进度。接口错误发现晚。错误定位困难。,6.4 集成测试设计组装方法,6.4 集成测试设计组装方法,增殖式组装/渐增式组装：首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。,6.4 集成测试设计组装方法,自顶向下的增殖方式：集成步骤：主模块作为驱动模块，所有与主模块直接相连的模块用桩模块替代。采用深度或广度优先，每次用一个子模块替换桩模块。进行回归测试以确定集成新模块后没有引入错误。从第2步重复进行上述过程，直到整个系统被集成完成。 特点：这种组装方式将模块按系统程序结构，沿控制层次自顶向下进行组装。自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。,6.4 集成测试设计组装方法,6.4 集成测试设计组装方法,自顶向下的增殖方式：桩模块的选择,6.4 集成测试设计组装方法,自底向上的增殖方式：集成步骤：由驱动模块控制最底层模块，进行并行测试。用实际模块替换驱动模块，形成子系统。为子系统配备驱动模块进行测试。按程序结构向上组装测试后的构件，直到整个系统被集成完成。特点：这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。,6.4 集成测试设计组装方法,6.4 集成测试设计组装方法,自底向上的增殖方式：驱动模块的选择,6.4 集成测试设计组装方法,6.4 集成测试设计组装方法,混合增殖式测试：衍变的自顶向下的增殖测试强化输入输出模块、复杂算法模块测试。自底向上组装成子系统。由主模块开始自顶向下增值测试。自底向上自顶向下的增殖测试首先对含读操作的子系统自底向上直至根结点模块进行组装和测试。然后对含写操作的子系统做自顶向下的组装与测试。回归测试采取自顶向下的方式测试所修改的模块及其子模块。将这一部分视为子系统，再自底向上测试，以检查该子系统与其上级模块的接口是否适配。,6.4 集成测试设计组装方法,关键模块：满足某些软件需求。高层控制模块。较复杂、较易发生错误。有明确定义的性能要求。关键模块及早测试，回归测试时重点测试。,6.4 集成测试设计,集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试设计时，应考虑如下因素：是采用何种系统组装方法来进行组装测试。组装测试过程中连接各个模块的顺序。模块代码编制和测试进度是否与组装测试的顺序一致。测试过程中是否需要专门的硬件设备。,6.4 集成测试完成,集,成,测,试,6.5 确认、系统与验收测试,集成测试,确认测试,系统测试,已集成的软件,已确认的软件,可交付的软件,测试通过的模块,验收测试,6.5 确认、系统与验收测试确认测试,确认测试包括有效性测试与软件配置复查。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中已经明确规定。,6.5 确认、系统与验收测试确认测试,有效性测试,管理机构裁决,测试报告,软件配置,6.5 确认、系统与验收测试确认测试,有效性测试是在模拟的环境（可能就是开发的环境）下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列的需求。,6.5 确认、系统与验收测试确认测试,软件配置复查的目的是保证软件配置的所有成分都齐全。各方面的质量都符合要求。具有维护阶段所必需的细节。而且已经编排好分类的目录。,6.5 确认、系统与验收测试系统测试,系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起测试。在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。,6.5 确认、系统与验收测试验收测试,验收测试与系统测试的区别：组织机构：项目经理负责组织验收组进行最终验收测试。验收组应由项目组成员、用户代表、监理代表等组成。测试地点：验收测试原则上在顾客所在地进行，但如顾客同意也可在公司内模拟用户环境进行。覆盖范围：验收测试针对用户关心的核心流程。实施人员：用户为主。,6.5 确认、系统与验收测试验收测试,验收测试根据合同、需求规格说明书或验收测试计划对成品进行验收测试。对于通过验收测试的软件产品/参照配置管理规范中所规定的标识方法更改测试状态，同时项目经理负责编制验收报告。,6.5 确认、系统与验收测试设计,功能（机能）测试：目标中的功能是否真正实现了。安全性测试：设法破坏程序的安全性、保密检查。可靠性测试：平均无故障时间、因故障停机时间，需要模拟运行环境。可用性测试：界面友好、错误信息简明易懂、测试操作工序次序正确。,6.5 确认、系统与验收测试设计,大数据量测试：企图证明程序不能处理目标中指出的大批数据。并发负载测试：在一定工作负荷和配置条件下，系统响应时间及处理速度。疲劳强度测试：让程序在高负荷情况下运行（微软建议72小时）。存储量测试：测试程序所占用的内外存容量（静/动态）。,6.5 确认、系统与验收测试设计,可安装性测试：测试系统的安装过程。启动/停止测试：系统启动及关机阶段，能否正常运行。配置测试：软硬件配置，至少每一类和最大最小的设备配置情况都要测试。兼容性测试：向下兼容、交错兼容，对现有程序进行修改和补充后，要进行此类测试。,6.5 确认、系统与验收测试设计,互连测试：测试不同系统之间的互连性。恢复测试：测试系统出错后如何恢复正常工作的。可维护性测试：对维护过程和难易程度进行测试。文档测试：审查文档的正确性，对文档中的每个例子都要作为测试用例。,6.5 确认、系统与验收测试完成,在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：测试结果与预期的结果相符。测试结果与预期的结果不符。测试的结论有两种情况：功能和性能与用