软件工程的测试阶段是软件开发过程中工作量最大的阶段之一，随着软件测试工作日益得到重视，测试工具的应用已经成为普遍趋势。测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，别外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具。其他测试工具（专用测试测试，如针对数据库测试的工具，对应用性能进行优化的工具等）。

测试工具的选择

建议从以下几个方面来权衡和选择

1. 功能

除了测试工具所提供的基本功能外，还可参考其它的功能需求，如报表功能、测试工具的集成能力、操作系统和开发工具的兼容性。

2. 价格

自主制作一个工具

有些情况下，我们需要自己制作测试工具：

l         操作系统不兼容：市场上没有现成的工具与正在使用的各种操作系统兼容，所以需要考虑制作一个在专门的测试环境下运行的定制工具。例如： Linux 下的消耗 CPU 的工具。

l         应用程序不兼容：正在测试的应用程序包含一个特殊元素，如一个自定义的控件或第三方插件，它和市场上存在的任何记录 / 回放工具都不兼容。例如：公司产品：录像播放器。

l         专项测试的需要：为了取得最佳的测试效果，以便对不能使用 GUI 测试工具的，复杂的和关键的组件进行自动测试。例如： agent 报文捕获率的测试。

自动测试：选择最好的实践

不要过分依赖记录 / 回放工具。

功能性测试工具（也称为记录 / 回放工具），只是无数可供利用的测试工具中的一种。记录 / 回放机制能够增强测试工作的效果，但是我们不应该只使用这一种自动测试方法。即使使用最好的记录 / 回放自动测试技术，它们还是有局限性。

1 ）硬编码的数值。

2 ）非模块化的、不易维护的脚本。

3 ）缺乏可重用性的标准。

尽量使回归测试自动化

回归测试确定的是：在修改先前的错误或者向应用程序添加新功能时，是否引放了新的错误，这些错误影响以前运行正常的功能。回归测试应该发现这些新引入的缺陷。

了解自动测试工具对测试工作的影响

自动测试工具只是解决方案的一部分，它们不能解决所有测试工作中的问题。自动测试工具决不能代替指导测试工作的分析技能，也不能替代手工测试。我们必须把自动测试看作是对手工测试过程的补充。

自动化测试可以帮助测试人员做到：

（ 1 ）提高测试执行的速度；

（ 2 ）提高运行效率；

（ 3 ）保证测试结果的准确性；

（ 4 ）连续运行测试脚本；

（ 5 ）模拟现实环境下受约束的情况。

自动化测试不能做到的是：

（ 1 ）所有测试活动都可以自动完成；

（ 2 ）减少人力成本；

（ 3 ）毫无成本的得到；

（ 4 ）降低测试的工作量。

附：测试工具介绍

IBM rational 测试工具：

测试缺陷管理工具 ClearQuest

性能测试工具： Rational Performance Tester （ TestManager 、 Robot ）

功能测试工具： Functional Tester （ Test XDE ）

单元测试工具： IBM/Rational PurifyPlus

– Purify ：白盒测试工具，自动定位内存相关错误

– Quantify ：白盒测试工具，用于性能瓶颈分析

– Pure Coverage ：白盒测试工具，记录代码覆盖率。发现未被测试的代码

– TestFactory ：可靠性测试

– Robot  自动测试工具，类似 WINRUNNDER ，加上 VT 可以做并发测试

– TestManager      测试计划制定及执行工具

Mercury 测试工具

功能测试： WinRunner  ， LoadRunner ， TestDirector

开源工具

测试框架： Junit 、 NUnit 、 HttpUnit 、 CppUnit

性能测试： JMeter

测试覆盖率工具： clover.net

参考文献：

《软件评测师考试考点分析与真题详解》 — 电子工业出版社

《有效软件测试 — 提高软件测试的 50 条建议》 — 清华大学出版社

《系统分析师常用工具》 — 清华大学出版社

本文档的ppt

相同点

不同点

QA

TEST

QA

TEST

保证和提高产品质量

关注过程

