【文档说明】软件测试工程师培训测试技术基础课件.ppt，共(154)页，1.759 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50460.html

以下为本文档部分文字说明：

软件测试工程师培训测试技术基础培训内容•第一章测试技术的发展历程•第二章测试基本概念•第三章基本测试技术•第四章测试中的若干问题第一章测试技术的发展历程60年代（软件工程建立前），为表明程序正确而进行测试。1972年，BillHetzel在NorthCaroli

na大学举行第一次以软件测试为主题的正式会议。1979年，GlenfordMyers《TheArtofSoftwareTesting》提出测试的目的是证伪。第一章测试技术的发展历程1981年，BillHetzel开设“S

tructuredSoftwareTesting”公共课1988年DavidGelperin&BillHetzel在“CommunicationsoftheACM”发表“TheGrowthofSof

twareTesting”。70年代后期至80年代中期的QA部门。第一章测试技术的发展历程1996年提出的测试能力成熟度TCMM（TestingCapabilityMaturityModel）、测试支持度TSM（TestabilitySupport

Model）、测试成熟度TMM（TestingMaturityModel）。第二章测试基本概念2.1软件测试的定义2.2软件开发与软件测试2.3广义的软件测试2.4测试方法2.5测试策略2.

6验收测试2.7第三方测试2.1软件测试的定义软件生存周期：需求定义和需求分析、软件设计、程序编码、软件测试、运行维护。2.1软件测试的定义软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。测试：为了发现软件中

的错误而运行软件的过程。2.1软件测试的定义软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。软件测试在软件生存期中，跨越两个阶段：一个是编码与单元测试阶段，另一个是综合测试阶段，即测试阶段。2.1软件测试的定义软件测试的

对象•软件测试不等于程序测试。•需求规格说明、概要设计规格说明、详细设计规格说明、源程序都是软件测试的对象。•软件测试贯串于软件定义和开发的整个期间。2.1软件测试的定义软件测试的分类–按测试用例设计方法：白盒测试黑盒测试。–按测试策略和过程：

单元测试、集成测试、确认测试、系统测试。2.1软件测试的定义软件测试的目的–测试的目的是寻找错误，并且是尽最大可能找出最多的错误。–观点1：好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。–观点2：成功的

测试是发现了至今为止尚未发现的错误的测试。–测试无法说明错误不存在，只能说明软件错误已出现。2.1软件测试的定义2.1软件测试的定义软件测试的原则–尽早地和不断地进行软件测试–避免测试自己的程序–执行测试计划，排除随意性–增量测试，由小到大–周密的测试用例（输入条件（合理、不合理）、预期输

出结果）–回归测试–出错统计和分析2.2软件开发与软件测试－软件开发过程各环节的关系2.2软件开发与软件测试测试的活动应该与软件开发同步进行。测试的执行是在软件已编制完成后进行。及早发现软件的缺陷可以降低软件开发的成本。2.2软件开发与软件测试－V模型2.2软件开发与软件

测试－V模型V模型：需求、功能、设计和编码的开发活动随时间而进行，而相应的测试活动（即针对需求、功能、设计和编码的测试）开展的次序正好相反。成功应用软件开发V模型的关键因素是设计测试案例的时机。2.2软件开发与软件测试－V模型V模型的问

题：–误解：“测试是开发之后的一个阶段”、“测试的对象就是程序本身”。–实际应用中容易导致需求阶段的错误一直到最后验收阶段才被发现。2.2软件开发与软件测试－W模型2.2软件开发与软件测试－W模型W模型：–测试伴随整个开发周期。–测试的对象不仅仅是程序，还包括需求和设

计。W模型应用：–相应开发活动完成，即可执行测试（例如：需求分析完成，即可对需求进行测试）。2.2软件开发与软件测试－W模型W模型未解决V模型中的部分问题：–需求、设计、编码串行进行，无法并行工作。–未将测试流程的完整性表示出来。2.2软件开发与软件测试－H模型测试流程

：–测试准备活动：测试计划、测试设计、测试开发。–测试执行活动：测试运行、测试评估。2.2软件开发与软件测试－H模型H模型：–测试不仅仅是测试执行，还包括其他活动。–测试是一个独立流程，贯穿产品整个周期，于其他流程并发进行。–测试要尽

