软件测试知识点总结

第1章 软件测试基础

1．知识点

1.1 件测试的工件模型与知道体系

1.2 件测试的核心概念与基础是的什么？为什么？ 1.3 件生命周期相关的知识点，测试与开发的关系 1.4 悉软件测试 的工件内容与职业发展方向 1.5 了解软件研发的流程与项目组织架构

1.6 掌握测试与调试的区别，错误、缺陷、故障、失效的别 1.7 掌握为什么软件会有问题？bug P21

2．软件测试的概念

2.1 软件测试的定义

目前没有公认的非常完整的定义形式。 软件测试定义如下：“使用人工和自动的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。”

2.2 软件测试的目的

Grenford J.Myers 曾对软件的目的提出过以下观点：

（1） 测试是为了发现程序中的错误而执行程序的过程；

（2） 好的测试文案是竟可能的发现迄今为止尚未发现的错误的测试方案； （3） 成功的测试执行是发现迄今为止尚未发现的错误的测试执行

然而，这种观点指出测试是以查找错误为中心，而不是为演示软件的正确功能，而实际上：

（1） 测试并不仅仅是为了找出错误，通过分析错误产生的原因和错误的发展趋

势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进。同时，这种分析方法也能帮助我们设计有针对性的检测方法，改善测试的有效性；

（2） 没有发现错误的测试也是有价值的，完整测试是评定软件质量的一种方法； （3） 保证整个软件开发过程是高质量的； （4） 增强人们对软件质量的信心。

2.3 软件测试的原则

（1）群集效应，80%的bug聚集在20%的模块； （2）测试不能证明软件没有问题；

（3）穷举测试是不可能的（风险） 如：输入； （4）尽早测试（发现缺陷及修改缺陷的成本低）； （5）并非所有的软件错误都能修复； （6）由小到大的测试范围； （7）避免检查自己的代码； （8）追溯至用户需求；

（9）软件测试是有风险的行为。

2.4 软件生命周期

软件的生命周期（SDL,Systems Development Life Cycle）是软件的产生直到报废的生命周期，它包括：计划（Planning），需求分析（Requirement Analysis），设计（Design），程序编码（Coding），测试（Testing），运行与维护（Run and Maintenance）。 典型的几种生命周期模型包括：瀑布模型、快速原型模型、迭代模型。

2.5 测试与开发的关系

制造企业，软件开发人员就是生产加工的工人，而软件测试的就相当于质检人员。软件测试贯穿于软件开发的整个过程。

1. 没有软件开发就没有软件测试，软件开发提供软件测试的对象； 2. 软件开发和软件测试都是软件生命周期中的重要组成部分； 3. 软件开发和软件测试都是软件过程中的重要活动； 4. 软件测试是保证软件开发产物质量的重要手段。

2.6 测试与调试的区别

测试的根基在于需求和用户，如果开发人员的编码或设计是错误的，即便通过调试，如果和需求相违背，测试也是过不去的。

2.7 缺陷的类型

遗漏：规定的或预期的需求未体现在产品中（可能未将规格说明全面的实现，也可能需求分析阶段就遗漏了需求）

错误：未将规格说明正确实现（可能设计错误，也可能编码错误） 额外的实现：规格说明中并未规定的需求被纳入产品，得到实现

缺陷：存在于软件之中的偏差，可被激活，以静态的形式存在于软件内部，相当于bug 故障：当缺陷被激活后，软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为

失效：软件运行时产生的外部异常行为结果，表现为与用户需求不一致，功能能力终止，用户无法完成需要的应用

以上类型总结为一句话：人的错误行为导致缺陷产生，缺陷被激活后，被触发导致故障，无人修复，就会失效。

2.8 导致缺陷的根源

导致缺陷的根源：客观的环境因素和主观的人为因素 （1） 缺乏有效的沟通，或没有进行沟通； （2） 软件复杂度； （3） 编程错误；

（4） 不断的变更需求； （5） 时间的压力； （6） 缺乏文档的代码； （7） 软件的开发工具； （8） 人员的自大。

2.9 什么是测试用例

测试用例：是指对一项特定的软件产品测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等并形成文档。

2.10 什么是测试执行

测试执行是根据测试用例在真实（或模拟真实）的环境下运行被测试的对象 （1） 一个测试用例的执行 （2） 一个测试用例集的执行

目的：发现软件中存在的缺陷，并将结果记录下来向上级汇报。 依据：《测试需求文档》、《测试计划》、《测试执行计划》、《测试用例》。

为什么要做测试执行记录？

（1） 保证测试工作的可追溯性； （2） 记录测试人员的工作环境； （3） 绩效评估的重要依据。

记录的内容：什么人（测试执行人员），在什么时间（Date），做了什么（Case ID）、结

果如何（Pass/Fail）