SQA 重点是对软件开发过程进行监督管理、控制

关注产品

TESTER 重点是对软件开发的成果进行检查、控制

以组织标准过程和项目已定义过程为依据

以产品需求为依据

以评审和审计为主要手段

以模拟各种场景的实际使用为手段

重在发现和提出过程存在的问题

重在发现产品存在的缺陷

重在预防

重在发现和纠正

软件配置管理的作用：

通过软件配置管理，严格执行软件开发过程控制，使软件开发的各个过程阶段（）置于软件配置管理控制之下，真实地记录软件生命周期内的全部过程活动，使软件开发从无形变成有形，从无法管理变成有章可循。

通过软件配置管理，严格执行软件版本控制（），做到完整保存各种历史软件，有利于验证和比较测试、联试中出现的问题；严格执行软件更改控制，严格审批更动过程。

配置管理内容：确立基线；建立 3 库（开发库、受控库、产品库）；出入库管理和审计；状态报告和查询。

测试管理组包括评审小组、测试小组和支持小组。

软件测试过程分成 4 个阶段：单元测试、集成测试、系统测试和验收测试。

软件测试文档描述要执行的软件测试及测试的结果。

测试文件的类型：测试计划和测试分析报告。

测试文件的重要性表现在：
（ 1 ）验证需求的正确性；
（ 2 ）检验测试资源；
（ 3 ）明确任务的风险；
（ 4 ）生成测试用例；
（ 5 ）评价测试结果；
（ 6 ）再测试；
（ 7 ）决定测试的有效性。

软件工程领域要考虑的风险类型：（ 1 ）项目风险；（ 2 ）技术风险；（ 3 ）商业风险。

风险条目检查表：
（ 1 ）产品规模风险；
（ 2 ）商业影响风险；
（ 3 ）客户相关风险；
（ 4 ）过程风险；
（ 5 ）技术风险；
（ 6 ）开发环境风险；
（ 7 ）与人员数目及经验相关的风险。

在 2003 年颁布的 GB/T16260-2003(ISO 9126-2001) 《软件工程 产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性；即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

（ 1 ）易理解性；（ 2 ）易学习性；（ 3 ）易操作性；（ 4 ）吸引性；（ 5 ）依从性。

易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。包括如下方面的测试：
（ 1 ）易理解性测试；
（ 2 ）易学性测试；
（ 3 ）易操作性测试；
（ 4 ）吸引性测试；
（ 5 ）易用的依从性测试。

易用性测试方法有：静态测试；动态测试；动态和静态结合测试。

软件质量模型将质量属性划分为 6 种特性：功能性、可靠性、易用性、效率、维护性和可移植性。

易用性与可靠性是正相关的；易用性与安全性（功能性的子特性）的某些方面是负相关的。

安装测试的主要工作（安装的易用性）：
（ 1 ）安装手册的评估；
（ 2 ）安装的自动化程度测试；
（ 3 ）安装选项和设置的测试；
（ 4 ）安装过程的中断测试；
（ 5 ）安装顺序测试；
（ 6 ）多环境安装测试；
（ 7 ）安装的正确性测试；
（ 8 ）修复安装测试和卸载测试。

功能易用性测试：
（ 1 ）业务符合性；
（ 2 ）功能定制性；
（ 3 ）业务模块的集成度；
（ 4 ）约束性；
（ 5 ）交互性；
（ 6 ）系统信息与错误提示。

界面整体测试指对界面的规范性、一致性、合理性等进行测试和评估。

国家有关计算机软件产品开发文件编制指南（）中共有 14 种文件，可分为 3 大类。

1．  开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

2．  用户文件：用户手册、操作手册。

3．  管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

用户文档分类：联机帮助；样例、示例和模板；包装；宣传与广告；其他。

用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。

用户文档测试方法：技术校对；功能测试；其他辅助方式。

用户文档测试要点：文档的读者群；文档的术语；文档的正确性；文档的完整性；文档的一致性；文档的易用性；样例与示例；文档的语言；印刷与包装质量。

