如何制定一份有效的，可行性高的测试规范？（08-09-22）（获奖名单已公布）

inksong

可行性研究报告的规范
1引言
1.1编写目的
说明编写本可行性研究报告的目的，指出预期的读者。
1.2背景
说明：
A.        所建议开发的软件系统的名称；
B.        本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
C.        该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出用得着的参考资料，如：
1.        本项目的经核准的计划任务书或合同、上级机关的批文；
2.        属于本项目的其他已发表的文件；
3.        本文件中各处引用的文件、资料，包括所需用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2可行性研究的前提
说明对所建议的开发项目进行可行性研究的前提，如要求、目标、假定、限制等。
2.1要求
说明对所建议开发的软件的基本要求，如：
A.        功能；
B.        性能；
C.        输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象；
D.        输入说明系统的输入，包括数据的来源、类型、数量、数据的组织以及提供的频度；
E.        处理流程和数据流程用图表的方式表示出最基本的数据流程和处理流程，并辅之以叙述；
F.        在安全与保密方面的要求；
G.        同本系统相连接的其他系统；
H.        完成期限。
2.2目标
说明所建议系统的主要开发目标，如：
A.        人力与设备费用的减少；
B.        处理速度的提高；
C.        控制精度或生产能力的提高；
D.        管理信息服务的改进；
E.        自动决策系统的改进；
F.        人员利用率的改进。
2.3条件、假定和限制
说明对这项开发中给出的条件、假定和所受到的限制，如：
a．        所建议系统的运行寿命的最小值；
b．        进行系统方案选择比较的时间；
c．        经费、投资方面的来源和限制；
d．        法律和政策方面的限制；
e．        硬件、软件、运行环境和开发环境方面的条件和限制；
f．        可利用的信息和资源；
g．        系统投入使用的最晚时间。
2.4进行可行性研究的方法
说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的。摘要说明所使用的基本方法 和策略，如调查、加权、确定模型、建立基准点或仿真等。
2.5评价尺度
说明对系统进行评价时所使用的主要尺度，如费用的多少、各项功能的优先次序、开发时间的长短 及使用中的难易程度。
3对现有系统的分析
这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是一个机械系统甚 至是一个人工系统。
分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。
3.1处理流程和数据流程
说明现有系统的基本的处理流程和数据流程。此流程可用图表即流程图的形式表示，并加以叙述。
3.2工作负荷
列出现有系统所承担的工作及工作量。
3.3费用开支
列出由于运行现有系统所引起的费用开支，如人力、设备、空间、支持性服务、材料等项开支以及开 支总额。
3.4人员
列出为了现有系统的运行和维护所需要的人员的专业技术类别和数量。
3.5设备
列出现有系统所使用的各种设备。
3.6局限性
列出本系统的主要的局限性，例如处理时间赶不上需要，响应不及时，数据存储能力不足，处理功能 不够等。并且要说明，为什么对现有系统的改进性维护已经不能解决问题。
4所建议的系统
本章将用来说明所建议系统的目标和要求将如何被满足。
4.1对所建议系统的说明
概括地说明所建议系统，并说明在第2章中列出的那些要求将如何得到满足，说明所使用的基本方法及理论根据。
4.2处理流程和数据流程
给出所建议系统的处理流程和数据流程。
4.3改进之处
按2.2条中列出的目标，逐项说明所建议系统相对于现存系统具有的改进。
4.4影响
说明在建立所建议系统时，预期将带来的影响，包括：
4.4.1对设备的影响
说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改。
4.4.2对软件的影响
说明为了使现存的应用软件和支持软件能够同所建议系统相适应。而需要对这些软件所进行的修改和补充。
4.4.3对用户单位机构的影响
说明为了建立和运行所建议系统，对用户单位机构、人员的数量和技术水平等方面的全部要求。
4.4.4对系统运行过程的影响
说明所建议系统对运行过程的影响，如：
a．        用户的操作规程；
b．        运行中心的操作规程；
c．        运行中心与用户之间的关系；
d．        源数据的处理；
e．        数据进入系统的过程；
f．        对数据保存的要求，对数据存储、恢复的处理；
g．        输出报告的处理过程、存储媒体和调度方法；
h．        系统失效的后果及恢复的处理办法。
4.4.5对开发的影响
说明对开发的影响，如：
a.        为了支持所建议系统的开发，用户需进行的工作；
b.        为了建立一个数据库所要求的数据资源；
c.        为了开发和测验所建议系统而需要的计算机资源；
d.        所涉及的保密与安全问题。
4.4.6对地点和设施的影响
说明对建筑物改造的要求及对环境设施的要求。
4.4.7对经费开支的影响
扼要说明为了所建议系统的开发，设计和维持运行而需要的各项经费开支。
4.5局限性
说明所建议系统尚存在的局限性以及这些问题未能消除的原因。
4.6技术条件方面的可行性
本节应说明技术条件方面的可行性，如：
a．        在当前的限制条件下，该系统的功能目标能否达到；
b．        利用现有的技术，该系统的功能能否实现；
c．        对开发人员的数量和质量的要求并说明这些要求能否满足；
d．        在规定的期限内，本系统的开发能否完成。
5可选择的其他系统方案
扼要说明曾考虑过的每一种可选择的系统方案，包括需开发的和可从国内国外直接购买的，如果没有供选择的系统方案可考虑，则说明这一点。
5.1可选择的系统方案1
参照第4章的提纲，说明可选择的系统方案1，并说明它未被选中的理由。
5.2可选择的系统方案2
按类似5.1条的方式说明第2个乃至第n个可选择的系统方案。
......
6投资及效益分析
6.1支出
对于所选择的方案，说明所需的费用。如果已有一个现存系统，则包括该系统继续运行期间所需的费用。
6.1.1基本建设投资
包括采购、开发和安装下列各项所需的费用，如：
a.        房屋和设施；
b.        ADP设备；
c.        数据通讯设备；
d.        环境保护设备；
e.        安全与保密设备；
f.        ADP操作系统的和应用的软件；
g.        数据库管理软件。
6.1.2其他一次性支出
包括下列各项所需的费用，如：
a．        研究（需求的研究和设计的研究）；
b．        开发计划与测量基准的研究；
c．        数据库的建立；
d．        ADP软件的转换；
e．        检查费用和技术管理性费用；
f．        培训费、旅差费以及开发安装人员所需要的一次性支出；
g．        人员的退休及调动费用等。
6.1.3非一次性支出
列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用，包括：
a．        设备的租金和维护费用；
b．        软件的租金和维护费用；
c．        数据通讯方面的租金和维护费用；
d．        人员的工资、奖金；
e．        房屋、空间的使用开支；
f．        公用设施方面的开支；
g．        保密安全方面的开支；
h．        其他经常性的支出等。
6.2收益
对于所选择的方案，说明能够带来的收益，这里所说的收益，表现为开支费用的减少或避免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进等，包括；
6.2.1一次性收益
说明能够用人民币数目表示的一次性收益，可按数据处理、用户、管理和支持等项分类叙述，如：
a．        开支的缩减包括改进了的系统的运行所引起的开支缩减，如资源要求的减少，运行效率的改进，数据进入、存贮和恢复技术的改进，系统性能的可监控，软件的转换和优化，数据压缩技术的采用，处理的集中化／分布化等；
b．        价值的增升包括由于一个应用系统的使用价值的增升所引起的收益，如资源利用的改进，管理和运行效率的改进以及出错率的减少等；
c．        其他如从多余设备出售回收的收入等。
6.2.2非一次性收益
说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民币数目表示的收益，包括开支的减少和避免。
6.2.3不可定量的收益
逐项列出无法直接用人民币表示的收益，如服务的改进，由操作失误引起的风险的减少，信息掌握情况的改进，组织机构给外界形象的改善等。有些不可捉摸的收益只能大概估计或进行极值估计（按最好和最差情况估计）。
6.3收益／投资比
求出整个系统生命期的收益／投资比值。
6.4投资回收周期
求出收益的累计数开始超过支出的累计数的时间。
6.5敏感性分析
所谓敏感性分析是指一些关键性因素如系统生命期长度、系统的工作负荷量、工作负荷的类型与这些不同类型之间的合理搭配、处理速度要求、设备和软件的配置等变化时，对开支和收益的影响最灵敏的范围的估计。在敏感性分析的基础上做出的选择当然会比单一选择的结果要好一些。
7社会因素方面的可行性
本章用来说明对社会因素方面的可行性分析的结果，包括：
7.1法律方面的可行性
法律方面的可行性问题很多，如合同责任、侵犯专利权、侵犯版权等方面的陷井，软件人员通常是不熟悉的，有可能陷入，务必要注意研究。
7.2使用方面的可行性
例如从用户单位的行政管理、工作制度等方面来看，是否能够使用该软件系统；从用户单位的工作人员的素质来看，是否能满足使用该软件系统的要求等等，都是要考虑的。
8结论
在进行可行性研究报告的编制时，必须有一个研究的结论。结论可以是：
a．        可以立即开始进行；
b．        需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行；
c．        需要对开发目标进行某些修改之后才能开始进行；
d．        不能进行或不必进行（例如因技术不成熟、经济上不合算等）。

