软件测试技术基础知识第一篇.ppt

《软件测试技术基础知识第一篇.ppt》由会员分享，可在线阅读，更多相关《软件测试技术基础知识第一篇.ppt（125页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、软件测试技术基础知识第一篇培训内容培训内容 第一章测试技术的发展历程 第二章测试基本概念 第三章基本测试技术第一章测试技术的发展历程第一章测试技术的发展历程60年代（软件工程建立前），为表明程序正确而进行测试。1972年，Bill Hetzel在North Carolina大学举行第一次以软件测试为主题的正式会议。1979年，Glenford MyersThe Art of Software Testing提出测试的目的是证伪。第一章测试技术的发展历程第一章测试技术的发展历程1981年，Bill Hetzel开设“Structured Software Testing”公共课1988年Davi

2、d Gelperin&Bill Hetzel 在“Communications of the ACM”发表“The Growth of Software Testing”。70年代后期至80年代中期的QA部门。第一章测试技术的发展历程第一章测试技术的发展历程1996年提出的测试能力成熟度TCMM（Testing Capability Maturity Model）、测试支持度TSM（Testability Support Model）、测试成熟度TMM（Testing Maturity Model）。第二章测试基本概念第二章测试基本概念2.1 软件测试的定义2.2 软件开发与软件测试2.3 广

3、义的软件测试2.4 测试方法2.5 测试策略2.6 验收测试2.7 第三方测试2.1 软件测试的定义软件测试的定义为什么会出现软件缺陷为什么会出现软件缺陷导致软件缺陷最大的原因是产品说明书。导致软件缺陷最大的原因是产品说明书。软件缺陷的第二大来源是设计方案。软件缺陷的第二大来源是设计方案。编写代码编写代码其他其他其他其他10%软件产品说明软件产品说明书（需求）书（需求）56%编写代码编写代码7%设设 计计27%软件缺陷的修复费用软件缺陷的修复费用从开始到计划、编制、测试、一直到公开使用的从开始到计划、编制、测试、一直到公开使用的过程中，都有可能发现软件缺陷。过程中，都有可能发现软件缺陷。随着时

4、间推移，修复软件缺陷的费用呈几何数级随着时间推移，修复软件缺陷的费用呈几何数级地增长。地增长。软件缺陷在不同阶段发现时修改的费用示意图测试模式测试模式测试模式测试模式测试模式测试模式测试团队测试团队测试团队测试团队测试组管理员测试组管理员测试组管理员测试组管理员测试组成员测试组成员测试组成员测试组成员测试方法论测试方法论测试方法论测试方法论 测试工具测试工具测试工具测试工具测试计划及设计工具测试计划及设计工具测试计划及设计工具测试计划及设计工具测试开发及执行工具测试开发及执行工具测试开发及执行工具测试开发及执行工具测试评估及缺陷跟踪工具测试评估及缺陷跟踪工具测试评估及缺陷跟踪工具测试评估及缺陷

5、跟踪工具2.1 软件测试的定义软件测试的定义软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。2.1 软件测试的定义软件测试的定义软件测试的对象软件测试不等于程序测试。需求规格说明、概要设计规格说明、详细设计规格说明、源程序都是软件测试的对象。软件测试贯串于软件定义和开发的整个期间。2.1 软件测试的定义软件测试的定义软件测试的分类 按测试用例设计方法：白盒测试黑盒测试。按测试策略和过程：单元测试、集成测试、确认测试、系统测试。2.1 软件测试的定义软件测

6、试的定义软件测试的原则 尽早地和不断地进行软件测试 避免测试自己的程序 执行测试计划，排除随意性 增量测试，由小到大 周密的测试用例（输入条件（合理、不合理）、预期输出结果）回归测试 出错统计和分析2.2 软件开发与软件测试软件开发与软件测试软件开发过程各环节的关系软件开发过程各环节的关系2.2 软件开发与软件测试软件开发与软件测试V模型模型2.2 软件开发与软件测试软件开发与软件测试V模型模型V模型：需求、功能、设计和编码的开发活 动随时间而进行，而相应的测试活动（即针对需求、功能、设计和编码的测试）开展的次序正好相反。成功应用软件开发V模型的关键因素是设计 测试案例的时机。2.2 软件开发

