测试计划模板

项目编号：

 

 

iwebshop系统

测试计划

 

文档编号：001

模块名称：iwebshop系统整理模块

 

版本号：1.00

软件测试小组：XXXXXXXXX

 

 

 

 

修订历史

日期	版本	说明	作者
2017.11.24	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项目背景

项目名称：传智播客iwebshop系统

用户：XXXXXXX

《传智播客iwebshop系统》可用于订单管理、会员管理、商品管理、营销管理、统计信息、系统内信息管理等应用模块。

测试版本：V1.0

1.2测试目的

为了要找出错误，通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。保证整个软件开发过程是高质量的，同时满足用户指定的需求（功能、性能、安全性、兼容性）。

1.3对象框架

iwebshop系统是B/S构架的软件，开发环境，是基于Linux操作系统、nginx服务器、mysql数据库平台上，采用PHP语言编写。

1.4标准

本测试项目中采用了：国家软件测试GB/T2500-2010和GB/T16260的相关标准。

1.5术语

软件测试：使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

硬件环境：指测试必需的服务器，客户端，网络连接设备，以及打印机扫描仪等辅助硬件设备所构成的环境。

软件环境：指被测软件运行时的操作系统，数据库及其他应用软件构成的环境。软件环境又可分为主测试环境和辅助测试环境。

验收测试：是软件产品交付用户正式使用前的最后一道工序。它是以用户为主的测试，软件开发和质量保证人员也应参加。

1.6参考文档

《iwebshop_需求_20171124_v1.0.doc》

软件界面

数据库设计文档

1.7受众、读者

受众、读者：主要针对项目经理，管理人员、测试工程师人员。

 

第二章 测试说明

2.1 测试对象范围

iwebshop系统前台、后台、数据库

2.2 测试环境

2.2.1  硬件设备

       使用2台不同配置电脑，在不同环境进行（真实机器和虚拟机器）

软件环境（相关软件、操作系统等）虚拟机

Centos

传智播客iwebshop系统

硬件环境（网络、设备等）

CPU：Inter Pentium Dual 2.20GHz     内存：1GB    硬盘：40G

网络环境：100MB局域网

软件环境（相关软件、操作系统等）真实机

Microsoft Windows 7旗舰版

传智播客iwebshop系统

CPU：Inter(R) Core(TM) is-2328  2.20GHz      内存：4G      硬盘：320G

网络环境：100MB局域网

2.2.2  辅助工具

测试管理工具：禅道

版本控制工具：SVN

2.3 测试资源

 

小组人员分配：

角色	所推荐的最少资源	具体职责或注释
测试组长		进行管理监督。 职责： 提供技术指导 生成测试计划，测试方案 参与测试
配置管理员		确保测试环境得到管理和维护。 职责： 管理测试系统 管理SVN 授予和管理角色对测试系统的访问权 参与测试
文档管理员		确保测试文档得到管理和维护。 职责： 管理文档 维护文档 生成工作日志 参与测试
质量监督员		外派他组进行质量监督。 职责： 质量监督 参与测试
需求分析员		对文档需求调研及需求反馈的分析。 职责： 分析需求 参与测试
记录员		记录会议内容及各种组内信息。 职责： 记录会议内容 生成会议记录文档 参与测试
测试员		执行测试。 职责： 执行测试 记录结果 从错误中恢复（返测报告） 收集测试用例 生成缺陷报告

 

2.4 测试策略

2.4.1 功能测试

功能测试是从用户的观点出发，主要以iwebshop系统软件需求说明书和操作使用手册为依据，对程序功能进行的测试。

 

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

 

2.4.2业务测试

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

 

2.4.3功能测试检查项：

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

 

2.4.4 常见错误类型：

     页面链接和风格、相关性检查、按钮功能、字串长度、字串类型、重复提交、回退、上传下载、必填项、快捷键、刷新、信息重复、功能错误、功能遗漏、界面错误、外部数据库错误。

2.5 任务分配

时间安排	主要任务	成果
第一天	测试环境搭建、熟悉iwebshop系统、制定测试计划、制定测试方案	项目调研 软件组织架构图 测试范围列表 测试计划说明书 测试方案说明书
第二天	初始化界面测试分析以及编写测试用例 系统功能分析以及编写测试用例	测试用例
第三天	系统功能分析以及编写测试用例	测试用例
第四天	系统业务流程分析以及用例编写	广度优先图 深度优先图 业务场景测试用例
第五天	系统非功能分析以及接口、性能分析 测试总结	Html页面了解 http协议了解 httpwatch工具使用 fiddler工具使用 测试报告编写

 