2.11 常见的软件研发基本流程

1. 瀑布模型：线形，无适应需求变更 2. 螺旋模型：基于风险，把一个项目分成若干小项目，客户始终参与 3. RUP( Rational Unified Proces)统一软件过程模型： 特点（1）增量迭代的开发与测试； （2）优先处理风险高；

（3）以架构为中心（高内聚，低耦合）可扩展性好； （4）自动化驱动测试（老测试）； （5）宏观上并行，微观上瀑布。

2.12 测试方法

测试需求分析（what to test） 测试用例分析（how to test） 测试交互分析

2.13 测试工具

解决测试手段（模拟）LoadRunner 提高效率 自动化QTP 管理类工具

2.14 测试流程

控制质量、进度和成本（三大要素）

3. 测试工程师的主要职责

测试工程师的主要职责是： 1． 检视代码、评审开发文档；

2． 进行测试设计、写作测试文档（测试计划、测试方案、测试用例等）； 3． 执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到修正； 4． 通过测试度量软件的质量。

利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具。设计和维护测试系。对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。

4. 面试题

第2章 测试过程

1. 知识点

1.1 阶段划分 1.2 测试模型 1.3 测试过程

2. 测试阶段划分

测试阶段划分

2.1 单元测试

单元测试是针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作。

目的是检测软件模块对《详细设计说明书》的符合度。

2.2 集成测试

集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。

目的是检测软件模块对《概要设计说明书》的符合程度。

2.3 系统测试

系统测试是将已集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机的硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作。

目的在于通过与《需求规格说明书》作比较，发现软件与系统需求定义不符合或与之矛盾的地方。

2.4 单元测试、集成测试和系统测试的比较

1） 测试方法不同

单元测试属于白盒测试范畴（验证程序设计） 集成测试属于灰盒测试范畴（验证程序设计）

系统测试属于黑盒测试范畴（验证系统设计）

2） 考察范围不同

单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等 集成测试主要测试模块之间的接口各接口数据传递关系，以及模块组合后的整体功能

系统测试主要测试整个系统相对于需求的符合度

3）评估基准不同

单元测试的评估基准主要是逻辑覆盖率 集成测试的评估基准主要是接口覆盖率

系统测试的评估基准主要是测试用例对需求规格的覆盖率

2.5 回归测试

软件在测试或是其他的活动中发现缺陷经过修改后，应该进行回归测试（Regression Testing）。

目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。 回归测试可以发生在任何一个阶段，包括单元测试、集成测试、系统测试。

2.5.1 回归测试策略

1） 完全重复测试

重新执行所有的前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性。 2） 选择性重复测试

即有选择地执行部分在前期测试阶段建立的测试用例，来测试修改的程序

选择性重复测试分为三种： （1） 覆盖修改法：

即针对被修改的部分，选取或重新构造测试用例验证测试没有错误再次发生的用例选择方法。 （2） 周边影响法：

该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响。 （3） 指标达成法：

这是一种类似于单元测试的方法，在重新执行前，先确定一个要达成的指标，如修改部分的代码100%覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。

2.5.2 回归测试流程

以下流程适合于单元测试、集成测试和系统测试

－ 在测试策略制定阶段，制定回归测试策略 － 确定需要回归测试的版本

－ 回归测试版本发布，按照回归测试策略执行回归测试 － 回归测试通过，关闭缺陷跟踪单

－ 回归测试不通过，缺陷跟踪单返回给开发人员，开发人员重新修改问题， 再次提交测试人员回归测试

2.5.3 回归测试的自动化

2.6 验收测试

2.6.1 验收测试的常用策略（重点）

验收测试的常用策略有三种，它们分别是： ● 正式验收

● 非正式验收或 Alpha 测试 ● Beta 测试

选择的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。

1） 正式验收测试

正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。

对于系统测试，活动和工件是一样的。在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。

这种测试形式的优点是：

● 要测试的功能和特性都是已知的。

● 测试的细节是已知的并且可以对其进行评测。 ● 这种测试可以自动执行，支持回归测试。 ● 可以对测试过程进行评测和监测。 ● 可接受性标准是已知的。 缺点包括：

● 要求大量的资源和计划。

● 这些测试可能是系统测试的再次实施。

● 可能无法发现软件中由于主观原因造成的缺陷，这是因为您只查找预期要发现的缺陷。

2） 非正式验收测试

在非正式验收测试中，执行测试过程的限定不象正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。

测试内容由各测试员决定。这种验收测试方法不象正式验收测试那样组织有序，而且更为主观。

大多数情况下，非正式验收测试是由最终用户组织执行的。 这种测试形式的优点是：

● 要测试的功能和特性都是已知的。 ● 可以对测试过程进行评测和监测。 ● 可接受性标准是已知的。

● 与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。 缺点包括：

