【笔记】《软件测试（第2版）》-周元哲

第一章 软件测试概述

1.1 计算机系统的软件可靠性问题

1. 千年虫问题

2. 爱国者导弹防御系统

3. 美国火星登陆事故

4. Intel奔腾芯片缺陷

5. Windows 2000安全漏洞

1.2 软件测试的概念

1.2.1 软件测试的定义

“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”。

1.2.2 测试用例

是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果的条件或变量，以便测试某个程序路径或核实是否满足某个特定需求。

1.2.3 软件测试的基本原则

1. 软件测试工作应尽早展开。因为越早发现问题，所花费的代价越小

2. 所有测试都应该追溯到用户的需求

3. 测试工作应该由独立的软件测评机构或测试小组来完成，而不能由开发人员承担

4. 设计测试用例时应该考虑到合法的输入和不合法的输入，甚至各种极端情况

5. 穷举测试是不可能的

6. 一定要注意测试中的错误集中发生的现象，这和程序员的编程水平和习惯有很大的关系

7. 制定详细的测试计划，并严格执行，避免测试的随意性

8. 回归测试的关联性一定要充分的注意，修改一个错误而引起更多的错误出现的现象并不少见

9. 妥善保存一切测试过程文档，包括测试需求规格说明、测试计划、测试说明、原始记录、问题报告以及测试报告等

1.2.4 软件测试从业人员要求

1.3 软件测试的过程

图1-3-1-1 软件测试过程

1. 单元测试：在软件开发过程中进行的最低级别的测试活动，其目的是检测程序模块中有无故障存在。

2. 集成测试：在单元测试基础之上，将各个模块组装起来进行的测试，其主要目的是发现与接口有关的模块之间的问题。

3. 确认测试：对照软件需求规格说明，对软件产品进行评估以确定其是否满足软件需求的过程。

4. 系统测试：软件开发完成以后，还应与系统中其他部分配合起来，进行一系列系统集成和测试，以保证系统各组成部分能够协调地工作。

5. 验收测试：向用户表明所开发的软件系统能够像用户所预定的那样工作。

6. 代码扫描

1.4 软件测试与软件开发的关系

1.4.1 软件开发过程

1. 制定计划

2. 需求分析

3. 软件设计

4. 程序编写

5. 软件测试

6. 运行维护

1.4.2 软件测试在软件开发中的作用

1. 项目规划阶段：负责整个测试阶段的监控。

2. 需求分析阶段：确定测试需求分析，制定系统测试计划。测试需求分析是指产品生存周期中测试所需的资源、配置、各阶段评审通过的标准等。

3. 概要设计和详细设计阶段：制定集成测试计划和单元测试计划。

4. 编码阶段：开发相应的测试代码或测试脚本。

5. 测试阶段：实施测试，并提交相应的测试报告。

1.4.3 软件测试模型

图1-4-3-1 软件测试与软件开发的关系

1. V模型
   
   图1-4-3-2 软件测试过程V模型

2. W模型
   
   图1-4-3-3 软件测试过程W模型

3. H模型

图1-4-3-4 软件测试过程H模型

4. X模型
   
   图1-4-3-5 软件测试过程X模型

1.4.4 软件测试环境的搭建

1. 测试环境=硬件+软件+网络+数据准备+测试工具

   1. 硬件环境：主要是指PC机、笔记本电脑、服务器、各种PDA终端等。

   2. 软件环境：主要是软件运行的操作系统。

   3. 网络环境：主要指的是C/S结构还是B/S结构。

   4. 数据准备：主要指的是测试数据的准备。

   5. 测试工具：目前市场上的测试工具很多，可分为静态测试工具、动态测试工具、黑盒测试工具、白盒测试工具、测试执行评估工具、测试管理工具等。

1.5 软件测试的发展和现状

1.6 我国软件测试产业现状

1.7 软件测试工具

1. 白盒测试工具

   1. 静态测试工具

   2. 动态测试工具

2. 黑盒测试工具

3. 测试设计与开发工具

4. 测试执行和评估工具

5. 管理测试工具

6. 代码扫描工具

7. 三大软件测试工具提供商

   1. MI公司产品介绍

   2. IBM Rational公司产品介绍

   3. Compuware公司产品介绍

第二章 软件缺陷

2.1 软件缺陷概述

2.1.1 软件缺陷的定义

1. 定义：程序中存在的错误，如语法错误、拼写错误或者一个不正确的程序语句。

2. 软件缺陷包括

   1. 软件没有达到产品说明书表明的功能。

   2. 程序中存在语法错误。

   3. 程序中存在拼写错误。

   4. 程序中存在不正确的程序语句。

   5. 软件出现了与产品说明书中不一致的表现。

   6. 软件功能超出产品说明书的范围。

   7. 软件没有达到用户期望的目标。

   8. 测试员或用户认为软件的易用性差。

3. 按照定义分类

   1. 文档缺陷

   2. 代码缺陷

   3. 测试缺陷

   4. 规程缺陷

2.1.2 软件缺陷分析

2.1.3 软件缺陷的种类

1. 输入缺陷

   1. 不接受正确输入

   2. 接受不正确输入

   3. 描述有错或遗漏

   4. 参数有错或遗漏

2. 输出缺陷

3. 格式有错

4. 结果有错

5. 在错误的时间产生正确的结果

6. 不一致或遗漏结果

7. 不合逻辑的结果

8. 拼写/语法错误

9. 修饰词错误

10. 逻辑缺陷

    1. 遗漏情况

    2. 重复情况

    3. 极端条件出错

    4. 解释有错

    5. 遗漏条件

    6. 外部条件有错

    7. 错误变量的测试

    8. 不正确的循环迭代

    9. 错误的操作符

11. 计算缺陷

    1. 不正确的算法

    2. 遗漏计算

    3. 不正确的操作数

    4. 不正确的操作

    5. 括号错误

    6. 精度不够

    7. 错误的内置函数

12. 接口缺陷

    1. 不正确的中断处理

    2. I/O时序有错

    3. 调用了错误的过程

    4. 调用了不存在的过程

    5. 参数不匹配

    6. 不兼容的类型

13. 数据缺陷

    1. 不正确的初始化

    2. 不正确的存储/访问

    3. 错误的标志/索引值

    4. 不正确的打包/拆包

    5. 使用了错误的变量

    6. 错误的数据引用

    7. 缩放数据范围或单位错误

    8. 不正确的数据维数

    9. 不正确的下标

    10. 不正确的类型

    11. 不正确的数据范围

    12. 传感器数据超出限制

    13. 不一致数据

2.1.4 软件缺陷的产生

1. 疏忽造成的错误

   1. 显式约束造成的错误

   2. 隐式约束造成的错误

2. 不理解造成的错误

3. 二义性造成的错误

4. 遗漏造成的错误

2.1.5 软件缺陷数目估计

1. 撒播模型

2. 静态模型

3. Akiyama模型：

N是缺陷数，L是可执行的源语句数目

1. 谓词模型：

C是谓词数目，J是子程序数目

1. Halstead模型：

2. Lipow模型：：

3. Gaffnev模型：

4. Compton and Withrow模型：

5. 根据测试覆盖率的预测模型

   1. 错误与时间曲线

   2. 错误与覆盖率曲线

   3. 覆盖率与时间曲线

2.1.6 软件测试效率分析

1. 软件测试的检测能力分析

2. 影响软件测试效率的因素

   1. 人为因素

   2. 软件类型

   3. 缺陷类型

      1. 初始化错误

      2. 控制错误

      3. 数据错误

      4. 计算错误

      5. 集成错误

      6. 容貌错误

2.2 软件缺陷管理

2.2.1 缺陷管理的目标

1. 确保每个发现的缺陷都能够解决

2. 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段

3. 收集缺陷数据并在其上进行数据分析，作为组织的过程管理财富

2.2.2 缺陷报告

2.2.3 软件缺陷管理流程

图2-2-3-1 缺陷的一般管理流程

1. 缺陷管理流程中的角色

   1. 测试人员A1

   2. 项目经理A2

   3. 开发人员A3

   4. 评审委员会A4

2. 权限管理流程中的缺陷状态

   1. 初始化——缺陷的初始状态

   2. 待分配——缺陷等待分配给相关开发人员处理

   3. 待修正——缺陷等待开发人员修正

   4. 待验证——开发人员已完成修正，等待测验人员验证

   5. 待评审——开发人员拒绝修改缺陷，需要评审委员会评审

   6. 关闭——缺陷已被处理完成

3. 缺陷管理流程描述

4. 缺陷管理流程实施的注意事项

2.2.4 缺陷管理工具

1. TrackRecord（商用）

   1. 定义了信息的条目类型

   2. 定义规则

   3. 工作流程

   4. 查询

   5. 概要统计或图形表示

   6. 网络服务器

   7. 自动电子邮件通知

2. ClearQuest（商用）

   1. 支持微软Access和SQL Server等数据库

   2. 拥有可完全定制的界面和工作流程机制，能适用于任何开发过程

   3. 可以更好地支持最常见的更变请求（包括缺陷和功能改进请求），并且便于对系统做进一步的定制，以便管理其他类型的更变

   4. 提供了一个可靠的集中式系统，该系统与配置管理、自动测试、需求管理和过程指导等工具集成，使项目中每个人都可以对所有变更发表意见，并了解其变化情况。

   5. 与IBM
      Rational的软件管理工具ClearCase完全集成，让用户充分掌握变更需求情况。

   6. 能适应所需的任何过程、业务规则和命名约定

   7. 强大的报告和图表功能，使用户能直观、简便地使用图形工具制定所需的报告、查询和图表，帮助用户深入分许开发现状

   8. 自动电子邮件通知、无须授权的web登录以及对Windows、UNIX和Web的内在支持，ClearQuest可以确保团队中的所有成员都被纳入缺陷和更变请求的交流中