7、与软件测试软件开发与软件测试V模型模型V模型的问题：误解：“测试是开发之后的一个阶段”、“测试的对象就是程序本身”。实际应用中容易导致需求阶段的错误一直到最后验收阶段才被发现。2.2 软件开发与软件测试软件开发与软件测试W模型模型2.2 软件开发与软件测试软件开发与软件测试W模型模型W模型：测试伴随整个开发周期。测试的对象不仅仅是程序，还包括需求和设计。W模型应用：相应开发活动完成，即可执行测试（例如：需求分析完成，即可对需求进行测试）。2.2 软件开发与软件测试软件开发与软件测试W模型模型W模型未解决V模型中的部分问题：需求、设计、编码串行进行，无法并行工作。未将测试流程的完整性表示出来。2

8、.2 软件开发与软件测试软件开发与软件测试H模型模型测试流程：测试准备活动：测试计划、测试设计、测试开发。测试执行活动：测试运行、测试评估。2.2 软件开发与软件测试软件开发与软件测试H模型模型H模型：测试不仅仅是测试执行，还包括其他活动。测试是一个独立流程，贯穿产品整个周期，于其他流程并发进行。测试要尽早准备，尽早执行。2.2 软件开发与软件测试软件开发与软件测试H模型模型应用H模型的意义：测试准备和测试执行分离，有利于资源调配。降低成本，提高效率。充分体现测试过程（不是技术）的复杂性。有组织、结构化的独立流程，有助于跟踪测试投入的流向。2.2 软件开发与软件测试软件开发与软件测试开发各阶段

9、的测试工作开发各阶段的测试工作2.3 广义的软件测试广义的软件测试广义的软件测试是由确认、验证、测试3个方面组成。确认（validation）：评估将要开发的软件产品是否正确 无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。验证（verification）：检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求 或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。测试：与狭隘的测试概念统一。2.3 广义的软件测试广义的软件测试确认主要体现在计划阶段、需求分析阶段，也会出现在测试阶段；验

10、证主要体现在设计阶段、编码阶段；测试主要体现在编码阶段和测试阶段。确认、验证、测试是相辅相成的。确认产生验证和测试的标准，验证和测试帮助完成确认（特别在系统测试阶段）。2.4 测试方法测试方法黑盒测试黑盒测试白盒测试白盒测试两种测试方法从不同的角度出两种测试方法从不同的角度出发，反映了软件的不同侧面，也发，反映了软件的不同侧面，也适用于不同的开发环境适用于不同的开发环境2.4 测试方法测试方法任何工程产品都可以使用以下的两种方法进行测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。（黑盒测试）。已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格的要求

11、，所有内部成分是否已经过检查。（白盒测试）。2.4 测试方法黑盒测试测试方法黑盒测试输入输入输入输入输出输出输出输出黑盒测试又称黑盒测试又称黑盒测试又称黑盒测试又称功能测试功能测试功能测试功能测试、数据驱动测试或基于、数据驱动测试或基于、数据驱动测试或基于、数据驱动测试或基于规格说明的测试，也可被成为规格说明的测试，也可被成为规格说明的测试，也可被成为规格说明的测试，也可被成为用户测试用户测试用户测试用户测试，主要，主要，主要，主要应用于快速应用开发应用于快速应用开发应用于快速应用开发应用于快速应用开发（RADRAD）环境环境环境环境2.4 测试方法黑盒测试测试方法黑盒测试黑盒测试法把程序看成