inksong

模块开发卷宗的规范
1标题
软件系统名称和标识符
模块名称和标识符（如果本卷宗包含多于一个的模块，则用这组模块的功能标识代替模块名）
程序编制员签名
卷宗的修改文本序号
修改完成日期
卷宗序号（说明本卷宗在整个卷宗中的序号）
编排日期（说明整个卷宗最近的一次编排日期）
2模块开发情况表
3功能说明
扼要说明本模块（或本组模块）的功能，主要是输入、要求的处理、输出。可以从系统设计说明书中摘录。同时列出在软件需求说明书中对这些功能的说明的章、条、款。
4设计说明
说明本模块（或本组模块）的设计考虑，包括：
a．        在系统设计说明书中有关对本模块（或本组模块）设计考虑的叙述，包括本模块在软件系统中所处的层次，它同其他模块的接口；
b．        在程序设计说明书中有关对本模块（或本组模块）的设计考虑，包括本模块的算法、处理流程、牵涉到的数据文卷设计限制、驱动方式和出错信息等；
c．        在编制目前已通过全部测试的源代码时实际使用的设计考虑。
5原代码清单
要给出所产生的本模块（或本组模块）的第一份无语法错的源代码清单以及已通过全部测试的当前有效的源代码清单。
6测试说明
说明直接要经过本模块（或本组模块）的每一项测试，包括这些测试各自的标识符和编号、进行这些测试的目的、所用的配置和输入、预期的输出及实际的输出。
7复审的结论
把实际测试的结果，同软件需求说明书、系统设计说明书、程序设计说明书中规定的要求进行比较和给出结论。


数据库设计说明书的规范
1引言
1.1编写目的
说明编写这份数据库设计说明书的目的，指出预期的读者。
1.2背景
说明：
a．        说明待开发的数据库的名称和使用此数据库的软件系统的名称；
b．        列出该软件系统开发项目的任务提出者、用户以及将安装该软件和这个数据库的计算站（中心）。
1.3定义
列出本文件中用到的专门术语的定义、外文首字母组词的原词组。
1.4参考资料
列出有关的参考资料：
a．        本项目的经核准的计划任务书或合同、上级机关批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用到的文件资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2外部设计
2.1标识符和状态
联系用途，详细说明用于唯一地标识该数据库的代码、名称或标识符，附加的描述性信息亦要给出。如果该数据库属于尚在实验中、尚在测试中或是暂时使用的，则要说明这一特点及其有效时间范围。
2.2使用它的程序
列出将要使用或访问此数据库的所有应用程序，对于这些应用程序的每一个，给出它的名称和版本号。
2.3约定
陈述一个程序员或一个系统分析员为了能使用此数据库而需要了解的建立标号、标识的约定，例如用于标识数据库的不同版本的约定和用于标识库内各个文卷、、记录、数据项的命名约定等。
2.4专门指导
向准备从事此数据库的生成、从事此数据库的测试、维护人员提供专门的指导，例如将被送入数据库的数据的格式和标准、送入数据库的操作规程和步骤，用于产生、修改、更新或使用这些数据文卷的操作指导。如果这些指导的内容篇幅很长，列出可参阅的文件资料的名称和章条。
2.5支持软件
简单介绍同此数据库直接有关的支持软件，如数据库管理系统、存储定位程序和用于装入、生成、修 改、更新数据库的程序等。说明这些软件的名称、版本号和主要功能特性，如所用数据模型的类型、允许 的数据容量等。列出这些支持软件的技术文件的标题、编号及来源。
3结构设计
3.1概念结构设计
说明本数据库将反映的现实世界中的实体、属性和它们之间的关系等的原始数据形式，包括各数据项、记录、系、文卷的标识符、定义、类型、度量单位和值域，建立本数据库的每一幅用户视图。
3.2逻辑结构设计
说明把上述原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和文卷结构、所建立的各个文卷之间的相互关系，形成本数据库的数据库管理员视图。
3.3物理结构设计
建立系统程序员视图，包括：
a．        数据在内存中的安排，包括对索引区、缓冲区的设计；
b．        所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分；
c．        访问数据的方式方法。
4运用设计
4.1数据字典设计
对数据库设计中涉及到的各种项目，如数据项、记录、系、文卷、模式、子模式等一般要建立起数据字典，以说明它们的标识符、同义名及有关信息。在本节中要说明对此数据字典设计的基本考虑。
4.2安全保密设计
说明在数据库的设计中，将如何通过区分不同的访问者、不同的访问类型和不同的数据对象，进行分别对待而获得的数据库安全保密的设计考虑。