● 要求资源、计划和管理资源。 ● 无法控制所使用的测试用例。

● 最终用户可能沿用系统工作的方式，并可能无法发现缺陷。

● 最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。 ● 用于验收测试的资源不受项目的控制，并且可能受到压缩。

3） Beta 测试

在以上三种验收测试策略中，Beta 测试需要的控制是最少的。在 Beta 测试中，采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。

Beta 测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不进行管理。Beta 测试是所有验收测试策略中最主观的。

这种测试形式的优点是： ● 测试由最终用户实施。 ● 大量的潜在测试资源。

● 提高客户对参与人员的满意程度。

● 与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。 缺点包括：

● 未对所有功能和/或特性进行测试。 ● 测试流程难以评测。

● 最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷。 ● 最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。 ● 用于验收测试的资源不受项目的控制，并且可能受到压缩。 ● 可接受性标准是未知的。

● 您需要更多辅助性资源来管理 Beta 测试员。

3. 测试过程模型

当前最常用的软件测试过程模型有：瀑布模型、V模型、W模型、H模型和X模型。

3.1 瀑布模型

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护六项，其过程是将上一项活动接收的工件对象作为输入，当该项活动完成后会输出该项活动的工作成果，并将该的成果作为一项活动的输入。

该模型规定这六项基本活动自上而下、固定相互衔接的次序，如同瀑布流水，逐级下落。 瀑布模型如下图所示：

瀑布模型的核心思想是按工序将问题简化，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。

瀑布模型的优点如下：

（1） 为项目提供了按阶段划分的检查点；

（2） 当前一阶段完成后，只需要关注后续阶段； （3） 可在迭代模型中应用瀑布模。 瀑布模型的缺点如下：

（1） 项目中各个阶段之间极少有反馈；

（2） 只有在项目生命周期的后期才能看到结果；

（3） 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

3.2 V模型

V模型其实是软件开发瀑布模型的变种，反映了软件测试活动与软件开发过程（从分析到设计）的关系。如下图所示：

V模型从左到右，描述了基本的开发过程和测试行为，明确地标明了测试工程中存在的不同级别以及测试阶段和开发过程各阶段的对应关系。图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此对应的是左边上升的部分，即测试过程各阶段。

V模型最大的缺陷就是只把程序作为被测试的对象，而需求、说明书等其他规格说明书都未被列为测试对象。

3.3 W（V&V）模型（重点）

W模型由两个V模型组成，相当于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。如下图所示：

W模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同时要测试，也就是说，测试与开发是同步进行的。

W模型有利于尽早的全面的发现问题。

3.4 H模型

H模型将测试活动分离出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。如下图所示：

H模型演示了在整个生命周期中某个层次上一次软件测试的“微循环”。当测试条件准备完成进入测试就绪状态后，在测试准备阶段需要至少完成以下几部分工作：

－ 该开发流程对应的测试策略是否完成； － 测试方案是否完成； － 测试用例是否完成； － 测试环境是否搭建好；

－ 相关输入、输出条件是否明确。

与V模型各W模型不同的：H模型的核心是将软件测试过程独立出来，并贯穿产品的整个和生命周期，与开发流程并行进行，不需要等到程序全部完成才开始执行测试，这充分体现了软件测试要尽早执行的原则。

3.5 X模型

X模型提倡探索性测试，指不进行事先计划的特殊类型的测试，这样可以帮助有经验的测试工程师发现测试计划之外更多的软件错误，避免把大量时间花费在编写测试文档上，导致真正的测试时间减少。如下图所示：

4. 测试过程（V&V模型）

1） 开始

2） 计划与控制

a ： 计划

－ 识别测试任务和测试范围 － 确定测试方法

－ 确定测试级别和测试准则 － 确定测试工作量和测试风险 － 确定测试资源

－ 确定测试工作产品和输出 b ： 控制

－ 监控和记录测试过度，测试覆盖率心及出口准则评估 － 测量分析测试结果

－ 缺陷跟踪和回归测试计划

－ 跟踪和监控工作量、分布和风险状态 － 更新测试计划 3） 测试分析和设计活动

－ 评审测试依据。如需求、设计文档等 － 分析和确定测试优先级

－ 识别测试条件、测试需求、测试数据 － 设计概要测试用例并确定优先级 － 规划测试环境搭建（拓朴结构图），计划测试基础设施和工具 4） 度量

－ 缺陷严重的比例 － bug数

－ 用例的执行结果 － 需求覆盖情况

－ 每日/每个版本发现缺陷的趋势图 － 累积缺陷分布图 － 缺陷分析方法 5） 测试结束活动

－ 检查测试产品是否正常提交 － 提交的缺陷是否关闭 － 提交的变更记录是否关闭

－ 测试件、测试环境和测试基础设备的归档和移交 － 分析和总结经验教训、输出测试总结报告

