测试计划.docx

上传人:b****8 文档编号:27665878 上传时间:2023-07-03 格式:DOCX 页数:14 大小:20.97KB
下载 相关 举报
测试计划.docx_第1页
第1页 / 共14页
测试计划.docx_第2页
第2页 / 共14页
测试计划.docx_第3页
第3页 / 共14页
测试计划.docx_第4页
第4页 / 共14页
测试计划.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

测试计划.docx

《测试计划.docx》由会员分享,可在线阅读,更多相关《测试计划.docx(14页珍藏版)》请在冰豆网上搜索。

测试计划.docx

测试计划

 

安徽地税执法管理信息系统

测试计划

产品名称:

安徽地税执法管理信息系统

项目承担部门

软件研发部

撰写人(签名)

完成日期

2009-10-31

本文档使用部门

测试部

评审负责人(签名)

评审日期

2009-11-10

版本

1.0

 

日期

测试工作

进度(人*工作日)

任务分配

2009-09-21---2009-09-22

测试计划

2

张士伟

2009-09-23---2009-09-30

测试设计

6

张士伟

2009-10-01---2009-10-20

测试执行总共进度

14

张士伟

2009-10-21---2009-10-27

每次回归进度

5

张士伟

2009-10-28---2009-10-31

测试报告

3

张士伟

 

目录

1概述1

1.1产品简介1

1.2范围1

1.3限制条件2

1.4参考文档2

2约定2

2.1测试目标2

2.2接收标准2

2.3资源和工具3

2.3.1资源3

2.4工具3

2.5送测要求3

2.6编号规则3

3测试种类及测试标准4

3.1测试种类4

3.2测试方法及标准4

3.2.1功能测试4

3.2.2业务测试5

3.2.3压力测试5

3.2.4安装测试6

3.2.5验收测试7

4测试重点及顺序7

4.1预测风险7

4.2测试重点8

4.2.1功能测试8

4.2.2压力测试8

5暂停标准和再启动要求9

6测试任务和进度9

7测试提交物11

1概述

随着税收AHTAX2009征管系统的完善,新《征管法》对税务机关实施税务检查赋予了更多的权限,同时对税务机关应承担的法律责任也作了进一步的明确,这就要求税务工作人员必须以国家税收法律、法规为依据,对纳税人、扣缴义务人是否履行纳税义务进行严格的审核监督,防范和惩治纳税人的税收违法犯罪行为,维护税务管理和税款征收工作秩序。

党的十六大明确提出将依法治国为党领导人民治理国家的基本方略,要求政府机关必须依法行政,并要求加强对政府机关和政府工作人员执法活动的监督。

为进一步规范税收执法行为,促进税务机关依法行政,全面推进依法治税,切实贯彻依法治国基本方略,国家税务总局决定,在税务系统推进税收执法监督工作。

1.1产品简介

本项目是一个以监控监督为目的的税收执法监督管理系统,其中包括了对征管业务日常工作的监控、考核以及对业务人员过错行为的追究。

其主要内容有:

征管数据监控、日常考核(系统自动考核、人机结合考核)、过错申请、审批,责任追究、申辩调整等几大部分。

1.2范围

本测试计划是针对<安徽地税执法管理信息系统>中规定内容的测试计划,包括:

Ø用户登陆模块

Ø我的工作夹

Ø执法考核

Ø系行政追究

Ø查询

Ø统计

Ø法制报表

Ø省局查询

Ø省局统计

Ø权限分配

Ø系统设置

1.3限制条件

本测试计划受限于产品开发人员提交测试的内容和时间的事实。

根据开发人员提交模块的实际情况,本计划会做出相应修改。

1.4参考文档

序号

名称

作者

备注

1.

需求分析说明书

吴鹏、何书查、孙睿

2.

概要设计说明书

吴鹏、何书查、孙睿

3.

系统详细设计说明书

吴鹏、周道源、孙睿

4.

用户功能使用说明书

吴鹏、周道源、张士伟

 

2约定

2.1测试目标

通过测试,达到以下目标:

Ø测试已实现的产品是否达到设计的要求,包括:

各个功能点是否以实现,业务流程是否正确。

Ø产品规定的操作和运行稳定。

ØBug数和缺陷率控制在可接收的范围之内。

2.2接收标准

本节所述的接收标准是指可测试的标准,这个标准以测试组接收测试为限。

单元测试接收标准的详细规定参见文档测试接收标准.doc。

