引入自动化测试的可行性分析报告文档格式.docx

引入自动化测试的可行性分析报告文档格式.docx

《引入自动化测试的可行性分析报告文档格式.docx》由会员分享，可在线阅读，更多相关《引入自动化测试的可行性分析报告文档格式.docx（15页珍藏版）》请在冰豆网上搜索。

QTP：

QuickTestProfessional，Mercury公司生产的功能测试工具。

1.3参考文档

2.项目介绍

2.1.项目背景

XXXX客户网银资金治理系统，是XXXX客户为了加强银行账户治理，提高资金利用效率而开发的一套资金治理系统。

2.2.项目开发、运行环境

XXXX客户网银资金治理系统遵循的开发规范如下：

Ø

操作系统：

Windows2003或者HPUnix或者SCOUnix或者AIX或者Solaris

数据库平台：

Informix9.0

J2EE应用服务器：

Weblogic8.1.4

开发平台：

Eclipse（3.1以上版本）

2.3.项目进度

项目的预定打算如下：

序号

时期名称

工期

开始时刻

结束日期

1

需求时期

34工作日

2006-5-10

2006-06-26

2

开发时期

64工作日

2006-6-12

2006-9-7

3

测试执行时期

48工作日

2006-7-4

2.4.项目特点分析

依照业务需求分析，业务量要紧集中在银行业务数据操作，包括银行数据查询，银行业务数据变更，因为和银行的交互集中在前置机上，且银行数据量大，操作复杂，耗费时刻长，因此系统在多用户并发操作时，可能存在性能瓶颈。

另外，由于XXXX客户的分支机构众多，操作人员多，数据量大，在多用户并发操作时，性能和效率会有较大阻碍。

3.现有测试流程

现有的测试流程按照时期划分为测试设计时期和测试执行时期。

测试设计时期的要紧工作是依照业务需求讲明书和系统需求讲明书来设计和编写测试用例。

依照以往的经验，将测试用例划分成三个部分：

测试需求分析；

测试方案；

数据执行步骤。

测试执行时期的要紧手段是手工测试，假如项目有性能方面的需求，再通过Mercury公司的性能测试工具LoadRunner来进行性能方面的测试。

手工测试时，要完成以下工作：

依照测试需求分析了解业务；

依照测试方案来执行测试；

依照数据库和详细设计来验证系统的具体实现；

依照测试结果补充、修正测试用例中的分析、测试方案部分。

系统上线部署之前两到三天，要进行内部的验收测试，其目的有两个：

确认系统差不多预备就绪，预定功能差不多实现；

立即上线部署的软件是正确的版本。

要紧通过重新搭建系统环境，重建数据库表的形式来开始验收测试。

4.自动化测试简介

随着软件开发技术和工具的提高，软件工程和软件过程实践的推广，软件测试日益得到重视和专业化。

自动化测试更成为热门话题。

测试自动化确实是充分利用市场已有的或自行开发的测试工具，全部或部分替代手工测试、完成手工测试无法完成的测试任务，以及相关的测试数据的记录和测试报告的生成等。

相关于手工测试而言，测试自动化通常具有速度快、执行效率高、执行过程受外界因素干扰小、测试结果准确等优点，缺点是前期投入较大，因此在采纳测试自动化之前应当做好相应的评估工作。

4.1.自动化测试的目的

自动化测试的目的是通过自动执行测试脚本，使测试人员在更短的时刻内能够更快地完成更多的软件测试，并提供以更高的频率执行测试的能力，从而有效降低测试成本、提高测试效率。

4.2.自动化测试的前提

自动化测试有几个前提：

测试人员的编程能力；

重用测试脚本的设计；

人机交互界面的早期冻结；

测试脚本开发的投入；

测试人员对测试工具的熟练程度。

4.3.自动化测试的优势和局限[1,2]

自动化测试的优势：

对新版本执行回归测试

关于产品型的软件，每公布一个新的版本，其中大部分功能和界面都和上一个版本相似或完全相同，这部分功能特不适合于自动化测试，从而能够让测试达到测试每个特征的目的。

更多更频繁的测试

在回归测试时期，假如是每天/每2天都要公布一个版本供测试人员测试，一个系统的功能点有几千个上万个，手工测试将是特不的耗时和繁琐，而且特不的枯燥，如此必定会使测试效率低下。

完善的自动化测试能够替代测试人员的手工测试。

一致性和可重复性

