测试计划示例

*****有限公司POS系统
测试计划

文 档 编 号：001
模 块 名 称：POS系统整体模块

版 本 号：1.00
软件测试小组：流氓兔

修订历史
日期 版本 说明 作者
2016.6.28 1.0 初稿，框架 赵……

目 录
第一章 项目概述 4
1.1项目背景 4
1.2 测试目的 4
1.3对象框架 4
1.4 标准 4
1.5 术语 4
1.6参考文档 5
1.7受众、读者 5
第二章 测试说明 5
2.1 测试对象范围 5
2.2 测试环境 5
2.2.1 硬件设备 5
2.2.2 辅助工具 6
2.3 测试资源 6
2.4 测试策略 7
2.4.1 功能测试 7
2.4.2业务测试 8
2.4.3功能测试检查项： 8
2.5 任务分配 9
2.6 文档管理 9
2.7 用例管理 9
2.8缺陷管理 10
第三章 风险控制 11
3.1系统风险 11
3.2影响计划的潜在因素 11
3.3应急措施 11
3.4测试的局限性 11
第四章 质量评估标准 12
4.1测试模块通过标准 12
4.2验收测试通过标准 12
第五章 关键里程碑 12
第六章 附录及其他 12
6.1 联系方式 12
6.2需求矩阵模板 13
6.3会议记录模板 13
6.4测试用例模版 13
6.5工作日志模板 14
6.6缺陷报告模版 15

第一章 项目概述
1.1项目背景
项目名称：亿达商贸有限公司POS系统
用户：XXXXXXX
《亿达商贸POS系统》可用于商品管理、商品类别、供应商的管理、客户管理、采购信息及销售信息、采购退货和销售退货、库存统计、系统维护等应用模块。
测试版本：V1.0
1.2 测试目的
为了要找出错误，通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。保证整个软件开发过程是高质量的，同时满足用户指定的需求（功能、性能、安全性、兼容性）。
1.3对象框架
亿达商贸POS系统是B/S构架的软件，开发环境是JSP，是基于Spring、Hibernate、MySQL的数据库平台上。
1.4标准
本测试项目中采用了：国家软件测试GB/T2500-2010和GB/T16260的相关标准。
1.5 术语
软件测试：使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
硬件环境：指测试必需的服务器，客户端，网络连接设备，以及打印机扫描仪等辅助硬件设备所构成的环境。
软件环境：指被测软件运行时的操作系统，数据库及其他应用软件构成的环境。软件环境又可分为主测试环境和辅助测试环境。
验收测试：是软件产品交付用户正式使用前的最后一道工序。它是以用户为主的测试，软件开发和质量保证人员也应参加。
1.6参考文档
《POS_需求_20160621_v4.1.doc》
1.7受众、读者
受众、读者：主要针对项目经理，管理人员、测试工程师人员。

第二章 测试说明
2.1 测试对象范围

2.2 测试环境
2.2.1 硬件设备
使用7台同等配置电脑，在不同环境进行（真实机器和虚拟机器）
软件环境（相关软件、操作系统等）虚拟机
Windows Server 2008 SP2
亿达商贸POS系统
硬件环境（网络、设备等）
CPU：Inter Pentium Dual 2.20GHz 内存：1GB 硬盘：40G
网络环境：100MB局域网
软件环境（相关软件、操作系统等）真实机
Microsoft Windows 7 旗舰版
亿达商贸POS系统
CPU：Inter(R) Core(TM) is-2328 2.20GHz 内存：4G 硬盘：320G
网络环境：100MB局域网
2.2.2 辅助工具
测试管理工具：ALM11
版本控制工具：SVN
2.3 测试资源
PM:
TL：
小组人员分配：
角色 所推荐的最少资源 具体职责或注释
测试组长 进行管理监督。
职责：
提供技术指导
生成测试计划，测试方案
参与测试
配置管理员 确保测试环境得到管理和维护。
职责：
管理测试系统
管理VSS
授予和管理角色对测试系统的访问权
参与测试
文档管理员 确保测试文档得到管理和维护。
职责：
管理文档
维护文档
生成工作日志
参与测试
质量监督员 外派他组进行质量监督。
职责：
质量监督
参与测试
需求分析员 对文档需求调研及需求反馈的分析。
职责：
分析需求
参与测试
记录员 记录会议内容及各种组内信息。
职责：
记录会议内容
生成会议记录文档
参与测试
测试员 执行测试。
职责：
执行测试
记录结果
从错误中恢复（返测报告）
收集测试用例
生成缺陷报告

