软件质量保证测试计划 编者说明: 要想系统性地完成一件事,首先要做好计划,测试工作是十分重要的,因此测试计划也是十分必要的。该文档适用于集成测试、系统测试、验收测试的计划制订,并不适用于单元测试计划。 第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 参考文件 Software Test Process Rational Unified Process 1.4 定义与缩写 RUP:统一开发过程 SIT:软件集成测试 SEPG:软件工程过程小组 SQA:软件质量保证 2. 集成测试指南 2.1 简介 集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。 2.2 单元测试工作内容及其流程
2.3 集成测试需求获取 集成测试着重于集成版本的外部接口的行为。因此,测试需求须具有可观测、可测评性。 1.集成工作版本应分析其类协作与消息序列,从而找出该工作版本的外部接口。 2.由集成工作版本的外部接口确定集成测试用例。 3.测试用例应覆盖工作版本每一外部接口的所有消息流序列。 注意:一个外部接口和测试用例的关系是多对多,部分集成工作版本的测试需求可映射到系统测试需求,因此对这些集成测试用例可采用重用系统测试用例技术。 2.4 集成测试工作机制 软件集成测试工作由产品评测部担任。需要项目组相关角色配合完成。如图示: 软件评测部:
软件项目组:
集成测试工作内容及其流程工作流程:
2.5 集成测试产生的工件清单 1、软件集成测试计划 2、集成测试用例 3、测试过程 4、测试脚本 5、测试日志 6、测试评估摘要
软件系统测试工作指南 编者说明: 这是一个系统测试的工作指南。你可以根据该文档,结合实际进行修改。 1. 简介 1.1 目的 1.2 范围 1.3 文档结构 第二部分:描述系统测试指南。包括系统测试流程、系统测试需求的获取、系统测试侧策略选择、系统测试技术和方法等。 第三部分:列出本指南使用的参考文献。 1.4 词汇表 系统测试(System Testing):系统测试是通过与系统的需求规格作比较,发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来,在实际运行(使用)环境下,对计算机系统进行的测试。 黑盒测试(Black-Box Testing):黑盒测试是基于系统需求规格,在不知道系统或组件的内部结构的情况下进行的测试。通常又将黑盒测试叫做:基于规格的测试(Specification-Based Testing )、输入输出测试(Input/Output Testing )、功能测试(Functional Testing )。 2. 系统测试指南 2.1 系统测试过程
|
方案:软件质量保证
•
软件开发