数据要求说明书的规范
1引言
1.1编写目的
说明编写这份数据要求说明书的目的，指出预期的读者。
1.2背景
说明：
a.        待开发软件系统的名称；
b.        b.列出本项目的任务提出者、开发者、用户以及将运行该项软件的计算站（中心）或计算机网络系统。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考资料，如：
a.        本项目的经核准的计划任务书或合同，上级机关的批文；
b.        属于本项目的其他已发表文件；
c.        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位。说明能够得到这些文件资料的来源。
2数据的逻辑描述
对数据进行逻辑描述时可把数据分为动态数据和静态数据。所谓静态数据，指在运行过程中主要作为参考的数据，它们在很长的一段时间内不会变化，一般不随运行而改变。所谓动态数据，包括所有在运行中要发生变化的数据以及在运行中要输入、输出的数据。进行描述时应把各数据元素逻辑地分成若干组，列如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定义（或物理意义）度量单位、值域、格式和类型等有关信息。
2.1静态数据
列出所有作为控制或参考用的静态数据元素。
2.2动态输人数据
列出动态输入数据元素（包括在常规运行中或联机操作中要改变的数据）。
2.3动态输出数据
列出动态输出数据元素（包括在常规运行中或联机操作中要改变的数据）。
2.4内部生成数据
列出向用户或开发单位中的维护调试人员提供的内部生成数据。
2.5数据约定
说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制（容 量、文卷、记录和数据元的个数的最大值）。对于在设计和开发中确定是临界性的限制更要明确指出。
3数据的采集
3.1要求和范围
按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。具体的内容包括：
a.        输入数据的来源，例如是单个操作员、数据输入站，专业的数据输入公司或它们的一个分组；
b.        数据输入（指把数据输入处理系统内部）所用的媒体和硬设备。如果只有指定的输入点的输入才是合法的，则必须对此加以说明；
c.        接受者说明输出数据的接受者；
d.        输出数据的形式和设备列出输出数据的形式和硬设备。无论接受者将接收到的数据是打印输出，还是CRT上的一组字符、一帧图形，或一声警铃，或向开关线圈提供的一个电脉冲，或常用介质如磁盘、磁带、穿孔卡片等，均应具体说明；
e.        数据值的范围给出每一个数据元的合法值的范围；
f.        量纲给出数字的度量单位、增量的步长、零点的定标等。在数据是非数字量的情况下，要给出每一种合法值的形式和含意；
g.        更新和处理的频度给出预定的对输入数据的更新和处理的频度。如果数据的输入是随机的，应给出更新处理的频度的平均值，或变化情况的某种其他度量。
3.2输人的承担者
说明预定的对数据输入工作的承担者。如果输入数据同某一接口软件有关，还应说明该接口软件的来源。
3.3预处理
对数据的采集和预处理过程提出专门的规定，包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。对于需经模拟转换或数字转换处理的数据量，要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。
3.4影响
说明这些数据要求对于设备、软件、用户、开发单位所可能产生的影响，例如要求用户单位增设某个机构等。

inksong

尽管在文件编制中存在着很多灵活性，然而，文件的编制确实是非常必要的，其意义如前所述。为了控制这种灵活性，保证文件编制能达到应该达到的目的，对于具体的软件开发任务，应编制的文件的种类、详细程度应取决于承担开发单位的管理能力、任务的规模、复杂性和成败风险等因素。一个软件开发单位应该根据本单位经营承包的应用软件的专业特点和本单位的管理能力，制定一个文件编制实施规定，说明在什么情况下应该编制哪些文件。由于国内目前在这方面还缺乏成熟的经验，这里提供参考国外经验制定的两个例子，用以向国内软件开发单位说明如何建立这种实施规定，使项目负责人能确定本项目开发过程中应编制的文件的种类。当然，例子毕竟只是例子，这两个例子各自都不免有其片面性，它们两者之间也不免有不一致之处，之所以列出来无非是供国内软件开发单位参考。
例1：
此例规定用求和法来确定应编制的文件。该方法的要点是提出十二个考虑因素来衡量一个应用软，件，每个因素可能取值的范围是互至5。任务负责人可用这十二个因素对所要开发的程序进行衡量，确定每个因素的具体值。把这十二个因素的值相加，得到一个总和。然后由这个总和的值来确定应该编制的文件的种类。使用这个方法的具体过程如下：
a.        按表OI中的十二个因素衡量所要开发的程序，得到每个因素的值；
b.        把衡量所得的各个因素的值相加，得总和之值；
c.        根据总和之值，从表OZ查出应编制的文件的种类。
表1文件编制的十二项衡量因素
序号        因素        因素取值准则
                1        2        3        4        5
1        创造性要求        没有——在不同的设备上重编程序        很少——具有严格的要求        有限——具有新的接口        相当多——应用现有的技巧        重大的——应用先进的技巧
2        通用程度        很强的限制——单一目标        有限制——功能的范围是参量化的        有限的灵活性允许格式上有某些变化        多用途，灵活的格式有一个主题领域        很灵活——能在不同的设备上处理范围广泛的主题
3        工作范围        局部单位        分指挥部        单个指挥部        多个指挥部        国防部，世界范围
4        目标范围的变化        没有        极少        偶尔有        经常        不断
5        设备复杂性        单机，常规处理        单机，常规处理，扩充的外设系统        多机，标准外设系统        多机，复杂的外设系统        主机控制系统，多机，自动I/O和显示
6        人员        1～2人        3～5人        5～10人        10～18人        18人以上
7        开发投资        6人月以下        6人月至3人年        3人年至10人年        10人年至30人年        30人年以上
8        重要程度        数据处理        常规过程控制        人身安全        单位成败        国家安全
9        对程序改变的完成时间要求        2周以上        1～2周        3～7天        1～3天        24小时以内
10        对数据输入的响应时间要求        2周以上        1～2周        1～7天        1～24小时        60分钟内
11        程序语言        高级语言        高级语言带一些汇编        高级语言带相当多的汇编        汇编语言        机器语言
12        并行的软件开发        没有        有限        中等程度        很多        完全的并行开发
表1文件编制的十二项衡量因素
因素总和        可行性研究报告        项目开发计划        软件需求说明书        数据要求说明书        概要设计说明书        详细设计说明书        数据库设计说明书        用户手册（使用说明）        操作手册        模块开发卷宗        测试设计        测试分析报告        项目开发总结报告        开发制度月报
12～18*
14～24
24～38
38～50
48～60       

√
√
√        √
√
√
√
√       
√
√
√
√       
***
***
***
***       


√
√       



√       
***
***
***
***        √
√
√
√
√       

√
√
√       
√
√
√
√       
√
√
√
√       
**
**
√
√        √
√
√
√
√       
√
√
√
√
*在因素总和较低的情况下,项目开发总结报告的内容应包括：程序的主要功能、基本流程、测试结果和使用说明。
**测试分析报告应该写，但不必很正规。
***数据要求说明和数据库设计说明是否需要编写应根据所开发软件的实际需要来决定。
例2：
为了避免在软件开发中文件编制的不足或过分，一个简便的办法是把对软件文件的编制要求同软件的规模大小联系起来，这就是本例的出发点。软件的规模不妨分为四级：
1.        小规模软件源程序行数小于5000的软件；
2.        中规模软件源程序行数为10000～50000的软件；
3.        大规模软件源程序行数为100000—500000的软件；
4.        特大规模软件源程序行数大于500000的软件。
对上述的四级软件的文件编制要求分别列于表3。
至于源程序行数为5000～10000，50000～100000的软件，其文件编制要求介于两级之间，可根据一个软件产品的具体情况，由项目负责人参照表3的规定，确定需要编制的文件种类。
对于源程序行数大于500000的特大规模软件，可进一步把本指南规定的十四种文件按实际需要扩展成更多种类，这一点在本指南5.3.3已经提到。
表3产品文件体系
(这里有个图，我不会传)

inksong