其余各阶段接收标准,以经过审核后的上一阶段测试报告为准,每一阶段停止标准的详细规定参见文档软件测试停止标准.doc。

2.3资源和工具

2.3.1资源

Ø测试服务器

稳定的测试服务器,IP地址为:

192.168.7.2。

Ø人员

测试审核人一名,测试实施人员2名。

2.4工具

Ø测试中使用的Bug管理工具为经过改进的Bug管理工具。

Ø自动化测试工具待定。

2.5送测要求

提交的测试按以下要求进行:

步骤

动作

负责人

相关文档或记录

要求

1

打包、编译

开发人员

确认可测试

2

审核并提交测试

吴燕

经审核的上一级测试报告

测试报告吴燕审核并签字

3

接收测试

测试人员

经吴燕审核并签字的上一级测试报告

4

开始测试

测试人员

Bug单、小结

测试小结个人编写个人的内容

2.6编号规则

与本测试计划相关的编号规则如下:

Ø测试用例中的编号,项目名称(每个字第一个汉语拼音大写)+编号

例如:

用例

AHZF0001

Ø测试用例文件命命名规则,模块名+测试用例

例如:

用户登录模块

用户登录测试用例

3测试种类及测试标准

3.1测试种类

计划完成以下类型测试

Ø功能测试

Ø业务测试

Ø压力测试

Ø安装测试

Ø验收测试

3.2测试方法及标准

3.2.1功能测试

3.2.1.1功能

系统能按照设计要求实现模块的各个功能,数据应完整、界面美观、操作方便。

具体可参照本文档测试重点及顺序部分。

3.2.1.2界面测试

详细的界面测试可以参考界面测试.doc。

3.2.1.3数据项测试

Ø字母数字数据项是否能够正确回显,并输入到系统中?

Ø图形模式的数据项(如滑动条)是否正常工作?

Ø是否能够识别非法数据?

Ø数据输入消息是否可理解?

3.2.1.4帮助文档测试

Ø文档是否精确描述了如何使用各种使用模式?

Ø交互顺序的描述是否精确?

Ø例子是否精确?

Ø术语、菜单描述和系统响应是否与实际程序一致?

Ø是否能够很方便地在文档中定位指南?

Ø是否能够很方便地使用文档排除错误?

Ø文档的内容和索引是否精确完整?

Ø文档的设计(布局、缩进和图形)是否便于信息的理解?

Ø显示给用户的错误信息是否有更详细的文档解释?

Ø如果使用超级链接,超级链接是否精确完整?

3.2.2业务测试

功能测试完成后进行业务测试,业务测试关注的要点是业务流程,及数据流从软件中的一个模块流到另一个模块的过程中的正确性。

业务测试的方法及标准参考业务测试用例。

3.2.3压力测试

3.2.3.1压力测试说明

本次压力测试根据实际情况包含性能测试,重点模拟客户进行多用户测试。

压力测试有一条8:

2原则。

及百分之八十的业务量在百分之二十的时间内输入。

例如:

正常每天有100条新数据,测试时在两小时内输入80条数据。

我们无法知道用户的业务量,所以用loadrunner进行压力测试。

3.2.3.2压力测试工具

Loadrunner

3.2.3.3压力测试方法及标准

压力测试的方法及标准参考压力测试用例。

3.2.4安装测试

3.2.4.1安装测试说明

除了嵌入式软件之外,安装是软件产品实现其功能的第一步,没有正确的安装根本就谈不上正确的执行,因此对于安装的测试就显得尤为重要。

3.2.4.2安装测试方法及标准

Ø自动安装还是手工配置安装,测试各种不同的安装组合,并验证各种不同组

合的正确性,最终目标是所有组合都能安装成功。

Ø安装退出之后,确认应用程序可以正确启动、运行。

Ø卸载测试和安装测试同样重要,如果系统提供自动卸载工具,那么卸载之后需检验系统是否把所有的文件全部删除,注册表中有关的注册信息是否也被删除。

Ø至少在一台笔记本上进行安装测试,因为有很多产品在笔记本中会出现问题,尤其是系统级的产品。

Ø安装完成之后,可以在简单地使用之后再执行卸载操作,有的系统在使用之后会发生变化,变得不可卸载。

Ø安装时间是否合理;

Ø对于客户服务器模式的应用系统,可以先安装客户端,然后安装服务器端,测试是否会出现问题。