12、一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用。黑盒测试又称功能测试。2.4 测试方法黑盒测试测试方法黑盒测试2.4 测试方法黑盒测试测试方法黑盒测试典型黑盒测试方法 等价类划分 因果图 边界值分析2.4 测试方法黑盒测试测试方法黑盒测试黑盒主要是为了发现以下几类错误：是否有不正确或遗漏了的功能？在接口上，输入能否正确地接受？能否输出正确的结果？是否有数据结构错误或外部信息（例如数据文件）访问错误？性能上是否能够满足要求？是否有初始化或终止性错误？2.4 测试方法白盒测试测试方法白盒测试白盒测试又称白盒测试又称白盒

13、测试又称白盒测试又称结构测试结构测试结构测试结构测试、逻辑驱动测试或基于、逻辑驱动测试或基于、逻辑驱动测试或基于、逻辑驱动测试或基于程序本身的测试，也可成为程序本身的测试，也可成为程序本身的测试，也可成为程序本身的测试，也可成为程序员测试程序员测试程序员测试程序员测试，主要，主要，主要，主要应用于结构化开发环境应用于结构化开发环境应用于结构化开发环境应用于结构化开发环境应用程序应用程序2.4 测试方法白盒测试测试方法白盒测试白盒测试的前提是可以把程序看成装在一个透明的白盒子里，也就是完全了解程序结构盒处理过程，这种方法按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。白盒测试

14、又称结构测试。2.4 测试方法白盒测试测试方法白盒测试2.4 测试方法测试方法静态测试静态测试是指不利用计算机运行被测程序，而是通过其他手段达到检测的目的。包括需求评审、设计评审、代码审查等。静态测试并不等同于人工测试，它也可以利用计算机作为对被测程序进行特性分析的工具，而只是不真正运行被测程序。静态方法也常常被称为“分析”，静态测试是对被测程序进行特性分析的方法的总称。2.4 测试方法测试方法代码审查(Code Inspections)代码审查会的过程如下：（1）会前准备：如组织者在会议开始之前把这个程序清单和设计规范分发给小组的其他成员，以便在会议之前熟悉这些材料。（2）会议期间：a.请程

15、序员逐句地讲述程序的逻辑结构。b.根据常见程序错误检验单分析程序。（3）会后检查：把已查出错误清单交程序员，并对修改结果进行跟踪。代码审查关注下列类型问题：（1）数据引用错误（2）数据说明（3）计算（4）比较（5）控制流（6）接口（7）输入/输出（8）其它检查2.4 测试方法测试方法静态测试阶段的任务：（1）检查算法的逻辑正确性。（2）检查模块接口的正确性。（3）检查输入参数是否有合法性检查。（4）检查调用其他模块的接口是否正确。（5）检查是否设置了适当的出错处理。（6）检查表达式、语句是否正确，是否含有二义性。（7）检查常量或全局变量使用是否正确。（8）检查标识符的使用是否规范、一致。（9）

16、检查程序风格的一致性、规范性。（10）检查代码是否可以优化，算法效率是否最高。（11）检查代码注释是否完整，是否正确反映了代码的功能。2.4 测试方法测试方法静态测试可以完成以下工作：（1）发现下列程序的错误：错用局部变量和全局变量；未定义的变量、不匹配的参数；不适当的循环嵌套或分支嵌套、死循环、不允许的递归；调用不存在的子程序，遗漏标号或代码。（2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未使用过的标号；潜在的死循环。（3）提供程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背编码规则；标识符的使用方法和过程的调用层次。（4）为进一步查找做好准备。（5）选择测试用例。

17、（6）进行符号测试。2.4 测试方法测试方法2、动态测试动态方法的主要特征是计算机必须真正运行被测试的程序，通过输入测试用例对其运行情况（即输入与输出的对应关系）进行分析，达到检测的目的。动态测试包括：单元测试、集成测试、系统测试、用户的验收测试和回归测试。2.4 测试方法测试方法使用静态和动态测试进行结构和功能测试：测试阶段执行人静态校验动态校验可行性评审开发人员，用户需求评审开发人员，用户设计评审开发人员单元测试开发人员集成测试开发人员，测试人员系统测试开发人员在测试人员的协助下完成验收测试用户2.5 测试策略测试策略2.5 测试策略测试的数据流测试策略测试的数据流2.5 测试策略单元测试

