软件测试文档编制规范

231 GB 8567－88软件开发主要文档编写规范本附录中列出了《计算机软件产品开发文件编制指南》GB 8567－88中主要软件文档的编写说明，供编写时参考。

这些文档主要是：可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。

一、可行性研究报告l 引言1.1 编写目的说明：说明本可行性研究报告的编写目的，指出预期的读者。

1.2 背景 说明：a ．所建议开发的软件系统的名称。

b ．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。

c ．该软件系统同其他系统或其他机构的基本的相互来往关系。

1.3 定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4 参考资料列出用得着的参考资料，如：a ．本项目的经核准的计划任务书或合同、上级机关的批文。

b ．属干本项目的其他已发表的文件。

c. 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。

列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2 可行性研究的前提说明对建议开发项目进行可行性研究的前提，如要求、目标、条件、假定和限制等。

2.1 要求说明对所建议开发软件的基本要求，如： a ．功能。

b ．性能。

c ．输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象。

d. 输入说明。

系统的输入包括数据的来源、类型、数量、数据的组织以及提供的频度。

e ．处理流程和数据流程。

用图表的方式表示出最基本的数据流程和处理流程，并输之以叙述。

f. 在安全与保密方面的要求。

g. 同本系统相连接的其他系统。

h. 完成期限。

2.2 目标说明所建议系统的主要开发目标，如： a. 人力与设备费用的减少。

b. 处理速度的提高。

c. 控制精度或生产能力的提高。

232 d ．管理信息服务的改进。

a. CSCI必须分配给接口的优先级别； b. 要实现的接口的类型的需求（如：实时数 据传送、数据的存储和检索等）； c. CSCI必须提供、存储、发送、访问、接收 的单个数据元素的特性，如： 1）名称/标识符； a）项目唯一标识符； b）非技术（自然语言）名称； c）标准数据元素名称； d）技术名称（如代码或数据库中的变量 或字段名称）； e）缩写名或同义名；
3.5.x （接口的项目唯一标识符） 本条（从3.5.2开始）应通过项目唯一标 识符标识CSCI的外部接口，简单地标识接口实 体，根据需要可分条描述为实现该接口而强加 于CSCI的需求。该接口所涉及的其它实体的接 口特性应以假设或“当（未提到实体）这样做 时，CSCI将……”的形式描述，而不描述为其 它实体的需求。本条可引用其它文档（如：数 据字典、通信协议标准、用户接口标准）代替 在此所描述的信息。（若适用）需求应包括下 列内容，它们以任何适合于需求的顺序提供， 并从接口实体的角度说明这些特性的区别（如 对数据元素的大小、频率或其它特性的不同期 望）：
c. 处理 定义对输入数据、中间参数进行处理以获得 预期输出结果的全部操作。包括： 1）输入数据的有效性检查。 2）操作的顺序，包括事件的时间设定。 3）异常情况的响应，例如，溢出、通信故 障、错误处理等。 4）受操作影响的参数。 5）用于把输入转换成相应输出的方法。 6）输出数据的有效性检查。
d. 输出 1）详细说明该功能的所有输出数据， 例如，输出目的地、数量、度量单位、 时间关系、有效输出范围、非法值的处 理、出错信息等。 2）有关接口说明或接口控制文件的 参考资料。
1
范围
本章应分为以下几条。 1.1 标识 本条应包含本文档适用的系统和软件的完 整标识，（若适用）包括标识号、标题、缩略 词语、版本号和发行号。 1.2 系统概述 本条应简述本文档适用的系统和软件的用 途，它应描述系统和软件的一般特性；概述系 统开发、运行和维护的历史；标识项目的投资 方、需方、用户、开发方和支持机构；标识当 前和计划的运行现场；列出其它有关的文档。