用户手册、操作手册的测试：“严格”地使用系统；“随心所欲”地使用系统；尝试文档中的每个建议和注意事项；描述的准确性；从用户角度看手册。

联机帮助的测试：准确性、用户的查询；帮助主题的完整性；帮助的风格。

软件安全性是与防止对程序和数据的非授权的故意或意外访问的能力相关的软件产品属性。软件安全性的测试包括程序和数据安全性的测试。

安全测试内容：用户认证机制、加密机制、安全防护策略、数据备份与恢复、防病毒系统。

安全测试策略：

（ 1 ）安全防护体系：实体安全、平台安全、数据安全、应用安全、通信安全、运行安全、组织安全、管理安全。

（ 2 ）安全保护国家标准：用户自主保护级、系统审计保护级、安全标记保护级、结构化保护级、安全域级保护级。

为保证实体、数据、平台、应用、运行等的安全，主要采用以下几种安全防护技术：防火墙、入侵检测系统、漏洞扫描、安全审计、病毒防治、 Web 信息防篡改。

安全测试方法：

主动发现方法：功能验证、漏洞扫描、模拟功能、侦听技术。

硬件兼容性测试：主机兼容性测试；板卡、配件及外设的兼容性测试。

配置指标主要包括对 CPU 、内存和硬盘的要求。

推荐配置就保证软硬件构成的系统在正常业务的压力负载下， CPU 资源占用率平均值不超过 75% 。

软件兼容性测试：操作系统兼容性测试、数据库兼容性测试、中间件兼容性测试、与其他软件的兼容性测试。

数据兼容性测试：编码体系测试、数据标准符合性测试。

新旧系统数据迁移测试：迁移准备、迁移实施、迁移验证。

平台软件兼容性测试：平台软件硬件、软件、数据库、文种兼容性测试。

网络性能测试的主要依据是：
（ 1 ）双方在规划设计阶段共同认可的网络性能指标；
（ 2 ）有关的国家标准或行业标准。

网络性能测试的具体内容应以网络设计方案为准，但一般包括以下内容：

（ 1 ）网络容量测试：最大容量和有效容量；

（ 2 ）网络响应时间测试：检测网络系统完成一系列任务所需的时间；

（ 3 ）网络可靠性测试；

（ 4 ）网络吞吐量测试；

（ 5 ）网络配置规模测试；

（ 6 ）网络瓶颈测试；

（ 7 ）衰减测试。

网络性能测试分类：
（ 1 ）网络可接受性测试；
（ 2 ）网络升级测试；
（ 3 ）网络设备评估测试。

网络性能测试的对象：
（ 1 ）路由器、集线器、交换机和网桥；
（ 2 ）网段；
（ 3 ）全局网；
（ 4 ）网络操作系统；
（ 5 ）文件服务器；
（ 6 ）工作站。

网络应用测试的主要内容：
（ 1 ）性能测试；
（ 2 ）功能测试；
（ 3 ）网络应用负载测试；
（ 4 ）应用系统响应时间测试；
（ 5 ）应用系统升级测试。

Web 应用测试类型：功能测试、性能测试、可用性测试、兼容性测试和安全测试。

根据测试对象的不同， Web 功能测试又分为链接测试、表单测试、 Cookies 测试、设计语言测试、数据库测试。

Web 性能测试是要是确保 Web 应用系统达到要求的性能，一般用最大运行时间、吞吐率、响应时间描述。 Web 应用在极端条件下的性能测试又分为负载测试和压力测试。负载测试是为了测量 Web 系统在某一负载级别上的性能，以保证 Web 系统的在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数据，也可以是在线数据处理的数量。压力测试是指实际破坏一个 Web 应用系统时测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。压力测试侧重于确定系统崩溃时的用户负载量。压力测试的区域包括表单、登录和其它信息传输页面等。

Web 性能测试：（ 1 ）连接速度测试；（ 2 ）负载测试；（ 3 ）压力测试。