3. Bugzilla（开源）

   1. 普通报表生成

   2. 基于表格的视图

   3. 请求系统

   4. 支持企业组成员设定

   5. 时间追踪功能

   6. 多种验证方法

   7. 补丁阅读器

   8. 评论回复连接

   9. 视图生成功能

   10. 统一性检测

4. 其他

   1. Buggit（开源）

   2. Mantis（开源）

   3. HP Quality Center（简称QC，商用）

第三章 黑盒测试

3.1 黑盒测试的基本概念

黑盒测试是从一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。

3.2 等价类划分法

3.2.1 等价类划分法的原理

1. 划分等价类

   1. 有效等价类：符合程序规格说明书，有意义的、合理的输入数据所构成的集合。

   2. 无效等价类：不符合程序规格说明书，不合理或无意义的输入数据所构成的集合。

2. 常用的等价类划分原则

   1. 按区间划分：如果规格说明规定了输入条件的取值范围或值的数量，则可以确定一个有效等价类和两个无效等价类。

   2. 按数值划分：如果规格说明规定了一组输入数据，而且程序要对每一个输入值分别进行处理，则可为每一个输入值确立一个有效等价类，针对这组值确立一个无效等价类，它是所有不允许输入。

   3. 按数值的集合划分：如果规格说明规定了输入值的集合，则可确定一个有效等价类和一个无效等价类(该集合有效值之外)。

   4. 按限制条件或规则划分：如果规格说明规定了输入数据必须遵守的规则或限制条件，则可以确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。

   5. 细分等价类：等价类中的各个元素在程序中的处理若不相同，则可将此等价类进一步划分成更小的等价类

3. 等价类划分测试用例设计

   1. 为每个等价类规定一个唯一的编号

   2. 设计一个新的测试用例，尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步直到测试用例覆盖了所有的有效等价类

   3. 设计一个新的测试用例，使其覆盖并且只覆盖一个还没有被覆盖的无效等价类

3.2.2 等价类划分法的测试运用

1. 三角形问题的等价类测试√

2. 保险公司人寿保险保费计算程序的等价类测试√

3.3 边界值分析法

3.3.1 边界值分析法的原理

1. 边界条件

2. 边界值分析测试

3. 健壮性边界值测试

3.3.2 边界值分析法的测试运用

1. 三角形问题的边界值分析测试用例设计√

2. 加法器边界值测试用例设计√

3.4 因果图法

3.4.1 因果图法的原理

1. 因果图：因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态(或称原因)，右结点表示输出状态(或称结果)。
   
   图3-4-1-1 因果图的基本符号

图3-4-1-2 约束符号

1. 因果图法测试用例的设计步骤

   1. 确定软件规格中的原因和结果

   2. 确定原因和结果之间的逻辑关系

   3. 确定因果图中的各个约束

   4. 把因果图转换为决策表

   5. 根据决策表设计测试用例

3.4.2 因果图法的测试运用

1. 软件规格说明书√

2. 五毛饮料机找零问题√

3.5 决策表法

3.5.1决策表法的原理

决策表并不是因果图的一个辅助工具，在一个程序中，如果输入输出比较多，输入之间、输出之间相互制约的条件比较多，在这种情况下应用决策表很合适，它可以更清楚地表达它们之间的各种复杂关系。

1. 决策表：把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。

   1. 条件桩

   2. 条件项

   3. 动作桩

   4. 动作项

2. 决策表的构造及简化

   1. 构出所有的条件桩和动作桩

   2. 确定规则的个数

   3. 填入条件项

   4. 填入动作项，得到初始决策表

   5. 简化决策表，合并相似规则

3. 依据决策表生成测试用例

3.5.2 决策表法的测试运用

1. 阅读指南√

2. NextDate函数√

3.6 黑盒测试方法的比较与选择

1. 测试工作量：主要以边界值分析、等价类划分和决策表测试方法来讨论它们的测试工作量，即生成测试用例的数量与开发这些测试用例所需的工作量。
   
   图3-6-1-1 每种测试方法的测试用例数量
   
   图3-6-1-2 每种方法设计测试用例的工作量趋势

2. 测试有效性

3.7 黑盒测试工具介绍

3.7.1 黑盒测试工具概要

1. 功能测试工具：检测被测程序能否达到预期的功能要求并能正常运行。

2. 性能测试工具：确定软件和系统性能。

3.7.2 黑盒功能测试工具——QTP

1. 设计测试用例

2. 创建测试脚本

3. 编辑测试脚本

4. 运行测试

5. 分析测试

3.7.3 黑盒功能测试工具——Selenium

1. 原理

2. Selenium的特点

3. 安装过程

4. 执行一个测试

3.7.4 其他常用功能测试工具

1. IBM Rational公司的功能测试工具Robot

2. Compuware公司的自动黑盒测试工具QACenter

   1. 功能测试工具QARun

   2. 性能测试工具QALoad

   3. 可用性管理工具EcoTools

   4. 性能优化工具EcoScope

3.7 黑盒测试方法-正交试验法

1. 全面试验法：M*N*P*Q…

2. 简单对比法：M+N+P+Q…

3. 正交试验法

   1. 每一列中各数字出现的次数都一样多

   2. 任何两列所构成的各有序数对出现的次数都一样多

3.8 黑盒测试方法-场景法和错误推测法

1. 场景法

用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。

1. 错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

第四章 白盒测试

用来分析程序的内部结构。

4.1 控制流测试

4.1.1 基本概念

1. 有向图：G=(V,E)，V是顶点的集合,E是有向边(本文简称边)的集合。e=(T(e),H(e))∈E是一对有序的邻接节点，T(e)是尾，H(e)是头。如果H(e)=T(e’),则e和e’是临界边。H(e)是T(e)的后继节点，T(e)是H(e)的前驱节点，indegree(n)和outdegree(n)分别是节点n的入度和出度。

2. 路径：如果P=e1e2…eq，且满足T(ei+1)=H(ei)，则P称为路径，q为路径长度。

3. 完整路径：如果P是一条路径，且满足e1=e0，eq=ek(e0是程序的原节点，ek是其汇结点)则P称为完整路径。如果存在输入数据使得程序按照该路径运行，这样的路径称为可行完整路径，否则称为不可行完整路径。

4. 可达：如果ei到ej存在一个路径，则称ei到ej是可达的。

5. 简单路径：若路径上所有的节点都是不同的，则称为简单路径。

6. 基本路径：任意有向边最多出现一次的路径称为基本路径。

7. 子路径：如果满足1≤u≤t≤q，路径A=eueu+1…et，是B=e1e2…eq的子路径。

8. 回路：若路径A=eueu+1…eq满足T(e1)=H(eq)，则P称为回路。除了第一个和嘴和一个节点外，其他节点都不同的回路称为简单回路。

9. 无回路路径：若一条路径中不包含回路子路径，则称为无回路路径。

10. A连接B：若A=eueu+1…et，B=evev+1…eq为两条路径，如果H(et)=T(ev)且eueu+1…etevev+1…eq为路径，则称A连接B，记为A*B。

11. 路径A覆盖路径B：如果路径B中所含的有向边均在路径A中出现，则称路径A覆盖路径B。

4.1.2 控制流覆盖准则

1. 语句覆盖准则：最简单的结构性测试方法之一。它要求在测试中，程序中的每条语句都得到运行。
   

2. 分支覆盖准则
   

3. 谓词测试

   1. 原子谓词覆盖准则
      
   2. 分支-谓词覆盖准则
      
   3. 复合谓词覆盖准则
      
   4. 路径覆盖准则
      

4.2 数据流测试

4.2.1 基本概念

控制流测试是面向程序的结构，控制流图和测试覆盖准则一旦给定，即可产生测试用例，至于程序中每个语句是如何实现的它并不关心。与控制流的测试思想不同，数据流测试面向程序中的变量。

1. 变量的定义性出现：若一个变量在程序中的某处出现使数据与该变量相绑定，则称该出现是定义性出现。

2. 变量的引用性出现：若一个变量在程序中的某处出现使与该变量相绑定的数据被引用，则称该出现是引用性出现。

4.2.2 数据流覆盖准则

1. 这些覆盖准则之间的包含关系如下

   1. “定义-引用覆盖准则”包含“引用覆盖准则”

   2. “引用覆盖准则”包含“定义覆盖准则”

4.3 代码审查

4.3.1 代码审查的意义

1. 可靠性：事实证明按照某种标准或规范编写的代码比不这样做的代码更可靠，软件缺陷更少。

2. 可读性/维护性：符合标准和规范的代码易于阅读、理解和维护。

3. 移植性：代码经常需要在不同的硬件上运行，或者使用不同的编译器编译。

4.3.2 代码审查的内容

1. 可追溯性

2. 逻辑

3. 数据

4. 接口

5. 文档

6. 注释

7. 异常处理

8. 内存

9. 其他

4.3.3 代码审查的过程

1. 代码审查策划阶段

2. 代码审查实施阶段

3. 代码审查总结阶段

4.4 代码走查

4.4.1 代码走查的意义