早准备，尽早执行。2.2软件开发与软件测试－H模型应用H模型的意义：–测试准备和测试执行分离，有利于资源调配。降低成本，提高效率。–充分体现测试过程（不是技术）的复杂性。–有组织、结构化的独立流程，有助于跟踪测试投入的流向。2.2软件开发与软件测试－软件测试与

开发的并行性需求分析需求评审概要设计详细设计概要设计评审单元测试编码设计走查编码走查各子模块有效性测试集成测试测试计划测试过程测试评审…………**项目阶段任务的里程碑********2.2软件开发与软件测试－开发各阶段的测试工作项目规划阶段：–确定专人负责测试阶段监控。需

求分析阶段：–制定测试需求分析、确认/系统测试计划，经评审后成为配臵管理项。–测试所需要的资源、配臵、每阶段评判通过标志进行规约。2.2软件开发与软件测试－开发各阶段的测试工作详细设计和概要设计阶段：–确保集成测试计划和单元测试计划完成。–测试计划完成后

，对参考的设计文档进行修改。编码阶段：–编写测试代码。（测试人员、专人）测试阶段：–测试人员执行测试。–完成测试报告。2.2软件开发与软件测试－开发各阶段的测试工作2.3广义的软件测试广义的软件测试是由确认、验证、测试3个方面组成。–确认（validatio

n）：评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。–验证（verification）：检测软件开发的每个阶段、每个步骤的结果是否正

确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。–测试：与狭隘的测试概念统一。2.3广义的软件测试确认：目的是想证实在一个给定的外部环境中软件的逻辑正确性。包括需求规格说明的确认和程序的确认。程序确认包括

静态确认与动态确认。验证：试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。2.3广义的软件测试确认：保证所生产的软件可追溯到用户需求的一系列活动。（生产的软件是否正确）验证：保证软件正确地实现了特定功能的一系列活动。（生产软件的步骤是否正确）2.3广义的软件测试确认

主要体现在计划阶段、需求分析阶段，也会出现在测试阶段；验证主要体现在设计阶段、编码阶段；测试主要体现在编码阶段和测试阶段。确认、验证、测试是相辅相成的。确认产生验证和测试的标准，验证和测试帮助完成确认（特别在系统测试

阶段）。2.4测试方法黑盒测试白盒测试两种测试方法从不同的角度出发，反映了软件的不同侧面，也适用于不同的开发环境2.4测试方法任何工程产品都可以使用以下的两种方法进行测试：–已知产品的功能设计规格，可以进

行测试证明每个实现了的功能是否符合要求。（黑盒测试）。–已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经过检查。（白盒测试）。2.4测试方法－黑盒测试黑盒测试法把程

序看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用。黑盒测试又称功能测试。2.4测试方法－黑盒测试2.4测试方法－黑盒测试典型黑盒测试方法–等价类划分–因果图–边界值分析2.4测试方

法－黑盒测试黑盒主要是为了发现以下几类错误：–是否有不正确或遗漏了的功能？–在接口上，输入能否正确地接受？能否输出正确的结果？–是否有数据结构错误或外部信息（例如数据文件）访问错误？–性能上是否能够满足要求？

–是否有初始化或终止性错误？2.4测试方法－黑盒测试输入输出黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试，也可被成为用户测试，主要应用于快速应用开发（RAD）环境2.4测试方法－白盒测试白盒测试的前提是可以把程序看成装在一

个透明的白盒子里，也就是完全了解程序结构盒处理过程，这种方法按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。白盒测试又称结构测试。2.4测试方法－白盒测试2.4测试方法－白盒测试典型白盒测试方法–静态分析(静态测试)–动态测试2.4测试方法静态

测试静态测试是指不利用计算机运行被测程序，而是通过其他手段达到检测的目的。包括需求评审、设计评审、人工走查、代码审查等。静态测试并不等同于人工测试，它也可以利用计算机作为对被测程序进行特性分析的工具，而只是不真正运行被测程序。静态方法也常常被称为“分析”，静态测试是对被测程序进行特

性分析的方法的总称。2.4测试方法代码审查(CodeInspections)代码审查会的过程如下：（1）会前准备：如组织者在会议开始之前把这个程序清单和设计规范分发给小组的其他成员，以便在会议之前熟悉这些