Web 可用性测试：（ 1 ）导航测试；（ 2 ）图形测试；（ 3 ）内容测试；（ 4 ）整体界面测试。

Web 兼容性测试：（ 1 ）平台测试；（ 2 ）浏览器测试。

Web 安装性测试，就是测试 Web 应用防止未授权用户访问或故意破坏等情况下的能力，其重点是测试 SSL （安全套接字）配置、登录模块、事务完整性等方面。

面向对象技术主要包括 6 个核心概念：对象、消息、接口、类、继承、多态。

面向对象的开发模型实质是将软件测试过程分成 3 个阶段，即面向对象分析（ OOA ）、面向对象设计（ OOD ）和面向对象编程（ OOP ）。

面向对象测试的类型分为：面向对象分析的测试（ OOA Test ）、面向对象设计的测试（ OOD Test ）、面向对象编程的测试（ OOP Test ）、面向对象单元测试（ OO Unit Test ）、面向对象集成测试（ OO Integration Test ）、面向对象系统测试（ OO System Test ）。

面向对象测试类型的另一种划分：模型测试、类测试（用于代替单元测试）、交互测试（用于代替集成测试）、系统（包括子系统）测试、接收测试、部署测试。

传统测试模式与面向对象的测试模式的最主要的区别在于，面向对象的测试更关注对象而不是完成输入 / 输出的单一功能，这样的话测试可以在分析与设计阶段就先行介入，便得测试更好的配合软件生产过程并为之服务。与传统测试模式相比，面向对象测试的优点在于：更早地定义出测试用例；早期介入可以降低成本；尽早的编写系统测试用例以便于开发人员与测试人员对系统需求的理解保持一致；面向对象的测试模式更注重于软件的实质。

面向对象测试的过程：
（ 1 ）指定范围；
（ 2 ）指定深度；
（ 3 ）指定已创建的被测试模块的基本要求（上一个阶段需要提供的接口）；
（ 4 ）以基本模型的内容为输入来设计测试用例作为评估标准；
（ 5 ）生成测试覆盖度量标准；
（ 6 ）试用测试清单执行静态分析，确保被测模块与基本模型的一致性；
（ 7 ）执行测试用例；
（ 8 ）如果覆盖不足以检测所有的活动，就需要分解测试工作，并且使用传统测试用例的方式来警醒，或者中断测试，重新测试传统测试用例。

软件工程的测试阶段是软件开发过程中工作量最大的阶段之一，随着软件测试工作日益得到重视，测试工具的应用已经成为普遍趋势。测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，别外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具。其他测试工具（专用测试测试，如针对数据库测试的工具，对应用性能进行优化的工具等）。

表格 1 测试工具

测试工具的选择

建议从以下几个方面来权衡和选择

1. 功能

除了测试工具所提供的基本功能外，还可参考其它的功能需求，如报表功能、测试工具的集成能力、操作系统和开发工具的兼容性。

2. 价格

自主制作一个工具

有些情况下，我们需要自己制作测试工具：

l         操作系统不兼容：市场上没有现成的工具与正在使用的各种操作系统兼容，所以需要考虑制作一个在专门的测试环境下运行的定制工具。例如： Linux 下的消耗 CPU 的工具。

l         应用程序不兼容：正在测试的应用程序包含一个特殊元素，如一个自定义的控件或第三方插件，它和市场上存在的任何记录 / 回放工具都不兼容。例如：公司产品：录像播放器。

l         专项测试的需要：为了取得最佳的测试效果，以便对不能使用 GUI 测试工具的，复杂的和关键的组件进行自动测试。例如： agent 报文捕获率的测试。

自动测试：选择最好的实践

不要过分依赖记录 / 回放工具。

功能性测试工具（也称为记录 / 回放工具），只是无数可供利用的测试工具中的一种。记录 / 回放机制能够增强测试工作的效果，但是我们不应该只使用这一种自动测试方法。即使使用最好的记录 / 回放自动测试技术，它们还是有局限性。

1 ）硬编码的数值。

2 ）非模块化的、不易维护的脚本。