经验表明，代码走查通常能够有效地查找出30%~70%的逻辑设计和编码错误。

4.4.2 代码走查小组的组成

1. 一位极富经验的程序员。

2. 一位程序设计语言专家。

3. 一位程序员新手(可以给出新颖、不带偏见的观点)。

4. 最终维护程序的人员。

5. 一位来自其他不同项目的人员。

6. 一位来自该软件编程小组的程序员。

4.4.3 代码走查的过程

1. 准备阶段

2. 生成实例

3. 执行走查

4. 形成报告

4.5 程序变异测试

是一种错误驱动测试，是针对某种类型的特定程序错误而提出来的。

4.5.1 程序强变异测试

4.5.2 程序弱变异测试

1. 变量定义与引用

2. 算术表达式

3. 关系表达式

4. 布尔表达式

4.6 白盒测试工具

4.6.1 Emma

1. 安装方法

2. 测试过程

   1. 测试基本流程

   2. Coverage单独视图

   3. 覆盖测试报告

   4. EclEmma对Junit单元测试的支持

3. Emma其他特性

4.6.2 C++test

1. 软件功能

   1. 静态代码检测

   2. 单元测试

2. 测试过程

4.6.3 Junit

1. Junit框架

   1. TestCase（测试用例）

   2. TestSuite

   3. TestRunner

   4. Assert

2. Junit的优势

4.6.4 Testbed

1. 代码评审

2. 质量评审

3. 设计评审

4. 单元测试

5. 检测验证

6. 测试管理

4.7 单元测试工具CTS

1. 选择“工程”菜单中的“新建工程”命令

2. 工程建立完毕后，界面的工程视图中显示了所有的文件信息

3. 覆盖准则选择

4. 选择工具栏中的“模块划分”按钮或工程名右键菜单中的“模块划分”选项，系统将对选定的文件和函数进行模块划分

5. 选择测试用例生成方式，有三个选项，选择“自动测试”

6. 查看测试结果

7. 故障定位

8. 回归测试及回归报告查看

第五章 基于缺陷模式的软件测试

5.1 基于缺陷模式的软件测试概述

1. 缺陷模式需满足的条件

   1. 该模式下的缺陷是符合实际的。

   2. 基于该模式的缺陷数目是可以容忍的，一般来讲，缺陷个数跟系统的规模成线性关系。

   3. 该模式下的缺陷是可以测试的。

2. 软件测试工具的特点

   1. 针对性强

   2. 具有特殊性

   3. 工具自动化程度高以及检测效率高

   4. 缺陷定位准确

   5. 易学、易用

5.2 基于缺点模式的软件测试指标分析

设P是待测程序，将缺陷模式M分成类M={M1，M2，…，Mn}，每类分成种M={Mi1，Mi2，…，MiL}，从P中计算出和M相匹配的检查点的集合IP={IP1，IP2，…，IPm}

1. 漏报率（ER）
   

2. 准确率（CR）
   

3. 误报率（DR）
   

4. 缺陷检测率（DDR）

5. 自动缺陷检测率（ADR）

6. 计算复杂性

5.3 缺陷模式

5.3.1 缺陷模式概述

1. 故障模式：此类缺陷是故障，一经产生，会导致系统出错。

   1. 内存泄露模式

   2. 资源泄漏模式

   3. 指针使用错误模式

   4. 数组越界模式

   5. 非法计算模式

   6. 使用未初始化变量模式

   7. 死循环结构模式

   8. 死锁模式

2. 安全漏洞模式：此类缺陷会给系统留下安全隐患，为攻击该系统开了绿灯。

   1. 缓冲区溢出模式

   2. 被感染的数据模式

   3. 竞争条件模式

   4. 风险操作模式

3. 缺陷模式：此类缺陷是不应该发生的，它未必会造成系统的错误，但可能会隐含某些故障，或者是由初级软件工程师不理解造成的。

   1. 性能缺陷模式：此类缺陷会降低系统的性能

   2. 疑问代码模式：让人费解的代码

4. 规则模式：软件开发总要遵循一定的规则，某个团队也有一些开发规则，违反这些规则也是不允许的。

   1. 代码规则

   2. 复杂性规则

   3. 控制流规则

   4. 命名规则

   5. 可移植性规则

   6. 资源规则

5.3.2 故障模式

1. 存储泄露的故障模式

内存泄漏故障：设在程序的某处申请了大小为M的空间，凡在程序结束时MB或者MB的一部分没被释放，或者多次释放MB或MB的一部分都是内存泄漏故障。

1. 遗漏故障：是指申请的内存没有被释放。

   1. 不匹配故障：是指申请函数和释放函数不匹配。

   2. 不相等的释放错误：是指释放的空间和申请的空间大小不一样。

2. 数组越界故障的故障模式

设某数组定义为Array[min~max]，若引用Array[i]且imax都是数组越界故障。

1. 对程序中任何出现Array[i]的地方，都要判断i的范围，可能有三种情况

   1. 若i是在数组定义的范围内，则是正确的。

      1. 若i是在数组定义的范围外，则是OBAF。

      2. 若i是不确定的，则Array[i]是否是OBAF则不确定。

   2. 字符串拷贝过程中存在的数组越界故障

   3. 在结构类型中，由于结构体中的成员变量是连续存放的，数组复制过程中，多余的数据会自动地存放在后面所定义的成员变量中，这种情况数组并不产生越界错误。

2. 使用未初始化变量故障模式

存在一个路径，在该路径上使用前面没有被赋初值的变量会出现使用未初始化变量故障。

1. 在C++中，由于静态变量和全局变量隐含了被赋予初值0,因此，静态变量和全局变量未被赋予初值，而不是使用未初始化变量故障模式故障。

   1. 当一个未被初始化的变量作为函数的参数时，该变量可能在函数中被赋予初值，这种情况也不属于使用未初始化变量故障模式故障。

   2. 变量x在一个条件或一个循环中被赋值，在该条件或循环后将x赋给变量y,此时,由于难以确定该条件或循环是否被执行，因此，这种情况也不列为使用未初始化变量故障模式故障。

   3. 变量x在case语句中被赋值，如果case语句是完备的，在case后将x赋给变量y,这种情况也不是使用未初始化变量故障模式故障。

2. 空指针使用故障

引用空指针或给空指针赋值的都是空指针使用故障

1. 非法计算类故障

   1. 除数为0故障

   2. 对数自变量为0或负数故障

   3. 根号内为负数的故障

2. 死循环结构模式

   1. 无增量或增量与结束条件无关

   2. 无结束条件

   3. 增量的变化趋势不能使循环结束

3. 资源泄露故障模式

在Java程序中，当一个资源被打开后，如果并不是在所有的可执行路径上都对其进行了显式的释放操作，则是一个资源泄漏故障。

1. 简单泄露：资源被分配给本地变量，在该变量的有效范围内并没有释放资源。

   1. 异常泄漏：资源被分配给本地变量，在该变量的有效范围内也释放了资源，但是在释放资源之前由于异常被抛出，导致资源释放操作没有执行。

   2. 交叉函数的情况：在一个方法内分配资源，该资源被传送到另一个方法内，在另一个方法内没有正常释放资源。

   3. “静态”情况：资源被分配给静态变量或者其他非本地变量，该变量没有正常释放。

2. 并发故障模式

   1. 不正确的同步

      1. 不连续的同步

      2. 对易变域的同步

      3. Set方法被同步了但是get方法却没有

      4. 方法writeObject同步但是其他方法均没有同步

      5. 方法readObject使用了synchronized修饰

      6. 静态域的不正确初始化

   2. 可能导致死锁

在Java中，对锁的不正确操作可能造成导致死锁的缺陷。

1. 方法占有两个锁时通知解锁

   1. 存在没有释放锁的路径

      1. 互锁引起的死锁

      2. 方法在上了锁之后又循环调用了Thread.sleep()

      3. 占有两个锁的时候再请求锁

   2. 多线程应用中方法调用时机或方式不正确

在Java中，一些同步方法的不正确调用将造成该类缺陷。

1. 错误地调用了notify或者notifyAll

   1. 错误地调用了wait

      1. 没有改变临界条件就调用了notify

      2. 调用notify而不是notifyAll

      3. 无等待条件

      4. 线程对象直接调用了run()方法

   2. 同一变量的双重验证

在Java中，同一变量的双重验证指对一个对象进行了两次判断，判断其是否为空。

1. 互相初始化的类

在Java中，相互初始化的类指的是两个类中分别有对对方类的实例初始化的代码。

1. 循环初始化

   1. 超类在初始化中使用子类

5.3.3 安全漏洞模式

1. 缓冲区溢出漏洞模式

当程序要在一个缓冲区内存储比该缓冲区的大小还要多的数据时，就会产生缓冲区溢出漏洞。

1. 数据拷贝造成的缓冲区溢出

   1. 格式化字符串造成的缓冲区溢出

2. 被污染的数据模式

程序从外部获取数据时，这些数据可能含有具有欺骗性或者是不想要的垃圾数据，如果在使用这些数据前不进行合法性检查则将威胁到程序的安全,造成一个被污染的数据缺陷。被污染的数据可能会导致程序不按原计划执行，也有可能直接或间接地导致缓冲区溢出缺陷。

1. 数据来自外部的全局变量

   1. 数据来自输入函数

2. 竞争条件