材料。（2）会议期间：a.请程序员逐句地讲述程序的逻辑结构。b.根据常见程序错误检验单分析程序。（3）会后检查：把已查出错误清单交程序员，并对修改结果进行跟踪。代码审查关注下列类型问题：（1）数据引用

错误（2）数据说明（3）计算（4）比较（5）控制流（6）接口（7）输入/输出（8）其它检查2.4测试方法人工走查(Walkthroughs)人工走查与代码审查一样，首先通过资料，研究程序。但不同的是：在人工走查会上是通过测试

数据与人工运行程序来达到测试目的。对照实验发现，人工走查和审查会平均能查出被测程序38%的错误。据资料，IBM代码审查会的查错效率高达80%。2.4测试方法静态测试阶段的任务：（1）检查算法的逻辑正确性。（2）检查模块接口的

正确性。（3）检查输入参数是否有合法性检查。（4）检查调用其他模块的接口是否正确。（5）检查是否设臵了适当的出错处理。（6）检查表达式、语句是否正确，是否含有二义性。（7）检查常量或全局变量使用是否正确

。（8）检查标识符的使用是否规范、一致。（9）检查程序风格的一致性、规范性。（10）检查代码是否可以优化，算法效率是否最高。（11）检查代码注释是否完整，是否正确反映了代码的功能。2.4测试方法静态测试可以完成以下工作：（1）发现下列程序的错误：错用

局部变量和全局变量；未定义的变量、不匹配的参数；不适当的循环嵌套或分支嵌套、死循环、不允许的递归；调用不存在的子程序，遗漏标号或代码。（2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未使用过的标号；潜在的死循环。（3）提供

程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背编码规则；标识符的使用方法和过程的调用层次。（4）为进一步查找做好准备。（5）选择测试用例。（6）进行符号测试。2.4测试方法2、动态测试动态方法的主要特征是计算机必须真正运行被测试的程序，通过输入测试

用例对其运行情况（即输入与输出的对应关系）进行分析，达到检测的目的。动态测试包括：单元测试、集成测试、系统测试、用户的验收测试和回归测试。2.4测试方法使用静态和动态测试进行结构和功能测试：测试阶段执行人静态校验动态校验可行性评审开发人员，用户√需求评审开

发人员，用户√设计评审开发人员√单元测试开发人员√集成测试开发人员，测试人员√系统测试开发人员在测试人员的协助下完成√验收测试用户√2.4测试方法－白盒测试使用白盒测试方法，主要想对程序模块进行如下的检查：–对程序模块的所有独立的执行路径至少测试一次。–对

所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次。–在循环的边界和运行界限内执行循环体。–测试内部数据结构的有效性等。2.4测试方法－白盒测试白盒测试又称结构测试、逻辑驱动测试或基于程序本身的测试，也可成为程序员测试，主要应用于结构化开发环境应用程序2.4测试方法黑盒测试

法和白盒测试法的比较黑盒测试是以用户的观点，从输入数据与输出数据的对应关系，也就是根据程序外部特性进行的测试。若外部特性本身存在问题或规格说明书有误，则应用黑盒测试方法是不能发现问题的。白盒测试是根据程序的内部结构进行测试。测试用例的设计要保证测试时程序的所有

语句至少执行一次，而且要检查所有的逻辑条件。如果程序的结构本身有问题，比如说程序逻辑有错误或者有遗漏，那也是无法发现的。黑盒测试和白盒测试各有自己的优缺点，可以构成互补的关系。在规划测试方案时，需要把黑盒测试与白盒测试结合起来。2.4测试方法项目黑盒法

白盒法规划方面功能的测试结构的测试优点方面能确保从用户的角度出发进行测试能对程序内部的特定部位进行覆盖测试缺点方面无法测试程序内部特定部位；当规格说明有误，则不能发现问题无法检查程序的外部特性；无法对未实现规格说明的程序内部欠缺部分进行测试应用范围边界分析法等价类

划分法决策表测试语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，路径覆盖，循环覆盖，模块接口测试2.5测试策略2.5测试策略－测试的数据流2.5测试策略－单元测试单元测试又称为模块测试，是针对程序模块（软件设计的最小单位）

来进行正确性检验的测试工作。软件单元测试的目的是检测程序模块对《详细设计说明书》的符合程度；软件单元测试依据是《单元测试计划》。2.5测试策略－单元测试软件单元测试由测试工程师编制测试用例进行测试，及针对程序模块进行