3 ）缺乏可重用性的标准。

尽量使回归测试自动化

回归测试确定的是：在修改先前的错误或者向应用程序添加新功能时，是否引放了新的错误，这些错误影响以前运行正常的功能。回归测试应该发现这些新引入的缺陷。

了解自动测试工具对测试工作的影响

自动测试工具只是解决方案的一部分，它们不能解决所有测试工作中的问题。自动测试工具决不能代替指导测试工作的分析技能，也不能替代手工测试。我们必须把自动测试看作是对手工测试过程的补充。

自动化测试可以帮助测试人员做到：

（ 1 ）提高测试执行的速度；

（ 2 ）提高运行效率；

（ 3 ）保证测试结果的准确性；

（ 4 ）连续运行测试脚本；

（ 5 ）模拟现实环境下受约束的情况。

自动化测试不能做到的是：

（ 1 ）所有测试活动都可以自动完成；

（ 2 ）减少人力成本；

（ 3 ）毫无成本的得到；

（ 4 ）降低测试的工作量。

参考文献：

《软件评测师考试考点分析与真题详解》 — 电子工业出版社

《有效软件测试 — 提高软件测试的 50 条建议》 — 清华大学出版社

《系统分析师常用工具》 — 清华大学出版社

白盒测试基本技术：控制流图、代码覆盖率分析（ Code Coverage Analysis ）。

白盒测试方法：从总体上可划分为静态测试和动态测试；按测试操作的实施方式划分为手工测试和借助于工具的自动化测试等。

白盒测试的静态测试方法：代码检查法、静态结构分析法、代码质量度量法等。

白盒测试的动态测试方法：功能确认与接口测试、逻辑覆盖分析法、基本路径测试法、性能分析、内存分析等。

动态测试通常在静态测试之后进行。

其他白盒测试方法：域测试（ Domain Testing ）、程序变异测试、符号测试、数据流测试、 Z 路径测试。

常用的黑盒测试用例设计方法有：等价类划分法、边值分析法、错误猜测法、因果图方法等，其他的一些测试方法还有判定表驱动法、正交试验法、功能图法，以及场景法等。

面向对象测试关注于设计合适的操作序列以测试类的状态。

测试用例设计方法的主要原则包括：

（ 1 ）对每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系。

（ 2 ）测试目的应当明确。

应当为每个测试用例开发一个测试步骤列表。这个列表应包括以下一些内容：

（ 1 ）列出所要测试的对象的专门说明；

（ 2 ）列出将要作为测试结果运行的消息和操作；

（ 3 ）列出测试对象可能发生的例外情况；

（ 4 ）列出外部条件；

（ 5 ）列出为了帮助理解和实现测试所需要的附加信息。

软件测试基本概念

软件质量与软件测试：软件测试是软件质量保证工作的一个重要环节。软件测试和软件质量保证是软件质量工程的两个不同层面的工作。软件测试只是软件质量保证工作中的一个重要环节。质量保证（ QA ）的工作是通过预防、检查与改进来保证软件的质量，它所关注的是软件质量的检查和测量。软件测试所关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。

软件测试定义：软件测试就是在软件投入运行前对软件需求分析、软件设计规格说明和软件编码进行的查错（包括代码执行活动与人工活动）。软件测试是为了发现错误而执行程序的过程。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序的错误。是在软件投入运行前，对软件需求分析、软件设计规格说明和软件编码的最终复审，是软件质量保证的关键步骤。

软件测试目的：（ 1 ）测试是一个为了寻找错误而运行程序的过程；（ 2 ）一个好的测试用例是指很可能找到迄今为止未发现的错误的用例；（ 3 ）一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

软件测试的目标是能够以耗费最少时间与最小工作量找出软件系统中潜在的各种错误与缺陷。

测试只能证明程序中错误的存在，但不能证明程序中没有错误。

