软件测试技术总复习

1.第一章 软件测试概述

1.1V模型和W模型及其特点和局限性

V模型

V模型示意图

V模型特点：

• 突出了测试过程的独立性，反映了软件测试活动和软件开发活动的关系，明确标明了测试过程中存在的不同级别的测试阶段，并且清除地描述了这些测试阶段和开发阶段之间的对应关系。
• 测试策略白喊低层和高层测试，底层测试是为了保证源代码和设计的正确性，高层测试是为了使系统满足用户需求。

V模型局限性

• 只是将测试看做编码之后的一个阶段，主要是针对程序寻找错误的活动，从而忽视了测试活动对需求分析和系统设计等前期开发活动的验证和确认功能。

W模型

W模型示意图

W模型优点

W模型有利于尽早地和全面地发现软件缺陷。在软件需求分析完成后，就应当及时地对需求分析结果进行验证和确认，尽早地发现隐藏在需求分析结果中的错误。

W模型局限性

• W模型将需求、设计和编码等开发活动都看做是串行活动。
• 同时，测试和开发活动也保持着一种线性的前后关系，前面的一个阶段完成后，才可以开始下面一个阶段的工作。
• 因此，W模型无法支持迭代的软件开发过程，也难以适应需求变更调整。

1.2什么是测试用例

测试用例是测试执行之前已设计好的一套详细的测试方案，也是测试执行时的最小实体。概况的来讲，测试用例是为了某个特殊目标而编制的一组测试输入、执行条件以及预期结果，其目的是确定应用程序的某个特性是否能够正常工作，并且满足了特定用户需求和软件设计结果。

1.3测试用例编写规范（主要内容 ）

一个测试套件或者一个测试用例一般包括如下内容：

1.用例版本历史信息

• （1）项目名称。
• （2）项目代号。项目研发代号，部分项目没有代号可空缺。
• （3）创建日期。测试用例文件创建的日期
• （4）版本。测试用例文件的版本号。
• （5）作者。创建或修改新用例版本的测试人员。
• （6）类型。新用例版本所作的操作选项：C创建，A添加，M修改，D删除。
• （7）备注。创建或修改用例的一些特殊说明或提醒。
• （8）参考文件名称。项目文档或技术文档的文件名。
• （9）参考文件路径/附件。项目文档的公共提取地址，此条目为
  用例编写依据。

2. 用例模板信息
（1）CASEID（用例编号）。
（2）CHECKPOINT（检查点）。统一使用“功能分支—功能点”命名方式，每个CHECKPOINT不允许出现相同的描述，必须做到可区分，例如“网上订货–订购”。
（3）PRESET CONDITIONS（预置条件）。实施此项测试用例的前提条件。
（4）TEST ENVIRONMENT（测试环境）。测试所需硬件、软件和网络等测试平台的描述。
（5）INPUT DATA（输入数据）。可能包括数据、文件，以
及必要时的数据库信息。
（6）TEST STEPS（测试步骤）。
（7）EXPECT RESULTS（期望结果）。
（8）ACTUAL RESULTS（实际结果）。当测试用例执行失败时的执行结果描述（注意：该条目对NA用例不适用）。
（9）PASS/FAIL/BLOCKED/NA（测试结论）。记录用例的通过和失败，BLOCKED为BUG无法测试，NA为当前用例不适用当前测试。
（10）Priority（用例优先级）。使用率高且对项目有重大影响的功能点为P1，使用率不高但同属于功能性的为P2，其他文字性和界面美观性为P3或P4。
（11）Created By（用例编写者）。
（12）Creation Date（用例编写日期）。
（13）Executed By（执行用例测试人员）。
（14）Execution Date（用例执行日期）。
（15）Execution Version（执行该条用例使用的软件版本号）。
（16）Comments（说明）。测试该条用例时如果出现失败或
被阻碍，描述简要现象和其它问题。

1.4设计测试用例的误区及其原因

• （1）把测试用例的设计等同于测试输入数据的设计
  确定测试输入数据之外，测试用例还包括测试环境、测试步骤、预期结果、优先级等重要内容。
• （2）强调测试用例设计得越详细越好
  会耗费大量的测试资源
• （3）追求测试用例设计“一步到位”
  软件在不断变化，测试用例自然也就需要随之不断变化，因此测试用例设计不可能一步到位，一劳永逸。
