论基于QTP的金融软件自动化测试框架

1、基于QTPP的金融软件件自动化测测试框架何谓自动化化测试框架架呢？我认认为它就是是一个关于于自动化测测试总体设设计规划和和一个关于于设计细节节的规范，同同时我认为为自动化测测试框架至至少应该包包含下面三三个部分：测试工具使使用规范、业务功能能模块分解解、测试数数据分离与与管理。图1.自动动化测试框框架草图下面分别别对这三个个方面进行行简单的阐阐述，不只只针对回归归测试，大大家可以把把系统测试试也考虑进进去，希望望能起到抛抛砖引玉的的作用。我我呢，经验验不多参加加工作才一一年，可能能有些看法法比较偏颇颇或者错误，希希望大家不不吝指教。测试工具使使用规范先谈谈规范范化的必要要性(引用用来源511T

2、estting)脚本的生成成方式就两两种，一种种是自写脚脚本，一种种是录制生生成。脚本本不管录制制也好，还还是手写也也好，选择择的时候应应该以脚本本模拟程序序真实有效效为准，结结合项目进进度，开发发难易程度度等因素考考虑。而脚脚本的开发发也需要符符合一种规规范，也可可以说是一一种习惯，因因为脚本不不只是开发发者一个人人看，测试试执行人员员也需要看看，这就要要求可读性性和可维护护性提高；故而开发发时应该考考虑这层因因素，规范范一下。综合起来可可以得到以以下结论：手写可读性性好，流程程清晰，检检查点截取取含义明确确。业务级级的代码读读起来总比比协议级的的代码更易易让人理解解，手写可可能花费更更多时

3、间，但但是也更容容易维护，必必要时可建建立一个脚脚本库。而而录制生成成的代码大大多没有维维护的价值值，现炒现现卖。其次，业务务逻辑稍微微复杂一点点的系统单单凭录制是是不可能检检查到绝大大部分异常常的，只有有手工书写写的时候边边写边思考考可能会发发生哪些异异常，才能能使脚本更更具逻辑性性、完整性性和健壮性性，给业务务流程控制制提供一个个好的依据据。其次是如何何做，做些些什么规范范在做框架设设计定义的的时候，需需要定义好好代码规范范，如变量量名称定义义规则、注注释规则、变量声明明规范、循循环时间和和次数上限限、等待时时间的处理理方法、单单个Acttion和和脚本的大大小限制等等等，这些些都是同CC

4、/C+、JAVVA等程序序员写代码码的要求如如出一辙，规规范就是为为了方便统统一管理。工具应用规规范的制定定，如：对对象库管理理方式、关联的的驱动脚本本和批处理理、测试工工具的设置置（如Acctivee Scrreen，RRun mmode等等）、测试试结果存放放分析、数数据源管理理维护、场场景错误恢恢复和资源源、环境定定义等等。并不是所有有进行自动动化测试的的人员技术术和经验都都在一个层层次上，所所以在设计计框架的时时候需要对对于一些疑疑难或者可可能会出现现麻烦的地地方事先进进行说明或或者做出培培训计划。这是风险险规避的一一条途径。明确测试目目标，规定定对数据检查查的程度和和测试目的的，FA

5、TT、ST还还是UATT，否则在在UAT阶阶段仔细校校验数据，工工作量就非非常大了，当当然如果有有ST测试试的脚本基基础倒是也也不会花很很多工夫，只只是有些公公司用QTTP都是单单只做UAAT的。对象库集集中管理，为为同一系统统所有脚本本提供共享享库抑或不不共享，这这是8.22以前留下下的习惯，其其实在9.0、9.2来说也也是可以考考虑的。测试脚本存存储和运行行管理有时候，我我们没有（公公司没有提提供）QCC/TD来来管理我们们的自动化化测试（当当然其他的的自动化测测试管理工工具我也没没有见过、用过，就就以QC/TD为例例吧），而而有时候我我们拥有管管理工具却却缺少必要要的主策略略和网络协协议