2.4 测试策略
2.4.1 功能测试
功能测试是从用户的观点出发，主要以亿达商贸POS系统软件需求说明书和操作使用手册为依据，对程序功能和程序接口进行的测试。

测试目标 系统提供的功能与需求或用户手册相符。
测试范围： 首页
商品管理
商品类别
供应商的管理功能
客户管理
采购信息及销售信息
采购退货和销售退货
库存统计
系统维护
方法： · 集成测试阶段主要针对所有主要的功能实现进行测试，系统测试阶段依据需求规格说明书逐项测试，验收测试阶段依据说明书逐项测试。
· 重要的功能应该投入更多的精力进行测试，并及时小结。
完成标准： · 功能实现，且可以正确执行。
· 所发现的缺陷尽量解决，留下的问题已经进行相应的处理或提供其他的解决方法。
需考虑的特殊事项： · 注意开发组可能的功能变化和需求变更。
· 注意其中一些重要功能是与实际效果相关，并不是简单的功能实现。
· 注意值域测试的提示信息。

2.4.2业务测试
业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到另一个模块的过程中的正确性。

2.4.3功能测试检查项：
1.表单测试：必填项，提示信息，边界值，数据类型，字符长度，特殊字符
2.链接测试：风格，链接正确，导航条，图片链接
3.图形测试：图片大小，位置，相关说明，字体，大小，颜色，背景前景
4.表格：样式
5.内容测试：信息归类是否正确，显示位置，检索功能
6.浏览器测试：功能，风格显示等

2.4.4 常见错误类型：
页面链接和风格、相关性检查、按钮功能、字串长度、字串类型、重复提交、回退、上传下载、必填项、快捷键、刷新、信息重复、功能错误、功能遗漏、界面错误、外部数据库错误。
2.5 任务分配
时间安排 主要任务 成果
第一天 长进行模块分解，进行工作量评估；测试人员撰写需求说明书 任务分配评估表、需求说明书初稿
第二天 需求说明书评审、修订，安装调试SVN及思维导图，组长分配任务，撰写POS系统思维导图初稿并组内评审 需求说明书修订版、SVN和Xmind安装调试成功、POS系统思维导图初稿
第三天 POS系统思维导图评审、修订，组长分配任务，测试人员撰写需求细化文档，并组内评审 思维导图修订版，需求细化初稿
第四天 新需求的评审、修订，安装调试Office和Visio，组长分配任务，测试人员撰写模块拆分图和需求跟踪矩阵 新需求修订版、office和Visio安装调试成功、模块拆分图初稿、需求分析矩阵初稿
第五天 模块拆分图初稿和需求跟踪矩阵初稿的评审、修订 模块拆分图修订版、需求跟踪矩阵修订版
第六天 测试计划制定； 需求分析矩阵、测试计划、产品环境搭建完成
第七天 测试计划评审、修订； 测试用例初稿
第八天 测试用例评审、修订 用例评审结论、测试用例
第九天 执行测试用例 用例测试结果、缺陷报告
第十天 执行测试用例，项目测试总结 用例测试结果、缺陷报告、项目测试总结报告

2.6 文档管理
对各种文档进行管理，以及给不同角色的人（项目经理、开发人员、测试人员）设置不同的权限；以下文档模板：需求矩阵、会议记录、工作日志参考附件。
2.7 用例管理
测试用例是为实施一次测试而向被测系统提供输入数据、操作或各种环境设置；它来源于测试需求。是对测试需求的一个细化，它是整个测试的基础。
测试用例的优先级别
1.小版本确认测试（BVTs）：一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。
2.高：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
3.中：这是使给出的功能区域或功能变得更详细，检查功能的多数方面。
4.低：通常最少被执行的测试用例，们在项目的生命期间里不是常常被运行。
测试用例的元素：5W1H
1.测试目标：Why—为什么而测试？功能 、可用性、安全性等。
2.测试对象：What—测试什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等；
3.测试环境：Where—在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议 等单机或网络环境。
4.测试前提：When—什么时候可以测？测试用例运行时所处的前提或条件限制。
5.输入数据：Which—那些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。
6.操作步骤：How——如何测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等
测试用例模板参考附录
2.8缺陷管理
缺陷报告用于记录缺陷，对缺陷进行分类，为解决不同的缺陷分配合理的资源，并通过缺陷报告对处理缺陷的过程进行跟踪，从而使软件缺陷得以修复。