由于每次自动化测试运行的脚本是相同的，因此每次执行的测试具有一致性，人是专门难做到的。

由于自动化测试的一致性，专门容易发觉被测软件的任何改变。

自动化测试替代手工测试的困难：

自动化测试的目的在于发觉旧有缺陷，而手工测试的目的在于发觉新缺陷。

事实证明新缺陷越多，自动化测试失败的几率就越大。

发觉更多的新缺陷应该是手工测试的要紧目的。

测试专家JamesBach总结得出，85%的缺陷靠手工发觉，而自动化测试只能发觉15％的缺陷。

技术问题、组织问题、脚本维护

自动化测试的推行，有专门多阻力，比如组织是否重视，是否成立如此的测试团队，是否有如此的技术水平，关于测试脚本的维护工作量也挺大的，是否值得维护等等问题都必须考虑。

4.4.自动化测试工具对比[3,4]

目前比较主流的自动化功能测试工具要紧是Mercury公司的QTP、Winrunner，以及IBM公司的RationalFunctionTester。

下面对QTP和RationalFunctionTester的功能来进行对比：

功能指标

RationalFunctionTester

QTP

用户界面

与Eclipse集成

独立的GUI

脚本语言

Java

VBScript

测试Web系统

支持

数据驱动

内建数据池

从Excel中获得数据

检查点

脚本治理工具

TestManager

TestDirector

其它

支持BusinessProcessTesting（BPT）

目前，我们测试人员对QTP比较熟悉，没有使用过RationalFunctionTester。

就功能上来讲，RationalFunctionTester和QTP差不不大。

5.测试工作量估算

5.1.手工测试工作量估算

手工测试工作量的估算原则：

依照业务和功能的复杂程度，以及以往项目的实际数据做参考，得出测试完成一遍的工作量。

在整个项目测试周期中，测试小组会对整个系统进行两到三轮的测试（一般是必须的）。

依照以往项目的统计数据：

每一轮手工测试的工作量是上一轮工作量的50％，直到达到临界值，即完成一轮手工测试的最小时刻后，工作量可不能再减小。

项目统计数据还表明：

手工测试中，后期的测试工作占到全部测试工作的40％～50％。

业务功能点

测试完成的工作量（人日）

一级功能

二级功能

第一轮

第二轮

第三轮

系统治理

职责治理

2.0

1.0

0.5

用户治理

3.0

1.5

0.8

基础设置

机构类型设置

0.3

机构设置

币种设置

银行类型设置

账户用途设置

0.4

账户扩展属性设置

业务类型设置

账户治理

开户处理

4.0

销户处理

变更处理

账号升级申请

冻结与解冻

账户信息查询

资金清算

支出资金申请

5.0

2.5

1.3

归集资金申请

资金划拨

资金打算

行项目设置

编制打算

审批打算

资金监控

账户当日余额查询

账户历史余额查询

账户历史流水查询

监控项设置

监控报表和提醒

银企接口

银行指令查询

银行指令维护

自动归集策略设置

交易核对

审批流

审批设置

权限转移

每轮合计工作量（人日）：

97.5

48.8

24.4

用户手册

验收测试

12.0

手工测试合计工作量：

187.6人日

按照4个测试资源计算，手工测试完成共需消耗187.6/4＝46.9个工作日。

与预定打算的48个工作日的测试周期接近。

后期的测试工作占测试工作的45％左右。

指标

数值

估算测试工作量

测试资源

4人

估算测试工作日

187.6/4＝46.9日

打算测试工作日

48日

后期测试工作量比例

（48.8+24.4+12）/187.6=45％

对手工测试的工作量估算没有考虑开发进度delay的因素。

一旦开发进度delay，则第3轮手工测试将无法完成，只能把优先级不较高的功能测试完成。

开发进度delay的缘故专门大一部分来自需求变更。

5.2.引入自动化测试后工作量估算

引入自动化测试工具后，手工测试的要紧工作量将要紧集中在第一轮测试，而自动化测试脚本也依照被测试功能和业务的复杂程度不同而不同。

依照下表的统计数据，在自动化测试中采纳数据驱动的方式，投入产出比比较合适。

结构

成本

收益

净收益

NoAutomation

RecordingandPlayback

8.3

11

2.7

Data-drivenstructureusingdatapools

8.4

18

9.6

Frameworkstructure

9.8

15

5.2

Framework/data-driven（hybrid）structurefocusingonvie