Ø考察安装该系统是否对其他的应用程序造成影响,特别是Windows操作系统,经常会出现此类的问题。

3.2.5验收测试

3.2.5.1验收测试说明

软件产品测试部对经过内部单元测试、集成测试和系统测试后的软件所进行的测试,测试用例采用业务流程测试用例。

3.2.5.2验收测试方法及标准

参考验收测试规范和软件测试停止标准。

4测试重点及顺序

4.1预测风险

本次测试过程中,可能出现的风险如下:

Øbug的修复情况

Ø模块功能的实现情况

Ø系统整体功能的实现情况

Ø代码的编写质量

Ø人员经验以及对软件的熟悉度

Ø开发人员、测试人员关于项目约定的执行情况

Ø人员调整导致研发周期延迟

Ø开发时间的缩短导致某些测试计划无法执行

4.2测试重点

4.2.1功能测试

这里仅为测试重点的描述,具体测试方法以及内容请参见测试用例。

4.2.1.1后台监控指标分析模块

Ø对征管每天的数据进行分析是否准确。

4.2.1.2考核计划业务流程

Ø考核计划的制作流程是否运行平稳。

Ø过错解释、审批、转追究、复审等运行是否平稳。

4.2.1.3系统设置和查询统计

Ø对系统编码表的设置是否达到设计运行要求。

Ø项目增、删、改功能是否运行平稳

Ø对后台数据的查询统计分析是否准确。

4.2.1.4计划上传

Ø对每月的考核计划数据是否完整的上传到省局数据库。

4.2.1.5其他功能模块

Ø预警提示是否及时准确。

Ø过错提示是否准确。

4.2.2压力测试

这里只是描述了压力测试的大概情况,具体测试方法以及内容请参见压力测试用例。

这里的压力测试包含模块之间的关系。

4.2.2.1用户登录

Ø多用户同时登录,系统承载能力情况。

Ø多用户陆续登录,系统承载情况。

4.2.2.2批次单独选项管理

Ø多用户同时进行增删改,系统承压情况。

5暂停标准和再启动要求

Ø软件系统在进行单元、集成、确认、系统、安装、验收测试时,发现一级错误(大于等于1)、二级错误(大于等于2)暂停测试返回开发。

Ø软件项目需暂停以进行调整时,测试应随之暂停,并备份暂停点数据。

Ø软件项目在其开发生命周期内出现重大估算,进度偏差,需暂停或终止时,测试应随之暂停或终止,并备份暂停或终止点数据。

Ø如有新的项目需求,则在原测试计划下做相应的调整。

Ø若开发暂停,则相应测试也暂停,并备份暂停点数据。

Ø若项目中止,则对已完成的测试工作做测试活动总结。

Ø项目再启动时,测试进度重新安排或顺延。

6测试任务和进度

测试阶段

测试任务

工作量估计

人员分配

起止时间

 

第一阶段

单元测试

 

用户登陆模块

我的工作夹

执法考核

行政追究

查询

统计

法制报表

省局查询

省局统计

权限分配

系统设置

 

14日(新增内容)

 

张士伟

2009.10.01—2009.10.20

单元测试BUG审核

3日

张士伟

2009.10.01—2009.3.03

第二阶段

集成测试

各模块之间的集成测试

3日

张士伟

2009.10.04—2009.10.06

根据实际任务情况人员做一定调整

第三阶段

业务测试

1.业务流程测试

2.关注数据的准确性,特别是报表

13日

张士伟

2009.10.07—2009.10.20

第四阶段

性能测试

性能测试

2日

张士伟

2009.10.20—2009.10.22

第五阶段

帮助和用户手册测试

1.帮助测试

2.用户手册测试

1日

张士伟

2009.10.23

第六阶段

审核BUG

审核单元测试以外的BUG

2日

张士伟

2009.10.24—2009.10.25

第七阶段

安装测试

程序的安装过程

1日

张士伟

2009.10.26—2009.10.26

第八阶段

验收测试

模仿用户使用过程的测试

1日

张士伟

2009.10.27--2009.10.27

第九阶段

附加测试

张士伟

测试总结

测试总结和分析、问题反馈

1日

张士伟

2009.10.28--2009.10.28

7测试提交物

本次测试完成后的提交物:

Ø测试计划

Ø测试用例

Ø测试Bug单

Ø测试总结

Ø测试分析报告

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高中教育 > 数学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1