软件测试基本理论和方法

1、1 CSIA软件测试工程师培训软件测试工程师培训 软件测试基础理论与方法软件测试基础理论与方法2引 言 软件测试是保证软件质量的重要技术手段测试理论和测试方法测试过程及测试的管理测试工具3测试的原则原则一：穷尽测试是不可能的原则二：测试工作具有创造性，但很困难原则三：测试旨在防止错误的发生原则四：测试是有风险的原则五：测试需要有计划性原则六：测试需要有独立性4软件测试技术基础软件测试技术基础 6.1、测试的目的、测试的目的6.2、测试的原则、测试的原则6.3、测试的层次结构、测试的层次结构6.4、测试阶段、测试阶段6.5、测试方法、测试方法6.6、测试种类、测试种类6.7、测试自动化、测试自动

2、化6.8、小结、小结51、测试的目的、测试的目的 测试是通过运行程序来发现错误的过程测试是通过运行程序来发现错误的过程 测试可以说明软件存在错误，但不能说测试可以说明软件存在错误，但不能说明它不存在错误明它不存在错误 目的：用相对少的测试尽可能多地找到目的：用相对少的测试尽可能多地找到程序中的缺陷程序中的缺陷62、测试的原则、测试的原则 一个好的测试用例具有较高的发现过去未被发一个好的测试用例具有较高的发现过去未被发现过的错误的概率，而不应只表明程序运行正现过的错误的概率，而不应只表明程序运行正常常 自己不能测试自己编写的程序自己不能测试自己编写的程序 对期望结果的描述是每个测试用例的必要组成

3、对期望结果的描述是每个测试用例的必要组成部分部分 杜绝不能重现或匆忙的测试杜绝不能重现或匆忙的测试 既要编写使用有效输入条件的测试用例，也要既要编写使用有效输入条件的测试用例，也要编写使用非法输入条件的测试用例编写使用非法输入条件的测试用例 深入细致地审查测试结果深入细致地审查测试结果72、测试的原则、测试的原则 如果一段程序中发现的缺陷数量增加，则意味如果一段程序中发现的缺陷数量增加，则意味着有更多未被发现的缺陷的可能性也在增加着有更多未被发现的缺陷的可能性也在增加 让最优秀的人员去完成测试让最优秀的人员去完成测试 保证软件可测试性是软件设计的一个重要目标保证软件可测试性是软件设计的一个重要

4、目标 不要为了测试方便而修改程序不要为了测试方便而修改程序 测试工作必须在任务建立之初就确定目标测试工作必须在任务建立之初就确定目标83、测试的层次结构、测试的层次结构类型方法阶段举例：功能算法正向反向可用性边界验收测试确认测试集成测试单元测试白盒黑盒自顶向下自底向上模拟用户操作94、测试阶段、测试阶段 单元测试单元测试 组装测试组装测试 确认测试确认测试 验收测试验收测试104.1、单元测试、单元测试 单元测试的目的是在一个隔离环境中对单元测试的目的是在一个隔离环境中对独立的软件模块进行测试以发现其中的独立的软件模块进行测试以发现其中的缺陷缺陷。114.1、单元测试、单元测试124.2、集成

5、测试、集成测试 集成测试的目的是当模块组装后查找模集成测试的目的是当模块组装后查找模块间接口的错误块间接口的错误134.3、确认测试、确认测试 确认测试的目的是确定软件是否满足软确认测试的目的是确定软件是否满足软件需求规格说明所提出的所有需求件需求规格说明所提出的所有需求144.4、验收测试、验收测试 用户参与的确认测试用户参与的确认测试155、测试方法、测试方法 黑盒测试方法黑盒测试方法 白盒测试方法白盒测试方法 自顶向下方法自顶向下方法 自底向上方法自底向上方法 模拟用户操作测试方法模拟用户操作测试方法165.1、黑盒测试方法、黑盒测试方法 黑盒测试也称功能测试或数据驱动测试，黑盒测试也称