第3章 软件质量

1. 知识点

1.1 熟悉ISO质量定义，了解质量及其它定义

1.2 掌握质量的三个层次及决定质量的三个因素（重点）

1.3 掌握CMM五个阶段及关键KPA，熟悉ISO质量体系、了解Bsigina 1.4 重点掌握质量模型（重点）

1.5 熟悉SQA与测试区别、了解SQA工作职责 1.6 熟悉软件度量

2. 面试常遇到的问题

1、 质量是不是测试确定的？ 2、 一个软件（产品）怎么测？

3、 SQA与测试什么关系？

4、 你的项目中各种数据（度量） 5、 CMM中关键过程率？（P53）

3. 软件质量的概念

3.1 质量定义

质量定义包括三个要素：实体、特性集合、需求。

3.2 什么是质量

一个实体的所有特性，基于这些特性可以满足明显或隐含的需求，而质量就是实体基于这些特性满足需求的程度。

3.3 软件质量的三个层次

评估软件质量的标准是需求，需求包括显示需求、隐式需求、用户的实际需求，由此引申软件质量的三个层次：

一层： 工作任务书或合同（外部质量）

UAT客户 二层： 满足SRS（内部质量）（ST测试工程师）可靠性 性能来源：

需求收集－－〉需求分析——〉需求说明

三层： 满足用户实际需求（使用质量〈――最终用户）

3.4 评估一个软件的角度

软件质量模型描述了一个软件产品包含的软件特性有：功能性、性能、可用性、维护性、易用性、可移植性。而评估一个软件就应该从这些不同的角度去进行。

上图为软件质量的铁三角 1）、人是技术的载体，组织是流程执行的推动力、是成功的实施的保障，流程对于产品的成功有着关键作用； 2）、没有流程则成功得不到保证，但有了流程并不意味着肯定成功，技术是成功的另一个必要条件； 3）、流程、技术、组织三者共同决定了质量，同时还应该兼顾成本和进度。

3.6 项目管理原则的意义

1）、是质量管理的理论基础；

2）、用高度概括、易于理解的语言所表述的质量管理的最基本、最通用的一般性规律；

3）、为组织建立质量管理体系提供了理论依据； 4）、是组织的领导者有效地实施质量管理工作必须遵循的原则； （八个字概括：高度概括，普遍适用）

4. 质量模型

一组特性之间的关系，它提供规定质量需求和评估质量的基础。

4.1 CMM模型

4.1.1 CMM模型概要

4.1.2 CMM模型的用途

1、 评估组织用来识别组织中的强处和弱点；

2、 评估组用来识别选择不同的业务承包商的风险和监督合同；

3、 管理者用来了解其组织的能力，并了解为了提高其能力成熟度而进行软件过程改进

所需要进行的活动；

4、 技术人员和过程改进组来作为指南，指导他们在组织中定义和改进软件过程。

CMM的目的：评估软件质量，改善软件过程。 CMM的精髓在于：过程决定质量。

4.1.3 CMMI能力成熟度模型集成

CMMI模型中包括验证（VER）和确认（VAL）两大过程域，这两大过程域与软件测试有着紧密的关系，也是规范软件测试的两大过程域。

（1）验证过程域的目的是确保所选定的工作产品符合其指定的需求。验证过程域包括验证准备、验证执行和纠正措施识别。 验证的对象包括产品和中间工件产品，验证的方法是将待验证的对象与选定的客户需求、产品需求各产品组件需求加以比较。 验证是渐进的过程，因为它发生在产品和工件产品的整个开发过程中。

（2）确认过程域的目的是展示完全置于预期环境中的产品或产品组件是否满足预期的使用需求。 确认过程域包括确认环境、确认证明。

4.1.4 CMM模型与CMMI模型的区别

CMM模型基本活动度量方法和瀑布过程一样是有次序的，基本活动的管理规范有非常密切的关系，更适合瀑布型的开发过程；CMMI相对于CMM更进一步的支持迭代示开发过

程和经济机。

CMMI比CMM进一步强化了对需求的重视。 CMMI对工程活动进行了一定的强化。 CMMI3级中单独强调了风险管理。

4.2 其他模型

4.2.1 ISO标准

ISO 9000族2000版标准的理论基础是八项质量管理原则，八项质量管理原则用：

（1） 高度概括、易于理解的语言所表述的质量管理的最基本、最通用的一般性规律； （2） 为组织建立质量体系提供了理论依据；

（3） 是组织的领导者有效地实施质量管理工作必须遵循的原则。

2000版标准的八项质量管理原则： （1） 以顾客为中心； （2） 领导作用； （3） 全员参与； （4） 过程方式；

（5） 管理的系统方法； （6） 持续改进；

（7） 基于事实的决策方法； （8） 互利的供方关系。