徐婷
1-16
3.3 计算机软件测试文档编制规范
3.3.1 标准的适用对象及范围
该规范是为软件管理人员、软件开发、测试和维 护人员、软件质量保证人员、审计人员、客户及用户 制定的。 用于描述一组与软件测试实施方面有关的基本测 试文档，该标准定义每一种基本文档的目的、格式和 内容。尽管标准所描述的文档侧重于动态测试活动， 但是有些文档仍适用于其他种类的测试活动（例如： 测试计划可用于设计和代码评审）。
徐婷
1-21
3.3 计算机软件测试文档编制规范
3.测试报告 测试报告包括4个文档： （1）测试项传递报告 指明在开发组和测试组独立工作的情况下或在希 望正式开始测试的情况下为进行测试而被传递的测试 项。 （2）测试日志 测试组用于记录测试执行过程中发生的情况。
软件文档
郑州大学信息工程学院
徐婷
1-22
软件文档 郑州大学信息工程学院 徐婷 1-9
3.2 计算机软件需求规格说明规范
3.2.2 软件需求文档的基本要求
SRS是对要完成一定功能、性能的软件产品、程 序或一组程序的说明。因此对SRS的描述有两项基本 要求： 1. 必须描述一定的功能、性能； 2. 必须用确定的方法叙述这些功能。 SRS作为软件开发规范之一，对软件开发的所有 阶段都起着非常重要的作用。但是，需要注意的是： SRS不能超出其作用范围，即除了SRS正确地定义所 有软件的需求之外，一般地SRS不描述任何设计、验 证或项目管理的细节，这是对SRS的另外两个要求。
软件文档
郑州大学信息工程学院
徐婷
1-20
3.3 计算机软件测试文档编制规范
2.测试说明 （3）测试规程说明 详细说明执行一组测试用例的各个步骤，或者 更广泛的说明为了评估一组特征而用于分析软件项的 各个步骤。 测试规程是与设计分开的，主要明确要遵循的 步骤，而不宜含有无关的细节。

软件测试标准规范1目的为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考2适用范围本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。

3职责➢项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。

➢项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。

➢测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见➢项目负责人组织测试环境的建立。

➢项目经理审核负责控制整个项目的时间和质量。

➢研发人员确认修改测试人员提交的bug。

4工作流程4.1 测试依据详细设计是模块测试的依据。

因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。

测试人员必须认真阅读，真正弄懂系统需求和详细设计。

4.2 制订《测试方案》在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容：➢测试目的；➢所需人员及相应培训要求；➢测试环境、工具和测试软件；➢测试用例、测试数据和预期的结果。

4.3 单元测试项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。

单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。

对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。

单元测试针对程序模块，从程序的内部结构出发设计测试用例。

多个模块可以独立进行单元测试。

➢单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等；➢单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试；➢单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。

gbt175441998信息系统及软件完整性级别gbt162602006软件质量模型与度量gbt189052002软件工程产品评价gbt85672006计算机软件文档编制规范gbt93862008计算机软件测试文件编制规范gbt2500012010软件质量要求与评价square指南cstcjsbz02应用软件产品测试规范cstcjsbz03软件产品测试评分标准
GB/T 25000.1-2010《软件质量要求与评价（SQuaRE）指南》
CSTCJSBZ02《应用软件产品测试规范》
CSTCJSBZ03《软件产品测试评标准》软件测试依据的国家技术标准规范主要有以下八个：
GB/T 17544－1998《信息系统及软件完整性级别》
GB/T 16260－2006《软件质量模型与度量》
GB/T 18905－2002《软件工程产品评价》
GB/T 8567－2006《计算机软件文档编制规范》
GB/T9386-2008《计算机软件测试文件编制规范》

