软件测试规范

软件测试规范

由安博测试空间技术中心提供

目录

一、简介........................................................................3

（一）软件测试的定义............................................................3

（二）软件测试类型的划分........................................................3

（三）测试中权衡的三个重要维度..................................................4

（四）不同阶段测试精度的把握....................................................4

（五）测试顺序..................................................................4

二、测试工作流程................................................................5

（一）测试准备..................................................................5

（二）测试的实施................................................................5

（三）测试问题处理流程..........................................................7

（四）测试验收..................................................................8

（五）测试总结..................................................................8

三、测试人员的组织与培训........................................................8

（一）测试人员的组织............................................................8

（二）测试人员的培训...........................................................10

四、测试工作机制一会议与讨论...................................................11

（一）测试工作启动会议.........................................................11

（二）阶段性会议...............................................................11

（三）专题会议.................................................................12

（四）讨论.....................................................................12

五、测试案例的编写.............................................................12

（一）案例编写的原则...........................................................12

（二）测试案例的取舍...........................................................13

六、测试相关文档...............................................................14

（一）测试计划书...............................................................14

（二）测试方案书...............................................................15

（三）测试报告.................................................................17

（四）其他文档资料.............................................................18

一、简介

(一)软件测试的定义

软件测试的定义是“为了发现程序中的错误而执行程序的过程”，具体地说，软件测试

是根据软件开发的产品设计说明书和程序的内部结构而精心设计出一批测试案例，并利用测

试案例来运行程序，以发现程序错误的过程。

(二)软件测试类型的划分

软件测试贯穿于整个开发过程中，软件系统的开发过程是一个自顶向下逐步细化的过

程，而测试过程则是按相反顺序逆行的集成过程，根据测试的阶段、测试的执行人，可划分

为：单元测试(unittesting)>组合测试(incrementalintegrationtesting)、集成测试

(integrationtesting)、系统测试(systemtesting)、用户验收测试。根据测试内容的不

同可分为:功能测试(functionaltesting)>安全性测试(securitytesting)、恢复测试

(recoverytesting),兼容性测试(硬件兼容、版本兼容)、容错性测试、性能/压力/负载

测试(performance/stress/loadtesting)、安装/卸载测试(install/uninstall

testing)在本文中，我们使用测试阶段的划分标准。

图一:软件生命周期“台阶”模型图：

（三）测试中权衡的三个重要维度

测试时间、测试成本和测试质量构成测试过程中需要关注的三个重要维度，三个维度相

互制约、相互影响。在测试中，永远无法实现时间、成本和质量的三赢，为其中任何2个目

标所做的努力，都必须以付出第三个目标的损失为代价，此外我们永远都不可能穷尽所有的

测试内容。因此必须综合权衡作出取舍。

图二：制约测试的三个要素

（四）不同阶段测试精度的把握

考虑到测试时间、测试成本的制约，在不同的测试阶段，对测试精度有不同的要求。从

单元测试、集成测试到系统测试、用户验收测试阶段，对测试精度的要求也呈现一个从粗到

细的过程。单元测试是发现错误最多、预防质量隐患最重要的测试阶段，需要最大的测试精

度，缺少单元测试，宜接进行集成和系统测试，缺陷隐患多。

图三：不同测试阶段测试精度模型图

单元测试集成测试系统测试用户验收测试

工程安装测试

（五）测试顺序

对于一项复杂产品的测试，遵循一定的测试顺序，可以是测试工作有条不紊，提高测试

工作效率。同时按照一定的测试顺序展开测试，一定程度上可以确保测试工作的全面性。

测试顺序的原则是由浅入深、由易而难。在具体的测试内容上表现为：

•先联机测试后批量测试；

・首先单元测试，其次集成测试，然后进行系统测试及验收测试；

•先进行基本功能测试再进行辅助功能测试；

・先进行正常情况案例的测试，再进行反常情况案例的测试；

•对于一项交易先进行输入项的测试,再进行输出项的测试,然后进行账务处理的测试。

二、测试工作流程

(一)测试准备

在技术实现编码阶段的工作结束时，进入产品的测试准备阶段，为真正开展产品测试

做好前期准备工作。

测试准备阶段的主要工作包括制定测试工作计•划、设计测试方案、组织协调测试人员、

测试所需硬件设施等其他准备工作。测试准备阶段的工作由参加产品设计说明书的主创人员