6、功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。测试来检测每个功能是否都能正常使用。176.5.2、白盒测试方法、白盒测试方法 白盒测试也称结构测试或逻辑驱动测试，白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说试来检测产品内部动作是否按照规格说明书的规定正常进行明书的规定正常进行。186.5.3、自顶向下或自底向上方法、自顶向下或自底向上方法 依据模块在模块层次中的位置，对模块依据模块在模块层次中的位置，对模块组装并测试，属

7、于增量组装测试方法。组装并测试，属于增量组装测试方法。196.5.4、模拟用户操作测试方法、模拟用户操作测试方法 着重对那些用户可能发现的错误进行测着重对那些用户可能发现的错误进行测试及修改工作试及修改工作206.6、测试类型、测试类型 功能测试功能测试 算法测试算法测试 正向测试正向测试 反向测试反向测试 可使用性测试可使用性测试 边界测试边界测试 平台测试平台测试 负载负载/ /强度测试强度测试216.7、自动化测试、自动化测试 6.7.16.7.1、属性及优点、属性及优点 6.7.26.7.2、主要分类、主要分类 6.7.36.7.3、实现类型、实现类型 6.7.46.7.4、注意的问题

8、、注意的问题226.7.1、属性及优点属性及优点 速度。速度。例如手工测试例如手工测试Windows计算器，假定平均每计算器，假定平均每5秒钟执行一个测试案例，那么数千个案例需要数小时秒钟执行一个测试案例，那么数千个案例需要数小时的时间。而自动化能够以成千上万倍的速度来执行。的时间。而自动化能够以成千上万倍的速度来执行。 效率。效率。测试工具减少了执行测试案例的时间，有更测试工具减少了执行测试案例的时间，有更多的时间进行测试计划考虑新的测试用例。多的时间进行测试计划考虑新的测试用例。 准确度和精确度。准确度和精确度。尝试执行百个测试用例之后，尝试执行百个测试用例之后，注意力就会分散，开始犯错误

9、。测试工具每次执行同注意力就会分散，开始犯错误。测试工具每次执行同样的测试，并毫无差错地检查结果。样的测试，并毫无差错地检查结果。 坚持不懈。坚持不懈。测试工具和自动化永远不会累倒或半途测试工具和自动化永远不会累倒或半途而废。而废。236.7.2、主要分类主要分类 回放类型自动测试工具回放类型自动测试工具 代码分析器：复杂度等代码分析器：复杂度等 覆盖分析器覆盖分析器 内存分析器内存分析器 强度测试工具强度测试工具 web测试工具测试工具 其它其它测试用例管理、文档管理、测试用例管理、文档管理、bug reporting、配置管理、配置管理 246.7.3、实现类型实现类型 宏录制和回放。宏录

10、制和回放。 最基本的测试自动化类型时录制第一次执最基本的测试自动化类型时录制第一次执行测试用例时的键盘和鼠标操作，然后在需行测试用例时的键盘和鼠标操作，然后在需要重新执行时回放要重新执行时回放 可编程的宏可编程的宏 编写回放系统遵守的简单指令编写回放系统遵守的简单指令 完全可编程的自动测试工具完全可编程的自动测试工具 提供编程语言提供编程语言256.7.4、注意的问题注意的问题 软件变更软件变更 人眼和直觉是不可替代的人眼和直觉是不可替代的 验证难以实现验证难以实现 容易过分依赖自动化容易过分依赖自动化 不要花费太多时间使用达不到测试软件目的的不要花费太多时间使用达不到测试软件目的的测试工具和

11、自动化测试工具和自动化 编写宏、开发工具都属于开发工作，应该遵守编写宏、开发工具都属于开发工作，应该遵守要求程序员遵守的相同标准和规范要求程序员遵守的相同标准和规范 某些工具是侵入式的，可能导致测试的软件不某些工具是侵入式的，可能导致测试的软件不正常失败。正常失败。266.8、小结、小结测试的目的测试的目的测试的原则测试的原则测试的层次结构测试的层次结构测试阶段测试阶段测试方法测试方法测试种类测试种类测试自动化测试自动化27软件测试理解1 软件测试活动2 测试过程3 测试方法4 测试类型5 测试策略6 小结281 软件测试活动 测试是从大量的测试用例中选择有限的测试用例发现软件中的大部分缺陷的