软件开发文档软件测试规范设计单位：建设单位：编制日期：目录第一章概述 (1)第二章测试理论 (2)2.1. 软件测试 (2)2.2. 测试目标 (3)第三章测试流程 (5)3.1. 测试流程图 (5)3.2. 流程细则 (9)3.2.1. 需求阶段 (9)3.2.2. 设计编码阶段 (9)3.2.3. 测试阶段 (9)3.2.4. 用户测试阶段 (11)3.3. 注意事项 (11)第四章测试类型 (14)4.1. 模块测试 (14)4.2. 子系统测试 (14)4.3. 系统测试 (15)4.4. 验收测试 (15)第五章黑盒测试方法 (16)5.1. 等价类划分 (18)5.2. 因果图 (20)5.3. 边值分析法 (21)5.4. 猜错法 (22)5.5. 随机数法 (23)第六章白盒测试方法 (24)6.1. 语句覆盖 (25)6.2. 判定理盖 (26)6.3. 条件覆盖 (27)6.4. 判定／条件覆盖 (28)6.5. 条件组合覆盖 (29)第七章测试错误类型 (31)7.1. A类 (31)7.2. B类 (31)7.3. C类 (32)7.4. D类 (32)7.5. E类 (33)第八章测试标准 (34)第九章附录一单元测试报告 (35)9.1. 测试过程与结果 (35)9.1.1. （某程序模块/文档名称）测试 (35)9.1.2. （某程序模块/文档名称）测试 (35)9.2. 测试结论 (36)第十章附录二集成测试报告 (37)第十一章附录三测试大纲 (38)11.1. 概述 (38)11.1.1. 编写目的 (38)11.1.2. 参考资料 (38)11.1.3. 术语和缩写词 (38)11.1.4. 测试内容和测试种类 (38)11.2. 系统结构 (39)11.3. 测试目的 (39)11.4. 测试环境 (39)11.4.1. 硬件 (39)11.4.2. 软件 (39)11.5. 人员 (39)11.6. 测试说明 (39)11.6.1. [测试1名称及标识符]说明 (40)11.6.2. [测试2名称及标识符]说明 (40)11.6.3. [测试3名称及标识符]说明 (41)11.6.4. [测试4名称及标识符]说明 (41)第十二章附录四测试大纲附录 (42)第十三章附录五测试计划 (44)13.1. 概述 (44)13.1.1. 编写目的 (44)13.1.2. 参考资料 (44)13.1.3. 术语和缩写词 (44)13.1.4. 测试种类 (44)13.2. 系统描述 (45)13.3. 测试环境 (45)13.3.1. 硬件 (45)13.3.2. 软件 (45)13.4. 测试安排 (45)13.4.1. （子系统1名称和项目唯一标识号） (45)13.4.2. （子系统2名称和项目唯一标识号） (46)13.5. 测试数据的记录、整理和分析 (46)第十四章附录六程序错误报告 (48)第十五章附录七测试分析报告 (50)15.1. 概述 (50)15.1.1. 编写目的 (50)15.1.2. 参考资料 (50)15.1.3. 术语和缩写词 (50)15.2. 测试对象 (50)15.3. 测试分析 (51)15.3.1. 测试结果分析 (51)15.3.2. 对比分析 (52)15.3.3. 测试评估 (52)15.4. 测试结论 (52)第一章概述本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量。

4 软件配置管理活动
本章描述配置标识、配置控制、配置状态 记录与报告以及配置检查与评审等四方面的软 件配置管理活动的需求。 4.1 配置标识
4.1.1 本条必须详细说明软件项目的基线（即 最初批准的配置标识），并把它们与本计划的 3.2条描述的生存周期的特定阶段相联系。在 软件生存周期中，主要有三种基线，它们是功 能基线、分配基线和产品基线。对于每个基线， 必须描述下列内容：
c. 描述软件库控制的规程，其中包括库存软 件控制、对于适用基线的读写保护、成员保护、 成员标识、档案维护、修改历史以及故障恢复 等七项规程；
d. 如果有必要修补目标代码，则要描述其标 识和控制的方法。
4.2.3 对于各个不同层次的配置控制组和其他 修改管理机构，本条必须：
a. 定义其作用，并规定其权限和职责；
a. 软件媒体和媒体文档的标识。
b. 把文档和媒体置于软件配置管理的控制之下，并 把它正式地交付给用户。例如，要给出对软件库内的 源代码和目标代码进行控制的工具、技术和方法的描 述；如果用到数据库管理系统，则还要对该系统进行 描述。又如，要指明怎样使用软件库工具、技术和方 法来处理软件产品的交付。
c. 编制关于程序及其有关文档的修改状态的文档。 因此必须进一步定义用于准备多种级别（如项目负责 人、配置控制小组、软件配置管理人员和用户）的管 理报告的工具、技术和方法。
4.4 配置的检查和评审
本条必须：
a. 定义在本计划的3.2条所定义的软件生存 周期的特定点上执行的检查和评审中软件配置 管理计划的作用；
b. 规定每次检查的评审所包含的配置项；
c. 指出用于标识和解决在检查和评审期间发 现的问题的工作流程。
5 工具、技术和方法
本章必须指明为支持特定项目的软件配置管理所 使用的软件工具、技术和方法，指明它们的目的，并 在开发者所有权的范围内描述其用法。例如，可以包 括用于下列任务的工具，技术和方法：