ISO9001标准有两个作用：

（1） 明确通过满足产品的规定要求达到使顾客满意所必须的质量管理体系最低要

求；

（2） 为质量管理体系的评价提供基本标准。

4.2.2 Sigma

4.3 软件质量模型的特性（重点）

ISO9126软件质量模型由6个特性、27个子特性组成。这个模型是软件质量标准的核心，测试工作需要从这6个特性、27个子特性去测试、评价一个软件。

4.3.1 功能性

功能性（Functionality）―― 当软件在指定条件下使用时，软件产品提供满足明确或隐含需求的能力。

功能性包含以下子特性：

适合性（Suitability）―― 软件产品为指定的任务和用户目标提供一组合适的功能的能力。即所提供的功能是用户所需要的，用户所需要的功能软件系统已提供。

准确性（Accuracy）（对不对）—— 软件产品提供具有需要精确度的正确或相符的结果或效果的能力。即软件除了能实现所要求的功能外，还需要能正确的实现所要求的功能。

适合性和准确性一般一起测 例如：

（1）、计算器，1+1＝2，适合性测的是有没有这个功能，而准确性测这个功能的结果是否正确。

（2）、手机，发送、接收短信，适合性测的是能不能发送和接收，而准确性看发送接收的内容是否正确。

互操作性（Interoperability）—— 软件产品与一个或更多的规定系统进行交互的能力。

例如：

（1）、不同型号的打印机与WORD之间的协议可能不一致，导致消息传递过程中发生错误。（所以测试过程中应该将被测软件系统与周边系统的各种主流的型号进行互操作性测试）

（2）、手机入网测试 （3）、ATM互操作测试

保密安全性（Security）―― 软件产品保护信息和数据的能力。主要有两方面： （1）、防止未得到授权的人或系统访问相关的信息或数据； （2）、保证得到授权的人或系统能正常的访问相关的信息或数据。

功能性的依从性（Functionality Compliance）―― 软件产品遵循与功能性相关的标准、约定或法规以及类似规定的能力。这些标准要考虑国际标准、国家标准、行业标准、企业内部标准等。

4.3.2 可靠性

可靠性（Reliability）―― 在指定条件下使用时，软件产品维持规定的性能级别的能力。

三要素：“三规”―― 规定的时间、规定的环境、规定的性能。

可靠性包含以下子特性：

成熟性（Maturity）（内部接口防范） ―― 软件产品为避免由软件中自身错误、自身模块间的错误，而导致失效的能力。

容错性（Fault Tolerance）（外部接口防范）―― 在软件出现故障或违反指定接口的情况下，软件产品维持性能级别的能力。

易恢复性（Recoverability）―― 在失效发生的情况下，软件产品重建规定性能级别并恢复受直接影响的数据的能力。（原有能力恢复的程度，原有能力恢复的速度）

可靠性的依从性（Reliability Compliance）――软件产品遵循与可靠性相关的标准、约定或法规以及类似规定的能力。

4.3.3 易用性

易用性（Usability）―― 在指定的条件下，软件产品被理解、学习、使用各吸引用户的能力。

功能性、可靠性和效率的某些方面会影响易用性

易用性包含以下子特性：

易理解性（Understandability）―― 软件产品使用户能理解软件是否合适以及如何能将软件用于选定的任务和使用环境的能力。即用户在使用软件系统的过程中，系统交互给用户的信息是否准确、清晰、易懂，能够帮助用户准确的理解系统当前的真实的状态，指导其进一步的操作。

易操作性（Operability）―― 软件产品使用户能操作和控制它的能力。

吸引性（Attractiveness）―― 软件产品吸引用户的能力。

易用性的依从性（Usability Compliance）软件产品遵循与易用性相关的标准、约定或法规以及类似规定的能力。这些标准要考虑国际标准、国家标准、行业标准、企业内部标准等。

4.3.4 效率

效率（Efficiency）―― 在规定条件下，相对于所用效资源的数量，软件产品可提供适当性能的能力。

效率包含以下的子特性：

时间特性（Time Behavior）―― 在规定条件下，软件执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。即完成用户的某个功能需要的响应时间。

资源利用性（Resource Utilization）―― 在规定条件下，软件产品执行其功能时，使用合适的资源数量和类别的能力。例如完成某个功能时需要的CPU的占用率 、内存占用率、通信带宽等。

效率依从性（Efficiency Compliance）――软件产品遵循与易用性相关的标准、约定或法规以及类似规定的能力。

4.3.5 可维护性

可维护性（Maintainability）―― 软件产品可被修改的能力。修改可能包括修正、改进、或软件对环境、需求和功能规格说明变化的适应。

可维护性包含以下的子特性：

易分析性（Analyzability）（降低定位缺陷的成本）―― 软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。