6、（可能能会出现这这种情况吧吧），这就就导致了QQTP自动动化测试管管理的多样样性；当然然多数情况况下，用得得起QTPP的也是能能用得起QQC/TDD的，呵呵呵。有QC/TTD作为我我们的测试试脚本存储储和运行管管理（抛开开需求和缺缺陷管理不不说）的时时候，我们们的自动化化测试流程程管理显得得简单的多多。脚本编编写、存储储、测试实实验室业务务流程的建建立、测试试执行和结结果分析等等等。一般般情况下，这这些规则之之需要简单单的口述即即可，当然然一定需要要阐明的话话也是很简简单的，只只是需要结结合我们要要说的其他他几个部分分来叙述，这这里不再赘赘述。对于没有QQC/TDD的情况，可可能大家见见过很多

7、管管理方式，类如如FTP、共享磁盘盘等等；一一个共同的的要点就是是“共享”。如果一一个系统或或项目有多多个自动化化脚本设计计者协同工工作，而大大家各自为为战把脚本本存储在自自己的私人人空间里就就会产生很很不好的效效果。因为为整个系统统的测试被被割裂，很很多需要关关联的业务务流程就无无法组合，尤尤其对于金金融软件来来说，功能能测试也好好、回归测测试也好，这这样自动化化就成了一一个摆设：它无法覆覆盖很多的的关联性很很强的业务务流程。其其次，在本本地空间存存储有一个个潜在的安安全隐患，因因为可能由由于误操作作或者磁盘盘的损坏导导致一个月月的工作付付诸东流。而共享服服务目录和和FTP器器一般都是是相对

8、比较较稳定的。最后，本本地测试执执行要覆盖不不同的业务务流程一般般需要使用用一个驱动动脚本，由由它来指引引流程的走走向，负责责数据文件件的获取并并且完成测测试结果的的定点存放放。这个脚脚本一般可可能都比较较喜欢用VVBS吧（我我见到的都都是）。本地存储，QQC/TDD上执行是是行不通的的，想法也也很愚昧，呵呵呵；而在在QC/TTD上存储储、拿到本本地执行也也许是一种种变通的法法子，可以以解决局域域网网络协协议和安全全策略对QQC/TDD的封杀；但是在网网络协议和和安全策略略正常的情情况下，这这种方法也也是不可取取的，因为为这样远没没有QC/TD管理理起来方便便。非要这这么做的只只有一种可可能：

9、那就就是QC/TD只是是作为存储储工具，浪浪费啊，呵呵呵；坚持持这种做法法的大约会会是很老的的前辈了，因因为以往QQC/TDD和QTPP的功能没没有像现在在9.0、9.2这这么全面，要要求很高的的技术，这这些前辈在在这种条件件下练就一一身好技术术，有了技技术当然可可以和测试试管理工具具抗衡了，呵呵呵，不知知道怎么表表达，反正正没有笑话话的意思，表表见怪哈。其实无论使使用共享磁磁盘管理还还是使用QQC/TDD管理都是是可以的，只只是QC/TD提供供了一种比比较省事的的方法而已已，当然，代代价是昂贵贵的liccensee，在本地地运行管理理相对来说说需要更强强的技术和和更为细致致的规划设设计，二者

10、者效果是一一样的。业务功能模模块划分熟悉一个应应用系统的的业务流程程是非常关关键的，因这为为不仅在方方法上给我我们带来很很大的便利利，而且从从根本上将将，我们做做自动化（回回归）测试试，多数都都是为了某某些个系统统核心业务务的完整性性和正确性性作保证，这这当然要求求我们精通通“业务”。明确一一个较为庞庞大的业务务系统的业业务流程不不是件容易易的事情，在在多数情况况下需要将将精通的业业务的同事事拉进来参参与我们的的流程制定定、选取和和覆盖设计计。对业务务模块的精精确划分是是我们完成成一份高效效的自动化化测试的良良好基础，否否则，我们们的自动化化可能为杂杂乱无章，甚甚至徒劳无无功。那么业务模模块划