如果程序中有两种不同的I/O调用同一文件进行操作，而且这两种调用是通过绝对路径或相对路径引用该文件的，那么就易出现竞争条件问题。在两种操作进行的间隙，黑客可能改变文件系统，那么将会导致对两个不同的文件操作而不是同一文件进行操作。

1. access()和remove()之间造成的竞争条件

   1. opendir()和stat()之间造成的竞争条件

2. 风险操作

如果不恰当地使用了某些标准库函数，可能会带来安全隐患。在某些情况下，某些函数一经被使用,就可能会带来安全隐患。

1. _spawnvpe()函数使用相对路径

   1. 不可靠的随机数

   2. 可预测的临时文件名

   3. 危险的外部程序调用

   4. Socket绑定问题

   5. 使用不可靠的宏

   6. 使用不可靠的注册表参数

   7. 使用不可靠的参数

   8. 对明确的宏定义使用变量

   9. 变量作为注册表参数

   10. 使用不可靠的SHELL命令

   11. 不充分的路径

   12. 不安全的权限提升

   13. 使用不可靠的加密算法

   14. 使用不可靠的进程创建

   15. 不可靠的资源处理

   16. 忽略检查函数的返回值

   17. 命名管道的缺陷

   18. Windows临时文件的脆弱性

   19. 意外的内存拷贝

   20. 文件存取函数

   21. 不安全的文件操作

   22. 暴露绝对路径

5.3.4 缺陷模式

1. 低性能模式

   1. 使用低调函数/代码

在Java程序中，对于一些特定的类、函数和语法，如果没有使用合适的方法，将造成性能下降，此类缺陷为使用低效函数/代码缺陷。

1. 判断字符串为空的方法使用

   1. 逻辑表达式中使用了非短路运算符

      1. 使用低效的类型构造器

      2. 不必要的包装类实例化

      3. 产生随机整数

      4. 在多个类之间复制很大的字符串常量

      5. 循环中的字符串连接

      6. 未定义的静态的内部类

      7. 未声明为静态的属性

      8. 调用低效的java.net.URL的比较方法

   2. 使用多余函数

在Java中，调用了一些不必要的函数调用，从而造成性能下降，此类缺陷为使用多余函数缺陷。

1. 同一锁的同步方法调用

   1. 没有必要的方法调用

      1. 调用了不必要的getClass()方法

      2. 参数为常数的数学方法

      3. 字符串变量调用toString()方法

   2. 显式垃圾回收

在Java中，垃圾回收是很耗费资源的，显示地调用垃圾回收机制会导致应用的性能急剧下降，此类缺陷为显式垃圾回收缺陷。

1. 冗余代码

在Java中，存在从未使用过的方法或者属性，或者存在从未使用(读取)过的局部变量，此类缺陷为冗余代码缺陷。

1. 头文件中定义的静态变量

头文件中定义的函数或变量被声明为静态的，即包含该头文件的任一文件都比较并拷贝一份该对象，这样无疑明显地增加了可执行文件的大小。

1. 不必要的文件包含

一个文件包含了另一个头文件却没有使用该头文件中的任一符号，这种缺陷会增加编译的时间。

1. 字符串低效操作

循环中的字符串连接。在循环里用“+”做String变量的连接。

1. 简单的运算可以替代

   1. i=i+1可以替代为i++

      1. i=i-1可以替代为i–

2. 代码国际化模式

3. 疑问代码模式

5.3.5 规则模式

1. 代码规则

2. 复杂性规则

3. 控制流规则

4. 命名规则

5. 可移植性规则

6. 资源规则

5.4 软件缺陷检测系统（DTS）

5.4.1 DTS系统结构

图5-4-1-1 DTS的系统结构

1. 构造抽象语法树

处理模块读入待测源码，经过预处理、词法分析、语法分析，产生与程序对应的抽象语法树。

1. 生成控制流图

从抽象语法树构造程序的控制流图，控制流图反映了程序的控制结构。程序的控制流图与语法树是相对应的，控制流图的每一个节点对应语法树上的语句节点，从控制流图可以访问语法树，同样的从语法树的语句节点也可以很方便的访问到控制流图的相应节点。

1. 生成符号表

从抽象语法树生成符号表，符号表被用来记录标识符的类型、作用域以及绑定信息。符号表将标识符与其类型和位置进行映射。在处理类型、变量和函数的声明的时候，这些标识符应该可以在符号表中得到解释。当发现有标识符被使用时，这些标识符应该都可以在符号表中找到。

1. 区间运算

区间运算支持区间集运算和实数、布尔变量、句柄变量和数组变量等多种数据类型的区间运算，可以对声明语句、赋值语句和条件语句进行区间计算，在控制流图遍历时，通过区间运算可以大概计算程序变量的取值范围，该信息用于缺陷模式的测试和不可达路径的消除。

1. 缺陷测试

缺陷模式统一测试框架读入软件缺陷状态机描述文件，通过解析器生成缺陷状态机内部数据结构。缺陷模式分析引擎对控制流图进行遍历，在遍历过程中，计算控制流图缺陷状态机的状态变迁，如果状态机进人缺陷状态则报告缺陷。

1. IP确认

对于每个IP，通常需要人工去判定该IP是否真的存在缺陷，考虑程序的逻辑复杂性以及测试代价等因素，IP
经确认后分为3种情况：缺陷、非缺陷，以及不能确定。根据作者经验估计，IP确认占测试代价的80%以上，通常由有经验的测试小组进行确认，每个成员平均每天能确认100个~200个IP。

5.4.2 DTS缺陷模式描述

1. 缺陷模式状态机

2. 缺陷模式状态机的XML描述

5.4.3 DTS的测试界面

5.4.4 DTS测试应用报告

第六章 集成测试

6.1 集成测试概述

6.1.1 集成测试的概念

1. 集成

指把多个单元组合起来形成更大的单元。

1. 集成测试

在假定各个软件单元已经通过了单元测试的前提下，检查各个软件单元之间的相互接口是否正确。

6.1.2 集成测试与系统测试的区别

表6-1-2-1 集成测试与系统测试的区别

	集成测试	系统测试
测试对象	通过了单元测试的各个模块所集成起来的组件	除了软件之外，还包括计算机硬件、相关的外围设备以及数据传输机构等
测试时间	集成测试是介于单元测试和系统测试之间的测试，在测试时间上，集成测试先于系统测试。
测试方法	白盒测试和黑盒测试相结合的测试方法	常用黑盒测试
测试内容	各个单元模块之间的接口，以及各个模块集成后所实现的功能	整个系统的功能和性能
测试目的	发现单元之间接口的错误，以及发现集成后的软件同软件概要设计说明书不一致的地方	通过与系统需求定义相比较之后发现软件与系统定义不符合或矛盾的地方。
测试角度	工作人员	用户

6.1.3 集成测试与开发的关系

集成测试是和软件开发过程中的概要设计阶段相对应的，软件概要设计中关于整个系统的体系结构是集成测试用例设计的基础。概要设计作为软件设计的骨架，可以清晰地看出大型系统中的组件或子系统的层次构造。那么，软件产品的层次、组件分布、子系统分布等也就一目了然，这为集成测试策略的选取提供了重要的参考依据，从而可以减少集成测试过程中桩模块和驱动模块开发的工作量，促使集成测试快速、高质量的完成。而集成测试可以服务于架构设计，可以检验所设计的软件架构中是否有错误和遗漏，以及是否存在二义性。集成测试和架构设计也是相辅相成的。

6.1.4 集成测试的层次与原则

1. 集成测试的层次

   1. 对于传统软件来说，按集成粒度不同

      1. 模块间集成测试

      2. 子系统内集成测试

      3. 子系统间集成测试

   2. 对于面向对象的应用系统来说，按集成粒度不用

      1. 类内集成测试

      2. 类间集成测试

2. 集成测试的原则

   1. 所有公共接口必须被测试到。

   2. 关键模块必须进行充分测试。

   3. 集成测试应当按-定层次进行。

   4. 集成测试策略选择应当综合考虑质量、成本和进度三者之间的关系。

   5. 集成测试应当尽早开始，并以概要设计为基础。

   6. 在模块和接口的划分，上，测试人员应该和开发人员进行充分沟通。

   7. 当测试计划中的结束标准满足时，集成测试才能结束。

   8. 当接口发生修改时，涉及到的相关接口都必须进行回归测试。

   9. 集成测试应根据集成测试计划和方案进行，不能随意测试。

   10. 项目管理者应保证审核测试用例。

   11. 测试执行结果应当如实地记录。

6.2 集成测试策略

1. 驱动模块：用以模拟待测模块的上级模块。驱动模块在集成测试中接受测试数据，把相关的数据传送给待测模块，启动待测模块，并打印出相应的结果。

2. 桩模块：也称为存根程序，用以模拟待测模块工作过程中所调用的模块。桩模块由待测模块调用，它们一般只进行很少的数据处理，例如打印人口和返回，以便于检验待测模块与其下级模块的接口。

6.2.1 非渐增式集成

非渐增式集成方法首先对每个子模块进行测试(即单元测试)，然后将所有模块全部集成起来一次性进行集成测试。

6.2.2 渐增式集成

渐增式集成与“一步到位”的非渐增式集成相反，它把程序划分成小段来构造和测试，在这个过程中比较容易定位和改正错误，对接口可以进行更彻底的测试，可以使用系统化的测试方法。