18、测试策略单元测试单元测试又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。软件单元测试的目的是检测程序模块对详细设计说明书的符合程度；软件单元测试依据是单元测试计划。2.5 测试策略单元测试测试策略单元测试软件单元测试由测试工程师编制测试用例进行测试，及针对程序模块进行多次循环反复的单元测试，并将测试结果记录在针对单元测试的软件测试报告上。若程序模块通过单元测试，则按配置管理规范所规定的标识方法进行标识。2.5 测试策略单元测试测试策略单元测试模块接口测试局部数据结构测试路径测试错误处理测试边界测试 2.5 测试策略单元测试的步骤测试策略单元测试的步骤通常单元测试

19、是在编码阶段进行的。在源程序代码编制完成。经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。驱动模块：相当于所测模块的主程序。桩模块：也叫做存根模块。用以代替所测模块调用的子模块。2.5 测试策略单元测试的环境测试策略单元测试的环境2.5 测试策略测试策略单元测试完成单元测试完成单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试单元测试2.5 测试策略集成测试测试策略集成测试为什么要进行集成测试？实践表明，软件的一些模块能够单独地工作，但并不能保证组装连接之后也肯定能正常

20、工作。程序在某些局部反映不出来的问题，在全局情况下有可能暴露出来，影响软件功能的实现。可能的原因有以下几方面：（1）模块相互调用时引入了新的问题，例如数据可能没有正确传递，一模块对另一模块产生了不利的影响等。（2）几个子功能组合后不能实现预期的主功能。（3）单个模块的误差累计达到了不可接受的程度。（4）全局数据结构出现问题。2.5 测试策略集成测试测试策略集成测试集成测试(Integrated Testing)阶段是指每个模块完成单元测试后，需要按照设计时确定的程序结构图，把它们连接起来进行集成测试。集成测试也称为综合测试、组装测试、联合测试。集成测试的对象：经过单元测试的程序模块间调用关系和

21、接口数据。集成测试的目的：找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题。集成测试的测试依据：程序结构设计文档（包括概要设计说明书、详细设计说明书等）。集成测试的基本方案：非增量式测试、增量式测试。2.5 测试策略集成中的组装方法测试策略集成中的组装方法非增量式测试是采用一步到位的方法来构造测试：对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。非增量式测试的缺点：当一次集成的模块较多时，这种测试容易出现混乱，因为测试时可能发现了许多故障，为每一个故障定位和纠正非常困难，并且在修正一个故障的同时，可能又引入了新的故障，新旧故障

22、混杂，很难判定出错的具体原因和位置。2.5 测试策略集成中的组装方法测试策略集成中的组装方法 AS3S4S5d2 Cd4 Ed5 Fd1 B s1d3 s2 DABCDEFABCDEF（1）程序结构图（3）集成测试示意图（2）单元测试示意图2.5 测试策略集成中的组装方法测试策略集成中的组装方法增量式测试的集成是逐步实现的：逐次将未曾集成测试的模块和已集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。按照不同的实施次序，增量式集成测试又可以分为三种不同的方法：自顶向下增量式测试自底向上增量式测试混合增量式测试2.5 测试

23、策略集成中的组装方法测试策略集成中的组装方法自顶向下增量式测试这种集成方式是将模块按系统的程序结构自顶向下进行集成，即模块集成的顺序是首先集成主控模块（主程序），然后沿控制层次向下进行集成。从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。深度优先方式的集成：首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。广度优先方式的集成：首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集中起来，直到最底层。2.5 测试策略集成中的组装方法测试策略集成中的组装方法自顶向下增量式测试的步骤：（1）以主控模块为所测模块兼驱动模块，所有直属于主控模块的下属模块