11、分的的准则和依依据到底是是什么呢？不同的系系统有着不不同的标准准，下面饮饮用一个案案例对金融融系统做个个粗略的介介绍。对金融系统统来说，我我们进行业业务分解和和设计业务务流程的时时候需要做做如下要求求：较为模块化化的设计，避避免重复的的脚本，减减少建立或或维护脚本本的成本。 在应用软件件开发的同同时，就可可以同步进进行脚本建建立的动作作，而且当当应用软件件功能变动动时，只需需要修改业业务功能脚脚本。 由于应用软软件的功能能已经被分分解成独立立的业务功功能脚本，测测试人员可可以随意组组合业务功功能脚本成成为更复杂杂多样的测测试个案。 测试输入数数据与验证证数据与脚脚本分开，储储存在另外外的档案，

12、如如纯文字文文件或 EExcell 文件，测测试人员可可以更容易易修改与维维护。 加强错误处处理合结果果分析判断断，让脚本本更有弹性性。 当然这样做做也会带来来一定的额额外开销，但但是这些都都是必须的的，自动化化本身就是是需要结合合良好的管管理以牺牲牲人力成本本来赢得时时间的，针针对一些缺缺点我做一一下简单的的注释：在编写业务务功能脚本本时，需要要精通测试工具具脚本语言言的工程师师：其实很很多公司都都有实力寻寻找这样的的人，因为为VBS本本身相对比比较简单，虽虽然自动化化测试还没没有在整个个中国全面面兴起，但但是有着丰丰富自动化化测试经验验的测试人人员已经非非常多了。每个Acttion都都会有

13、自己己的输入输输出参数，需需要用文档档统一维护护，控制变变更：这的的确增加了了一些工作作量，但是是对测试本本身的规范范来说，是是一大进步步。测试人员除除了要维护护测试计划划之外，还还要另外维维护数据文文件：同上上。对测试工具具以及脚本本语言来说说，使用数数据文件可可能也要注注意数据文文件的格式式。 这个分解结结果来自551Tesstingg上的一位位同仁，我我在做完兴兴业银行自自动化之后后做总结的的时候无意意发现了这这段话，猿猿粪哪！与与我的想法法不谋而和和，呵呵，所所以当时就就Copyy下来了，并并非有意剽剽窃，如果果侵犯了这这位仁兄，敬敬请原谅！这里修改改了一些地地方，我觉觉得这是金金融尤

14、其是是银行业务务分解的一一个经典，也也算是一个个不大不小小的标准吧吧，可能并并不能适用用于所有系系统，但是是对银行来来说，还是是很实用的的。下面以兴业业银行交易易处理中心心项目自动动化测试为为例，看看看这份业务务分解和脚脚本规范会会带来什么么样的效果果。（注：附件文档档乃非正式式发布文档档，系个人人私有，不不牵涉兴业业银行商业业秘密，诸位位放心！）系统说明：前台Telller（银银行柜员操操作界面）、电子验印印系统（印印章校验）、Inteegrattor（信信息管道）、工作流系系统（IBBM的FiileNeet）、后后台交易集集中处理系系统（中间间业务平台台）、核心心（联想亚亚信的FTTS）等

15、。考虑金融融系统的安安全性，所所有交易流流程的处理理采用独占占的方式，后后台界面交交易处理按按交易优先先级次、时时间先后进进行，同等等条件下FFileNNet随机机分配，所所以自动化的的难度相当当的大。交交易功能分分解按照操操作员岗位位职责划分分为前台柜柜员，CPPC（中间间业务平台台）的录入入岗、审核核岗、报文文审核岗、异常处理理岗、监控控岗等部分分。实际应用：这样的框架架设计会带带来什么结结果呢？我我们来计算算一下：前台发起的的交易大约约有60多多个，每个个交易的典典型业务覆覆盖需要大大约20个个流程，这这样共计11200个个测试流程程；每个测试流流程除去操操作员登陆陆、签退之之后大约有有