软件测试标准规范1目的为了确保软件产品质量,使产品能够顺利交付和通过验收,特编写本文档，以作参考2适用范围本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。

3职责➢项目测试负责人组织编制《测试计划》、《测试方案》,指导和督促测试人员完成各阶段的测试工作。

➢项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。

➢测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见➢项目负责人组织测试环境的建立.➢项目经理审核负责控制整个项目的时间和质量。

➢研发人员确认修改测试人员提交的bug。

4工作流程4.1 测试依据详细设计是模块测试的依据。

因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料.测试人员必须认真阅读，真正弄懂系统需求和详细设计.4.2 制订《测试方案》在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容:➢测试目的;➢所需人员及相应培训要求；➢测试环境、工具和测试软件;➢测试用例、测试数据和预期的结果.4.3 单元测试项目开发实现过程中,每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。

单元测试由单元开发者自己进行,使用白盒测试方法，根据程序单元的控制流程,争取达到分支覆盖.对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。

单元测试针对程序模块，从程序的内部结构出发设计测试用例。

多个模块可以独立进行单元测试。

➢单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等；➢单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试；➢单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改.4.4 集成测试编码开发完成，项目组内部应进行组装测试.集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。

文档编制规范目录文档编制规范 (1)一、文档的分类 (2)二、文档的编号 (2)三、文档编写的格式要求 (3)3.1、页面布局 (3)3.1.1、页边距 (3)3.1.2、页眉页脚 (3)3.2、首页标题及公司基本信息 (4)3.3、目录 (4)3.4、正文 (4)3.4.1、正文内容 (4)3.4.2、小标题级别 (4)3.4.3、图片与表格 (5)3.4.4、功能点与列表 (8)3.5、附件 (8)一、文档的分类将文档分成如下几类：1、规章制度类（编号：GZZD）：公司、部门的各项规章制度；2、工作规范类（编号：GZGF）：各部门的工作规范；3、项目管理规范类（编号：XMGL）：项目管理规范、药监项目管理规范、招投标系统开发与实施指南等；4、项目类文档（编号：XM）：包括项目各个过程的产出物，如合同（HT）、建设方案（FA）、需求文档（XQ）、设计文档（SJ）、操作手册（CZSC）、测试报告（CSBG）等；5、体系类（ISO9001、ISO27001、CMMI3）；6、知识类（编号：ZS）：各类技术经验总结等；7、产品类（编号：产品名称缩写）：如OA、Mis平台、电子招投标产品的介绍资料/操作手册等8、其他类（不需要编号）：上述7个类别之外的其它文档。

二、文档的编号文档的编号是文档唯一标识，主要用于文档的检索和版本控制。

文档编号规则如下：文档编号=文档所属部门代码+文档类别代码+文档流水号+版本号示例如下：例如：QYGL－GZZD －001 V2.12．1表示第二版第一次修改第一个文件规章制度企业管理部说明：1.部门代码为各部门的拼音首字母（公司的部门代码为GTXD）。

部门编码示例：企业管理部－QYGL、人力资源部－RLZY、行政部－XZ、开发部－KF（子部门为KF1、KF2类推）、实施部－SS（子部门SS1、SS3类推）、测试部－CS等；2.版本号使用2位数字进行声明，数字间使用英文标点“.”隔开。

计算机软件测试规范引言：计算机软件广泛应用于各行各业，确保软件质量和安全性对于用户的满意度和企业的声誉至关重要。