l标题
开发中的软件系统的名称和标识符
分项目名称和标识符
分项目负责人签名
本期月报编写人签名
本期月报的编号及所报告的年月
2工程进度与状态
2.1进度
列出本月内进行的各项主要活动，并且说明本月内遇到的重要事件，这里所说的重要事件是指一个开发阶段（即软件生存周期内各个阶段中的某一个，例如需求分析阶段）的开始或结束，要说明阶段名称及开始（或结束）的日期。
2.2状态
说明本月的实际工作进度与计划相比，是提前了、按期完成了、或是推迟了？如果与计划不一致，说 明原因及准备采取的措施。
3资额耗用与状态
3.1资额耗用
主要说明本月份内耗用的工时与机时。
3.1.1工时
分为三类：
a．        管理用工时包括在项目管理（制订计划、布置工作、收集数据、检查汇报工作等）方面耗用的工时；
b．        服务工时包括为支持项目开发所必须的服务工作及非直接的开发工作所耗用的工时；
c．        开发用工时要分各个开发阶段填写。
3.1.2机时
说明本月内耗用的机时，以小时为单位，说明计算机系统的型号。
3.2状态
说明本月内实际耗用的资源与计划相比，是超出了、相一致、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。
4经费支出与状态
4.1经费支出
4.1.1支持性费用
列出本月内支出的支持性费用，一般可按如下七类列出，并给出本月支持费用的总和：
a.        房租或房屋折旧费；
b.        社工资、奖金、补贴；
c.        培训费包括给教师的酬金及教室租金；
d.        资料费包括复印及购买参考资料的费用；
e.        会议费召集有关业务会议的费用；
f.        旅差费；
g.        其他费用。
4.1.2设备购置费
列出本月内支出的设备购置费，一般可分如下三类：
a．        购买软件的名称与金额；
b．        购买硬设备的名称、型号、数量及金额；
c．        已有硬设备的折旧费。
4.2状态
说明本月内实际支出的经费与计划相比较，是超过了。相符合、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。
5下个月的工作计划
6建议
本月遇到的重要问题和应引起重视的问题以及因此产生的建议。

inksong

1引言
1.1编写目的
说明编写这份项目开发总结报告的目的，指出预期的阅读范围。
1.2背景
说明：
a．        本项目的名称和所开发出来的软件系统的名称；
b．        此软件的任务提出者、开发者、用户及安装此软件的计算中心。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a．        本项目的已核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处所引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2实际开发结果
2.1产品
说明最终制成的产品，包括：
a．        程序系统中各个程序的名字，它们之间的层次关系，以千字节为单位的各个程序的程序量、存储媒体的形式和数量；
b．        程序系统共有哪几个版本，各自的版本号及它们之间的区别；
c．        每个文件的名称；
d．        所建立的每个数据库。 如果开发中制订过配置管理计划，要同这个计划相比较。
2.2主要功能和性能
逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。
2.3基本流程
用图给出本程序系统的实际的基本的处理流程。
2.4进度
列出原定计划进度与实际进度的对比，明确说明，实际进度是提前了、还是延迟了，分析主要原因。
2.5费用
列出原定计划费用与实际支出费用的对比，包括：
a.        工时，以人月为单位，并按不同级别统计；
b.        计算机的使用时间，区别CPU时间及其他设备时间；
c.        物料消耗、出差费等其他支出。
明确说明，经费是超出了、还是节余了，分析其主要原因。
3开发工作评价
3.1对生产效率的评价
给出实际生产效率，包括：
a．        程序的平均生产效率，即每人月生产的行数；
b．        文件的平均生产效率，即每人月生产的千字数；
并列出原订计划数作为对比。
3.2对产品质量的评价
说明在测试中检查出来的程序编制中的错误发生率，即每干条指令（或语句）中的错误指令数（或语句数）。如果开发中制订过质量保证计划或配置管理计划，要同这些计划相比较。
3.3对技术方法的评价
给出对在开发中所使用的技术、方法、工具、手段的评价。
3.4出错原因的分析
给出对于开发中出现的错误的原因分析。
4经验与教训
列出从这项开发工作中所得到的最主要的经验与教训及对今后的项目开发工作的建议。

inksong

1引言
1.1编写目的
说明编写这份用户手册的目的，指出预期的读者。
1.2背景
说明：
a.        这份用户手册所描述的软件系统的名称；
b.        该软件项目的任务提出者、开发者、用户（或首批用户）及安装此软件的计算中心。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有用的参考资料，如：
a.        项目的经核准的计划任务书或合同、上级机关的批文；
b.        属于本项目的其他已发表文件；
c.        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够取得这些文件资料的来源。
2用途
2.1功能
结合本软件的开发目的逐项地说明本软件所具有各项功能以及它们的极限范围。
2.2性能
2.2.1精度
逐项说明对各项输入数据的精度要求和本软件输出数据达到的精度，包括传输中的精度要求。
2.2.2时间特性
定量地说明本软件的时间特性，如响应时间，更新处理时间，数据传输、转换时间，计算时间等。
2.2.3灵活性
说明本软件所具有的灵活性，即当用户需求（如对操作方式、运行环境、结果精度、时间特性等的要求）有某些变化时，本软件的适应能力。
2.3安全保密
说明本软件在安全、保密方面的设计考虑和实际达到的能力。
3运行环境
3.1硬设备
列出为运行本软件所要求的硬设备的最小配置，如：
a.        处理机的型号、内存容量；
b.        所要求的外存储器、媒体、记录格式、设备的型号和台数、联机／脱机；
c.        I／O设备（联机／脱机？）；
d.        数据传输设备和转换设备的型号、台数。
3.2支持软件
说明为运行本软件所需要的支持软件，如：
a．        操作系统的名称、版本号；
b．        程序语言的编译／汇编系统的名称和版本号；
c．        数据库管理系统的名称和版本号；
d．        其他支持软件。
3.3数据结构
列出为支持本软件的运行所需要的数据库或数据文卷。
4使用过程
在本章，首先用图表的形式说明软件的功能同系统的输入源机构、输出接收机构之间的关系。
4.1安装与初始化
一步一步地说明为使用本软件而需进行的安装与初始化过程，包括程序的存储形式、安装与初始化过程中的全部操作命令、系统对这些命令的反应与答复。表征安装工作完成的测试实例等。如果有的话，还应说明安装过程中所需用到的专用软件。
4.2输入
规定输入数据和参量的准备要求。
4.2.1输入数据的现实背景
说明输入数据的现实背景，主要是
a.        情况——例如人员变动、库存缺货；
b.        情况出现的频度——例如是周期性的、随机的、一项操作状态的函数；
c.        情况来源—一例如人事部门、仓库管理部门；
d.        输入媒体———例如键盘、穿孔卡片、磁带；
e.        限制——出于安全、保密考虑而对访问这些输入数据所加的限制；
f.        质量管理——例如对输入数据合理性的检验以及当输入数据有错误时应采取的措施，如建立出错情况的记录等；
g.        支配——例如如何确定输入数据是保留还是废弃，是否要分配给其他的接受者等。
4.2.2输入格式
说明对初始输入数据和参量的格式要求，包括语法规则和有关约定，如：
a.        长度—一例如字符数／行，字符数／项；
b.        格式基准——例如以左面的边沿为基准；
c.        标号——例如标记或标识符；
d.        顺序——例如各个数据项的次序及位置；
e.        标点——例如用来表示行、数据组等的开始或结束而使用的空格、斜线、星号、字符组等。
f.        词汇表——给出允许使用的字符组合的列表，禁止使用＊的字符组合的列表等；
g.        省略和重复——给出用来表示输人元素可省略或重复的表示方式；
h.        控制——给出用来表示输入开始或结束的控制信息。
4.2.3输入举例
为每个完整的输入形式提供样本，包括：
a．        控制或首部——例如用来表示输入的种类和类型的信息，标识符输入日期，正文起点和对所用编码的规定；
b．        主体——输入数据的主体，包括数据文卷的输入表述部分；
c．        尾部——用来表示输入结束的控制信息，累计字符总数等；
d．        省略——指出哪些输入数据是可省略的；
e．        重复——指出哪些输入数据是重复的。
4.3输出对每项输出作出说明
4.3.1输出数据的现实背景
说明输出数据的现实背景，主要是：
a．        使用——这些输出数据是给谁的，用来干什么；
b．        使用频度——例如每周的、定期的或备查阅的；
c．        媒体——打印、CRI显示、磁带、卡片、磁盘，
d．        质量管理—一例如关于合理性检验、出错纠正的规定；
e．        支配——例如如何确定输出数据是保留还是废弃，是否要分配给其他接受者等。
4.3.2输出格式
给出对每一类输出信息的解释，主要是：
a．        首部——如输出数据的标识符，输出日期和输出编号；
b．        主体——输出信息的主体，包括分栏标题；
c．        尾部——包括累计总数，结束标记。
4.3.3输出举例
为每种输出类型提供例子。对例子中的每一项，说明：
a．        定义——每项输出信息的意义和用途；
b．        来源——是从特定的输入中抽出、从数据库文卷中取出、或从软件的计算过程中得到；
c．        特性——输出的值域、计量单位、在什么情况下可缺省等。
4.4文卷查询
这一条的编写针对具有查询能力的软件，内容包括：同数据库查询有关的初始化、准备、及处理所需 要的详细规定，说明查询的能力、方式，所使用的命令和所要求的控制规定。
4.5出错处理和恢复
列出由软件产生的出错编码或条件以及应由用户承担的修改纠正工作。指出为了确保再启动和恢复的能力，用户必须遵循的处理过程。
4.6终端操作
当软件是在多终端系统上工作时，应编写本条，以说明终端的配置安排、连接步释、数据和参数输入步骤以及控制规定．说明通过终端操作进行查询、检索、修改数据文卷的能力、语言、过程以及辅助性程序等。