16、10个脚脚本，这样样如果没有有采取公用用的话，每每个健全的的脚本应该该在2000行左右，不不计算重复复的测试流流程，总的的脚本的行行数应该是是：10*200*60=11200000行； 但是采用了了子模块的的公用，我我们完整地地写了不到到300个个脚本（其其中包含近近百个100行以内的的登陆、登登出脚本），平平均每个脚脚本只有不不到1000行，并且且通文件系系统操作覆覆盖了所有有的流程，即即：3000*1000=300000行；这样可以清清楚地看到到，同样覆覆盖了12200个流流程，我们们节省了775%的脚脚本行数，减减轻至少550%的工工作量（考考虑技术问问题甚至880%），为为QC/TTD

17、服务器器也减轻了了75%的的存储压力力，虽然在在技术上带带来一定难难度，但是是也没有产产生多大的的影响。如果在没有有外界压力力的情况下下，这种框框架设计是是非常有效效的。很明明显，稍微微加大一些些技术层面面的工作量量会给我们们带来很大大的好处：减少30%到50%甚至更多多的脚本编编写的工作作量，系统统越大，有有点越明显显。后期维护难难度和工作作量在同一一的管理下下大幅度下下降。减轻了测试试管理服务务器的存储储压力，对对于QC/TD和QQTP的llicennse不多多的企业和和单位来说说，统一协协调运行、管理可以以很大程度度上减少由由于liccensee有限带来来的时效性性不高的问问题。刚才提到

18、外外界压力，什什么是外界界压力：我我是你老大大，我让你你写10000个脚本本你就不能能偷懒写9900数据分离和和数据管理理规范使用测测试工具、规范开发发脚本也许许需要考虑虑的不是很很多，业务务分解也可可以获取大大量的支持持，但是相相对这二者者来说，数数据分离和和数据管理理就需要综综合考虑了了。对于类类似银行、保险、证证券、信托托等金融业业务系统来来说，数据据量要求比比较大而且且对其准确确性有着很很高的要求求，所以实实现数据分分离、管理理就成了这这个框架中中最重要的的一个点了了。自动化测试试中有一个个很鲜明的的概念叫“数据驱动动”，事实上上就是利用用数据控制制业务流程程的走向，这这是同前面面提到

19、的驱驱动脚本意意思是相同同的，只不不过这儿说说的数据是是完全剥离离开的，从从脚本中独独立出来了了。做到数数据驱动不不是很简单单的事情，因因为这些金金融业务系系统的业务务逻辑是非非常复杂的的，凡是接接触过这些些业务的核核心系统的的朋友可能能都有这个个体会。为为了完成数数据驱动，我我们必须熟熟知每一个个我们要测测试的业务务节点的功功能，这比比性能测试试对业务流流程的掌握握要高一些些，同时还还要掌握数数据库相关关的表结构构，当然其其中最麻烦烦的就数表表的关联性性了。熟悉悉了系统的的需求、设设计、数据据库表结构构，听起来来可能有点点危言耸听听，但是考考虑到将来来的使用，系系统的不断断升级，我我们花一些

20、些功夫还是是值得的；一个上线线了的核心心业务系统统一般不会会在一两年年之内就淘淘汰的，金金融业务的的日新月异异其实并不不影响我们们自动化测测试的流程程，一系列列的升级和和数据集中中会体现出出我们高质质量脚本的的价值所在在。举例来来说，*保险险公司一个个养老险业业务系统，无无论业务需需求怎么逐逐步更改，系系统始终都都会稳固的的摆在那儿儿；因为不不到实在非非废弃不可可的程度，谁谁愿意花费费巨大的代代价重新去去做一个新新的系统呢呢？为了保保证对公众众业务的连连贯性，一一个系统始始终会以改改造升级的的方式去运运作。说这些无非非就是想告告诉大家，做做一个优秀秀的自动化化个案，尤尤其在金融融这个行业业里，