负责完成。

1、制定测试工作计划和测试方案

相关内容见测试文档编写

2、组织协调测试人员

根据测试计划和测试方案，组织协调相关人员，形成测试工作组。

3、测试人员的培训

正式开展测试工作之前，对所有测试人员进行测试工作的集中培训。通过测试培训，

使测试人员明确测试目标和要求、了解待测系统、统一测试方法和流程，保质保量的开展和

进行测试工作。

4、测试所需要硬件设施和其他准备工作

与相关部门联系协调对测试工作所需的设施：服务器、测试机等在测试准备阶段全部

到位。

(-)测试的实施

测试实施是软件测试工作的核心阶段，测试实施阶段严格按照测试计划和测试方案展

开。

1、搭建测试环境

根据产品的实际需要搭建的运行环境及准备相关测试所需初始数据。包括：测试人员、

测试工具等。

2、单元测试

单元编码完成后，进行单元测试。单元测试指构建者的角度出发，检测产品的各个部分

是否是正常、合理、安全的，换句话说，就是通过检测要保证软件产品满足用户操作的质量

标准。

单元测试关注的重点是产品的内部结构、框架以及技术实现是否符合产品设计说明书等

等。

单元测试可以并行进行。对于彼此独立的单元，进行并行测试可以加速测试的进程。

单元测试按照测试进程可分为联机功能测试和批量功能测试两个阶段，其中批量测试阶

段需要建立手工账，以便于同系统处理结果相互核对。

3、集成测试

集成测试在所有单元测试完成之后进行。集成测试也称综合测试，即将已分别通过测试

的单元按要求组合起来再进行的测试，以检查这些单元之间的接口是否存在问题。或按设计

要求把通过单元测试的各个模块组装在一起之后，进行测试以便发现与接口有关的各种错

误。

集成测试的重点是各个模块之间的接口的功能进行测试。

4、系统测试

系统测试是整个测试阶段的最后一步，所有的开发和测试在这一点上，集中表现为生成

一个具有一定功能的软件系统，整个系统开发完成，即将交付用户使用。

系统测试主要对系统的准确性及完整性等方面进行测试。分别进行：运行测试、强度测

试、恢复测试、安全性测试等。

目前系统测试的主要工作由技术人员完成，业务测试人员协助工作。

5、需求维护

需求维护指测试过程中根据每项测试结果发现前期需求不合理之处并对其进行相应的

调整和改正。

需求维护工作贯穿整个测试过程。

测试阶段的需求维护工作是整个产品产生过程中需求维护工作的一部分。

（三）测试问题处理流程

测试问题处理流程可以采用以下两种形式

形式1:

形式1与形式2之间的主要差别在于测试问题的分析流程，形式一由开发人员对测试问

题统一分析，查明原因后交给相应的人员解决修改；形式二业务人员在测试中发现问题后，

继而分析问题缘由，由测试人员将问题交给相应人员解决修改。

（四）测试验收

测试验收阶段的主要工作是：以客户使用的角度，再次确认系统的可操作性、正确性、

全面性和完整性。为产品的上线应用、推广营销最后把关。

测试验收工作相关业务由上海总部及西安研发部共同组织人员负责。

测试验收阶段依旧沿袭测试实施阶段使用到的各种测试形式和方法，依据测试实施阶段

产生的测试问题报告单、交易记账凭证、报表、测试案例单、阶段性测试总结等各种文档和

资料展开。

（五）测试总结

测试总结阶段是测试工作的最后一个阶段，要进行以下四项工作：

1、对测试阶段工作完成情况、工作方法进行总结。

一方面总结好的方法和经验用于指导将来的测试工作；另一方面发现不足需改进之处，

引起借鉴，并在今后的工作中加以避免。

2、对测试验收阶段的遗留问题的进行汇总、统计和分析，并提出解决和修改建议。

3、整理文档。

包括：产品设计说明书最终版本、产品培训教材、产品操作手册以及测试阶段生成的各

种文档资料。

4、编写测试报告。

详见相关测试文档规范。

三、测试人员的组织与培训

（一）测试人员的组织

1、具体组织形式

测试T作的组织形式分为项目经理、测试组、支持组0项目经理自责全面地组织和协调

工作。测试的工作实体(最小组织单位)是测试组和支持组，分别设组长全权负责。测试组由

