参考书籍

软件测试技术基础教程

软件测试概述

第一类测试：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug

第一类测试方法以需求和设计为本

第二类测试：强调测试人员发挥主观能动性，用逆向思维方式，不断思考开发人员理解的误区、不良习惯、程序代码的边界、无效数据的输入及系统的各种弱点，试图破坏系统、摧毁系统，目标是发现系统中各种各样的问题

测试是以评价一个程序或系统属性为目标的任何一种活动。测试是对软件质量的度量

对于软件缺陷的定义：

1. 软件未达到产品说明书要求的功能
2. 软件出现了产品说明书指明不会出现的错误
3. 软件功能超出了产品说明书规定的功能
4. 软件未实现产品说明书虽未明确指出胆应该实现的目标

软件测试的充分性准则：

1. 对任何软件都存在有限的充分测试集合
2. 软件测试的单调性 ：当一个测试的数据集合对于一个被测的软件系统的测试是充分的，那么再多增加一些测试数据任然是充分的
3. 软件测试的非复合性 ：即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分
4. 软件测试的非分解性 ：即使对一个软件的系统整体的测试是充分的，也并不意味着这个软件系统各个成分都已经充分地的得到了测试
5. 软件测试的复杂性 ：软件测试的数据量正比于软件的复杂度
6. 软件测试的充分性与软件的需求、软件的实现相关
7. 软件测试具有回报递减性，即随着测试次数的增加，检查出软件缺陷的概率不断减少

软件测试基础

软件测试的目的

• 测试时程序的执行过程，目的在于发现错误
• 一个好的测试用例在于可以发现还未曾发现的错误
• 一个成功的测试是发现了至今还没有发现的错误

软件测试的原则

• 尽早开始测试
• 测试用例包括测试输入数据和与之对应的预期输出结果
• 避免检查自己的程序
• 设计测试用例时，包括合理的输入条件和不合理的输入条件

软件测试的分类

按照软件测试的生命周期分类

• 单元测试

目的：检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等

• 集成测试

目的：用于检验程序单元或部件的接口关系，使其符合概要设计

• 确认测试

目的：检验软件的功能、性能及其他特性是否与用户的要求一致

• 系统测试

目的：通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方

可以分为三个阶段

* 模块测试 测试模块程序
* 组装测试 测试模块之间的接口
* 确认测试 测试整个软件系统

• 验收测试

目的：用户对软件系统进行测试和接收

按照软件测试技术分类

• 白盒测试

通过对程序内部结构的分析、检测来发现系统代码中存在的问题

常用的测试方法：

* 静态测试 不执行
* 动态测试 需要执行

• 黑盒测试

在不考虑程序内部结构的情况下，检查程序的功能是否按照需求规格说明书的规定

常用的测试方法：

* 等价类划分
* 边界值分析法
* 错误推断法
* 因果图法

• 灰盒测试

关注输出对于输入的正确性，同时也关注内部表现，通过表征性的现象、实践、标志来判断内部的运行状态

按照软件测试实施主体分类

1. 开发方测试(验证测试)

在软件开发环境下，由开发者通过检测和提供客观证据，证实软件的实现能否满足规定的需求

1. 用户测试(Beta测试)

用户在真实的应用环境下，通过运行和使用软件，检测与核查软件是否符合自己预期的要求

1. 第三方测试(独立测试)

软件第三方测试是由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试

按照测试内容分类

• 功能性测试

考察方面：

1. 适合性：是否提供了满足需求的功能，以及系统所提供的功能对需求的适合程度的测试工作
2. 准确性：检验系统处理数据是否准确，以及处理数据的精度是否符合需求
3. 互操作性：检查系统的相关功能与其他特定系统之间交互能力
4. 安全性：检验系统的安全性，防止对系统及数据非授权的故意或意外访问等
5. 功能的依从性：检验软件产品的功能是否遵循有关的标准、约定、法规等