inksong

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.        与运行有联系的其他事项。
4.3.3输入一输出文卷
提供被本运行建立、更新或访问的数据文卷的有关信息，如：
a.        文卷的标识符或标号；
b.        记录媒体；
c.        存留的目录表；
d.        文卷的支配如确定保留或废弃的准则、是否要分配给其他接受者、占用硬设备的优先级以及保密控制等有关规定。
4.3.4输出文段
提供本软件输出的每一一个用于提示、说明、或应答的文段（包括“菜单”）的有关信息，如：
a.        文段的标识符；
b.        输出媒体（屏幕显示、打印、……）；
c.        文字容量；
d.        分发对象；
e.        保密要求。
4.3.5输出文段的复制
对由计算机产生，而后需用其他方法复制的那些文段提供有关信息，如：
a.        文段的标识符；
b.        复制的技术手段；
c.        纸张或其他媒体的规格；
d.        装订要求；
e.        分发对象；
f.        复制份数。
4.3.6恢复过程
说明本运行故障后的恢复过程。
4.4运行2（标识符）说明
用与本手册4.3条相类似的方式介绍另一个运行的有关信息。
5非常规过程
提供有关应急操作或非常规操作的必要信息，如出错处理操作、向后备系统的切换操作以及其他必须向程序维护人员交待的事项和步骤。
6远程操作
如果本软件能够通过远程终端控制运行，则在本章说明通过远程终端运行本软件的操作过程。

inksong

1引言
1.1编写目的
本测试计划的具体编写目的，指出预期的读者范围。
1.2背景
说明：
a．        测试计划所从属的软件系统的名称；
b．        该开发项目的历史，列出用户和执行此项目测试的计算中心，说明在开始执行本测试计划之前必须完成的各项工作。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2计划
2.1软件说明
提供一份图表，并逐项说明被测软件的功能、输入和输出等质量指标，作为叙述测试计划的提纲。
2.2测试内容
列出组装测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的，例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行时间的测试、设计约束和极限的测试等。
2.3测试1（标识符）
给出这项测试内容的参与单位及被测试的部位。
2.3.1进度安排
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境。培训、准备输入数据等）。
2.3.2条件
陈述本项测试工作对资源的要求，包括：
a．        设备所用到的设备类型、数量和预定使用时间；
b．        软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件，如测试驱动程序、测试监控程序、仿真程序、桩模块等等；
c．        人员列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术水平及有关的预备知识，包括一些特殊要求，如倒班操作和数据键入人员。
2.3.3测试资料
列出本项测试所需的资料，如：
a．        有关本项任务的文件；
b．        被测试程序及其所在的媒体；
c．        测试的输入和输出举例；
d．        有关控制此项测试的方法、过程的图表。
2.3.4测试培训
说明或引用资料说明为被测软件的使用提供培训的计划。规定培训的内容、受训的人员及从事培训的工作人员。
2.4测试2（标识符）
用与本测试计划2.3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。
3测试设计说明
3.1测试1（标识符）
说明对第一项测试内容的测试设计考虑。
3.1.1控制
说明本测试的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果的记录方法。
3.1.2输入
说明本项测试中所使用的输入数据及选择这些输入数据的策略。
3.1.3输出
说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息。
3.1.4过程
说明完成此项测试的一个个步骤和控制命令，包括测试的准备、初始化、中间步聚和运行结束方式。
3.2测试2（标识符）
用与本测试计划3.l条相类似的方式说明第2项及其后各项测试工作的设计考虑。
4评价准则
4.1范围
说明所选择的测试用例能够接查的范围及其局限性。
4.2数据整理
陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同，已知结果进行比较而要用到的转换处理技术，如手工方式或自动方式；如果是用自动方式整理数据，还要说明为进行处理而要用到的硬件、软件资源。
4.3尺度
说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。

inksong

1引言
1.1编写目的
说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
1.2背景
说明：
a.        被测试软件系统的名称；
b.        该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境 之间可能存在的差异以及这些差异对测试结果的影响。
1.3定义
列出本文件中用到的专问术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2测试概要
用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3测试结果及发现
3.1测试1（标识符）
把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
3.2测试2（标识符）
用类似本报告3.1条的方式给出第 2项及其后各项测试内容的测试结果和发现。
4对软件功能的结论
4.1功能1（标识符）
4.1.1能力
简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
4.1.2限制
说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
4.2功能2（标识符）
用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。
．．．．．．
5分析摘要
5.1能力
陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异 对能力的测试所带来的影响。
5.2缺陷和限制
陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。
5.3建议
对每项缺陷提出改进建议，如：
a．        各项修改可采用的修改方法；
b．        各项修改的紧迫程度；
c．        各项修改预计的工作量；
d．        各项修改的负责人。
5.4评价
说明该项软件的开发是否已达到预定目标，能否交付使用。
6测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。

inksong