2.6 文档管理

对各种文档进行管理，以及给不同角色的人（项目经理、开发人员、测试人员）设置不同的权限；以下文档模板：需求矩阵、会议记录、工作日志参考附件。

2.7 用例管理

测试用例是为实施一次测试而向被测系统提供输入数据、操作或各种环境设置；它来源于测试需求。是对测试需求的一个细化，它是整个测试的基础。

测试用例的优先级别

1.小版本确认测试：一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。

     2.高：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。

     3.中：这是使给出的功能区域或功能变得更详细，检查功能的多数方面。

4.低：通常最少被执行的测试用例，我们在项目的生命期间里不是常常被运行。

测试用例的元素：5W1H

1.测试目标：Why—为什么而测试？功能 、可用性、安全性等。

2.测试对象：What—测试什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等；

3.测试环境：Where—在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议 等单机或网络环境。

4.测试前提：When—什么时候可以测？测试用例运行时所处的前提或条件限制。

     5.输入数据：Which—那些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。

6.操作步骤：How——如何测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等

测试用例模板参考附录1

2.8缺陷管理

缺陷报告用于记录缺陷，对缺陷进行分类，为解决不同的缺陷分配合理的资源，并通过缺陷报告对处理缺陷的过程进行跟踪，从而使软件缺陷得以修复。

 

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

 

缺陷严重程度

（1）致命性错误：数据丢失、数据传递错误，造成操作系统或其他支撑系统崩溃、应用系统崩溃，非正常关闭和非正常死机。

（2）严重性错误：规定的主要功能没有实现或不完整、影响系统的运行；设计不合理造成性能低下。

（3）一般性错误：不影响业务运行的功能问题。

修改优先级：

P1：立刻修复；

P2：如果时间允许就修复；

P3：可以在将来的某个版本修复；

P4：推迟修复；

P5：不进行修复。

 

缺陷报告模板参考附录2

第三章 风险控制

3.1系统风险

市场压力比较大。

需求或设计的变更未及时通知。

需求不明确可能导致开发的产品与目标不一致。

3.2影响计划的潜在因素

在测试计划执行过程中，可能存在以下因素影响计划的按时完成：

时间紧迫，任务繁重；

测试人员对的熟悉进度慢；

测试人员对被测试产品不够熟悉，对测试工具的使用熟悉程序不够；

被测试产品存在重大错误，以致于测试无法继续；

测试资源未及时到位（设备和人员）；

硬件、软件或网络环境出现故障等；

测试人员获取的需求与开发人员产生分歧；

测试人员与开发人员的协调与沟通。

3.3应急措施

如果上述潜在的可能事件发生，则通过适当加班来保证计划的按时完成。如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。

3.4测试的局限性

系统硬件配置存在不可预测的问题；

测试范围不能覆盖所有的可能情况；

测试时间的限制；

测试数据可能不全面；

测试工具自身的缺陷；

测试人员的失误。

第四章质量评估标准

4.1测试模块通过标准

测试项的通过标准目前定义为：当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系统的错误，则认为此项测试通过。

4.2验收测试通过标准

验收测试的通过标准目前定义为：对于每一类测试，当没有发现致命性错误和严重性错误，一般性错误数量小于测试用例总数的5%，则认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准。

第五章关键里程碑

里程碑任务	日期	输出结果
需求分析培训	20170621	需求矩阵
需求分析	20170628	需求分析报告
完成测试计划	20171124	测试计划
编写测试用例		测试用例
测试用例评审		功能测试
执行用例、缺陷报告		缺陷报告
项目测试总结		测试总结

 

第六章 附录及其他

6.1  联系方式

姓名	责任	联系电话	电子邮件
	测试组长
	测试组长
	文档管理员
	质量管理员
	配置管理员
	测试工程师
	需求分析员

 

6.2需求矩阵模板

序号	需求文档来源	章节来源	原始需求	测试要点	注释

 

6.3会议记录模板

测试组编号		例会时间	早会
主持人
会议记录人
参加人员
例会议题	1、 2、 3、 ……
议题讨论结果： 1. 2. 3. ……

 

6.4测试用例模版

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

 

6.5工作日志模板

姓名		测试组编号		日期
当日工作任务：
完成情况（%）100
未完成任务的原因：
工作成果：
遇到的问题：
备注：

 

6.6缺陷报告模版

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