12、一种技术 好的测试用例的4个特性：1.检测软件质量的有效性，是否能发现缺陷，或至少可能发现缺陷；2.可仿效的测试用例可以测试很多内容，因而减少测试用例的数量；3.经济性，测试用例的执行、分析和调试是否经济4.测试用例的可修改性，每次软件修改后对测试用例的维护成本如何实现？29测试活动 计划 编制测试计划：标志测试条件（确定测试什么）和测试的优先级 设计 设计测试用例（确定怎么测试） 开发 测试开发（设计脚本、数据等） 执行 执行测试用例 将测试结果与期望结果进行比较 评估 30测试活动 1计划阶段内容：人员、进度、资源。p测试条件取决于被测试验证的项目或事件。p测试条件是被测环境的描述。可以用

13、多种方式描述：如简单的语言，表格项形式或类似于流图的图表形式；p标识测试条件的活动最好与开发活动（即V模型左边的活动）并行开展31测试活动 2 设计阶段 内容：设计测试用例、预期结果p测试用例（test case）是按一定顺序执行的与测试目标（test object, 测试理由或目的）相关的一系列测试。p测试用例设计将产生许多测试所包括的运行测试的有关信息（如环境要求，也称为先决条件）、输入值、期望结果。p期望输出包括应输出或建立的内容，应修改或更新或应删除的内容。期望输出集可以是一个很大的集合。32测试活动测试活动测试用例：POS1036先决条件： 作为数据输入员注册到定单系统显示的主菜单

14、数据库系统必须含有标准数据集合 确保系统中没有其他活跃的新定单活动 步骤输入期望输出测试条件1建立用任何一个标准的订单项建立一个新订单，设置订单数为100显示订单确认信息VB10VB202确认订单打印具有正确细目购置订单VB103打印新订单报表打印的新订单报表就是新创建的订单VB10VB234取消订单打印正确的取消购置订单信息VB85打印新订单报表无打印订单输出VB833测试活动测试活动 3开发阶段开发阶段开发测试用例包括: 准备测试脚本、测试输入、测试数据以及期望输出。p测试脚本（test script）是具有正规语法的数据和指令的集合，在测试执行自动工具使用中，通常以文件形式保存；p必须先

15、完成测试用例的先决条件（precondition），然后再执行测试。测试用例可能要求专门的硬件或软件，如网络环境或打印机等；p期望输出可以组成文件形式用于自动工具。对于手动测试，期望输出仅仅只是简单地记录在手工测试过程或脚本中。对于自动测试，其期望输出比设置用于手工测试的期望输出复杂得多。在自动工具中要求每项内容都要拼写正确，而在手工测试中要求没这么严格。p测试开发的任何工作可以提前进行（相对V模型左边的活动进行），以后可以节省时间。34测试活动测试活动 4执行阶段执行阶段 执行测试用例p对于手动测试：测试者按事先准备好的手工过程进行测试，测试者输入数据、观察输出、记录发现的问题。p对于自动测

16、试：可能只需要启动测试工具，并告诉工具执行哪些测试用例；p测试执行只能在软件开发完成后进行，即V模型右边的活动。35测试活动 5评估阶段 将测试结果与期望输出进行比较p应该对每次测试的实际输出进行分析研究，判断软件功能是否正确。p验证可以是测试者的主观判断，也可以是将实际输出与期望输出进行严格准确的比较。p信息比较，如可以在执行测试时进行显示屏幕上的信息，另一些输出比较，如修改数据库记录，只能在测试执行结束后进行。p自动测试一般结合了信息比较的两种方法。36软件测试与软件工程模型V模型介绍扩展：左边的每一部分还包括评审，也是测试任务。需求需求验收测试验收测试系统测试系统测试集成测试集成测试单元