24、全部用桩模块代替。（2）采用深度优先或广度优先的策略，用实际模块替换相应桩模块，再用桩模块代替实际模块的直接下属模块，与已测试的模块或子系统集成为新的子系统。下层的桩模块一次一次地被替换为真正的模块。（3）进行回归测试（即重新执行以前做过的全部测试或部分测试），排除集成过程中引起错误的可能。（4）判断是否所有的模块都已集成到系统中，是则结束测试，否则转到（2）去执行。2.5 测试策略集成中的组装方法测试策略集成中的组装方法 A B C D E F A S1 S2 S3 A B C D S4 S5 A B C D E F（1）（2）（3）广度优先方式广度优先方式2.5 测试策略集成中的组装方法测

25、试策略集成中的组装方法 A B C S3 E A B C D E F A S1 S2 S3 A B S2 S3 E（1）（2）（3）深度优先方式深度优先方式（4）2.5 测试策略集成中的组装方法测试策略集成中的组装方法自底向上增量式测试自底向上增量式测试这种集成方式是将模块按系统的程序结构自底向上进行集成，即从程序模块结构的最底层模块开始集成和测试。由于是自底向上进行集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。2.5 测试策略集成中的组装方法测试策略集成中的组装方法自

26、底向上增量式测试的步骤：（1）由驱动模块控制最底层模块的并行测试。（2）用实际模块代替驱动模块，与它已测试的直属子模块集成为子系统。（3）为子系统配备驱动模块，进行新的测试。（4）判断是否已集成到达主控模块，是则结束测试，否则执行（2）。2.5 测试策略集成中的组装方法测试策略集成中的组装方法 A B C D E F d2 Cd1 Ed3 Fd4 B Ed5 F D A B C D E F2.5 测试策略集成中的组装方法测试策略集成中的组装方法混合增殖式测试：对软件中、上层使用自顶向下，对软件的中下层采用自底向上。集成步骤：首先对输入输出模块和引入新算法模块进行测试；再自底向上组装成为功能相当

27、完整且相对独立的子系统；然后由主模块开始自顶向下进行增殖测试。2.5 测试策略集成测试的组织和实施测试策略集成测试的组织和实施集成测试是一种正规测试过程，必须精心计划,并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：是采用何种系统组装方法来进行组装测试。组装测试过程中连接各个模块的顺序。模块代码编制和测试进度是否与组装测试的顺序一致。测试过程中是否需要专门的硬件设备。2.5 测试策略集成测试完成的标志测试策略集成测试完成的标志成功地执行了测试计划中规定的所有组装测试。修正了所发现的错误。测试结果通过了专门小组的评审。2.5 测试策略集成测试完成的标志测试策略集成测试完成的标志

28、组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试组合测试集成测试集成测试2.5 测试策略确认测试测试策略确认测试确认测试又称有效性测试。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中已经明确规定。2.5 测试策略确认测试的步骤测试策略确认测试的步骤2.5 测试策略测试策略确认测试中的有效性测试确认测试中的有效性测试有效性测试是在模拟的环境（可能就是开发的环境）下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列的需求。在全部软件测试的测试用例运行完后，所有的测试

29、结果可以分为两类：测试结果与预期的结果相符。测试结果与预期的结果不符。2.5 测试策略测试策略确认测试中的软件配置复查确认测试中的软件配置复查软件配置复查的目的是保证软件配置的所有成分都齐全。各方面的质量都符合要求。具有维护阶段所必需的细节。而且已经编排好分类的目录。2.5 测试策略系统测试测试策略系统测试系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起测试。在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的

30、地方。2.5 测试策略系统测试测试策略系统测试由于软件只是计算机系统中的一个组成部分，软件开发完成之后，最终还要和系统中的硬件系统、某些支持软件、数据信息等其他部分配套运行。因此，软件在投入运行以前需要完成系统测试，以保证各组成部分不仅能单独的得到检验，而且在系统各部分协调工作的环境下也能正常工作。系统测试实际上是针对系统中各个组成部分进行的综合性检验。尽管每一个检验有特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能。严格的说，系统测试超出了软件工程范围。通常这项工作并不由系统开发人员或系统开发组织来承担，而是由软件用户或软件开发机构委托独立测试机构来