1. 自顶向下集成

   1. 对主控制模块进行测试，测试时用桩模块代替所有直接附属于主控制模块的模块。

   2. 根据选定的结合策略(深度优先或宽度优先)，每次用一个实际模块代换一个桩模块(新结合进来的模块往往又需要新的桩模块)。

   3. 在结合进一个模块的同时进行测试。

   4. 为了保证加入模块没有引进新的错误，可能需要进行回归测试(即全部或部分地重复以前做过的测试)。

2. 自底向上集成

   1. 把低层模块组合成实现某个特定的软件子功能的族。

   2. 写一个驱动程序(用于测试的控制程序),协调测试数据的输人和输出。

   3. 对由模块组成的子功能族进行测试。

   4. 去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能组

6.2.3 三明治集成

1. 确定以哪一层为界来进行集成(若确定以B模块为界)。

2. 对模块B及其所在层下面的各层使用自底向上的集成策略。

3. 对模块B所在层上面的层次使用自顶向下的集成策略。

4. 对模块B所在层各模块同相应的下层集成。

5. 对系统进行整体测试。

6.3 集成测试用例设计

1. 为系统运行设计用例

   1. 等价类划分。

   2. 边界值分析。

   3. 基于决策表的测试。

2. 为正向测试设计用例

   1. 输人域测试。

   2. 输出域测试。

   3. 等价类划分。

   4. 状态转换测试。

   5. 规范导出法。

3. 为逆向测试设计用例

   1. 错误猜测法。

   2. 基于风险的测试。

   3. 基于故障的测试。

   4. 边界值分析。

   5. 特殊值测试。

   6. 状态转换测试。

4. 为满足特殊需求设计用例

5. 为高覆盖设计用例

   1. 功能覆盖分析。

   2. 接口覆盖分析。

6. 测试用例补充

7. 注意事项

6.4 集成测试过程

图6-4-1-1 集成测试过程

1. 计划阶段

   1. 确定被测试对象和测试范围。

   2. 评估集成测试被测试对象的数量及难度，即工作量。

   3. 确定角色分工和划分工作任务。

   4. 标识出测试各个阶段的时间、任务和约束条件。

   5. 考虑一定的风险分析机及急计划。

   6. 考虑和准备集成测试需要的测试工具、测试仪器、环境等资源。

   7. 考虑外部技术支援的力度和深度，以及相关培训安排；定义测试完成标准。

2. 设计阶段

   1. 被测对象结构分析。

   2. 集成测试模块分析。

   3. 集成测试接口分析。

   4. 集成测试策略分析。

   5. 集成测试工具分析。

   6. 集成测试环境分析。

   7. 集成测试工作量估计和安排。

3. 实施阶段

   1. 集成测试用例设计。

   2. 集成测试规程设计。

   3. 集成测试代码设计(系统需要)。

   4. 集成测试脚本开发(系统需要)。

   5. 集成测试工具开发或选择(系统需要)。、

4. 执行阶段

5. 评估阶段

6.5 面向对象的集成测试

6.5.1 对象交互

1. 汇集类测试

   1. 存放这些对象的引用(或指针)，程序中常表现为对象之间一对多的关系。

   2. 创建这些对象的实例。

   3. 删除这些对象的实例。

2. 协作类测试

6.5.2 面对对象集成测试的常用方法

1. 抽样测试

2. 正交阵列测试

6.5.3 分布式对象测试

1. 分布式对象的概念和特点

   1. 在类的层次上进行更彻底的测试。

   2. 在记录事件发生顺序的同时，执行大量的测试用例。

   3. 指定标准的测试环境。

2. 测试中需要注意的情况

   1. 局部故障

   2. 超时

   3. 结构的动态性

   4. 线程

   5. 同步

第七章 系统测试

7.1 性能测试

主要检验软件是否达到需求规格说明书中规定的各类性能指标，并满足一些性能相关的约束和限制条件。

1. 评估系统的能力

2. 识别系统中的弱点

3. 系统调优

7.1.1 性能测试方法

1. 响应时间

2. 并发用户数

3. 吞吐量

4. 性能计数器

7.1.2 性能测试执行

1. 计划阶段

   1. 定义目标并设置期望值

   2. 收集系统和测试要求

   3. 定义工作负载

   4. 选择要收集的性能度量值

   5. 标出要运行的测试并决定什么时候运行它们

   6. 决定工具选项和生成负载

   7. 编写测试计划，设计用户场景并创建测试脚本

2. 测试阶段

   1. 做准备工作(如建立测试服务器或布置其他设备)

   2. 运行测试

   3. 收集数据

3. 分析阶段

   1. 分析结果

   2. 改变系统以优化性能

   3. 设计新的测试

7.1.3 性能测试方案分析

1. 系统介绍

2. 测试目的

3. 测试工具的选择

4. 测试步骤

7.2 压力测试

1. 压力测试的特点

   1. 压力测试是检查系统处于压力情况下的能力表现

   2. 压力测试一般通过模拟方法进行

   3. 压力测试一般用于测试系统的稳定性

2. 压力测试和负载测试：负载测试是通过逐步增加系统工作量，测试系统能力的变化，并最终确定在满足功能指标的情况下，系统所能承受的最大工作量的测试。压力测试实质上就是–种特定类型的负载测试。

3. 压力测试和并发性测试：并发性测试是一种测试手段，在压力测试中可以利用并发测试来进行压力测试。

7.2.1 压力测试方法

1. 重复测试：重复测试就是一遍又一遍地执行某个操作或功能。

2. 并发测试：并发是同时执行多个操作的行为，即在同一时间执行多个测试线程。

3. 量级增加：压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。

4. 随机变化：对上述测试手段进行随机组合，以便获得最佳的测试效果。

7.2.2 压力测试执行

1. 输人待处理事务来检查是否有足够的磁盘空间。

2. 创造极端的网络负载。

3. 制造系统溢出条件。

7.3 容量测试

容量测试是指采用特定的手段，测试系统能够承载处理任务的极限值所从事的测试工作。

7.3.1 容量测试方法

7.3.2 容量测试执行

1. 测试步骤

   1. 分析系统的外部数据源，并进行分类。

   2. 对每类数据源分析可能的容量限制，对于记录类型数据需要分析记录长度限制，记录中每个域长度限制和记录数量限制。

   3. 对每个类型数据源，构造大容量数据对系统进行测试。

   4. 分析测试结果，并与期望值比较，确定目前系统的容量瓶颈。

   5. 对系统进行优化并重复以上四步，直到系统达到期望的容量处理能力。

2. 常见的容量测试用例子包括

   1. 处理数据敏感操作时进行的相关数据比较。

   2. 使用编译器编译一个极其庞大的源程序。

   3. 使用一个链接编辑器编辑一个包含成千，上万模块的程序。

   4. 一个电路模拟器模拟包含成千，上万块的电路。

   5. 一个操作系统的任务队列被充满。

   6. 一个测试形式的系统被输人大量文档。

   7. 互联网中庞大的E-mail信息和文件信息。

7.3.3 容量测试案例分析

1. 按用例中测试环境的描述建立测试系统

2. 准备测试过程，合理地组织用例的测试流程

3. 根据用例中“初始化”内容运行初始化过程

4. 执行测试，从终止的测试恢复

5. 验证预期结果，对应测试用例中描述的测试目的

6. 调查突发结果，即对异常现象进行研究，适当地进行一些回归测试

7. 记录问题报告。

7.4 健壮性测试

健壮性测试主要用于测试系统抵御错误的能力。

7.4.1 健壮性测试评价

1. 健壮性测试可以根据以下方面评价系统的健壮性

   1. 通过：系统调用运行输入的参数产生预期的正常结果。

   2. 灾难性失效：这是系统健壮性测试中最严重的失效，这种失效只有通过系统重新引导才能得到解决。

   3. 重启失效：一个系统函数的调用没有返回，使得调用它的程序挂起或停止。

   4. 夭折失效：程序执行时由于异常输人，系统发出错误提示使程序中止。

   5. 沉寂失效：异常输人时，系统应当发出错误提示，但是测试结果却没有发生异常。

   6. 干扰失效：指系统异常时返回了错误的提示，但是该错误提示不是期望中的错误。

2. 自动化实现上述测试内容时需要把握以下特性和原则

   1. 可移植性：健壮性测试基准程序是用来比较不同系统的健壮性，因此移植性是测试基准程序的基本要求。

   2. 覆盖率：理想的基准程序能够覆盖所有的系统模块，然而这种开销是巨大的。因此一般选取使用频度最高的模块进行测试。

   3. 可扩展性：可扩展性体现在当需要扩展测试集时能够前后一致。这种可扩展性不仅指为已有模块增加测试集，还包括为新增加的模块增加测试集。

   4. 测试结果的记录：健壮性测试的目的是找出系统的不健壮性因素，因此应详细的记录测试结果。

3. 设计健壮性测试时可以从以下几个方面考虑

   1. 基于错误的策略：确认所有可能的错误源，为每一类错误开发错误注入技术

   2. 基于覆盖率的策略：接口覆盖的数量，故障位置覆盖的数量，例外覆盖的数量

   3. 基于失效的策略：用例设计是否被处理了，例外是否被处理了，一个组件中的失效是否影响另一个组件

7.4.2 健壮性测试案例分析

7.5 安全性测试

1. 安全性测试的概念：检查系统对非法侵人的防范能力,其目的是为了发现软件系统中是否存在安全漏洞。