软件测试原则：（ 1 ）尽早地并不断地进行软件测试；（ 2 ）程序员或程序设计机构应避免测试自己设计的程序；（ 3 ）测试前应当设定合理的测试用例；（ 4 ）测试用例的设计不仅要有合法的输入数据，还要有非法的输入数据；（ 5 ）在对程序修改之后要进行回归测试；（ 6 ）充分注意测试中的群集现象；（ 7 ）妥善保留测试计划、全部测试用例、出错统计和最终分析报告，并把它们作为软件的组成部分之一，为软件的维护提供方便；（ 8 ）应当对每一个测试结果做全面检查；（ 9 ）严格执行测试计划，排除测试的随意性。

软件测试对象：软件的测试不仅仅是程序的测试，软件的测试应贯穿于整个软件生命同期中。在软件定义阶段产生的可行性报告、项目实施计划、软件需求说明书或系统功能说明书，在软件开发阶段产生的概要测试说明书、详细设计说明书，以及源程序等都是软件测试的对象。

软件测试过程模型： V 模型、 W 模型、 H 模型。

软件测试模型的使用：在实际软件测试的实施过程中，应灵活地运用各种模型的优点，通常可以在 W 模型的框架下，运用 H 模型的思想进行独立的测试。当有变更发生时，按 X 模型和前置模型的思想进行处理。同时，将测试和开发紧密结合，寻找恰当的就绪点开始测试，并反复进行迭代测试，以达到按期完成预定的目标。

软件问题分类：软件错误、软件缺陷、软件故障、软件失效。

软件测试类型：

按开发阶段分：单元测试、集成测试、确认测试（有效性测试）、系统测试

确认测试、验收测试

按测试实施组织分：开发方测试（验证测试或 alpha 测试）、用户测试（ beta ）、第三方测试（独立测试）

按测试方式分：动态测试、静态测试

按测试技术分：白盒测试、黑盒测试、灰盒测试

软件测试过程：用黑盒法设计基本的测试方案，再利用白盒法补充一些必要的测试方案。可以用以下策略结合各种方法：

（ 1 ）在任何情况下都应该使用边界值分析的方法；

（ 2 ）必要时用等价划分法补充测试方案；

（ 3 ）必要时用错误推测法补充测试方案；

（ 4 ）如果在程序的功能说明中含有输入条件的组合，最好在一开始就用因果图法，然后再按以上（ 1 ）、（ 2 ）、（ 3 ）步进行。

（ 5 ）对照程序逻辑，检查已设计出的设计方案。可以根据对程序可靠性的要求采用不同的逻辑覆盖标准，如果现有测试方案的逻辑覆盖程度没有达到要求的覆盖标准，则应再补充一些测试方案。

单元测试主要是对模块的 5 个基本特性进行测试和评价：（ 1 ）模块接口；（ 2 ）局部数据结构；（ 3 ）重要的执行路径；（ 4 ）错误处理；（ 5 ）边界测试。

在集成测试时，要考虑的问题有：数据经过接口是否会丢失；一个模块对另一模块是否造成不应有的影响；几个子功能组合起来能否实现主功能；误差不断积累是否达到不可接受的程度；全局数据结构是否有问题。

确认测试又称为有效性测试、合格测试或验收测试。确认测试主要由使用用户参加测试，检验软件规格说明的技术标准的符合程度，是保证软件质量的最后关键环节。

系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试实质上是由一系列不同测试组成的，其主要目的是充分运行系统，验证系统各个部件是否都能正常工作并完成所分配的功能。

系统测试包括：恢复测试、安全性测试、强度测试、性能测试等。

验收测试是以用户为主，软件开发人员和质量保证人员也应参加的测试。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。验收测试往往知系统测试完成后，项目最终交付前进行。

白盒测试是一种结构测试，有时也被称为逻辑驱动测试，它与程序内部结构相关，需要利用程序结构的实现细节等知识，才能有效进行测试用例的设计工作。

1．  控制流图

程序流程图 (flowchart)

控制流图（ Control Flow Graph ， CFG ）：控制流图一般只有两种简单的图示符号：节点和控制流。