而软件测试规范作为软件开发和测试的指导，对于提高软件的质量和可靠性起到了重要的作用。

本文将重点介绍计算机软件测试规范的相关内容，包括测试策略、测试计划、测试用例设计以及测试执行的规范。

一、测试策略测试策略是软件测试的基础，它明确测试的目标、范围和方法，对软件测试的整体规划起到了指导作用。

在制定测试策略时，应该考虑以下几个方面：1. 定义测试目标：明确测试的目标，例如发现软件中的缺陷、评估软件的质量等。

2. 确定测试范围：明确测试的范围，包括功能测试、性能测试、安全测试等方面，并明确测试的时间和资源限制。

3. 制定测试计划：详细规划测试的时间安排、测试环境的准备、测试资源的分配等内容，确保测试工作有序进行。

4. 选择测试方法和技术：根据软件的特点和要求，选择适合的测试方法和技术，例如黑盒测试、白盒测试、自动化测试等。

二、测试计划测试计划是在测试策略的基础上，对测试活动进行具体规划的文件。

测试计划的编制应包含以下内容：1. 软件概述：对待测软件的背景、目标和功能进行简要描述，让测试人员对软件有一个全面的了解。

2. 测试目标和测试范围：明确测试的目标和范围，确保测试工作有重点，尽可能地覆盖所有可能出现问题的区域。

3. 测试资源和时间安排：明确测试需要的人力资源、硬件设备和测试环境，并规划测试的时间安排，确保测试人员有足够的时间和资源进行测试。

4. 测试进度和风险评估：制定详细的测试进度表，确保测试工作按时完成，并对可能遇到的风险进行评估和应对措施的制定。

5. 测试人员和责任分配：明确各个测试岗位的职责和测试人员的分工，确保测试团队的协作和高效运作。

三、测试用例设计测试用例是用来检验软件是否按照设计要求工作的一系列步骤和预期结果。

在测试用例设计时，应该遵循以下几个原则：1. 有效性和全面性：测试用例应覆盖软件的主要功能和边界条件，能够发现潜在的问题。

文档编制规目录文档编制规 (1)一、文档的分类 (2)二、文档的编号 (2)三、文档编写的格式要求 (3)3.1、页面布局 (3)3.1.1、页边距 (3)3.1.2、页眉页脚 (3)3.2、首页标题及公司基本信息 (4)3.3、目录 (4)3.4、正文 (4)3.4.1、正文容 (4)3.4.2、小标题级别 (4)3.4.3、图片与表格 (5)3.4.4、功能点与列表 (8)3.5、附件 (8)一、文档的分类将文档分成如下几类：1、规章制度类（编号：GZZD）：公司、部门的各项规章制度；2、工作规类（编号：GZGF）：各部门的工作规；3、项目管理规类（编号：XMGL）：项目管理规、药监项目管理规、招投标系统开发与实施指南等；4、项目类文档（编号：XM）：包括项目各个过程的产出物，如合同（HT）、建设方案（FA）、需求文档（XQ）、设计文档（SJ）、操作手册（CZSC）、测试报告（CSBG）等；5、体系类（ISO9001、ISO27001、CMMI3）；6、知识类（编号：ZS）：各类技术经验总结等；7、产品类（编号：产品名称缩写）：如OA、Mis平台、电子招投标产品的介绍资料/操作手册等8、其他类（不需要编号）：上述7个类别之外的其它文档。

二、文档的编号文档的编号是文档唯一标识，主要用于文档的检索和版本控制。

文档编号规则如下：文档编号=文档所属部门代码+文档类别代码+文档流水号+版本号示例如下：例如：QYGL－GZZD －001V2.12．1表示第二版第一次修改第一个文件规章制度企业管理部说明：1.部门代码为各部门的拼音首字母（公司的部门代码为GTXD）。

部门编码示例：企业管理部－QYGL、人力资源部－RLZY、行政部－XZ、开发部－KF（子部门为KF1、KF2类推）、实施部－SS（子部门SS1、SS3类推）、测试部－CS等；2.版本号使用2位数字进行声明，数字间使用英文标点“.”隔开。