• 可靠性测试

  1. 成熟性测试：检验软件系统故障导致失效的可能程度的测试
  2. 容错性测试：检验软件系统在出现故障或违反指定接口的情况下，是否能维持规定的性能水平
  3. 易恢复性测试：检验软件失效后，重建其直接受影响的数据，以及为达此目的所需的实践和相关工作

• 易用性测试

  1. 易理解性测试：主要检查用户为认识系统的逻辑概念及系统的应用
  2. 易学习性测试：主要检查用户为学习软件的输入、输出、计算、控制等应用所实施的相关工作
  3. 易操作性测试：检查系统中用户为操作和运行控制所付出努力有关

• 效率测试

  1. 时间特性测试：主要考查系统的执行效率
  2. 资源利用性测试：检测系统的设备效率与网络效率

• 可移植性测试

  1. 适应性测试：检测系统软件无需特殊准备就可适应不同的规定环境的软件测试工作
  2. 易安装性测试：检测软件系统在指定环境下的安装中所需的相关工作
  3. 共存性测试：检验软件系统与指定的其他软件共存于指定环境下的软件属性
  4. 易替换性测试：检验软件系统在该软件环境中用于替代指定的其他软件的机会

• 文档测试

  1. 文档完整性：检查开发文档、管理文档等相关文档是否按照实际系统的全部功能提供了相关信息说明
  2. 文档正确性：检查开发文档、管理文档等想相关文档的描述信息是否与实际系统的全部功能一一对应
  3. 文档一致性：考察文档与文档的一致性、文档与系统的一致性两部分
  4. 文档易理解性

软件质量保证的工作内容

1. 参与制定软件质量要求
2. 组织正式评审
3. 软件测试管理
4. 对软件的变更进行控制
5. 对软件质量进行度量
6. 对软件质量情况及时记录和报告

软件开发各阶段SQA(软件质量保证)的目标

1. 需求分析阶段
   • 确保客户所需求的系统是可行的
   • 确保客户指定的需求确实能够满足真正的要求
   • 避免开发者与客户之间的误解
2. 软件规格说明书编制阶段
   • 确保规格说明书与系统需求保持一致
   • 建立测试策略
   • 建立现实的开发进度表
   • 设计正式的变更流程
3. 软件设计阶段
   • 建立用于描述设计的标准
   • 适当地控制并用文档记录对设计进行的变更
4. 编码阶段
   • 遵循已建立的风格、结构和文档标准
   • 确保代码经过适当测试和集成
   • 代码编写遵循进度
5. 测试阶段
   • 确保测试计划的建立和遵循
6. 维护阶段
   • 代码和文档的一致性
   • 对已建立的变更控制过程进行监测

ISO 9000系列标准是ISO组织制定的国际标准

核心标准是质量保证标准ISO 9001 ~ ISO 9003和质量管理标准ISO 9004

ISO 9001 ~ ISO 9003作为第一类用于建立客户对生产商质量要求保证

ISO 9004作为第二类用于生产商自身建立质量保障体系

ISO 9000系列标准的两个主要特点：

• 目标在于整个产品流程的控制
• 产品缺陷提早预防

CMM(能力成熟度模型)是软件行业的标准模型，用来定义和评价软件公司开发过程的成熟度，以通用性好作为特点

CMM将软件过程能力成熟度划分为五个等级

1. 等级1(初始级)

开发过程是随意的、混乱的

1. 等级2(可重复级)

成熟度主要集中在项目级。建立基本的项目管理过程。软件开发具有一定的组织性

1. 等级3(已定义级)

具备了组织化，不仅仅针对具体项目。软件开发中的管理活动和工程活动被文档化或标准化。所有项目均在标准软件过程中进行

1. 等级4(已管理级)

软件过程和产品质量有具体的度量标准，软件过程和产品质量等到了定量理解和控制

1. 等级5(优化级)

能够进行持续的过程改进，达到质量更佳

软件质量保证和软件测试的关系

软件测试可以查找错误并修改，从而提高软件质量

软件质量保证则是避免错误，从而提高软件质量

正规的软件测试系统主要包括：

• 制定测试计划
• 测试设计
• 实施测试
• 建立和更新测试文档