21、是值值得的，绝绝对不会让让我们觉得得浪费了太太多精力而而没有实现现他的价值值。在外包包公司，可可以将这部部分作为服服务和系统统开发成果果的一部分分移交到“甲方”；而在“甲方”，这些东东西就可以以直接应用用于自己的的运营测试试。据我所所知，很多多公司在持持续集成的的时候配合合LR、JJUNITT等工具也也使用了QQUICKKTESTT PROOFESSSIONAAL，大频频率的集成成对我们的的脚本的要要求也是非非常高的，如如果做不好好就会阻碍碍这部分工工作。不花功夫去去研究这些些业务功能能和数据逻逻辑会还有有什么不利利呢？从开篇的结结果草图可可以看到，我我将测试数数据分为两两部分：动动态部分和和

22、静态部分分。静态数数据是哪些些呢：审核核意见、客客户地址这些信信息在Sttaginng环境里里是无关紧紧要的，后后台不会进进行校验，也也不会影响响到我们业业务流程的的走向，所所以我们一一般采用一一些随机函函数将其带带过，还可可以很大程程度的上保保证数据的的唯一性。若是某个个模块不进进行任何校校验，或者者只有查询询之类的功功能，抑或或是一个不不关紧要外外围（非核核心）系统统，我们大大可以使用用MI（HHP）跟我我们说的那那样Reccordiing、RReplaayingg。但是这样的的情况在金金融业务系系统里还是是不占多数数的。为什什么我们不不能使用固固定那一条条或几条数数据进行我我们的测试试呢

23、，道理理很简单：几个数列的的前几项、十几项规规律看起来来一样但是是后面各是是什么样谁谁能说得准准呢？这么么几条数据据校验过去去的系统拿拿到生产线线上会不会会出什么事事故谁也不不敢保证。我们在力力所能及的的范围内尽尽可能减少少这些事故故发生的可可能性就是是我们的责责任，也可可以上升到到职业道德德上面去，吓吓死人咧吧吧！缺陷的修改改往往会使使用发现错错误的那几几条数据进进行校验，或或者就是针针对这几条条数据修改改了，怎么么办？如果果还是用这这么几条数数据来验证证，系统肯肯定还是好好的；但是是换几条数数据可能就就不是那么么回事了。我这儿不不是诋毁编编码的蝈蝈蝈们，这种种情况我的的确碰到过过好几次，呵

24、呵呵。有些人在某某些地方喜喜欢将用过过的数据UUPDATTE回头，下下次运行时时继续使用用（我在做做性能测试试的时候就就喜欢这样样，嘿嘿）。其实这样样做也是有有一定的风风险的，因因为复杂的的关联性会会让你不小小心漏掉某某张表或者者某个字段段，这样在在运行的时时候要么运运行良好却却发现不了了存在的缺缺陷，要么么就出一些些莫名其妙妙的问题让让你花费很很多的时间间去排查。那么多的的触发器，谁谁能保证面面面俱到呢呢？当然有有时为了进进行复杂的的操作我们们必须去写写一些PROCEEDUREE、PACCKAGEE和JOBB来配合我我们的测试试；有些人人喜欢在脚脚本里直接接调用这些些过程或包包，有些人人喜欢用JJOB与脚脚本并行操操作。我属属于后者，我我觉得在测测试脚本里里执行浪费费时间，但但是并行可可能会出现现LOCKK，需要计计算时间耦耦合。这都都是个人习习惯问题，有有问题大家家可以评论论哈。说了半天讲讲的都是数数据分离的的必要性，到到底怎么做做呢？有没没有一个简简单的方法法或者例子子呢？莫急急，听我慢慢慢摆。我使用QTTP第一个个月（学习习阶段），傻傻乎乎的就就把数据固固定或者简简单地参数数化一下以以显示我会会这个功能能，接下来来我觉得这这样对流程程性的测试试很不利，于于是就把数数据写到本本地