第四章 测试工程
4.4 测试的前期准备
? 软件测试工程的作业过程可分为 测试设
计 （包括制定测试计划、确定测试方法
等）和 实施测试 两大步骤。
4.4.1测试规划与测试设计
? 对大规模开发系统一般不采用一次性整
体测试，而是从局部依次扩大到整体的
测试，按计划，有步骤地实施测试。一
般从项目需求定义开始，概要设计、详
细设计、程序编码的各个开发阶段，要
进行测试设计，作成测试计划书，还包
括测试作业完成后移植运行作业的计划。
4.4.1测试规划与测试设计
? 表 4.3各开发阶段的测试规划和设计评审
验证内容
4.4.1测试规划与测试设计
? 测试计划书一般包括如下的一些的内容：
（ 1）测试工程概要、测试场所、测试方针
（ 2）测试日程和实施体制
4.4.1测试规划与测试设计
（ 3）测试管理方法
·测试工具
·测试环境
·测试检测清单
·验证方法
·版本管理方法
·进度管理方法
·问题管理方法
·回归测试方法
·设计变更管理方法
4.4.1测试规划与测试设计
（ 4）针对各阶段的测试应明确的事项
·阶段测试的目的和范围
·阶段测试开始和测试终止的基准
·阶段测试检测清单
·阶段测试实施日程和实施体制
·阶段测试的验收基准和方法
4.4.2 了解系统错误、缺陷的影响度
? 信息系统的测试很难实现在与实际运行
环境（数据、使用者、硬件、时间、网
络、系统负荷等）完全一致的条件下进
行的测试。
? 在做测试计划和测试设计时，充分理解
软件的错误、缺陷对用户将会造成什么
样的影响是很重要的。
4.4.2 了解系统错误、缺陷的影响度
? 软件中即使是很微小的错误，有可能会
给用户造成重大的损害和影响。
4.4.2 了解系统错误、缺陷的影响度
? 下图是系统缺陷对一个生产型企业的各
个方面所产生的影响
业务
混乱
系统缺
陷
丧失顾
客信任
经济损
失
不可能
恢复的
数据
业务停
止
不能回答用户的咨
询
送货发生错误
交付期延迟
不能处理用户订货
断货
业务状况不明
不能检索信息
不能进行业务指示
产品报废
业务效率降低
发生手工作业
发生返工
用户信息
产品信息
设计信息
销售信息
生产信息
4.4.3利用各种测试支持工具
? 测试工具：
⑴ 作为定型测试，反复实施测试作业的支持工具；
⑵ 确定测试分支、生成测试数据的支持工具；
⑶ 验证测试的覆盖率，提高测试效率的工具；
⑷ 性能测试的支持工具；
⑸ 管理与测试相关连项目的支持工具；
⑹ 变更管理、版本管理的支持工具；
⑺ 检测错误作业的支持工具。
4.4.3利用各种测试支持工具
? 表 4.4 部分常用的测试支持工具
常用测试工具
? Mercury Interactive
? WinRunner-----功能：
1.插入检查点；
2.检验数据；
3.增强测试；
4.分析结果；
5.维护测试；、
６,为无线应用作准备。
? 范围：功能测试、生成测试用例、分析测试结果、
维护测试用例、回归测试。
常用测试工具
? LoadRunner-----功能：
1.松创建虚拟用户；
2.创建真实的负载；
3.定位性能问题；
4.分析结果以精确定位问题所在；
5.重复测试保证系统发布的高性能；
6.Enterprise Java Beans的测试；
7.支持无线应用协议；
8.支持 Media Stream应用；
9.完整的企业应用环境的支持。
? 范围：性能测试、压力测试、模拟多用户、定位性能瓶颈
常用测试工具
? TestDirector------功能：
1．需求管理 ;
2,计划测试 ;
3,安排和执行测试 ;
4,缺陷管理 ;
5,图形化和报表输出 ;
? 范围：测试管理工具
常用测试工具
? Rational系列
? Rational Purify （测试时用，检查运行时内
存错误） ;
? Rational Quantify（性能检测工具，查出系
统瓶颈以便改进运行速度） ;
? Rational TestManager （测试管理） ;
4.4.4 测试检测清单与测试数据
? 根据测试计划，按各个测试阶段的目的
准备实施测试使用的检测清单和测试使
用的数据。
4.4.4 测试检测清单与测试数据
? 如单元（模块）测试阶段的程序检测清
单称为 PCL，组合测试阶段的检测清单称
为 CCL，系统测试阶段的检测清单称为
SCL。
4.4.4 测试检测清单与测试数据
? 在测试中需要验证的项目及其判别、制
约条件必须全部记入 检测清单 。
4.4.4 测试检测清单与测试数据
? 例如单元测试的程序检测清单 PCL要明确
以下几个方面内容：
⑴ 窗体显示的输入、输出项目及判别条件；
⑵ 输出表格印刷输出项目及判别条件；
⑶ 数据库 /文件输入、输出项目及判别条
件；
⑷ 程序间传递的数据、信息及判别条件。
4.4.4 测试检测清单与测试数据
? 作成检测清单应遵循如下的原则：
⑴ 具体性,判别条件和确认内容必须是在
测试结果中可确认的；
⑵ 完整性,检测内容必须是包含设计书中
的所有项目、功能；
⑶ 有一定的密度,检测点占测试对象的一
定比例。
4.4.4 测试检测清单与测试数据
⑷ 有一定的 分布率,如 PCL对正常、异常、临界
处理及模块间接口数据、信息传输的检测一般
按如下比率分配：
① 检测正常分支的 PCL条数约占 70%；
② 检测异常分支的 PCL条数约占 10%；
③ 检测边界、临界项目的 PCL条数约占 15%；
④ 检测关联模块间传递、接口项目的 PCL条数约
占 5%。
4.4.4 测试检测清单与测试数据
? 测试检测清单针对各种各样的测试分支，
须明确测试的 前提条件、应确认的内容，
明确在何种条件下应有什么样的测试结
果 。
? 每个测试分支都有 编号,以便于实施测
试时记录测试结果。
4.4.4 测试检测清单与测试数据
? 测试结果的记录不仅仅是记录检查合格，
还要记录 测试结果的具体内容 。
? 记录测试结果要注意 易读性,便于他人
追踪测试中发现的问题。
? 根据不同用户的要求，测试内容和测试
结果还有可能作为开发方的系统验证资
料提供给用户。
4.4.4 测试检测清单与测试数据
? 在测试工程的进度管理中，可以按测试
检测清单确定的测试分支作成测试实施
日程，统计已实施测试的分支数，确认
各个测试分支组的测试进度。因此 测试
检测清单 又可以用于 测试进度管理 。
4.4.4 测试检测清单与测试数据
? 作成测试检测清单后，根据测试检测清单记述
的测试分支准备其使用的测试数据。此外，根
据测试分支的覆盖率（正常处理、例外处理
等）、测试分支数，还可 预算 测试工程所需要
的 工数 。
? 测试检测清单格式要根据测试项目的不同而进
行不同的设计。一般都应包括 检查条件、确认
内容、确认日期 等，并且要注意可读性和可实
施性，便于测试者做测试数据，进行测试。
4.4.5 测试前期准备应确认的事项
（ 1）开发环境和测试环境
（ 2）确保必要的测试时间（表 4.5举例说
明了开发日程延后的对策处理方法。）
4.4.5 测试前期准备应确认的事项
（ 3）留有余地的测试计划（回归测试）
? 测试计划时，必须考虑如何利用测试工具等多种手段
有效实施回归测试，并且制定出留有余地的测试计划，
例如，制定精确的测试流程、有效利用测试工具、使
测试尽可能自动化、留有回归测试的时间等。
? 此外，因为变更、修正作业可能诱发新的错误，要根
据测试中发现的问题的重要度、优先顺序进行问题管
理和变更管理。例如，经判断，对于影响度低的问题，
程序的修正可放在测试的最后阶段，由专人集中实施，
以减少变更、修正的工作量和风险。
4.4.5 测试前期准备应确认的事项
（ 4）系统的各个接口是测试工程的关注点
外部接口的测试，应尽量避免在系统测试和运
行测试时才实施。最好是在程序开发工程期间
内，即在单元测试阶段实施接口测试。最初测
试时，只需要确认接口部分的动作，不必要完
成系统整体的逻辑处理。为接口部分的处理准
备简单的程序，专门的测试数据，测试接收和
传送数据的效果。
4.4.5 测试前期准备应确认的事项
? 在考虑测试计划、设计测试方案时要注意以下
几点：
（ 1）在设计工程期间要考虑组合测试计划书；
（ 2）站在用户的立场考虑系统错误、缺陷造成
的影响；
（ 3）结合各种测试方法确定测试流程；
（ 4）搭建必要的测试环境，确定测试工具；
（ 5）将回归测试列入测试计划；
（ 6）作测试计划时要考虑尽早实施接口测试。
4.5 测试的实施
? 在作好测试计划的基础上，确认开发作
业已基本完成，测试工具、数据、环境
等已准备好，就可以进入测试作业。
4.5.1 各个测试阶段的测试设计和实施者
? 单元测试 一般由开发程序的程序员实施。
组合测试 由详细设计者和测试设计者实
施。 系统测试和运行测试 一般由从事系
统设计作业的系统工程师实施，而 运行
测试 不仅仅是由承担开发项目的企业或
部门实施，而且要以用户为主体实施。
表 4.6对各个测试阶段的计划、实施测试
作业者给以了说明。
4.5.2 实施测试的要点
1、实施测试前应确认的事项
? 测试前必须确认系统是否进入测试状态。
? 虽然各个测试阶段有不同的测试重点，
但是对于作为测试对象的软件系统的核
心部分，要尽早实施性能测试，即对软
件系统的效率性进行测试。
4.5.2 实施测试的要点
2、风险意识
? 采用新技术、用户需求变更、开发人员的变动
等都有可能带来风险。
? 风险度 = 发生概率（发生频率） × 发生时的
影响程度（损失）
? 每个开发人员在自己担任的作业中，都应该经
常考虑有可能发生什么样的风险，一旦发现问
题应及时与项目管理者商谈，尽可能避免和防
止风险的发生。
4.5.2 实施测试的要点
3、问题管理
? 在测试中发现错误，修正程序，再测试，
确认修正是否正确，这是一般测试作业
的流程。
? 表 4.7 处理问题的流程
4.5.2 实施测试的要点
? 问题管理的要点如下：
⑴ 设置专人进行问题管理，对发生的问题作最终
判断；
⑵ 对测试结果一定要有记录；
⑶ 作成问题一览表，给每个问题编号，并记录问
题解决的状况；
⑷ 对发生的问题要立即记录，以免遗忘；
⑸ 对问题的记录要注意语言简洁、明确、准确，
同时要记录实施测试时的条件（如测试环境、
测试流程、测试数据）；
4.5.2 实施测试的要点
? ⑹ 如果感觉是很难再现的问题，应马上保留测
试环境、测试数据等，以便分析原因；如果实
施测试者判断是难以用文字表达的问题，要立
即找开发人员或程序修正人员，现场说明；
? ⑺ 问题发现者和处理者都要记录和判断问题的
重要度；
? ⑻ 问题处理者对记录的问题不明白、或认为没
有必要修正程序时，要与测试人员联系、确认；
对判断为不需要修正的问题，一定要说明理由；
4.5.2 实施测试的要点
? ⑼ 修正错误之后。要记录发生问题的现
象和修正的内容；
? ⑽ 修正错误时要注意对同类问题的检查，
不能在程序或系统的其它地方遗留同样
的错误。
4.5.2 实施测试的要点
4、问题记录表
? 记录测试过程中发现的错误、问题。 B票
不仅仅是用于记录错误信息，还可以提
供给质量管理人员、验收人员，作为追
踪、分析、确认软件质量的原始资料，
有利于改进和提高开发质量。
4.5.2 实施测试的要点
? 根据统计规律，一般要求各个测试阶段
发现的错误应占测试对象规模的一定比
例，以确保测试的质量。
4.5.2 实施测试的要点
? B票主要记录如下内容：
⑴ 发生错误的现象，如测试中发生功能遗漏、计
算结果错误、打印错误等等；
⑵ 产生错误的原因，如由于设计不良、理解错误、
编程不良、测试数据错误等原因造成；
⑶ 采取的对应措施，如修正设计书、程序、测试
数据等；
⑷ 发生设计书、程序修正时，记录其修正的范围。
4.5.2 实施测试的要点
5、不再现问题
测试中常发生曾经出现而以后不在出现
的问题，我们常称之为不再现问题。
4.5.2 实施测试的要点
? 一类是问题发生时环境发生了改变，如：
⑴ 测试数据有变化；
⑵ 硬件发生变化；
⑶ 数据库发生变化；
⑷ 操作系统发生变化；
⑸ 某个相关连的程序版本发生变化；
⑹ 其他相关连程序发生故障；
4.5.2 实施测试的要点
⑺ 受内存空间变化的影响；
⑻ 受测试时间、日期变化的影响；
⑼ 运行到某种程度时系统内部发生冲突；
⑽ 系统状态发生变化（初期状态，多次运
行状态）。
上述的 ⑺～⑽ 项属于 间歇性问题,发生的
频度低，但修正很花时间。
4.5.2 实施测试的要点
? 另一类是在完全相同的环境下，由于人
为的原因引起的变化，如：
⑴ 操作顺序发生变化；
⑵ 测试人员未按测试流程进行作业；
⑶ 测试人员变更；
⑷ 无关人员触动了系统。
4.5.2 实施测试的要点
? 在发生 不再现问题 时，首先要对引起不
再现问题的原因进行 分析 。同时，向测
试实施者确认测试时的状况，消除人为
因素，尽可能在问题发生时的相同环境
下进行再次测试，使问题再现。其次是
收集、确认问题发生时的 系统日志, 程
序日志,检查相关连的程序，反复测试
使问题再现。
4.5.2 实施测试的要点
6、测试中发现的错误的水平展开
对测试中发现的错误、缺陷，不能仅限
于对该错误、缺陷的修正，要同时注意
分析程序中是否有其它类似的问题；是
自己的理解错误，还是编程习惯产生的
错误；别的程序是否也有类似的错误等
等。
4.5.2 实施测试的要点
7、版本的管理
? 明确发现的错误是在什么时间的程序版
本上测试的。
? 每个参加测试、修正程序的开发人员要
充分理解开发项目的整体版本管理方法。
4.5.2 实施测试的要点
8、提高测试工程的效率
? 测试工程是需要花费整个开发工程的约
25%～ 50%的工数的工程
? 从外部设计阶段就开始考虑提高质量和
测试规划，直到内部设计阶段考虑整体
的测试方案，逐步形成周密的测试计划。
4.5.2 实施测试的要点
9、防止系统在正式运行中出现故障
? 在正式运行前，要尽可能在接近真实的
数据量、网络环境、终端数量、集中使
用密度等实际环境进行系统性能验证测
试、负荷测试、耐力测试等。
? 在正式运行前，还需要从系统的应用方
面考虑编制操作手册，进行用户培训，
建立技术支持体制。
4.5.2 实施测试的要点
? 确保系统测试成功的一些要点
⑴ 在充分理解用户业务流程的基础上设计测试流
程；
⑵ 在设计测试流程时设想用户容易发生的操作错
误；
⑶ 对参加测试的人员进行相关业务培训，使测试
人员对用户业务有一定的了解；
⑷ 确保系统测试必需要的时间和人员；
⑸ 计划测试日程时要考虑回归测试的时间；
⑹ 活用测试工具，提高测试效率；
4.5.2 实施测试的要点
⑺ 系统测试以开发方为主体，用户为辅，并着手准备运
行测试；
⑻ 系统测试时尽可能使用接近真实的数据；
⑼ 设想正式运行时系统的负荷进行耐力测试；
⑽ 根据可靠性成长曲线（请参见 4.6.2中图 4.24）判断测
试的动向和进度，在出现异常曲线时采取适当的对策；
⑾ 对发现的问题确定优先顺序，从优先顺序高的问题着
手修正；
⑿ 对测试发现的问题根据需要进行水平展开；
⒀ 重视问题管理、设计变更管理和版本管理
4.5.2 实施测试的要点
? 10、测试设计和实施测试中的注意事项
? 表 4.8说明了组合测试、系统测试和运行
测试各个测试阶段的主要测试工作，以
及开始和结束的条件。
? 表 4.9说明了各个测试阶段在测试设计和
测试实施时一般应注意的一些主要问题。
4.5.3 从运行测试到实机运行
1、运行测试的主要特征
⑴ 运行测试以使用者为主体
⑵ 运行测试是进行业务测试
4.5.3 从运行测试到实机运行
2、运行测试的结束
在结束运行测试，进入实机运行时，必须是用
户的所有与系统相关的人员都能够使用该系统。
因此为了确保系统实机运行能够顺利进行，用
户培训是非常必要的。一般在开发计划中应包
括用户培训计划，准备与实际系统接近的培训
系统，在运行测试阶段同时实施用户培训。
4.5.3 从运行测试到实机运行
? 从运行测试到实机运行作以下几点总结：
① 运行测试要以用户为主体进行设计、实施；
② 业务测试是在运行测试阶段实施，而不是在系
统测试阶段实施；
③ 在进行运行测试前作成操作手册；
④ 尽早明确实机运行的评价基准；
⑤ 运行测试的设计、实施要从技术、业务、环境
等多方面考虑；
⑥ 运行测试是用户培训的最好时机。
4.5.4 测试实例说明 --单元测试
? 测试策略
单元测试一般总是把白盒测试法和黑
盒测试法结合运用。先用黑盒测试法设
计出一组基本的测试用例，然后用白盒
测试法，根据覆盖标准补充新的测试用
例以满足覆盖标准。
一般情况下，单元测试以白盒法为主。
4.5.4 测试实例说明 --单元测试
? 主要工作：
? 根据详细设计书作成单元测试使用的程序检测清单（ PCL）
PCL有 矩阵型 PCL 和 表格式 PCL。 无论哪种格式，都有检查项目、
检查条件、确认内容、确认时间等基本内容。作成 PCL的主要
思路是针对详细设计书中的每个功能项目，列出其执行时需
要的条件，确认在相对应的条件下应产生的结果。
? 根据详细设计书和 PCL则可作成测试数据
通常可以用一批数据来测试一个或几个 PCL的检查项目, 一般
不采用一条数据测试一个或几个 PCL。
? 使用问题记录表（ B票）
记录在测试过程中程序发生错误和对错误进行处理的相关信息 。
? 对测试结果进行整理 。在测试结果中需要注明测试的输入数
据和输出数据，并标注相对应的 PCL的检查项目编号 。
4.5.4 测试实例说明 --单元测试
? 测试实例 p120
? 程序检测清单（ PCL）
? 表 4.11是一个矩阵型 PCL p122
? 表 4.12是一个表格式 PCL p123
? 测试数据 P121
问：要完成 PCL中的所有测试项目的测试，
应怎样补充测试 数据？
? 问题记录表（ B票） P125
? 测试结果 P126
4.5.4 测试实例说明 --组合测试
? 组合测试需考虑的问题,
? 数据穿越接口可能丢失。
? 一模块可能破坏另一模块功能。
? 子功能组装可能未产生所要求的主功能。
? 全程数据结构可能出问题。
? 误差累积问题。
? 测试策略
? 由独立的测试小组进行
? 测试用例通常采用黑盒法设计
? 推进方式可采用渐增式或非渐增式
? 模块组合后，应进行回归测试（采用软件改动前测
试时执行过的测试用例对改动后的软件再进行测
试。）
4.5.4 测试实例说明 --组合测试
? 主要工作：
? 测试流程和测试计划 。测试流程的作成，一般可以利用基本
设计的各个子系统的数据流程图，按照各个子系统的输入参
数，自顶向下设计测试流程。同时，要做好测试计划，落实
各个子系统的测试期间、测试人员和验收人员。
? CCL。 CCL的作成 一般以各个子系统的相关联几个程序模块为
单位进行。它主要检测各个程序模块之间的参数设置和传递
是否正确，确认关联程序运行的最后结果。
? 测试数据。 测试数据的作成 要按照 CCL的检查条件进行，一般
要注意多个参数的各种组合条件的测试数据、数据记录条数
(1条或多条 )和特殊条件下的测试数据的做成。当然，基本数
据文件（例如初期设定文件等），各种代码表的数据文件要
事先准备好。
4.5.4 测试实例说明 --组合测试
? 主要工作：
? B票 。 组合测试阶段的 B票作成 方法与单元测试阶段
的 B票作成方法基本相同。其目的是要把测试过程
中所发现的设计不良和程序错误记录到 B票中，以
保证快速有效地解决问题，提高程序系统的质量。
? 测试结果 。 作成测试结果 的目的首先是要使测试人
员和验收人员按照 CCL和测试结果对各个子系统的
功能进行严格检查，其次是要证明所进行的组合测
试是有效的。
4.5.4 测试实例说明 --组合测试
? 测试实例 p127
? 程序检测清单（ CCL）
主要检测各个程序模块之间的参数设置和传递是否正确，
确认关联程序运行的最后结果。
? 表 4.15 CCL清单 p128
? 测试数据 P127
测试数据的作成要按照 CCL的检查条件进行，一般要注意
多个参数的各种组合条件的测试数据、数据记录条数 (1条或
多条 )和特殊条件下的测试数据的做成。当然，基本数据文件
（例如初期设定文件等），各种代码表的数据文件要事先准
备好。
? 问题记录表（ B票）
? 测试结果整理 P129
软件测试与调试
测试与调试的比较
测试 (test) 调试 (debug)
以已知条件开始,
使用预先定义的程序,
有预知的结果
以不可知内部条件开始,结
果一般不可 预见
有计划 被动的
由独立的测试组，在
不了解软件设计的条
件下完成
由程序作者进行
发现错误 找出错误位置，排除
软件调试
? 调试的步骤
? 从错误的外部表现形式着手，确定出错位置；
? 研究有关部分的程序，找出出错的内在原因；
? 修改设计和代码，以排除有关错误；
? 进行回归测试，以确认错误是否排除，是否引起新
的错误；
? 若不能通过回归测试，则撤消此次修改活动，恢复
设计和代码至此次修改之前的状态，并重复上述过
程，直到错误得以改正。
软件调试
? 调试困难的原因
? 心理方面：高度焦虑、不愿接受可能发现的错误
? 错误本身的特点
? 错误症状和引起错误的原因相隔很远（高度耦合的程序结构）；
? 错误症状可能在另一个错误被纠正后消失或暂时消失；
? 错误症状可能实际并不是由错误引起的（如误差）；
? 错误症状可能是由不易跟踪的人工操作引起的；
? 错误症状可能是和时间相关，而不是处理问题；
? 很难再现错误症状的输入条件；
? 错误症状可能时有时无（如在软硬件结合的嵌入式系统中）
? 错误症状可能是由于把任务分布在若干不同处理器上运行而造
成
软件调试
? 调试策略
? 猜测法
通过分析错误症状，根据以往的经验，辅助使用已有的计算
机工具，猜测错误的原因并进行定位。
? 在程序中插入打印语句
? 使用注释或 GOTO语句运行部分程序
? 使用调试工具
? 跟踪法
检查错误征兆，确定最先发现错误, 症状, 的位置，然后人
工沿程序的控制流往回跟踪源代码，直到找出错误的根源；
也可以向前跟踪每条语句的执行情况，找到最先出现错误的
地方进行分析
软件调试
? 调试策略
? 原因排除法, 先假定错误原因，然后利用数据证明
或否定假设（归纳法）；或先列出所有可能的原因，
然后逐一排除。（演绎法）
列举可
能原因
排除不会发
生的原因
收集更多的
测试结果
分析余下
的原因
证
明
假
设
纠
正
错
误
无剩余
有剩余 能
不
能
演绎法调试过程
收集有
关数据
组
织
数
据
研究数
据间的
关系 提出假设
证明假设纠正错误
不能
不能能
能
归纳法调试的过程
4.6 软件质量与测试工程
? 定义
? ANSI/IEEE Std 729-1983定义软件质量为, 与软件产品满足
规定的和隐含的需求的能力有关的特征或特性的全体,
? M.J.Fisher定义软件质量为, 所有描述计算机软件优秀程度的
特性的组合,
? 软件的质量特性
质量特性 说明
1,功能性 按照使用目的, 正确运行 。
2,可靠性 软件运行过程中不会发生突然中断等故障 。
3,使用性 用户容易理解, 学习, 操作 。
4,效率性 具备要求的运行速度和数据, 信息的处理量 。
5,维护性 容易维护和修改 。
6,移植性 容易移植 。
4.6 软件质量与测试工程
? 软件质量反映了以下三方面的内容,
? ⑴ 软件需求是度量软件质量的基础。不符合需
求的软件就不具备质量。
? (2)在各种标准中定义了一些开发准则，用来指
导软件开发人员用工程化的方法来开发软件。
如果不遵守这些开发准则，软件质量就得不到
保证。
? (3)会有一些隐含的需求没有明确地提出来。例
如，软件应具备良好的可维护性。
4.6 软件质量与测试工程
? 提高软件开发质量的基本方法
提高质量
防止发生问题
（早期发现问题）
发现并修正问题（
测试发现问题）
需求定义
概要设计
详细设计
程序制造
测试
4.6 软件质量与测试工程
早期防止问题发生，通常采用 4种做法：（ 1）信息交
流，（ 2）经验积累，（ 3）文档化，（ 4）设计评审
交流信息的方法
定期会议
电视会议
电子传言
利用互联网
信
息
交
流
积累经验的方法
过去做过的项目的再利用
为新项目准备必要的资料
整理开发注意事项和基准
对发现问题采取的对策研讨
经
验
积
累
项目计划书
需求定义书
概要设计书
详细设计书
作业基准, 规范
文
档
化
设计评审
方法会议评审
演示
循环演讲
内容
需求调查责任者以召集会议的形式
进行设计评审对相关人员进行模拟程序运行演示
设计人员分别说明各自设计的内容
设
计
评
审
4.6 软件质量与测试工程
? 测试工程应注意的事项
⑴ 测试工程需要充分的时间和工数；
⑵ 必须保证进入测试工程前的软件开发质量；
⑶ 针对软件的特性考虑软件最重要的质量特性, 确定测
试的优先顺序；
⑷ 进入测试工程后必须采取各种有效措施, 尽最大努力
发现软件的问题和缺陷；
⑸ 利用可靠性成长曲线监视测试的效果和进度；
⑹ 活用业务对象的相关知识、信息技术的知识，扩大视
野规划测试工程。
4.4 测试的前期准备
? 软件测试工程的作业过程可分为 测试设
计 （包括制定测试计划、确定测试方法
等）和 实施测试 两大步骤。
4.4.1测试规划与测试设计
? 对大规模开发系统一般不采用一次性整
体测试，而是从局部依次扩大到整体的
测试，按计划，有步骤地实施测试。一
般从项目需求定义开始，概要设计、详
细设计、程序编码的各个开发阶段，要
进行测试设计，作成测试计划书，还包
括测试作业完成后移植运行作业的计划。
4.4.1测试规划与测试设计
? 表 4.3各开发阶段的测试规划和设计评审
验证内容
4.4.1测试规划与测试设计
? 测试计划书一般包括如下的一些的内容：
（ 1）测试工程概要、测试场所、测试方针
（ 2）测试日程和实施体制
4.4.1测试规划与测试设计
（ 3）测试管理方法
·测试工具
·测试环境
·测试检测清单
·验证方法
·版本管理方法
·进度管理方法
·问题管理方法
·回归测试方法
·设计变更管理方法
4.4.1测试规划与测试设计
（ 4）针对各阶段的测试应明确的事项
·阶段测试的目的和范围
·阶段测试开始和测试终止的基准
·阶段测试检测清单
·阶段测试实施日程和实施体制
·阶段测试的验收基准和方法
4.4.2 了解系统错误、缺陷的影响度
? 信息系统的测试很难实现在与实际运行
环境（数据、使用者、硬件、时间、网
络、系统负荷等）完全一致的条件下进
行的测试。
? 在做测试计划和测试设计时，充分理解
软件的错误、缺陷对用户将会造成什么
样的影响是很重要的。
4.4.2 了解系统错误、缺陷的影响度
? 软件中即使是很微小的错误，有可能会
给用户造成重大的损害和影响。
4.4.2 了解系统错误、缺陷的影响度
? 下图是系统缺陷对一个生产型企业的各
个方面所产生的影响
业务
混乱
系统缺
陷
丧失顾
客信任
经济损
失
不可能
恢复的
数据
业务停
止
不能回答用户的咨
询
送货发生错误
交付期延迟
不能处理用户订货
断货
业务状况不明
不能检索信息
不能进行业务指示
产品报废
业务效率降低
发生手工作业
发生返工
用户信息
产品信息
设计信息
销售信息
生产信息
4.4.3利用各种测试支持工具
? 测试工具：
⑴ 作为定型测试，反复实施测试作业的支持工具；
⑵ 确定测试分支、生成测试数据的支持工具；
⑶ 验证测试的覆盖率，提高测试效率的工具；
⑷ 性能测试的支持工具；
⑸ 管理与测试相关连项目的支持工具；
⑹ 变更管理、版本管理的支持工具；
⑺ 检测错误作业的支持工具。
4.4.3利用各种测试支持工具
? 表 4.4 部分常用的测试支持工具
常用测试工具
? Mercury Interactive
? WinRunner-----功能：
1.插入检查点；
2.检验数据；
3.增强测试；
4.分析结果；
5.维护测试；、
６,为无线应用作准备。
? 范围：功能测试、生成测试用例、分析测试结果、
维护测试用例、回归测试。
常用测试工具
? LoadRunner-----功能：
1.松创建虚拟用户；
2.创建真实的负载；
3.定位性能问题；
4.分析结果以精确定位问题所在；
5.重复测试保证系统发布的高性能；
6.Enterprise Java Beans的测试；
7.支持无线应用协议；
8.支持 Media Stream应用；
9.完整的企业应用环境的支持。
? 范围：性能测试、压力测试、模拟多用户、定位性能瓶颈
常用测试工具
? TestDirector------功能：
1．需求管理 ;
2,计划测试 ;
3,安排和执行测试 ;
4,缺陷管理 ;
5,图形化和报表输出 ;
? 范围：测试管理工具
常用测试工具
? Rational系列
? Rational Purify （测试时用，检查运行时内
存错误） ;
? Rational Quantify（性能检测工具，查出系
统瓶颈以便改进运行速度） ;
? Rational TestManager （测试管理） ;
4.4.4 测试检测清单与测试数据
? 根据测试计划，按各个测试阶段的目的
准备实施测试使用的检测清单和测试使
用的数据。
4.4.4 测试检测清单与测试数据
? 如单元（模块）测试阶段的程序检测清
单称为 PCL，组合测试阶段的检测清单称
为 CCL，系统测试阶段的检测清单称为
SCL。
4.4.4 测试检测清单与测试数据
? 在测试中需要验证的项目及其判别、制
约条件必须全部记入 检测清单 。
4.4.4 测试检测清单与测试数据
? 例如单元测试的程序检测清单 PCL要明确
以下几个方面内容：
⑴ 窗体显示的输入、输出项目及判别条件；
⑵ 输出表格印刷输出项目及判别条件；
⑶ 数据库 /文件输入、输出项目及判别条
件；
⑷ 程序间传递的数据、信息及判别条件。
4.4.4 测试检测清单与测试数据
? 作成检测清单应遵循如下的原则：
⑴ 具体性,判别条件和确认内容必须是在
测试结果中可确认的；
⑵ 完整性,检测内容必须是包含设计书中
的所有项目、功能；
⑶ 有一定的密度,检测点占测试对象的一
定比例。
4.4.4 测试检测清单与测试数据
⑷ 有一定的 分布率,如 PCL对正常、异常、临界
处理及模块间接口数据、信息传输的检测一般
按如下比率分配：
① 检测正常分支的 PCL条数约占 70%；
② 检测异常分支的 PCL条数约占 10%；
③ 检测边界、临界项目的 PCL条数约占 15%；
④ 检测关联模块间传递、接口项目的 PCL条数约
占 5%。
4.4.4 测试检测清单与测试数据
? 测试检测清单针对各种各样的测试分支，
须明确测试的 前提条件、应确认的内容，
明确在何种条件下应有什么样的测试结
果 。
? 每个测试分支都有 编号,以便于实施测
试时记录测试结果。
4.4.4 测试检测清单与测试数据
? 测试结果的记录不仅仅是记录检查合格，
还要记录 测试结果的具体内容 。
? 记录测试结果要注意 易读性,便于他人
追踪测试中发现的问题。
? 根据不同用户的要求，测试内容和测试
结果还有可能作为开发方的系统验证资
料提供给用户。
4.4.4 测试检测清单与测试数据
? 在测试工程的进度管理中，可以按测试
检测清单确定的测试分支作成测试实施
日程，统计已实施测试的分支数，确认
各个测试分支组的测试进度。因此 测试
检测清单 又可以用于 测试进度管理 。
4.4.4 测试检测清单与测试数据
? 作成测试检测清单后，根据测试检测清单记述
的测试分支准备其使用的测试数据。此外，根
据测试分支的覆盖率（正常处理、例外处理
等）、测试分支数，还可 预算 测试工程所需要
的 工数 。
? 测试检测清单格式要根据测试项目的不同而进
行不同的设计。一般都应包括 检查条件、确认
内容、确认日期 等，并且要注意可读性和可实
施性，便于测试者做测试数据，进行测试。
4.4.5 测试前期准备应确认的事项
（ 1）开发环境和测试环境
（ 2）确保必要的测试时间（表 4.5举例说
明了开发日程延后的对策处理方法。）
4.4.5 测试前期准备应确认的事项
（ 3）留有余地的测试计划（回归测试）
? 测试计划时，必须考虑如何利用测试工具等多种手段
有效实施回归测试，并且制定出留有余地的测试计划，
例如，制定精确的测试流程、有效利用测试工具、使
测试尽可能自动化、留有回归测试的时间等。
? 此外，因为变更、修正作业可能诱发新的错误，要根
据测试中发现的问题的重要度、优先顺序进行问题管
理和变更管理。例如，经判断，对于影响度低的问题，
程序的修正可放在测试的最后阶段，由专人集中实施，
以减少变更、修正的工作量和风险。
4.4.5 测试前期准备应确认的事项
（ 4）系统的各个接口是测试工程的关注点
外部接口的测试，应尽量避免在系统测试和运
行测试时才实施。最好是在程序开发工程期间
内，即在单元测试阶段实施接口测试。最初测
试时，只需要确认接口部分的动作，不必要完
成系统整体的逻辑处理。为接口部分的处理准
备简单的程序，专门的测试数据，测试接收和
传送数据的效果。
4.4.5 测试前期准备应确认的事项
? 在考虑测试计划、设计测试方案时要注意以下
几点：
（ 1）在设计工程期间要考虑组合测试计划书；
（ 2）站在用户的立场考虑系统错误、缺陷造成
的影响；
（ 3）结合各种测试方法确定测试流程；
（ 4）搭建必要的测试环境，确定测试工具；
（ 5）将回归测试列入测试计划；
（ 6）作测试计划时要考虑尽早实施接口测试。
4.5 测试的实施
? 在作好测试计划的基础上，确认开发作
业已基本完成，测试工具、数据、环境
等已准备好，就可以进入测试作业。
4.5.1 各个测试阶段的测试设计和实施者
? 单元测试 一般由开发程序的程序员实施。
组合测试 由详细设计者和测试设计者实
施。 系统测试和运行测试 一般由从事系
统设计作业的系统工程师实施，而 运行
测试 不仅仅是由承担开发项目的企业或
部门实施，而且要以用户为主体实施。
表 4.6对各个测试阶段的计划、实施测试
作业者给以了说明。
4.5.2 实施测试的要点
1、实施测试前应确认的事项
? 测试前必须确认系统是否进入测试状态。
? 虽然各个测试阶段有不同的测试重点，
但是对于作为测试对象的软件系统的核
心部分，要尽早实施性能测试，即对软
件系统的效率性进行测试。
4.5.2 实施测试的要点
2、风险意识
? 采用新技术、用户需求变更、开发人员的变动
等都有可能带来风险。
? 风险度 = 发生概率（发生频率） × 发生时的
影响程度（损失）
? 每个开发人员在自己担任的作业中，都应该经
常考虑有可能发生什么样的风险，一旦发现问
题应及时与项目管理者商谈，尽可能避免和防
止风险的发生。
4.5.2 实施测试的要点
3、问题管理
? 在测试中发现错误，修正程序，再测试，
确认修正是否正确，这是一般测试作业
的流程。
? 表 4.7 处理问题的流程
4.5.2 实施测试的要点
? 问题管理的要点如下：
⑴ 设置专人进行问题管理，对发生的问题作最终
判断；
⑵ 对测试结果一定要有记录；
⑶ 作成问题一览表，给每个问题编号，并记录问
题解决的状况；
⑷ 对发生的问题要立即记录，以免遗忘；
⑸ 对问题的记录要注意语言简洁、明确、准确，
同时要记录实施测试时的条件（如测试环境、
测试流程、测试数据）；
4.5.2 实施测试的要点
? ⑹ 如果感觉是很难再现的问题，应马上保留测
试环境、测试数据等，以便分析原因；如果实
施测试者判断是难以用文字表达的问题，要立
即找开发人员或程序修正人员，现场说明；
? ⑺ 问题发现者和处理者都要记录和判断问题的
重要度；
? ⑻ 问题处理者对记录的问题不明白、或认为没
有必要修正程序时，要与测试人员联系、确认；
对判断为不需要修正的问题，一定要说明理由；
4.5.2 实施测试的要点
? ⑼ 修正错误之后。要记录发生问题的现
象和修正的内容；
? ⑽ 修正错误时要注意对同类问题的检查，
不能在程序或系统的其它地方遗留同样
的错误。
4.5.2 实施测试的要点
4、问题记录表
? 记录测试过程中发现的错误、问题。 B票
不仅仅是用于记录错误信息，还可以提
供给质量管理人员、验收人员，作为追
踪、分析、确认软件质量的原始资料，
有利于改进和提高开发质量。
4.5.2 实施测试的要点
? 根据统计规律，一般要求各个测试阶段
发现的错误应占测试对象规模的一定比
例，以确保测试的质量。
4.5.2 实施测试的要点
? B票主要记录如下内容：
⑴ 发生错误的现象，如测试中发生功能遗漏、计
算结果错误、打印错误等等；
⑵ 产生错误的原因，如由于设计不良、理解错误、
编程不良、测试数据错误等原因造成；
⑶ 采取的对应措施，如修正设计书、程序、测试
数据等；
⑷ 发生设计书、程序修正时，记录其修正的范围。
4.5.2 实施测试的要点
5、不再现问题
测试中常发生曾经出现而以后不在出现
的问题，我们常称之为不再现问题。
4.5.2 实施测试的要点
? 一类是问题发生时环境发生了改变，如：
⑴ 测试数据有变化；
⑵ 硬件发生变化；
⑶ 数据库发生变化；
⑷ 操作系统发生变化；
⑸ 某个相关连的程序版本发生变化；
⑹ 其他相关连程序发生故障；
4.5.2 实施测试的要点
⑺ 受内存空间变化的影响；
⑻ 受测试时间、日期变化的影响；
⑼ 运行到某种程度时系统内部发生冲突；
⑽ 系统状态发生变化（初期状态，多次运
行状态）。
上述的 ⑺～⑽ 项属于 间歇性问题,发生的
频度低，但修正很花时间。
4.5.2 实施测试的要点
? 另一类是在完全相同的环境下，由于人
为的原因引起的变化，如：
⑴ 操作顺序发生变化；
⑵ 测试人员未按测试流程进行作业；
⑶ 测试人员变更；
⑷ 无关人员触动了系统。
4.5.2 实施测试的要点
? 在发生 不再现问题 时，首先要对引起不
再现问题的原因进行 分析 。同时，向测
试实施者确认测试时的状况，消除人为
因素，尽可能在问题发生时的相同环境
下进行再次测试，使问题再现。其次是
收集、确认问题发生时的 系统日志, 程
序日志,检查相关连的程序，反复测试
使问题再现。
4.5.2 实施测试的要点
6、测试中发现的错误的水平展开
对测试中发现的错误、缺陷，不能仅限
于对该错误、缺陷的修正，要同时注意
分析程序中是否有其它类似的问题；是
自己的理解错误，还是编程习惯产生的
错误；别的程序是否也有类似的错误等
等。
4.5.2 实施测试的要点
7、版本的管理
? 明确发现的错误是在什么时间的程序版
本上测试的。
? 每个参加测试、修正程序的开发人员要
充分理解开发项目的整体版本管理方法。
4.5.2 实施测试的要点
8、提高测试工程的效率
? 测试工程是需要花费整个开发工程的约
25%～ 50%的工数的工程
? 从外部设计阶段就开始考虑提高质量和
测试规划，直到内部设计阶段考虑整体
的测试方案，逐步形成周密的测试计划。
4.5.2 实施测试的要点
9、防止系统在正式运行中出现故障
? 在正式运行前，要尽可能在接近真实的
数据量、网络环境、终端数量、集中使
用密度等实际环境进行系统性能验证测
试、负荷测试、耐力测试等。
? 在正式运行前，还需要从系统的应用方
面考虑编制操作手册，进行用户培训，
建立技术支持体制。
4.5.2 实施测试的要点
? 确保系统测试成功的一些要点
⑴ 在充分理解用户业务流程的基础上设计测试流
程；
⑵ 在设计测试流程时设想用户容易发生的操作错
误；
⑶ 对参加测试的人员进行相关业务培训，使测试
人员对用户业务有一定的了解；
⑷ 确保系统测试必需要的时间和人员；
⑸ 计划测试日程时要考虑回归测试的时间；
⑹ 活用测试工具，提高测试效率；
4.5.2 实施测试的要点
⑺ 系统测试以开发方为主体，用户为辅，并着手准备运
行测试；
⑻ 系统测试时尽可能使用接近真实的数据；
⑼ 设想正式运行时系统的负荷进行耐力测试；
⑽ 根据可靠性成长曲线（请参见 4.6.2中图 4.24）判断测
试的动向和进度，在出现异常曲线时采取适当的对策；
⑾ 对发现的问题确定优先顺序，从优先顺序高的问题着
手修正；
⑿ 对测试发现的问题根据需要进行水平展开；
⒀ 重视问题管理、设计变更管理和版本管理
4.5.2 实施测试的要点
? 10、测试设计和实施测试中的注意事项
? 表 4.8说明了组合测试、系统测试和运行
测试各个测试阶段的主要测试工作，以
及开始和结束的条件。
? 表 4.9说明了各个测试阶段在测试设计和
测试实施时一般应注意的一些主要问题。
4.5.3 从运行测试到实机运行
1、运行测试的主要特征
⑴ 运行测试以使用者为主体
⑵ 运行测试是进行业务测试
4.5.3 从运行测试到实机运行
2、运行测试的结束
在结束运行测试，进入实机运行时，必须是用
户的所有与系统相关的人员都能够使用该系统。
因此为了确保系统实机运行能够顺利进行，用
户培训是非常必要的。一般在开发计划中应包
括用户培训计划，准备与实际系统接近的培训
系统，在运行测试阶段同时实施用户培训。
4.5.3 从运行测试到实机运行
? 从运行测试到实机运行作以下几点总结：
① 运行测试要以用户为主体进行设计、实施；
② 业务测试是在运行测试阶段实施，而不是在系
统测试阶段实施；
③ 在进行运行测试前作成操作手册；
④ 尽早明确实机运行的评价基准；
⑤ 运行测试的设计、实施要从技术、业务、环境
等多方面考虑；
⑥ 运行测试是用户培训的最好时机。
4.5.4 测试实例说明 --单元测试
? 测试策略
单元测试一般总是把白盒测试法和黑
盒测试法结合运用。先用黑盒测试法设
计出一组基本的测试用例，然后用白盒
测试法，根据覆盖标准补充新的测试用
例以满足覆盖标准。
一般情况下，单元测试以白盒法为主。
4.5.4 测试实例说明 --单元测试
? 主要工作：
? 根据详细设计书作成单元测试使用的程序检测清单（ PCL）
PCL有 矩阵型 PCL 和 表格式 PCL。 无论哪种格式，都有检查项目、
检查条件、确认内容、确认时间等基本内容。作成 PCL的主要
思路是针对详细设计书中的每个功能项目，列出其执行时需
要的条件，确认在相对应的条件下应产生的结果。
? 根据详细设计书和 PCL则可作成测试数据
通常可以用一批数据来测试一个或几个 PCL的检查项目, 一般
不采用一条数据测试一个或几个 PCL。
? 使用问题记录表（ B票）
记录在测试过程中程序发生错误和对错误进行处理的相关信息 。
? 对测试结果进行整理 。在测试结果中需要注明测试的输入数
据和输出数据，并标注相对应的 PCL的检查项目编号 。
4.5.4 测试实例说明 --单元测试
? 测试实例 p120
? 程序检测清单（ PCL）
? 表 4.11是一个矩阵型 PCL p122
? 表 4.12是一个表格式 PCL p123
? 测试数据 P121
问：要完成 PCL中的所有测试项目的测试，
应怎样补充测试 数据？
? 问题记录表（ B票） P125
? 测试结果 P126
4.5.4 测试实例说明 --组合测试
? 组合测试需考虑的问题,
? 数据穿越接口可能丢失。
? 一模块可能破坏另一模块功能。
? 子功能组装可能未产生所要求的主功能。
? 全程数据结构可能出问题。
? 误差累积问题。
? 测试策略
? 由独立的测试小组进行
? 测试用例通常采用黑盒法设计
? 推进方式可采用渐增式或非渐增式
? 模块组合后，应进行回归测试（采用软件改动前测
试时执行过的测试用例对改动后的软件再进行测
试。）
4.5.4 测试实例说明 --组合测试
? 主要工作：
? 测试流程和测试计划 。测试流程的作成，一般可以利用基本
设计的各个子系统的数据流程图，按照各个子系统的输入参
数，自顶向下设计测试流程。同时，要做好测试计划，落实
各个子系统的测试期间、测试人员和验收人员。
? CCL。 CCL的作成 一般以各个子系统的相关联几个程序模块为
单位进行。它主要检测各个程序模块之间的参数设置和传递
是否正确，确认关联程序运行的最后结果。
? 测试数据。 测试数据的作成 要按照 CCL的检查条件进行，一般
要注意多个参数的各种组合条件的测试数据、数据记录条数
(1条或多条 )和特殊条件下的测试数据的做成。当然，基本数
据文件（例如初期设定文件等），各种代码表的数据文件要
事先准备好。
4.5.4 测试实例说明 --组合测试
? 主要工作：
? B票 。 组合测试阶段的 B票作成 方法与单元测试阶段
的 B票作成方法基本相同。其目的是要把测试过程
中所发现的设计不良和程序错误记录到 B票中，以
保证快速有效地解决问题，提高程序系统的质量。
? 测试结果 。 作成测试结果 的目的首先是要使测试人
员和验收人员按照 CCL和测试结果对各个子系统的
功能进行严格检查，其次是要证明所进行的组合测
试是有效的。
4.5.4 测试实例说明 --组合测试
? 测试实例 p127
? 程序检测清单（ CCL）
主要检测各个程序模块之间的参数设置和传递是否正确，
确认关联程序运行的最后结果。
? 表 4.15 CCL清单 p128
? 测试数据 P127
测试数据的作成要按照 CCL的检查条件进行，一般要注意
多个参数的各种组合条件的测试数据、数据记录条数 (1条或
多条 )和特殊条件下的测试数据的做成。当然，基本数据文件
（例如初期设定文件等），各种代码表的数据文件要事先准
备好。
? 问题记录表（ B票）
? 测试结果整理 P129
软件测试与调试
测试与调试的比较
测试 (test) 调试 (debug)
以已知条件开始,
使用预先定义的程序,
有预知的结果
以不可知内部条件开始,结
果一般不可 预见
有计划 被动的
由独立的测试组，在
不了解软件设计的条
件下完成
由程序作者进行
发现错误 找出错误位置，排除
软件调试
? 调试的步骤
? 从错误的外部表现形式着手，确定出错位置；
? 研究有关部分的程序，找出出错的内在原因；
? 修改设计和代码，以排除有关错误；
? 进行回归测试，以确认错误是否排除，是否引起新
的错误；
? 若不能通过回归测试，则撤消此次修改活动，恢复
设计和代码至此次修改之前的状态，并重复上述过
程，直到错误得以改正。
软件调试
? 调试困难的原因
? 心理方面：高度焦虑、不愿接受可能发现的错误
? 错误本身的特点
? 错误症状和引起错误的原因相隔很远（高度耦合的程序结构）；
? 错误症状可能在另一个错误被纠正后消失或暂时消失；
? 错误症状可能实际并不是由错误引起的（如误差）；
? 错误症状可能是由不易跟踪的人工操作引起的；
? 错误症状可能是和时间相关，而不是处理问题；
? 很难再现错误症状的输入条件；
? 错误症状可能时有时无（如在软硬件结合的嵌入式系统中）
? 错误症状可能是由于把任务分布在若干不同处理器上运行而造
成
软件调试
? 调试策略
? 猜测法
通过分析错误症状，根据以往的经验，辅助使用已有的计算
机工具，猜测错误的原因并进行定位。
? 在程序中插入打印语句
? 使用注释或 GOTO语句运行部分程序
? 使用调试工具
? 跟踪法
检查错误征兆，确定最先发现错误, 症状, 的位置，然后人
工沿程序的控制流往回跟踪源代码，直到找出错误的根源；
也可以向前跟踪每条语句的执行情况，找到最先出现错误的
地方进行分析
软件调试
? 调试策略
? 原因排除法, 先假定错误原因，然后利用数据证明
或否定假设（归纳法）；或先列出所有可能的原因，
然后逐一排除。（演绎法）
列举可
能原因
排除不会发
生的原因
收集更多的
测试结果
分析余下
的原因
证
明
假
设
纠
正
错
误
无剩余
有剩余 能
不
能
演绎法调试过程
收集有
关数据
组
织
数
据
研究数
据间的
关系 提出假设
证明假设纠正错误
不能
不能能
能
归纳法调试的过程
4.6 软件质量与测试工程
? 定义
? ANSI/IEEE Std 729-1983定义软件质量为, 与软件产品满足
规定的和隐含的需求的能力有关的特征或特性的全体,
? M.J.Fisher定义软件质量为, 所有描述计算机软件优秀程度的
特性的组合,
? 软件的质量特性
质量特性 说明
1,功能性 按照使用目的, 正确运行 。
2,可靠性 软件运行过程中不会发生突然中断等故障 。
3,使用性 用户容易理解, 学习, 操作 。
4,效率性 具备要求的运行速度和数据, 信息的处理量 。
5,维护性 容易维护和修改 。
6,移植性 容易移植 。
4.6 软件质量与测试工程
? 软件质量反映了以下三方面的内容,
? ⑴ 软件需求是度量软件质量的基础。不符合需
求的软件就不具备质量。
? (2)在各种标准中定义了一些开发准则，用来指
导软件开发人员用工程化的方法来开发软件。
如果不遵守这些开发准则，软件质量就得不到
保证。
? (3)会有一些隐含的需求没有明确地提出来。例
如，软件应具备良好的可维护性。
4.6 软件质量与测试工程
? 提高软件开发质量的基本方法
提高质量
防止发生问题
（早期发现问题）
发现并修正问题（
测试发现问题）
需求定义
概要设计
详细设计
程序制造
测试
4.6 软件质量与测试工程
早期防止问题发生，通常采用 4种做法：（ 1）信息交
流，（ 2）经验积累，（ 3）文档化，（ 4）设计评审
交流信息的方法
定期会议
电视会议
电子传言
利用互联网
信
息
交
流
积累经验的方法
过去做过的项目的再利用
为新项目准备必要的资料
整理开发注意事项和基准
对发现问题采取的对策研讨
经
验
积
累
项目计划书
需求定义书
概要设计书
详细设计书
作业基准, 规范
文
档
化
设计评审
方法会议评审
演示
循环演讲
内容
需求调查责任者以召集会议的形式
进行设计评审对相关人员进行模拟程序运行演示
设计人员分别说明各自设计的内容
设
计
评
审
4.6 软件质量与测试工程
? 测试工程应注意的事项
⑴ 测试工程需要充分的时间和工数；
⑵ 必须保证进入测试工程前的软件开发质量；
⑶ 针对软件的特性考虑软件最重要的质量特性, 确定测
试的优先顺序；
⑷ 进入测试工程后必须采取各种有效措施, 尽最大努力
发现软件的问题和缺陷；
⑸ 利用可靠性成长曲线监视测试的效果和进度；
⑹ 活用业务对象的相关知识、信息技术的知识，扩大视
野规划测试工程。