多次循环反复的单元测试，并将测试结果记录在针对单元测试的《软件测试报告》上。若程序模块通过单元测试，则按《配臵管理规范》所规定的标识方法进行标识。2.5测试策略－单元测试模块接口测试局部数据结构测试路径测试

错误处理测试边界测试2.5测试策略－单元测试的步骤通常单元测试是在编码阶段进行的。在源程序代码编制完成。经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。–驱动模块：相当于所测模块的主程序。–桩模块：也叫做存根模块。用以代替所测模块调用的子模块。2.5测

试策略－单元测试的环境2.5测试策略－单元测试完成单元测试单元测试单元测试单元测试单元测试2.5测试策略－集成测试为什么要进行集成测试？实践表明，软件的一些模块能够单独地工作，但并不能保证组装连接之后也肯定能正常工作。程序在某些局部反映不出来的问题，在全局情况下有可能暴露出来，

影响软件功能的实现。可能的原因有以下几方面：（1）模块相互调用时引入了新的问题，例如数据可能没有正确传递，一模块对另一模块产生了不利的影响等。（2）几个子功能组合后不能实现预期的主功能。（3）单个模块的误差累计达到了不可接受的程度。（4）全局数据结构出现问题。2.5测试策略－集成

测试集成测试(IntegratedTesting)阶段是指每个模块完成单元测试后，需要按照设计时确定的程序结构图，把它们连接起来进行集成测试。集成测试也称为综合测试、组装测试、联合测试。集成测试的对象：经过单元测试的程

序模块间调用关系和接口数据。集成测试的目的：找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题。集成测试的测试依据：程序结构设计文档（包括概要设计说明书、详细设计说明书等）。集成测试的基本方案：非增量式测试、增量式测试。2.5测试策略－集

成中的组装方法非增量式测试是采用一步到位的方法来构造测试：对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。非增量式测试的缺点：当一次集成的模块较多时，这种测

试容易出现混乱，因为测试时可能发现了许多故障，为每一个故障定位和纠正非常困难，并且在修正一个故障的同时，可能又引入了新的故障，新旧故障混杂，很难判定出错的具体原因和位臵。2.5测试策略－集成中的组装方法AS3S4S5d2Cd4Ed5Fd1Bs1d3s

2DABCDEFABCDEF（1）程序结构图（3）集成测试示意图（2）单元测试示意图2.5测试策略－集成中的组装方法增量式测试的集成是逐步实现的：逐次将未曾集成测试的模块和已集成测试的模块（或子系统）结合成程序包，再将这些模块集成

为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。按照不同的实施次序，增量式集成测试又可以分为三种不同的方法：•自顶向下增量式测试•自底向上增量式测试•混合增量式测试2.5测试策略－集成中的组装方法自顶向下增量式测试•这种集成方式是将模块按系统的程序结构自顶向下进行

集成，即模块集成的顺序是首先集成主控模块（主程序），然后沿控制层次向下进行集成。从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。深度优先方式的集成：首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。

广度优先方式的集成：首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集中起来，直到最底层。2.5测试策略－集成中的组装方法自顶向下增量式测试的步骤：（1）以主控模块为所测模块兼驱动模块，所有直属于主控模块的下属模块全部用桩模块代替。（2）采用深度优先或广度优先

的策略，用实际模块替换相应桩模块，再用桩模块代替实际模块的直接下属模块，与已测试的模块或子系统集成为新的子系统。下层的桩模块一次一次地被替换为真正的模块。（3）进行回归测试（即重新执行以前做过的全部测试或部分测试），

排除集成过程中引起错误的可能。（4）判断是否所有的模块都已集成到系统中，是则结束测试，否则转到（2）去执行。2.5测试策略－集成中的组装方法ABCDEFAS1S2S3ABCDS4S5ABCDEF（1）（

2）（3）广度优先方式2.5测试策略－集成中的组装方法ABCS3EABCDEFAS1S2S3ABS2S3E（1）（2）（3）深度优先方式（4）2.5测试策略－集成中的组装方法自底向上增量式测试•这种集成方式是将模块按系统的程序结构自底向上进行集成，即从程

序模块结构的最底层模块开始集成和测试。•由于是自底向上进行集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运