软件质量保证的工作为：

• 制定软件质量要求
• 组织正式审查
• 软件测试管理
• 对软件的变更进行控制
• 对软件质量进行度量
• 对软件质量 情况及时记录和报告

共同之处：尽力确保软件产品满足需求

不同之处：软件质量保证侧重于对软件开发过程中的各个过程进行管理与控制；测试是对已产生的软件缺陷进行修复

软件测试规范

通常分为国家标准、行业标准、企业规范和项目规范

软件测试过程与方法

软件测试过程

按照从编写到交付的各个阶段的先后顺序可以分为：

1. 单元测试
2. 集成测试
3. 确认测试
4. 系统测试
5. 验收测试

软件测试过程与软件开发过程的关系

软件开发过程是自下向上、逐步细化的过程

软件测试是自上向下、逐步集成的过程

单元测试

单元测试的对象是软件设计的最小单位—模块

单元测试的主要目标：确保个单元模块被正确的编码

单元测试的主要内容：

• 模块接口测试：对通过被测模块的数据流进行测试
• 局部数据结构测试：设计测试用例检查数据类型说明、初始化、默认值等问题
• 独立路径测试：对模块中重要的执行路径进行测试
• 出错处理测试：检查模块的错误处理功能是否含有错误或缺陷
• 边界条件测试

单元测试的步骤

在编码阶段进行，在代码经过评审和验证，确认没有语法错误后，开始进行单元测试

在单元测试中，会使用辅助模块帮助单元测试的进行

• 驱动模块：相当于被测模块的主程序，接受测试数据，并将数据输入到测试模块中
• 桩模块：用以代替被测模块调用的子模块，桩模块可以做少量的数据操作

集成测试

是单元测试的扩展和延伸，为了测试程序模块之间接口的规范性、一致性等

需要根据实际情况对程序模块采用适当的策略组装起来

集成测试的层次：

集成测试对传统软件和面向对象的应用系统的测试是不同的

传统软件的3个测试层次：

1. 模块被集成测试
2. 子系统内集成测试
3. 子系统间集成测试

面向对象的应用系统的两个测试阶段：

1. 类内集成测试
2. 类间集成测试

集成测试的模式：

采用不同的集成方式对应的测试不同

把模块组装成系统的测试方式有两种：

• 一次性集成测试

先分别测试每个模块，再把所有模块按设计要求一次性全部组装起来所要的系统，然后进行整体测试

• 增量式集成测试

将下一个要测试的模块同已经测好的模块结合起来进行测试，即边组装边测试

* 自顶向下增量测试

从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步组装各个模块

优点：尽早对程序的主要控制和决策机制进行检验

缺点：底层桩模块不符合真实情况

* 自底向上增量测试

从软件结构最底层的模块开始向上一层层地组装测试

优点：及早解决容易出错的部分

缺点：程序的主要控制和决策机制不能及时验证

* 混合增量测试

  * 改进的自顶向下增量测试

基本思想是强化对输入/输出模块和引入新算法模块的测试，并自底向上组装成为功能相当完整且相对独立的子系统，然后由主模块开始自顶向下进行增量测试

  * 自底向上-自顶向下

首先对含读操作的子系统自底向上直至根结点模块进行组装和测试，然后对含写操作的子系统做自顶向下的组装与测试

  * 回归测试

取自顶向下的方式测试被修改的模块及其子模块，然后将这一部分视为子系统，再自底向上测试，以检查该子系统与其上级模块的接口是否适配

集成测试的测试计划：测试计划表、各模块单元测试完成日期、首次集成测试日期、集成测试全部完成日期、测试用例及期望结果

集成测试完成的标志：

• 成功地执行力测试计划中规定的所有集成测试
• 修正了所发现的错误
• 测试结果通过了专门小组的评审

集成测试需要提交的文档：集成测试计划、集成测试规格说明、集成测试分析报告

确认测试

目的是验证软件的功能和性能及其特性是否与客户的要求一致，是否满足软件需求规格说明书中的规定。

确认测试的流程：