• （4）将多个测试用例混在一个用例中
  这种错误的测试用例设计结果很容易引起混淆，执行测试用例的时候，如果有些用例通过而有些没有，那么将很难记录测试结果。

2.第二章和第三章 白/黑盒测试

2.1逻辑覆盖与逻辑覆盖类型、包容关系

逻辑覆盖测试是一种常用的动态白盒测试方法，主要包括 语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖和路径覆盖。 逻辑覆盖是基于程序的内部逻辑结构进行的测试，要求在设计测试用例时，对被测程序的逻辑结构有清晰的了解。

• 判定：决定程序分支走形的整体布尔型表达式被称为判定，取值为true或者false。（判定不是语句）
• 判定表达式大部分由多个逻辑条件组合而成。
  以下测试用例以此为例
  

（1）语句覆盖

• 设计若干个测试用例，使得被测程序中的每一条可执行语句（以;结尾）至少执行一次。
• 只针对程序中显式存在的语句，无法测试隐藏的条件和可能的逻辑分支。
• 最弱的逻辑覆盖标准。

测试用例	判定P1	判定P2	执行路径
A=2,B=0,X=3	T	T	a-c-b-e-d

（2）判定覆盖（分支覆盖）

• 设计若干个测试用例，使被测程序中每个判定的取真分支和取假分支至少被执行一次，即每个判定的真假值均被满足。（使每一个分支获得每一种可能的结果）
• 满足判定覆盖标准的测试用例一定满足语句覆盖标准，反之则不然。
• 判定覆盖的测试充分性仍旧很弱，只判断整个判定表达式的最终取值结果，不考虑表达式中每个条件的取值情况。

测试用例	判定P1	判定P2	执行路径
A=3,B=0,X=1	T	F	a-c-b-d
A=2,B=2,X=3	F	T	a-b-e-d

（3）条件覆盖

• 设计足够多的测试用例，使每个判定中每个条件的真假取值都至少被满足一次。
• 条件覆盖比判定覆盖要强，更细致地考虑了判定表达式中每个条件的取值情况。
  上述例子中有四个条件，分别为
  C1（A>1），取真值为T1，否则为F1
  C2（B=0），取真值为T2，否则为F2
  C3（A=2），取真值为T3，否则为F3
  C4（X>1），取真值为T4，否则为F4

测试用例	C1	C2	C3	C4	判定P1	判定P2	执行路径
A=2,B=0,X=1	T1	T2	T3	F4	T	T	a-c-b-e-d
A=1,B=1,X=4	F1	F2	F3	T4	F	T	a-b-e-d

（4）判定-条件覆盖

• 设计足够多的用例，使被测程序中每个判定的每个条件的可取值至少被执行一次，并且每个可能的判定结果也至少被执行一次。
• 满足判定-条件覆盖就一定能满足条件覆盖、判定覆盖和语句覆盖。

测试用例	C1	C2	C3	C4	判定P1	判定P2	执行路径
A=2,B=0,X=4	T1	T2	T3	T4	T	T	a-c-b-e-d
A=1,B=1,X=1	F1	F2	F3	F4	F	F	a-b-d

（5）条件组合覆盖

• 涉及足够多的用例，使得被测程序中每个判定的所有可能的条件取值组合至少被执行一次。
• 条件组合覆盖标准能够完全包容判定-条件覆盖标准。
  条件取值组合情况

组合编号	1	2	3	4	5	6	7	8
条件取值组合	T1,T2	T1,F2	F1,T2	F1,F2	T3,T4	T3,F4	F3,T4	F3,F4

条件取值组合的注意事项：

• 条件取值组合只针对同一个判定表达式内存在多个条件的情况，将这些条件的取值进行笛卡尔乘积组合；
• 不同判定表达式内的条件取值之间不需要进行组合；
• 对于单条件的判定表达式，只需要满足自己的所有取值即可。

条件组合覆盖测试用例

测试用例	C1	C2	C3	C4	覆盖条件组合	判定P1	判定P2	执行路径
A=2,B=0,X=4	T1	T2	T3	T4	1,5	T	T	a-c-b-e-d
A=2,B=1,X=1	T1	F2	T3	F4	2,6	F	T	a-b-e-d
A=1,B=0,X=2	F1	T2	F3	T4	3,7	F	T	a-b-e-d
A=1,B=1,X=1	F1	F2	F3	F4	4,8	F	F	a-b-d