测试人员组成，负责测试案例的编写、具体的测试操作、测试问题的记录与反馈，以及对己

修改问题的回归测试和验收等工作。根据测试工作内容的具体需求，测试组可以按照业务种

类或其他分为若干小组开展工作。支持组由朱莉负责主要工作是测试的后勤保障和日常管理

工作，如网络管理、数据备份、文档管理、设备管理和维护、日常事务管理和检查等。

2、主要职责

(1)项目经理(李永平)

职责：

①拟定产品测试阶段的总体工作思路、测试方案等。

②产品测试阶段测试人员、支持人员的组织工作。

③把握工作进度，监督、控制、督促产品测试工作按计划进行。

④对测试组和支持组的工作进行必要的沟通和协调，建立测试组与支持组相互配合、

支持、协作的桥梁。

⑤对产品测试阶段工作的总结和评估；包括分阶段性工作、总体工作的总结与评估。

©与相关部门就测试工作所需的软、硬件设施进行沟通和协调：如：测试工作场地、

网络环境、所需设施、其他凭证、报表等。

⑦参与产品测试阶段的具体测试工作。

(2)测试组组长

职责：

①拟定产品测试阶段的总体工作思路、测试计划、测试方案等。

②组织本组测试人员的开展本组负责的测试工作，包括组员的工作安排、工作检查和

问题反馈等。

③把握工作进度，监督、控制、督促本组测试工作按计划进行。

④与支持组互相配合、支持、协作。

⑤对测试组工作的总结和评估；包括分阶段性工作、总体工作的总结与评估。

⑥对产品测试中发现的问题总结、分析，形成问题报告单，与支持组进行沟通。

⑦参与产品测试阶段的具体测试工作。

（3）支持组

职责：

①对测试组的测试工作进行业务、技术以及后勤设备各方面的支持。

②与测试组互相配合、支持、协作。

③日常测试支持性工作。

④参与产品测试阶段的具体支持工作。

（4）测试人员

职责：

①根据测试方案编写测试案例。

②按照测试计划开展所负责的测试工作。

③提交问题，协助测试组长完成问题报告单。

④测试作中需求的解群和维护_L作。

⑤配合测试组长对测试阶段工作进行总结；包括分阶段性工作、总体工作的总结。

⑥组长分配的其他工作。

测试组成员应对熟悉负责测试的业务，参加过产品测试工作，掌握一定的测试方法和技

巧。

（二）测试人员的培训

1、培训人员的选择

在测试准备阶段要首先确定进行培训的人员。

进行测试培训的培训人员应参加过前期产品设计，对所测产品的创意、产品构架、业务

流程、主要功能等方面非常熟悉；具测试工作经验，参加过产品测试工作，熟悉测试工作流

程，掌握一定的测试方法和技巧；同时具有培训经验，擅长沟通和表达。

2、培训内容

测试培训包括两方面内容：一方面是测试方法和技巧、测试形式、相关测试工具等；

另一方面围绕产品设计说明书对待测产品进行详细的介绍和讲解，其中重点在于新产品的突

破创新之处、整体架构、业务流程、主要功能等。

3、培训形式

培训形式以授课方式为主，包括讲授和基本操作的演示。培训课程之外可以采用测试经

验交流、提问和讨论等各种形式对培训课程未能涉及的方面进行补充。

四、测试工作机制一会议与讨论

会议是测试工作中进行沟通和交流的有效的方式和手段。

（一）测试工作启动会议

在启动会议中要明确测试工作的目标、任务，协调人员配置，强调工作纪律。同时会议

应详细介绍测试工作计划和方案，使与会的测试组成员明确测试工作的整体思路、各自的主

要工作和责任，做到心中有数。测试工作启动会议是测试工作的开端，标志着正式进入产品

测试阶段。

测试工作启动会议由测试主管主持，测试工作组全体成员和非测试组成员代表参加。

（二）阶段性会议

不同测试阶段的测试工作重点不同，召开阶段性会议，对前阶段的测试工作进行总结，

同时对下阶段的测试工作进行安排。包括强调测试重点、介绍此阶段的测试方法和形式、人

员的调整和分工、需要完成的相关文档等内容。

阶段性会议由测试主管支持，测试工作组全体成员参加。

阶段性会议也可由测试组、支持组组内定期召开，对本组阶段性工作进行总结和下阶段

