秦皇岛移动客服信息管理平台系统测试计划书.docx
- 文档编号:11849397
- 上传时间:2023-04-06
- 格式:DOCX
- 页数:14
- 大小:21.30KB
秦皇岛移动客服信息管理平台系统测试计划书.docx
《秦皇岛移动客服信息管理平台系统测试计划书.docx》由会员分享,可在线阅读,更多相关《秦皇岛移动客服信息管理平台系统测试计划书.docx(14页珍藏版)》请在冰豆网上搜索。
秦皇岛移动客服信息管理平台系统测试计划书
秦皇岛移动客服信息管理平台系统
软件测试计划
1前言III
1.1编写目的III
1.2名词解释III
1.3参考资料III
1.4测试摘要5
2资源需求6
2.1硬件、软件资源资源6
2.2人力资源6
3测试详述6
3.1测试范围6
3.2测试目标7
3.3风险和约束7
3.4测试进度7
4测试策略8
4.1整体策略8
4.2测试类型8
4.3测试技术9
5测试覆盖率要求10
6测试提交文档10
7质量目标12
前言
编写目的
测试计划是在软件测试中最重要的步骤之一,它在软件开发的前期对软件测试做出清晰,完整的计划,不光对整个测试起到关键性的作用,而且对开发人员的开发工作,整个项目的规划,项目经理的审查都有辅助性作用。
编写测试计划用来定义测试的范围、测试的方法、所需的资源、进度等,明确需要测试的产品项,需要覆盖的功能特性,需要执行的测试任务,每项任务的负责人,识别相关的风险。
测试计划编写好后,领导可以根据测试计划做宏观调控,进行相应的资源配置,测试人员能够了解整个项目测试情况以及项目测试不同阶段所要进行的工作,便于其他人员了解测试人员的工作内容,进行有关配合工作,尤其是系统开发人员,要根据测试计划来安排自己的工作,以便测试人员找到Bug后,开发人员可以及时去掉Bug,很好的安排自己的工作。
测试计划可以有效地预防计划的风险,保证计划的顺利进行。
通过对移动客服信息管理平台进行全面深入的系统测试和功能测试,我们要使这套系统使用起来更加方便,系统更加稳定,功能更加丰富,性能更加良好,整体地提高这套软件系统的质量、性能和安全性。
该文档使用人员包括:
秦皇岛移动公司负责客服信息管理平台项目的相关人员;
燕山大学软件中心参与秦移动公司本项目的相关测试人员。
名词解释
本方案中包含如下术语和缩写:
秦移动:
秦皇岛移动公司;
燕大软件:
燕山大学计算机软件中心;
参考资料
参考资料及内容:
移动客服信息管理平台系统程序清单;
移动客服信息管理平台系统测试方案;
移动客服信息管理平台系统测试项目清单;
移动客服信息管理平台系统测试计划;
遵循标准:
燕软文档编写规范;
燕软测试管理过程规范。
测试摘要
A.测试事项
1、公共:
这一功能类型是每个程序模块都要测试的,包括如下几项:
(1)信息处理:
主要是与界面提示信息有关的,如提示信息
(2)UI动态处理:
主要是界面动态变化时出现的错误,如窗口不能自适应
(3)常规:
主要是界面通常的控件是否符合开发标准,如字体大小
(4)DATA排列:
数据的对齐方式
(5)遗漏:
检查遗漏的错别字等
(6)其他:
一些其他明显的错误
(7)检查输入形式:
与输入数据有关的错误,如是否校验
(8)检查必录项:
与必录项检查相关的内容
(9)检查KEY值:
与保存是否主键冲突有关的内容
(10)Data保护:
保护数据不被任意修改
(11)检查输入大小:
与数值是否越界等有关的内容
(12)LINK处理:
菜单是否与程序连接正确
(13)保密:
与系统安全有关的内容
(14)事件处理:
控件的操作事件是否能够正确执行
(15)初始化:
界面参数初始化相关的内容
2、查询、增加、删除、修改、保存、弹出窗、打印/导出等,只有当程序有相应功能才需进行测试,没有的忽略这个功能类型。
3、其他:
上述两项中没有包括的测试项目
B.时间进度:
测试活动
计划开始时间
计划结束时间
实际开始时间
实际结束时间
制定测试计划
测试方案设计
单元测试
集成测试
系统测试
性能测试
安装测试
用户验收测试
产品发布
C.测试目标
通过测试,达到以下目标:
1.测试已实现的产品是否达到设计的要求,包括:
各个功能点是否以实现,业务流程是否正确。
2.产品规定的操作和运行稳定。
3.Bug数和缺陷率控制在可接收的范围之内。
资源需求
硬件、软件资源资源
测试人员
操作系统
CPU
内存
浏览器
其它
程平
WindowsXP
P87002.53GHz
2GB
IE7
王朋
WindowsXP
P87002.53GHz
2GB
IE7
蔺静
WindowsXP
P87002.53GHz
2GB
IE6
崔晓军
WindowsXP
P87002.53GHz
2GB
IE6
孔德瀚
WindowsXP
P87002.53GHz
2GB
IE6
2.2人力资源
测试审核人一名,测试实施人员5名。
测试详述
测试范围
本次测试的范围是信息管理平台系统的系统测试和功能测试。
需要测试的模块共有11个模块,99个应用程序。
11个模块包括系统管理、数据处理、报表系统、客服投诉督办任务、综合查询、日月报管理、其他附件管理、附件接收设置、投诉预警管理、营业厅排号机管理、升级投诉管理。
测试目标
通过对移动客服信息管理平台进行全面深入的系统测试和功能测试,我们要使这套系统使用起来更加方便,系统更加稳定,功能更加丰富,性能更加良好,整体地提高这套软件系统的质量、性能和安全性。
风险和约束
本次测试过程中,可能出现的风险如下:
Øbug的修复情况
Ø模块功能的实现情况
Ø系统整体功能的实现情况
Ø代码的编写质量
Ø人员经验以及对软件的熟悉度
Ø开发人员、测试人员关于项目约定的执行情况
Ø人员调整导致研发周期延迟
Ø开发时间的缩短导致某些测试计划无法执行
测试进度
测试阶段
开始时间
结束时间
资源
是否里程碑
系统测试计划
测试用例编写
测试用例评审
单元测试
用户手册编写
集成测试
系统测试
系统测试报告编写
测试策略
整体策略
第一步:
根据测试计划中的计划日期和测试人员,确认待测程序。
第二步:
把测试报告模板按测试报告命名规范另存为该程序的测试报告
第三步:
填写测试报告的开发者、程序标识、测试人员、测试日期、设计要点、测试要点、前提条件.
第四步:
根据移动客服信息管理平台需求报告的基本流程以及备选事件流程确认该应用界面需要进行测试的步骤,并将其填写到测试报告的测试用例中。
第五步:
根据程序界面编写测试用例,并在测试报告中记录测试用例,测试用例的编写请参照测试用例编写说明严格进行。
第六步:
输入测试用例,执行用例进行系统测试并填写测试报告的测试项目的测试结果。
第七步:
比较实际结果与预期结果,填写功能测试结果。
第八步:
根据各测试分项的测试结果,确认该应用界面综合测试结果。
测试类型
编号
测试类型
说明
是否采用
1
功能测试
根据需求文档、设计文档等检查产品是否正确实现了功能。
2
流程测试
按操作流程进行的测试,主要有业务流程、数据流程、逻辑流程、正反流程,检查软件在按流程操作时是否能够正确处理
3
界面测试
检查界面是否符合公司界面规范,是否美观合理
4
易用性测试
检查系统是否易用友好,是否符合通用的操作习惯
5
接口测试
检查系统能否与外部系统或外部设备等是否接口正常
6
安装测试
检查系统能否正确安装、配置基础数据是否正确
7
性能测试
提取系统性能数据,检查系统是否满足在需求中所规定达到的性能。
8
安全性测试
检查系统安全,是否达到安全需求,是否存安全隐患
9
兼容性测试
对于C/S架构的系统来说,需要考虑客户端支持的系统平台。
对于B/S架构的系统来说需要考虑用户端浏览器的版本。
4.3测试技术
编号
测试技术
说明
是否采用
1
测试用例设计
在产品需求评审通过后编写测试用例
2
白盒测试
单元测试是否开展代码测试
3
自动化测试
系统回归时是否要引入自动化测试
4
性能测试
是否是使用工具进行性能方面的测试
5
黑盒测试
指的是把被测软件看作一个盒子,我们不去关心盒子里面是什么样子,只关心软件的输入数据和输出结果。
6
静态测试
静态测试的对象包括文档、代码、界面等,主要是根据用户的要求、及相关标准规范进行分析与检查。
常用的手段是人工检测,依靠人工审查或评审软件,偏重于编码风格、质量的检验,除了审查编码还要对各阶段的软件文档进行检验,计算机辅助静态分析,是很有效的静态测试。
7
动态测试
通过观察代码运行时的动作,来获取执行结果,并得到时间效率、系统可靠性等方面的信息,动态测试通过真正运行程序发现错误,通过有效的测试用例,对应的输入/输出关系来分析被测程序的运行情况。
8
回归测试
重复测试先前测试过的或修改过的程序,确认发生的更改是否给软件其他未改变的部分带来新的缺陷。
9
手工测试
手工测试即测试人员在不借助工具的情况下,“亲力亲为”地进行测试。
10
随机测试
指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误。
随机测试又叫猴子测试。
5测试覆盖率要求
A.对源代码的测试覆盖率要求:
对软件关键模块的语句覆盖率要达到100%,分支覆盖要达到90%以上。
B.对需求的测试覆盖率要求:
软件测试的需求有三个层次,即任务需求、用户需求、功能需求,测试需求分析和测试用例设计参照的是软件需求规格说明书。
测试用例的执行率要在100%
6测试提交文档
(一)测试项目列表部分:
1.开发者:
被测程序的开发人员,可以从程序清单中获取;
2.程序标识:
分为两部分,分别为程序ID和程序名称,均可以从程序清单中获取;
3.设计要点:
该程序设计时的要点信息,可以从程序清单中获取;
4.测试要点:
在对该程序测试时的测试要点信息,可以从程序清单中获取;
5.前提条件:
在进行被测程序前,需要具备的前提条件;
6.测试人员:
进行该程序测试的测试人员,如果进行第一轮测试,请在[测试人员1]中填写测试人员的姓名,如果进行第二轮测试,请在[测试人员2]中填写......;
7.测试日期:
进行该程序测试的测试日期,填写方式与测试人员一致;
8.测试结果:
综合测试结果,测试结果1等测试结果的填写说明见详见下表:
结果标识
结果说明
Y
通过(没有错误)
N
未通过(有错误)
N->Y
修复后通过(有错误但已修复)
X
无该测试项目
Z
无法确定(不能判断或无法测试)
9.问题用例编号:
在本项目上未通过的用例编号,未在该项目上出错的用例不用填写;
10.改善意见及其它说明:
测试人员对该项目完善的意见及说明文字。
(二)测试用例部分:
1.用例编号:
测试用例的流水编号;
2.测试序号:
第几轮测试的编号,如第一轮测试就填入1st;
3.测试项目分类:
某测试用例如果是专为某测试项目测试而编制的,则选择具体的测试项目分类,否则,选择全部;
4.用例前提:
使用该用例测试的前提条件是什么;
5.步骤描述:
对操作步骤进行详细描述;
6.输入值:
对本测试操作所输入的内容值;
7.预期结果:
对本测试操作的系统反应的期望结果,也就是说正确的结果是什么;
8.实际结果:
测试人员本测试用例进行测试后,系统给出的实际操作结果
9.是否通过:
实际测试后,比较预期结果与实际结果,判定是否能够通过本次测试;
10.标志状态:
用于测试人员与开发人员共同对缺陷的改善进行跟踪,具体见下表:
缺陷状态
描述
提交
测试经理:
已提交但未确认的缺陷
打开
开发经理:
确认“提交的缺陷”,分配相关人员修复
拒绝
开发经理:
拒绝“提交的缺陷”,不需要修复或不是缺陷
解决
开发经理:
缺陷被修复
关闭
测试经理:
确认被修复的缺陷,将其关闭
暂缓
开发经理:
暂时无法解决的缺陷
6.2、测试报告命名规范
规则:
程序ID_测试人姓名全拼_测试日期(YYYYMMDD)_第几轮测试。
例如:
测试人员王朋在2010年10月9日在进行第1轮测试,被测程序ID为A01,这时这个测试报告的名称应该为:
A01_wangpeng_20101009_1.xls
6.3、测试报告提交方式
测试报告提交到服务器的VSS上的XX目录下,VSS服务器用户名:
密码:
7质量目标
编写
测试质量目标
确认人以及特殊说明
1
测试已实现的产品是否达到设计的要求,包括:
各个功能点是否以实现,业务流程是否正确
2
所有的测试用例已经执行过
3
所有的自动测试脚本已经执行通过
4
不允许存严重程度为高和中的功能缺陷
5
缺陷的发现速率正在下降并接近0
6
在最后的三天内没有发现严重程度为高和中的缺陷
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 秦皇岛 移动 客服 信息管理 平台 系统 测试 计划书