发信人: bllsbgw(SPARK)
整理人: soaringbird(2002-03-05 15:20:58), 站内信件
|
附录K
测试计划的编写提示
（参考件）
K·1引言
K．1．1编写目的
本测试计划的具体编写目的，指出预期的读者范围。
K．1．2背景
说明：
a 测试计划所从属的软件系统的名称；
b．该开发项目的历史，列出用户和执行此项目测试的计算中心，说明在开始执行本测试计划之前必须完成的各项工作。
K．1．3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
K．1．4参考资料
列出要用到的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
K．2计划
K．2．1软件说明
提供一份图表，并逐项说明被测软件的功能、输入和输出等质量指标，作为叙述测试计划的提纲。
K．2．2测试内容 列出组装测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的，例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行时间的测试、设计约束和极限的测试等。
K．2．3测试1（标识符）
给出这项测试内容的参与单位及被测试的部位。
K．2．3.1进度安排
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境。培训、准备输入数据等）。
K．2．3.2条件
陈述本项测试工作对资源的要求，包括：
a．设备所用到的设备类型、数量和预定使用时间；
b．软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件，如测试驱动程序、测试监控程序、仿真程序、桩模块等等；
c．人员列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术水平及有关的预备知识，包括一些特殊要求，如倒班操作和数据键入人员。
K．2．3.3测试资料
列出本项测试所需的资料，如：
a．有关本项任务的文件；
b·被测试程序及其所在的媒体；
c．测试的输入和输出举例；
d．有关控制此项测试的方法、过程的图表。
K．2．3.4测试培训
说明或引用资料说明为被测软件的使用提供培训的计划。规定培训的内容、受训的人员及从事培训的工作人员。
K．2．4测试2（标识符）
用与本测试计划K．2．3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。
K．3测试设计说明
K．3.1测试1（标识符）
说明对第一项测试内容的测试设计考虑。
K．3．1．1控制
说明本测试的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果的记录方法。
K．3.1．2输入
说明本项测试中所使用的输入数据及选择这些输入数据的策略。
K．3．1．3输出
说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息。
K．3.1．4过程
说明完成此项测试的一个个步骤和控制命令，包括测试的准备、初始化、中间步聚和运行结束方式。
K.3.2测试2（标识符）
用与本测试计划K．3．l条相类似的方式说明第2项及其后各项测试工作的设计考虑。
K．4评价准则
K．4．1范围
说明所选择的测试用例能够接查的范围及其局限性。
K．4．2数据整理
陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同，已知结果进行比较而要用到的转换处理技术，如手工方式或自动方式；如果是用自动方式整理数据，还要说明为进行处理而要用到的硬件、软件资源。
K．4．3尺度
说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。
附录L
测试分析报告的编写提示
（参考件）
L·1引言
L·1·1编写目的
说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
L·1·2背景
说明：
a.被测试软件系统的名称；
b．该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境 之间可能存在的差异以及这些差异对测试结果的影响。
L·1．3定义
列出本文件中用到的专问术语的定义和外文首字母组词的原词组。
L·1·4参考资料
列出要用到的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
L·2测试概要
用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计 划中预先设计的内容之间的差别，说明作出这种改变的原因。
L·3测试结果及发现
L· 3.1测试1（标识符）
把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比 较，陈述其中的各项发现。
L．3．2测试2（标识符）
用类似本报告 L． 3． 1条的方式给出第 2项及其后各项测试内容的测试结果和发现。
L·4对软件功能的结论
L· 4． 1功能1（标识符）
L·4·1．1能力
简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
L·4·1·2限制
说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查 出的缺陷、局限性。
L·4．2功能2（标识符）
用类似本报告L．4．l的方式给出第2项及其后各项功能的测试结论。
．．．．．．
L·5分析摘要
L·5·1能力
陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实 现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异 对能力的测试所带来的影响。
L·5·2缺陷和限制
陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。
L·5·3建议
对每项缺陷提出改进建议，如：
a．各项修改可采用的修改方法；
b．各项修改的紧迫程度；
c．各项修改预计的工作量；
d．各项修改的负责人。
L·5．4评价
说明该项软件的开发是否已达到预定目标，能否交付使用。
L·6测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。
附录M
开发进度月报的缩写提示
（参考件）
M．l标题
开发中的软件系统的名称和标识符 分项目名称和标识符 分项目负责人签名 本期月报编写人签名 本期月报的编号及所报告的年月
M·2工程进度与状态
M·2．1进度
列出本月内进行的各项主要活动，并且说明本月内遇到的重要事件，这里所说的重要事件是指一个 开发阶段（即软件生存周期内各个阶段中的某一个，例如需求分析阶段）的开始或结束，要说明阶段名称 及开始（或结束）的日期。
M·2·2状态
说明本月的实际工作进度与计划相比，是提前了、按期完成了、或是推迟了？如果与计划不一致，说 明原因及准备采取的措施。
M·3资额耗用与状态
M.3.1 资额耗用
主要说明本月份内耗用的工时与机时。
M.3.1.1工时
分为三类：
a．管理用工时包括在项目管理（制订计划、布置工作、收集数据、检查汇报工作等）方面耗用的 工时；
b．服务工时包括为支持项目开发所必须的服务工作及非直接的开发工作所耗用的工时； C．开发用工时要分各个开发阶段填写。
M·3.1·2机时
说明本月内耗用的机时，以小时为单位，说明计算机系统的型号。
M·3·2状态
说明本月内实际耗用的资源与计划相比，是超出了、相一致、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。
M·4经费支出与状态
M·4·1经费支出
M·4·1．1支持性费用
列出本月内支出的支持性费用，一般可按如下七类列出，并给出本月支持费用的总和：
a. 房租或房屋折旧费；
b.社工资、奖金、补贴；
c．培训费包括给教师的酬金及教室租金；
d．资料费包括复印及购买参考资料的费用；
e．会议费召集有关业务会议的费用；
f·旅差费；
g．其他费用。
M．4．1．2设备购置费
列出本月内支出的设备购置费，一般可分如下三类：
a．购买软件的名称与金额；
b．购买硬设备的名称、型号、数量及金额；
c．已有硬设备的折旧费。
M·4·2状态
说明本月内实际支出的经费与计划相比较，是超过了。相符合、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。
M．5下个月的工作计划
M．6建议
本月遇到的重要问题和应引起重视的问题以及因此产生的建议。
附录N
项目开发总结报告的编写提示
（参考件）
N.I引言
N．1．1编写目的
说明编写这份项目开发总结报告的目的，指出预期的阅读范围。
N．1．2背景
说明：
a．本项目的名称和所开发出来的软件系统的名称；
b．此软件的任务提出者、开发者、用户及安装此软件的计算中心。
N.I．3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
N．1．4参考资料
列出要用到的参考资料，如：
a．本项目的已核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处所引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
N．2实际开发结果
N．2．1产品
说明最终制成的产品，包括：
a.程序系统中各个程序的名字，它们之间的层次关系，以千字节为单位的各个程序的程序量、存储媒体的形式和数量；
b．程序系统共有哪几个版本，各自的版本号及它们之间的区别；
c．每个文件的名称；
d．所建立的每个数据库。 如果开发中制订过配置管理计划，要同这个计划相比较。
N．2．2主要功能和性能
逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需 ．求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。
N．2．3基本流程
用图给出本程序系统的实际的基本的处理流程。
N．2．4进度
列出原定计划进度与实际进度的对比，明确说明，实际进度是提前了、还是延迟了，分析主要原因。
N．2．5费用
列出原定计划费用与实际支出费用的对比，包括：
a.工时，以人月为单位，并按不同级别统计；
b．计算机的使用时间，区别CPU时间及其他设备时间；
c．物料消耗、出差费等其他支出。
明确说明，经费是超出了、还是节余了，分析其主要原因。
N·3开发工作评价
N·3.1对生产效率的评价
给出实际生产效率，包括：
a．程序的平均生产效率，即每人月生产的行数；
b．文件的平均生产效率，即每人月生产的千字数；
并列出原订计划数作为对比。
N．3.2对产品质量的评价
说明在测试中检查出来的程序编制中的错误发生率，即每干条指令（或语句）中的错误指令数（或语句数）。如果开发中制订过质量保证计划或配置管理计划，要同这些计划相比较。
N·3.3对技术方法的评价
给出对在开发中所使用的技术、方法、工具、手段的评价。
N·3.4出错原因的分析
给出对于开发中出现的错误的原因分析。
N．4经验与教训
列出从这项开发工作中所得到的最主要的经验与教训及对今后的项目开发工作的建议。
附录O
文件给制实施规定的实例
（参考件）
尽管在文件编制中存在着很多灵活性，然而，文件的编制确实是非常必要的，其意义如前所述。为了控制这种灵活性，保证文件编制能达到应该达到的目的，对于具体的软件开发任务，应编制的文件的种类、详细程度应取决于承担开发单位的管理能力、任务的规模、复杂性和成败风险等因素。一个软件开发单位应该根据本单位经营承包的应用软件的专业特点和本单位的管理能力，制定一个文件编制实施规定，说明在什么情况下应该编制哪些文件。由于国内目前在这方面还缺乏成熟的经验，这里提供参考国外经验制定的两个例子，用以向国内软件开发单位说明如何建立这种实施规定，使项目负责人能确定本项目开发过程中应编制的文件的种类。当然，例子毕竟只是例子，这两个例子各自都不免有其片面性，它们两者之间也不免有不一致之处，之所以列出来无非是供国内软件开发单位参考。
例1：
此例规定用求和法来确定应编制的文件。该方法的要点是提出十二个考虑因素来衡量一个应用软，件，每个因素可能取值的范围是互至5。任务负责人可用这十二个因素对所要开发的程序进行衡量，确定每个因素的具体值。把这十二个因素的值相加，得到一个总和。然后由这个总和的值来确定应该编制的文件的种类。使用这个方法的具体过程如下：
a. 按表OI中的十二个因素衡量所要开发的程序，得到每个因素的值;
b．把衡量所得的各个因素的值相加，得总和之值；
c. 根据总和之值，从表OZ查出应编制的文件的种类。
表OI文件编制的十二项衡量因素
*在因素总和较低的情况下,项目开发总结报告的内容应包括：程序的主要功能、基本流程、测试结果和使用说明。
**测试分析报告应该写，但不必很正规。
* **数据要求说明和数据库设计说明是否需要编写应根据所开发软件的实际需要来决定。
例2：
为了避免在软件开发中文件编制的不足或过分，一个简便的办法是把对软件文件的编制要求同软件的规模大小联系起来，这就是本例的出发点。软件的规模不妨分为四级：
1．小规模软件源程序行数小于5 000的软件；
2．中规模软件源程序行数为 10 000～ 50 000的软件；
3．大规模软件源程序行数为 100 000—500 000的软件；
4．特大规模软件源程序行数大于500 000的软件。
对上述的四级软件的文件编制要求分别列于表O3。
至于源程序行数为 5 000～ 10 000， 50 000～ 100 000的软件，其文件编制要求介于两级之间，可根据一个软件产品的具体情况，由项目负责人参照表O3的规定，确定需要编制的文件种类。
对于源程序行数大于500 000的特大规模软件，可进一步把本指南规定的十四种文件按实际需要扩展成更多种类，这一点在本指南5．3．3已经提到。
|
|