title: 软件测试计划
date: 2021-01-24
tags: [软件测试, 计划]
categories: [软件开发]
::: {.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
设计测试用例
测试开发
测试环境准备
测试实施
功能测试
集成测试
性能测试
系统测试
验收测试
文档编写
风险分析及应对措施
风险分析是评测项目管理的重要内容。常见的风险包括供测试的软件版本混乱、软件缺陷修改时间过长、回归不足引发新的问题、测试方和开发方对缺陷的认识存在差异等。建议以列表的方式给出识别的风险并提供针对性的缓解措施。
内容审核要点：
- 测试内容是否完整，是否涵盖了测试目的、内容、方法策略、资源、进度安排等各方面；
- 测试进度安排是否合理；
- 测试资源要求是否充分；
- 测试技术和方法的选择是否可行；
- 是否包含了对测试结果评价分析标准；
- 是否包含了对测试过程的跟踪和控制规程。
网友评论