行子模块得到。2.5测试策略－集成中的组装方法自底向上增量式测试的步骤：（1）由驱动模块控制最底层模块的并行测试。（2）用实际模块代替驱动模块，与它已测试的直属子模块集成为子系统。（3）为子系统配备驱动模块，进行新的测试。（

4）判断是否已集成到达主控模块，是则结束测试，否则执行（2）。2.5测试策略－集成中的组装方法ABCDEFd2Cd1Ed3Fd4BEd5FDABCDEF2.5测试策略－集成中的组装方法混合增殖式测试：对软件中、上层使用自

顶向下，对软件的中下层采用自底向上。集成步骤：–首先对输入／输出模块和引入新算法模块进行测试；–再自底向上组装成为功能相当完整且相对独立的子系统；–然后由主模块开始自顶向下进行增殖测试。2.5测试策略－集成测试的组织和实施集成测试是一种正规测试过程，必须精心计划

,并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：–是采用何种系统组装方法来进行组装测试。–组装测试过程中连接各个模块的顺序。–模块代码编制和测试进度是否与组装测试的顺序一致。–测试过程中是否需要专门的硬件设备。2.5

测试策略－集成测试完成的标志成功地执行了测试计划中规定的所有组装测试。修正了所发现的错误。测试结果通过了专门小组的评审。2.5测试策略－集成测试完成单元测试单元测试单元测试单元测试单元测试组合测试2.5测试策略－集成测试完成的标志组合测试组合测试组合

测试组合测试集成测试2.5测试策略－确认测试确认测试又称有效性测试。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中已经明确规定。2.5测试策略－确认测试的步骤2.5测试策略－确认测试中的有效性测试有效性测试是在模拟的环境（可能就

是开发的环境）下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列的需求。在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：–测试结果与预期的结果相符。–测试结果与预期的结果不符。2.5测试策略－确认测试中的软件配置复查

软件配臵复查的目的是保证软件配臵的所有成分都齐全。各方面的质量都符合要求。具有维护阶段所必需的细节。而且已经编排好分类的目录。2.5测试策略－系统测试系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素

结合在一起测试。在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。2.5测试策略－系统测试由于软件只是计算机系统中的一个

组成部分，软件开发完成之后，最终还要和系统中的硬件系统、某些支持软件、数据信息等其他部分配套运行。因此，软件在投入运行以前需要完成系统测试，以保证各组成部分不仅能单独的得到检验，而且在系统各部分协调工作的环境下也能正常工作。系统测试

实际上是针对系统中各个组成部分进行的综合性检验。尽管每一个检验有特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能。严格的说，系统测试超出了软件工程范围。通常这项工作并不由系统

开发人员或系统开发组织来承担，而是由软件用户或软件开发机构委托独立测试机构来完成。2.5测试策略－系统测试系统测试与单元测试、集成测试的区别：（1）测试方法不同：系统测试属于黑盒测试，而单元测试大量采用白盒测试，集成测

试则是结合使用白盒与黑盒测试方法。（2）考察范围不同：单元测试主要测试模块内部的接口、数据结构、逻辑、异常处理等对象。集成测试主要测试模块之间的接口和异常。系统测试主要测试整个系统相对于用户的需求。（3）评估基准不同：系统测试的评估基准是测试用例对需求规格的覆盖率；

而单元测试和集成测试的评估主要是代码的覆盖率。2.5测试策略－系统测试的15种测试类型功能（机能）测试：目标中的功能是否真正实现了。批量测试：企图证明程序不能处理目标中指出的大批数据。强度测试：让程序在高负荷情况下运行（微软建议72小时）。可用性测试：界面友好、

错误信息简明易懂。安全性测试：设法破坏程序的保密检查。2.5测试策略－系统测试的15种测试类型性能测试：在一定工作负荷和配臵条件下，系统响应时间及处理速度。存储量测试：测试程序所占用的内外存容量（静/动态）。配臵测试：至少每一类和最大最小

的设备配臵情况都要测试。兼容/移植测试：对现有程序进行修改和补充后，要进行此类测试。可安装性测试：测试系统的安装过程。2.5测试策略－系统测试的15种测试类型可靠性测试：如平均无故障时间（MTT

F），需要模拟运行环境。恢复测试：测试系统出错后如何恢复正常工作的。可维护性测试：对维护过程和难易程度进行测试。文档测试：审查文档的正确性，对文档中的每个例子都要作为测试用例。工序测试：测试操作工序的次序正确