易改变性（Changeability）（降低修改缺陷的成本）―― 软件产品使用指定的修改可以被实现的能力。实现包括编码、设计和文档的更改。

稳定性（Stability）―― 软件产品避免由于软件修改造成意外结果的能力。

易测试性（Testability）（降低发现缺陷的成本）―― 软件产品使已修改软件能被确认能力。

维护性的依从性（Maintainability Compliance）――软件产品遵循与易用性相关的标准、约定或法规以及类似规定的能力。

4.3.6 可移植性

可移植性（Portability）―― 软件产品从一种环境迁移到另外一种环境的能力。

可移植性包含以下子特性：

适应性（Adaptability）―― 软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段就可能适应不同指定环境的能力。

易安装性（Installability）―― 软件产品在指定的环境中被安装的能力。

共存性（Co-existence）―― 软件产品在公共环境中同与鞭分享公共资源的其它独立软件共存的能力。

易替换性（Replaceability）―― 软件产品在同样环境下，替代另一个相同用途的指定软件的产品的能力。

可移植性的依从性（Portability Compliance）――软件产品遵循与易用性相关的标准、约定或法规以及类似规定的能力。

4.4 质量度量

4.4.1 软件质量活动

软件组织主要软件质量活动包括：软件质量保证（SQA）和测试。

SQA和测试的关系

软件质量由组织、流程和技术三方面组成。简单说：

（1）、SQA从流程方面保证软件的质量；

（2）、测试是从技术方面保证软件的质量；

（3）、只进行SQA活动或只进行测试活动不一定能产生好的软件质量。

SQA的工件范围

（1）、保障制度体系；

（2）、促使过程改进；

（3）、指导项目实施；

（4）、增加透明度；

（5）、评审项目活动；

（6）、审核工件产品；

（7）、协助问题解决；

（8）、提供决策参考；

（9）、进行缺陷预防；

（10）、实现质量目标。

什么是度量

1） 度量的概念

度量：对事物属性的量化表示。

软件度量：是指计算机软件中范围广泛的测度，包括对软件系统、构件或生命

周期过程具有的某个给定属性的度的一个定量测量。

2） 度量的目的

－提高软件生产率，缩短产品研发成本、维护成本

－提高软件产品质量，提高用户满意度

－为组织持续改进提供量化的指标和反馈

3） 度量的作用

软件度量的作用：理解、预测、评估、改进

4） 度量的类型

过程度量――过程优化和改进

产品度量――产品评估和决策

项目度量――项目控制和评估

5） 度量的四个基本度量项

四个基本度量项：规模、工作量、进度、质量

6） 度量的其它度量指标

其它指标：缺陷密度、生产率、测试执行效率、用例密度、需求稳定性

第4章 测试方法

第5章 配置管理

第6章 需求管理

第7章 通用测试用例写作

第8章 缺陷管理

第9章 测试用例设计方法

1. 黑盒测试用例设计方法

1.1 等价类划分法

等价类划分是一种典型的黑盒测试用例设计方法，使用该方法主要是对测试子项进行测试规格分析，等到用例，而不用对系统内部的处理深入了解。

等价类是指某个输入域的子集合，在该子集合中，各个输入的数据对于揭露软件中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类的其它的值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为输入条件，就可以用少量代表性的测试数据取得较好的测试结果。

等价类划分有两种情况，有效等价类和无效等价类：

有效等价类：是指对于的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类：是指对于系统的规格说明来说是不合理或无意义的输入数据构成的集合。

1.1.1 产生的背景（或说目的）

采用等价类划分，是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试，这样可以避免穷举法产生的大量用例。

1.1.2 实施步骤

第一步：找出输入的条件；

第二步：为每个输入条件划分有效等价类和无效等价类；

第三步：为每个等价类编号；

第四步：设计用例。

1.1.3 总结

等价类划分原则：

1、 追求效率与效果的平衡；

2、 到底将等价类划分多细取决于人力资源与进度，但必须做到将所有的等价类都覆盖到。

等价类的完备性：

1、 不冗余；

2、 不遗漏。

即所有等价类的和刚好等于所有的数据。

注意事项：

1、 要注意输入背后的隐藏条件；

2、 输出域覆盖：当遇到中间输出对最终结果有影响时，需要将中间作为输入的条

件考虑；

3、 当输入框由多个规则的输入条件组成时，则需要输入框拆分为多个输入条件。

4、 当输入条件有组合或约束影响输出时，等价类无法覆盖全面。

应用场合：

主要应用在功能测试、性能测试、GUI测试、配置测试等类型中。

1.2 边界值分析法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

边界值分析法的理论基础，是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其它的取值导致程序错误的可能性也很小。

边界值分析法使用条件：

1、 输入条件明确了一个值的取值范围，或是规定了值的个数；

2、 输入条件明确了一个有序集合。

边界值点的定义：