17、测试单元测试概设概设详设详设编码编码测试测试测试编码测试编码测试运行测试运行测试测试测试测试测试测试37测试设计基于需求分析 缺陷预防：是指各种错误遗留到后续开发阶段之前，运用各种技术和过程来发现和避免这些错误。 最有效的测试工作应该开始于需求； 对于每一条需求，如果可以设计出一个过程来执行所测试的功能，若输出结果是可以预先知道的，并且能够通过编程或者人工方法加以验证，则称该需求是可测试的； 测试人员需要彻底了解产品，只有这样他们才能设计出更出色和更全面的测试计划，测试设计和测试过程和测试用例。38测试人员及早介入 避免在项目生命周期中的后续阶段对产品的功能行为不理解 了解应用程序的哪些方面对

18、最终用户而言是最关键以及哪些元素的风险最大 测试重点放在应用程序中最重要的部分，避免对不经常使用的部分过度测试而对重要的部分又测试不充分。39RequirementsspecificationRequirementsverificationFunctional designspecificationFunctional designverificationCode and spec modification System and acceptance validationCode and spec modification Function validation Code and spec m

19、odification Integration validation Product simulation Usability test Code Code verification Code and spec modification Unit validation 12Internal designspecificationInternal design verification4597108113640测试的生命周期测试的生命周期p在软件开发生命周期中，软件是通过迭代来不断加以完善的。p在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。41测试的生命周

20、期测试的生命周期42测试活动的信息流 被测模块 设 软 系统 客 计 件 其他 户 信 需 元素 参 息 求 与 被测模块 被测模块 单元测试 单元测试 单元测试 集成测试 确认测试 系统测试 验收测试 已经测试过的模块 已集成的软件 已确认的软件 可交付的软件 43测试阶段的信息流测试阶段的输入信息有两类：p软件配置：这是测试的对象，包括 需求说明书 设计说明书 被测的源程序等。p测试配置：包括 测试计划 测试步骤 测试用例（测试数据） 具体实施测试的测试程序 测试工具等 44RUP中 定义测试的目的在于： pFinding and documenting defects in softwa

21、re quality. pGenerally advising about perceived software quality. pProving the validity of the assumptions made in design and requirement specifications through concrete demonstration. pValidating the software product functions as designed. pValidating that the requirements have been implemented app

22、ropriately. 45RUPActivities活动46RUP-2001Artifacts工件472 测试过程2.1 单元测试2.2 集成测试2.3 系统测试2.4 验收测试482.1 单元测试p目的：分别完成每个单元的测试任务，以确保每个模块能正常工作。 p单元测试-RUP 单元测试在迭代的早期实施，侧重于核实软件的最小可测试元素。单元测试通常应用于实施模型中的构件，核实是否已覆盖控制流和数据流，以及构件是否可以按照预期工作。这些期望值建立在构件参与执行用例的方式的基础上，参与方式可参见该用例的序列图。实施员在单元的开发期间执行单元测试。实施工作流程对单元测试作出了详细描述。49单元测

23、试的考虑 p算法和逻辑p模块接口p数据结构（全局和局部）p边界条件p独立的路径p错误处理 50单元测试的辅助模块 p驱动程序：用于模拟主程序的运行p桩模块：用于模拟子程序的运行51单元测试的过程 522.2 集成测试p为什么进行集成测试？ 一个模块可能对另一个模块产生不利的影响 将子功能合成时不一定产生所期望的主功能 独立可接受的误差，在组装后可能会超过可接受的误差限度 可能会发现单元测试中未发现的接口方面的错误 在单元测试中无法发现时序问题（实时系统） 在单元测试中无法发现资源竞争问题p集成测试的目的：在模块组装后查找模块间接口的错误53集成测试-RUPp执行集成测试是为了确保当把实施模型中