性。2.5测试策略－系统测试完成系统联调2.5测试策略－回归测试系统维护二次开发项目更新单元测试集成测试确认测试系统测试回归测试2.5测试策略－α测试和β测试α测试是由一个用户在开发环境下进行的测试,也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评

价软件产品的功能、可使用性、可靠性、性能和支持，尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。2.5测试策略－α测试和β测试β测试是由软件的多

个用户在一个或多个用户的实际使用环境下进行的测试。与α测试不同的是，开发者通常不在测试现场。α测试的目的是衡量软件产品的功能、可使用性、可靠性、性能和支持，尤其注重产品的产品的支持性，包括文档、客户培训和支持产品生产能力。只有当α测试达到一

定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿2.5测试策略－测试与调试软件调试和软件测试是完全不同的含义。通常情况是在测试以后紧接着要进行调试，实际上这两项工作是交叉进行的。

测试是一种检验，经过测试后可能会发现一些错误的征兆，但常常不能直接从测试的结果中找出错误的根源。这就需要充分利用测试结果和测试过程中提供的信息进行全面地分析，找到错误的根源和出现错误的原因，修正这些已发现的错误就是调试。即：调试是在测试发现错误后消除错误的过程。2.6验收测试验收测试是检验

软件产品质量的最后一道工序。验收测试是以用户为主的测试，同时软件开发人员也有一定的参与。验收测试由用户参加设计测试用例，使用用户界面来输入测试数据，并分析测试的输出结果，一般使用生产中的实际数据进行测试。在验

收测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性等进行确认。2.6验收测试－范围软件验收测试应完成的工作包括：–明确验收项目，给定验收测试通过的标准。–确定测试方法。–决定验收测试的组织机构和可利用的资源。–选定测试结果分析方

法。–制定验收测试计划并进行评审。–设计验收测试所用测试用例。–审查验收测试准备工作。–执行验收测试。–分析测试结果。–阐明验收测试结论，决定通过验收或是拒绝。2.6验收测试－计划可能包括的检验方面有以下一些：–功能测试（例如，完整的工资计算过程）。–逆向测试（例如，检验不符合要求数据

而引起出错的恢复能力）。–特殊情况（例如，极限测试、不存在路径的测试）。–文档检查。–强度测试（例如，大批数据或多用户同时使用）。–恢复测试（例如，硬件故障或用户不良数据引起的一些情况）。–可维护性评价。–用户操作测试（如

启动、退出系统）。–用户友好性检验。–安全测试。2.6验收测试－结果确认测试的结果，确认测试的结果有两种情况：–功能和性能与用户的要求一致，软件可以接受。–功能和性能与用户的要求的差距。2.7第三方测试信息系统工程承建单位内部进行的自测被称为第一方测

试，业主单位对工程进行的测试被称为第二方测试。与此相对应，由中立的第三方测试机构对系统进行的权威技术测试被称为第三方测试。国内的第三方测试工作始创于九十年初，经过了近十年的孕育，以“千年虫”问题的检验为契机，在二十世纪末开始快速发

展。2.7第三方测试－必要性国外开发商质量控制能力较强，但在比较专业的质量认证领域依然需要由第三方机构来完成。国内业主与开发商在信息技术与业务技术上的信息不对称性。国内还没有适应国情的、系列化协调配套的、工程化的信

息系统生产过程管理、质量评测、控制技术的规范和法律规程指导。2.7第三方测试－特点第三方测试具有明显的工程特性，主要包括需求分析审查、设计审查、功能测试、性能测试、安全性测试、可靠性测试、易用性测试、兼

容性测试、可扩充性测试、文档测试等。2.7第三方测试－特点第三方测试以合同的形式制约了测试方，保证了测试工作在一开始就具有客观性。第三方能够从需求理解系统，从软件工程角度把握系统，公平的评价系统中出现的问题。第三方机构的权威性能够更好的协调

用户与开发方之间的关系。2.7第三方测试－特点第三方测试不同于开发方的自测试。–避免开发人员的定势思维。–第三方测试的目的就是为尽量多地发现程序中的错误而运行程序的过程，可以更多的发现问题。–随着系统越做越大，开发方很难投入足够的人力与物力进行测试工作，同时也缺乏专业的测试工具及丰富的工具使用经