1. 进行有效性测试和软件配置审查
2. 进行验收测试和安装测试
3. 专家鉴定

确认测试的准则：

若一个软件的功能、性能及限制条件达到了设计要求，这个软件的开发是成功的

确认测试后发现严重错误和偏差一般很难在预定工期内改正，需要和用户协商

确认测试需要交付的文档有：

• 确认测试分析报告
• 最终的用户手册和操作手册
• 项目开发总结报告

确认测试需要进行软件配置复审 ，目的在于保证软件配置齐全、分类有序，各方面的质量符合要求，具备维护阶段所需的细节资料并且已经编排好分类的目录

系统测试

它是将已经集成好的软件系统，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行的环境下，对计算机系统进行一系列的组装测试和确认测试

系统测试的目的在于：通过与系统的需求定义进行比较，检车软件是否与系统需求顶不符合或与之矛盾的地方，以验证软件系统的功能和性能等是否满足其规约所指定的要求

系统测试的目标

• 确保系统测试的活动是按计划进行的
• 验证软件产品是否与系统需求用例不相符合或与之矛盾
• 建立完善的系统测试缺陷记录跟踪库
• 确保软件系统测试活动及其结果及时通知相关小组和个人

系统测试的过程：

1. 软件项目立项
2. 测试工程师参与前期的需求分析活动等
3. 测试工程师根据测试需求定义测试策略，进行工作量估计
4. 总体测试工作量估计并进行测试任务分配
5. 系统测试计划评审
6. 根据系统测试计划中的要求搭建测试环境
7. 设计测试用例
8. 系统测试用例评审
9. 定义系统用例执行过程，并更新系统测试用例
10. 执行系统测试并记录测试结果

系统测试的设计：

• 用户层：面向产品最终的使用操作者的测试
• 应用层：针对产品工程应用或行业应用的测试
• 功能层：针对产品具体功能实现的测试
• 子系统层：针对产品内部结构性能的测试
• 协议/指标层：针对系统支持的协议、指标的测试

常见的系统测试方法：

• 恢复测试

用来检查系统的容错能力。通过对软件的非法处理，使其不能正常工作，从而检验系统的恢复能力

• 安全测试

检测系统对外界非法入侵的防范能力

• 强度测试

检测程序对异常情况的抵抗能力

• 性能测试

测试软件在系统运行时的性能表现

• 容量测试

在系统正常运行的范围内测定系统能够处理的数据容量

• 正确性测试

检测软件的各项功能是否符合产品规格说明的要求

主要包括：枚举法、边界值法

• 可靠性测试

检测系统的可靠性是否达到预期目标的测试方法

• 兼容性测试

指软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同网络等环境中是否能够很好运行

• web测试

不同厂商、不同版本的浏览器对某些构建和设置的适应性

验收测试

验收测试是软件开发结束后，用户对软件投入实际应用前进行的最后一次质量检验活动

软件验收测试应该完成的内容：

• 规定验收通过的标准
• 确定测试方法
• 决定验收测试的组织机构和可利用资源
• 选定测试结果分析方法
• 指定验收测试计划并评审
• 设计验收测试的测试用例
• 审查验收测试的准备工作
• 执行验收测试
• 分析测试结果
• 得出测试结论，明确验收结果

验收测试的常用策略：

• 正式验收测试

是系统测试的延续

• 非正式验收测试(Alpha测试)

测试步骤和内容由测试人员决定

• Beta测试

Beta测试是所有测试中最主观的

验收测试可以分为两大部分：软件配置审查、可执行程序测试

白盒测试

白盒测试侧重于分析内部结构是否合理，以及设计测试用例来检验产品内部操作是否按照规格说明书正确执行

白盒测试可以分为：静态测试和动态测试

静态测试：不在计算机上执行程序，以人工模拟技术或使用测试软件对软件进行分析和测试

• 静态结构分析
• 静态质量度量
• 代码检查方法
• …

动态测试：设计一系列的测试用例，动态地运行程序，以发现程序中的缺陷

• 逻辑覆盖
• 路径测试
• …