上点：边界上的点；

离点：就是离上点最近的点，如果域的边界封闭，则离点在范围外，如果域的边界开放，

则离点在范围内；

内点：除上点和离点外的域的点。

1.2.1 产生的背景（或说目的）

对等价类划分进行补充

1.2.2 实施步骤

第一步：找出输入条件；

第二步：为每个输入条件划分有效和无效等价类；

第三步：为每个等价类标识边界点；

第四步：为每个边界值及无边界值的等价类编号；

第五步：用最少的用用例覆盖最多的有效边界，每个无效边界为一个用例。

1.2.3 总结

1、 等价类边界值是最基础，使用率最高的方法；

2、 边界值不公要考虑输入条件，还一定要考虑输出域；

3、 等价类是发现缺陷最强的方法，取值时时刻注意。

4、 边界值取值应当选取正好等于、刚刚大于最大边界值和刚刚小于最小边界值最为测

试数据。

应用场景：

1、 输入（输出）条件规定了取值范围 ；

2、 输入（输出）条件规定了值的个数 ；

3、 程序规格说明书中提到的输入或输出是一个有序的集合 ；

4、 程序中使用了一个内部数据结构

1.3 判定表法

判定表法是分析和表达多种输入条件下系统执行不同动作的工具。

判定表组成

条件桩：列出了问题的所有条件

动作桩：列出了问题规定可能采取的操作

条件项：列出针对它所列条件的取值，在所有可能情况下的真假值

动作项：列出在条件项的各种取值情况下应该采取的动作

规则：任何一个条件组合的特定取值及其相应要执行的操作

注：判定表中贯穿条件项和动作项的一列就是一条规则；

1.3.1 产生的背景（或说目的）

程序在一些数据处理问题中， 某些操作依赖多个逻辑条件的取值， 即就是这些逻辑条件取值组合所构成的多种情况下，分别执行不同的操作，所以想处理这类问题就需要用判定表

1.3.2 实施步骤

第一步：找出条件桩作为输入条件；

第二步：找出动作桩作为输出条件；

第三步：找出每个条件桩的规则，假如有n个条件，每个条件有两个取值（0,1） ，故有2n种规则

第四步：填入条件项

第五步：填入动作项。制定初始判定表

第六步：简化。（合并原则：动作项相同，条件项（必须是确定条件）N-1个相同，则两列可以合并）

第七步：每一列就是一条用例。

1.3.3 总结

判定表设计测试用例的条件：

1、 规格说明以判定表的形式给出，或很容易转换成判定表；

2、 条件的排列顺序不影响执行哪些操作；

3、 规则的排列顺序不影响执行哪些操作；

4、 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则 ；

5、 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

优点：

1、 充分考虑了输入条件间的组合，对组合情况覆盖充分；

2、 最终每个用例覆盖多种输入条件，有利于提高测试效率；

3、 设计过程中，对输入条件间的约束关系做了考虑，避免了无效用例，用例的有

效性高；

4、 能同时得出每个测试项目的预期输出。

缺点：

1、 当被测试特性输入较多时，判定表的规模将会非常庞大；

2、 输入之间的约束条件不能有效区分输入是否确实需要进行组合测试，会造成不

需要组合测试的输入做了组合，从而产生用例冗余。

1.4 因果图法

因果图用于描述系统的输入输出、以及输入和输出之间的因果关系、输入和输入之间的约束关系。

因果图的绘制过程是对被测试系统外部特征的建模过程。

根据系统输入输出间的因果关系图可以得到判定表，从而规划出测试用例。

因果图需要描述下面的一此关系：

1、 输入与输出之间的因果关系

1） 恒等关系：当输入项发生，会产生对应的输出，当输入项不发生时，不会产生

对应的输出。

2） 非关系（～）：与恒等关系相反。

3） 或关系（v）：多个输入条件中，只要有一个发生，则产生对应结果。

4） 与关系（^）：多少输入条件中，只有所有输入项发生时，才会产生对应输出。

2、 输入与输入之间的约束关系

1) 异（E）：所有输入中至多一个输入条件发生。

2) 或（I）：所有输入中至少一个输入条件发生。

3) 唯一（O）：所有输入中有且只有一个输入条件发生。

4) 要求（R）：所有输入中只有一个输入条件发生，则其它输入也会发生。

强制性的，A要发生，要求B必须发生。

1.4.1 产生的背景（或说目的）

因果图和判定表两种方法在实际的使用中结合紧密，往往同时使用，此时可以理解因果图为判定表的前置过程。

对于简单的系统，或输入输出已经非常明确的系统，判定表可以单独使用，如果复杂则要用先用因果图法找出输入与输出、输入与输入之间的关系，再进行后续的操作。

因果图法的来源

大家熟悉的等价类划分法和边界值分析法，都是着重考虑输入条件，但未考虑输入条件之间的联系、相互组合等；