24、的构件集成起来执行用例时，这些构件能够正常运行。p测试对象是实施模型中的一个包或一组包。p要集成的包通常来自于不同的开发组织。p集成测试将揭示包接口规约中不够完全或错误的地方。54集成测试的方法p非增式测试：采用一步到位的方法来构造测试：对所有模块进行个别的单元测试后，按程序结构图将各模块联接起来，把联接后的程序当作一个整体进行测试。p增式测试 ：把下一个要测试的模块同已经测试好的模块结合起来进行测试，一次增加测试的模块。55非增式测试 56增式测试 增式测试把单元测试与集成测试结合起来进行，将模块逐步集成起来，逐步完成集成测试。 实施方法： 自顶向下结合 自底向上结合 57两种集成方法的比较

25、非增式测试增式测试工作量工作量大工作量小接口错误发现错误较晚发现错误早错误定位错误定位难错误定位易测试程度测试不彻底测试彻底需要的机器量需要机器量少需要机器量多测试的并行性并行性好并行性差58自顶向下增式测试 p集成步骤：主控模块作为测试驱动，所有与主控模块直接相连的模块作为桩模块；根据集成的方式（深度或广度），每次用一个替换从属的桩模块；在每个模块被集成时，都必须已经进行了单元测试；进行回归测试以确定集成新模块后没有引入错误p上述过程从第2步重复进行，直到整个系统结构被集成完成。 59自顶向下增式测试60自底向上增式测试p工作程序： 组装从最底层的模块开始，组合成一个构件，用以完成指定的软件

26、子功能 编制驱动程序，协调测试用例的输入与输出； 测试集成后的构件 按程序结构向上组装测试后的构件，同时除掉驱动程序61自底向上增式测试62两种集成测试方法的比较 优点缺点自顶向下测试 可以自然地做到逐步求精，一开始便能让测试者看到系统的框架 需要提供桩模块 在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难 由于桩模块不能模拟数据，如果模块间的数据流不能构成有向的非环状图，一些模块的测试数据难于生成； 观察和解释测试输出往往也是困难的 自底向上测试 由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也没有困难 特别适合于关键模块在结构图底部的情况 直到

27、最后一个模块被加进去之后才能看到整个程序（系统）的框架 只有到测试过程的后期才能发现时序问题和资源竞争问题63讨 论p在你的工作中采用了集成测试吗？如何做的？p集成测试过程中最关键的问题是什么？642.3 系统测试 p系统测试实际上是针对系统中各个组成部分进行的综合性检验。p尽管每一个检验有着特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能 。p系统测试-RUP当将软件作为整体运行或实施明确定义的软件行为子集时，即可进行系统测试。这种情况下的目标是系统的整个实施模型。65认识系统测试 什么是系统测试为了发现缺陷并度量产品质量，按照系统的功能和性能需求进

28、行的测试 一般使用黑盒测试技术 一般由独立的测试人员完成对于模块之间交互性比较强的软件，还会有单独的集成测试，用来发现模块接口之间的错误66认识系统测试 客户和用户 Customer v.s. User都是利益相关者，但是终极关注的是客户 客户是衣食父母，不是上帝尊重客户的需求与客户沟通，让他理解你的困难和方案，给他咨询 客户是人，人就会犯错误67认识系统测试 系统测试的常见内容1、功能测试 目标：对产品的功能进行测试，检验是否实现、是否正确实现 方法：覆盖产品的功能 工具：回归测试时候可以使用工具68认识系统测试 系统测试的常见内容2、性能测试 目标：对产品的性能进行测试，检验是否达标、是否

29、能够保持 方法：覆盖系统的性能需求，一般和负载测试结合使用 工具：在需要大访问量时候尤其需要使用工具69认识系统测试 系统测试的常见内容3、负载测试 目标：在人为设置的高负载(大数据量、大访问量)的情况下，检查系统是否发生功能或者性能上的问题 方法：人为生成大数据量，并利用工具模拟频繁并发访问 工具：一般需要使用工具70认识系统测试 系统测试的常见内容4、压力测试 目标：在人为设置的系统资源紧缺情况下，检查系统是否发生功能或者性能上的问题 方法：人为减少可用的系统资源，包括：内存、硬盘、网络、CPU占用、数据库反应时间 工具：一般需要使用工具71认识系统测试 系统测试的常见内容5、疲劳测试 目