缺陷报告包括的元素：缺陷标题、复现缺陷的操作步骤、缺陷的实际结果、缺陷的预期结果、缺陷的优先级别、缺陷的严重程度、缺陷的基本信息、缺陷的类型、测试的软件和硬件环境、测试的软件版本、注释文字和截的缺陷图像。

缺陷严重程度
（1）致命性错误：数据丢失、数据传递错误，造成操作系统或其他支撑系统崩溃、应用系统崩溃，非正常关闭和非正常死机。
（2）严重性错误：规定的主要功能没有实现或不完整、影响系统的运行；设计不合理造成性能低下。
（3）一般性错误：不影响业务运行的功能问题。
修改优先级：
P1：立刻修复；
P2：如果时间允许就修复；
P3：可以在将来的某个版本修复；
P4：推迟修复；
P5：不进行修复。

缺陷报告模板参考附录
第三章 风险控制
3.1系统风险
市场压力比较大。
需求或设计的变更未及时通知。
需求不明确可能导致开发的产品与目标不一致。
3.2影响计划的潜在因素
在测试计划执行过程中，可能存在以下因素影响计划的按时完成：
时间紧迫，任务繁重；
测试人员对的熟悉进度慢；
测试人员对被测试产品不够熟悉，对测试工具的使用熟悉程序不够；
被测试产品存在重大错误，以致于测试无法继续；
测试资源未及时到位（设备和人员）；
硬件、软件或网络环境出现故障等；
测试人员获取的需求与开发人员产生分歧；
测试人员与开发人员的协调与沟通。
3.3应急措施
如果上述潜在的可能事件发生，则通过适当加班来保证计划的按时完成。如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。
3.4测试的局限性
系统硬件配置存在不可预测的问题；
测试范围不能覆盖所有的可能情况；
测试时间的限制；
测试数据可能不全面；
测试工具自身的缺陷；
测试人员的失误。
第四章 质量评估标准
4.1测试模块通过标准
测试项的通过标准目前定义为：当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系统的错误，则认为此项测试通过。
4.2验收测试通过标准
验收测试的通过标准目前定义为：对于每一类测试，当没有发现致命性错误和严重性错误，一般性错误数量小于测试用例总数的5%，则认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准。
第五章 关键里程碑
里程碑任务 日期 输出结果
需求分析培训 20160621 需求矩阵
需求分析 20160628 需求分析报告
完成测试计划 20160629 测试计划
编写测试用例 测试用例
测试用例评审 功能测试
执行用例、缺陷报告 缺陷报告
项目测试总结 测试总结

第六章 附录及其他
6.1 联系方式
姓名 责任 联系电话 电子邮件
测试组长
测试组长
文档管理员
质量管理员
配置管理员
测试工程师
需求分析员

6.2需求矩阵模板
序号 需求文档来源 章节来源 原始需求 测试要点 注释

6.3会议记录模板
测试组编号 例会时间 早会
主持人
会议记录人
参加人员
例会议题 1、
2、
3、
……

议题讨论结果：
1.
2.
3.
……

6.4测试用例模版
测试用例
项目名称 　 程序版本 　
模块名称 　
设计人员 　 编制时间 　
功能特性 　
测试目的 　
预置条件 　
参考信息 　 特殊规程说明 　
用例编号 相关用例 模块 功能点 操作步骤 输入数据 预期结果 测试结果（通过/不通过） 缺陷编号 备注
　
　 　 　 　 　 　 　 　 　
　
　 　 　 　 　 　 　 　 　

6.5工作日志模板
姓名 测试组编号 日期
当日工作任务：

完成情况（%）100
未完成任务的原因：

工作成果：

遇到的问题：

备注：

6.6缺陷报告模版
缺 陷 报 告
项目名称 项目编号
测试人员 测试日期
缺陷状态 缺陷类型 ( )功能级别 ( )非功能级别
优先级 ( )P1 ( )P2 ( )P3 ( )P4 （ ）P5
严重程度 ( )一般 ( )严重 ( )致命
概要
详细描述 运行环境 软件环境：
硬件环境：
操作步骤 重现率： ( )%
预期结果
实际结果
附件
备注：