工作的安排。

（三）专题会议

测试过程中测试组、支持组，或测试组与支持族之间针对某个测试工作中具体问题的商

议、解决可以采用专题会议的形式

针对具体问题的专题会议可以召集会议主题涉及到成员参加。

（四）讨论

讨论是测试工作中进行沟通和交流的另一种有效的方式和手段。

对于测试工作中发现的••般性问题，由测试组通过组内讨论，研究解决方案，组内自行

解决。

对于测试工作中发现的重大问题，测试组以及其他相关开发人员展开讨论，共同协商，

寻求解决方案.

五、测试用例的编写

测试过程中每笔交易或每项操作都要根据专门编制的具体案例进行。

（一）案例编写的原则

案例编写应遵照完整性、针对性、关联性和规范性四项原则。

1、完整性

完整性也可以理解为仝面性，指设计测试案例要同时考虑到系统实际运行情况中可能会

出现的各种情况，并通过测试案例的模拟操作，发现问题，完善产品。

为了保证案例编制的完整性，在编制案例时从以下方面入手：

（1）从案例编制的整体考虑，应覆盖所测产品业务流程中的每项交易：

（2）针对单项交易编制的案例应从人机交互、业务逻辑、账务处理等方面考虑。

一般情况下，首先该交易操作的每项输入项都是一个测试点，根据输入性的性质取值

类型分别设定该输入项的正常值、边界值以及越界值进行测试。对于列表选择的输入项，要

充分考虑到不同输入项的不同列表取值的组合情况。对于不同的组合测试案例中要穷举。

其次考虑单个交易内部的业务逻辑，例如：各输入项之间的相互制约、相互控制的关

系

产品自身状态对交易的限制、相关制度对具体产品的规定等。

（3）要考虑到每项金融性交易的相应的账务处理。

（4）通过对每项交易输出项是否完整、正确，能否如实反映账务处理的检验，验证系统

对该项交易的处理过程。

（5）对于每项交易的每个测试点，不仅仅要考虑正常发生的情况，还要同时兼顾反常情

况下系统的处理及反映。如：对于错误信息的输入，系统是否进行控制、是否给与

相应的错误提示等。

（6）确保案例编制的完整性，可参考技术人员提供的错误信息代码，根据错误信息提示

的情况，编制案例。

（7）系统每个层次的显示界面是否合理、全面、美观，是否符合操作者的使用习惯。

2、针对性

针对性指每个测试案例要明确测试意图。一方面要考虑各种更杂的实际应用情况系统

地规划，避免出现对任何功能的遗漏，同时编制一个案例应尽可能多的涉及该系统各项功能,

避免出现大量案例重复编制，无意义地加大工作量，降低了效率。

3、关联性

关联性，一方面指整个系统各个交易之间的关联性；另一方面指单项交易涉及到的各个

要素之间的内在关系。

例：一个用于贷款业务的测试案例设计时要考虑放款、还款、展期、形态转移等一系列

交易及相互的影响和控制。另外所有查询类、报表类交易也都基于基本交易的结果和基础上

进行。

单项交易涉及到的各个要素包括：产品科目、期限、利率及静态表的维护之间的相互关

联。

4、规范性

测试案例要严格依据产品设计说明书编制。同时为了便于统计和管理，应按照统一的格

式、编码、内容和规范进行编制。

（-）测试案例的取舍

在测试过程中，如果待测试软件功能复杂，在受测试时间和测试资源限制的情况下，不

可能将测试资源平均用于所有案例测试，因此我们在测试案例的编写过程和测试过程中需要

对测试内容按照功能和内容对测试案例进行优先等级的划分，以把握测试和验收重点。

测试案例划分的方法简单总结如下，供参考：

“功能优先级”的划分标准为：

3.重要功能:

2.一般功能

1.不常用功能;

“内容优先级”的划分标准为：

3.正常情况;

2.重要的异常情况;

1，不重要的异常情况。

案例优先级=功能优先级X内容优先级

其取值范围为：[9、6、4、3、2、1]

举例：“外汇宝客户签约，正常情况”

功能优先级=3

内容级别=3

案例优先级=3*3=9

六、测试相关文档

(-)测试计划书

测试工作计划是测试工作开展的基础，测试计划为整个测试工作建立完整的框架结构,

是测试工作的起始步骤和重要环节。制定测试工作计划书应该包括以下方面：