逻辑覆盖测试

逻辑覆盖测试通过对程序的逻辑结构的遍历实现程序的覆盖

覆盖率是度量测试完整性的一个手段，是测试有效性的度量。

覆盖率计算公式：

\[覆盖率 = 至少被执行一次的item数 / item总数 \]

测试覆盖可以分为：

• 语句覆盖

每条可执行语句至少被执行一次

不能发现逻辑错误

• 判断覆盖(分支覆盖)

被测程序中的每个判断的”真”、”假”分支至少被执行一次

• 条件覆盖

被测程序中的每判断语句中的每个逻辑条件的可能值至少被满足一次

• 判断/条件覆盖

被测程序中的每个判断本身的判定结果至少满足一次，同时，每个逻辑条件的可能指也至少被满足一次

• 条件组合覆盖

被测程序中的每个判断的所有可能条件取值的组合至少被满足一次

不同的判断语句内的条件取值之间无需组合

条件组合只针对同一个判断语句内存在多个条件的情况

• 路径覆盖

被测程序中的每条路径至少被覆盖一次

路径分析测试

常见的路径覆盖方法：独立路径选择和Z路径覆盖

控制流图是对程序流程图的简化

控制流图的特点：

• 具有唯一的入口结点
• 具有唯一的出口结点
• 结点由带有标号的圆圈表示；包含条件的结点被称为判定结点
• 控制流线由带箭头的直线或弧表示

环型复杂度是描述程序逻辑复杂度的软件度量，适用于独立路径方法，是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上限

对于控制流图G，设其环型复杂度为V(G)，常见的计算方法：

1. \(V(G) = E - N + 2\) E是边的数量，N是结点的数目
2. \(V(G) = P + 1\) P是判定结点的数目
3. \(V(G) = A\) A是区域的数目

由边和结点围成的区域叫做区域，控制流图外的区域也作为一个区域

独立路径测试

一条独立路径是至少包含有一条在其他独立路径中从未有过的边的路径

独立路径测试的步骤：

1. 到处程序控制流图
2. 求出程序环型复杂度
3. 设计测试用例

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

Z路径覆盖测试

采用简化循环方法的路径覆盖。不考虑循环的执行次数，只考虑通过循环体0次和1次。即将循环结构转变为选择结构

循环测试

着重循环结构有效性测试的白盒测试方法

循环结构测试用例的设计有4种模式：

• 简单循环

测试集的几种情况：

1. 零次循环：跳过循环体
2. 通过一次循环体：检查循环初始值
3. 通过两次循环体：检查两次循环
4. m次通过循环体：检查多次循环
5. n-1,n,n+1次通过循环体：检查最大次数循环以及比最大次数多一次，、少一次的循环

• 嵌套循环

  1. 对最内层按照简单循环的测试方法，把其他外层循环设置为最小值
  2. 逐步外推，对其外面一层的循环进行测试。保持本次循环的所有外层循环仍取最小值
  3. 反复进行(b)中操作，向外层推进，直到所有各层循环测试完毕

• 串接循环

如果彼此独立，则采用简单循环；否则采用嵌套循环

• 非结构循环

需要重新设计结构化程序

代码检查法

主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等

代码审查

代码审查的步骤

1. 计划
2. 概述
3. 准备
4. 审查会议
5. 审查报告
6. 返工
7. 跟进

代码审查的特点：

• 专注于缺陷的检测
• 参与者有明确的角色
• 主持人不能是产品的作者
• 参与者需要做出相应的准备
• 高层管理人员不参加审查会议
• 检查单关注的是审查者过去所遇到的问题

桌面检查

通过对源程序代码进行分析、检验来发现程序中的错误。桌面检查关注的是变量的值和程序逻辑

代码走查

和代码审查类似，只是在会议进程上有所区别。

代码走查中，由测试者为所测程序准备一批代表性的测试用例，由参与者扮演计算机的角色，让测试用例按照代码逻辑运行，记录程序的状态

白盒测试综合策略

