软件测试计划

::: {.center}
xx公司

2020-01-01
:::

文档管理

合理地管理主文档,确保文档版本的及时更新,同时保持备份文档和源文档的一致性。

版本管理


本版本修订日期 2019-08-12 生效日期 2019-08-12


版本 生效日期 变更内容 编制人


V1.0 2020-01-01 初稿编写完成 xx

范围

标识

本条应包含本文档及本文档适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本号和发行号。

系统概述

本条应简述本文档适用的系统和软件的用途,它应描述系统和软件的一般特性;概述系统开发、运行和维护的历史;标识项目的开发方、业主方、总集方、监理方等;标识当前和计划的运行现场等。

文档概述

本条应概述本文档的用途和内容,并描述与其使用有关的保密性和私密性的要求。

引用文档

应列出本文档引用的所有文档的编号、标题、修订版本、日期和来源。

术语和定义

提供此文档中用到的专门术语的定义和缩写词的原词组。

测试目标和测试内容

测试目标

描述本测试计划的测试目标。如完成软件的出厂测试,达到可交付验证测试的目的。

测试的功能和特性

概要说明本次需要测试的功能和特性

不测的功能和特性

说明本次不测的功能、特性及原因

测试质量目标

简要说明测试的质量目标,如:

测试计划中所有测试方法和模块已经执行通过

所有的测试案例已经执行过

所有的重要等级Bug已经解决并由测试验证

应交付的测试成果文档

说明最终需要交付的测试成果文档,包括软件测试计划、软件测试说明(含测试用例、软件测试报告、测试问题报告等。文档名和数量因具体项目而异,应确定文档责任人。

测试策略

整体测试策略

说明基本的测试过程和策略。如测试人员在需求和设计阶段参与需求评审和设计评审、在开发完成前实施测试案例设计和测试开发,在系统开发完成之后正式执行测试等。

问题等级划分

划分软件缺陷的等级分类代码。推荐的等级划分如下:

A 严重缺陷

文档与软件不符、文档严重不足、关键性内容错误。软件需求明显未实现。软件不能正常运行,导致系统崩溃或资源严重不足。例如: 由程序引起的死机、非法退出;死循环;导致数据库发生死锁;错误操作导致的程序中断;与数据库连接错误;数据通讯错误等

B 较严重缺陷中现

软件能够运行,但当前缺陷严重影响软件基本功能的正确实现。例如:软件功能与需求不符;程序接口错误;数据流错误;数值计算错误等。

C 一般性缺陷

软件能够运行,但当前缺陷影响部分功能的正确实现。例如:界面错误;打印内容或格式错误;简单的输入限制未放在前台进行控制;删除操作未给出提示;数据输入没有边界值限定或不合理等。

D 较小缺陷

软件能够运行,软件功能基本实现,但当前缺陷使操作者不方便或遇到麻烦。例如:辅助说明描述不清楚;显示格式不规范;系统处理未优化;长时间操作未给用户进度提示;提示窗口文字未采用行业术语等。

开始/中断/完成标准

测试启动条件

说明启动测试的条件。如对于出厂测试,已经过评审、测试人力资源已经具备、软件需求规格说明/详细设计文档/测试说明文档已经过确认、内部模块测试和组装测试已经完成等。

其中业主方、总集方、监理方交付验证测试的准入条件:

软件源代码正确通过编译且为最终版本;

软硬件测试平台已搭建并已配置完成;

业主方具有测试所需的各种文档(纸质、电子版);

业主方获得的各种文档均与最终版本的软件相对应,且全部通过审核;

承建方、监理方已完成测试并提交测试报告。

测试中断条件

说明测试中断的条件。例如:

在测试中发现A类bug,并导致后续的测试无法继续时;

已执行完所有的测试用例,并已报告给承建方,等待承建方在限期内改正时。

测试终止条件

说明在什么条件下终止本计划所述产品交付验收证测试。如:

正常终止条件:

按照测试计划完成所有定义的测试用例;

客观、详细地记录了软件测试过程和软件测试中发现的问题;

有效完成了定位缺陷的回归测试循环;

测试中未发现A、B缺陷,以及少于n个C类缺陷;

提交测试报告。

异常终止条件

太多的A或B类缺陷以致测试无法进行或测试周期已结束。

或者针对软件规模,规定C类bug不超过n个

测试工具选择

说明需要用到的测试工具软件,应包括软件版本号。

测试流程

阐述或引用测试流程,应包括问题报告、审核、分配、跟踪、回归等各方面。测试流程与承建方内部质量管理制度和业主方的要求相关。

测试技术和方法

确定测试需要的技术或方法,如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术等;明确测试用例的设计和选择方法,针对不同类型的测试(功能测试、性能测试、容量测试、用户界面测试,

根据需要,应给出针对性的测试用例设计要求。

评价准则和方法

测试通过准则

定义系统测试通过准则,以下是一个测试通过准则的示例:

可执行软件与需求规格说明书、设计说明书是一致的;

测试覆盖率应达到100%

测试用例通过率要达到95%;

软件缺陷终结率达到100%

系统页面风格符合规范化要求,程序代码编写以及各种命名符合规范化要求。

各模块正确衔接。

对异常数据应有相应的提示信息,并能安全终止异常操作。

对测试结果处理方法

测试结果分为通过和未通过。测试达到通过准则的要求称为”通过”,测试结果没有达到测试通过准则的称为”未通过”。说明对不同测试结果的处理方法。

测试项目组织与资源

参与部门和组织

说明参与测试的组织/部门

角色和职责

说明参与测试的组织/部门中各角色划分及职责。

人员和培训要求

说明参与测试的组织/部门的员及角色对应关系。以及是否需要预先进行相关培训。

关键资源

说明需要用到的关键资源

测试活动和进度计划应根据测试资源和测试项目内容,分解测试活动,分配测试资源,编制测试进度计划。以下是一个进度计划的示例:

测试阶段 开始时间 完成时间 测试人员 阶段完成标志


制定测试计划
需求 Review
设计 Review
设计测试用例
测试开发
测试环境准备
测试实施
功能测试
集成测试
性能测试
系统测试
验收测试
文档编写

风险分析及应对措施

风险分析是评测项目管理的重要内容。常见的风险包括供测试的软件版本混乱、软件缺陷修改时间过长、回归不足引发新的问题、测试方和开发方对缺陷的认识存在差异等。建议以列表的方式给出识别的风险并提供针对性的缓解措施。

内容审核要点:

测试内容是否完整,是否涵盖了测试目的、内容、方法策略、资源、进度安排等各方面;

测试进度安排是否合理;

测试资源要求是否充分;

测试技术和方法的选择是否可行;

是否包含了对测试结果评价分析标准;

是否包含了对测试过程的跟踪和控制规程。

参考

https://www.jianshu.com/p/a7984927cfb9