但是，如考虑所输入条件之间的相互组合，会由于组合情况数目相当大，需要大量的测试用例；

因果图法，是一种帮助人们系统地选择一组高效率测试用例的方法。

1.4.2 实施步骤

第一步：画出结果；

第二步：画出原因；

第三步：画出原因与结果的关系（可借助中间变量）；

第四步：画出原因与原因之间的关系

第五步：根据因果图化简2n ；

第六步：将化简后的公式代入判定表；

第七步：第一例就是一个用例。

1.4.3 总结

因果图法的特点：

1） 考虑输入条件间的组合关系；

2） 考虑输出条件对输入条件的信赖关系，即因果关系；

3） 测试用例发现错误的效率高；

4） 能检查出功能说明中的某些不一致或遗漏；

5） 因果图方法最终生产的就是判定表，它适合于检查程序输入条件和各种组合情况。

优点：

1、 充分考虑了输入条件间的组合，对组合情况覆盖充分；

2、 最终每个用例覆盖多种输入条件，有利于提高测试效率；

3、 设计过程中，对输入条件间的约束关系做了考虑，避免了无效用例，用例的有效性高；

4、 能同时得出每个测试项目的预期输出。

缺点：

1、 当被测试特性输入较多时，判定表的规模将会非常庞大；

2、 输入之间的约束条件不能有效区分输入是否确实需要进行组合测试，会造成不需要组合测试的输入做了组合，从而产生用例冗余。

1.5 正交试验法

所谓正交试验设计法，是从大量的试验上挑选出适量的、有代表性的点，应用依据迦罗瓦理论导出的“正交表”，合理的安排试验的一种科学的试验设计方法，是研究多水平的一种设计方法。它是根据正交性从全面试验中挑选部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。

通常把判断试验结果优劣的标准叫做试验的指标，把所有影响试验指标的条件叫称为因子，而影响试验因子的，叫做因子的状态。

1.5.1 产生的背景（或说目的）

正交试验法是一种用来测试组合的方法，这一点和判定表类似，但是判定表法是通过人工对全排列组合来进行化简得到测试用例的，正交试验是借助于数学工具，通过算法从全排列组合中选择出组合并放到正交表中，这样通过查看合适的正交表就可以直接得到测试用例。

可以解决判定表当被测试特性输入较多时，判定表的规模将会非常庞大和输入之间的约束条件不能有效区分输入是否确实需要进行组合测试，会造成不需要组合测试的输入做了组合，从而产生用例冗余的问题。

1.5.2 实施步骤

第一步：提取功能说明，生成因素分析表；

第二步：加权筛选，生成因素分析表；

第三步：画出布尔图；

第四步：查找最接近的相应除数的正交表；

第五步：将实际的因子和状态代入正交表中，得到最终的正交表。

1.5.3 总结

1、 正交试验法能借助于正交表快速的设计测试用例；

2、 正交试验的组合方式不考虑实际取值的意义，因此可能出现正交表中的组合不一定是用户常用的，或者用户常用的组合并未包含在正交表中。所以，使用时要注意选出组合的实际意义，删除无效的组合，补充漏掉的常见组合。

应用场景：

1、 单个功能；

2、 功能组合测试；

3、 配置测试。

1.6 状态迁移法

1.6.1 产生的背景（或说目的）

对等价类划分进行补充

1.6.3 总结

1.7

1.7.1 产生的背景（或说目的）

对等价类划分进行补充

1.7.2 实施步骤

1.7.3 总结

1.8

1.8.1 产生的背景（或说目的）

对等价类划分进行补充

1.8.2 实施步骤

1.8.3 总结

1.9

1.9.1 产生的背景（或说目的）

对等价类划分进行补充

1.9.3 总结

1.10

1.10.1 产生的背景（或说目的）

对等价类划分进行补充

1.10.2 实施步骤

1.10.3 总结

1.11

1.11.1 产生的背景（或说目的）

对等价类划分进行补充

1.11.2 实施步骤

1.11.3 总结

等价类与边界的区别

在测试过程中，边界值分析法是作为对等价类划分法的补充，专注于每个等价类的边界值，两者的区别在于前者在等价类中随机选取一个测试点。边界值分析法采用一到多个测试用例来测试一个边界，不仅重视输入条件边界值，而且重视输出域中导出的测试用例。边界值分析法比较简单，仅用于考察正处于等价划分边界或边界附近的状态，考虑输出域边界产生的测试情况，针对各种边界情况设计测试用例，发现更多的错误。边界值分析法的测试用例是由等价类的边界值产生的，根据输入输出等价类，选取稍高于边界值或稍低于边界值等特定情况作为测试用例。下面介绍边界值分析方法需要注意的问题。 与等价划分的区别

1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。