（6）路径覆盖

• 设计足够多的测试用例，使被测程序的每条可执行路径都至少执行一次。
• 相比于其他逻辑覆盖测试， 测试覆盖率最大。

测试用例	C1	C2	C3	C4	判定P1	判定P2	执行路径
A=2,B=0,X=4	T1	T2	T3	T4	T	T	a-c-b-e-d
A=3,B=0,X=3	T1	T2	F3	F4	T	F	a-b-e-d
A=1,B=0,X=2	F1	T2	F3	T4	F	T	a-b-e-d
A=1,B=1,X=1	F1	F2	F3	F4	F	F	a-b-d

实际工作中，语句覆盖、判定覆盖和路径覆盖使用
的最多，一般有如下要求：

⚫ 语句覆盖率：100%；
⚫ 判定覆盖率：85以上；
⚫ 路径覆盖率：80%以上

6种逻辑覆盖测试的强弱关系

2.2逻辑覆盖测试用例设计

见2.1

2.3 基本路径测试用例设计（正确绘制流图、技术复杂度）

基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例需要保证被测程序的每一条可执行语句至少被执行一次。

基本路径测试法步骤：
（1）以详细设计或源代码为基础，绘制程序控制流图；
（2）根据程序控制流图，计算程序环路复杂度；
（3）确定独立路径的集合；
（4）生成测试用例。

---

（1）程序控制流图简称流图，本质上是一种“退化”了的程序流程图，用于突出表示程序的控制结构。流图只呈现程序的控制流程，完全不表现具体的语句以及选择或循环的具体条
件。

控制流图是一种有向图，由结点和边构成，其含义分别为：

• （1）结点：用圆表示。一个结点代表一条或多条顺序执行的语句。程序流程图中的一个顺序的处理框序列和一个菱形判定框，可以映射成流图中的一个结点。
• （2）边：用箭头线表示。边代表控制流，一条边必须终止于一个结点，即使这个结点并不代表任何语句。

当我们将常见的程序流程图转化为控制流图时，需要注意以下两点：

• ⚫ 在选择或者是多分支结构中，分支的汇聚处应当添加一个汇聚结点，即使是该处并没有实际的可执行语句也应如此，这样可以使控制结构表现地更为完整和清晰。
• ⚫ 由边和结点围成的面积称为区域。当计算区域总数时，图形外未被围起来的那个区域也要记为一个区域。

将程序流程图转化为控制流图

如果判定中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断。

（2）计算环路复杂性

环形复杂度定量度量程序的逻辑复杂度。有了描绘程序控制流的流图之后，可以用下述3种方法中的任何一种来计算环形复杂度。

• (1) 流图中的区域数等于环形复杂度。
• (2) 流图G的环形复杂度V(G)=E-N+2,其中，E是流图中边的条数，N是结点数。
• (3) 流图G的环形复杂度V(G)=P+1，其中，P是流图中判定结点的数目。

（3）确定独立路径集合

独立路径，也称为基本路径，其含义包含以下两点：

• （1）是一条从起始结点到终止结点的路径。
• （2）一条独立路径至少包含一条其它独立路径没有包含的边!!! 也就是说，至少引入了一条新执行语句或一个新判定的程序通路。

程序的环路复杂度计算结果给出了程序独立路径集合中的独立路径条数，这是保证程序中每个可执行语句至少被执行一次所必需的测试用例数量的上限我们只要最多V(G)个测试用例就可以满足基本路径覆盖要求。

注意事项：

➢ 程序的环路复杂度表示的是最多的测试用例个数，是测试用例数量的上界，实际用例数不一定要达到这个上界。
➢ 测试用例数量越简化，测试的充分性就越低。
➢ 需要根据实际情况来确定测试用例数量简化的程度。

（4）设计测试用例
为每一条独立路径各设计一个测试用例，驱动被测程序沿着该路径至少执行一次。

基本路径测试用例

输入数据	预期结果	独立路径

2.4等价类划分（有效等价类和无效等价类）

link

2.5边界值分析法

link

3 第四章 软件测试的执行阶段

3.1 单元测试、集成测试、系统测试和验收测试的主要任务、采用技术、依据文件、参与人员。（尤其是集成测试）

1.单元测试

• 概念： 单元测试就是根据软件规格说明书、详细设计说明书、编码规范和源程序清单，对软件设计中的最小单元进行正确性检验的测试工作，主要测试软件单元在语法、格式和逻辑上的错误。