30、标：在一段时间内(经验上一般是连续72小时)保持系统功能的频繁使用，检查系统是否发生功能或者性能上的问题 方法：人为设置不同功能的连续重复操作 工具：一般需要使用工具72认识系统测试 系统测试的常见内容6、易用性测试 目标：检查系统界面和功能是否容易学习、使用方式是否规范一致，是否会误导用户或者使用模糊的信息 一般与功能测试结合使用 方法：可以采用用户操作、观察(录像)、反馈并评估的方式73认识系统测试 系统测试的常见内容7、安装测试 目标：检查系统安装是否能够安装所有需要的文件/数据并进行必要的系统设置；检查系统安装是否会破坏其他文件或配置；检查系统安装是否可以中止并恢复现场；检查系统是否能

31、够正确卸载并恢复现场；检查安装和卸载过程的用户提示和功能是否出现错误有时候将安装测试作为功能测试的一部分74认识系统测试 系统测试的常见内容8、配置测试 目标：在不同的硬件配置下，在不同的操作系统和应用软件环境中，检查系统是否发生功能或者性能上的问题 方法：一般需要建立测试实验室，IE4.0测试实验室建立花费了$200万75认识系统测试 系统测试的常见内容9、文档测试 目标：检查系统的文档是否齐全，检查是否有多余文档或者死文档，检查文档内容是否正确/规范/一致，检查CI是否正确 方法：一般由单独的一组测试人员实施76认识系统测试 系统测试的常见内容10、安全测试(包括病毒、加密、权限) 目标检

32、查系统是否有病毒检查系统是否正确加密检查系统在非授权的内部或外部用户访问或故意破坏时候是否出现错误77认识系统测试 系统测试的常见内容11、恢复测试 目标：在人为使发生系统灾难(系统崩溃、硬件损坏、病毒入侵等)的情况下，检查系统是否能够恢复被破坏的环境和数据78认识系统测试 系统测试的常见内容12、回归测试 目标：检查系统变更之后是否引入新的错误或者旧的错误重新出现，尤其是在每次Biuld之后和稳定期测试的时候 工具：一般使用工具，一般依赖于测试用例库和缺陷报告库79认识系统测试 系统测试的常见内容13、健全测试 目标：检查系统的功能和性能是否基本可以正常使用，来确定是否可以继续进行系统测试的

33、其他内容 方法：正常安装，并使用正常情况下的测试用例对主要功能进行测试；同时检查系统文档是否齐全80认识系统测试 系统测试的常见内容14、交付测试 目标：关闭所有缺陷报告，确保系统达到预期的交付标准 方法：一般需要结合回归测试，并谨慎处理新出现的Bug 交付测试也称为稳定期测试，有时候与系统测试独立划分81认识系统测试 系统测试的常见内容15、演练测试 目标：在交付给用户之前，利用相似的用户环境进行测试例如：奥运会MIS系统在2008年前用于其他比赛82认识系统测试 系统测试的常见内容16、背靠背测试 目标：设置一组以上的测试团队，在互相不进行沟通的情况下独立进行相同的测试项目，用来评估测试团

34、队的效果并发现更多的错误 开始用于测试外包，现在也用于内部测试83认识系统测试 系统测试的常见内容17、度量测试 目标：在系统中人为地放入错误(播种)，并根据被发现的比例来确定系统中遗留的错误数量 开始用于测试外包，现在也用于内部测试84认识系统测试 系统测试的常见内容18、比较测试 目标：与竞争产品及本产品的旧版本测试同样的内容，来确定系统的优势和劣势 严格地说，比较测试属于系统测评的内容 BenchMarking是一种特殊的比较测试85认识系统测试 系统测试的常见内容实际上，以上18种测试内容并不是都要进行的，而是在制定测试策略和测试计划的时候有不同的侧重点，这与测试目标、测试资源、软件系