31、完成。2.5 测试策略系统测试测试策略系统测试系统测试与单元测试、集成测试的区别：（1）测试方法不同：系统测试属于黑盒测试，而单元测试大量采用白盒测试，集成测试则是结合使用白盒与黑盒测试方法。（2）考察范围不同：单元测试主要测试模块内部的接口、数据结构、逻辑、异常处理等对象。集成测试主要测试模块之间的接口和异常。系统测试主要测试整个系统相对于用户的需求。（3）评估基准不同：系统测试的评估基准是测试用例对需求规格的覆盖率；而单元测试和集成测试的评估主要是代码的覆盖率。2.5 测试策略测试策略系统测试的系统测试的15种测试类型种测试类型功能（机能）测试：目标中的功能是否真正实现了。批量测试：企图证

32、明程序不能处理目标中指出的大批数据。强度测试：让程序在高负荷情况下运行（微软建议72小时）。可用性测试：界面友好、错误信息简明易懂。安全性测试：设法破坏程序的保密检查。2.5 测试策略测试策略系统测试的系统测试的15种测试类型种测试类型性能测试：在一定工作负荷和配置条件下，系统响应时间及处理速度。存储量测试：测试程序所占用的内外存容量（静/动态）。配置测试：至少每一类和最大最小的设备配置情况都要测试。兼容/移植测试：对现有程序进行修改和补充后，要进行此类测试。可安装性测试：测试系统的安装过程。2.5 测试策略测试策略系统测试的系统测试的15种测试类型种测试类型可靠性测试：如平均无故障时间（MT

33、TF），需要模拟运行环境。恢复测试：测试系统出错后如何恢复正常工作的。可维护性测试：对维护过程和难易程度进行测试。文档测试：审查文档的正确性，对文档中的每个例子都要作为测试用例。工序测试：测试操作工序的次序正确性。2.5 测试策略系统测试完成测试策略系统测试完成系统联调系统联调2.5 测试策略回归测试测试策略回归测试系统维护系统维护二次开发二次开发项目更新项目更新单元测试单元测试单元测试单元测试集成测试集成测试确认测试确认测试确认测试确认测试系统测试系统测试系统测试系统测试回归测试回归测试2.5 测试策略测试策略测试和测试和测试测试测试是由一个用户在开发环境下进行的测试,也可以是开发机构内部的

34、用户在模拟实际操作环境下进行的测试。测试的目的是评价软件产品的功能、可使用性、可靠性、性能和支持，尤其注重产品的界面和特色。测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。2.5 测试策略测试策略测试和测试和测试测试测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与测试不同的是，开发者通常不在测试现场。测试的目的是衡量软件产品的功能、可使用性、可靠性、性能和支持，尤其注重产品的产品的支持性，包括文档、客户培训和支持产品生产能力。只有当测试达到一定的可靠程度时，才能开始测试。它处在整个测试的最

35、后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿2.6 验收测试验收测试验收测试是检验软件产品质量的最后一道工序。验收测试是以用户为主的测试，同时软件开发人员也有一定的参与。验收测试由用户参加设计测试用例，使用用户界面来输入测试数据，并分析测试的输出结果，一般使用生产中的实际数据进行测试。在验收测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性等进行确认。2.6 验收测试范围验收测试范围软件验收测试应完成的工作包括：明确验收项目，给定验收测试通过的标准。确定测试方法。决定验收测试的组织机构和可利用的资源。选定测试结果分析方法。制定验收测试计划并进行评审。设计验