• 主要任务：
  （1）模块接口测试
  （2） 模块局部数据结构测试
  （3）模块独立路径测试
  （4）出错处理测试
  （5）边界条件测试
  

• 采用技术
  单元测试主要采用白盒测试方法，以黑盒测试方法作为辅助。通常用一下方法完成单元测试。
  静态测试（可发现30%-70%的程序逻辑和编码错误）
  动态测试（单元测试的重难点）
  状态转换测试（采用的是黑盒测试方法，通常用状态转换图来辅助测试用例的设计，每个测试用例必须包括单元起始状态、输入、预期输出和转换后的期望状态）

• 依据文件
  主要依据是《软件详细设计说明说》，也包括源程序本身的代码和注释。

• 参与人员
  单元测试一般由开发人员自己负责完成。可以由开发人员测试自己开发的代码，也可以在条件允许的情况下进行开发人员之间的交叉测试
  

2.集成测试

• 概念：集成测试也被称为部件测试、组装测试、联合测试或子系统测试，主要测试组合在一起的软件单元能否正常工作。
• 主要任务
  ⚫模块间的数据传输是否有问题，数据是否在模块接口处丢失。这就需要测试各个模块间能否通过接口以正确、稳定和一致的方式进行交互。
  ⚫ 一个模块的程序是否对其它模块的功能产生了错误的影响。
  ⚫ 全局数据结构是否出现设计和运行错误。由于全局数据结构的存在，使得软件模块“高内聚、低耦合”的程度降低。
  ⚫ 模块组合在一起后，整体功能是否满足需求和设计要求。
  ⚫ 各个模块的误差积累在一起之后，积累误差达到无法接受的程度。
• 采用技术
  主要采用黑盒测试方法，以白盒测试方法为辅助。可以归类为“灰盒测试”。
• 依据文件
  软件概要设计说明书。
• 参与人员
  集成测试一般是由开发人员和测试人员共同完成的，其中开发人员所负责完成的工作通常更多一些。
  ⚫ 在集成测试的前期阶段，也就是集成粒度仍然比较小的阶段，由开发人员或白盒测试工程师来完成测试。
  ⚫ 在系统级大粒度的后期集成测试阶段，测试工作一般由专门的测试部门来完成。

3.系统测试

• 概念：
  系统测试是将经过集成测试之后的软件系统与计算机硬件、输入输出设备、所需要的其它支撑软件、必须的初始化业务数据等系统运行必备元素组合在一起，然后对用户实际运行环境下的完整计算机系统进行测试。
• 主要任务
  通过检验软件系统各项功能是否正确，以及检验软件系统在性能、安全性、可靠性等非功能特性上的表现是否满足要求，从而验证软件系统与系统的需求定义是否完全一致。
  前期主要以功能测试为主，后期以性能测试、安全性。可靠性。兼容性等非功能测试为主。
• 采用技术
  黑盒测试技术
• 依据文件
  软件规格说明书
• 参与人员
  ⚫ 独立测试部门中的专职测试人员。
  ⚫ 与项目用户直接沟通，熟悉用户需求的主要市场人员。
  ⚫ 部分需求分析、设计和开发人员。
  ⚫ 在业务上与本项目密切相关的其它项目的开发人员。
  ⚫ 企业中负责质量体系管理的质量保证人员。

4.验收测试

• 概念：
  验收测试也被称为交付测试，是在发布或部署软件之前，对软件系统进行的最后一个技术测试阶段。测试工作以用户为主，测试人员等质量保障人员共同参与，用于最终确认软件的有效性，保证软件的功能和性能等满足了用户的所有要求。通过了验收测试的软件系统才可以正式交付用户使用。
• 主要任务
  软件配置审查和软件有效性测试。

验收测试的流程与内容：

• 采用技术
  黑盒测试技术
• 依据文件
  软件需求规格说明书、项目合同、项目或产品验收准则。
• 参与人员
  ⚫验收测试强调以用户为主导，是最终用户从实际使用的角度验证软件功能是否全面、正确，以及系统性能等非功能特性是否和软件需求相一致。
  ⚫ 验收测试通常在开发方测试小组的配合下由用户方代表来执行，也可能完全由最终用户组织进行。
  ⚫ 为了保证验收测试的客观性，一些软件验收会采用第三方进行验收测试的方式进行。