35、统特点和业务环境有关。862.4 验收测试 验收测试是检验软件产品质量的最后一道工序。验收测试的目的是确保软件准备就绪，并且可以供最终用户用于执行软件的既定功能和任务。验收测试主要在于它突出了客户的作用，这是与前面讨论的各种测试活动不同之处。用户在现场或直接参与测试。验收测试可以重复确认测试中所使用的全部测试或部分测试，或采用完全由用户自己开发的测试。 87验收测试1. 正式验收2. 非正式验收或Alpha测试3. Beta测试p选择的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。p某些验收测试（如工厂验收而不是现场验收）是部署软件之前的最后一个测试操作。此时采用后两种测试方法8

36、8验收测试的范围 明确验收项目，规定验收测试通过的标准；确定测试方法；决定验收测试的组织机构和可供利用的资源；选定测试结果分析方法；制定验收测试计划并进行评审；设计验收测试所用测试用例；审查验收测试准备工作；执行验收测试；分析测试结果；阐明验收测试结论，决定通过验收或是拒绝 89确认测试p 确认测试是检验所开发的软件是否能按顾客提出的要求运行。p若能达到这一要求，则认为开发的软件是合格的，确认测试也称为合格性测试 90测试和测试通常由用户或其他人（非开发人员和测试人员）来完成测试：在开发即将完成时对应用进行的测试，此时仍然允许对设计作微小的变动;测试：在开发基本完成时进行，于正式发布之前寻找程

37、序中的错误913 测试方法p静态方法和动态方法 p黑盒测试和白盒测试p回归测试方法p自顶向下方法和自底向上方法p模拟用户操作测试方法p自动方法和手工方法92静态方法和动态方法 p静态方法的主要特征是在用计算机测试源程序时，计算机并不真正运行被测试的程序，只对被测程序进行特性分析。因此，静态方法常称为“分析”，静态分析是对被测程序进行特性分析的一些方法的总称。p动态方法的主要特征是计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况(输入/输出的对应关系)进行分析。 93黑盒测试 p黑盒测试（Blackbox Testing）又称功能测试、数据驱动测试或基于规格说明的测试，是一种从用户

38、观点出发的测试。p被测程序被当作一个黑盒，不考虑程序内部结构和内部特性，测试者只知道该程序输入和输出之间的关系或程序的功能，依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。p软件的黑盒测试被用来证实软件功能的正确性和可操作性。 94白盒测试白盒测试（Whitebox Testing）又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序细节的严密检验，针对特定条件和/与循环集设计测试用例，对软件的逻辑路经进行测试。在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致。软件的白盒测试用来分析程序的内部结构95白盒测试 白盒测试要求对某些

39、程序的结构特性做到一定程度的覆盖，或者说是“基于覆盖的测试” 。 最为常见的程序结构覆盖有：语句覆盖：它要求被测程序的每一可执行语句在测试中尽可能都检验过，这是最弱的逻辑覆盖准则；分支覆盖或判定覆盖：要求程序中所有判定的分支尽可能得到检验；条件覆盖：当判定式中含有多个条件时，要求每个条件的取值均得到检验；判定条件覆盖：同时考虑条件的组合值及判定结果的检验；路径覆盖：只考虑对程序路径的全面检验。取得测试覆盖的方法程序插装 96黑盒测试与白盒测试的比较 黑 盒 测 试 白 盒 测 试 测 试 规 划 根据用户的规格说明，即针对命令、信息、报表等用户界面及体现它们的输入数据与输出数据之间的对应关系，

40、特别是针对功能进行测试。 根据程序的内部结构，比如语句的控制结构，模块间的控制结构以及内部数据结构等进行测试。 优 点 能站在用户立场上进行测试。 能够对程序内部的特定部位进行覆盖测试。 特 点 缺 点 不能测试程序内部特定部位。 如果规格说明有误，则无法发现。 无法检验程序的外部特性。 无法对未实现规格说明的程序内部欠缺部分进行测试。 方 法 举 例 基于图的测试 等价类划分 边值分析 比较测试 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 基本路径覆盖 循环覆盖 模块接口测试 97回归测试p目标： 修改的或增加的部分是正确的 没有引起其他部分产生错误p应用：增量开发 版本控制 软件维护98