2. 程序级的安全性和系统级别的安全性的关系

   1. 应用程序级别的安全性包括对数据或业务功能的访问；而系统级别的安全性包括对系统的登录或远程访问。

   2. 应用程序级别的安全性可确保在预期的安全性情况下，操作者只能访问特定的功能或用例，或者只能访问有限的数据。

   3. 系统级别的安全性对确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的人口来访问。

7.5.1 安全性测试方法

1. 测试方法概述

   1. 功能验证：功能验证是采用软件测试当中的黑盒测试方法，对涉及安全的软件功能，如用户管理模块、权限管理模块、加密系统、认证系统等进行测试，主要是验证上述功能是否有效。

   2. 漏洞扫描：安全漏洞扫描通常都是借助于特定的漏洞扫描器完成。漏洞扫描器是一种能自动检测远程或本地主机安全性弱点的程序，通过使用漏洞扫描器，系统管理员能够发现所维护信息系统存在的安全漏洞，从而在信息系统网络安全防护过程中做到有的放矢，及时修补漏洞。

   3. 模拟攻击试验

      1. 冒充：就是一个实体假装成另外一个不同的实体。

         1. 口令猜测

         2. 缓冲区溢出

      2. 重演：当一个消息或部分消息为了产生非授权效果而被重复时，就出现了重演。

      3. 消息篡改

         1. DNS高速缓存污染

         2. 伪造电子邮件

      4. 服务拒绝：当一个实体不能执行它的正常功能，或它的动作妨碍了别的实体执行它们的正常功能的时候，便发生服务拒绝。

         1. 死亡之Ping

         2. 泪滴

         3. UDP洪水

         4. SYN洪水

         5. Land攻击

         6. Smurf攻击

         7. Fraggle攻击

         8. 电子邮件炸弹

         9. 畸形消息攻击

      5. 内部攻击：当系统的合法用户以非故意或非授权方式进行动作时就成为内部攻击。

      6. 外部攻击：外部攻击可以使用的办法有:搭线(主动的与被动的)、截取辐射、冒充为系统的授权用户，冒充为系统的组成部分、为鉴别或访问控制机制设置旁路等。

      7. 陷阱门：当系统的实体受到改变，致使一个攻击者能对命令或对预定的事件或事件序列产生非授权的影响时，其结果就称为陷阱门。

      8. 特洛伊木马：对系统而言的特洛伊木马，是指它不但具有自己的授权功能，而且还有非授权功能。

   4. 侦听技术：侦听技术实际上是在数据通信或数据交互过程中，对数据进行截取分析的过程。

2. 确定安全性标准

   1. 安全目标

      1. 预防

      2. 跟踪审计

      3. 监控

      4. 保密性和机密性

      5. 匿名性

      6. 数据的完整性

   2. 安全的原则

      1. 加固最脆弱的连接

      2. 实行深度防护

      3. 失败安全

      4. 最先优先权

      5. 分割

      6. 简单化

      7. 保密性

   3. 缓冲区溢出

   4. 密码学的应用

   5. 信任管理和输入的有效性

   6. 口令认证

   7. 客户端安全性

   8. 安全控制/构架

3. 安全性评价模型

   1. 贝叶斯模型

   2. 3M评价模型

4. 安全性测试执行

   1. 危险和威胁分析

   2. 以一种它们可以和系统的安全性动作相比较的方式来定义安全性需求和划分优先级

   3. 模拟安全行为

   4. 执行安全性测试

   5. 估计基于证据的安全活动的可能性和影响

7.5.2 安全性测试案例分析

1. 风险和威胁分析

2. 测试环境

3. IPv6防火墙测试

7.6 可靠性测试

图7-6-1-1 软件可靠性测试流程

7.6.1 可靠性测试的基本概念

1. 软件可靠性测试过程

2. 描述软件可靠性的基本参数

   1. 故障率（风险函数）

1. 维修率
   

2. 平均无故障时间
   

3. 平均维护时间
   

4. 有效度
   

5. 残留的缺陷数目N0

6. 可靠性

1. 测试剖面和使用剖面之间的关系

假设Test(D)是测试时的运行剖面，User(D)是用户使用时的运行剖面。

1. Test(D)=User(D)

   1. fTest(D)≠fUser(D)

7.6.2 软件的运行剖面

1. 运行剖面的概念及意义

设D是软件S的定义域，D={d1，d2，…，dn}，P(di)是di的发生的概率，则运行剖面被定义为：{(d1,P(d1)),(d2,P(d2))，…，(dn,P(dn))}。

1. 获取运行剖面的步骤

   1. 客户剖面：所谓客户是指用同一种方式使用系统的一组用户。

   2. 用户剖面：用户剖面是关于用户及其用户发生概率的集合。

   3. 系统模式剖面：系统模式是为便于管理系统或分析执行行为，分组而成的–个功能或操作的集合。

   4. 功能剖面：将每种模式进一步分解为其对应的功能，并确定每个功能发生的概率，就构成了功能剖面。

   5. 运行剖面：系统的具体实现功能及其对应的发生概率的集合称为运行剖面。

2. 获取运行剖面的一般描述

7.6.3 可靠性测试案例分析

1. 运行剖面的构造及测试用例生成

2. 测试运行及数据收集

3. 可靠性数据分析

7.7 恢复性测试与备份测试

恢复性测试主要检查系统的容错能力。

1. 备份文件，并且比较备份文件与最初的文件的区别。

2. 存储文件和数据。

3. 完善系统备份工作的步骤。

4. 检查点数据备份。

5. 备份引起系统性能衰减程度。

6. 手工备份的有效性。

7. 系统备份“触发器”的检测。

8. 备份期间的安全性。

9. 备份过程日志。

7.8 协议一致性测试

7.8.1 协议一致性测试基本概念

协议测试是在软件测试的基础上发展起来的。根据对被测软件的控制观察方式，软件测试方法分为三种：白盒测试、黑盒测试和灰盒测试。协议测试是一种黑盒测试，它按照协议标准，通过控制观察被测协议实现的外部行为对其进行评价。

7.8.2 协议一致性测试方法

1. 协议一致性测试基本框架

7-8-2-1 一致性测试体系结构

2. 协议一致性测试标准

3. 协议已执行测试执行

   1. 声明行与声明

      1. 事件：声明是否成立，取决于当前所发生的事件

      2. 行动：有时声明总是成立的，也就是说它是可执行的，这种声明称为活动

      3. 条件：声明行也可以包括条件声明，即布尔表达式，这个声明行称为条件声明行

      4. 事件、行动和条件的结合：事件、行动和条件组合可以通过TTCN-MP来定义。

   2. 执行和匹配

      1. 替换：在同一缩排的声明行的集合中，有相同父节点的节点称为可替换声明行。

      2. 行为树的执行：行为树的执行从树根开始。

7.9 兼容性测试

兼容性测试是指检查软件之间是否能够正确地进行交互和共享信息。

7.10 安装测试

7.11 可用性测试

7.11.1 可用性测试的概念

可用性测试是对于用户友好性的测试，是指在设计过程中被用来改善易用性的一系列方法。

1. 可用性测试会包含以下维度

   1. 任务操作的成功率。

   2. 任务操作效率。

   3. 任务操作前的用户期待

   4. 任务操作后的用户评价。

   5. 用户满意度。

   6. 各任务出错率。

   7. 二次操作成功率。

2. 可用性测试的文档主要包括以下内容

   1. 日程安排文档。

   2. 用户背景资料文档。

   3. 用户协议。

   4. 测试脚本。

   5. 测试前问卷。

   6. 测试后问卷。

   7. 任务卡片。

   8. 测试过程检查文档。

   9. 过程记录文档。

   10. 测试报告。

   11. 影音资料。

7.11.2 可用性测试方法

1. 一对一用户测试：一个可用性测试部分包括测试人员(主持人1助理)和一个目标用户，这个目标用户会在测试人员的陪同下完成一系列的典型任务。

2. 启发式评估：邀请5~8名用户作为评估人员来评价产品使用中的人机交互状况，发现问题，并根据可用性设计原则提出改进方案。

3. 焦点小组：焦点小组是依据群体动力学原理由6~12个参试人组成的富有创造力的小群体，在一名专业主持人的引导下对某一主题或观念进行深入讨论，主持人要在不限制用户自由发表观点和评论的前提下，保持谈论的内容不偏离主题。

7.12 配置测试

7.12.1 配置测试的概念

配置测试是验证系统在不同的系统配置下能否正确工作，这些配置包括：软件、硬件和网络等。

7.12.2 配置测试方法

1. 分离配置缺陷

2. 计算机配置测试工作量

7.13 文档测试

7.13.1 文档测试的概念

文档测试主要针对系统提交给用户的文档进行验证，目标是验证软件文档是否正确记录系统的开发全过程的技术细节。

1. 用户文档测试内容

2. 开发文档测试内容

7.13.2 文档测试方法

1. 文档走查

2. 数据校对

3. 操作流程检查

4. 引用测试

5. 链接测试

6. 可用性测试

7. 界面截图测试

7.14 GUI测试

7.14.1 GUI测试的概念及方法

1. GUI的手工测试

2. GUI的自动化测试

   1. 记录回放

   2. 测试用例自动化

   3. 自动测试

7.14.2 GUI测试案例分析

7.15 回归测试

7.15.1 回归测试的概念

回归测试是在软件发生变动时保证原有功能正常运作的一种测试策略和方法。

7.15.2 回归测试方法

1. 测试用例库的维护

2. 回归测试包的选择

