软件测试工程师培训测试技术基础PPT课件.ppt

软件测试工程师培训测试技术基础软件测试工程师培训测试技术基础培训内容培训内容第一章 软件测试的发展第二章 软件测试的定义第三章 软件测试的模型第四章 质量保证与测试第五章 测试方法第六章 测试策略第七章 测试实施培训内容培训内容第一章 软件测试的发展第二章 软件测试的定义第三章 软件测试的模型第四章 质量保证与测试第五章 测试方法第六章 测试策略第七章 测试实施第一章第一章 软件测试的发展软件测试的发展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”，介绍系统化的测试和评估流程。20世纪80年代早期，开始吹响“质量”的号角，软件测试的定义发生了改变，开始引入“质量评价”的内容第一章第一章 软件测试的发展软件测试的发展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.7 软件失效机理2.1 软件生存周期软件生存周期软件生存周期：项目规划、需求定义和需求分析、软件设计、程序编码、软件测试、运行维护。2.1 软件生存周期软件生存周期设计说明书设计说明书设计员：我要让软件怎么做？需求规格说明书需求规格说明书分析员：我可以提供什么？源程序源程序程序员：我要让计算机怎么做？软件需求软件需求用户：我要什么？运行结果运行结果计算机：程序运行得到什么？理解正确性编码正确性理解正确性设计正确性表达正确性理解正确性表达正确性相符吗？输入正确性运行正确性2.2 软件测试的概念软件测试的概念软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。2.2 软件测试的概念软件测试的概念经典定义：在规定的条件下对程序程序进行操作，以发现错误和对软件质量进行评估 使用人工或自动化手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是发现预期结果与实际结果之间的差别。2.2 软件测试的概念软件测试的概念扩展定义：软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（包括输入数据与预期输出结果），并利用这些测试用例运行软件，以发现软件错误的过程。2.2 软件测试的概念软件测试的概念广义的软件测试是由确认、验证、测试3个方面组成。确认：评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。验证：检测软件开发的每个阶段、每个步骤结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。测试：与狭隘的测试概念统一。2.2 软件测试的概念软件测试的概念确认：保证所生产的软件可追溯到用户需求的一系列活动。（生产的软件是否正确）确认（validation）：are we building the right product?验证：保证软件正确地实现了特定功能的一系列活动。（生产软件的步骤是否正确）验证（verification）：are we building the product right?2.2 软件测试的概念软件测试的概念确认主要体现在计划阶段、需求分析阶段，也会出现在测试阶段；验证主要体现在设计阶段、编码阶段；测试主要体现在编码阶段和测试阶段。确认、验证与测试是相辅相成的。确认产生验证和测试的标准，验证和测试帮助完成确认。2.3 软件测试的对象软件测试的对象软件测试不等于程序测试。软件测试贯串于软件定义和开发的整个期间。需求规格说明、概要设计说明、详细设计说明、程序都是软件测试的对象。2.4 软件测试的分类软件测试的分类按测试用例设计方法：白盒测试、黑盒测试。按测试策略和过程：单元测试、集成测试、确认测试、系统测试、验收测试。按实施对象：企业内部测试、最终用户测试、第三方测试。2.5 软件测试的目的软件测试的目的测试的最直接的目的是寻找错误，并且是尽最大可能找出最多的错误。观点1：好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。观点2：成功的测试是发现了至今为止尚未发现的错误的测试。2.5 软件测试的目的软件测试的目的证明程序的正确性除非仅处理有限种情况发现程序错误直接目标检查系统是否满足需求期望目标2.5 软件测试的目的软件测试的目的测试目的延伸（软件工程）：1.测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。2.5 软件测试的目的软件测试的目的2.通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进软件过程改进。同时通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。2.5 软件测试的目的软件测试的目的3.测试是以评价一个程序或者系统属性为目标的一种活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求，为用户选择与接受软件提供有力的依用户选择与接受软件提供有力的依据据。2.5 软件测试的目的软件测试的目的验证用户需求验证用户需求验证用户需求验证用户需求发现软件缺陷发现软件缺陷发现软件缺陷发现软件缺陷改进开发过程改进开发过程改进开发过程改进开发过程目的：在软件分目的：在软件分发到最终用户手发到最终用户手中之前，发现并中之前，发现并解决软件缺陷解决软件缺陷2.6 软件测试的原则软件测试的原则所有的软件测试都应追溯到用户需求。尽早地和不断地进行软件测试。程序员应避免检查测试自己编写的程序。执行测试计划，尽量避免测试的随意性。增量测试，由小到大。2.6 软件测试的原则软件测试的原则充分注意群集现象。完全测试是不可能的，测试需要终止。测试无法显示软件潜在的错误妥善保存一切测试过程文档。2.7 软件失效机理软件失效机理软件错误软件缺陷软件故障软件失效软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。软件缺陷是存在于软件之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。此时若无适当措施（容错）加以及时处理，便产生软件失效。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。2.7 软件失效机理软件失效机理软件错误软件缺陷软件故障软件失效软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有及时的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。培训内容培训内容第一章 软件测试的发展第二章 软件测试的定义第三章 软件测试的模型第四章 质量保证与测试第五章 测试方法第六章 测试策略第七章 测试实施第三章第三章 软件测试的模型软件测试的模型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模型中的部分问题：需求、设计、编码串行进行，无法并行工作。未将测试流程的完整性表示出来。培训内容培训内容第一章 软件测试的发展第二章 软件测试的定义第三章 软件测试的模型第四章 质量保证与测试第五章 测试方法第六章 测试策略第七章 测试实施第四章第四章 质量保证与测试质量保证与测试4.1 质量保证4.2 主要职责4.3 工作内容4.4 工作方法4.5 与测试的区别4.6 误解4.1 质量保证质量保证质量保证（Quality Assurance）质量保证：通过预防、检查与改进来保证软件质量，是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求质量保证软件测试4.2 主要职责主要职责QA的主要职责：检查开发和管理活动是否与已定的过程策略、标准和流程一致 检查工作产品是否遵循模板规定的内容和格式收集度量数据，确定和管理风险，促进和协助流程改进向管理者提供正确的信息，以使软件开发正确的执行充当测试工作的监督者，测试工作是否按照既定的流程（测试计划、测试方案、测试案例、测试执行）进行4.3 工作内容工作内容参与公司质量体系建设促使过程持续改进 指导项目实施 评审项目活动 审核工作产品 提供决策参考 进行缺陷预防4.4 工作过程工作过程计划针对具体项目制定SQA计划，确保项目组正确执行过程有重点：依据企业目标以及项目情况确定检查、审计的重点明确内容：标识出检查、审计的工作产品对象 明确方式：确定怎样进行检查、审计明确结果报告：每个阶段SQA的输出产品、结果报告给谁评审/审计依据SQA计划进行SQA检查、审计工作，按照规则发布结果报告审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品、产品是否符合相应的规程定义问题跟踪对审计中发现的问题，要求项目组改进，并跟进直到解决。提供项目改进的依据4.5 与测试的区别与测试的区别软件质量保证：着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析找出问题或评估软件测试：关心的不是过程的活动，是对过程的产物以及开发出的软件进行剖析4.5 与测试的区别与测试的区别软件质量保证：采用“全面质量管理”和“过程改进”的原理开展质量保证工作 软件测试：对过程中的产物开发文档和源代码、应用软件进行走查、运行以找出问题，报告质量 4.6 误解误解SQA工作就是测试工作软件质量保证人员对软件产品质量负责如果发布出去的软件有错误，那是软件测试人员的错软件质量保证人员是专门监督项目组成员的第五章第五章 测试方法测试方法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 单元测试设计单元测试设计测试模型驱动模块：相当于所测模块的主程序。桩模块：也叫做存根模块。用以代替所测模块调用的子模块。测试用例测试用例驱动模块桩模块桩模块2被测模块被测模块测试结果测试结果桩模块桩模块1桩模块桩模块n6.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 确认、系统与验收测试完成确认、系统与验收测试完成在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：测试结果与预期的结果相符。测试结果与预期的结果不符。测试的结论有两种情况：功能和性能与用户的要求一致，软件可以接受。功能和性能与用户的要求有差距。6.5 确认、系统与验收测试完成确认、系统与验收测试完成确认与确认与系统测试系统测试6.5 确认、系统与验收测试确认、系统与验收测试测试类型对象目的依据方法单元测试 模块内部程序错误消除局部模块的逻辑和功能上的错误和缺陷详细设计 白盒为主黑盒为辅集成测试 模块间的集成和调用关系找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题概要设计 白盒与黑盒结合确认与系统测试整个系统中的软硬件对整个系统进行一系列的整体、有效性测试需求规格说明书黑盒6.6 回归测试回归测试单元测试单元测试单元测试单元测试集成测试集成测试集成测试集成测试确认测试确认测试确认测试确认测试系统测试系统测试系统测试系统测试回归测试回归测试6.6 回归测试回归测试回归测试的范围测试全部用例问题修改后的检验测试高风险模块/系统基于操作剖面选择测试6.6 回归测试回归测试回归测试的基本过程识别出软件中被修改的部分从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0依据一定的策略从T0中选择测试用例测试被修改的软件6.6 回归测试回归测试回归测试的基本过程如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分用T1执行修改后的软件第2和第3步测试验证修改是否破坏了现有的功能，第4和第5步测试验证修改工作本身6.7 测试与调试测试与调试调试不属于测试。成功的测试发现了错误的症状，从而引起调试的进行。调试的困难在于：症状和原因可能相距很远症状在另一个错误被改正后消失症状可能由人为错误引起症状可能由于时间问题而不是处理问题可能难以再现症状出现的输入条件培训内容培训内容第一章 软件测试的发展第二章 软件测试的定义第三章 软件测试的模型第四章 质量保证与测试第五章 测试方法第六章 测试策略第七章 测试实施第七章第七章 软件测试实施软件测试实施7.1 开发方测试7.2 用户测试7.3 第三方测试7.1 开发方测试开发方测试开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。有时也被称为“测试”。测试是由一个用户在开发环境/模拟环境下进行的测试。目的是评价软件产品的功能和性能，尤其注重产品的界面和特色。测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。7.2 用户测试用户测试非验收测试，有时被称为“测试”。测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与测试不同的是，开发者通常不在测试现场。测试的目的是衡量软件产品的功能和性能，尤其注重产品的支持性，包括文档、客户培训和支持产品生产能力。只有当测试达到一定的可靠程度时，才能开始测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。7.3 第三方测试第三方测试介于软件开发方和用户方之间的测试组织的测试。第三方测试也称为独立测试。软件质量工程强调开展独立验证和确认（IV&V）活动。第三方测试是由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。一般情况下是模拟用户在真实应用环境下，进行软件测试。7.3 第三方测试发展第三方测试发展信息系统工程承建单位内部进行的自测被称为第一方测试，业主单位对工程进行的测试被称为第二方测试。与此相对应，由中立的第三方测试机构对系统进行的权威技术测试被称为第三方测试。国内的第三方测试工作始创于九十年代初，经过了近十年的孕育，以“千年虫”问题的检验为契机，在二十世纪末开始快速发展。7.3 第三方测试必要性第三方测试必要性国外开发商质量控制能力较强，但在比较专业的质量认证领域依然需要由第三方机构来完成。国内业主与开发商在信息技术与业务技术上的信息不对称性。国内还没有适应国情的、系列化协调配套的、工程化的信息系统生产过程管理、质量评测、控制技术的规范和法律规程指导。7.3 第三方测试特点第三方测试特点第三方测试具有明显的工程特性，主要包括需求分析审查、设计审查、功能测试、性能测试、安全性测试、可靠性测试、易用性测试、兼容性测试、可扩充性测试、文档测试等。7.3 第三方测试特点第三方测试特点第三方测试以合同的形式制约了测试方，保证了测试工作在一开始就具有客观性。第三方能够从需求理解系统，从软件工程角度把握系统，公平的评价系统中出现的问题。第三方机构的权威性能够更好的协调用户与开发方之间的关系。7.3 第三方测试特点第三方测试特点第三方测试不同于开发方的自测试。避免开发人员的定势思维。第三方测试的目的就是为尽量多地发现程序中的错误而运行程序的过程，可以更多的发现问题。随着系统越做越大，开发方很难投入足够的人力与物力进行测试工作，同时也缺乏专业的测试工具及丰富的工具使用经验。7.3 第三方测试特点第三方测试特点第三方测试不同于用户的自测试。用户熟悉业务但不熟悉计算机领域知识，很难对系统进行深入分析。用户缺乏专用的测试工具。第三方机构既往测试经验对测试的帮助。7.3 第三方测试原则第三方测试原则委托原则独立公正原则依法原则回避原则保密原则7.3 第三方测试对象第三方测试对象应用软件的确认测试、鉴定测试工程项目的系统测试、验收测试特殊项目/项目关键模块的单元测试7.3 第三方测试开展第三方测试开展项目组成立制定方案、规范、案例与计划实施测试工作问题报告回归测试测试总结、评估与测试报告回顾一下培训的内容回顾一下培训的内容培训内容培训内容第一章 软件测试的发展第二章 软件测试的定义第三章 软件测试的模型第四章 质量保证与测试第五章 测试方法第六章 测试策略第七章 测试实施培训内容培训内容第二章 软件测试的定义2.1 软件生存周期2.2 软件测试的概念2.3 软件测试的对象2.4 软件测试的分类2.5 软件测试的目的2.6 软件测试的原则2.7 软件失效机理培训内容培训内容第三章 软件测试的模型3.1 V模型3.2 W模型3.3 H模型3.4 其他模型3.5 模型的指导意义培训内容培训内容第四章 质量保证与测试4.1 质量保证4.2 主要职责4.3 工作内容4.4 工作方法4.5 与测试的区别4.6 误解培训内容培训内容第五章 测试方法5.1 测试方法的分类5.2 白盒测试5.3 黑盒测试5.4 白盒测试与黑盒测试的比较培训内容培训内容第六章 测试策略6.1 测试的过程6.2 测试的数据流6.3 单元测试6.4 集成测试6.5 确认、系统与验收测试6.6 回归测试6.7 测试与调试培训内容培训内容第七章 测试实施7.1 开发方测试7.2 用户测试7.3 第三方测试谢 谢