• 应尽量先用测试工具进行静态结构分析
• 采取先静态后动态的组合方式
• 利用静态分析的结果引导动态测试
• 覆盖率测试是白盒测试的重点，一般采用独立路径测试达到语句覆盖标准
• 不同测试阶段，测试的侧重点不同。单元测试：代码检查、逻辑覆盖；集成测试：静态结构分析、静态质量度量；系统测试：根据黑盒测试结果采取对应的白盒测试

使用N-S图表示基本的控制结构可以用于计算最少测试用例数

测试覆盖准则

1. Foster的ESTCA覆盖准则
2. Woodward等人的层次LCSAJ覆盖准则

黑盒测试

又称为功能测试或数据驱动测试，主要从用户的观点出发，以软件规格说明书为依据，着重测试软件的功能需求，对程序功能和程序接口进行测试

黑盒测试的两种基本方法

• 通过测试

确认软件能做什么，不会去考验能力如何

• 失败测试

为了破坏软件而设计和执行的测试用例

常见黑盒测试方法：

• 等价类划分
• 边界值分析
• 决策表
• 因果图

等价类划分法

把所有可能的输入数据划分为若干部分，对每个部分中选取具有代表性的数据作为测试用例

有效等价类：对软件规格说明书来说，合理、有意义的输入数据所构成的集合

无效等价类：不满足程序输入要求或无效的输入数据所构成的集合

划分等价类的几个原则：

• 如果规定了输入条件的取值范围或者个数，则可以确定一个有效等价类和两个无效等价类
• 如果规定了输入值的集合，则可以确定一个有效等价类和一个无效等价类
• 如果规定了输入数据的一组值，并且程序要对每一个输入值分别进行处理，则可为每一个值确定一个有效等价类，所有不允许的输入值的集合为无效等价类
• 如果规定里输入数据必须遵守的规则，则可以确定一个有效等价类和若干个无效等价类
• 如果已知的等价类中各个元素在程序中的处理方式不同，则应将该等价类进一步划分

划分等价类的标准：

• 完备性
• 无冗余性

针对是否对无效数据进行测试，将等价类测试分为

• 标准等价类测试

不考虑无效数据，测试用例使用每个等价类中的一个值

• 健壮等价类测试

考虑无效数据，对于有效数据，测试用例从每个有效等价类中取一个值；对无效数据，一个测试用例有一个无效值，其他值均为有效值

边界值分析法

边界值分析法的测试用例来自于等价类的边界，是一种补充等价类划分的测试用例设计技术

应用边界值分析法设计测试用例时，应遵循以下原则：

• 如果输入条件规定了值的范围，则应该选取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小数多1、比最大数少1的数作为测试数据
• 根据规格说明的每一个输出条件，分别使用以上两个原则
• 如果程序的规格说明给出的输入与或者输出域时有序集合，则应选取集合的第一个元组和最后一个元素作为测试用例
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界值作为测试用例

决策表法

用于分析和表达多个逻辑条件下执行不同操作情况

决策表由四部分组成：

• 条件桩：列出来问题的所有条件
• 动作桩：列出来问题规定的可能采取的操作
• 条件项：针对条件桩给出的条件列出所有可能的取值
• 动作项：列出条件项的各组取值情况下应该采取的动作

任何一个条件组合的特定取值及其相应要执行的操作称为一条规则，在决策表中贯穿条件项和动作项的一列就是一条规则。

建立决策表的步骤：

1. 确定规则的个数
2. 列出搜有的条件桩和动作桩
3. 填入条件项
4. 填入动作项
5. 化简

决策表适用于：

• 规格说明以决策表形式给出
• 条件或规则的排列顺序不会也不应影响执行哪些操作
• 每当某一规则的条件满足，并确定要执行的操作后，不必检验别的规则
• 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要

因果图法

利用图解法分析输入的各种组合情况，从而设计测试用例的方法，适用于检查程序输入条件的各种情况的组合

讲解

各种测试方法选择的综合策略

• 进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试
• 在任何情况下都必须使用边界值分析法
• 采用错误推测法再最佳测试用例
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度
• 如果程序的功能说明中含有输入条件的足额和情况，应再一开始就选用因果图法

