OA测试计划书.docx
- 文档编号:3798289
- 上传时间:2022-11-25
- 格式:DOCX
- 页数:15
- 大小:21.90KB
OA测试计划书.docx
《OA测试计划书.docx》由会员分享,可在线阅读,更多相关《OA测试计划书.docx(15页珍藏版)》请在冰豆网上搜索。
OA测试计划书
文档版本号:
文档编号:
文档密级:
秘密
归属部门/项目:
产品名:
OA
子系统名:
人力资源系统
编写人:
高翠
编写日期:
2012-11-26
测试计划书
拟制:
高翠
日期:
2012/11/26
审核:
日期:
yyyy/mm/dd
批准:
日期:
yyyy/mm/dd
修订记录:
版本号
修订人
修订日期
修订内容
V
高翠
2012-11-26
初稿完成
1.引言
本文档是为了指导人力资源系统的测试代码设计、测试用例设计和测试执行。
本系统测试计划对测试范围、测试策略、测试环境等进行了定义,主要用于测试负责人指导整个项目的系统测试能够有序、完整的实施,为产品质量提供有力的保证。
同时供项目经理、开发人员、测试人员参考。
目标
本计划旨在对人力资源系统的以下各项内容进行明确的标识,使系统测试活动可以顺利有效的执行。
Ø组织结构,结构间的关系及成员的职责
Ø测试进度,任务安排
Ø测试通过/失败的标准
Ø测试挂起/恢复的标准
Ø应交付的测试工作产品
1.2被测对象
本次测试的对象包括:
人力资源管理系统。
人力资源系统基于B/S架构。
主要是对用户的档案以及绩效考核进行管理。
1.3术语和缩略语
无
参考资料
《项目计划.doc》
《需求规格说明书.doc》
2.范围
本次测试的范围,包括功能和压力测试、性能测试、兼容性测试、可用性测试、错误恢复和可靠性测试、安全性测试、可维护性测试、安装部署测试、配置项测试等。
参考被测对象的软件需求规格说明书,对各类测试说明测试项和不被测试
功能测试
功能测试主要包括登录、人事管理、绩效考核、销售管理、超级管理四个模块。
序号
功能模块
功能项
优先级
1
登录功能
登录
High
2
人事管理
档案管理
High
3
档案查询
High
4
历史记录
High
5
数据维护
High
6
档案统计
High
7
绩效考核
考核打分
High
8
打分跟踪
High
9
成绩管理
High
10
成绩发布
High
11
部门成绩
High
12
部门统计
High
13
年龄统计
High
14
考核分组
High
15
考核方案
High
16
同事打分
High
17
自我评价
High
18
领导打分
High
19
我的成绩
High
20
销售管理
客户管理
High
21
销售管理
22
供应商
23
库存管理
24
超级管理
组织结构
25
权限管理
26
公共共享
27
文件柜
28
工作流程
29
公共通讯录
30
问卷调查
31
考试管理
32
查看生日
33
工作计划
34
值班管理
35
讨论管理
36
论坛管理
37
短信管理
38
任务督办
39
CRM
40
工作日历
41
汇率管理
42
系统管理
性能和压力测试
性能测试主要有个方面:
1、档案管理数量达到1000个,查询档案所需要的时间。
2、档案管理数量达到1000个,档案统计所需要时间。
3、如果同时有几十个用户同时登录系统,看系统页面的响应时间。
2.3兼容性测试
客户端:
IE7、IE8、360浏览器。
服务器端:
windowsserver2003、linux系统
2.4可用性测试
人力资源系统通过网页来进行操作,需要进行可用性测试,测试包括以下范围:
1.简易性
●界面提供功能操作步骤简单、明了;容易操作。
2.直观性
●用户界面简洁,布局合理。
页面各元素不拥挤,界面不应该为用户制造障碍,所需功能或者期待的响应应该明显,并在预期出现的地方;对于重要操作给予用户明确提示。
3.一致性
●用户界面布局风格一致;界面各等价元素的标识、位置应尽量保持一致;系统涉及到的等价的术语和给予用户的提示应保持一致。
4.舒适性
●用户界面、快捷键、菜单等的设计和使用尽量贴近大众用户使用习惯。
2.5安全性测试
功能点:
1)用户登录名的输入格式
2)用户密码是否已经做加密处理
3)普通用户登录的权限设置
4)SQL注入
5)文件上传
6)Session和cookie,用于验证session和cookie不会导致信息泄露和认证错误。
7)服务器端是否验证客户端的输入(如长度,数据类型,格式)。
2.6安装部署测试
1)Windows操作系统:
windows2003server;
2)IE浏览器;
3)数据库:
Mysql;
2.7配置项测试
1)360浏览器下基本功能和性能测试。
2)IE7浏览器环境下基本功能和性能测试。
3)IE8浏览器环境下基本功能和性能测试。
3.测试策略
3.1功能测试
模块
测试项
用例设计方法
测试重点
登录
登录功能
等价类
利用正确的用户名密码可以正常登录
人事管理
档案管理
等价类,边界值
选择部门后,可以添加用户
档案查询
正交法,边界值
可以正确查询到所需档案
历史记录
查看到历史记录
数据维护
等价类
档案统计
边界值
可以正确统计档案的数量
绩效考核
考核打分
打分跟踪
成绩管理
成绩发布
部门成绩
部门统计
年龄统计
考核分组
考核方案
同事打分
自我评价
领导打分
我的成绩
销售管理
客户管理
销售管理
供应商
库存管理
超级管理
组织结构
权限管理
公共共享
文件柜
工作流程
公共通讯录
问卷调查
考试管理
查看生日
工作计划
值班管理
讨论管理
论坛管理
短信管理
任务督办
CRM
工作日历
汇率管理
系统管理
3.2性能和压力测试
通过使用性能测试工具Loadrunner,设置测试场景,观察测试结果和系统运行日志。
压力测试主要是针对后台服务器进行。
主要考虑的是客户端输入内容后,传输给后台服务器时服务器的处理能力。
要求系统达到以下性能指标:
1、档案管理数量达到1000个,查询档案控制在3秒内。
2、档案管理数量达到1000个,档案统计所需要时间控制在3秒内。
3、如果同时有几十个用户同时登录系统,看系统页面的响应时间不能超过1s。
3.3兼容性测试
兼容性测试优先级较低,时间充裕的情况下考虑:
兼容性测试主要考虑在IE8、IE7浏览器和360浏览器,在IE7上面测试所有的功能,在其他的浏览器测试主要功能。
3.4可用性测试
通过在功能测试过程中,观察各界面的布局、风格,菜单,快捷操作,提示语,及使用相关功能的舒适性,来对系统的可用性进行验证。
3.5安全性测试
1)用户名输入特殊值,密码不输入是否可以登录系统。
2)利用抓包工具,看用户密码是否加密。
3)普通用户的权限。
4)SQL注入。
5)文件上传,观察上传文件,是否对文件的类型进行过滤。
6)服务器端对用户输入的数据是否进行验证。
3.6安装部署测试
系统文件是否完整。
3.7配置项测试
1)360浏览器下基本功能和性能测试。
2)IE8浏览器环境下基本功能和性能测试。
3)IE7浏览器环境下基本功能和性能测试。
4.测试环境
4.1实际环境
客户端:
pc机、IE7浏览器
服务器端:
windowsserver2003、mysql、apache、版本以上)
功能测试环境
客户端:
pc机、IE7浏览器
服务器端:
windowsserver2003、mysql、apache、版本以上)
资源列表
前台:
2台PC
后台:
1台pc
测试人员:
3人
4.3性能测试环境
客户端:
pc机、IE7浏览器、loadrunner
服务器端:
windowsserver2003、mysql、apache、版本以上)
资源列表
后台与功能测试相同;前台需要添加秒表计时器;
计时器可网上下载。
4.4资源的分配
测试人员:
高翠,赵维海,李杰斌
测试机器:
台式机3台,要求CPU:
1GMHZ以上,内存:
1GMB以上。
测试环境:
WindowsXP,WindowsXP,windows2003sever+mysql+jdk+apache
4.5测试工具
需求
是否已具备
使用工具
解决途径
管理用例及问题跟踪工具
已有
QC
性能测试模拟场景
已有
Loadrunner
5.测试人员
[测试技能和经验要求]
a)测试人员需要具备懂得测试的基本操作和应付临时危机的技能;
b)工作经验至少工作1-2年;
测试人力资源数量:
3
测试人员介入时间段:
a)测试计划:
高翠负责;
b)测试设计:
高翠,赵维海,李杰斌负责;
c)测试实现:
赵维海,李杰斌负责;
d)测试执行:
高翠,赵维海,李杰斌负责;
6测试管理
角色和职责
外部
角色
人员
职责描述
客户经理
xxx
产品规划
xxx
对本项目产品需求进行细化,并保证项目的产出符合用户要求
项目经理
xxx
对本项目进行全面负责,保证项目按时按质完成
QA
xxx
协助项目经理完成系统设计和软件质量控制方面的工作
软件需求作者
xxx
完成软件需求的编写
开发工程师
xxx
概要设计,详细设计,编码,单元测试。
配置管理员
xxx
做好后台管理,对软件的版本进行有序的管理。
内部
●测试负责人:
高翠
1.制定测试计划,组织测试工作
2.掌控测试进度,控制风险。
3.协调与外部团队的工作配合。
4.指导测试人员测试工作。
5.测试总结报告评审组织。
●测试人员:
赵维海
李杰斌
1.测试用例编写。
2.测试用例执行。
3.向测试负责人汇报测试进度。
工作汇报
2、测试负责人每天向项目经理提交测试日报。
3、测试人员每天向测试负责人提交测试日报。
测试开始的标准
开发组提交用于测试的版本后,经产品测试人员的评估,认为达到进入测试的标准后开始,否则退回产品开发组继续完善产品。
测试终止和完成的标准
●测试终止:
由于进行测试的产品存在严重的质量问题,导致测试无法继续,并且产品开发组在项目测试组可接受的时间范围内无法修复,测试终止。
●测试完成:
对于进行测试的产品,执行完所有测试的功能、兼容性等测试案例,无3级(含)以上遗留问题,测试完成。
缺陷管理
●缺陷严重级别:
严重级别
严重程度
1-Low
•微小的错误,不会影响系统的功能;
•该问题是一个不准确或容易误解的行为,但不会引起下面(Severity2、3、4、5)列出的问题
2-Medium
•该问题增加了安装、测试或用户操作的复杂度或成本;
•该问题轻微降低了系统的性能,但系统仍然能工作。
3-High
•该问题会严重降低系统的性能;
•用户需求没有实现;
•该问题不符合需求规格书;
•该问题引起系统的部件故障。
4-VeryHigh
•系统不能正常启动或时常自动崩溃(至少一星期一次)。
5-Urgent
•系统不能启动或启动后无法正常工作;
•系统经常自动崩溃(至少一天一次)。
●修复优先级:
优先级别
严重程度
1-Low
•该缺陷希望被修复,并且修复可以在以后的版本中发布。
2-Medium
•该缺陷必须被修复,并且修复可以在以后的版本中发布。
3-High
•该缺陷必须被修复,并在正式版本发布前重新提交验证。
4-VeryHigh
•该缺陷必须尽快被修复。
•该修复将在一个工作日内以特定补丁的形式提交,使测试能够继续下去。
5-Urgent
•该缺陷必须立刻被修复。
•该修复将在半个工作日内以正式补丁的形式提交,使测试能够继续下去。
测试发现的缺陷将提交到TD缺陷库中集中,将作为对版本/PATCH漏测率考核的依据。
测试执行管理
通过项目系统测试状态统计表纳入管理。
变更管理
●需求变更
需求变更时必须及时通知测试负责人,并且在测试开始前2个工作日以前完成,否则测试组无法做出相应的测试准备工作,不予安排测试。
●计划变更
如果测试部发生人力资源变化而引起工作量超过0.5人*天的情况下,需要相应的变更本测试计划。
如果测试进行过程中加入了其他非计划的突发任务,而导致工作量巨大,无法完成任务的时候,需要相应的变更本测试计划。
由于进行系统测试的版本存在严重的质量问题或开发人员修改测试问题效率、质量过低,导致测试延误,应修改测试计划来规划新的测试进度。
7计划进度
里程碑
功能测试完成。
测试时间安排
序号
任务
内容
前置任务
工作量
开始时间
终止时间
负责人
输出
1
测试案例编写
2012.11.28
高翠,李杰斌
《功能性测试用例》
《兼容性测试用例》
2
测试环境准备
1
8
1
赵维海
3
执行测试并记录结果
2
2012.12.01
李杰斌,赵维海
QC中
4
完成测试报告
3
2012.
高翠
《功能性测试报告》
《兼容性测试报告》
5
测试评估
4
2012.12.09
6
测试结果修正与跟踪
4
2012.12.11
8风险和应急
如果测试人员离职,需要有一个月的交接时间,以保证测试工作的顺利进行。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- OA 测试 计划书