36、收测试所用测试用例。审查验收测试准备工作。执行验收测试。分析测试结果。阐明验收测试结论，决定通过验收或是拒绝。2.6 验收测试计划验收测试计划可能包括的检验方面有以下一些：功能测试（例如，完整的工资计算过程）。逆向测试（例如，检验不符合要求数据而引起出错的恢复能力）。特殊情况（例如，极限测试、不存在路径的测试）。文档检查。强度测试（例如，大批数据或多用户同时使用）。恢复测试（例如，硬件故障或用户不良数据引起的一些情况）。可维护性评价。用户操作测试（如启动、退出系统）。用户友好性检验。安全测试。2.6 验收测试结果验收测试结果确认测试的结果，确认测试的结果有两种情况：功能和性能与用户的要求一致，

37、软件可以接受。功能和性能与用户的要求的差距。2.7 第三方测试第三方测试信息系统工程承建单位内部进行的自测被称为第一方测试，业主单位对工程进行的测试被称为第二方测试。与此相对应，由中立的第三方测试机构对系统进行的权威技术测试被称为第三方测试。国内的第三方测试工作始创于九十年初，经过了近十年的孕育，以“千年虫”问题的检 验为契机，在二十世纪末开始快速发展。2.7 第三方测试必要性第三方测试必要性国外开发商质量控制能力较强，但在比较专业的质量认证领域依然需要由第三方机构来完成。国内业主与开发商在信息技术与业务技术上的信息不对称性。国内还没有适应国情的、系列化协调配套 的、工程化的信息系统生产过程管

38、理、质量 评测、控制技术的规范和法律规程指导。2.7 第三方测试特点第三方测试特点第三方测试具有明显的工程特性，主要包括需求分析审查、设计审查、功能测试、性能测试、安全性测试、可靠性测试、易用性测试、兼容性测试、可扩充性测试、文档测试等。2.7 第三方测试特点第三方测试特点第三方测试以合同的形式制约了测试方，保证了测试工作在一开始就具有客观性。第三方能够从需求理解系统，从软件工程角度把握系统，公平的评价系统中出现的问题。第三方机构的权威性能够更好的协调用户与开发方之间的关系。2.7 第三方测试特点第三方测试特点第三方测试不同于开发方的自测试。避免开发人员的定势思维。第三方测试的目的就是为尽量多

39、地发现程序中的错误而运行程序的过程，可以更多的发现问题。随着系统越做越大，开发方很难投入足够的人力与物力进行测试工作，同时也缺乏专业的测试工具及丰富的工具使用经验。2.7 第三方测试特点第三方测试特点第三方测试不同于用户的自测试。用户熟悉业务但不熟悉计算机领域知识，很难对系统进行深入分析。用户缺乏专用的测试工具。第三方机构既往测试经验对测试的帮助。2.7 第三方测试对象第三方测试对象应用软件的确认测试、鉴定测试工程项目的系统测试、验收测试特殊项目/项目关键模块的单元测试其他：工程监理 ISO9000认证、CMM认证2.7 第三方测试开展第三方测试开展项目组成立制定方案、规范、案例与计划实施测试

40、工作问题报告回归测试测试总结、评估与测试报告第三章基本测试技术第三章基本测试技术3.1 测试生命周期3.2 测试计划3.3 测试设计3.4 测试开发3.5 测试执行3.6 测试评估3.7 测试跟踪3.1 测试生命周期测试生命周期测试计划测试计划测试计划测试计划测试设计测试设计测试设计测试设计测试开发测试开发测试开发测试开发测试执行测试执行测试执行测试执行测试评估测试评估测试评估测试评估3.2 测试计划概述测试计划概述测试目的完成的标准时间安排明确的责任测试用例库测试工具3.2 测试计划概述测试计划概述所需机器时间软/硬件配置系统组装方式记录手段回归测试3.2 测试计划具体内容测试计划具体内容目

