《自动化测试可行性分析报告报告材料》由会员分享，可在线阅读，更多相关《自动化测试可行性分析报告报告材料（11页珍藏版）》请在金锄头文库上搜索。
1、wordXXXX客户网银资金管理系统引入自动化测试的可行性分析报告1. 概述1.1. 目的本文档对XXXX客户网银资金管理系统项目引入自动化测试工具的可行性进展评估，为项目经理提供决策参考。1.1 X围本文档描述了XXXX客户项目情况、现有测试工作流程、自动化测试本身的一些情况，对测试工作量进展了估算，最后对估算结果进展了分析，并依此提出了一些建议。本文档中讨论的自动化测试工具主要是功能测试工具。1.2 术语定义本文档涉与了几款自动化测试工具：TestManager：IBM公司的测试管理工具，属于Rational系列产品之一。Robot：IBM公司的性能测试工具，属于Rational系列产品之
2、一。RFT：Rational Function Tester，IBM公司的功能测试工具，属于Rational系列产品之一。TestDirector：Mercury公司生产的测试管理工具。Loadrunner：Mercury公司生产的性能测试工具。QTP：QuickTest Professional，Mercury公司生产的功能测试工具。1.3 参考文档2. 项目介绍2.1. 项目背景XXXX客户网银资金管理系统，是XXXX客户为了加强银行账户管理，提高资金利用效率而开发的一套资金管理系统。2.2. 项目开发、运行环境XXXX客户网银资金管理系统遵循的开发规X如下： 操作系统：Windows20
3、03或者HP Unix或者SCO Unix或者AIX或者Solaris 开发平台：Eclipse3.1以上版本2.3. 项目进度项目的预定计划如下：序号阶段名称工期开始时间完毕日期1需求阶段34工作日2006-5-102006-06-262开发阶段64工作日2006-6-122006-9-73测试执行阶段48工作日2006-7-42006-9-72.4. 项目特点分析根据业务需求分析，业务量主要集中在银行业务数据操作，包括银行数据查询，银行业务数据变更，因为和银行的交互集中在前置机上，且银行数据量大，操作复杂，消耗时间长，所以系统在多用户并发操作时，可能存在性能瓶颈。另外，由于XXXX客户的分
4、支机构众多，操作人员多，数据量大，在多用户并发操作时，性能和效率会有较大影响。3. 现有测试流程现有的测试流程按照阶段划分为测试设计阶段和测试执行阶段。测试设计阶段的主要工作是根据业务需求说明书和系统需求说明书来设计和编写测试用例。根据以往的经验，将测试用例划分成三个局部： 测试需求分析； 测试方案； 数据执行步骤。测试执行阶段的主要手段是手工测试，如果项目有性能方面的需求，再通过Mercury公司的性能测试工具LoadRunner来进展性能方面的测试。手工测试时，要完成以下工作： 根据测试需求分析了解业务； 根据测试方案来执行测试； 根据数据库和详细设计来验证系统的具体实现； 根据测试结果补
5、充、修正测试用例中的分析、测试方案局部。系统上线部署之前两到三天，要进展内部的验收测试，其目的有两个： 确认系统已经准备就绪，预定功能已经实现； 即将上线部署的软件是正确的版本。主要通过重新搭建系统环境，重建数据库表的形式来开始验收测试。4. 自动化测试简介随着软件开发技术和工具的提高，软件工程和软件过程实践的推广， 软件测试日益得到重视和专业化。自动化测试更成为热门话题。测试自动化就是充分利用市场已有的或自行开发的测试工具，全部或局部替代手工测试、完成手工测试无法完成的测试任务，以与相关的测试数据的记录和测试报告的生成等。相对于手工测试而言，测试自动化通常具有速度快、执行效率高、执行过程受外
6、界因素干扰小、测试结果准确等优点，缺点是前期投入较大，所以在采用测试自动化之前应当做好相应的评估工作。4.1. 自动化测试的目的自动化测试的目的是通过自动执行测试脚本，使测试人员在更短的时间内能够更快地完成更多的软件测试，并提供以更高的频率执行测试的能力，从而有效降低测试本钱、提高测试效率。4.2. 自动化测试的前提自动化测试有几个前提： 测试人员的编程能力； 重用测试脚本的设计； 人机交互界面的早期冻结； 测试脚本开发的投入； 测试人员对测试工具的熟练程度。4.3. 自动化测试的优势和局限1,2自动化测试的优势： 对新版本执行回归测试对于产品型的软件，每发布一个新的版本，其中大局部功能和界面
7、都和上一个版本相似或完全一样，这局部功能特别适合于自动化测试， 从而可以让测试达到测试每个特征的目的。 更多更频繁的测试在回归测试阶段，如果是每天 / 每 2 天都要发布一个版本供测试人员测试，一个系统的功能点有几千个上万个，手工测试将是非常的耗时和繁琐，而且非常的枯燥，这样必然会使测试效率低下。完善的自动化测试可以替代测试人员的手工测试。 一致性和可重复性由于每次自动化测试运行的脚本是一样的，所以每次执行的测试具有一致性，人是很难做到的。由于自动化测试的一致性，很容易发现被测软件的任何改变。自动化测试替代手工测试的困难： 自动化测试的目的在于发现旧有缺陷，而手工测试的目的在于发现新缺陷。事实
8、证明新缺陷越多，自动化测试失败的几率就越大。发现更多的新缺陷应该是手工测试的主要目的。测试专家 James Bach 总结得出， 85% 的缺陷靠手工发现，而自动化测试只能发现 15 的缺陷。 技术问题、组织问题、脚本维护自动化测试的推行，有很多阻力，比如组织是否重视， 是否成立这样的测试团队，是否有这样的技术水平，对于测试脚本的维护工作量也挺大的，是否值得维护等等问题都必须考虑。4.4. 自动化测试工具比照3,4目前比拟主流的自动化功能测试工具主要是Mercury公司的QTP、Winrunner，以与IBM公司的Rational Function Tester。下面对QTP和Rational
9、 Function Tester的功能来进展比照：功能指标Rational Function TesterQTP用户界面与Eclipse集成独立的GUI脚本语言JavaVBScript测试Web系统支持支持数据驱动内建数据池从Excel中获得数据检查点支持支持脚本管理工具TestManagerTestDirector其它支持Business Process TestingBPT目前，我们测试人员对QTP比拟熟悉，没有使用过Rational Function Tester。就功能上来说，Rational Function Tester 和QTP差异不大。5. 测试工作量估算5.1. 手工测试工作
10、量估算手工测试工作量的估算原如此：根据业务和功能的复杂程度，以与以往项目的实际数据做参考，得出测试完成一遍的工作量。在整个项目测试周期中，测试小组会对整个系统进展两到三轮的测试一般是必须的。根据以往项目的统计数据：每一轮手工测试的工作量是上一轮工作量的50，直到达到临界值，即完成一轮手工测试的最小时间后，工作量不会再减小。项目统计数据还明确：手工测试中，后期的测试工作占到全部测试工作的4050。业务功能点测试完成的工作量人日一级功能二级功能第一轮第二轮第三轮系统管理职责管理2.0 1.0 0.5 用户管理3.0 1.5 0.8 根底设置机构类型设置1.0 0.5 0.3 机构设置1.0 0.5
11、 0.3 币种设置1.0 0.5 0.3 银行类型设置1.0 0.5 0.3 账户用途设置1.5 0.8 0.4 账户扩展属性设置1.0 0.5 0.3 业务类型设置3.0 1.5 0.8 账户管理开户处理4.0 2.0 1.0 销户处理4.0 2.0 1.0 变更处理4.0 2.0 1.0 账号升级申请3.0 1.5 0.8 冻结与解冻3.0 1.5 0.8 账户信息查询2.0 1.0 0.5 资金清算支出资金申请5.0 2.5 1.3 归集资金申请5.0 2.5 1.3 资金划拨5.0 2.5 1.3 资金计划行项目设置2.0 1.0 0.5 编制计划2.0 1.0 0.5 审批计划2.0
12、 1.0 0.5 资金监控账户当日余额查询2.0 1.0 0.5 账户历史余额查询2.0 1.0 0.5 账户历史流水查询2.0 1.0 0.5 监控项设置5.0 2.5 1.3 监控报表和提醒3.0 1.5 0.8 银企接口银行指令查询5.0 2.5 1.3 银行指令维护5.0 2.5 1.3 自动归集策略设置5.0 2.5 1.3 交易核对5.0 2.5 1.3 审批流审批设置4.0 2.0 1.0 权限转移4.0 2.0 1.0 每轮合计工作量人日：97.5 48.8 24.4 用户手册5.0 验收测试12.0 手工测试合计工作量：按照4个测试资源计算，手工测试完成共需消耗187.6/4
13、46.9个工作日。与预定计划的48个工作日的测试周期接近。后期的测试工作占测试工作的45左右。指标数值估算测试工作量测试资源4人估算测试工作日计划测试工作日48日后期测试工作量比例(48.8+24.4+12)/187.6=45对手工测试的工作量估算没有考虑开发进度delay的因素。一旦开发进度delay，如此第3轮手工测试将无法完成，只能把优先级别较高的功能测试完成。开发进度delay的原因很大一局部来自需求变更。5.2. 引入自动化测试后工作量估算引入自动化测试工具后，手工测试的主要工作量将主要集中在第一轮测试，而自动化测试脚本也根据被测试功能和业务的复杂程度不同而不同。根据下表的统计数据，
14、在自动化测试中采用数据驱动的方式，投入产出比比拟适宜。结构本钱收益净收益No Automation000Recording and Playback11Data-driven structure using data pools18Framework structure15Framework / data-driven (hybrid) structure focusing on views of the application and using data pools197.4 窗体底端根据业内的统计数据，手工测试与自动化测试脚本编写的工作量比例约为3:7，在不考虑需求变更的情况下，测试脚本的维护工作量为建立脚本工作