1.1        目的
此文档是根据TPUP中定义的Test Workflow形成的软件测试过程 ，明确在TPUP的各阶段的测试工作内容。
1.2        背景
为了按照TPUP进行软件开发和测试活动，特制作该文档。
1.3        范围
此文档可运用于采用TPUP开发的任一软件项目。
1.4        定义
1.4.1        测试的软件错误级别：
按照对工作功能的影响程度，将错误分为以下5级：
一级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。
二级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。
三级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。
四级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
五级：其他错误。
1.4.2        单元测试（Unit Testing）：
单元测试是对最小的可测试软件元素（单元）实施的测试。它所测试的内容包括内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。
1.4.3        集成测试（Integration Testing）：
集成测试是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。
1.4.4        系统测试（System Testing）：
系统测试是通过与系统的需求定义作比较，发现软件与系统定义不相符合或与之矛盾的地方。它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统所进行的一系列集成测试和确认测试。
1.4.5        验收测试（Acceptance Testing）：
1.5        验收测试是系统测试的延续，这种测试是确定系统是否符合它的验收标准，并使客户、用户或经授权的实体能够确定接受该系统。缩略词
TPUP                   托普统一开发过程
RUP                     Rational统一开发过程
SEPG                       软件工程过程组
SQA                       软件质量保证
SCM                    软件配置管理
SDP                     软件开发计划
2.        过程描述
2.1        软件测试过程总观
软件测试包括下列七个阶段：
a.        计划测试阶段– 开展下列计划活动：
1.        测试总体计划。
2.        计划系统测试。
3.        计划集成测试。
4.        计划单元测试。
b.        设计测试阶段—开展下列设计活动
1.        设计系统测试用例。
2.        设计集成测试用例。
3.        设计单元测试用例。
4.        设计测试过程。
5.        设计单元测试和集成测试所需要的驱动程序和桩模块。
c.        实施测试阶段—开展下列活动
1.        制作测试脚本。
d.        单元测试阶段—开展下列活动
1.        根据单元测试计划以及单元测试用例、测试过程（脚本）执行单元测试。
2.        记录单元测试结果。
3.        评估单元测试活动。
e.        集成测试阶段—开展下列活动
1.        根据集成测试计划以及集成测试用例、测试过程（脚本）执行集成测试。
2.        记录集成测试结果。
3.        评估集成测试活动。
f.        系统测试阶段—开展下列活动
1.        根据系统测试计划以及系统测试用例、测试过程（脚本）执行系统测试。
2.        记录系统测试结果。
3.        评估系统测试活动。
g.        验收测试阶段—开展下列活动
1.        根据委托方制定的验收标准，选取系统测试用例的一个子集执行验收测试。
2.        记录验收测试结果，根据验收标准得出验收测试结论。
2.2        角色和职责
下面定义的各角色在项目开展前需要经过相关培训，掌握开展角色活动所需要的技能。
2.2.1        软件测试组
2.2.1.1 测试设计员
测试设计员负责下列活动：
a.        制定系统、集成、单元测试计划。
b.        设计系统、集成、单元测试用例、测试过程、测试脚本。
c.        评估系统、集成、单元测试活动。
2.2.1.2 测试员
测试员负责下列活动：
a.        在集成测试阶段按照集成测试用例执行集成测试
b.        记录集成测试结果
c.        在系统测试阶段按照系统测试用例执行系统测试
d.        记录系统测试结果
2.2.2        设计员
设计员负责下列活动：
a.        设计单元测试、集成测试所需要的驱动程序、桩模块
2.2.3          集成员
集成员负责下列活动：
a.        制定软件集成计划。
b.        集成软件工作版本。
2.2.4        实施员
实施员负责下列活动：
a.        编写驱动程序和桩模块
b.        在单元测试阶段按照单元测试用例执行单元测试
c.        记录单元测试结果
2.2.5        SQA
SQA 审计软件测试过程。向项目经理报告其结果。
2.2.6        SEPG
SEPG 维护此文档并对其进行更新以满足TPUP的需要。SEPG为项目提供支持并可提供软件测试过程培训。
2.2.7          SCM
配置管理员负责对所有测试工件进行配置管理。
2.2.8        客户、用户或经授权的实体
执行验收测试。
2.3        过程详述
2.3.1        计划测试阶段
2.3.1.1 主要活动
主要活动        输入工件        输出工件
测试总体计划        Software Development Plan (Draft)
        主测试计划 (Baseline)
计划系统测试        Use Case Model（Baseline）
Supplementary Specification (Baseline)
Software Development Plan (Draft)
Iteration Plan        软件系统测试计划 (Baseline)
Software Development Plan (Baseline)
计划集成测试        Design Model (Baseline)
Software Development Plan
Software Integration Plan (Baseline)
Iteration Plan        软件集成测试计划 (Baseline)
计划单元测试        Design Model
Implement Model
Software Development Plan
Iteration Plan        软件单元测试计划 (Baseline)
a.        测试总体计划：
时机：Inception Phase第一个迭代后期进行。
输入：Software Development Plan（Draft）
活动：明确测试的范围、需要的资源。定义角色等。
输出：Main Test Plan

b.        计划系统测试
进入准则：
a)        SRS（Use Case Model & Supplementary Specification）形成文档，纳入基线。
时机：Elaboration Phase第一个迭代前期进行。
输入：SRS、SDP(Draft)
活动：制定System Test Plan。
输出：System Test Plan
退出准则：
a)        所有SRS中的需求在测试计划中指定了相应的测试用例包对其进行跟踪。
b)        测试计划被批准并且置于配置管理之下。

c.        计划集成测试
进入准则：
a)        Design Model 形成文档、纳入基线。
时机：在Elaboration的中、后期进行。在以后的迭代中增加。
输入：Design Model、Software Integration Plan、Iteration Plan
活动：制定集成测试计划
输出：Integration Test Plan
退出准则：
a)        所有的集成版本都进行了描述、并且每一集成版本内Class 之间的接口都建立了跟踪。
b)        测试计划被批准并且置于配置管理之下。

d.        计划单元测试
进入准则：
a)        Design Model 形成文档、纳入基线。
时机：在Elaboration的中、后期进行，在以后的迭代中增加。
输入：Design Model、Software Integration Plan、Iteration Plan
活动：制定单元测试计划
输出：Unit Test Plan
退出准则：
a)        测试计划被批准并且置于配置管理之下。
2.3.2        设计测试阶段
2.3.2.1 主要活动
主要活动        输入工件        输出工件
设计系统测试        Use Case Model
Supplementary Specification
System Test Plan        软件系统测试用例
软件系统测试过程
工作量分析文档（仅供性能测试用）
设计集成测试        Design Model
Implementation Model
Integration Test Plan        软件集成测试用例
软件集成测试过程
驱动程序或桩模块
设计单元测试        Design Model
Implementation Model
Unit Test Plan        软件单元测试用例
驱动程序或桩模块
a.        设计系统测试
进入准则：System Test Plan被基线化。
时机：在Elaboration第一个迭代前期。
输入：SRS（Use Case Specification、Supplementary Specification）、System Test Plan
活动：制定系统测试用例。
制定系统测试过程。
输出：System Test Cases、System Test Procedure、Workload  Analysis Document
退出准则：
a)        所有的软件需求能够被测试用例跟踪。
b)        测试用例和测试过程被批准且基线化。

b.        设计集成测试
进入准则：Integration Test Plan被基线化。
时机：在Elaboration第一个迭代后期，以后的迭代新增。
输入：Integration Test Plan、Software Integration Plan、Design Model
活动：
a)        制定集成测试用例（可以部分重用系统测试用例）。
b)        制定集成测试过程（可以部分重用系统测试过程）。
c)        开发集成测试所需要的驱动程序和桩模块。       

输出：Integration Test Cases、Integration Test Procedures、Drives、Stubs
退出准则：测试用例和测试过程被批准，并且被基线化。