41、的测试项（对象）测试类型测试范围测试过程资源需求（硬件、软件、人力）3.2 测试计划具体内容测试计划具体内容文档的检验进度安排测试开始、结束准则测试记录回归测试的方法测试的评估缺陷跟踪3.2 测试计划测试需求测试计划测试需求业务功能 业务流程 数据库事务 域值合法性用户界面 对象状态 窗口模式 菜单 标准尺寸的控件/文字3.2 测试计划测试需求测试计划测试需求性能 在少于3秒的情况下增加一个新顾客帐户强度 当内存很低的情况下运行应用程序 为设计规定是1,000,000 条记录的系统增加1,000,001条记录3.2 测试计划测试需求测试计划测试需求配置 显示驱动的兼容性 网络连接安装 新安装（

42、典型安装、定制安装）升级安装 网络下载3.3 测试设计测试设计测试过程测试过程包括详细的步骤以确定测试需求是否被满足。组成：测试的先决条件 输入条件 被执行的动作 期待的结果 证实期待结果的方法3.3 测试设计单元测试用例测试设计单元测试用例模块接口局部数据结构独立的路径边界条件出错处理3.3 测试设计黑盒测试用例测试设计黑盒测试用例功能不对或遗漏界面错误数据结构或外部数据库访问错误性能不满足初始化和终止错误3.3 测试设计白盒测试用例测试设计白盒测试用例保证一个模块中的所有可执行路径至少被执行一次 对所有逻辑值均需测试真和假在上下边界及可操作范围内运行所有循环检查内部数据结构以确保其有效性3

43、.3 测试设计循环测试用例测试设计循环测试用例简单循环嵌套循环串接循环非结构循环3.3 测试设计测试设计GUI测试用例测试用例窗口下拉菜单与鼠标数据项3.3 测试设计测试案例测试设计测试案例测试说明：3.3 测试设计测试案例测试设计测试案例测试案例：3.3 测试设计测试案例测试设计测试案例测试案例：3.4 测试开发测试开发功能的自动化测试工具性能的自动化测试工具中的开发3.5 测试执行测试执行概述概述目标 执行测试 查看测试结果 研究并组织对测试结果进行评估 记录缺陷输入 测试过程和测试用例输出 测试日志 缺陷报告3.5 测试执行测试执行记录结果记录结果测试日志信息执行测试过程评估意外的结果记

44、录缺陷3.5 测试执行测试执行错误等级错误等级5级：灾难性的系统崩溃、数据被破坏4级：很严重的数据被破坏3级：严重的特性不能运行，无法替代2级：中等的特性不能运行，可替代1级：烦恼的提示不正确，报警不确切0级：轻微的表面化的错误，拼写错等3.5 测试执行测试执行记录格式记录格式3.5 测试执行测试执行记录格式记录格式3.5 测试执行测试执行记录格式记录格式3.6 测试评估测试评估概述概述目标 提交测试过程的衡量标准 产生缺陷报告和测试覆盖的总结报告输入 测试日志 缺陷报告输出 测试覆盖程度 缺陷分析报告3.6 测试评估测试评估测试覆盖率测试覆盖率基于覆盖策略的系统测试 验证所有需求的完成情况

45、验证每行代码的执行情况基于测试需求的测试过程 覆盖功能和设计的需求 验证一个测试需求对应的测试过程3.6 测试评估测试评估缺陷分析缺陷分析软件质量 缺陷分析是提供验证软件质量的手段之一 测试需求的覆盖程度决定了软件测试的质量如何实例报告 缺陷分配 缺陷趋向 缺陷状态 遗留缺陷对软件的影响3.6 测试评估测试评估性能评测性能评测主要的性能评测包括动态监测：在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。响应时间吞吐量：测试对象针对特定主角或测试用例的响应时间或吞吐量的评测。百分比报告：代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。追踪报告：包括主角（测试脚本）和测试对象之间的消息会话详细信息。3.6 测试评估测试评估报告报告对上面所有的测试评估方法按规格整理成一个书面的测试评估报告，展现出软件在各种评测手段下的质量状态。3.7 测试跟踪测试跟踪记录测试事件或用户问题分析原因，定位错误进行软件修改修改结果的跟踪谢谢大家！