验。2.7第三方测试－特点第三方测试不同于用户的自测试。–用户熟悉业务但不熟悉计算机领域知识，很难对系统进行深入分析。–用户缺乏专用的测试工具。–第三方机构既往测试经验对测试的帮助。2.7第三方测试－对象应用软件的确认测试、鉴定测

试工程项目的系统测试、验收测试特殊项目/项目关键模块的单元测试其他：–工程监理–ISO9000认证、CMM认证2.7第三方测试－开展项目组成立制定方案、规范、案例与计划实施测试工作问题报告回归测试测试总结、

评估与测试报告第三章基本测试技术3.1测试生命周期3.2测试计划3.3测试设计3.4测试开发3.5测试执行3.6测试评估3.7测试跟踪3.1测试生命周期测试计划测试设计测试开发测试执行测试评估3.2测试计划－概述测试目的完成的标准时间安排明确的责任测试用例库测试

工具3.2测试计划－概述所需机器时间软/硬件配臵系统组装方式记录手段回归测试3.2测试计划－具体内容目的测试项（对象）测试类型测试范围测试过程资源需求（硬件、软件、人力）3.2测试计划－具体内容文档的检验进

度安排测试开始、结束准则测试记录回归测试的方法测试的评估缺陷跟踪3.2测试计划－测试需求业务功能–业务流程–数据库事务–域值合法性用户界面–对象状态–窗口模式–菜单–标准尺寸的控件/文字3.2测试计划－测试需求性能–在少于3秒的情况下增加一个新顾客帐户强度–当内存很低的情况

下运行应用程序–为设计规定是1,000,000条记录的系统增加1,000,001条记录3.2测试计划－测试需求配臵–显示驱动的兼容性–网络连接安装–新安装（典型安装、定制安装）–升级安装–网络下载3.3测试设计—测试过程包括详细的步骤以确定测试需求是否被满

足。组成：–测试的先决条件–输入条件–被执行的动作–期待的结果–证实期待结果的方法3.3测试设计－单元测试用例模块接口局部数据结构独立的路径边界条件出错处理3.3测试设计－黑盒测试用例功能不对或遗漏界面错误数据结构或外部数据库访问错误性能不满足初始化和终止错误

3.3测试设计－白盒测试用例保证一个模块中的所有可执行路径至少被执行一次对所有逻辑值均需测试真和假在上下边界及可操作范围内运行所有循环检查内部数据结构以确保其有效性3.3测试设计－循环测试用例简单循环嵌套循环串接循环非结构循环3.3测试设计－GUI测试用例窗口下拉菜单与鼠标

数据项3.3测试设计－测试案例•测试说明：3.3测试设计－测试案例测试案例：3.3测试设计－测试案例测试案例：3.4测试开发功能的自动化测试工具性能的自动化测试工具中的开发3.5测试执行—概述目标–执行测试–查看测试结果–研究并组织对测试结果进行评估–

记录缺陷输入–测试过程和测试用例输出–测试日志–缺陷报告3.5测试执行—记录结果测试日志信息执行测试过程评估意外的结果记录缺陷3.5测试执行—错误等级5级：灾难性的—系统崩溃、数据被破坏4级：很严重的—数据被破坏3

级：严重的—特性不能运行，无法替代2级：中等的—特性不能运行，可替代1级：烦恼的—提示不正确，报警不确切0级：轻微的—表面化的错误，拼写错等3.5测试执行—记录格式3.5测试执行—记录格式3.5测试执

行—记录格式3.6测试评估—概述目标–提交测试过程的衡量标准–产生缺陷报告和测试覆盖的总结报告输入–测试日志–缺陷报告输出–测试覆盖程度–缺陷分析报告3.6测试评估—测试覆盖率基于覆盖策略的系统测试–验证所有需求的完成情况–验证每行代码的执行情况基于测试需求的测试过程–

覆盖功能和设计的需求–验证一个测试需求对应的测试过程3.6测试评估—缺陷分析软件质量–缺陷分析是提供验证软件质量的手段之一–测试需求的覆盖程度决定了软件测试的质量如何实例报告–缺陷分配–缺陷趋向–缺陷状态–遗留缺陷对软件的影响

3.6测试评估—性能评测主要的性能评测包括•动态监测：在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。•响应时间／吞吐量：测试对象针对特定主角或测试用例的响应时间或吞吐量的评测。•百分比报告：代表不同测

