OA测试计划书Word文件下载.docx

OA测试计划书Word文件下载.docx

《OA测试计划书Word文件下载.docx》由会员分享，可在线阅读，更多相关《OA测试计划书Word文件下载.docx（15页珍藏版）》请在冰豆网上搜索。

测试挂起/恢复的标准

应交付的测试工作产品

1.2被测对象

本次测试的对象包括：

人力资源管理系统。

人力资源系统基于B/S架构。

主要是对用户的档案以及绩效考核进行管理。

1.3术语和缩略语

无

参考资料

《项目计划.doc》

《需求规格说明书.doc》

2.范围

本次测试的范围，包括功能和压力测试、性能测试、兼容性测试、可用性测试、错误恢复和可靠性测试、安全性测试、可维护性测试、安装部署测试、配置项测试等。

参考被测对象的软件需求规格说明书，对各类测试说明测试项和不被测试

功能测试

功能测试主要包括登录、人事管理、绩效考核、销售管理、超级管理四个模块。

序号

功能模块

功能项

优先级

1

登录功能

登录

High

2

人事管理

档案管理

3

档案查询

4

历史记录

5

数据维护

6

档案统计

7

绩效考核

考核打分

8

打分跟踪

9

成绩管理

10

成绩发布

11

部门成绩

12

部门统计

13

年龄统计

14

考核分组

15

考核方案

16

同事打分

17

自我评价

18

领导打分

19

我的成绩

20

销售管理

客户管理

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功能测试

模块

测试项

用例设计方法

测试重点

等价类

利用正确的用户名密码可以正常登录

等价类，边界值

选择部门后，可以添加用户

正交法，边界值

可以正确查询到所需档案

查看到历史记录

边界值

可以正确统计档案的数量

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配置项测试

2）IE8浏览器环境下基本功能和性能测试。

3）IE7浏览器环境下基本功能和性能测试。

4.测试环境

4.1实际环境

客户端：

pc机、IE7浏览器

服务器端：

windowsserver2003、mysql、apache、版本以上）

功能测试环境

资源列表

前台：

2台PC

后台：

1台pc

测试人员：

3人

4.3性能测试环境

pc机、IE7浏览器、loadrunner

后台与功能测试相同；

前台需要添加秒表计时器；

计时器可网上下载。

4.4资源的分配

高翠,赵维海，李杰斌

测试机器：

台式机3台，要求CPU：

1GMHZ以上，内存：

1GMB以上。

测试环境：

WindowsXP，WindowsXP,windows2003sever+mysql+jdk+apache

4.5测试工具

需求

是否已具备

使用工具

解决途径

管理用例及问题跟踪工具

已有

QC

性能测试模拟场景

Loadrunner

5.测试人员

[测试技能和经验要求]

a）测试人员需要具备懂得测试的基本操作和应付临时危机的技能；

b）工作经验至少工作1-2年；

测试人力资源数量：

测试人员介入时间段：

a）测试计划：

高翠负责；

b）测试设计：

高翠，赵维海，李杰斌负责；

c）测试实现：

赵维海，李杰斌负责；

d）测试执行：

6测试管理

角色和职责

外部

角色

人员

职责描述

客户经理

xxx

产品规划

对本项目产品需求进行细化，并保证项目的产出符合用户要求

项目经理

对本项目进行全面负责，保证项目按时按质完成

QA

协助项目经理完成系统设计和软件质量控制方面的工作

软件需求作者

完成软件需求的编写

开发工程师

概要设计，详细设计，编码，单元测试。

配置管理员

做好后台管理，对软件的版本进行有序的管理。

内部

●测试负责人：

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

•系统不能启动或启动后无法正常工作；

•系统经常自动崩溃（至少一天一次）。

●修复优先级：

优先级别

•该缺陷希望被修复，并且修复可以在以后的版本中发布。

•该缺陷必须被修复，并且修复可以在以后的版本中发布。

•该缺陷必须被修复，并在正式版本发布前重新提交验证。

•该缺陷必须尽快被修复。

•该修复将在一个工作日内以特定补丁的形式提交，使测试能够继续下去。

•该缺陷必须立刻被修复。

•该修复将在半个工作日内以正式补丁的形式提交，使测试能够继续下去。

测试发现的缺陷将提交到TD缺陷库中集中，将作为对版本/PATCH漏测率考核的依据。

测试执行管理

通过项目系统测试状态统计表纳入管理。

变更管理

●需求变更

需求变更时必须及时通知测试负责人，并且在测试开始前2个工作日以前完成，否则测试组无法做出相应的测试准备工作，不予安排测试。

●计划变更

如果测试部发生人力资源变化而引起工作量超过0.5人*天的情况下，需要相应的变更本测试计划。

如果测试进行过程中加入了其他非计划的突发任务，而导致工作量巨大，无法完成任务的时候，需要相应的变更本测试计划。

由于进行系统测试的版本存在严重的质量问题或开发人员修改测试问题效率、质量过低，导致测试延误，应修改测试计划来规划新的测试进度。

7计划进度

里程碑

功能测试完成。

测试时间安排

任务

内容

前置任务

工作量

开始时间

终止时间

负责人

输出

测试案例编写

2012.11.28

高翠，李杰斌

《功能性测试用例》

《兼容性测试用例》

测试环境准备

执行测试并记录结果

2012.12.01

李杰斌，赵维海

QC中

完成测试报告

2012.

《功能性测试报告》

《兼容性测试报告》

测试评估

2012.12.09

测试结果修正与跟踪

2012.12.11

8风险和应急

如果测试人员离职，需要有一个月的交接时间，以保证测试工作的顺利进行。