软件测试计划

软件测试计划(STP)是描述对计算机软件配置，系统或子系统进行合格性测试的计划安排，内容包括进行测试的环境、测试工作的标识及测试工作的时间安排等

测试计划的内容：

• 测试目的
• 测试范围
• 测试对象
• 测试策略
• 测试任务
• 测试用例
• 资源配置
• 测试结果分析
• 度量及测试风险评估

软件测试计划是整个软件测试流程工作的基本依据，测试计划中所列条目在实际测试中必须一一执行

软件测试计划的目的是明确测试活动的意图，规范了软件测试内容、方法和过程，为有组织地完成测试任务提供保障

软件测试计划的主要作用：明确测试内容、测试完成时间、测试资源、测试风险、测试方法和过程

测试计划的编制原则：

1. 明确测试目标，增强测试计划的实用性
2. 坚持5W规则，明确测试的内容与过程
3. 采用评审和更新机制，保证测试计划满足实际需求
4. 分别创建测试计划与测试详细规格、测试用例

测试过程实施所必备的核心文档是：测试计划、测试用例和软件测试报告

测试用例

测试用例是对一项特定的软件产品进行测试任务描述，体现测试方案、方法、技术和策略

测试用例的内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档

一个完整有效的测试用例应该具备的特点有：

• 覆盖率100%
• 对测试环境，用户环境，模拟用户环境，以及之间差别的描述
• 设计场景测试法虚拟业务流程
• 建立测试公共数据，并根据系统内部关系组织数据的关联性
• 测试用例可执行
• 如果有标准的模板，使用用例模板

\[测试完成率 = 实际测试项数目 / 计划测试项数目 * 100\% \]

\[测试覆盖率 = [Y]项的数目 / 计划测试项数目 * 100\% \]

[Y]表示测试结果全部通过

自动化测试

主要是通过所开发的软件测试工具、脚本呢等来实现，具有良好的可操作性、可重复性和高效率等特点

测试的自动化部分在于测试过程自动化或测试结果分析自动化

手动测试的目的着重于发现新的软件故障

自动化测试的目的着重于发现旧的软件故障

自动化测试有点：

• 对程序的新版本运行回归测试

回归测试：在新版本中存在和旧版本相似的功能，可以复用旧版本的测试

• 可以运行更多更频繁的测试

• 可以进行一些手工测试难以完成的任务

自动化测试的适用情况：

• 回归测试
• 设计大量不同数据输入的功能测试
• 用手工完成难度较大的测试，如性能测试

自动化测试方法：

1. 代码分析

2. 捕获和回放

捕获：记录用户每一步操作并转换为脚本

回放：将脚本转换为用户的操作

1. 脚本技术

   • 线性脚本

   • 结构化脚本

   • 共享脚本

某个脚本可以被多个测试用例使用

 * 数据驱动脚本

 * 关键字驱动脚本

自动化测试过程

1. 自动化测试需求分析
2. 自动化测试框架的搭建
3. 脚本的编写
4. 脚本的测试与试运行

自动化测试工具

• 白盒测试工具

  1. 静态测试工具

Logiscope、PRQA

2. 动态测试工具

DevPartner、Purify

工具名	支持语言
Jtest	Java
Jcontract	Java
C++Test	c/c++
Code Wizard	c/c++
Insure++	c/c++
.test	.Net
BiundChecker	c++, Delphi
TrueTime	c++,java,VB
Failsafe	VB
TrueCoverage	c++,java,VB
CodeReview	VB
Jcheck	MS Visual J++

• 黑盒测试工具

主要包括功能测试工具、负载测试工具、性能测试工具

工具名

WinRunner
Astra Quick Test
LoadRunner
Robot
Team Test
QARun
QALoad
Silk Test
Silk Performer
e-Test
e-Load
WAS
Webload
OpenSTA
* 测试管理工具

用于对测试进行管理。负责对测试计划、测试用例、测试的实施进行管理

TeamManager、TrackRecord、TestDirector