1、测试项目的基本简介

通过测试产品基本情况简介使测试者对所测试的产品有所了解，形成整体认识。

测试产品基本情况的介绍应该围绕该产品创意展开，主要包括产品项目背景、项目目

标、业务范围、产品及核算架构、与其他子系统的关系等五方面内容。

2、测试工作进度安排

测试工作时间安排是测试计划的核心内容之一，按照测试工作内容、进程，排定时间表。

测试工作时间表不仅统筹整体工作进展，并且应将具体的工作内容细化到周或工作日。另外,

时间表中还应考虑到测试工作分阶段进行的阶段性总结与反馈。

3、测试策略

测试策略对测试工作进行指导，针对具体问题具体分析，对不同情况提供具体的处理和

解决方法。例如：对于测试中出现的重大事故问题，集合技术人员和业务人员共同召开会议

研究；对于测试组内对于某问题产生的不同意见，采用小组讨论的形式解决等等。

4、测试记录

测试记录指对测试工作详细、完整的文档纪录。包括：阶段性的测试工作总结、测试

问题报告单、测试问题工作量统计表、测试案例单等。

5、测试资源配置

一方面包括测试工作所需的硬件设施：测试环境等。另一方面包括测试工作需要的测

试人员的组织。

测试计划完成之后，应与技术人员进行讨论、协商，对完成的测试计划进行评审，形成

反馈意见，并对测试计划修改和完善，形成最终予以实施的版本。

（二）测试方案书

测试方案具体指导测试工作的开展、进行；是测试工作实施的依据。全面、合理的测试

方案一定程度上能够推动测试工作的进展，提高工作效率。

设计出全面、合理测试方案，做到心中有数，是测试准备阶段的重要工作之一。完整的

测试方案应包括以下方面：

1、测试目标、原则和要求

测试是保证软件产品质量最重要的手段。目的在于检验软件是否满足规定的需求或是弄

清实际结果和预期结果之间的差别。寻找程序错误，寻找与用户需求不一致和存在的缺陷。

以较少的案例、时间和人力找出软件潜在的各种错误和缺陷，以确保系统的质量。具体表现

在以下几个方面：（1）确保软件产品达到需求功能的说明；（2）确保软件产品满足性能需求；

（3）（压力测试）确认程序能够处理用户要求的负载；（4）确保软件产品在要求的硬件和软件

平台上工作正常。

测试工作按照全面性、有效性和正确性的原则进行。

全面性指测试工作应涵盖所测系统所有交易，包括金融类和管理类交易，并需检测系统

在各时段（模式）运行时的功能实现情况。

有效性指以实际业务情形为基础，从可操作性等方面进行测试，检测系统是否已满足营

业网点和管理行各项业务处理和管理的需要。

正确性指检测系统业务处理流程的正确合理性、账务组织的完整性、金融性交易账务处

理的正确性以及会计和业务统计报表真实、准确性.

测试工作的要求包括测试工作的完成情况和工作态度两方面的要求。

2、测试内容、范围

根据所测试的金融产品的主要业务和功能，确定测试内容和范围°例如资产业务系统的

测试工作内容指主要的资产业务，包括个人贷款、对公贷款、质押贷款、系统内拆借、同业

拆借、委托贷款、贴现、转贴现以及额度管理等业务的测试。

3、测试方式

测试方式指测试工作不同的切入点和不同方面。即测试工作需要从几下方面分别进行：

常规性测试指模拟实际业务正常发生情况进行的测试。

反常规性测试指针对除实际业务正常发生情况以外的非正常情况进行的测试。通过反常

规性测试，检验系统是否进行了相应的控制，能否做出正确的反馈。

验收测试是从用户的角度出发，也可以由产品的使用者来对产品进行的检测。使用者关

注的重点是使用产品的感受，关心软件的界面是否美观、菜单的位置是否合适，各个交易的

操作是否方便，是否能够满足使隹者的需要等，通过验收测试认定该软件产品是否满足规定

的质量要求。

回归测试指对测试过程中发现并提交问题的修改结果进行再次测试和验收。

完整的测试工作应同时从以上方面着手，兼顾全面。

4、测试依据

测试依据指测试工作得以正常开展所参考的相关制度和资料。包括产品设计说明书、测

试计划、相关管理制度和规定等。

5、测试环境