3. 回归测试的基本过程

   1. 识别出软件中被修改的部分。

   2. 从原基线测试用例库T中排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。

   3. 依据一定的策略从T0中选择测试用例测试被修改的软件。

   4. 生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。

   5. 用T1执行修改后的软件。

7.16 系统测试工具及其应用

7.16.1 LoadRunner

1. 录制脚本

2. 生成测试场景

3. 查看测试结果

7.16.2 TTworkbench

7.16.3 QACenter

7.16.4 DataFactory

7.16.5 JMeter

1. 运行预准备

2. 运行

第八章 主流信息应用系统测试

8.1 Web应用系统测试

8.1.1 Web系统基本组成

1. 访问客户端：包含用户操作的浏览器及运行平台。

2. Web应用服务器：用于发布Web页面，接受来自客户端的请求，并把请求的处理结果返回客户端。

3. 数据库：虽然数据库不是Web系统的必要部分，但在现有的大多数Web系统中，数据库是重要的部分。

4. 网络及中间件：提供客户端的请求到Web服务器的通道。

5. 防火墙与CA认证：保障系统安全性的一个系统，对于重要的系统也必不可少。

8.1.2 Web应用系统测试综述

8.1.3 Web应用系统测试的实施

1. 功能测试

   1. 链接测试：链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。

   2. 表单测试：测试提交操作的完整性，以校验提交给服务器的信息的正确性。

   3. Cookie测试：Cookie通常用来存储用户信息和用户在某应用系统的操作。

   4. 应用程序特定的功能需求：除了以上基本的功能测试外，测试人员仍需要对应用程序特定的功能需求进行验证。

2. 性能测试

   1. 连接速度测试：用户连接到Web应用系统的速度根据上网方式的变化而变化。

   2. 负载测试：负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。

   3. 压力测试：压力测试是指实际破坏一个Web应用系统时测试系统的反应。

3. 可用性测试

   1. 导航测试：导航描述了用户在一个页面内操作的方式，在不同的用户界面控件之间进行操作，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间进行操作。

   2. 图形测试：在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。

   3. 内容测试：内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

   4. 表格测试：表格测试需要验证表格是否设置正确。

   5. 整体界面测试：整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。

4. 客户端兼容性测试

   1. 平台测试：Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。

   2. 浏览器测试

   3. 分辨率测试

   4. 打印测试

   5. 组合测试

5. 安全性测试

6. 接口测试

   1. 服务器接口：第一个需要测试的接口是浏览器与服务器的接口。

   2. 外部接口：有些Web系统有外部接口。

   3. 错误处理：最容易被测试人员忽略的地方是接口错误处理。

7. 故障恢复测试

   1. 客户端/服务器断电。

   2. 网络通信中断。

   3. 异常关闭某个功能。

   4. 错误的操作顺序。

8.2 数据库测试

8.2.1 数据库测试概述

8.2.2 数据库功能性测试

1. 功能测试内容

   1. 安装与配置

   2. 数据库存储管理

   3. 模式对象管理

      1. 标管理

      2. 索引管理

      3. 视图管理

      4. 约束管理

      5. 存储过程管理

      6. 触发器管理

   4. 非模式对象管理

   5. 交互式查询工具

   6. 性能检测与调优

   7. 数据迁移工具

   8. 作业管理

2. 测试方法

采用黑盒测试方法，可以通过图形化管理工具、交互式SQL工具等对数据库管理系统的功能特性进行测试。

8.2.3 数据库性能测试与原因分析

1. 数据库性能测试

   1. 数据库的设计

   2. SQL语句

2. 数据库性能问题及原因分析

   1. 单类型事务响应时间过长

   2. 并发能力差

   3. 锁冲突严重

   4. 性能瓶颈的处理方法

8.2.4 数据库可靠性及安全性测试

1. 可靠性测试

   1. 数据库备份

   2. 故障恢复

   3. 运行稳定性

2. 安全性测试

   1. 用户及口令管理

   2. 授权和审计管理

8.3 嵌入式系统测试

图8-3-1-1 嵌入式系统的基本结构

嵌入式系统由嵌入式硬件与嵌入式软件组成。硬件以芯片、模板、组件、控制器形式嵌入到设备内部，软件是实时多任务OS和各种专用软件，一般固化在ROM或闪存中。

8.3.1 嵌入式软件测试策略及测试流程

1. 嵌入式软件测试问题及测试方法

2. 嵌入式软件测试的一般流程

   1. 使用测试工具的插装功能(主机环境)执行静态测试分析并且为动态覆盖测试准备好已插装的软件代码。

   2. 使用源码在主机环境下执行功能测试，修正软件的错误和测试脚本中的错误。

   3. 使用插装后的软件代码执行覆盖率测试，添加测试用例或修正软件的错误，保证达到所要求的覆盖率目标。

   4. 在目标环境下重复步骤2)，确认软件在目标环境中执行测试的正确性。

   5. 若测试需要达到极端的完整性，最好在目标系统上重复步骤3),确定软件的覆盖率没有改变。

8.3.2 嵌入式软件测试代表工具

1. 嵌入式白盒测试工具

2. 嵌入式黑盒测试工具

3. 嵌入式灰盒测试工具

4. 嵌入式软件仿真工具

8.4 游戏测试

8.4.1 游戏开发与测试过程

1. 游戏测试与开发的关系

2. 游戏与通用软件的开发有何区别

   1. 通用软件的需求明确，游戏软件的需求理想化。

   2. 通用软件开发过程中需求变更少，游戏软件开发过程中需求变化快。

   3. 开发过程的阶段不同。

8.4.2 游戏测试主要内容

8.4.3 游戏测试的实施

1. 游戏策划与测试计划

   1. 游戏程序本身的测试计划。

   2. 游戏可玩性测试计划。

   3. 关于性能测试的计划。

2. 游戏性能测试

   1. C/S架构的网络游戏

   2. B/S架构的网络游戏

   3. WAP网络游戏

8.5 移动应用软件测试

8.5.1 移动应用测试的困难

1. 手机/终端配置测试实验室

2. 安全问题严重

3. 专业测试队伍

4. 管理难度加大

8.5.2 测试类型

1. 冒烟测试

2. 图形用户界面屙屎

3. 安全性测试

4. 性能测试

5. 兼容性测试

6. 网络测试

7. 本地化测试

8.5.3移动应用测试工具

1. Monkey

2. Instrumentation

8.6 云应用软件测试

8.6.1 云测试基本概念

8.6.2 云测试方法和技术

1. 云环境中的测试和针对“云”的测试

   1. 在云环境中的测试

   2. 针对“云”的测试

      1. 功能测试

      2. 性能测试

      3. 可用性和恢复性测试

      4. 安全测试

      5. 兼容性和互操作性测试

   3. 迁移测试到“云”中

8.6.3 云测试现状及挑战

1. 云测试的现状

   1. 测试人员利用云测试服务商提供的测试环境，运行自己的测试用例。

   2. 云测试服务商为测试人员提供测试执行的服务。

   3. 测试中需要使用软件工具或测试运行于不同测试环境。

2. 云测试的挑战

   1. 数据安全

   2. 集成问题

   3. 多用户租赁

   4. 服务保障

   5. 并发问题

   6. 兼容和交互性

   7. 虚拟化问题

第九章 软件评审

9.1 软件评审概述

1. 评审阶段的划分

   1. 系统分析与设计

   2. 软件需求分析。

   3. 软件概要设计。

   4. 软件详细设计。

   5. 编码和单元测试。

   6. 软件部件测试。

   7. 软件配置项测试。

   8. 软件系统测试。

   9. 系统验收。

2. 内部评审

   1. 软件开发的各个阶段都必须进行内部评审。

   2. 项目承办方的质量管理人员负责组织内部评审。

   3. 内部评审要成立评审组，承办方依据项目的具体情况，自行确定内部评审组的成员，一般情况下，评审组成员由具备相关背景知识、了解项目情况的同行专家、代表组成。

   4. 评审组一般由五人以上组成。

3. 外部评审

   1. 提出评审申请

   2. 成立评审委员会

   3. 提交被评审的工作产品

   4. 预先审查

   5. 评审会议

   6. 评审结论

   7. 对评审结论的处理

9.2 需求评审

1. 需求评审概述

   1. 需求报告很长，短时间内评审者根本不可能把需求报告读懂，想清楚。

   2. 没有做好前期准备工作，需求评审的效率很低。

   3. 需求评审的节奏无法控制。

   4. 找不到合格的评审员，与会的评审员无法提出深入的问题。

2. 如何做好需求评审

   1. 分层次评审

      1. 目标性需求：定义了整个系统需要达到的目标。

      2. 功能性需求：定义了整个系统必须完成的任务。

      3. 操作性需求：定义了完成每个任务的具体的人机交互。

   2. 正式评审与非正式评审结合

   3. 分阶段评审

   4. 精心挑选评审员

   5. 对评审员进行培训

   6. 充分利用需求评审检查单

   7. 建立标准的评审流程

   8. 做好评审后的跟踪工作

   9. 充分准备评审

3. “软件需求规格说明”评审细则

9.3 概要设计评审

1. 概要设计评审概述

   1. 概要设计说明书是否与软件需求说明书的要求-致。

   2. 概要设计说明书是否正确、完整、一致。

   3. 系统的模块划分是否合理。

   4. 接口定义是否明确。

   5. 文档是否符合有关标准规定。

2. “概要设计说明”评审细则

9.4 详细设计评审

