项目文档
内存错误-国际信号
2023年2月20日发(作者：东莞情事)最全！软件开发类项⽬关键⽂档内容要求
前⾔
之前在软件需求，概要设计，详细设计（⽂档）怎么做，做什么？中做了三个⽂档的⼀些主要内容的介绍。⽽我曾尝试在⽹上找寻这些内容，最
后都被搜索都内容误导了不少。但是真正的项⽬管理中，我们所需要的⽂档远远远远不⽌这三个⽂档。这⾥包括15类项⽬⽂档：
1软件开发计划
2需求规格说明书
3软件概要设计说明
4数据库设计说明
5软件详细设计说明
6可执⾏程序⽣成说明
7软件测试计划
8软件测试说明
9软件测试报告
10安装部署⼿册
11源代码交付说明
12上线部署⽅案
13上线部署实施报告
14软件终验测试⽅案
15软件终验测试报告
在本篇⽂章中就将对这15类项⽬⽂档做⼀个完整的内容介绍要求。完全可以复⽤到其他项⽬中去使⽤。这⾥着眼于内容要求，对于具体的项⽬⽽
⾔，⽂档名称可能存在不同的称谓，也允许⽂档的分拆和合并，但⽂章中所述内容要求应得到体现。
格式要求
所有⽂档应包括封⾯、⽂档变更记录、⽬录和正⽂四个部分。封⾯应包括⽂档提供⽅的名称、项⽬名称、项⽬阶段、⽂件名称、⽂件版本和总页
数。应有⽂档维护记录。发⽣重⼤版本变更时，应保存不同版本的技术⽂档，同时应保存必要的变更说明和变更审核记录。
1软件开发计划
(⼀)⽂档内容要求
1引⾔
1.1标识
本条应包含本⽂档的完整标识，以及本⽂档适⽤的系统和软件的完整标识，包括标识号、标题、缩略词语、版本号和发⾏号。
1.2系统概述
本条应简述本⽂档适⽤的系统和软件的⽤途，应描述系统和软件的⼀般特性；概述系统开发、运⾏和维护的历史；标识项⽬的业主⽅、⽤户、承建
⽅、监理⽅等；标识当前和计划的运⾏现场等。
1.3⽂档概述
概述本⽂档的⽤途和内容，并描述与其使⽤有关的保密性和私密性的要求。
1.4与其他计划之间的关系
描述本计划和其他项⽬管理计划的关系。
1.5输⼊基线
给出编写本项⽬开发计划的输⼊基线，如业务需求说明书等。
2引⽤⽂件
应列出本⽂档引⽤的所有⽂档的编号、标题、修订版本、⽇期和来源。
3.项⽬范围及约束条件
3.1交付产品
列出本项⽬的交付产品成果，包括软件程序、交付⽂档等，以及各交付成果的交付期限。
3.2业务需求和约束条件
分条阐述项⽬的业务需求和约束条件；
3.3其它⽅⾯的需求和约束条件
分条阐述其它⽅⾯的约束，如项⽬进度要求、保密性等。
3.4项⽬⽬标
综述项⽬进度⽬标、成本⽬标、质量⽬标。
4项⽬总体计划
4.1软件开发过程和⾥程碑
描述要采⽤的软件开发过程。计划应覆盖论及它的所有合同条款，确定已计划的开发阶段(适⽤)、⽬标和各阶段要执⾏的软件开发活动。
⾥程碑设置分条阐述⾥程碑/阶段名称、期限、⾥程碑标志说明（进⼊条件和输出）、评审⽅式等。
提供⼀张⼯作产品矩阵表，描述各⼯作产品的编号、名称、产⽣阶段、评审⽅式等。⼯作产品包括各阶段产⽣的过程⽂档和技术⽂档等，是⼯
作任务分解和配置管理计划制定的重要依据。
4.2软件开发⽅法
描述或引⽤要使⽤的软件开发⽅法，包括为⽀持这些⽅法所使⽤的⼿⼯、⾃动⼯具和过程的描述。
4.3软件产品标准
描述或引⽤在表达需求、设计、编码、测试⽤例、测试过程和测试结果⽅⾯要遵循的标准和要求。对要使⽤的各种编程语⾔应提供编码标准。
4.4评审途径
阐述软件内部评审的⽅式，以及需⽅或授权代表（总集、监理）实施软件产品和活动评审的途径和⽅式。
4.5软件配置管理
描述针对本项⽬所采⽤和遵循的软件配置管理⽅法.包括配置项的标识、控制、状态统计、审核、交付等。具体的配置项识别和管理可在配置管
理计划中另⽂给出。
4.6软件质量保证
描述针对在本项⽬所采⽤和遵循的软件质量保证⽅法。包括软件质量保证评估、软件质量保证记录和处理、第三⽅独⽴性保证等。质量保证计
划也可另⽂给出。承建⽅应在计划中落实下述内部审核和检查⼯作：
软件计划审核：在软件计划编制阶段结束后必须进⾏软件计划审核，以确保在软件开发计划、软件配置管理计划、软件质量保证计划中所规定
的计划的合适性。
软件需求审核：在软件需求分析阶段结束后必须进⾏软件需求审核，以确保在软件需求规格说明中所规定的各项需求的合适性。
软件概要设计审核：在软件设计结束后必须进⾏软件设计的审核，以评价软件概要设计说明、数据结构设计说明中所描述的软件设计在总体结
构、外部接⼝、主要部件功能分配、全局数据结构以及各主要部件之间的接⼝等⽅⾯的合适性；以及在数据结构、功能、算法和过程描述等⽅
⾯的合适性。
软件详细设计、编码阶段的审核：在软件详细设计和编码实现完成之后要对软件详细设计说明、软件测试计划、软件测试说明（含软件测试⽤
例）、⽬标程序⽣成说明进⾏审核，以确认业主⽅的业务需求是否得到满⾜，验证软件需求规格说明中的需求是否已由软件设计说明描述的设
计实现，软件设计说明表达的设计是否已由编码实现。
出⼚测试审核：在完成出⼚测试之后要对源代码交付验证说明、软件测试报告（含源代码交付验证报告）以及按照合同要求应提交给业主⽅的
所有⽂档（如：软件⽤户⼿册等）进⾏审核，以评价待交付的程序及⽂档的质量是否满⾜出⼚交付要求、覆盖了业主⽅的业务需求、做好了交
付准备。
部署审核：在配合监理⽅和业主⽅完成测试⼯作后承建⽅进⼊系统部署阶段，在完成软件部署并配合完成系统联调联试后，要对部署实施报告
进⾏审核，以验证部署实施的真实性以及外部接⼝的正确性。
4.7问题跟踪和处理(更正活动)
描述软件更正活动中要遵循的⽅法，包括不同阶段的问题发现、纪录、报告、处理、审核和更正流程，问题/bug跟踪系统的选⽤等。须论及出⼚
测试、需⽅验证测试、试运⾏三个阶段。
4.8档案收集
阐述作为承建⽅在项⽬进⾏过程中进⾏⾃⾝档案收集管理的⽅法，包括纸质档案。
5项⽬估算及进度计划
5.1⼯作任务分解
分解项⽬⼯作任务，得出⼯作任务分解结构（WBS）。
5.2规模估算
估算项⽬规模，如需新编的代码⾏数、⽂档页数等。
5.3⼯作量估算
根据规模估算及项⽬经验，估算项⽬⼯作量。
5.4进度计划
在⼯作任务分解结构（WBS）、⼯作量估算的基础上，进⾏活动排序、资源分配，进⽽编制进度计划⽢特图,标识各活动的依赖关系、资源分配情
况、起⽌时间等。
5.5风险估计及应对⽅法
逐条给出识别的风险及其风险估计量化指标（可能性、严重性等级）、相应的对策和缓解⽅案。建议以列表的⽅式给出。
6项⽬跟踪与变更管理
6.1项⽬⽇常跟踪
阐述项⽬⽇常跟踪⽅法，包括由业主⽅和授权代表(监理⽅)参与的项⽬跟踪。
6.2⾥程碑评审
阐述或引⽤项⽬各⾥程碑评审的⽅法。
6.3变更管理
包括计划变更、需求变更等的处理流程、机制和⽅法。
7项⽬组织和资源
7.1项⽬组织
本条应描述本项⽬要采⽤的组织结构，包括涉及的组织机构、机构之间的关系、执⾏所需活动的每个机构的权限和职责。
7.2项⽬资源
本条应描述适⽤于本项⽬的资源。主要包括：
a.⼈⼒资源，分条说明投⼊此项⽬的⼈员、职责、投⼊阶段、地理位置和涉密程度等；
b.开发⼈员要使⽤的设施，包括执⾏⼯作的地理位置、要使⽤的设施、保密区域和运⽤合同项⽬的设施的其他特性；
c.为满⾜合同需要，需⽅应提供的设备、软件、服务、⽂档、资料及设施及需要提供的时间。
8内部培训
根据项⽬的技术要求和项⽬成员的情况，确定是否需要进⾏项⽬培训，并制订培训计划。如不需要培训，应说明理由。
9注解
本章应包含有助于理解本⽂档的⼀般信息(例如原理)。本章应包含为理解本⽂档需要的术语和定义，所有缩略语和它们在⽂档中的含义的字母序列
表。
附录
附录可⽤来提供那些为便于⽂档维护⽽单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编
排。
(⼆)内容审核要点：
1．项⽬范围阐述与合同及其附件要求等是否⼀致；
2．⼯作任务分解与项⽬范围/需求是否⼀致；
3．⼯作任务分解、⼯作量估计和活动进度安排是否合理；
4．计划内容是否包括软件项⽬管理的各个必要的⽅⾯；
5．⼯作产品定义是否包含需⽅所要求的各相关必要⽂档；
6．组织机构和⼈⼒资源安排和分配是否合理并符合合同相关要求；
7．项⽬⽇常跟踪管理是否具有可操作性；
8．项⽬开发过程中的问题/bug处理机制是否具有可操作性；
9．档案收集管理是否具有可操作性。
10．是否制定了合适的配置管理策略和质量保证策略。
2软件需求规格说明书
（⼀）⽂档内容要求
1引⾔
1.1编写⽬的
说明编写这份⽤户需求说明书的⽬的，指出预期的读者范围。
1.2范围
说明系统的业务范围以及功能界限的划分。
1.3术语和缩略语
提供此⽂档中⽤到的专门术语的定义和缩写词的原词组。
1.4参考资料
列出此⽂档所参考的⽂档。这些⽂档可以是合同、标准、指南、和其他的⽤户需求说明书。
2需求概述
2.1项⽬背景
提供对项⽬的整体描述。如果此⽂档定义的项⽬是⼀个更⼤的项⽬的⼀个构件，应提供同更⼤项⽬或系统的关系和这个项⽬会提供的功能。并且提
供和明确两者之间的关系。
2.2操作环境
描述使软件运⾏的运⾏环境。给出了软件运⾏所需的硬件平台、操作系统和软件平台等细节。
如果功能/⼦模块/⼦项⽬涉及仅仅是整体的产品/项⽬、硬件/软件环境的⼦集，也在这⾥指出。
2.3设计和实现限制
包括客户在所采⽤的技术和运⾏环境等⽅⾯的特定要求，以及其它影响开发⼈员⾃由选择的问题，必要时说明原因。
2.4假设、依赖和外部风险
明确在准备此⽂档时所做的假设和外部依赖条件，这些假设会影响需求的状态。
对外部项⽬或软件的接⼝服务的依赖条件也可在这⾥说明。
明确客户应该会关⼼的外部风险，如：第三⽅供应的软件和硬件应该准时送到、所依赖软件是否按时提供等等。
对需求优先等级的定义也需要给出。
3功能需求
以下详细描述系统功能需求。如果需要，⽤例图及其描述可以作为附录。功能点、⼦功能或功能可以指定缺省优先级。
3.1
所有的功能名、⼦功能名、功能点都需要以某种全⽂档唯⼀的⽅式进⾏编号，以备审核、设计、实现、测试时引⽤。功能、⼦功能都要规定优先等
级。
3.1.1功能概述
对本功能进⾏概要描述。如有需要，可⽤结构图来描述本功能中各模块的结构关系。
3.1.2相关业务流程
根据需要，提供相应的业务流程图。
3.1.3
3.1.3.1⼦功能描述
对⼦功能作⽂字描述。如果需要，对⼦功能流程进⾏流程描述，并提供⼦功能业务流程图。
3.1.3.2
对于每⼀功能点，需要具体描述其各种需求，由下列部分组成，可以以表格的形式给出：
a.功能点编号
b.功能点描述
具体描述该功能点所提供的功能。
c.操作
这⾥说明⽤户要求的常规的和特殊的操作。
d.输⼊
描述该功能的所有输⼊数据，如输⼊源、数量、度量单位、时间设定和有效输⼊范围等。
e.输出
详细描述该功能的所有输出数据，如输出⽬的地、数量、度量单位、时间关系、有效输出范围、⾮法值的处理、出错信息等。
f.业务表单
如果需要，描述该模块所涉及的业务表单。
g.处理或算法
定义获得预期输出结果的全部操作，包括输⼊数据的有效性检查、操作的顺序、异常情况的响应、把输⼊转换成相应输出的⽅法、输出数据的有效
性检查等。
f.数据库要求
如果需要，指出对于数据库表设计⽅⾯的要求
3.1.3.3功能需求
……
3.1.4功能需求
……
3.2功能需求
……
4外部接⼝需求
所有接⼝都必须提供唯⼀标识。
4.1⽤户接⼝
提供⽤户使⽤软件产品时的接⼝需求。例如，如果系统的⽤户通过显⽰终端进⾏操作，就必须指定如下要求：
a．对屏幕格式的要求；
b．报表或菜单的页⾯格式和内容；
c．程序功能键的可⽤性。
屏幕接⼝要求细节很多，建议提供界⾯demo。
4.2硬件接⼝
要指出软件产品和系统硬部件之间每⼀个接⼝。包括⽀撑什么样的设备，如何⽀撑这些设备，有何约定。
4.3软件接⼝
需要说明3⽅⾯的软件接⼝内容：
1．说明需使⽤的其他软件产品（例如，数据管理系统、⼯作流软件、中间件产品等）；
2．说明需要使⽤到的其它应⽤软件系统所提供的接⼝功能；
3．说明需要提供出来供其它应⽤软件系统调⽤的公⽤接⼝功能服务。对这些接⼝要尽量做形式化描述。
5.成品软件定制需求：
如果本项⽬是在成熟的成品软件基础上进⾏进⼀步的定制开发，需要在此说明本项⽬所依据的成品软件版本。并根据成品软件的功能，对照本项⽬
需求，以列表的⽅式明确说明哪些功能点需要进⾏进⼀步的定制开发。
6.性能需求
以下详细说明软件各项性能需求，(如适⽤)包括以下⽅⾯。
6.1数据容量
根据实际情况，确定数据容量。
6.2时间特性
说明系统在响应时间、更新处理时间、数据转换与传输时间、运⾏时间等⽅⾯所需达到的时间特性。
6.3吞吐量
系统需要⽀持并发的处理能⼒。
6.4安全性
系统安全⽅⾯的需求描述。
6.5其它质量属性
指明软件产品在可靠性、可移植性、实⽤性、可维护性等⽅⾯的⽬标和需求。应尽量以明确的、量化的、可检验的⽅式来描述。
7.其他需求
7.1可测试性需求
指出可测试性⽅⾯的需求。如对于只能在⽣产环境才能满⾜的测试条件，如何在出⼚测试时⽤变通的⽅式解决。
7.2安装和操作
定义软件安装和操作⽅⾯的需求，例如安装的环境要求，以及安装的⽅式等。
7.3安全保密
定义有关产品安全保密⽅⾯的要求和说明。如果没有这⽅⾯的要求，注明⽆安全保密性要求。
7.6维护服务
对软件的升级、维护以及服务⽅⾯的需求说明，包含维护⽅式和提供服务的⽅式，以及服务的质量要求，时间要求等。
8辅助部分
8.1未确定的问题
说明⽬前尚未确定的问题，以及对这些问题的处理的计划。
8.2风险分析
说明本项⽬⾯临的主要风险，例如需求可实现性、需求变动、时间压⼒、技术复杂度、⼈⼒资源不⾜等，并提出规避或预防措施。
8.3编程⼯具
说明对开发的⼯具要求，包含编程语⾔，使⽤的开发环境，以及其中涉及到的其它⼯具的要求，例如建模⼯具，分析⼯具，配置管理⼯具等。
8.4其它⽀撑软件
软件运⾏说必需的环境的说明，包含软件使⽤到地第三⽅的组件以及应⽤程序的说明。
9项⽬的交付
9.1交付形式
项⽬的交付⽅式的说明，包含交付的产品、⽂档，以及交付的⽅式等。
9.2测试要求
说明需要对⽬标系统进⾏哪些⽅⾯的测试，如功能测试、集成测试、压⼒测试等，以及各种测试的功能覆盖⾯要求。
（⼆）内容审核要点：
1．功能描述是否完备，是否通盘考虑了业务需求说明书所述内容；
2．⽂档内容是否充分反应了与⽤户的沟通成果；
3．功能描述是否明确，是否有⼆义性、含糊的或相互⽭盾的需求内容；
4．功能点是否细化到合理程度；
5．对外接⼝服务的描述是否全⾯并细化到合理程度；
6．对于外部依赖条件的描述是否准确全⾯；
7．是否提供了⽤户所需的⼈机界⾯的必要描述（如以demo⽅式）；
9．对性能指标是否进⾏了必要的说明；
10．是否给出了必要的数据库设计⽅⾯的要求；
3软件概要设计说明
（⼀）⽂档内容要求
1引⾔
1.1编写⽬的
说明编写这份概要设计说明书的⽬的，指出预期的读者。（对于由多个⼦系统构成的系统，可以根据需要针对⼦系统编写单独的软件概要设计说
明）
1.2背景
说明：
a．待开发软件系统的名称；
b．列出此项⽬的任务提出者、开发者、⽤户以及将运⾏该软件的位置；
1.3术语和缩略语
列出本⽂件中⽤到的专门术语的定义和外⽂⾸字母组词的原词组。
1.4参考资料
列出有关的参考⽂件，如：
a．本项⽬的经核准的计划任务书或合同，上级机关的批⽂；
b．属于本项⽬的其他已编制⽂件；
c．本⽂件中各处引⽤的⽂件、资料，包括所要⽤到的软件开发标准、专业技术标准。列出这些⽂件的标题、⽂件编号、发表⽇期、出版单位和来
源。
2总体设计
2.1需求规定
说明对本系统的主要的输⼊输出项⽬、处理的功能性能要求。可以引⽤软件规格说明⽂档以避免重复。
2.2运⾏环境
简要地说明对本系统的运⾏环境（包括硬件环境和⽀持环境）的规定。
2.3设计思想
2.1.1系统构思
说明本系统设计的系统构思。
2.1.2关键技术与算法
说明本系统设计采⽤的关键技术和主要算法。
2.1.3关键数据结构
简要说明本系统实现中的最主要的数据结构。
2.2系统总体结构
以图表的形式说明本系统的系统元素（各层模块、⼦模块、公⽤模块等）的划分，扼要说明各系统元素的标识和功能，分层次说明各系统元素之间
的关系。
2.3基本处理流程
2.3.1系统流程图
⽤流程图的⽅式说明本系统的主要控制流程和处理流程。
2.3.2数据流程图
根据需要，⽤数据流程图说明本系统的主要数据及其流转过程，并说明流转过程中的处理动作。
2.4功能需求与模块的关系
说明各项功能需求的实现同各模块的分配关系。要与软件规格说明中的功能编号相⼀致。
2.6尚未解决的问题
说明在概要设计过程中尚未解决⽽设计者认为在系统完成之前必须解决的各个问题。
3接⼝设计
3.1外部接⼝
说明本系统同外界的所有接⼝设计。包括本系统与硬件之间的接⼝设计、本系统与各⽀持软件之间的接⼝设计、对外提供的接⼝服务的设计。
3.2内部接⼝
说明本系统之内的各个系统元素之间的接⼝的安排。
4性能设计及质量属性考虑
通过设计落实在软件规格说明中的各种性能及质量属性规定。
5数据库设计
说明本系统内所使⽤的数据结构设计要点及与程序模块间的关系。对数据库表的设计⼀般以另⽂⽅式（数据库设计说明）给出。
（⼆）内容审核要点：
1．是否全⾯考虑了软件需求规格说明⽂档的功能需求；
2．所述功能名称及编号与软件需求规格说明⽂档是否⼀致；
3．总体结构是否清晰合理；
4．是否包括对外提供的接⼝服务的形式化表述和设计内容；
5．数据结构设计内容的全⾯性及合理性；
4数据库设计说明
(⼀)⽂档内容要求
1概述
1.1编写⽬的
描述该⽂档的编写⽬的。
1.2参考资料
列出此⽂档所参考的⽂档，如软件需求规格说明、软件设计说明等。
1.3分类
（若有）对存储数据分类进⾏简要说明（数据可以按照⼦系统进⾏划分）。
·第全局类数据及其说明
·第⼆类数据及其说明
·第三类数据及其说明
…
1.4使⽤它的程序
描述对应不同分类的数据，所使⽤它的外部程序或者业务系统。
1.5约定
描述数据库设计⽅⾯的标识约定、设计约定、特殊约定等。
2数据定义
2.1全局数据
主要应⽤范围：
作⽤：
数据库定义⽂件：
ER图⽂件：
2.1.1表结构设计
2.1.1.1表⼀与触发器
表⼀结构说明，包括：表名、表说明（内容、作⽤）、索引、各列属性。
各列属性，包括：列英⽂名、列中⽂名、数据类型、长度、列取值含义等。
触发器列表，包括：名称、说明、定义等。
2.1.1.2表⼆与触发器
……
2.1.2视图设计
2.1.2.1视图⼀
定义：
⽤途：
2.1.2.1视图⼆
……
2.1.3存储过程设计
2.1.3.1过程⼀
定义：
⽤途：
输⼊：
输出：
2.1.3.2过程⼆
……
2.2第⼆类数据
主要应⽤范围：
作⽤：
数据库定义⽂件：
ER图⽂件：
2.2.1表结构设计
……
2.2.2视图设计
……
2.1.3存储过程设计
……
3数据库⾓⾊定义
3.1第⼀类⾓⾊
⾓⾊职能：
⾓⾊权限：
3.2第⼆类⾓⾊
……
4数据库安全设计
针对数据库安全⽅⾯的要求进⾏的设计，包括保密性、安全性等⽅⾯。
5数据库备份设计
针对数据的备份要求，描述数据库的备份策略、备份和恢复的⼿段、备份计划、操作步骤等⽅⾯的内容。
(⼆)内容审核要点：
1．本⽂档内容与软件设计⽂档、软件需求⽂档是否⼀致性；
2．所述内容是否完备；
3．本⽂档内容本⾝是否前后⼀致；
4．表结构描述是否清楚明确；
5．（若有）触发器描述是否清楚明确；
6．（若有）视图描述是否清楚明确；
7．（若有）存储过程描述是否清楚明确；
8．数据库⾓⾊设置是否清楚合理。
9．是否满⾜了安全、备份的要求。
5软件详细设计说明
（⼀）⽂档内容要求
1引⾔
1.1编写⽬的
说明编写这份详细设计说明书的⽬的，指出预期的读者范围。
1.2背景
说明：
a．待开发的软件系统的名称；
b．列出本项⽬的任务提出者、开发者、⽤户以及将运⾏该项软件的单位。
1.3术语和缩略语
列出本⽂件中⽤到的专门术语的定义和缩写词的原词组。
1.4参考资料
列出要⽤到的参考资料，如：
a．本项⽬的经核准的计划任务书或合同、上级机关的批⽂；
b．属于本项⽬的其他已发表的⽂件，包括软件需求说明书、软件概要设计说明等；
c．本⽂件中各处引⽤的⽂件、资料，包括所要⽤到的软件开发标准。
列出这些⽂件的标题、⽂件编号、发表⽇期和出版单位，说明能够得到这些⽂件资料的来源。
2系统结构
以表格⽅式列出本程序系统内的每个程序（包括每个模块和⼦程序）的名称、标识符和它们之间的层次结构关系。并⽤⽂字说明每个程序完成的功
能，以及互相之间的调⽤关系。
3程序1（标识符）设计说明
从本章开始，逐个地给出各个层次中的每个程序的详细设计。以下给出的提纲是针对⼀般情况的。对于⼀个具体的模块，可能根据需要在其说明条
⽬上有适当增减。
3.1程序描述
给出对该程序的简要描述，主要说明安排设计本程序的⽬的意义，并且说明本程序的特点。
3.2功能
说明该程序应具有的功能，可采⽤IPO图（即输⼊－处理－输出图）的形式。
3.3性能
说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。
3.4输⼊项
给出对每⼀个输⼊项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输⼊的⽅式、数量和频度、输⼊媒体、输⼊数据的来源和
安全保密条件等等。
3.5输出项
给出对每⼀个输出项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输出的形式、数量和频度、输出媒体、对输出图形及符号
的说明、安全保密条件等等。
3.6算法
详细说明本程序所选⽤的算法，具体的计算公式和计算步骤。
3.7流程逻辑
⽤图表（例如流程图、判定表等）辅以必要的说明来表⽰本程序的逻辑流程。
3.8接⼝
⽤图的形式说明本程序所⾪属的上⼀层模块及⾪属于本程序的下⼀层模块、⼦程序，说明参数赋值和调⽤⽅式，说明与本程序相直接关联的数据结
构。
3.11限制条件
说明本程序运⾏中所受到的限制条件。
3.12单元测试
说明对本程序进⾏单元测试的计划和⽅式，包括单元测试⽤例的设计等。
3.13尚未解决的问题
说明在本程序的设计中尚未解决⽽设计者认为在软件完成之前应解决的问题。
4程序2（标识符）设计说明
．．．．．．
（⼆）内容审核要点：
1．本⽂档内容与概要设计说明、软件需求规格说明等⽂档中的内容是否⼀致性；
2．所述内容是否完备；
3．各⼦程序模块描述是否清楚；
4．是否有必要的单元测试⽤例编制⽅⾯的考虑；
5．程序模块间关系是否清楚准确。
6可执⾏程序⽣成说明
（⼀）⽂档内容要求
1概述
1.1编写⽬的
说明编写⽬的。本⽂档主要供开发⽅项⽬组内部使⽤，其⽬的包括：
a．便于项⽬组测试⼈员通过版本控制机制，每次⽣成新的⽬标程序在⼲净的环境下进⾏⾃测（包括出⼚测试）；
b．便于今后源代码的交付。
1.2背景
说明软件系统的名称和作⽤，以及本可执⾏程序属于软件系统的哪⼀部分。
1.3参考资料
列出所参考的⽂档，如需求规格说明、设计说明等。
2⼯具和⽀撑软件要求
指出⽬标程序⽣成的⼯具要求，如对于使⽤ant脚本⽣成⽬标程序的⽅式，需要ant⼯具的⽀持。
指出⽬标程序执⾏的⽀撑软件要求，如虚拟机、应⽤服务器或其它底层软件⽀持。
注：建议尽量提供⽣成脚本⽽不依赖于可视化开发⼯具来⽣成⽬标代码，以便于测试⽅能根据版本控制库中的源码迅速⽣成⽬标程序进⾏测试和回
归测试。
3源代码获取
指出从何处及如何获取源代码，包括脚本程序代码。⼀般情况下，在开发团队内部，源代码的获取⽅法和步骤与项⽬源代码配置管理⽅式相关。
4⽬标程序⽣成步骤
详细说明⽬标程序⽣成步骤，步骤的多少与项⽬复杂度、所编制脚本功能强弱等因素相关。
注：不管步骤多少，整个步骤应是明确和完备的，并提供⽅便的清除所⽣成⽬标程序的⽅法。
5⽬标程序的执⾏
说明如何运⾏⽣成的⽬标程序，⼀般包括以下内容：
。从何处获取⽣成的⽬标程序；
。执⾏前的准备⼯作，如配置⽂件的修改、数据库表定义/删除的脚本的执⾏、数据库表的初始化数据⽣成/清除脚本的执⾏等；
。软硬件运⾏环境的建⽴；
。程序的部署和执⾏。
（⼆）内容审核要点：
1．所述各⽬标程序⽣成说明⽂档是否涵盖项⽬整个软件系统；
2．所述步骤是否明确和详细；
3．是否内部有版本控制机制。
7．软件测试计划
（⼀）⽂档内容要求
1范围
1.1标识
本条应包含本⽂档及本⽂档适⽤的系统和软件的完整标识，(若适⽤)包括标识号、标题、缩略词语、版本号和发⾏号。
1.2系统概述
本条应简述本⽂档适⽤的系统和软件的⽤途，它应描述系统和软件的⼀般特性；概述系统开发、运⾏和维护的历史；标识项⽬的开发⽅、业主⽅、
总集⽅、监理⽅等；标识当前和计划的运⾏现场等。
1.3⽂档概述
本条应概述本⽂档的⽤途和内容，并描述与其使⽤有关的保密性和私密性的要求。
2引⽤⽂档
应列出本⽂档引⽤的所有⽂档的编号、标题、修订版本、⽇期和来源。
3术语和定义
提供此⽂档中⽤到的专门术语的定义和缩写词的原词组。
4测试⽬标和测试内容
4.4测试⽬标
描述本测试计划的测试⽬标。如完成软件的出⼚测试，达到可交付验证测试的⽬的。
4.1测试的功能和特性
概要说明本次需要测试的功能和特性
4.2不测的功能和特性
说明本次不测的功能、特性及原因
4.4测试质量⽬标
简要说明测试的质量⽬标,如：
(1)测试计划中所有测试⽅法和模块已经执⾏通过
(2)所有的测试案例已经执⾏过
(3)所有的重要等级Bug已经解决并由测试验证
5.应交付的测试成果⽂档
说明最终需要交付的测试成果⽂档，包括软件测试计划、软件测试说明(含测试⽤例)、软件测试报告、测试问题报告等。⽂档名和数量因具体
项⽬⽽异，应确定⽂档责任⼈。
6.测试策略
6.1整体测试策略
说明基本的测试过程和策略。如测试⼈员在需求和设计阶段参与需求评审和设计评审、在开发完成前实施测试案例设计和测试开发，在系统开
发完成之后正式执⾏测试等。
6.2问题等级划分
划分软件缺陷的等级分类代码。推荐的等级划分如下：
6.3开始/中断/完成标准
6.3.1测试启动条件
说明启动测试的条件。如对于出⼚测试，已经过评审、测试⼈⼒资源已经具备、软件需求规格说明/详细设计⽂档/测试说明⽂档已经过确认、内部
模块测试和组装测试已经完成等。
其中业主⽅、总集⽅、监理⽅交付验证测试的准⼊条件：
a)软件源代码正确通过编译且为最终版本；
b)软硬件测试平台已搭建并已配置完成；
c)业主⽅具有测试所需的各种⽂档（纸质、电⼦版）；
d)业主⽅获得的各种⽂档均与最终版本的软件相对应，且全部通过审核；
e)承建⽅、监理⽅已完成测试并提交测试报告。
6.3.2测试中断条件
说明测试中断的条件。例如：
１．在测试中发现A类bug，并导致后续的测试⽆法继续时；
２．已执⾏完所有的测试⽤例，并已报告给承建⽅，等待承建⽅在限期内改正时。
6.3.３测试终⽌条件
说明在什么条件下终⽌本计划所述产品交付验收证测试。如：
1.正常终⽌条件：
a)按照测试计划完成所有定义的测试⽤例；
b)客观、详细地记录了软件测试过程和软件测试中发现的问题；
c)有效完成了定位缺陷的回归测试循环；
d)测试中未发现A、B缺陷，以及少于n个C类缺陷；
e)提交测试报告。
2.异常终⽌条件
太多的A或B类缺陷以致测试⽆法进⾏或测试周期已结束。
或者针对软件规模，规定C类bug不超过n个
6.4测试⼯具选择
说明需要⽤到的测试⼯具软件，应包括软件版本号。
6.5测试流程
阐述或引⽤测试流程，应包括问题报告、审核、分配、跟踪、回归等各⽅⾯。测试流程与承建⽅内部质量管理制度和业主⽅的要求相关。
6.6测试技术和⽅法
确定测试需要的技术或⽅法，如测试数据⽣成与验证技术、测试数据输⼊技术、测试结果获取技术等；明确测试⽤例的设计和选择⽅法，针对
不同类型的测试(功能测试、性能测试、容量测试、⽤户界⾯测试),根据需要，应给出针对性的测试⽤例设计要求。
6.7评价准则和⽅法
6.7.1测试通过准则
定义系统测试通过准则，以下是⼀个测试通过准则的⽰例：
1．可执⾏软件与需求规格说明书、设计说明书是⼀致的；
2．测试覆盖率应达到100%
3．测试⽤例通过率要达到95%；
4．软件缺陷终结率达到100%
5．系统页⾯风格符合规范化要求，程序代码编写以及各种命名符合规范化要求。
6．各模块正确衔接。
7．对异常数据应有相应的提⽰信息，并能安全终⽌异常操作。
6.7.2对测试结果处理⽅法
测试结果分为通过和未通过。测试达到通过准则的要求称为“通过”，测试结果没有达到测试通过准则的称为“未通过”。说明对不同测试结
果的处理⽅法。
3.测试项⽬组织与资源
7.1参与部门和组织
说明参与测试的组织/部门
7.2⾓⾊和职责
说明参与测试的组织/部门中各⾓⾊划分及职责。
7.3⼈员和培训要求
说明参与测试的组织/部门的员及⾓⾊对应关系。以及是否需要预先进⾏相关培训。
7.4关键资源
说明需要⽤到的关键资源
4.测试活动和进度计划
应根据测试资源和测试项⽬内容，分解测试活动，分配测试资源，编制测试进度计划。以下是⼀个进度计划的⽰例：
8风险分析及应对措施
风险分析是评测项⽬管理的重要内容。常见的风险包括供测试的软件版本混乱、软件缺陷修改时间过长、回归不⾜引发新的问题、测试⽅和开发⽅
对缺陷的认识存在差异等。建议以列表的⽅式给出识别的风险并提供针对性的缓解措施。
（⼆）内容审核要点：
1．测试内容是否完整，是否涵盖了测试⽬的、内容、⽅法策略、资源、进度安排等各⽅⾯；
2．测试进度安排是否合理；
3．测试资源要求是否充分；
4．测试技术和⽅法的选择是否可⾏；
5．是否包含了对测试结果评价分析标准；
6．是否包含了对测试过程的跟踪和控制规程。
8软件测试说明
（⼀）⽂档内容要求
1范围
1.1标识
本条应包含本⽂档及本⽂档适⽤的系统和软件的完整标识，(若适⽤)包括标识号、标题、缩略词语、版本号和发⾏号。
1.2系统概述
本条应简述本⽂档适⽤的系统和软件的⽤途，它应描述系统和软件的⼀般特性；概述系统开发、运⾏和维护的历史；标识项⽬的开发⽅、业主⽅、
总集⽅、监理⽅等；标识当前和计划的运⾏现场等。
1.3⽂档概述
本条应概述本⽂档的⽤途和内容，并描述与其使⽤有关的保密性和私密性的要求。
2引⽤⽂件
应列出本⽂档引⽤的所有⽂档的编号、标题、修订版本、⽇期和来源。
3术语和缩略语
提供此⽂档中⽤到的专门术语的定义和缩写词的原词组。
4测试准备
以下按照软件测试类型（如：功能测试、性能测试、可靠性测试等）分章节编写。
每⼀项测试类型均应有唯⼀的标识号，应描述如何准备并获取测试资源，如测试环境所必须的软件、硬件、数据资源等；必要时，应描述如何准备
测试程序，如开发测试接⼝所需的数据仿真、业务仿真程序以及测试⽀持软件等。
4.X（测试名称、唯⼀标识号）
4.X.1设施环境要求
描述对测试场所、设施和环境的要求。（若有）分析上述差异对测试可能造成的影响。
4.X.2硬件准备
描述对测试硬件的要求。分析硬件差异对测试可能造成的影响。
4.X.3软件准备
描述对测试软件的要求。分析软件差异对测试可能造成的影响。
4.X.4数据准备
描述对测试数据的要求。分析数据差异对测试可能造成的影响。
4.X.5其它测试准备
描述对测试程序等分⾯的其他测试准备⼯作。
5测试项分解
将需测试的内容进⾏层次化的分解形成测试项，并进⾏标识命名。对最终分解后的每个测试项，说明测试⽤例设计⽅法的具体应⽤、测试数据的选
择依据等。测试项与具体的功能和性能要求对应，测试项还应包含对⽤户⽂档(⽤户⼿册、安装部署⼿册)的测试。
6测试说明
逐层对测试项和测试⽤例进⾏标识和说明。其中，测试⽤例⾄少应包含：所属测试项、⽤例名称标识、⽤例说明、对应需求、前提和约束、执⾏步
骤、预期结果等。
注：测试⽤例可采⽤表格⽅式，可作为本⽂档的附件另⾏成⽂，以下是对测试⽤例相关项的解释。
对应需求：说明测试所依据的内容来源，如软件需求规格说明书中的需求功能编号或具体条款
测试说明：简要描述测试的对象、⽬的和所采⽤的测试⽅法。
前提和约束：说明实施该测试⽤例的前提条件和约束条件，如环境条件、准备⼯作等。
执⾏步骤：编写按照执⾏顺序排列的⼀系列相对独⽴的步骤，每⼀个执⾏步骤应包括测试操作动作、测试程序输⼊或设备操作、期望的测试结果。
预期结果：期望测试结果应有具体内容(如确定的元数值、业务流程状态等)，不应是不确切的概念或笼统的描述。
7测试⽤例执⾏顺序
应确定软件测试⽤例的执⾏顺序，从⽽合理安排测试执⾏过程，避免重复执⾏测试⽤例，提⾼测试⼯作效率。同时，通过合理的测试⽤例执⾏顺序
实现对完整的业务流程的确认和验证。
（⼆）内容审核要点：
1．测试说明的范围与合同及其附件要求等是否⼀致；是否覆盖了全部软件需求；是否覆盖了全部测试需求；
2．软件测试准备是否充分；
3．软件测试分解是否合理；测试设计思路是否清晰；测试技术实现⽅法是否科学；
4．对接⼝的分析和说明是否完整、准确；对接⼝测试的正常和容错说明是否全⾯；
5．测试⽤例是否充分；除正常操作、正常流程、正常数据外，是否覆盖了可测试的异常情况；
6．测试⽤例的执⾏顺序是否合理；是否可覆盖必要的业务流程。
9软件测试报告
（⼀）⽂档内容要求
1引⾔
1.1标识
本条应包含本⽂档及其所适⽤的系统和软件的完整标识，(若适⽤)包括标识号、标题、缩略词语、版本号、发⾏号。
1.2系统概述
本条简述本⽂档适⽤的系统和软件的⽤途。应描述系统与软件的⼀般性质；描述系统基本功能；概述本系统或软件的开发、测试、试运⾏和维护的
历史；标识项⽬的承建⽅、业主⽅、总集⽅、监理⽅等；标识系统当前和计划的运⾏现场；
1.3⽂档概述
本条应概括本⽂档的⽤途与内容，并描述与其使⽤有关的保密性⽅⾯的要求。
1.5引⽤⽂件
本条应列出本⽂档引⽤的所有⽂档的编号、标题、修订版本、⽇期和来源。
1.6术语与缩略语
提供此⽂档中⽤到的专门术语的定义和缩写词的原词组。
2测试概述
2.1测试⽬的
描述本次测试的⽬的。
2.2测试内容
描述本次测试的主要内容，包括需要进⾏测试的功能和特性。可以引⽤测试计划和测试说明⽂档中的内容。对于出⼚测试，要将⽤户⽂档的正确性
测试作为测试的内容之⼀。
2.3测试的质量⽬标
描述本次测试所要达到的质量⽬标，如A、B类bug低于多少个，系统响应时间、系统表现达到什么⽬标等等。
2.4测试依据
描述本次测试的所依据的⽅案、⽂档和标准。
2.5测试环境描述
描述本次测试的软硬件环境，包括使⽤的服务器的软硬件环境和配置，⽹络和客户端环境，部署情况说明等。与⽣产系统环境的差异。
2.6测试时间
说明本次测试的执⾏时间。
2.7测试⼈员及⼯作量
说明本次测试投⼊的⼈员、⼯作量，以及具体每个功能⼦模块的⼈员、计划⼯作量、实际⼯作量的分配。
3测试问题记录
通过列表的⽅式列出测试发现的主要问题记录，包括问题编号、问题说明、对应测试⽤例、解决情况等。
4测试结果分析及软件评价
4.1对被测试软件的总体评价
.根据本报告中所展⽰的测试结果，提供对该软件的总体评价，包括遗留bug的统计与分析、软件存在的主要问题、是否达到本次测试的质量⽬标
等。
4.2测试技术分析
分析测试技术对测试结果的影响。
4.3测试环境的影响
对测试环境与操作环境的差异进⾏评估，并分析这种差异对测试结果的影响。
4.4改进建议
针对对被测试软件还存在的问题，提出改进建议。
附录
附录可⽤来提供那些为便于⽂档维护⽽单独出版的信息(例如图表、分类数据)。为便于处理，附录可单独装订成册。附录应按字母顺序(A,B等)编
排。
⽂档中，如果定义了缺陷等级分类代码，需要在附录中给出其定义。
（⼆）内容审核要点：
1．是否全⾯、真实地反映了测试执⾏过程；测试记录是否完整、有效；
2．是否全⾯总结了测试执⾏过程中发现的软件问题和缺陷；
3.对问题及缺陷的判断和定位是否准确；
4．所测试内容与测试计划是否⼀致。
10软件安装部署⼿册
（⼀）⽂档内容要求
1概述
1.1编写⽬的
说明编写⽬的，指出本⽂档的预期读者。
1.2背景
说明系统的项⽬背景，使⽤本系统所包含的⽤户。
1.2范围
说明本⽂档的适⽤范围。
1.3参考资料
列出所参考的⽂档，如其它的⽤户⽂档。
1.3软件清单
列出所提交的软件产品的程序及其它必要的附件⽂件，包括可能的⽀持软件、第三⽅包、脚本⽂件、说明⽂档等，对清单中的名项给出必要的说
明。
2运⾏环境要求
说明系统进⾏安装部署时，对运⾏环境的要求，分为硬件环境和软件环境，包括服务器、客户端。
服务器端的运⾏环境，硬件⽅⾯需要指出最低参数要求，软件⽅⾯需要指出如操作系统、数据库软件、web应⽤服务器的名称、版本信息等。
客户端的运⾏环境，硬件⽅⾯需要指出最低参数要求，软件⽅⾯需要列出操作系统版本、运⾏依赖的浏览器版本、需要安装的驱动程序等。
3⽀撑软件的安装、部署和配置
给出所有⽀撑软件的安装、部署和配置步聚，可以引⽤第三⽅⽂档。
3.x的安装、部署和配置
⽀撑软件X安装、部署和配置步聚。
4应⽤程序的安装、部署和配置
4.x的安装、部署和配置
4.x.1安装、部署前的准备⼯作
说明系统进⾏安装部署前，需要进⾏的前期准备⼯作。如对操作系统、数据库、web应⽤服务器进⾏相应的参数设置，数据库的初始化等等。
4.x.2部署环境概要说明
可以对部署的服务器环境，如⽂件⽬录结构，进⾏概要说明。
4.x.3依赖
系统在进⾏安装、部署时，如果需要对外部系统运⾏或接⼝有依赖关系，在此列出。
4.x.4安装、部署和配置步聚
列出详细的安装、部署和配置过程，包括对相关配置⽂件内容的修改。
5程序的启动和停⽌
给出软件的启动和停⽌说明
（⼆）内容审核要点：
1．所述运⾏环境和⽀撑软件是否详细完备；
2．部署前的准备⼯作是否详细完备；
3．安装过程是否详细易懂。
11源代码交付说明
（⼀）⽂档内容要求
1概述
1.1背景
说明系统的项⽬背景，本系统的使⽤和运维单位等。
1.2范围
说明本⽂档的适⽤范围。
2源代码交付清单
以表格的形式，列出所提交的源代码光盘中所有的⽂件⽬录结构，对各⽬录和⼦⽬录加以说明。对主要源代码程序加以说明。对其它必要的附件
（包括第三⽅包、类库、配置⽂件、程序的帮助说明⽂档等）也要加以说明。
3编译和打包的说明
3.1编译环境和⼯具要求
如果需要，对编译环境和所需要⼯具进⾏简要说明。
3.2编译和打包步聚
说明对源代码进⾏编译和打包的详细步聚，要能根据这些步骤⽣成可⽤的⽬标程序。尽量使⽤脚本⽅式⽣成⽬标程序。
3.3⽣成物说明
对编译⽣成的执⾏程序进⾏简要说明。
（⼆）内容审核要点：
1．交付清单是否详细完备；
2．说明⽂字是否明确易懂；
3．交付物版本是否和实际系统的程序版本⼀致（能根据本⽂档⽣成与实际⽣产系统⼀致的程序）；
12系统上线部署⽅案
（⼀）⽂档内容要求
1概述
1.1编写⽬的
说明编写⽬的，指出预期的读者范围。
1.2背景
简要描述此次上线部署的背景。
1.3参考资料
列出所参考的⽂档，如安装部署⼿册等。
2⼯作内容
说明本次上线部署的⼯作内容。即要做哪⼏件事。
3部署环境
3.1部署结构
以部署结构图的形式描述本软件系统各部件的上线部署结构。对部署部件、服务器、⽹络等情况加以必要的说明。
3.2软件环境描述
明确描述本次部署的软件环境。包括操作系统、数据库、JDK、中间件等系统软件及版本信息。对于尚未明确需要协调的部分要加以说明。
3.3硬件环境描述
明确描述本次部署的硬件⽀撑环境。对于尚未明确需要协调的部分要加以说明。
4详细步骤
详细说明本次部署要做的各项⼯作的执⾏步骤（需要时可以引⽤安装部署⼿册中的内容）。本章是该⽂档的重点，各步骤必须具体明确，具有可操
作性。
5⼈员和进度安排
列出本次的⼈员组织以及详细的进度安排。
6部署测试
说明系统上线部署时需要进⾏的必要的测试验证⼯作内容。
7部署不成功的处理
说明部署不成功的处理措施。如果是在⽣产系统上替代已有系统，则必须提供完善的应对措施。
（⼆）内容审核要点：
1．部署⽬标和⼯作内容是否明确；
2．部署环境描述是否清楚；
3．任务是否适当分解，⼈员是否落实，进度是否明确。
4．所述步骤是否具体并具有可操作性；
4．部署测试内容是否能对本次部署是否成功能起到验证作⽤。
13系统上线部署实施报告
（⼀）⽂档内容要求
1概述
1.1编写⽬的
说明编写⽬的，指出预期的读者范围。
1.2背景
简要描述此次上线部署的背景。
1.3参考资料
列出所参考的⽂档，如安装部署⼿册等。
2⼯作内容
说明本次上线部署的⼯作内容。即要做哪⼏件事。
3实际完成情况
对照⼯作内容，详细说明本次实际部署过程和⼯作任务完成情况。
4部署测试情况
详细说明本次部署测试情况，测试内容是否都获通过。
5遗留⼯作和待解决问题
如果有遗留⼯作或问题，需要在此部分列出。
6签字栏
本报告作为验收的依据，需要相关⽅的签字。应留有签字栏。
（⼆）内容审核要点：
1．任务描述是否明确；
2．部署实际完成情况是否描述清楚；
3．部署测试情况是否描述清楚；
2．部署部署过程是否与实际情况⼀致。
14软件终验测试⽅案
(⼀)⽂档内容要求
１．测试⽬的
终验测试是项⽬终验的组成部分，⽤于各⽅现场验证系统各功能可⽤，试运⾏中发现的问题是否已经解决。
２．测试对象
描述所测试的软件系统名、版本等信息
３．测试⽅式
由业主⽅、承建⽅、监理⽅、总集⽅代表在⽤户现场，依据本⽅案进⾏测试，并记录测试结果，时间以半天到⼀天为宜。测试结束后，现场编制终
验测试报告并由各⽅签字确认。
４．测试通过准则
本测试⽅案中所列所有测试项均已通过，则终验测试通过，否则为不通过。
5．功能测试
４.1功能名1
以表格⽅式列出⼦功能、测试⽅法、是否通过、备注
4.2功能名2
。。。
6．试运⾏期间问题解决情况测试
以表格⽅式列出问题、问题描述、测试⽅法、是否通过、备注
(⼆)内容审核要点：
略
15软件终验测试报告
(⼀)⽂档内容要求
１．测试⽬的
终验测试是项⽬终验的组成部分，⽤于各⽅现场验证系统各功能可⽤，试运⾏中发现的问题是否已经解决。
２．测试对象
描述所测试的软件系统名、版本等信息
３．测试⽅式
由业主⽅、承建⽅、监理⽅、总集⽅代表在⽤户现场，依据本⽅案进⾏测试，并记录测试结果，时间以半天到⼀天为宜。测试结束后，现场编制终
验测试报告并由各⽅签字确认。
４．测试通过准则
终验测试⽅案中所列所有测试项均已通过，则终验测试通过，否则为不通过。
５．测试时间
说明实施测试的时间
６．测试地点
说明实施测试的地点
７．测试参与⼈员
说明参与终验测试的各⽅⼈员，要说明所属单位
８．功能测试结果记录
根据终验测试⽅案，以表格的⽅式列出各项所测功能是否通过
９．问题解决情况记录
根据终验测试⽅案，以表格的⽅式列出各项所测问题是否全部解决
10．测试结论
给出终验测试是否通过的结论。
(⼆)内容审核要点：
略
附：关于接⼝描述的⽂档内容要求
1、概述
1.1、接⼝的概念
在应⽤软件系统中，接⼝是程序和系统与外界交互的窗⼝。本⽂中所阐述的接⼝，包括：
应⽤软件系统提供软件功能供外部软件程序调⽤；
应⽤软件系统调⽤外部系统提供的软件功能；
应⽤软件系统依据应⽤级别的交互协议与外系统进⾏功能和数据的交换；
应⽤软件系统通过公⽤⽂件⽬录或数据库与外部系统交换信息。
此处中所阐述的接⼝不包括：
应⽤软件系统内部功能模块之间的接⼝调⽤；
应⽤软件系统提供的⼈机交互界⾯。
1.2、接⼝处理策略
xxxxxxxxxxx是⼀个庞⼤的由众多应⽤⼦系统构成的复杂分布式系统。各应⽤⼦系统之间存在众多的软件接⼝关系。
在xxxxxxxxxxx中，我们采⽤SOA的体系架构来解决各应⽤⼦系统之间、应⽤⼦系统与外部系统之间的接⼝问题。通过基于ESB服务总线技术的
应⽤⽀撑平台来发布和管理应⽤软件系统对外提供公⽤服务。在这⾥，服务系指精确定义、封装完善、独⽴于其他服务所处环境和状态的软件功
能。接⼝服务系指以服务的⽅式提供的接⼝实现。
通过⽀撑平台，各业务⼦系统接⼝之间的点对点关系，变成了各业务⼦系统接⼝与⽀撑平台的关系，从⽽简化了系统间的逻辑关系，应⽤⽀撑平台
是各业务⼦系统相互连接的中介和纽带。各业务⼦系统之间在进⾏服务请求和服务调⽤时所需的⼀些附加⼯作，如通信协议的转换、路由、消息格
式转换、安全性保证等，也可以由应⽤⽀撑平台来提供⽀持。此外，应⽤⽀撑平台提供适配器⽅式以⽀持⽂件同步、数据库同步、JMS、FTP等,
应⽤⽀持平台还提供定制适配器功能接⼊特殊的外部系统。
通过应⽤⽀持平台发布公⽤服务，将有利于接⼝服务的复⽤，以及接⼝服务的维护和管理。
1.3、接⼝⽂档规范的必要性
xxxxxxxxxxx建设过程中，各应⽤软件系统的接⼝定义、实现、发布和管理是处理好接⼝问题的四个关键环节，他们贯穿在软件⽣命周期的全过
程。为了保证在这些环节对应⽤软件系统之间的接⼝问题进⾏有效的处理，保证接⼝的良好定义、合理实现、受控发布和⽅便管理，有必要对相关
技术⽂档提出规范化要求。
涉及接⼝定义的技术⽂档主要有业务需求说明书、软件需求规格说明书；涉及接⼝实现的技术⽂档主要有软件概要设计说明书、软件详细设计说明
书、⽤户⼿册；涉及接⼝服务发布和管理的技术⽂档包括接⼝服务发布和管理规范等。
2、接⼝定义的⽂档规范要求
2.1、业务需求说明书中的接⼝描述
在xxxxxxxxxxx中，业务需求说明书由业主⽅任命的⼦项⽬组负责编制。业务需求说明书中有关接⼝描述的要求：
1．宜有专门章节阐述⼦项⽬拟分包系统与其它⼦项⽬系统及外部系统之间的接⼝关系；
2．在描述本系统与外部某系统接⼝关系时，宜：
具体阐明本系统的哪项或哪些业务功能与所述外部系统存在接⼝关系；
阐明接⼝的类型，如向外系统提供数据、从外系统获取数据、对外系统提供功能服务、向外系统请求某项功能服务；
对所述接⼝作必要的⽂字解释。
2.2、软件需求规格说明书中的接⼝描述
软件需求规格说明书系由承建⽅在业务需求说明书的基础上，在系统功能、性能、外部限制条件等⽅⾯的进⼀步明确和细化，作为系统设计、实
现、测试的依据。是涉及接⼝定义的重要⽂档。
软件需求规格说明书中有关接⼝定义和描述的要求如下：
1．软件需求规格说明书中有关与外部系统接⼝定义的范围应涵盖业务需求说明书中有关接⼝的描述，并补充业务需求书中遗漏的接⼝内容；
2．本系统作为接⼝对外提供的软件功能，应在软件需求规格说明书中明确阐明该功能。包括接⼝功能编号、名称、性质（功能服务、数据交换、
⽂件交换等）、接⼝功能的各输⼊参数及数据类型，返回的结果数据类型等；
3．如果接⼝是作为某种信息交互协议（如Z39.50）的服务端提供的功能，要求阐明⽀持的协议版本以及是否完全⽀持该协议，如果不完全⽀
持，要明确列举⽀持或不⽀持的功能；
4．如果接⼝是某种信息交互协议（如Z39.50）的客户端，且外部系统提供的相应协议服务端功能是本系统相关功能实现的必要条件，须将对外
部系统的相关接⼝实现要求列⼊软件需求规格说明书中的限制条件部分；
5．如果系统功能涉及到要使⽤或访问外部系统提供的功能，须将其列⼊需求规格说明书中限制条件部分。
2．3接⼝定义的变更
如果在软件需求评审通过后的实施过程中，原定义或描述的接⼝发⽣了变化，须通过变更流程修改软件需求规格说明书；或编制需求⽂档的补充材
料，与原需求规格说明书⼀起，作为测试和验收的依据。
3、接⼝实现的⽂档规范要求
3.1、软件设计说明书中的接⼝服务实现描述
在软件概要设计说明书中，有关接⼝实现的要求如下：
1．须覆盖软件需求说明书中所述对外提供接⼝功能；
2．确定接⼝的实现策略。如采⽤WebService、EJB、通过⽹络端⼝连接对外提供服务、⽂件⽬录或数据库同步等。
3．对外提供的接⼝功能，需要进⾏形式化描述，如果不能确定在软件概要设计说明书完全进⾏接⼝功能的形式化表述，应在该说明书中明⽰并在
详细设计说明书中给出以供编码实现之⽤。
3．2⽤户⽂档中的接⼝使⽤描述
在设计说明书中描述的所有对外提供的接⼝功能，最终都要落实在⽤户⽂档中。具体的⽤户⽂档名称，取决于项⽬合同和软件开发计划中对最终交
付⽂件的规定。如⽤户使⽤⼿册、⽤户参考⼿册、⽤户技术⼿册等。
各应⽤软件系统通过该系统的⽤户⽂档对外正式公布本系统对外的接⼝服务的功能和调⽤⽅式。