41、回归测试方法举例： 全部再测试（Retest All) 再测试风险用例(Retest Risky Use Case) 按纲要再测试(Retest by Profile) 再测试修改的段(Retest Changed Segments) 防火墙内再测试（Retest Within Firewall）99模拟用户操作测试方法p基于对用户如何使用被测试软件的了解来开发测试的方法。p经验告诉我们，复杂的软件产品有许多错误，但用户一般只能找出这些错误中很少的一部分。p为给用户带来最大利益，要着重对那些用户可能发现的错误进行测试和修改工作。1004 测试类型p（质量维度1） 可靠性测试p完整性测试：侧重于

42、评估测试对象的强壮性（防止失败的能力），语言、语法的技术兼容性以及资源利用率的测试。该测试针对不同的测试对象实施和执行，包括单元和已集成单元。 p结构测试：侧重于评估测试目标是否符合其设计和构造的测试。通常对基于 Web 的应用程序执行该测试，以确保所有链接都已连接、显示正确的内容以及没有孤立的内容。101测试类型（质量维度2） 功能测试p配置测试：侧重于确保测试对象在不同的硬件和/或软件配置上按预期运行的测试。该测试还可以作为系统性能测试来实施。 p功能测试：侧重于核实测试对象按计划运行，提供需求的服务、方法或用例的测试。该测试针对不同的测试对象实施和执行，包括单元、已集成单元、应用程序和系

43、统。 p安装测试：侧重于确保测试对象在不同的硬件和/或软件配置上，以及在不同的条件下（磁盘空间不足或电源中断）按预期安装的测试。该测试针对不同的应用程序和系统实施和执行。 p安全测试：侧重于确保只有预期的主角才可以访问测试对象、数据（或系统）的测试。该测试针对多种测试对象实施和执行。 p容量测试：侧重于核实测试对象对于大量数据（输入和输出或驻留在数据库内）的处理能力的测试。容量测试包括多种测试策略，如创建返回整个数据库内容的查询；或者对查询设置很多限制，以至不返回数据；或者返回每个字段中最大数据量的数据条目。102测试类型（质量维度（质量维度3 3） 性能测试性能测试p基准测试：一种性能测试，

44、该测试将比较（新的或未知的）测试对象与已知的参照负载和系统的性能。 p竞争测试：侧重于核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受的测试。 p负载测试：一种性能测试，用于在测试的系统保持不变的情况下，核实和评估系统在不同负载下操作极限的可接受性。 评测包括负载和响应时间的特征。如果系统结合了分布式构架或负载平衡方法，将执行特殊的测试以确保分布和负载平衡方法能够正常工作。 p性能曲线：在该测试中，将监测测试对象的计时配置文件，包括执行流、数据访问、函数和系统调用，以确定并解决性能瓶颈和低效流程。 p强度测试：一种性能测试，侧重于确保系统可在遇到异常条件时按预期运

45、行。系统面对的工作强度可以包括过大的工作量、不充足的内存、不可用的服务/硬件或过低的共享资源。103测试类型其他测试术语其他测试术语p恢复测试（例如，硬件故障或用户不良数据引起的一些情况）p兼容性测试 对软硬件、操作系统、网络的兼容性测试p比较测试 与同类产品进行比较，列出优缺点 p算法测试 确定是否已正确实现算法p正向测试 确定正确使用软件是软件某一特性产生的结果是否与需求一致p逆向测试 确定软件无效输入或非法操作的处理是否合理p边界测试 测试产品特定的限制，如最大值、最小值，确定软件在这些特定的限制下是否能正常工作p时序测试p突变测试（mutation testing） 判断测试用例是否有效的方法 p等等1045 测试策略测试阶段目的执行者测试方法单元测试查找独立模块中逻辑错误、数据错误和算法错误软件工程师结构测试集成测试查找模块之间接口错误软件工程师测试人员结构测试、自顶向下或自底向上回归