c.        设计单元测试
进入准则：Unit Test  Plan被基线化。
时机：在Elaboration第一个迭代后期进行，以后的迭代增加。
输入：Design Model、Implement Model、Unit Test Plan
活动：
a)        制定单元测试用例
b)        开发单元测试驱动程序或桩模块。
输出：Unit Test Cases、Unit Test Drivers、Unit Test Stubs
退出准则：Unit Test Cases被批准并基线化。
2.3.3        实施测试阶段
2.3.3.1         进入准则
测试用例和测试过程被批准并基线化
2.3.3.2         输入
系统测试用例、系统测试过程、集成测试用例、集成测试过程
2.3.3.3         活动
编制测试脚本
2.3.3.4 输出
测试脚本（Test Scripts）
2.3.3.5         退出准则
测试脚本通过编译、顺利运行。
2.3.4        单元测试阶段
2.3.4.1 进入准则：
a.   完成单元（Class）的编码
b.        代码无错误地通过编译
2.3.4.2 输入：
a.        Implement model
b.        Class
c.        Unit Test Plan
d.        Unit Test Cases
b.             单元测试所需要的驱动程序和桩模块。
2.3.4.3 活动：
a、        执行单元测试
b、       评估单元测试
2.3.4.4 输出：
a、        单元测试日志
b、       单元测试评估报告
2.3.4.5 退出准则：
a、        软件单元功能与设计一致。
b、        软件单元接口与设计一致。
c、        能够正确处理输入和运行中的错误。
d、        在单元测试中发现的错误已经得到修改并且通过了测试。
e、        达到了相关的覆盖率的要求。
1、        语句覆盖率达到100%。
2.3.5          集成测试阶段
2.3.5.1 进入准则
a.   软件集成策略已被制定。
b.   被集成的模块通过了单元测试
c.        需要的驱动程序或桩模块已经开发。
2.3.5.2 输入：
a、        Design Model
b、        Implementation Model
c、        按照集成策略集成的版本。
d、        软件集成计划。
e、        集成测试用例、测试过程、测试脚本。
f、        集成测试计划。
c.        驱动程序或桩模块。
2.3.5.3 活动
a、        执行集成测试
b、        回归测试以前的集成
c、        记录测试结果
d、          集成增量模块，重复a-c，直到增量集成结束。
e、        评估集成测试
2.3.5.4 输出
a、        集成测试日志
b、        集成测试评估报告
2.3.5.5 退出准则
a、软件单元无错误地连接。
b、满足各项功能、性能要求。
c、按照增量集成策略完成了整个系统的集成以及测试。
d、 在集成测试中发现的错误已经得到修改并且通过了测试。
2.3.6        系统测试阶段
2.3.6.1 进入准则
a.        所有的模块按照集成策略全部集成且通过了集成测试
2.3.6.2 输入：
a、        软件需求规格说明书（Use Case Model & Supplementary Specification）。
b、        软件系统。
c、        软件系统测试计划。
d、        软件系统测试用例、测试过程、测试脚本
2.3.6.3 活动
a、执行系统测试
根据测试计划、测试用例、系统测试指南作下列类型的测试：
功能确认测试
性能测试
安全性测试
故障转移及恢复测试
强度（压力）测试

inksong

2.3        过程详述
2.3.1        计划测试阶段
2.3.1.1 主要活动
主要活动        输入工件        输出工件
测试总体计划        Software Development Plan (Draft)
        主测试计划 (Baseline)
计划系统测试        Use Case Model（Baseline）
Supplementary Specification (Baseline)
Software Development Plan (Draft)
Iteration Plan        软件系统测试计划 (Baseline)
Software Development Plan (Baseline)
计划集成测试        Design Model (Baseline)
Software Development Plan
Software Integration Plan (Baseline)
Iteration Plan        软件集成测试计划 (Baseline)
计划单元测试        Design Model
Implement Model
Software Development Plan
Iteration Plan        软件单元测试计划 (Baseline)
a.        测试总体计划：
时机：Inception Phase第一个迭代后期进行。
输入：Software Development Plan（Draft）
活动：明确测试的范围、需要的资源。定义角色等。
输出：Main Test Plan

b.        计划系统测试
进入准则：
a)        SRS（Use Case Model & Supplementary Specification）形成文档，纳入基线。
时机：Elaboration Phase第一个迭代前期进行。
输入：SRS、SDP(Draft)
活动：制定System Test Plan。
输出：System Test Plan
退出准则：
a)        所有SRS中的需求在测试计划中指定了相应的测试用例包对其进行跟踪。
b)        测试计划被批准并且置于配置管理之下。

c.        计划集成测试
进入准则：
a)        Design Model 形成文档、纳入基线。
时机：在Elaboration的中、后期进行。在以后的迭代中增加。
输入：Design Model、Software Integration Plan、Iteration Plan
活动：制定集成测试计划
输出：Integration Test Plan
退出准则：
a)        所有的集成版本都进行了描述、并且每一集成版本内Class 之间的接口都建立了跟踪。
b)        测试计划被批准并且置于配置管理之下。

d.        计划单元测试
进入准则：
a)        Design Model 形成文档、纳入基线。
时机：在Elaboration的中、后期进行，在以后的迭代中增加。
输入：Design Model、Software Integration Plan、Iteration Plan
活动：制定单元测试计划
输出：Unit Test Plan
退出准则：
a)        测试计划被批准并且置于配置管理之下。
2.3.2        设计测试阶段
2.3.2.1 主要活动
主要活动        输入工件        输出工件
设计系统测试        Use Case Model
Supplementary Specification
System Test Plan        软件系统测试用例
软件系统测试过程
工作量分析文档（仅供性能测试用）
设计集成测试        Design Model
Implementation Model
Integration Test Plan        软件集成测试用例
软件集成测试过程
驱动程序或桩模块
设计单元测试        Design Model
Implementation Model
Unit Test Plan        软件单元测试用例
驱动程序或桩模块
a.        设计系统测试
进入准则：System Test Plan被基线化。
时机：在Elaboration第一个迭代前期。
输入：SRS（Use Case Specification、Supplementary Specification）、System Test Plan
活动：制定系统测试用例。
制定系统测试过程。
输出：System Test Cases、System Test Procedure、Workload  Analysis Document
退出准则：
a)        所有的软件需求能够被测试用例跟踪。
b)        测试用例和测试过程被批准且基线化。

b.        设计集成测试
进入准则：Integration Test Plan被基线化。
时机：在Elaboration第一个迭代后期，以后的迭代新增。
输入：Integration Test Plan、Software Integration Plan、Design Model
活动：
a)        制定集成测试用例（可以部分重用系统测试用例）。
b)        制定集成测试过程（可以部分重用系统测试过程）。
c)        开发集成测试所需要的驱动程序和桩模块。       

输出：Integration Test Cases、Integration Test Procedures、Drives、Stubs
退出准则：测试用例和测试过程被批准，并且被基线化。