试执行情况的两个（或多个）数据集之间的差异或趋势。•追踪报告：包括主角（测试脚本）和测试对象之间的消息／会话详细信息。3.6测试评估—报告对上面所有的测试评估方法按规格整理成一个书面的测试评估报告，展现出软件在各种评

测手段下的质量状态。3.7测试跟踪记录测试事件或用户问题分析原因，定位错误进行软件修改修改结果的跟踪第四章测试中的若干问题4.1对测试的误解4.2测试的改进方法4.3测试工程师能力与职业素质4.4测试格言4.1对测试的误解如果发布出去的软件

有质量问题，那是软件测试人员的错。软件测试技术要求不高，至少比编程容易多了。软件测试随便找一个能力差的人就能做。有时间就多测试一些，来不及就少测试一些。软件测试是测试人员的事，与开发人员无关。

设计－实现－测试，软件测试是开发后期的一个阶段。4.2测试的改进方法外聘更多的测试人员。将原有的开发人员抽调做测试工作。加强对测试和开发人员在软件测试方面的专业培训。购买或者自主开发一些测试工具。

将测试工作外包。4.3测试工程师能力与职业素质人是测试工作中最有价值也是最重要的资源让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作，是一种目光短浅的行为4.3测试工程师能力与职业素质－基本素质写作能力沟通能力移情能力技术能力自

信心外交能力幽默感判别与诊断能力解决争议能力项目管理4.3测试工程师能力与职业素质－基本素质影响力与动议很强的记忆力耐心怀疑精神自我督促洞察力指导能力每年40小时培训分析与表达力组织与领导力4.3测试工程师能力与职业素质－测试技能与方法质量概念与测试术语

质量管理系统与质量控制质量成本单元、集成、确认、系统、回归和验收测试软件测试生命周期检查、走查、评审、验证、确认测试工程师能力与职业素质－测试技能与方法测试环境、过程与工具、测试驱动测试标准GBGJBISO监控与测量测试水平选择测试工具运行测试工具软件变更测试4.3

测试工程师能力与职业素质－测试策划在开发平台工作中的风险软件在商业应用中的风险软件和商业风险的严重等级制定降低风险的应对措施结构测试与功能测试的有效方法4.3测试工程师能力与职业素质－测试策划使用工具制

定测试计划和用户一起定义软件验收的准则制定软件测试计划的经历检查测试计划、测试设计、测试范例与测试现的经历确定测试目标的能力4.3测试工程师能力与职业素质－执行测试计划测试设计和测试执行的开发方法制定测试数据覆盖的测试计划

编制测试脚本的知识编制测试案例文档、技术与方法以及期望的测试结果比较实际测试结果与期望之差4.3测试工程师能力与职业素质－执行测试计划记录测试发生问题与缺陷缺陷识别、跟踪与管理回归测试过程和概念

修改测试计划的过程执行过程测试工具使用前的培训4.3测试工程师能力与职业素质－测试分析报告和改进需求覆盖、代码覆盖、路径覆盖覆盖包括监控与需要执行的数量测量概念理论与技巧度量例如，检测缺陷发现率、缺陷密度和平均失效率计算软件产品的复杂度4.3测试工程师能力与职业素质－测试分

析报告和改进编制测试报告量化测试结果的有效结论验证测试过程分析有效测试过程能力测试过程持续改进的能力4.3测试工程师能力与职业素质－评估测试人员有效性评估测试工作有效性–测试策略–测试环境–测试组技巧测试

人员要求–达到测试目标与任务–遵守测试标准与过程–保持进度、控制预算4.4测试格言测试自己的程序是不可能的。派最好的人去做测试。保证在软件设计中可测性是一个重要的目标。在一个系统的设计中，每个模块应该只被集成到系统中一次。不要

改变程序，使测试更容易（除非这个修改使永久的）。测试像大多数其他活动一样，必须在开始的时候有目标。4.4测试格言在测试中，一个最难的问题就是知道什么时候测试可以结束。每个测试用例的一个必需的部分

使对预期输出的描述。避免不可重复的或无用的测试。既要写有效输入条件的测试用例，也要写无效输入条件的测试用例。当软件的某个部分所发现的缺陷数目上升时，那么存在更多的未发现的缺陷数的可能性也上升了。