测试环境指建立测试硬件环境、软件环境、网络环境、测试数据、账务环境等。

6、测试人员与职责说明

测试方案中应根据所测试系统的具体内容和要求，对参加测试的人员进行安排和分工。

包括人员分组、指定责任人并根据测试进程确定每个测试人员具体工作任务等。

7、测试问题处理流程

测试问题处理流程指测试人员、后台技术人员、前台技术人员对测试中发现的问题处

理解决的具体的过程。即谁发现问题，交由谁进行分析，由谁具体解决等，建立统一的责任

和规范。

测试方案要对测试处理问题处理流程进行明确。

8、测试案例

根据实际业务发生情况模拟编制的用于检测每项交易的输入项、输出项、账务处理等

方面正确性、全面性、合理性的实例。

详见附件。

(三)测试报告

完整的测试报告应包括以下几方面：

1、测试任务

概要说明本次测试所承担的具体任务及应达到的目标。

2、测试组织方案

(1)测试时间

描述整个测试工作的起止时间。

(2)测试地点

描述测试工作的具体地点。

(3)测试环境

描述测试工作所应用的硬件及软件环境。

硬件

设备类型配置数量

主机

终端

打印机

软件

软件类型名称

操作系统

数据库

开发工具

应用软件

其他

（4）人员安排

描述参与测试的人员应承担的工作任务及职责。

姓名所属部门职责

3、测试情况回顾

（1）测试数据准备

描述为测试工作进行的必要的数据准备。

（2）测试案例准备

概要描述案例种类（正常案例和纠错案例）及数量等，并将测试案例单作为附件。

（3）测试功能及结果

按照具体交易分别描述交易功能及测试结果。

交易代码交易名称功能描述测试结果测试员

（4）测试中出现问题的统计

交易代码交易名称问题描述类型测试员

4、总体评价

对整个测试工作的任务完成情况、与其他部门配合情况及需要在以后的测试中注意的其

他问题等进行总结。

（四）其他文档资料

附件一：《测试案例单》

附件二：《测试问题报告单》

附件三：《测试问题汇总统计表》

附件四：《需求变更申请单》

附件五：《需求变更记录表》

附件六：《功能与案例对照表》

附件一:

测试案例单

编号:

子系统交易测试测试

交易码

名称名称人员时间

测试说明

测试初始

数据准备

测试案例

预期结果

实际结果

是否通过是口否口

测试案例

预期结果

实际结果

是否通过是口否口

测试案例

预期结果

实际结果

是否通过是口否口

附件二：

测试问题报告单（第一联）

报告单编号:

子系统名称：交易码：交易名称：

涉及平台：UNIXDAS400口ES9000D测试日期：测试案例单编号：

问题描述：（此处由负责测试的人员对问题的现象作详细描述）

问题发现人签字：测试负责人签字：问题修改人签字：备注：

口期：日期：日期

测试问题报告单（第二联）

报告单编号:

子系统名称；交易码：交易名称：

涉及平台：UNIXDAS400QES9000口测试日期：测试案例单编号：

问题描述：（此处由负责测试的人员对问题的现象作详细描述）

问题发现人签字：测试负责人签字：问题修改人签字：备注：

口期：日期：日期

附件三:

测试问题汇总统计表

产品名称程序版本程序提交日

序号案例编号测试问题描述测试人员是否修改修改方案/不开发结果

修改原因人员

附件四：

需求变更申请单

年月日编号:

业务种类：申请人：组长：

希望完成日期：实际完成日期：

需求描述:

反馈意见:

经办人：组长：

附件五:

需求变更记录表

修订时间修订人修订内容版本审批人备注

附件六:

功能与案例对照表

序号功能编号功能名称案例编号案例名称

软件项目测试规范

一、概述

本规范是对项目软件测试的一份规范性文件，对软件测试过程中所涉及

到的测试类型、测试方法、测试标准、测试流程以及软件产品责任单位

所承担的职责进行总体规范，以有效保证软件产品的质量。

软件测试是对软件设计的一种控制手段，是对软件产品质量的一种检查

和审核手段。软件设计单位应采取有效措施保证软件产品的质量，软件

测试应按本规范要求对软件进行检查、测试，软件设讦单位应保证对测

试错误进行修正。测试过程中发现的软件错误必须及时改正，这就是软

件测试的任务。为了改正错误，首先必须确定故障的准确位置，这是测