1. 详细设计评审概述

   1. 详细设计说明书是否与概要设计说明书的要求一致。

   2. 模块内部逻辑结构是否合理，模块之间的接口是否清晰。

   3. 数据库设计说明书是否完全，是否正确反映详细设计说明书的要求。

   4. 测试是否全面、合理。

   5. 文档是否符合有关标准规定。

2. “详细设计说明”评审细则

9.5 数据库设计评审

1. 数据库设计评审概述

   1. 概念结构设计。

   2. 逻辑结构设计。

   3. 物理结构设计。

   4. 数据字典设计。

   5. 安全保密设计。

2. “数据库设计说明”评审细则

9.6 测试评审

1. “软件测试需求规格说明”评审细则

2. “软件测试计划”评审细则

3. “软件测试说明”评审细则

4. “软件测试报告”评审细则

5. “软件测试记录”评审细则

第十章 测试管理

10.1 建立测试管理体系

1. 测试计划：确定各测试阶段的目标和策略。

2. 测试设计：根据测试计划设计测试方案。

3. 测试实施：使用测试用例运行程序，将获得的运行结果与预期结果进行比较和分析，记录、跟踪和管理软件故障，最终得到测试报告。

4. 配置管理：测试配置管理是软件配置管理的子集，作用于测试的各个阶段。

5. 资源管理：包括对人力资源和工作场所，以及相关设施和技术支持的管理。

6. 测试管理

10.2 测试稿管理的基本内容

10.2.1 测试组织管理

1. 组织和管理测试小组

2. 确定测试小组的组织模式

3. 安排测试任务

4. 估计测试工作量

5. 确定应交付的测试文档

6. 管理测试件

7. 确定测试需求

8. 组织测试设计

10.2.2 测试过程管理

1. 测试准备

2. 测试计划阶段

   1. 目的

   2. 完成测试的标准

   3. 测试策略

   4. 资源配置

   5. 责任明确

   6. 进度安排

   7. 风险

   8. 组装方式

   9. 工具

3. 测试设计阶段

4. 测试执行阶段

5. 测试结果分析

10.2.3 资源和配置管理

1. 资源管理

2. 设备管理

   1. 配置标识

   2. 配置控制

   3. 配置状态发布

   4. 配置评审

10.2.4 测试文档管理

1. 测试文档的类型

   1. 是计划

   2. 测试设计规格说明

   3. 测试用例规格说明

   4. 测试步骤规格水命

   5. 测试日志

   6. 测试实践报告

   7. 测试总结报告

2. 测试文档的管理

   1. 文档的分类管理。

   2. 文档的格式和模板管理。

   3. 文档的一致性管理。

   4. 文档的存储管理。

10.3 测试管理的原则

1. 尽早测试

2. 全面测试

3. 全过程测试

4. 迭代测试

10.4测试管理实践

1. 策划测试过程

2. 需求分析

3. 更变控制

4. 度量与分析

5. 测试过程可持续改进

10.5 常用的测试管理工具

10.5.1 TestDirector测试管理工具

1. 需求管理

2. 测试计划管理

3. 测试执行管理

4. 缺陷管理

10.5.2 JIRA介绍

1. JIRA的用户管理

   1. 管理人员

   2. 项目管理者

   3. 开发人员

   4. 测试人员

2. JIRA的问题管理

   1. 问题类型

   2. 优先级

   3. 状态

   4. 解决

10.5.3 国外其他测试管理工具

1. Rational公司的TestManager

2. Compuware公司的QA Director

3. RAIDS和Test Studio

10.5.4 国产测试管理工具KTFlow

1. 测试需求管理

2. 测试计划管理

3. 测试用例管理

4. 测试执行管理

5. 测试总结管理

6. 回归测试管理

7. 测试项目数据库管理

8. 测试人员协同工作

   5. 编码和单元测试。

   6. 软件部件测试。

   7. 软件配置项测试。

   8. 软件系统测试。

   9. 系统验收。

9. 内部评审

   1. 软件开发的各个阶段都必须进行内部评审。

   2. 项目承办方的质量管理人员负责组织内部评审。

   3. 内部评审要成立评审组，承办方依据项目的具体情况，自行确定内部评审组的成员，一般情况下，评审组成员由具备相关背景知识、了解项目情况的同行专家、代表组成。

   4. 评审组一般由五人以上组成。

10. 外部评审

    1. 提出评审申请

    2. 成立评审委员会

    3. 提交被评审的工作产品

    4. 预先审查

    5. 评审会议

    6. 评审结论

    7. 对评审结论的处理

9.2 需求评审

1. 需求评审概述

   1. 需求报告很长，短时间内评审者根本不可能把需求报告读懂，想清楚。

   2. 没有做好前期准备工作，需求评审的效率很低。

   3. 需求评审的节奏无法控制。

   4. 找不到合格的评审员，与会的评审员无法提出深入的问题。

2. 如何做好需求评审

   1. 分层次评审

      1. 目标性需求：定义了整个系统需要达到的目标。

      2. 功能性需求：定义了整个系统必须完成的任务。

      3. 操作性需求：定义了完成每个任务的具体的人机交互。

   2. 正式评审与非正式评审结合

   3. 分阶段评审

   4. 精心挑选评审员

   5. 对评审员进行培训

   6. 充分利用需求评审检查单

   7. 建立标准的评审流程

   8. 做好评审后的跟踪工作

   9. 充分准备评审

3. “软件需求规格说明”评审细则

9.3 概要设计评审

1. 概要设计评审概述

   1. 概要设计说明书是否与软件需求说明书的要求-致。

   2. 概要设计说明书是否正确、完整、一致。

   3. 系统的模块划分是否合理。

   4. 接口定义是否明确。

   5. 文档是否符合有关标准规定。

2. “概要设计说明”评审细则

9.4 详细设计评审

1. 详细设计评审概述

   1. 详细设计说明书是否与概要设计说明书的要求一致。

   2. 模块内部逻辑结构是否合理，模块之间的接口是否清晰。

   3. 数据库设计说明书是否完全，是否正确反映详细设计说明书的要求。

   4. 测试是否全面、合理。

   5. 文档是否符合有关标准规定。

2. “详细设计说明”评审细则

9.5 数据库设计评审

1. 数据库设计评审概述

   1. 概念结构设计。

   2. 逻辑结构设计。

   3. 物理结构设计。

   4. 数据字典设计。

   5. 安全保密设计。

2. “数据库设计说明”评审细则

9.6 测试评审

1. “软件测试需求规格说明”评审细则

2. “软件测试计划”评审细则

3. “软件测试说明”评审细则

4. “软件测试报告”评审细则

5. “软件测试记录”评审细则

第十章 测试管理

10.1 建立测试管理体系

1. 测试计划：确定各测试阶段的目标和策略。

2. 测试设计：根据测试计划设计测试方案。

3. 测试实施：使用测试用例运行程序，将获得的运行结果与预期结果进行比较和分析，记录、跟踪和管理软件故障，最终得到测试报告。

4. 配置管理：测试配置管理是软件配置管理的子集，作用于测试的各个阶段。

5. 资源管理：包括对人力资源和工作场所，以及相关设施和技术支持的管理。

6. 测试管理

10.2 测试稿管理的基本内容

10.2.1 测试组织管理

1. 组织和管理测试小组

2. 确定测试小组的组织模式

3. 安排测试任务

4. 估计测试工作量

5. 确定应交付的测试文档

6. 管理测试件

7. 确定测试需求

8. 组织测试设计

10.2.2 测试过程管理

1. 测试准备

2. 测试计划阶段

   1. 目的

   2. 完成测试的标准

   3. 测试策略

   4. 资源配置

   5. 责任明确

   6. 进度安排

   7. 风险

   8. 组装方式

   9. 工具

3. 测试设计阶段

4. 测试执行阶段

5. 测试结果分析

10.2.3 资源和配置管理

1. 资源管理

2. 设备管理

   1. 配置标识

   2. 配置控制

   3. 配置状态发布

   4. 配置评审

10.2.4 测试文档管理

1. 测试文档的类型

   1. 是计划

   2. 测试设计规格说明

   3. 测试用例规格说明

   4. 测试步骤规格水命

   5. 测试日志

   6. 测试实践报告

   7. 测试总结报告

2. 测试文档的管理

   1. 文档的分类管理。

   2. 文档的格式和模板管理。

   3. 文档的一致性管理。

   4. 文档的存储管理。

10.3 测试管理的原则

1. 尽早测试

2. 全面测试

3. 全过程测试

4. 迭代测试

10.4测试管理实践

1. 策划测试过程

2. 需求分析

3. 更变控制

4. 度量与分析

5. 测试过程可持续改进

10.5 常用的测试管理工具

10.5.1 TestDirector测试管理工具

1. 需求管理

2. 测试计划管理

3. 测试执行管理

4. 缺陷管理

10.5.2 JIRA介绍

1. JIRA的用户管理

   1. 管理人员

   2. 项目管理者

   3. 开发人员

   4. 测试人员

2. JIRA的问题管理

   1. 问题类型

   2. 优先级

   3. 状态

   4. 解决

10.5.3 国外其他测试管理工具

1. Rational公司的TestManager

2. Compuware公司的QA Director

3. RAIDS和Test Studio

10.5.4 国产测试管理工具KTFlow

1. 测试需求管理

2. 测试计划管理

3. 测试用例管理

4. 测试执行管理

5. 测试总结管理

6. 回归测试管理

7. 测试项目数据库管理

8. 测试人员协同工作