c.        设计单元测试
进入准则：Unit Test  Plan被基线化。
时机：在Elaboration第一个迭代后期进行，以后的迭代增加。
输入：Design Model、Implement Model、Unit Test Plan
活动：
a)        制定单元测试用例
b)        开发单元测试驱动程序或桩模块。
输出：Unit Test Cases、Unit Test Drivers、Unit Test Stubs
退出准则：Unit Test Cases被批准并基线化。
2.3.3        实施测试阶段
2.3.3.1         进入准则
测试用例和测试过程被批准并基线化
2.3.3.2         输入
系统测试用例、系统测试过程、集成测试用例、集成测试过程
2.3.3.3         活动
编制测试脚本
2.3.3.4 输出
测试脚本（Test Scripts）
2.3.3.5         退出准则
测试脚本通过编译、顺利运行。
2.3.4        单元测试阶段
2.3.4.1 进入准则：
a.   完成单元（Class）的编码
b.        代码无错误地通过编译
2.3.4.2 输入：
a.        Implement model
b.        Class
c.        Unit Test Plan
d.        Unit Test Cases
b.             单元测试所需要的驱动程序和桩模块。
2.3.4.3 活动：
a、        执行单元测试
b、       评估单元测试
2.3.4.4 输出：
a、        单元测试日志
b、       单元测试评估报告
2.3.4.5 退出准则：
a、        软件单元功能与设计一致。
b、        软件单元接口与设计一致。
c、        能够正确处理输入和运行中的错误。
d、        在单元测试中发现的错误已经得到修改并且通过了测试。
e、        达到了相关的覆盖率的要求。
1、        语句覆盖率达到100%。
2.3.5          集成测试阶段
2.3.5.1 进入准则
a.   软件集成策略已被制定。
b.   被集成的模块通过了单元测试
c.        需要的驱动程序或桩模块已经开发。
2.3.5.2 输入：
a、        Design Model
b、        Implementation Model
c、        按照集成策略集成的版本。
d、        软件集成计划。
e、        集成测试用例、测试过程、测试脚本。
f、        集成测试计划。
c.        驱动程序或桩模块。
2.3.5.3 活动
a、        执行集成测试
b、        回归测试以前的集成
c、        记录测试结果
d、          集成增量模块，重复a-c，直到增量集成结束。
e、        评估集成测试
2.3.5.4 输出
a、        集成测试日志
b、        集成测试评估报告
2.3.5.5 退出准则
a、软件单元无错误地连接。
b、满足各项功能、性能要求。
c、按照增量集成策略完成了整个系统的集成以及测试。
d、 在集成测试中发现的错误已经得到修改并且通过了测试。
2.3.6        系统测试阶段
2.3.6.1 进入准则
a.        所有的模块按照集成策略全部集成且通过了集成测试
2.3.6.2 输入：
a、        软件需求规格说明书（Use Case Model & Supplementary Specification）。
b、        软件系统。
c、        软件系统测试计划。
d、        软件系统测试用例、测试过程、测试脚本
2.3.6.3 活动
a、执行系统测试
根据测试计划、测试用例、系统测试指南作下列类型的测试：
功能确认测试
性能测试
安全性测试
故障转移及恢复测试
强度（压力）测试
负载测试
配置测试
安装测试
以上类型的测试可以根据项目情况进行裁剪。
b、记录测试结果
c、评估测试活动
d、编写系统测试评估报告
2.3.6.4 输出
a、        系统测试日志
b、        系统测试评估报告
2.3.6.5 退出准则
a、系统满足需求规格说明书的要求 。
b、完全执行了系统测试计划中的每个测试用例。
C、在系统测试中发现的错误已经得到修改并且通过了测试。
2.3.7        验收测试阶段
验收测试阶段是客户、用户证明软件满足需求而执行的测试活动，一般是执行系统测试用例的一个子集来证明其满足验收标准。用户也可以授权某一实体来执行验收测试，但需要在委托合同中注明。
2.3.7.1 进入准则：
软件已经通过了系统测试。
2.3.7.2 输入
b.        a、项目立项审批表。软件需求规格说明书（SRS）
c.        软件系统。
d.        选择用于验收测试的系统测试用例、测试过程、测试脚本。
2.3.7.3 活动
执行验收测试。
2.3.7.4 输出
验收测试报告。
2.3.7.5 退出准则
完全执行所选择的系统测试用例。
根据测试结果，对被测试软件给出验收测试结论。
2.4        过程测量
•        各阶段的缺陷修复率。
•        各阶段计划测试的完成率。

fire83617

有效的，可行性高的测试规范要依公司实际情况而确定，可以借鉴和学习，最忌生搬硬套。
一套测试规范其主要目的在于提高工作效率，提高大家的工作热情，让工作在有条不紊且愉快的环境中展开。
我觉得要做到有效且可行性高，需做到以下几点：
1.集思广益，先在测试部门拿出一套出来，大家经过讨论后确定，然后广证意见。前期制定的时候我们必须做到所有人都参与了，这样，规范出来后大家按照规范来做的积极性就很高了，我想很少有人会自己打自己的脸吧？
2.规范必须因公司和产品不同而有所不同。就像有些公司并不适合走cmmi流程一样。大路通天，找到适合自己的路走是最快的，用高射炮打蚊子，岂非大材小用？反之，亦然。举一例，起抛砖引玉：
   我第一家公司的产品比较多元化也开发周边产品，其实说白了就一种产品，只不过对于平台的不同和客户不同经常冠不同的名字，我第二家公司只有一种产品，也就是一款软件，同类市场有很强、很成熟的国外产品，他们两家公司在需求分析阶段有着截然的不同：第一家公司，需求分析由开发做，然后开发测试一起评审；第二家公司,由测试提第一手需求，开发提第二手需求，然后开发测试一起评审得到最终的需求。而且我觉得他们这样做很合理，第一家就不说了，只分析第二家，为什么会有两手需求？为什么会由测试提第一手需求呢？原因在于公司的产品单一，加上为了保密和人员的流动性，很多开发人员只了解自己写的功能，对其他开发人员写的并不熟悉，而最熟悉公司产品的，反而是测试人员，而且市场上有其他同类产品，对比分析这块，测试人员比较有时间。而第二手需求只是更进一步的细化，让开发明确该如何实现功能，和实现什么样的功能。
3.规范不止是测试的流程、开发的流程、文档的管理和代码的标准，其实最重要的就是规范出属于自己公司的术语和专业词汇。也就是说你在描述bug或者交流的时候，你说出一个什么样的名词，别人通过了解规范知道你这个名词是什么意思。这样可以提高bug的可读性和严谨性，又可以提高交流的速度和质量，做到千人一词，那么就不会出现你自己“创造”新的名词，开发或者测试还来问你是什么意思的尴尬，既节省时间又提高效率。
    总之一句话：因人而异，各有千秋，集百家之长来完善自己，属于自己的才是最有效、最可行的测试规范。

zhuzx

由于内容太多，请想看的朋友通过下面的链接到我的博客看看，谢谢！！！
http://www.51testing.com/?33505/ ... e_itemid_93575.html
                    

                                           zhuzx
                                                              2008-09-24

tian910

还有一个“如何制定一份有效的，可行性高的测试规范？”我们更是期待您的精彩回答呀？

偶，先送点鲜花表示谢意！！！哈哈！！！

爱巢

好贴呀，和tian910同行一样，迫切希望您再继续回答后面的问题，分享您的测试经验。

zhuzx

爱巢和tian910朋友，不用急，我今天比较忙，后面一定回答，谢谢各位对我的关注！！！

                                         zhuzx

世博宝宝

zhuzx，今天通过您的链接去看了答题的答案，顺便浏览了您的博客，终于在您的博客相册里看到您的真面目了。真的很帅呢！！

chuming

不过还是很感谢你的无私分享精神！！！

archonwang

【如何制定一份有效的，可行性高的测试规范？】是一项管理性质的问题，我想一些模板、流程、方法、工具等等固然有用，却是不全面的。希望可以看到更多有深度的思考和解答。

附图是对测试管理中各项内容的简单分析。

[ 本帖最后由 archonwang 于 2008-9-25 16:28 编辑 ]

zhuzx

我今天下午抽空，在我的博客里回答了这个问题，请想看的朋友到我博客转转，呵呵！！！

http://www.51testing.com/?33505/ ... e_itemid_93689.html