模版集萃软件质量保证类.docx
《模版集萃软件质量保证类.docx》由会员分享，可在线阅读，更多相关《模版集萃软件质量保证类.docx（39页珍藏版）》请在冰豆网上搜索。
模版集萃软件质量保证类
模版集萃（软件质量保证类）
综述：
在程序员的日常工作中，除了编写代码之外，还免不了需要编写各种技术文档。
一个编写良好的技术文档在项目中能够很好地建立沟通与协作，起到很积极的作用。
因此，编写技术文档也就成为了程序员技能提升的很重要的一面。
为此，我们特意收集了一些在项目开发过程中经常用到的文档模板，这些模板包括格式和简单的写作说明，相信能够帮助大家编写出更加高效、实用的技术文档。
在收集过程中，我们十分注重其实用性，以确保每个模板的价值，而且对于一些重要的文档提供了多个模板。
为了方便大家查找，我们将收录的57模板分为以下几类：
1）项目及开发管理类：
包括立项前的分析，立项后的计划、以及进度跟踪、风险控制方面的文档模板，共计16个；
2）需求分析类：
明确清晰的需求，是项目成功的基础，在此收集了在需求分析过程中所将使用到的文档模板，共计14个；
3）系统分析与设计类：
包括体系结构设计、高层设计、详细设计、数据库设计等6个相关文档模板；
4）软件质量保证类：
软件测试是质量保证的关键活动，在此收集了软件测试相关的11个文档模板；
5）其它类：
除此之外，还收集了关于用户手册、软件维护等方面的10个文档模板，其中还有一个软件过程规范的示例。
另外，值得说明的是，文档模板只是为文档的编写提供一个基础，在实际的编写过程中，你可以根据自己的需要进行必要的剪裁和增补。
测试计划
编者说明：
要想系统性地完成一件事，首先要做好计划，测试工作是十分重要的，因此测试计划也是十分必要的。
该文档适用于集成测试、系统测试、验收测试的计划制订，并不适用于单元测试计划。
第1章引言
1.1综述
1.2参考文献
序号
名称
文件标识/版本
出版单位
出版日期
第2章测试项
2.1测试项
测试项名称
测试项标识
介质特性
变换要求
相关引用材料
2.2不测试的软件项
软件项名称
软件项标识
未测试原因
相关引用材料
第3章被测试的特性
特性或组合名称
测试设计说明编号
第4章不被测试的特性
特性或组合名称
测试设计说明编号
第5章方法
5.1<方法名称>
5.2<方法名称>
第6章项通过准则
第7章暂停标准和再启动要求
7.1暂停标准
7.2再启动要求
第8章应提供的测试文档
文档名称
标识符
第9章测试任务
序号
任务
前期任务
特殊技能
责任人
工作量（天）
完成日期
第10章环境要求
10.1硬件
10.2软件
10.3安全性
10.4工具
10.5文档
第11章职责
11.1测试组
11.2开发组
11.3……
第12章人员和培训要求
12.1人员
12.1.1测试组
12.2培训
第13章进度
13.1进度
序号
测试任务名称
工作量
开始日期
完成日期
13.2测试资源使用期限
第14章风险和应急
测试日志
编者说明：
测试都有一个结果，而这些结果对于软件质量保证活动来说是十分重要的，因此应该将这些结果有序地记录下来，这就是测试日志模板所要解决的问题。
第1章描述
1.1测试项
序号
测试项名称
标识符
版本
相关传递报告
1.2测试的环境
1.2.1硬件
1.2.2软件
第2章活动和事件条目
2.1<日期>
时间
活动描述
事件
2.2<日期>
测试设计说明
编者说明：
如果说测试计划是对测试的活动、人员进行安排，那么测试设计则是对测试方法、测试技术的说明。
第1章被测试的特性
1.1单项特性
1.2组合特性
1.3引用文档
第2章方法详述
2.1方法描述
2.2测试评价标准
2.3测试用例选择原则
2.4测试用例的共同属性和依赖关系
测试用例说明
编者说明：
测试计划解决的是怎么安排测试活动，测试设计说明是怎么测试，那么测试用例说明就是测试什么，也就是列出具体的测试项目，以使得测试有目的、有计划。
第1章测试项
1.1测试项名称
测试项名称
标识符
说明
1.2引用文档
编号
文档名称
章节名
第2章输入说明
序号
名称
值
类型
允许误差
输入方式
第3章输出说明
序号
名称
值
类型
允许误差
输出方式
第4章环境要求
4.1硬件
4.2软件
4.3其它
第5章特殊的规程要求
第6章用例间的依赖关系
6.1所依赖的用例
序号
用例名称或标识
6.2依赖关系的性质
集成测试计划（ISO标准）
编者说明：
前面的测试计划模板是一个通用性的，也可以是用于制定所有测试活动的计划，而本模块则是用来指导编写集成测试计划的。
1.引言
1.1编写目的
[说明编写这份测试计划目的，指出预期的读者。
]
1.2背景
a.待开发系统的名称；
b.列出本项目的任务提出者、开发者、用户。
1.3定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
]
1.4参考资料
[列出有关的参考资料。
]
2．计划
2.1系统说明
[提供一份图表，并逐项说明被测系统的功能、输入、输出等质量指标，作为叙述测试计划的提纲。
]
2.2测试内容
[列出集成测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的。
]
2.3测试1（标识符）
[给出这项测试内容的参与单位及被测试的部位。
]
2.3.1进度安排
[给出对这项测试的进度安排，包括进行测试的日期和工作内容。
]
2.3.2条件
[陈述本项测试工作对资源的要求。
包括：
]
a.硬件
b.软件
c.人员
2.3.3测试资料
[列出本项测试所需的资料。
]
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。
1条相类似的方式说明第2项及其后各项测试工作的设计考虑。
]
[……]
4．评价准则
4.1范围
[说明所选择的测试用例能够检查的范围及其局限性。
]
4.2数据整理
[陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同已知结果进行比较而要用到的转换处理技术；如果是用自动方式整理数据，还要说明为进行处理而要用到的硬件、软件资源。
]
4.3尺度
[说明用来判断测试工作是否能通过的评价尺度，如合理和输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大数。
]
软件集成测试工作流程指南
编者说明：
严格地说，该文档不属于文档模板，它只是一个工作指南。
要想更好地完成集成测试工作，你就需要为团队制定一个工作指南。
你可以根据该文档，结合实际进行修改。
1.简介
1.1目的
本文详细阐述了集成测试流程，指导项目开发人员如何开展软件集成测试。
1.2范围
此指南可运用于使用RUP的任一软件项目的集成测试。
1.3参考文件
SoftwareTestProcess
RationalUnifiedProcess
1.4定义与缩写
RUP：
统一开发过程
SIT：
软件集成测试
SEPG：
软件工程过程小组
SQA：
软件质量保证
2.集成测试指南
2.1简介
集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。
它所测试的内容包括单元间的接口以及集成后的功能。
使用黑盒测试方法测试集成的功能。
并且对以前的集成进行回归测试。
2.2单元测试工作内容及其流程
活动
输入工件
输出工件
参与角色和职责
制定集成测试计划
设计模型
集成构建计划
集成测试计划
测试设计员负责制定集成测试计划
设计集成测试
集成测试计划
设计模型
集成测试用例
测试过程
测试设计员负责设计集成测试用例和测试过程。
实施集成测试
集成测试用例
测试过程
工作版本
测试脚本（可选）
测试过程（更新）
测试设计员负责编制测试脚本（可选），更新测试过程。
驱动程序或稳定桩
设计员负责设计驱动程序和桩，实施员负责实施驱动程序和桩。
执行集成测试
测试脚本（可选）
工作版本
测试结果
测试员负责执行测试并记录测试结果
评估集成测试
集成测试计划
测试结果
测试评估摘要
测试设计员负责会同集成员、编码员、设计员等有关人员（具体化）评估此次测试，并生成测试评估摘要。
2.3集成测试需求获取
集成测试需求所确定的是对某一集成工作版本的测试的内容，即测试的具体对象。
集成测试需求主要来源于设计模型（DesignModel）和集成构件计划（IntegrationBuildPlan）。
集成测试着重于集成版本的外部接口的行为。
因此，测试需求须具有可观测、可测评性。
1.集成工作版本应分析其类协作与消息序列，从而找出该工作版本的外部接口。
2.由集成工作版本的外部接口确定集成测试用例。
3.测试用例应覆盖工作版本每一外部接口的所有消息流序列。
注意：
一个外部接口和测试用例的关系是多对多，部分集成工作版本的测试需求可映射到系统测试需求，因此对这些集成测试用例可采用重用系统测试用例技术。
2.4集成测试工作机制
软件集成测试工作由产品评测部担任。
需要项目组相关角色配合完成。
如图示：
软件评测部：
角色
职责
测试设计员
负责制定集成测试计划、设计集成测试、实施集成测试、评估集成测试。
测试员
执行集成测试，记录测试结果。
软件项目组：
角色
职责
实施员
负责实施类（包括驱动程序和桩），并对其进行单元测试。
根据集成测试发现的缺陷提出变更申请。
配置管理员
负责对测试工件进行配置管理。
设计员
负责设计测试驱动程序和桩。
根据集成测试发现的缺陷提出变更申请。
集成测试工作内容及其流程工作流程：
2.5集成测试产生的工件清单
1、软件集成测试计划
2、集成测试用例
3、测试过程
4、测试脚本
5、测试日志
6、测试评估摘要
软件系统测试工作指南
编者说明：
这是一个系统测试的工作指南。
你可以根据该文档，结合实际进行修改。
1.简介
1.1目的
本文详细阐述了系统测试的类型以及各个类型的基本测试方法，指导项目开发人员进行软件系统测试。
1.2范围
本文适用于使用RUP的所有软件项目的系统测试工作。
1.3文档结构
第一部分：
简介，介绍软件系统测试指南的目的，本指南的适用范围，以及在本文档中使用的术语的解释。
第二部分：
描述系统测试指南。
包括系统测试流程、系统测试需求的获取、系统测试侧策略选择、系统测试技术和方法等。
第三部分：
列出本指南使用的参考文献。
1.4词汇表
系统测试（SystemTesting）：
系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。
它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统进行的测试。
黑盒测试（Black-BoxTesting）：
黑盒测试是基于系统需求规格，在不知道系统或组件的内部结构的情况下进行的测试。
通常又将黑盒测试叫做：
基于规格的测试（Specification-BasedTesting）、输入输出测试（Input/OutputTesting）、功能测试（FunctionalTesting）。
2.系统测试指南
2.1系统测试过程
活动名称
输入工件
输出工件
参与角色
制定系统测试计划
软件需求工件
软件项目计划
系统测试计划
测试设计员
设计系统测试
系统测试计划
软件需求工件
系统测试用例
系统测试过程
测试设计员
实施系统测试
系统测试计划
工作版本
系统测试脚本
测试设计员
执行系统测试
系统测试计划
系统测试用例
系统测试过程
系统测试脚本
测试结果
测试员
评估系统测试
测试结果
测试分析报告
变更请求
测试设计员
相关组
2.2系统测试需求获取
系统测试需求所确定的是测试的内容，即测试的具体对象。
系统测试需求主要来源于需求工件集，它可能是一个需求规格说明书，或是由前景、用例、用例模型、词汇表、补充规约组成的一个集合。
在分析测试需求时，可应用以下几条一般规则：
1）测试需求必须是可观测、可测评的行为。
如果不能观测或测评的测试需求，就无法对其进行评估，以确定需求是否已经满足。
2）在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。
用例通常具有多个测试需求；有些补充需求将派生一个或多个测试需求，而其他补充需求（如市场需求或包装需求）将不派生任何测试需求。
3）在需求规格说明书中每一个功能描述将派生一个或多个测试需求，性能描述、安全性描述等也将派生出一个或多个测试需求。
1.功能性测试需求
功能性测试需求来自于测试对象的功能性说明。
每个用例至少会派生一个测试需求。
对于每个用例事件流，测试需求的详细列表至少会包括一个测试需求。
对于需求规格说明书中的功能描述，将至少派生一个测试需求。
2.性能测试需求
性能测试需求来自于测试对象的指定性能行为。
性能通常被描述为对响应时间和资源使用率的某种评测。
性能需要在各种条件下进行评测，这些条件包括：
1）不同的工作量和/或系统条件
2）不同的用例/功能
3）不同的配置
4）性能需求在补充规格或需求规格说明书中的性能描述部分中说明。
对包括以下内容的语句要特别注意：
1）时间语句，如响应时间或定时情况
2）指出在规定时间内必须出现的事件数或用例数的语句
3）将某一项性能的行为与另一项性能的行为进行比较的语句
4）将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句
5）一段时间内的操作可靠性（平均故障时间或MTTF）
6）配置或约束
应该为规格中反映以上信息的每个语句生成至少一个测试需求。
3.其它测试需求
其它测试需求包括配置测试、安全性测试、容量测试、强度测试、故障恢复测试、负载测试等测试需求可以从非功能性需求中发现与其对应的描述。
每一个描述信息可以生成至少一个测试需求。
2.3系统测试策略
测试策略用于说明某项特定测试工作的一般方法和目标。
系统测试策略主要针对系统测试需求确定测试类型及如何实施测试的方法和技术。
一个好的测试策略应该包括要实施的测试类型和测试的目标、所采用的技术、用于评估测试结果和测试是否完成的标准、对测试策略所述的测试工作存在影响的特殊事项等内容。
2.3.1系统测试类型和目标
确定系统测试策略首先应清楚地说明所实施系统测试的类型和测试的目标。
清楚地说明这些信息有助于尽量避免混淆和误解（尤其是由于有些类型测试看起来非常类似，如强度测试和容量测试）。
测试目标应该表明执行测试的原因。
系统测试的测试类型一般包括：
功能测试（FunctionalTesting）、性能测试（PerformanceTesting）负载测试（LoadTesting）、强度测试（StressTesting）、容量测试（VolumeTesting）、安全性测试（SecurityTesting）、配置测试（ConfigurationTesting）、故障恢复测试（RecoveryTesting）、安装测试（InstallationTesting）、文档测试（DocumentationTesting）、用户界面测试（GUITesting）等等。
其中，功能测试、配置测试、安装测试等在一般情况下是必需的。
而其它的测试类型则需要根据软件项目的具体要求进行裁剪。
2.3.2采用的测试技术
系统测试主要采用黑盒测试技术设计测试用例来确认软件满足需求规格说明书的要求。
2.4系统测试的工作机制
1）项目组为每一个软件项目成立测试组，确定测试经理（通常由测试设计员担任）一名，测试设计员和测试员若干。
角色
职责
测试设计员
制定系统测试计划、设计系统测试、实施系统测试以及评估系统测试
测试员
执行系统测试
2）项目组需要提供系统测试需要的输入，建立测试环境，以及对测试工件进行配置管理。
角色
职责
系统分析员
生成需求工件集，管理需求。
为测试设计员提供测试需求。
配置管理员
对测试工件进行配置管理
2.5系统测试产生的工件清单
1）软件系统测试计划
2）系统测试用例
3）系统测试过程
4）测试脚本（可选）
5）测试结果
6）测试分析报告
测试分析报告（GB标准）
编者说明：
测试完成后，将会形成一些测试日志，对于每个测试用例也有了一个反馈的结果，那么从这个数据中看出问题、找到问题以及寻找解决问题的方法，那就是测试分析报告所要完成的事了。
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测试资源消耗
[总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。
]
测试规程说明
编者说明：
软件测试就像生产线上的产品测试一样，需要专业的技能与工作方法，而测试规程则是确保每次测试动作高度统一。
第1章目的
1.1一般目的
1.2执行的测试用例
序号
测试用例名称或标识符
第2章特殊要求
2.1前继规程
序号
前继规程的名称或标识符
2.2专门技能
2.3特殊环境
2.4其它
第3章规程步骤
3.1日志
3.2准备
3.3启动
3.4处理
3.5度量
3.6暂停
3.7再启动
3.8停止
3.9清除
3.10应急
计算机软件测试文件编制规范
编者说明：
测试是一个复杂、系统化的工作，也是一个内容广泛的课题，其间将产生大量的文档。
本文档就是一个指导所有这些文档编写的规范。
你可以根据自己的实际，对其修改，以适用于你的开发团队。
1.引言
1.1目的和作用
本规范规定一组软件测试文件。
测试是软件生存周期中一个独立的、关键的阶段，也是保证软件质量的重要手段。
为了提高检测出错误的几率，使测试能有计划地、有条不紊地进行地进行，就必须要编制测试文件。
而标准化的测试文件就如同一种通用的参照体系，可达到便于交流的目的。
文件中所规定的内容可以作为对测试过程完备性的对照检查表，故采用这些文件将会提高测试过程的每个阶段的能见度，极大地提高测试工作的可管理性。
1.2适用对象及范围
本规范是为软件管理人员、软件开发人员和软件维护人员、软件质量保证人员、审计人员、客户及用户制定的。
本规范用于描述一组测试文件，这些测试文件描述测试行为。
本规范定义每一种基本文件的目的、格式和内容。
所描述的文件着重于动态测试过程，但有些文件仍适用其它种类的测试活动。
本规范可应用于数字计算机上运行的软件。
它的应用范围不受软件大小、复杂度或重要性的限制，本规范既适用于初始开发的软件测试文件编制，也适用于其后的软件产品更新版本的测试文件编制。
本规范并不要求采用特定的测试方法学、技术及设备或工具。
对文件控制、配置管理或质量保证既不指明也不强制特定的方法学。
根据所用的方法学，可能需要增加别的文件（如“质量保证计划”）。
本规范既适用于纸张上的文件，也适用于其它媒体上的文件。
如果电子文件编制系统不具有安全的批准注册机制，则批准签字的文件必须使用纸张。
2.引用标准
GB/T11457软件工程术语
GB8566计算机软件开发规范
升级会员 