首位数字表示第几个版本，末尾数字表示版本的第几次修改。

GB9386-88计算机软件测试文件编制规范计算机软件测试文件编制规范1引言1.1目的和作用本规范规定一组软件测试文件。

测试是软件生存周期中一个独立的、关键的阶段，也是保证软件质量的重要手段。

为了提高检测出错误的几率，使测试能有计划地、有条不紊地进行地进行，就必须要编制测试文件。

而标准化的测试文件就如同一种通用的参照体系，可达到便于交流的目的。

文件中所规定的内容可以作为对测试过程完备性的对照检查表，故采用这些文件将会提高测试过程的每个阶段的能见度，极大地提高测试工作的可管理性。

1.2事实适用对象及范围本规范是为软件管理人员、软件开发人员和软件维护人员、软件质量保证人员、审计人员、客户及用户制定的。

本规范用于描述一组测试文件，这些测试文件描述测试行为。

本规范定义每一种基本文件的目的、格式和内容。

所描述的文件着重于动态测试过程，但有些文件仍适用其它种类的测试活动。

本规范可应用于数字计算机上运行的软件。

它的应用范围不受软件大小、复杂度或重要性的限制，本规范既合用于初始开发的软件测试文件编制，也合用于其后的软件产品更新版本的测试文件编制。

本规范并不要求采用特定的测试方法学、技术及设备或工具。

对文件控制、配置管理或质量保证既不指明也不强制特定的方法学。

根据所用的方法学，可能需要增加别的文件（如“质量保证计划”）。

本规范既适用于纸张上的文件，也适用于其它媒体上的文件。

如果电子文件编制系统不具有安全的批准注册机制，则批准签字的文件必须使用纸张。

2引用标准GB/T 软件工程术语GB 8566计算机软件开发规范GB 8567计算机软件产品开发文件编制指南13定义本章定义本规范中使用的关键术语。

3.1设计层design level软件项的设计分解（如系统、子系统、程序或模块）。

3.2经由过程原则pass criteria判断一个软件项或软件特性的测试是否通过的判别依据。

3.3软件特征software feature软件项的显著特性。

@ by China Electronics Standardization Institute
计算机文档编制
中国电子技术标准化研究所
5.2 文档（编制）过程的关注点
• 文档编制计划 • 文档开发（编制） • 文档评审
@ by China Electronics Standardization Institute
@ by China Electronics Standardization Institute
计算机文档编制
中国电子技术标准化研究所
五、文档（编制）过程 5.1 概述
有两种主要类型的标准： a. 产品标准，它规定产品的特征和功能需求； b. 过程标准，它规定开发产品的过程。
计算机文档编制
中国电子技术标准化研究所
ＧＢ／Ｔ８５６７新老版本的主要差异
ＧＢ／Ｔ８５６７－２００6原则上适用于各种类型的开 发方法 ＧＢ／Ｔ８５６７－２００6描述了文档编制过程 ＧＢ／Ｔ８５６７－２００6给出２５种文档的编制格式 要求
１）可行性分析（研究）报告 ２）软件开发计划 ３）软件测试计划
ＧＢ／Ｔ８５６７新老版本的主要差异
４）数据要求说明书 ５）概要设计说明书 ６）详细设计说明书 ７）数据库设计说明书 ８）用户手册 ９）操作手册 １０）模块开发卷宗 １１）测试计划 １２）测试分析报告 １３）开发进度月报 １４）项目开发总结报告
@ by China Electronics Standardization Institute
@ by China Electronics Standardization Institute
计算机文档编制
中国电子技术标准化研究所
二、GB/T8567-2019制定的依据

软件测试流程规范软件测试是在软件开发过程中对软件进行评估和验证的重要步骤。

为了确保测试的有效性和可靠性，需要遵守一定的测试流程规范。

本文将介绍软件测试流程规范的主要内容和步骤。

1. 需求分析在进行软件测试之前，首先需要对软件需求进行详细的分析和理解。

了解软件的功能、性能、安全和可靠性等方面的需求，包括用户需求和技术需求。

这有助于明确测试的目标和范围。