（1）       节点。以标有编号的圆圈表示，它一般代表了程序流程图中矫形框所表示的处理、以及菱形框所表示的判定条件，以及两条或多条节点的汇合点等。

（2）       控制流。以带箭头的弧线表示，用来连接相关的两个节点。

控制流图的一个重要性质是它的可规约性（ reducibility ）。如果程序中不存在从循环外跳到循环内的 goto 语句，那么这个程序对应的控制流图是可规约的 (reducible) ，反之这个控制流图是不可规约的 (irreducible) 。因此，模块符合结构化程序设计的准则是控制流图可规约的基础。

2．  代码覆盖率分析

典型的逻辑覆盖度量标准有 5 种，它们按照从低到高的排序一般可分为：语句覆盖（ Statement Coverage SC ）、判定覆盖（ Decision Coverage DC ）、条件覆盖（ Condition Coverage CC ）、判定 / 条件覆盖（ Decision/Condition Coverage DCC ）和条件组合覆盖（ Multiple condition Coverage MCC ），条件组合覆盖，也被称为多条件覆盖，它所完成的逻辑覆盖程序最高。

(1)    语句覆盖（ Statement Coverage SC ）

语句覆盖指通过选择足够的测试用例，使得运行这些测试用例时，被测程序的每上语句至少被执行一次。

(2)    判定覆盖（ Decision Coverage DC ）

判定覆盖又称为分支覆盖，它指通过设计足够的测试用例，使得程序中的每一个判定至少都获得一次“真值”和“假值”的机会，或者说使得程序中的每一个分支都至少通过一次。满足判定覆盖度量标准的测试用例，一定也满足语句覆盖的度量标准。

(3)    条件覆盖（ Condition Coverage CC ）

条件覆盖指对于每个判定中所包含的若干个条件，应设计足够多的测试用例，便得判定中的每个条件都至少取到一次“真值”和“假值”的机会，也就是说，判定中的每个条件的所有结果至少出现一次。

(4)    判定 / 条件覆盖（ Decision/Condition Coverage DCC ）

判定 / 条件覆盖指通过设计足够多的测试用例，使得运行这些测试用例时，判定中的每个条件的所有结果至少出现一次，并且每个判定本身的所有可能结果也至少出现一次。满足判定 / 条件覆盖度量标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖度量标准。

(5)    条件组合覆盖（ Multiple condition Coverage MCC ）

条件组合覆盖指通过设计足够多的测试用例，使得运行这些测试用例时，每个判定中条件结果的所有可能组合至少出现一次。条件组合覆盖是对每个判定分别考虑它们的条件组合，而不是对整个程序中所有判定的所有条件的组合。满足条件组合覆盖的测试用例一定也满足语句覆盖、判定覆盖、条件覆盖、判定 / 条件覆盖，它是上述 5 种覆盖度量标准中最强的一种。

(6)    修正的条件 / 判定覆盖（ Modified Decision/Condition Coverage MCDC ）

(7)    路径覆盖（ Path Coverage ）

路径覆盖指通过设计足够多的测试用例，使得运行这些测试用例时，程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求环路至少经过一次）。路径覆盖，也称为断言覆盖（ predicate Coverage ）

3．  其它的覆盖度量标准

(1)    函数覆盖（ Function Coverage ）。

(2)    调用覆盖（ Call Coverage ）。也被称为调用对覆盖（ call pair coverage ）。

(3)    线性代码顺序及跳转覆盖（ Linear Code Sequence and Jump Coverage ）。

(4)    数据流覆盖（ Data Flow Coverage ）。

(5)    目标代码分支覆盖 (Object Code Branch Coverage) 。

(6)    循环覆盖 (Loop Coverage) 。

(7)    竞争覆盖（ Race Coverage ）。

(8)    关系操作符覆盖（ Relational Operator Coverage ）。

(9)    弱变化覆盖（ Weak Mutation Coverage ）。

(10) 表覆盖（ Table Coverage ）。

(11) 函数出入口覆盖（ Function Exits Coverage ）。