试过程中最困难和任务。需要周密审慎的思考和推理。改正错误常常包

括修正原来的设计，必须通盘考虑而不能“头痛医头脚痛医脚”，应该

尽量避免在测试过程中引进新的故障。

二、测试类型

项目软件测试类型包括单元测试、集成测试（组装测试）、有效性测试

（功能测试）、系统测试、回归测试和用户测试（验收测试）。

单元测试

主要针对软件设计单元、功能模块进行测试，测试内容包括模块程序结

构检查、代码测试和模块内功能测试。

集成测试（组装测试）

主要针对软件设计单元、功能模块组装、集成为系统时，对软件单元、

功能模块的接口、连接进行测试。

有效性测试（功能测试）

按照系统功能需求规定对系统的功能、流程、数据、业务规则等进行测

试，以及对系统基本特征如操作、界面、报表等的合理性、一致性进行

测试。

系统测试

为系统性能测试，如安全性、可靠性、稳定性测试，以及对系统其它性

能如负载能力、处理能力以及响应时间等进行测试。

回归测试

在软件设计错误修正、设计修改以及软件升级后，主要针对软件修改、

影响部分进行有效性测试和系统测试。

用户测试（验收测试）

为用户方组织的有效性和系统测试。

三、测试的方法

逻辑覆盖法

根据测试用例，运行被测试程序，使程序中的每个可执行语句、执行条

件至少执行一次。

语句覆盖

语句覆盖就是设计若干个测试用例，运行被测程序，使得每一条可执行语句至少执行一次。

判定覆盖

判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假

分支至少经历一•次,判定覆盖又称为分支覆盖。

条件覆盖

条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能

取值至少执行•次。

判定一条件覆盖

判定一条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一

次，同时每个判断中的每个条件的可能取值至少执行一次。

条件组合僵盖

条件组合构襦就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取

值组合至少执行一次。

路径测试

路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径■

条件测试路径选择

当程序中判定多于一个时，形成的分支结构可以分为两类：嵌套型分支结构和连锁型分支结

构，

对于嵌套型分支结构,若有n个判定语句，需要n+l个测试用例：

对于连锁型分支结构,若有n个判定语句，需要有2n个测试用例，覆盖它的2n条路径.当

n较大时将无法测试。

循环测试路径选择

循环分为4种不同类型：简单循环、连锁循环、嵌套循环和M结构循环,

(1)简单循环

①零次循环：从循环入口到出口

②一次循环：检查循环初始值

③二次循环：检查多次循环

④m次循环：检查在多次循环

⑤最大次数循环、比最大次数多一次、少一次的循环。

(2)嵌套循环

①对最内层循环做简单循环的全部测试.所有其它层的循环变量置为最小值：

②逐步外推，对其外而循环进行测试。测试时保持所有外层循环的能环变量取圾小但，所仃

其它嵌套内层循环的循环变量取“典型”值.

③反更进行，直到所有各层循环测试完毕。

④对全部各层循环同时取最小循环次数，或者同时取最大循环次数。

(3)连锁循环

如果各个循环互相独立，则可以用与简单循环相同的方法进行测试。但如果几个循环不是互

相独立的，则需要使用测试嵌套循环的办法来处理。

(4)加结构循环

这•类循环应该使用结构化程序设计方法重新设计测试用例。

所谓等价类，就是指某个输入域的集合，集合中的每个输入对揭露程序

错误来说是等效的，把程序的输入域划分成若干部分，然后从每个部分

中选取少数代表性数据作为测试用例，这就是等价类划分方法。它是功

能测试的基本方法。使用这一方法设计测试用例要经历划分等价类(列

出等价类表)及选取测试用例两步。

划分等价类：有效等价类、无效等价类

确定测试用例：为每个等价类规定一个唯一的编号；设计一个测试用例,

使其尽可能多地覆盖尚未覆盖的有效等价类；设计一个新的测试用例，

使其只覆盖一个无效等价类。

等价类划分是一种典型的黑盒测试方法,使用这一方法时，完全不考虑程序的内乱结

构，只依据程序的规格说明来设计测试用例.

等价类划分方法把所有可能的输入数据，即程序的输入域划分成若卜部分，然后从每

一部分中选取少数有代表性的数据做为测试用例。

使用这一方法设ir测试用例要经历划分等价类(列出等价类表)和选取测试用例两步。