3.2 集成测试的 主要内容、策略与模式（自顶向下、自底向上、深度、广度、桩模块、驱动模块）， 集成过程图文描述。

• 主要内容
  ⚫模块间的数据传输是否有问题，数据是否在模块接口处丢失。这就需要测试各个模块间能否通过接口以正确、稳定和一致的方式进行交互。
  ⚫ 一个模块的程序是否对其它模块的功能产生了错误的影响。
  ⚫ 全局数据结构是否出现设计和运行错误。由于全局数据结构的存在，使得软件模块“高内聚、低耦合”的程度降低。
  ⚫ 模块组合在一起后，整体功能是否满足需求和设计要求。
  ⚫ 各个模块的误差积累在一起之后，积累误差达到无法接受的程度。
• 策略与模式
  （1）自顶向下的集成测试
  按照软件模块在设计中的层次结构，从上到下逐步进行集成和测试。先从最上层的主控模块开始，软后沿着软件的模块层次向下移动，逐步将软件所包含的模块集成在一起。这种测试模式又分为深度优先和广度优先两种集成策略。
  
  以此图为例，
  深度优先的模块集成顺序为A→B→D→C→E→F。
  广度优先的模块集成顺序为A→B→C→D→E→F。
  自顶向下集成测试的步骤

1. 首先完成对主控模块的测试，用桩模块代替主控模块所调用的下层模块。
2. 根据深度优先或者是广度优先策略，每次用一个实际模块替换一个桩模块。如果新增模块具有下层调用模块，则用桩模块代替这些被调用模块。
3. 每增加一个模块的同时都要进行测试。
4. 进行必要的回归测试以保证增加的模块没有引起新的错误。
5. 从步骤②开始重复进行，直到所有的模块都被集成到系统中。

深度优先的自顶向下集成测试示例

（2）自底向上的集成测试
自底向上的方法与自顶向下的方法正好相反，是从软件结构的最底层模块开始，自下而上地逐步完成模块的集成和测试工作。由于下层模块的实际功能都已开发完成，因此在集成过程中就不需要开发桩模块了，只需要开发相应的上层驱动模块即可。

通常根据功能族的划分对模块逐步进行集成，形成不同粒度的功能族并进行测试。然后通过合并已测试过的功能族，逐渐扩大功能族的粒度以反映系统的主要功能。
自底向上集成测试的步骤

1. 将底层模块组合成实现某一特定系统子功能的功能族。
2. 编写一个驱动程序，能够调用已组合的模块，并协调测试数据的输入与输出。
3. 对组合模块构成的子功能族进行测试。
4. 去掉驱动程序，沿着软件结构从下往上移动，将已测试过的子功能族组合在一起，形成更大粒度的子功能族。
5. 从步骤②开始重复进行，直到所有的模块都被集成到系统中。

示例

驱动模块

驱动模块（Driver）也称为驱动程序，是用于模拟被测模块的上级模块，能够调用被测模块。当被测模块是底层模块时，需要编写驱动模块。

桩模块

桩模块（Sub）也称为存根程序，是用于模拟程序结构中被测模块所调用的下级模块。当被测模块是上层模块时，需要编写桩模块。

驱动模块启动被测模块，接受测试数据，将测试数据传送给被测模块并输出测试用例的测试结果。桩模块只做少量的数据处理，如简单条件判断和返回，模拟被测模块所需要的调用结果即可。

3.3 α测试，β测试

• α测试
  • α测试是在软件开发方内部进行的一种验收测试，是在开发方人员模拟软件实际运行环境和用户操作行为情况下进行的受控测试。
  • 主要用于对软件产品的功能、性能、可用性和可靠性等做出评价，特别是对软件界面和易用性进行测试。 要尽可能模拟用户真实环境和可能的操作方式。
  • 测试的执行一般不能由开发人员或测试人员完成。 α测试人员最好由非项目组人员或其它非技术部门人员构成，也应当有代表性用户参与。
  • 测试过程中，项目组开发或测试人员主要负责进行产品使用说明和回答一些软件操作方面的问题，但不进行过多的干预。
• β测试
  • β测试是由软件开发方组织各方面的典型用户，在用户的日常工作和生活场所实际使用软件，并要求用户反馈使用中发现的异常情况和使用意见，然后再由开发方对软件进行改错和完善。
  • 测试是在开发方不受控环境下进行的外部测试，开发方人员通常不在现场，β测试不能由开发人员和测试人员完成。

