中华人民共和国国家标准
GB／T 12504一—90
计算机软件质量保证计划规范
Specification for computer
software quality assurance plan
1
主题内容与适用范围
本规范规定了存制订软件质量保证计划时应该遵循的统一的基本要求。
本规范适用于软件中特别是重要软件的质量保证计划的制订工作。对于非重要软件或已经开发好的软件，可以采用本规范规定的要求的子集。
2 引用标准
GB／T 11457 软件工程术语
GB 8566 计算机软件开发规范
GB 8567 计算机软化：严品并发文件编制指南
GB／T 12505 计算机软件配置管理计
3 术语
下面给出中规范中用到的—些术语的定义．其他术语的定义按 GB／T 11457。
3．1 项目委托单位 project entrust organization
项目委托单位是指为产品开发提供资金并通常也是(但有时也未必)确定产品需求的单位或个人。
3．2 项目承办、单位 project undertaking organization
项目承办单位是指为项门委托单位开发、购置或选用软件产品的单位或个人。
3．3 软件开发单位 software development organization
软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。
3．4 用户 user
用户是指实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。
3．5软件 software
软件是指计算机程序及其有关的数据和文挡，也包括固化下的程序。
3．6 重要软件 critical software
重要软件是指它的故障会影响到人身安全、会导致重大经济损失或社会损失的软件。
3．7 软件生存周期 software life cycle
软件生存周期是指从系统设计到计算机软件系统提出应用需求开始，经过开发，产生—个满足需求的计算机软件系统，然后投入运行。直至该软件系统退役为止。其间经历系统分析与软件定义、软件开发以及系统的运行与维护等三个阶段。其中软件开发阶段—般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。
3．8 验证 verification
验证是指确定软件什发周期中的—个给定阶段的产品是否达到在上一阶段确立的需求的过程。
3．9确认 validation
确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。
3．10 测试 testing
测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。
3．11 软件质量 software quality
软件质量是指软件产品中能满足给定需求的各种特性的总和。这些特性称做质量特性，它包括功能度、可靠性、易使用性、时间经济性、资源经济性、可维护性和可移植性等。
3． 12 质量保证 quality assurance
质量保证是指为使软件产品符合规定需求所进行的一系列有计划的必要工作。
4 软件质量保证计划编制大纲
项目承办单位(或软件开发单位)中负责软件质量保证的机构或个人，必须制订一个包括以下各章内容的软件质量保证计划(以下简称计划)。各章应以所给出的顺序排列;如果某章中没有相应的内容，则在该章标题之后必须注明“本章无内容”的宇样，并附上相应的理由；如果需要，可以在后面增加章条；如果某些材料已经出现在其他文档中，则在该计划中应引用那些文档。计划的封面必须标明计划名和该计划所属的项目名，并必须由项目委托单位和项目承办单位(或软件开发单位)的代表共同签字、批准。
计划的目次是：
引言
管理
文档
标准、条例和约定
评审和检查
软件配置管理
工具、技术和方法
媒体控制
对供货单位的控制
记录的收集、维护和保存
下面给出软件质量保证计划的各个章条必须具有的内容。
4． 1引言
4．1． 1 目的
本条必须指出特定的软件质量保证计划的具体目的。还必须指出该计划所针对的软件项目(及其所属的各个子项目)的名称和用途。
4．1．2 定义和缩写词
本条应该列出计划正文中需要解释的而在 GB／T l1457中尚未包含的术语的定义，必要时，还要给出这些定义的英文单词及其缩写词。
4．1．3 参考资料
本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。
4．2 管理
必须描述负责软件质量保证的机构、任务及其有关的职责。
4．2． 1 机构
本条必须描述与软件质量保证有关的机构的组成。还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的相互关系。
4．1．2 任务
本条必须描述计划所涉及的软件生存周期中有关阶段的任务，特别要把重点放在描述这些阶段所应进行的软件质量保证活动上。
4．2．3 职责
本条必须指明软件质量保证计划中规定的每一个任务的负责单位或成员的责任。
4．3 文档
必须列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评中与检查的准则。
4．3． 1 基本文档
为了确保软件的实现满足需求，至少需要下列基本文档：
4．3．1． 1 软件需求规格说明书 software requirements specification
软件需求规陷说明书必须清楚、准确地播述软件的每一个基本需求(功能、性能、设计约束和属性)和外部界面。必须把每—个需求规定成能够通过预先定义的方法(例如检查、分析、演示或测试等)被客观地验证与确认的形式。软件需求规格说明书的详细格式按 GB8567。
4．3．1．2 软件设计说明书 software design description
软件设计说明书应该包括软件概要设计说明和软件详细设计说明两部分。其概要设计部分必须描述所设计软件的总体结构、外部接口、各个主要部件的功能与数据结构以及各主要部件之间的接口；必要时还必须对主要部件的每—个子部件进行描述。其详细设计部分必须给出每一个基本部件的功能、算法和过程描述。软件设计说明书的详细格式按 GB8567。
4．3．1．3 软件验证与确认计划 software verification and validation plan
软件验证与确认计划必须描述所采用的软件验证和确认方法(例如评审、检查、分析、演示或测试等)，以用来验证软件需求规格说明书中的需求是否已由软件设计说明书描述的设计实现；软件设计说明书表达的设计是否已由编码实现。软件验证与确认计划还可用来确认编码的执行是否与软件需求规格说明书中所规定的需求相—致。软件验证与确认计划的详细格式按 GB8567中的测试计划的格式。
4．3．1．4 软件验证和确认报告 software verification and validation report
软件验证与确认报告必须描述软件验证与确认计划的执行结果。 这里必须包括软件质量保证计划所需要的所有评审、检查和测试的结果。软件验证与确认报告的详细格式按 GB8567中的测试报告的格式
4．3．1．5 用户文档 user documcntation
用户文档(例如手册、指南等)必须指明成功运行该软件所需要的数据、控制命令以及运行条件等；必须指明所有的出错信息、含义及其修改方法；还必须描述将用户发现的错误或问题通知项目承办单位(或软件开发单位)或项目委托单位的方法。用户文档的详细格式按 GB8567。
4．5．2 其他文档
除基本文档外，还应包括下列文档：
a． 项目实施计划(其中可包括软件配置管理计划，但在必要时也可单独制订该计划)：其详细格式按 GB8567。
b． 项目进展报表：其详细格式可参考本规范附录 B(参考件) 中有关《项目进展报表》的各项规定。
c． 项目开发各阶段的评审报表：其详细格式可参考本规范附录 c(参考件)中有关《项目阶段评审表》的各项规定。
d． 项目开发总结：其详细格式按 GB8567。
4．4 标准、条例和约定
必须列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施。
4．5 评审和检查
必须规定所要进行的技术和管理两方面的评审和检查工作，并编制或引用有关的评审和检查规程以及通过与否的技术准则。至少要进行下列各项评审和检查工作：
4．5． 1 软件需求评审 software requirements review
在软件需求分析阶段结束后必须进行软件需求评审，以确保在软件需求规格说明书中所规定的各项需求的合适性。
4． 5．2 概要设计评审 preliminary desjgn review
在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。
4．5．5 详细设计评审 detailed design review
在软件详细设计阶段结束后必须进行详细设计评审，以确定软件设计说明书中所描述的详细设计在功能、算法和过程描述等方面的合适性。
4．5．4 软件验证与确认评审 software verification and validation review
在制订软件验证与确认计划之后要对它进行评审，以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。
4．5．5 功能检查 functional audit
在软件释放前，要对软件进行功能检查，以确认已经满足在软件需求规格说明书中规定的所有需求。
4．5．6 物理检查 physjcal audit
在验收软件前，要财软件进行物理检查，以验证程序和文档已经一致并已做好了交付的准备。
4．5．7 综合检查 comprehensive audit
在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查，以验证代码和设计文档的—’致性、接口规格说明之间的——致性(硬件和软件)、设计实现和功能需求的—致性、功能需求和测试描述的一致性。
4．5．8 管理评审 management reviews
要对计划的执行情况定期(或按阶段)进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。
4．6 软件配置管理
必须编制有关软件配置管理的条款，或引用按照 GB／T12505单独制订的文档。在这些条款或文挡中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。
4．7 工具、技术和方法
必须指明用以支持特定软件项目质量保证工作的工具、技术和方法，指出它们的目的，描述它们的用途。
4．8 媒体控制
必须指出保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化。
4．9 对供货单位的控制
供货单位包括项目承办单位、软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位(或子开发单位)开发的或从开发(或子开发)单位现存软件库中选用的软件能满足规定的需求。
4．10 记录的收集、维护和保存
必须指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限。
中华人民共和国国家标准
GB/T
15532-1995
Computer
software unit testing
计算机软件单元测试
1 主题内容与适用范围
1.1 主题内容
软件单元测试是一个过程。本标准为该过程规定了一个标准的方法，使之成为软件工程实践中的基础。该方法是一种综合的方法，目的是对软件单元进行系统化的测试，包括测试计划的执行、测试集的获取以及测试单元与其需求的对照衡量包括使用样本数据来执行被测试单元、并将该单元的实际结果与单元的需求文件中指定的结果进行比较。
本标准描述了一个测试过程，它由一系列具有层次结构的阶段、活动及任务组成，且为每一活动定义了一个最小任务集。
1.2 适用范围
本规范可适用于任何计算机软件的单元测试（包括新开发的或修改过的软件单元）。本标准并不规定这些软件的类型，也不规定哪些软件必须进行单元测试。
本标准不涉及其他综合性的单元验证或确认过程，象评审（例如走查、审查）、静态分析（例如一致性核查、数据流分析—）或形式化分析（例如：正确性证明、符号执行）。
本标准不要求使用特定的测试机制或工具。本标准也不蕴含任何特定的方法学以进行文件控制、配置管理、质量保证、或测试步骤管理。同时也不规定软件排错的过程。
本标准的使用者可以是测试人员、也可是开发人员。
2 引用标准
GB 9386 计算机软件测试文件编制规范
GB/T 11457 软件工程术语
GB 12505 计算机软件配置管理计划规范
3 术语
下列术语定义适用于本标准，其他术语见GB 9386和GB/T 11457。
3.1 特性 characteristic
见数据特性（3.2条）或软件特性（3.5条）。
3.2 数据特性data characteristic
数据的一种固有的（也可能是非固有的）性质、质量或特征（例如数据使用率、格式、值范围或域值间关系）。
3.3 非过程性编程语言 monprocedure programming language
与过程性编程语言相对。是一种用于表达问题的参数，而不是表达解决问题的步骤的计算机编程语言（例如：报告生成器或分类的规范化语言）。
3.4 过程性编程语言 procedure programming language
与非过程性编程语言相对。是一种用于表达操作步骤，以供计算机执行的编程语言（例如：COBOL）。
3.5 软件特性software characteristic
软件的一种固有的（也可能是非固有的）性质、质量或特征（例如功能、性能、属性、设计约束、状态数目、分支的行数等）。
3.6 软件特征software feature
由需求文件所规定或蕴含的软件特征（例如：功能、性能、属性、设计约束）。
3.7 软件测试事件software test incident
在软件测试期间所发生的任何事件。
3.8 状态数据state data
确定测试单元内部状态的数据，它用于建立状态或与现存状态比较。
3.9 测试对象test objective
在指定条件下，通过对软件的实际状况与软件文件中所描述的状况进行比较来测量的软件特征集。
3.10 测试集结构test set architecture
测试用例集（测试集）的嵌套关系，它能直接反映测试对象的层次分解情况。
3.11 测试单元 test unit
一个包括一个或多个计算机程序模块及相应控制数据（例如表格）、调用过程、操作过程的模块集合，且该集合成员满足下列条件：
a. 所有模块属于同一个计算机程序系统；
b. 集合中至少有一个模块（新的或改变过的模块）尚未完成单元测试；
c. 所有模块及相应数据和过程的集合是一个测试过程的唯一对象；
注:①一个测试单元可能出现在一个单独的模块到一个完整的程序这样一种设计层次的任何一个级别中,因此,一个测试单元可能是一个模块、一些模块，或一个具有相关数据和过程的完整的计算机程序。
②一个测试单元可能包含一个或多个忆进行过单元测试的模块。
3.12 单元unit
见单元测试。
3.13 单元需求文件unit requirement documentation
论述被测单元的功能需求、接口需求、性能需求及设计约束需求的文件。
4 单元测试活动
本章规定单元测试过程所涉及的活动，每个活动按输入、任务和输出这样的结构加以描述。所描述的阶段及活动如下：
a.
完善测试计划
——制定方法、资源及进度的计划
——确定需测试的与需求有关的特性
——细化计划。
b.
获得测试集：
——设计测试集
执行计划及实现设计
c.
评价测试单元
——执行测试规程
——核对终止情况
——评价测试效果和测试单元。
所有活动的流程见图1
制订计划
确定测试特性
细化计划
设计测试集
实现设计
执行测试规程
补充测试集
核对结果
评价
图1单元测试活动流程
当一个以上的单元需进行测试时（例如所有的这引起单元均与一个软件项目有关），则计划活动须指出每个单元在整个测试单元集合中的位置，以免在每个测试单元中重复。
在一般情况下，除了图1中执行测试规程和核对结果这两个循环活动外，所有活动必须顺序进行，对于除了制订计划阶段外的任何一个活动，若其前面的活动或某一外部事件（例如：进度、需求、设计）有错，则有必要重新执行其前面的若干个活动，然后返回到当前活动。
各阶段的输入、输出数据流见图2。
在每个阶段，每个基本活动都连的自身的输入集和输出集，其内容由一系列任务组成。本标准描述了每个活动的输入、任务、输出。所有活动的输出集应当包含足够的信息来创建至少以下两个文件，一份测试设计说明及一份测试总结报告。所有文件必须符合GB 9386中的规定。所有的测试文件必须标明作者及日期。
测试设计说明将从确定测试特性、细化计划及设计测试集这几个活动中获得信息，测试总结报告将从所有的活动中获得信息。
4.1 制订方法、资源及进度的计划
总的单元测试应当在综合测试计划期间制订，且应在相应的计划文件中作出记录。
4.1.1 输入
a. 项目计划
b. 软件需求文件
4.1.2 任务
a. 指定单元测试的总方法
确定测试欲发展的风险区域。指定对确定特性（例如需测试的特性），设计测试集或实现测试（例如必须使用的测试集）等这几个活动阶段的限制。
确定现有的输入、输出和数据资源（例如测试文件、制作文件、测试数据生成器），确定数据确认的总技术。确定用于记录、收集、化简和确认输出数据的总技术。描述与被测试的单元有直接接口的应用软件的准备情况。
b. 指定完备的测试要求
确定单元测试集所覆盖的区域（例如软件特征、过程、状态、功能、数据特性、指令等）以及对每一区域所要求的覆盖程度。
在软件开发期间进行单元测试时，每一软件特征必须至少被一测试用例所覆盖，例外情况须得以批准。此原则也适用于软件维护时的单元测试。
当在软件开发期间测试一个用过程性语言（例如COBOL）实现的单元时，对每一指令（能够到达及执行的），除非该指令所在的模块已经独立地进行过单元测试，或者得到某种特许，它必须被某一测试用例所覆盖。此原则已适用于软件维护时用过程性语言实现的软件的单元测试。
c. 指定终止测试的要求
指定终止测试过程正常终止的需求。终止需求必须满足完备性。
确定会导致单元测试过程异常终止的任何情况（例如发现主要的设计缺陷，到达的最终期限）以及确定其相应通告过程。
d. 决定资源的要求
估计进行测试集获取、初始启动及后续测试活动反复执行所需的资源。应考虑硬件情况、访问时间（例如所用的计算机时间）、通信或系统软件、测试工具、测试文件等。
确定需准备的以及各部门响应所需的资源，包括那些对于其交付时间有严格要求的资源（例如定制的测试工具），并安排这些资源。
确定对单元测试及单元排错负责的部门、人员技能、数量及可参加时间的要求。
e. 指定总的进度安排
指定由资源的测试单元所决定的单元测试活动的进度。
4.1.3 输出
a. 单元测试计划（从4.1.2条的a-c得到）；
b. 单元测试的总体资源请求（若能从4.1.2 条的d条得到）。
4.2 确定需测试的与需求有关的特性
4.2.1 输入
a. 单元需求文件；
b. 软件结构设计的文件（若需要）。
4.2.2 任务
a. 研究功能需求
研究单元需求文件中描述的每一功能、保证每一功能有唯一的标识符，若需要的话，应对需求进行分类。
b. 确定附加需求及相应规程
对于那些没有被需求指定，却在单元测试一级有效的软件特性（例如软件性能、属性或设计约束），确定与之相关的需求语句，使之成为附加需求。确定那些仅与待测试单元有关的使用或操作规程。确保每一附加需求及规程有唯一的标识。若需要的话，应对需求进行分类。
c. 确定单元状态
若单元文件指定或蕴含了多种状态（例如不活动、等待接收、处理）软件，0则确定每一状态及每一有效状态转换。保证每一状态转换有唯一的标识符，若需要的话，应对需求进行分类。
d. 确定输入及输出数据特征
确定待测试单元的输入及输出数据结构。对每一结构，确定其特性，诸如使用率、格式、值范围和域值之间的关系，对每个特性，指定其有效范围。保证每一特性有唯一标识符。若需要的话，应对需求进行分类。
e. 选择包含于测试中的各要素
选择待测试的软件特征。选择其相应规程、状态及状态转换，以及测试时的有关数据特性。无效及有效数据都应选择。当无法进行这种完整的测试时，则应该利用如何使用该单元的信息决定选择的内容。对于不能选择的要素，确定由此可能带来的风险问题。
将所选择的特性、状态、状态转换及数据特性等数据记录在单元测试设计说明中的“被测试的特性”一章中（见GB 9386）
4.2.3 输出
a. 测试过程中包含的各要素的列表（从4.1.2条的a-c得到）；
b. 单元测试的总体资源请求（若能从4.1.2 条的d条得到）。
4.3 细化计划
4.3.1 输入
a. 测试过程中包含的各要素的列表（从4.2.2条的e得到）；
b. 单元测试计划（从4.1.2条的e得到）；
4.3.2 任务
a. 方法
确定可以考虑利用的现有的测试用例及测试规程。确定用于数据确认的任何特定技术。确定用于输出记录、输出收集、输出化简及输出确认所用的技术。将细化的方法记录于单元的测试设计说明文件中的“方法详述”一章中（见GB9386）。
b. 详述指定的资源需求
确定所指定的测试单元所需的资源（例如与该单元直接接口的软件）。并为已确定的资源作准备。将指定资源的需求记录在单元测试设计说明的“方法详述”一章中。
c. 指定详细进度
根据支撑软件、指定资源、所使用单元的可获得性及组装进度，为单元测试规定相应进度。将该进度记录于单元的测试设计说明的“方法详述”一章中。“
4.3.3 输出
a. 详细的单元测试计划（从4.3.2条的a-c得到）；
b. 单元测试的指定资源要求（若能从4.3.2条的b得到）。
4.4 设计测试集
4.4.1 输入
a. 单元需求文件；
b. 测试过程所包含的各要素的列表（从4.2.2条的e得到）；
c. 单元测试计划（从4.1.2条的a和b及4.3.2条的a得到）；
d. 单元测试文件；
e. 来自以前测试的测试规格说明（若可获得的话）。
4.4.2 任务
a. 设计测试集的层次结构
根据待测试的软件特征和由所选的有关要素（例如规程、状态转换、数据特性）所指定或蕴含的情况，设计一个按层次分解好的测试对象集，使得最低层的每一对象能直接用一些测试用例进行测试。选择合适的现有的测试用例，将测试用例标识符组与最低层的相应的对象相关联。将对象层次和相应的测试用例标识符记录于单元的测试设计说明中的“测试用例名称”一章中（见GB9386）。
b. 按需求获得清晰的测试规程
单元需求文件、单元测试计划及测试用例说明的组合可能会隐含地指定出单元测试规程，从而不需要更细致的“测试规程说明”选择现存的测试规程，稍作修改或不加修改地使用。
若单元测试设计说明的补充章条有要求，或另外的规程说明文件有要求，应指定相应的附加的规程。每一种选择都应与GB9386相吻合。当测用例和测试规程的对应关系不是很明显时，用表格连接它们，并将其放于单元测试设计说明中。
c. 获得测试用例说明
指定新的测试用例，可参考现存的测试用例说明。
将该测试用例直接记录于或通过引用的方式记录于单元的测试设计说明的补充章条中或另外的文件中。记录的文件必须符合GB 9386的要求，并放于单元的测试设计说明中。
d. 根据设计信息，按需要扩大测试用例说明。
根据单元设计信息，按需要更新测试集层次结构，注意应与4.4.1条的a保持一致，并考虑所选算法及内部数据结构等软件特征。
如果要确定控制流程及确定必须记录的内容数据的变化情况，则应考虑到可能产生的特殊记录的困难。例如，跟踪复杂算法中的控制流或踊跃内部数据结构（如栈或树）的变化时存在的记录困难。若需求的话，应增加单元设计（例如格式化数据结构、转储功能）以增强单元的可测试性。
根据单元设计中的信息，描述那些新增加的测试用例，并完成各部分的测试用例说明，同时应与4.2.2条的c保持一致。
e. 完成测试设计说明
完成被测单元的测试设计说明，并与 GB 9386相一致。
4.4.3 输出
a. 单元测试设计说明（从4.4.2条的e得到）；
b. 附加的测试规程说明（若能从4.4.2条的b得到）;
c. 附加的测试用例说明（若能从4.4.2条的c-d得到）;
d. 单元设计的增强需求（若能从4.4.2条的d得到）;
4.5 执行计划及实现设计
4.5.1 输入
a. 单元测试计划（从4.1.2条的a、c、e及4.3.2条的a-c得到）；
b. 在单元测试设计说明或附加文件中的测试用例说明（从从4.4.2条的d得到）；
c. 软件数据结构描述；
d. 测试支持资源；
e. 测试项；
f. 来自以前测试活动的测试数据（若存在）；
g. 来自以前测试活动的测试工具（若存在）；
4.5.2 任务
a. 获得并验证测试数据
对于能稍作修改或不作修改便可使用的测试数据，获得它们的一份备份，按需求产生新的数据。为保证数据的一致性和完整性，还应包含附加数据。按照软件数据结构规格说明验证所有数据。当测试用例和数据集的关系不明显时，用表格来记录此种关系，并放于单元测试设计说明书。
b.
获得指定资源
获得4.3.2条的b中指定的测试支持资源。
c. 获得测试项
收集包含已有的手册、操作系统规程、控制数据（如表格）和计算机程序在内的所有测试项，获得在测试设计期间确定的与测试单元有直接接口的软件。
当测试一个用过程性语言实现的单元时，要保证执行轨迹信息足以能够满足基于代码的程序的完备性要求。
将每一项的标识符记录于单元测试总结报告的“简述”一章中（见GB9386）
4.5.3 输出
a. 验证过的测试数据（从4.5.2条的a得到）；
b. 测试支持资源（从4.5.2条的b得到）;
c. 测试项的配置（从4.5.2条的c得到）
d. 初步总结（从4.5.2条的c得到）
4.6 执行测试规程
4.6.1 输入
a. 验证过的测试数据（从4.5.2条的a得到）
b. 测试文件资源（从4.5.2条的b得到）
c. 测试项的配置（从4.5.2条的c得到）
d. 测试用例说明（从4.5.2条的c、d得到）
e. 测试规程说明（从4.5.2条的b能够产生）
f. 故障分析结果（从排错过程得到）；
4.6.2 任务
图3为执行测试规程活动的控制流程图
a. 运行测试
建立测试环境，运行测试集，在单元测试总结报告的“结果概述”一章中记录所有的软件测试事件。
b. 判定结果
对每一个测试用例，利用测试用例描述文件中有关的所需的结果的规程说明，来判定单元测试活动是通过还是失败。将通过或失效结果记录于单元测试总结报告的“结果概述”一章中，将资源消耗数据记录于报告的“活动总结”一章中（见GB 9386）。当测试一个用过程性语言实现的单元时，收集执行轨迹的总结信息，且将其添入总结报告中。
对每一次效，应加以分析并将出错信息记录在测试总结报告的“结果概述”一章中，然后选择以下适用情况执行相应措施。
情况1：测试规格说明或测试数据的故障
改正错误，将改正错误信息记录在测试总结报告的“活动总结”一章中，然后重新运行该测试。
情况2：执行测试规程时的故障
重新运行未正确执行的规程。
情况3：测试环境（例如系统软件）中的故障
将环境修正，将环境修正情况记录在测试总结报告的“活动总结”一章中，然后重新运行该测试，或者预先设置异常终止情况，将不能修正环境的理由记录于测试总结报告的“活动总结”一章中，然后开始核对终止情况（即开始执行4.7条的活动）。
情况4：单元实现故障
修正错误，并将修正错误情况记录在测试总结报告的“活动总结”一章中，然后重新运行所有的测试，或者预准备异常终止情况，将不能进行单元修正的理由记录于测试总结报告的“活动总结”一章中，然后开始核对终止情况（即开始执行4.7条的活动）。
情况5：单元设计故障
修正单元设计并实现，在适当的时侯修改测试规格说明及数据，将错误修正情况记录于测试总结报告的“活动总结”一章中，然后重新运行所有的测试，或者，预先设置异常终止情况，将不能进行设计修正的理由记录于于测试总结报告的“活动总结”一章中，然后开始核对终止情况（即开始执行4.7条的活动）。
4.6.3 输出
a. 包含在测试总结报告中的执行信息，其中包括测试输出、软件测试事件描述、故障分析结果、错误修正活动、不能修改错误的理由、资源消耗数据，对过程性语言实现的程序而言，还应包括执行轨迹总结信息（从4.6.2条的a、b）产生；
b. 修订后的测试规格说明（若能从4.6.2条的b得到）；
c. 修订后的测试数据（若能从4.6.2条的b得到）。
4.7 核对终止情况
4.7.1 输入
a. 完备性和终止情况的需求说明（从4.1.2条的b、c得到）；
b. 执行信息（从4.6.2条的a、b得到）
c. 测试规格说明 (从4.4.2条的a-c得到）（若有需要）；
d. 软件数据结构描述（若有需要）。
4.7.2 任务
图4为结果核对活动内的控制流程图。
a. 对测试过程的正常终止情况进行核对
根据完备性要求或失效记录，决定是否要增加新的测试。对于用过程性语言实现的程序，要分析执行轨迹总结信息（例如变量、数据流）。
若不需附加测试，则将正常终止情况记录于测试总结报告的“活动总结”一章中，然后开始评价测试效果及被测单元（即开始执行4.8条的活动）。
b. 对测试过程的异常终止情况进行核对
若满足异常终止条件（例如重要错误不能修正、超时），则应将导致终止的特殊条件记录于测试总结报告的“活动总结”一章中，同时也应记录未完成的测试及未被修正的错误，然后开始评价测试效果及被测单元（即开始执行4.8条的活动）。
c. 补充测试集
当需要附加的测试且异常终止情况不满足时，通过下列步骤来补充测试集。
——更新测试集的结构，并与4.4.2条的a一致，且根据4.4.2条的c获得相应的测试用例说明；
——按需要根据4.4.2条的b，修改测试规程说明；
——根据4.4.2条的a，获得附加测试数据；
——将附加内容记录于测试总结报告的“活动总结”一章中；
——执行附加的测试（即返回4.6条的活动）。
4.7.3 输出
a. 记录于测试总结报告内的核对信息，包括终止条件及任何及任何测试用例的附加情况（4.7.2条的a-c得到）；
b. 附加的或修订后的测试规格说明（若能从4.7.2条的c得到）；
c. 附加的测试数据（若能从4.7.2条的c得到）。
4.8 评价测试效果和被测单元
4.8.1 输入
a. 单元的测试设计说明（从4.4.2 条的e得到）；
b. 执行信息（从4.6.2 条的a、b得到）；
c. 核对信息（从4.7.2 条的a-c得到）；
d. 附加的测试用例说明（若能从4.4.2 条的c、d得到）。
4.8.2 任务
a. 描述测试状态
将测试计划和测试规格说明的变化情况记录于测试总结报告的“差异”一章中（见GB 9386）。要说明每次变化的原因。
对异常终止情况，要确定未能被测试活动充分地覆盖的区域。且将理由记录于总结报告的“测试充分性评价”一章内（见GB 9386）。
确定未能解决的软件测试事件以及不能解决的理由，并记录于测试总结报告的“结果概述”一章中。
b. 描述单元状态
将通过测试所反映的单元与其需求文件之间的差异记录于测试总结报告的“差异”一章中。
将测试结果及所发现的错误情况同需求对照，评价单元的设计与实现，将评价信息记录于测试总结报告的“测试充分性评价”一章中。
c. 完成测试总结报告
根据GB 9386，完成测试总结报告。
d. 保存测试文件
确保测试得到的成果的收集、组织和存储。以备调用及重用，这些成果包括测试设计说明、附加和测试用例说明，附加的测试规程说明、测试数据、测试用例的产生规程、测试驱动程序和桩模块以及测试总结报告。
4.8.3 输出
a. 测试总结报告（从4.8.2 条的c得到）；
b. 测试成果的收集存储（从4.8.2 条的d得到）。
附录A
实现及使用指南
（参考件）
本附录包含使用本标准时有益的信息。因此建议在作出更作详细的计划之前先阅读本附录。
A1 标准的使用
本标准有以下作用：
a.作为确定当前的实践活动而比较的基础；
b.作为修改当前实践活动的思路之源；
c.作为当前实践活动的替代物。
A2 附加的测试需求
对每个项目，象附加测试文件（如测试日志）的数量，应当描述的细致程度及批准、复查的数量和类型等等这样的需求都应详细说明，有些因素，如单元的批语意见，读者需求或合同说明会经常影响这些需求，本标准将这种需求留给用户自己去描述，该描述可作为单独项目的需求，亦可作为某个组织的标准。若这些需求是某个项目特指的，则应在项目计划、质量保证计划、证明及验证计划或全局的测试计划中进行描述。
A3 附加的测试文件
一般认为。测试设计说明和测试总结报告中包含的信息是完成测试过程后得到的最小文件集合。另外，通过在这些文件中增加内容或增加额外的文件，GB 9386中描述的测试文件集可以满足所要求的任何测试信息。
A4 认可及评审