划分等价类

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错

误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。

等价类的划分有两种不同的情况：

①有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的

集合。

②无效等价类：是指对于程序的规格说明来说，是不合理的，尤意义的输入数据构

成的集合。

在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

划分等价类等价类的原则。

(1)如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个

无效等价类。

例如，在程序的规格说明中，对输入条件有一句话：

“项数可以从I到999”

则有效等价类是“1W项数《999”

两个无效等价类是“项数VI”或“项数＞999”。

(2)如果输入条件规定了输入值的集合，或者是规定了“必须如何"的条件，这时可确

立一个有效等价类和一个无效等价类。

例如,在Pascal语言中对变量标识符规定为“以字母打头的……串”。那么所有以字母

打头的构成有效等价类，而不在此集合内(不以字母打头)的归于无效等价类。

(3)如果输入条件是一个布尔量，则可以确定•个有效等价类和一个无效等价类,

(4)如果规定了愉入数据的一组值，而且程序要对每个输入值分即进行处理，这时可

为律•个输入值确立一个有效等价类，此外针对这组值确立•个无效等价类，它是

所有不允许的输入值的集合。

例如.在教师上岗方案口规定对教授、副教授、讲师和助教分别计算分数，做相应的

处理“因此可以确定4个有效等价类为教授、副教授、讲师和助教，个无效等价类,它是

所仃不符合以上身分的人员的输入值的集合.

(5)如果规定了输入数据必须遵守的规则，则可以确立一个有效箸价类(符合规则)和

若干个无效等价类(从不同角度违反规则)。

例如，Pascal语言规定“一个语句必须以分号结束”这时，可以确定一个有效等价

类"以结束'若干个无效零价类“以“结束”、"以结束，"以“结束”、“以LF结束”

等.

确立测试用例

在确立了等价类之后,建立等价类表，列出所有划分出的等价类,再从划分出的等价

类中按以下原则选择测试用例：

(1)为每一个等价类规定一个唯一编号：

(2)设计一个新的测试用制，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一

步，直到所有的有效等价类都被覆盖为止；

(3)设计•个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这•步，

直到所有的无效等价类都被陵盖为止

边界值分析法

使用边界值分析方法设计测试方案首先应该确定边界情况，这需要经验

和创造性，通常输入等价类和输出等价类的边界，就是应该注重测试的

程序边界情况。选取的测试数据应该刚好等于、刚刚小于和刚刚大于边

界值。也就是说，按照边界值分析法，应该选取刚好等于、稍小于和稍

大于等价类边界值作为测试数据，而不是选取每个等价类内的典型值或

任意值作为测试数据。

边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充，人们从长期的测试

工作”聆得知，大最的错误是发生在躲入或输出范用的动界匕而不累在输入范用的内部。

因此针对各种边界情况设汁测试用例，可以查出更多的错误。

比如,在做三角形计算时，要输入三角形的三个边长：A、B和C。我们应注意到这

二个数值应当满足A>0、B>0、C>0.A+B>C.A+C>B、B+C>A,才能构成三角形。

但如果把六个不等式中的任何一个大于号错写成大于等于号“2”，那就不能构成三角

形。问题恰出现在容易被疏忽的边界附近，

这里所说的边界是指，相当于悔入等价类和输出等价类而言，稍高于其边界值及稍低于

共边界值的•些特定情况.

使用边界值分析方法设计测试用例，首先应确定边界情况。应当选取正好等于.刚刚

大十，或刚刚小于边界的位做为测试数据,血不是选取等价类中的典型值或任意值做为测试

数据。

实践证明，软件在输入、输出域的边界附近容易出现差错，边值分析是考虑边界条件

而选取测试用例的一种功能测试方法。边值分析是对等价类划分的有效补充，

因-果图法

分析程序规格说明的描述中哪些是原因，哪些是结果。原因是输入条件

或是输入条件的等价类。结果是输出条件。因果图是一种形式语言，由

自然语言写成的规范转换而成，这种形式语言实际上是一种使用简化记

号表示数字逻辑图。因果图法是帮助人们系统地选择一组高效测试用例

的方法，此外，它还能指出程序规范中的不完全性和二义性。

因果图的适用范匣

如果在测试时必须考虑输入条件的各种组合，可使用•种适合于描述对于多种条件的组合，

相应产生