2. 测试计划测试计划是软件测试的重要组成部分，它规定了测试的目标、策略、资源和时间安排等重要信息。

测试计划应该根据需求分析结果编制，并经过相关人员的审核和确认。

测试计划的编制需要充分考虑软件特性和测试环境等因素。

3. 测试设计在进行具体测试工作之前，需要进行测试设计。

测试设计的目的是根据测试计划中的要求，制定详细的测试方案和测试用例。

测试用例应该能够覆盖软件的各个功能模块和可能出现的异常情况。

测试设计需要遵循一定的规范和标准，以提高测试的有效性和效率。

4. 测试执行测试执行是软件测试的核心环节。

在测试执行过程中，需要根据测试设计中的测试用例，逐一执行测试，并记录测试结果和问题。

测试执行过程中，需要按照测试计划和要求，进行必要的测试环境配置和数据准备工作。

同时，测试执行也需要充分考虑测试的顺序和优先级。

5. 缺陷管理在测试执行的过程中，可能会发现软件存在缺陷或问题。

这些缺陷需要进行记录和跟踪管理，以便进行及时的修复和验证。

缺陷管理包括缺陷的登记、分析、分配、修复和验证等过程。

通过缺陷管理，可以提高软件质量，并保证软件测试的有效性和可靠性。

6. 测试评估测试评估是对软件测试过程进行总结和评价的环节。

通过测试评估，可以判断测试的有效性、可靠性和覆盖度等指标，并提出相应的改进建议。

测试评估可以由测试团队内部进行，也可以由外部独立的评估机构进行。

7. 测试文档在软件测试过程中，需要编制相应的测试文档，包括测试计划、测试设计、测试用例、测试报告等。

测试文档是对测试过程和结果的记录和总结，具有重要的参考价值。

软件开发技术文档编写规范在项目开发过程中，应该按要求编写好十三种文档，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。

◇可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。

◇项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。

◇软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。

它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。

该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。

◇概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。

◇详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。

◇用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。

◇测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。

计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。

◇测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。

◇开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。

◇项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。

概要设计说明书
引言
编写目的（阐明编写概要设计说明书的目的，指明读者对象。 ） 项目背景（可包括： （1）项目的委托单位,开发单位和主管部门； （2）该软件系统与其 他系统的关系。）
定义（列出文档中用到的专门术语定义和缩写词的原意。 ） 参考资料（列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源，可包 括：（1）项目经核准的计划任务书，合同或上机机关的批文； （2）项目开发计划；（3）需 求规格说明书；（4）测试计划（初稿）；（5）用户操作手册（初稿） ；（6）文档所引用的资 料、采用的标准或规范。 ）
（1）项目的计划任务书,合同或批文；（2）项目开发计划；（3）需求规格说明书； （3）概 要设计说明书；（4）测试计划（初稿）；（5）用户操作手册（初稿）；（5）文档所引用的其他 资料、软件开发标准或规范。 ）
． 总体设计
1． 需求概述
2． 软件结构（如给出软件系统的结果图。 ）
． 程序描述（逐个模块给出以下的说明:：）
3． 定义（列出本文档中用到的专门术语的定义和缩略词的原文。 ）
4． 参考资料（可包括：（1）项目经核准的计划任务书、合同或上级机关的批文； （2）文档 所引用的资料、 规范等；列出资料的作者、 标题、编号、发表日期、 出版单位或资料来源。 ） ．项目概述
1.工作内容（简要说明项目的各项主要工作,介绍所开发软件的功能 性能等.若不编写可行性 研究报告,则应在本节给出较详细的介绍。）
用户操作手册
一． 引言
1． 编写目的（阐明编写手册的目的，指明读者对象。 ）
2． 项目背景（说明项目的来源、委托单位、开发单位及主管部门。 ）
3．定义（列出文档中用到的专门术语定义和缩写词的原文。 ）
4．参考资料（可包括： （1）项目经核准的计划任务书,合同或上机机关的批文； （2）项目开 发计划；（3）文档所引用的资料，标准和规范。列出这些资料的作者、标题、编号、发表 日期、出版单位或资料来源。 ）