四种主要测试阶段的对比

4第五章 功能测试与非功能测试

4.1功能测试和非功能测试的区别、各自的主要内容。

4.1.1功能测试

• 功能测试就是根据软件需求规格说明书，检验软件系统是否满足用户对于各方面功能的使用要求，确保软件以用户期望的方式运行。
  （注意：功能测试反映的是测试目标，而黑盒测试反映的是具体测试方法，两者含义是有区别的，不能混为一谈）

• 一般情况下使用黑盒测试方法， 完整的功能测试主要在系统测试和验收测试时完成。

• 主要内容：

  • 用户界面（User Interface，UI) 测试软件界面是否规范合理，用户与软件通过界面交互是否方便。

  • 数据 ：数据接收处理正常，有容错处理备份保存功能，保证数据安全性和对旧版本的数据的兼容性。

  • 操作：程序的安装、启动以及卸载正常，可支持各种主流的应用环境。

  • 逻辑： 逻辑清晰且符合用户使用习惯。

  • 接口：可通过接口配合使用外部设备，可以向外部应用系统提供接口，可以通过规定接口使用第三方软件。

4.1.2非功能测试

• 非功能测试是相对于功能测试而言的，是针对软件非功能属性所进行的测试活动。通俗的来讲，功能测试面对的是软件“能不能用和够不够用”的问题，而非功能测试面对的是软件“好不好用”的问题。

• 非功能测试经常需要定量化的测试指标 SMART标准

  • 具体的（Specific）
  • 可度量的（Measurable）
  • 可实现的（Achievable）
  • 相关的（Relevant）
  • 有时限的（Time-bound）

• 非功能测试的主要内容

  • 性能测试——验证软件系统能否达到用户提出的性能指标；
  • 压力测试——模拟比预期要大的工作负载来暴露只在系统峰值条件下才会出现的缺陷；
  • 负载测试——主要测试系统在高于正常水平的负载下所出现的性能问题；
  • 可靠性测试——度量软件在一般情形和非预期情形下维持正常功能的能力；
  • 低资源测试——确定系统在重要资源降低或不足的情况下会出现的软件系统状况；
  • 容量测试——确定系统最大承受量；
  • 重复性测试——循环运行测试直到达到一个具体临界值或者异常境况；
  • 兼容性测试——测试软件面对不同软硬件平台和不同支持软件时能否正常运行；
  • 安全性测试——检查系统对非法侵入的防范能力；
  • 辅助功能测试——保证软件系统能被残疾人士使用；
  • 本地化测试——验证软件能否满足某一特定地区的语言、文化和风俗习惯的要求；
  • 配置测试——验证被测软件在不同的软件和硬件配置中的运行情况；
  • 可用性测试——测试在特定使用情景下，软件产品能够被用户理解、学习和使用的方便程度，以及评价软件产品能够吸引用户的能力。

4.1.3功能测试与非功能测试的区别

比较项目	功能测试	非功能测试
目的	验证软件系统是否满足用户的功能需求 能不能用和够不够用	验证软件系统的非功能性属性 好不好用
测试指标	非定量化	有定量化测试指标（SMART）
针对部位	大多具有局部特点	具有全局意义

4.2性能测试中有哪些常用指标，负载测试，理解系统性能和负载的关系。

4.2.1性能测试中的常用指标

web应用中还有点击率。

负载测试

• 特点：逐步增加系统的负载量（并发用户数、文件大小、数据库记录数），检测软件系统或具体被测对象在不同负载状况下所能达到的能力和性能水平。
• 通过逐步增加负载，最终确定在满足系统功能正确性的前提下，系统所能承受的最大负载量。
• 负载测试是一种性能测试方法和手段，通常在压力测试和容量测试中被采用。

系统性能与负载的关系

系统负载越大，系统的性能一般降低越多。

标准的软件系统负载性能模型如下图。

负载量等于最优并发用户数时，系统整体使用效率最高，系统资源充分利用。当负载量超过最优并发用户数时，系统响应时间延长，负载量超过最大并发用户数时，吞吐量急速下降，响应时间明显变长。

5第六章 软件缺陷报告与测试评估

5.1软件评估的方法（覆盖率评估和质量评估）

1.覆盖率评估

评估测试的覆盖率，对测试完成程度进行评测。最常见的覆盖率评估分为需求覆盖率评估和代码覆盖率评估。

