概要设计说明书测试报告
(国内标准)GB-软件开发主要文档编写规范
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 ．管理信息服务的改进。
国家标准软件文档模板(全17个Word模板)
对应大规模软件所规定的文件可进一步细分测试分析报告项目开发总结小规模软件中规模软件大规模软件超大规模软件操作手册（GB8567——88）1引言1.1编写目的说明编写这份操作手册的目的，指出预期的读者。
1.2前景说明：a．这份操作手册所描述的软件系统的名称；b．该软件项目的任务提出者、开发者、用户（或首批用户）及安装该软件的计算中心。
1.3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料列出有用的参考资料，如：a．本项目的经核准的计划任务书或合同、上级机关的批文；b．属于本项目的其他已发表的文件；c．本文件中各处引用的文件、资料，包括所列出的这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2软件征述2.1软件的结构结合软件系统所具有的功能包括输入、处理和输出提供该软件的总体结构图表。
2.2程序表列出本系统内每个程序的标识符、编号和助记名。
2.3文卷表列出将由本系统引用、建立或更新的每个永久性文卷，说明它们各自的标识符、编号、助记名、存储媒体和存储要求。
3安装与初始化一步一步地说明为使用本软件而需要进行的安装与初始化过程，包括程序的存载形式，安装与初始化过程中的全部操作命令，系统对这些命令的反应与答复，表征安装工作完成的测试实例等。
如果有的话，还应说明安装过程中所需用到的专用软件。
4运行说明所谓一个运行是指提供一个启动控制信息后，直到计算机系统等待另一个启动控制信息时为止的计算机系统执行的全部过程。
4.1运行表列出每种可能的运行，摘要说明每个运行的目的，指出每个运行各自所执行的程序。
4.2运行步骤说明从一个运行转向另一个运行以完成整个系统运行的步骤。
4.3运行1（标识符）说明把运行1的有关信息，以对操作人员为最方便最有用的形式加以说明。
4.3.1运行控制列出为本运行所需要”的运行流向控制的说明。
4.3.2操作信息给出为操作中心的操作人员和管理人员所需要的信息，如：a.运行目的；b.操作要求；c.启动方法如应请启动（由所遇到的请求信息启动）、预定时间启动、…，··等；d.预计的运行时间和解题时间；e.操作命令；f.与运行有联系的其他事项。
概要设计说明书(模板)
XXX项目概要设计说明书目录XXX项目_概要设计书 (1)1 引言 (1)1.1 编写目的 (1)1.2 参考文献 (1)1.3 术语与缩写解释 (1)2 总体设计 (1)2.1 系统概述 (1)2.2 系统设计原则 (1)2.3 设计中应用的关键技术 (1)2.4 系统结构图 (2)2.5 网络结构图 (2)2.6 系统功能模块图 (2)2.7 数据流向图（或称为时序图） (2)2.8 模块构成 (2)3 环境设计 (2)4 硬件设备 (2)5 支持软件 (3)6 接口设计 ......................................................................................................... 错误！未定义书签。
6.1 用户接口 (3)6.2 外部接口 (5)6.3 内部接口 (5)7 数据库设计 (6)7.1 数据库环境说明 (6)7.2 数据库命名规则 (6)7.3 逻辑设计 (6)7.4 物理设计 (6)7.5 安全性设计 (7)8 公用结构 ......................................................................................................... 错误！未定义书签。
9 界面设计 (8)10 出错处理设计 (8)11 开发工具 ..................................................................................................... 错误！未定义书签。
12 附录 (8)1 引言1.1 编写目的[说明编写这份概要设计说明书的目的,指出预期的读者]例如：本设计说明书简单阐明了XXX系统的XXX模块的基本设计思想、基本功能、模块划分以及模块间接口。
概要设计说明书
概要设计说明书一、引言1．编写目的本阶段主要解决了实现该系统需求的程序模块设计问题，包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等。
在下一阶段的详细设计中，程序设计员可参考此概要设计报告，在概要设计对机票预定系统所做的模块结构设计的基础上，对系统进行详细设计。
在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设计结构，或在修改时找出在本阶段设计的不足或错误。
2．项目背景机票预定系统将由两部分组成：置于个旅行社定票点的前台客户程序，以及置于航空公司的数据库服务器。
本系统与其他系统的关系如下：3．参考资料《软件工程导论》，张海藩，清华大学出版社。
《实用软件工程》，郑人杰等，清华大学出版社。
二、总体设计1．验证登陆名密码正确进入主菜单，根据登录时所选的登录方式（客户、管理员）的不同分别对用户设定不同的访问权限（如果是输入的客户用户名和密码正确，选择以客户方式登陆则主界面里面的管理员界面不能用，如果输入的是管理员的相应用户密码正确，以管理员的方式登陆则管理员界面可用）不正确则清空登录框，最多可以输入三次，三次不正确系统会自动关闭。
2．主窗体的用户信息界面用户点击个人查询按钮，可以把自己的个人信息显示到界面上，还可以对自己的信息进行相应的修改（用户编号和用户名不能修改），还可以点击我的机票查询，查询该用户的订票记录。
3．主窗体的订票界面你可以点击你想查询的有关机票的信息的按钮（舱位信息查询，客机信息查询，航线查询，客户类型信息查询）获得相关信息的表，根据表的内容，你可以在下面的下拉框中选择你要定的票信息，点确定后在下面会显示你的机票的相关内容，如果满意可以点击订票，把相关信息添加到机票数据库表中，如果不满意，可以点重置，所有信息清空，再重新选择。
三、接口设计1．外部接口（1）用户界面在用户界面部分，根据需求分析的结果，用户需要一个用户友善界面。
测试文档主要包括什么
测试文档主要包括：1.测试计划2.测试用例3.测试记录报告4.测试问题报告5.测试评估报告七、测试计划1．引言11.1编写目的11.2项目背景21.3定义21.4参考资料22．任务概述22.1目标22.2运行环境22.3需求概述22.4条件与限制23．计划33.1测试方案33.2测试项目33.3测试准备33.4测试机构及人员34．测试项目说明34.1测试项目名称及测试内容34.2测试用例34.3进度34.4条件34.5测试资料35．评价35.1范围35.2准则31．引言1.1编写目的【阐明编写测试计划的目的，指明读者对象。
】1.2项目背景【说明项目的来源、委托单位及主管部门。
】1.3定义【列出测试计划中所用到的专门术语的定义和缩写词的原意。
】1.4参考资料【列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：a. 项目的计划任务书、合同或批文；b. 项目开发计划；c. 需求规格说明书；d. 概要设计说明书；e. 详细设计说明书；f. 用户操作手册；g. 本测试计划中引用的其他资料、采用的软件开发标准或规范。
】2．任务概述2.1目标2.2运行环境2.3需求概述2.4条件与限制3．计划3.1测试方案【说明确定测试方法和选取测试用例的原则。
】3.2测试项目【列出组装测试和确认测试中每一项测试的内容、名称、目的和进度。
】3.3测试准备3.4测试机构及人员【测试机构名称、负责人和职责。
】4．测试项目说明【按顺序逐个对测试项目做出说明：】4.1测试项目名称及测试内容4.2测试用例4.2.1输入【输入的数据和输入命令。
】4.2.2输出【预期的输出数据。
】4.2.3步骤及操作4.2.4允许偏差【给出实测结果与预期结果之间允许偏差的范围。
】4.3进度4.4条件【给出测试对资源的特殊要求，如设备、软件、人员等。
】4.5测试资料【说明测试所需的资料。
】5．评价5.1范围【说明所完成的各项测试说明问题的范围及其局限性。
[计算机软件产品开发文件编制指南]GB8567-88
![[计算机软件产品开发文件编制指南]GB8567-88](https://img.taocdn.com/s3/m/f66c638e04a1b0717fd5ddf5.png)
引言1 目的一项计算机软件的筹划、研制及实现，构成一个软件开发项目。
一个软件开发项目的进行，一般需要在人力和自动化资源等方面作重大的投资。
为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制二定的文件。
这些文件连同计算机程序及数据一起，构成为计算机软件。
文件是计算机软件中不可缺少的组成部分，它的作用是：a．作为开发人员在一定阶段内的工作成果和结束标志；b．向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料。
以便管理人员在各个阶段检查开发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种类和数量；C．记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改；d．提供对软件的有关运行、维护和培训的信息，便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作；e．向潜在用户报导软件的功能和性能，使他们能判定该软件能否服务于自己的需要。
换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。
计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类则是应编制的技术资料或技术管理资料，可称之为文件。
本指南规定软件文件的编制形式，并提供对这些规定的解释。
本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。
2 范围本指南是一份指导性文件。
本指甫建议，在一项计算机软件的开发过程中，一般地说，应该产生十四种文件。
这十四种文件是：可行性研究报告；项目开发计划；软件需求说明书；数据要求说明书；概要设计说明书；详细设计说明书；数据库设计说明书；用户手册；操作手册；模块开发卷宗；测试计划；测试分析报告；开发进度月报；项目开发总结报告。
本指南将给出开发过程中建议产生的这十四种文件的编制指导，同时，本指南也是这十四种文件的编写质量的检验准则。
概要设计说明书检查表
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更
▢是▢否
是否所有的TBD的影响都已经被评估了
▢是▢否
是否仍存在可能不可行的设计部分
▢是▢否
是否已记录设计时的权衡考虑该文件是否包括了权衡选择的标准和不选择其它方案的原因
▢是▢否
依从性
依从性该文档是否遵守了该项目的文档编写标准
▢是▢否
一致性
▢是▢否
是否所有的界面都提供了所要求的信息
▢是▢否
是否已说明内部各界面之间的关系
▢是▢否
界面的数量和复杂程度是否已减少到最小
▢是▢否
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
▢是▢否
可维护性
该设计是否是模块化的
▢是▢否
这些模块具有高内聚度和低耦合度
▢是▢否
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明
▢是▢否
性能
主要性能参数是否已复（例如：输入输出检查）
▢是▢否
是否已考虑非正常情况
▢是▢否
是否所有的错误情况都被完整和准确地说明
▢是▢否
该设计是否满足该系统进行集成时所遵守的约定
▢是▢否
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的
▢是▢否
是否已描述最低级别数据元素是否已详细说明取值范围
▢是▢否
功能性
是否对每一下级模块进行了概要算法说明
▢是▢否
所选择的设计和算法能否满足所有的需求
▢是▢否
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
▢是▢否
是否已描述界面的功能特性
概要设计说明书范例及模板
《XXXXXX》概要设计说明书张三、李四、王五1．引言1．1编写目的在本机票预定系统项目的前一阶段，也就是需求分析阶段中，已经将系统用户对本系统的需求做了详细的阐述，这些用户需求已经在上一阶段中对航空公司、各旅行社及机场的实地调研中获得，并在需求规格说明书中得到详尽得叙述及阐明。
本阶段已在系统的需求分析的基础上，对机票预定系统做概要设计。
主要解决了实现该系统需求的程序模块设计问题。
包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等。
在以下的概要设计报告中将对在本阶段中对系统所做的所有概要设计进行详细的说明。
在下一阶段的详细设计中，程序设计员可参考此概要设计报告，在概要设计对机票预定系统所做的模块结构设计的基础上，对系统进行详细设计。
在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设计结构，或在修改时找出在本阶段设计的不足或错误。
1．2项目背景机票预定系统将由两部分组成：置于个旅行社定票点的前台客户程序，以及置于航空公司的数据库服务器。
本系统与其他系统的关系如下：1．3定义1．3．1 专门术语SQL SERVER: 系统服务器所使用的数据库管理系统（DBMS）。
SQL: 一种用于访问查询数据库的语言事务流：数据进入模块后可能有多种路径进行处理。
主键：数据库表中的关键域。
值互不相同。
外部主键：数据库表中与其他表主键关联的域。
ROLLBACK: 数据库的错误恢复机制。
1．3．2 缩写系统：若未特别指出，统指本机票预定系统。
SQL: Structured Query Language（结构化查询语言）。
ATM: Asynchronous Transfer Mode (异步传输模式)。
1．4参考资料以下列出在概要设计过程中所使用到的有关资料：1．机票预定系统项目计划任务书浙江航空公司1999/32．机票预定系统项目开发计划《**》软件开发小组1999/33．需求规格说明书《**》软件开发小组1999/34．用户操作手册（初稿）《**》软件开发小组1999/45．软件工程及其应用周苏、王文等天津科学技术出版社1992/16．软件工程张海藩清华大学出版社1990/117．Computer Network A.S.Tanenbaun Prentice Hall 1996/01文档所采用的标准是参照《软件工程导论》沈美明著的“计算机软件开发文档编写指南”。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
表述含糊，没有确切的定义
是否定义了总体设计目标
是，但表述不够详细和明确
完整性
是否所有以前的TBD（待确定条目）都已经被解决了
否
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更
否
是否所有的TBD的影响都已经被评估了
否
是否仍存在可能不可行的设计部分
概要设计说明书测试报告
【图书杂志采购和借阅系统】
2010-5-21
华南理工大学软件学院
07软件（2）班小组
指导老师：王振宇
小组成员：陈军、傅桔选、
沈书毅、胡立
编写：傅桔选
清晰性
是否所设计的架构，包括数据流、控制流和接口，被清楚地表达了
对控制流的描述过于简单，只采用流程图做了基本的说明，控制流和数据流都没有体现。表达的含糊，非常不全面
否
可维护性
该设计是否是模块化的
是
这些模块具有高内聚度和低耦合度吗？
是
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明性能
是
主要性能参数是否已被详细说明（例如：实时、速度要求、吞吐量等）
是
可靠性
该设计能够提供错误检测和恢复吗？（例如：输入输出检查）
是
是否已考虑非正常情况
是
是否所有的错误情况都被完整并准确地说明
是
数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化
否
是否还有任何需要的，但还没有定义的数据结构，反之亦然
否
是否已描述最低级别数据元素，是否已详细说明取值范围
否
功能性
该设计是否是模块化的
是
这些模块具有高内聚度和低耦合度吗
是
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明性能
否
主要性能参数是否已被详细说明（例如：实时、速度要求、吞吐量等）
是
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
是
是否已描述界面的功能特性
否
界面将有利于问பைடு நூலகம்解决吗？
是
是否所有界面都互相一致，与其他模块一致，以及和更高级别文档中的需求一致
是
是否所有的界面都提供了所要求的信息
是
是否已说明内部各界面之间的关系
是
界面的数量和复杂程度是否已减少到最小
否
是否已记录设计时的权衡考虑，该文件是否包括了权衡选择的标准和不选择其他方案的原因
是
依从性
是否遵守了该项目的文档编写标准
是
一致性
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致
是
是否反映了实际操作环境（硬件、软件和支持软件）
是
可行性
从进度、预算和技术角度上看该设计是否可行
是
是否存在错误的、缺少的或不完整的逻辑
否
是否满足该系统进行集成时所遵守的约定
否
易测性
是否能够对该系统进行测试、演示、分析或检查来说明它是满足需求的
是
该系统是否能用增量型的方式来集成和测试
是
可追溯性
是否各部分的设计都能追溯到需求说明书的需求
是
是否所有的设计决策都能追溯到原来确定的权衡因素
是
所继承设计的已知风险是否已确定和分析
是