2.质量评估

通过缺陷分析可以对软件的可靠性、稳定性等进行详细分析，对软件的性能进行多方面的评测，获得反映软件质量特征的多种指标数据，在此基础上确定软件质量与需求的相符程度。

5.2覆盖评估（基于需求的测试覆盖和基于代码的测试覆盖）

1.需求覆盖率评估

• 对需求的全面覆盖是软件测试的基本要求，需求覆盖率是测试到的功能和非功能需求占整个需求总数的百分比

• 评估需求覆盖率的最直观的方法是首先确定需求说明中有多少功能点，然后确定测试用例覆盖了多少模块和多少个功能点，已测功能点和全部功能点的比值就是需求覆盖率。

• 通常使用以下三种公式来计算需求的测试覆盖率：

• 计划的测试覆盖率=Tp/Rft （1）
• 已执行的测试覆盖率=Tx/Rft （2）
• 成功执行的测试覆盖率=Ts/Rft （3）

Rft是测试需求的总数
Tp是用测试过程或测试用例表示的计划测试需求数
Tx是用测试过程或测试用例表示的已执行的测试需求数
Ts是用完全成功、没有缺陷或意外结果的测试过程或测试用例表示的已执行测试需求数。

2.代码覆盖率评估

• 代码覆盖率是指所测试的源代码数量占代码总数的百分比。
• 代码覆盖率反映了测试用例对被测软件代码的覆盖程度，也是衡量测试工作进展情况的重要定量化指标。
• 将逻辑覆盖测试用例的测试结果进行量化就可以得到相应的语句覆盖率、路径覆盖率等代码覆盖率指标。
• 一个比较通用的代码覆盖标准是：关键模块的语句覆盖率要达到100%，分支覆盖率要达到85%以上。

5.3质量评估中的缺陷趋势分析，缺陷发现率与测试成本的一般关系

• 缺陷趋势分析是根据缺陷数量随时间变化的情况，分析和监控开发与测试的进展状况与质量，预测未来软件研发工作情况。
• 单位时间内发现的缺陷数量称为缺陷发现率，下图反映了一般情况下缺陷发现率与测试成本之间的关系。
  

6第七章 软件测试管理

6.1软件配置管理

• 软件配置管理（Software ConfigurationManagement，SCM）是一种标识、组织和控制软件变更的技术。
• 配置管理与软件开发过程紧密相关，其目的是为了建立和维护软件产品的完整性和一致性.

6.2软件配置管理的重点工作

• 1.配置项识别
• 2.变更控制
• 3.版本管理
• 4.配置状态报告
• 5.配置审计

6.3 配置项和基线，基线在配置管理中的作用

• 配置项
  软件配置项就是配置管理的对象。软件特定版本的配置项之间需要相互匹配以保持软件整体的一致性。
• 基线
  • 基线是已经正式通过审核批准的一个配置项或一组配置项的集合，因此可以作为进一步开发的基础，并且只能通过正式的变化控制过程来改变。
  • 基线通常与项目开发过程中的里程碑相对应，经过评审批准的阶段性成果的统一标识就标志着项目的不同基线。
  • 常见的基线有需求规格说明、设计说明、特定版本的源程序、测试计划等。
• 基线在配置管理中的作用
  作为进一步开发的基础，并且只能通过正式的变化控制过程来改变。

6.4 软件变更控制流程

变更控制的典型流程

7第八章 软件测试自动化

7.1 自动化测试的引入风险分析

• （1）成本风险
  自动化测试的成本包括人员、工具、硬件以及测试培训、准备、开发、执行和维护费用。
• （2）切入点的风险
  自动化测试的引入应当由简到难、由点到面。
• （3）切入方式的风险
  在引入自动化测试时不能贪多求全。
• （4）时间风险
  需要预留较为宽松的时间应对首次实施自动化测试所带来的冲击。
• （5）开发和测试流程以及设计变更的风险

7.2 适合引入自动化测试的软件项目

1. 程序已经基本稳定，不再会发生频繁的变动
2. 用户界面稳定
3. 项目的进度压力不大
4. 测试脚本的可重用性比较高
5. 回归测试的频率高、数量多
6. 软件产品有较高的性能要求
7. 组合遍历型的测试
8. 持续集成测试
9. 测试流程和测试用例设计规范
10. 资源充足