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

基于QTP的金金融软件自动动化测试框架架何谓自动化测试试框架呢？我我认为它就是是一个关于自自动化测试总总体设计规划划和一个关于于设计细节的的规范，同时时我认为自动动化测试框架架至少应该包包含下面三个个部分：测试工具使用规规范、业务功功能模块分解解、测试数据据分离与管理理。图1.自动化测测试框架草图图下面分别对这这三个方面进进行简单的阐阐述，不只针针对回归测试试，大家可以以把系统测试试也考虑进去去，希望能起起到抛砖引玉玉的作用。我我呢，经验不不多参加工作作才一年，可可能有些看法法比较偏颇或或者错误，希望望大家不吝指指教。Ø 测试工具使用规规范¨ 先谈谈规范化的的必要性(引引用来源511Testiing)脚本的生成方式式就两种，一一种是自写脚脚本，一种是是录制生成。脚脚本不管录制制也好，还是是手写也好，选选择的时候应应该以脚本模模拟程序真实实有效为准，结结合项目进度度，开发难易易程度等因素素考虑。而脚脚本的开发也也需要符合一一种规范，也也可以说是一一种习惯，因因为脚本不只只是开发者一一个人看，测测试执行人员员也需要看，这这就要求可读读性和可维护护性提高；故故而开发时应应该考虑这层层因素，规范范一下。综合起来可以得得到以下结论论：1. 手写可读性好，流流程清晰，检检查点截取含含义明确。业业务级的代码读读起来总比协协议级的代码码更易让人理理解，手写可可能花费更多多时间，但是是也更容易维维护，必要时时可建立一个个脚本库。而而录制生成的的代码大多没没有维护的价价值，现炒现现卖。2. 其次，业务逻辑辑稍微复杂一一点的系统单单凭录制是不不可能检查到到绝大部分异异常的，只有有手工书写的的时候边写边边思考可能会会发生哪些异异常，才能使使脚本更具逻逻辑性、完整整性和健壮性性，给业务流流程控制提供供一个好的依依据。¨ 其次是如何做，做做些什么规范范1. 在做框架设计定定义的时候，需需要定义好代代码规范，如如变量名称定定义规则、注注释规则、变变量声明规范范、循环时间间和次数上限限、等待时间间的处理方法法、单个Acction和和脚本的大小小限制等等，这这些都是同CC/C+、JJAVA等程程序员写代码码的要求如出出一辙，规范范就是为了方方便统一管理理。2. 工具应用规范的的制定，如：对象库管理理方式、关联的驱驱动脚本和批批处理、测试试工具的设置置（如Acttive SScreenn，Run mode等等）、测试结结果存放分析析、数据源管管理维护、场场景错误恢复复和资源、环环境定义等等等。3. 并不是所有进行行自动化测试试的人员技术术和经验都在在一个层次上上，所以在设设计框架的时时候需要对于于一些疑难或或者可能会出出现麻烦的地地方事先进行行说明或者做做出培训计划划。这是风险险规避的一条条途径。4. 明确测试目标，规规定对数据检查的的程度和测试试目的，FAAT、ST还还是UAT，否否则在UATT阶段仔细校校验数据，工工作量就非常常大了，当然然如果有STT测试的脚本本基础倒是也也不会花很多多工夫，只是是有些公司用用QTP都是是单只做UAAT的。对象库集中管管理，为同一一系统所有脚脚本提供共享享库抑或不共共享，这是88.2以前留留下的习惯，其其实在9.00、9.2来来说也是可以以考虑的。¨ 测试脚本存储和和运行管理有时候，我们没没有（公司没没有提供）QQC/TD来来管理我们的的自动化测试试（当然其他他的自动化测测试管理工具具我也没有见见过、用过，就就以QC/TTD为例吧），而而有时候我们们拥有管理工工具却缺少必必要的主策略和和网络协议（可可能会出现这这种情况吧），这这就导致了QQTP自动化化测试管理的的多样性；当当然多数情况况下，用得起起QTP的也也是能用得起起QC/TDD的，呵呵。1. 有QC/TD作作为我们的测测试脚本存储储和运行管理理（抛开需求求和缺陷管理理不说）的时时候，我们的的自动化测试试流程管理显显得简单的多多。脚本编写写、存储、测测试实验室业业务流程的建建立、测试执执行和结果分分析等等。一一般情况下，这这些规则之需需要简单的口口述即可，当当然一定需要要阐明的话也也是很简单的的，只是需要要结合我们要要说的其他几几个部分来叙叙述，这里不不再赘述。2. 对于没有QC/TD的情况况，可能大家家见过很多管管理方式，类如FFTP、共享享磁盘等等；一个共同的的要点就是“共享”。如果一个个系统或项目目有多个自动动化脚本设计计者协同工作作，而大家各各自为战把脚脚本存储在自自己的私人空空间里就会产产生很不好的的效果。因为为整个系统的的测试被割裂裂，很多需要要关联的业务务流程就无法法组合，尤其其对于金融软软件来说，功功能测试也好好、回归测试试也好，这样样自动化就成成了一个摆设设：它无法覆覆盖很多的关关联性很强的的业务流程。其其次，在本地地空间存储有有一个潜在的的安全隐患，因因为可能由于于误操作或者者磁盘的损坏坏导致一个月月的工作付诸诸东流。而共共享服务目录录和FTP器器一般都是相相对比较稳定定的。最后，本本地测试执行行要覆盖不同同的业务流程程一般需要使使用一个驱动动脚本，由它它来指引流程程的走向，负负责数据文件件的获取并且且完成测试结结果的定点存存放。这个脚脚本一般可能能都比较喜欢欢用VBS吧吧（我见到的的都是）。3. 本地存储，QCC/TD上执执行是行不通通的，想法也也很愚昧，呵呵呵；而在QQC/TD上上存储、拿到到本地执行也也许是一种变变通的法子，可可以解决局域域网网络协议议和安全策略略对QC/TTD的封杀；但是在网络络协议和安全全策略正常的的情况下，这这种方法也是是不可取的，因因为这样远没没有QC/TTD管理起来来方便。非要要这么做的只只有一种可能能：那就是QQC/TD只只是作为存储储工具，浪费费啊，呵呵；坚持这种做法的的大约会是很很老的前辈了了，因为以往往QC/TDD和QTP的的功能没有像像现在9.00、9.2这这么全面，要要求很高的技技术，这些前前辈在这种条条件下练就一一身好技术，有有了技术当然然可以和测试试管理工具抗抗衡了，呵呵呵，不知道怎怎么表达，反反正没有笑话话的意思，表表见怪哈。其实无论使用共共享磁盘管理理还是使用QQC/TD管管理都是可以以的，只是QQC/TD提提供了一种比比较省事的方方法而已，当当然，代价是是昂贵的liicensee，在本地运运行管理相对对来说需要更更强的技术和和更为细致的的规划设计，二二者效果是一一样的。Ø 业务功能模块划划分熟悉一个应用系系统的业务流流程是非常关关键的，因这为不不仅在方法上上给我们带来来很大的便利利，而且从根根本上将，我我们做自动化化（回归）测测试，多数都都是为了某些些个系统核心心业务的完整整性和正确性性作保证，这这当然要求我我们精通“业务”。明确一个个较为庞大的的业务系统的的业务流程不不是件容易的的事情，在多多数情况下需需要将精通的的业务的同事事拉进来参与与我们的流程程制定、选取取和覆盖设计计。对业务模模块的精确划划分是我们完完成一份高效效的自动化测测试的良好基基础，否则，我我们的自动化化可能为杂乱乱无章，甚至至徒劳无功。那么业务模块划划分的准则和和依据到底是是什么呢？不不同的系统有有着不同的标标准，下面饮饮用一个案例例对金融系统统做个粗略的的介绍。对金融系统来说说，我们进行行业务分解和和设计业务流流程的时候需需要做如下要要求：1. 较为模块化的设设计，避免重重复的脚本，减减少建立或维维护脚本的成成本。 2. 在应用软件开发发的同时，就就可以同步进进行脚本建立立的动作，而而且当应用软软件功能变动动时，只需要要修改业务功功能脚本。 3. 由于应用软件的的功能已经被被分解成独立立的业务功能能脚本，测试试人员可以随随意组合业务务功能脚本成成为更复杂多多样的测试个个案。 4. 测试输入数据与与验证数据与与脚本分开，储储存在另外的的档案，如纯纯文字文件或或 Exceel 文件，测测试人员可以以更容易修改改与维护。 5. 加强错误处理合合结果分析判判断，让脚本本更有弹性。 当然这样做也会会带来一定的的额外开销，但但是这些都是是必须的，自自动化本身就就是需要结合合良好的管理理以牺牲人力力成本来赢得得时间的，针针对一些缺点点我做一下简简单的注释：1. 在编写业务功能能脚本时，需需要精通测试工具脚脚本语言的工工程师：其实实很多公司都都有实力寻找找这样的人，因因为VBS本本身相对比较较简单，虽然然自动化测试试还没有在整整个中国全面面兴起，但是是有着丰富自自动化测试经经验的测试人人员已经非常常多了。2. 每个Actioon都会有自自己的输入输输出参数，需需要用文档统统一维护，控控制变更：这这的确增加了了一些工作量量，但是对测测试本身的规规范来说，是是一大进步。3. 测试人员除了要要维护测试计计划之外，还还要另外维护护数据文件：同上。4. 对测试工具以及及脚本语言来来说，使用数数据文件可能能也要注意数数据文件的格格式。 这个分解结果来来自51Teestingg上的一位同同仁，我在做做完兴业银行行自动化之后后做总结的时时候无意发现现了这段话，猿猿粪哪！与我我的想法不谋谋而和，呵呵呵，所以当时时就Copyy下来了，并并非有意剽窃窃，如果侵犯犯了这位仁兄兄，敬请原谅谅！这里修改改了一些地方方，我觉得这这是金融尤其其是银行业务务分解的一个个经典，也算算是一个不大大不小的标准准吧，可能并并不能适用于于所有系统，但但是对银行来来说，还是很很实用的。下面以兴业银行行交易处理中心心项目自动化化测试为例，看看看这份业务务分解和脚本本规范会带来来什么样的效效果。（注：附件文档乃乃非正式发布布文档，系个个人私有，不不牵涉兴业银银行商业秘密密，诸位放心心！）系统说明：前台Telleer（银行柜柜员操作界面面）、电子验验印系统（印印章校验）、IIntegrrator（信信息管道）、工工作流系统（IIBM的FiileNett）、后台交交易集中处理理系统（中间间业务平台）、核核心（联想亚亚信的FTSS）等。考虑虑金融系统的的安全性，所所有交易流程程的处理采用用独占的方式式，后台界面面交易处理按按交易优先级级次、时间先先后进行，同同等条件下FFileNeet随机分配配，所以自动化的难难度相当的大大。交易功能能分解按照操操作员岗位职职责划分为前前台柜员，CCPC（中间间业务平台）的的录入岗、审审核岗、报文文审核岗、异异常处理岗、监监控岗等部分分。实际应用：这样的框架设计计会带来什么么结果呢？我我们来计算一一下：1. 前台发起的交易易大约有600多个，每个个交易的典型型业务覆盖需需要大约200个流程，这这样共计12200个测试试流程；2. 每个测试流程除除去操作员登登陆、签退之之后大约有110个脚本，这这样如果没有有采取公用的的话，每个健健全的脚本应应该在2000行左右，不不计算重复的的测试流程，总总的脚本的行行数应该是：10*2000*60=1200000行； 3. 但是采用了子模模块的公用，我我们完整地写写了不到3000个脚本（其其中包含近百百个10行以以内的登陆、登登出脚本），平平均每个脚本本只有不到1100行，并并且通文件系系统操作覆盖盖了所有的流流程，即：3300*1000=300000行；4. 这样可以清楚地地看到，同样样覆盖了12200个流程程，我们节省省了75%的的脚本行数，减减轻至少500%的工作量量（考虑技术术问题甚至880%），为为QC/TDD服务器也减减轻了75%的存储压力力，虽然在技技术上带来一一定难度，但但是也没有产产生多大的影影响。如果在没有外界界压力的情况况下，这种框框架设计是非非常有效的。很很明显，稍微微加大一些技技术层面的工工作量会给我我们带来很大大的好处：1. 减少30%到550%甚至更更多的脚本编编写的工作量量，系统越大大，有点越明明显。2. 后期维护难度和和工作量在同同一的管理下下大幅度下降降。3. 减轻了测试管理理服务器的存存储压力，对对于QC/TTD和QTPP的liceense不多多的企业和单单位来说，统统一协调运行行、管理可以以很大程度上上减少由于llicensse有限带来来的时效性不不高的问题。刚才提到外界压压力，什么是是外界压力：我是你老大大，我让你写写1000个个脚本你就不不能偷懒写9900Ø 数据分离和数据据管理规范使用测试工工具、规范开开发脚本也许许需要考虑的的不是很多，业业务分解也可可以获取大量量的支持，但但是相对这二二者来说，数数据分离和数数据管理就需需要综合考虑虑了。对于类类似银行、保保险、证券、信信托等金融业业务系统来说说，数据量要要求比较大而而且对其准确确性有着很高高的要求，所所以实现数据据分离、管理理就成了这个个框架中最重重要的一个点点了。自动化测试中有有一个很鲜明明的概念叫“数据驱动”，事实上就就是利用数据据控制业务流流程的走向，这这是同前面提提到的驱动脚脚本意思是相相同的，只不不过这儿说的的数据是完全全剥离开的，从从脚本中独立立出来了。做做到数据驱动动不是很简单单的事情，因因为这些金融融业务系统的的业务逻辑是是非常复杂的的，凡是接触触过这些业务务的核心系统统的朋友可能能都有这个体体会。为了完完成数据驱动动，我们必须须熟知每一个个我们要测试试的业务节点点的功能，这这比性能测试试对业务流程程的掌握要高高一些，同时时还要掌握数数据库相关的的表结构，当当然其中最麻麻烦的就数表表的关联性了了。熟悉了系系统的需求、设设计、数据库库表结构，听听起来可能有有点危言耸听听，但是考虑虑到将来的使使用，系统的的不断升级，我我们花一些功功夫还是值得得的；一个上上线了的核心心业务系统一一般不会在一一两年之内就就淘汰的，金金融业务的日日新月异其实实并不影响我我们自动化测测试的流程，一一系列的升级级和数据集中中会体现出我我们高质量脚脚本的价值所所在。举例来来说，*保险公司司一个养老险险业务系统，无无论业务需求求怎么逐步更更改，系统始始终都会稳固固的摆在那儿儿；因为不到到实在非废弃弃不可的程度度，谁愿意花花费巨大的代代价重新去做做一个新的系系统呢？为了了保证对公众众业务的连贯贯性，一个系系统始终会以以改造升级的的方式去运作作。说这些无非就是是想告诉大家家，做一个优优秀的自动化化个案，尤其其在金融这个个行业里，是是值得的，绝绝对不会让我我们觉得浪费费了太多精力力而没有实现现他的价值。在在外包公司，可可以将这部分分作为服务和和系统开发成成果的一部分分移交到“甲方”；而在“甲方”，这些东西西就可以直接接应用于自己己的运营测试试。据我所知知，很多公司司在持续集成成的时候配合合LR、JUUNIT等工工具也使用了了QUICKKTEST PROFEESSIONNAL，大频频率的集成对对我们的脚本本的要求也是是非常高的，如如果做不好就就会阻碍这部部分工作。不花功夫去研究究这些业务功功能和数据逻逻辑会还有什什么不利呢？从开篇的结果草草图可以看到到，我将测试试数据分为两两部分：动态态部分和静态态部分。静态态数据是哪些些呢：审核意意见、客户地地址这些信息息在Stagging环境境里是无关紧紧要的，后台台不会进行校校验，也不会会影响到我们们业务流程的的走向，所以以我们一般采采用一些随机机函数将其带带过，还可以以很大程度的的上保证数据据的唯一性。若若是某个模块块不进行任何何校验，或者者只有查询之之类的功能，抑抑或是一个不不关紧要外围围（非核心）系系统，我们大大可以使用MMI（HP）跟跟我们说的那那样Recoordingg、Repllayingg。但是这样的情况况在金融业务务系统里还是是不占多数的的。为什么我我们不能使用用固定那一条条或几条数据据进行我们的的测试呢，道道理很简单：1. 几个数列的前几几项、十几项项规律看起来来一样但是后后面各是什么么样谁能说得得准呢？这么么几条数据校校验过去的系系统拿到生产产线上会不会会出什么事故故谁也不敢保保证。我们在在力所能及的的范围内尽可可能减少这些些事故发生的的可能性就是是我们的责任任，也可以上上升到职业道道德上面去，吓吓死人咧吧！2. 缺陷的修改往往往会使用发现现错误的那几几条数据进行行校验，或者者就是针对这这几条数据修修改了，怎么么办？如果还还是用这么几几条数据来验验证，系统肯肯定还是好的的；但是换几几条数据可能能就不是那么么回事了。我我这儿不是诋诋毁编码的蝈蝈蝈们，这种种情况我的确确碰到过好几几次，呵呵。3. 有些人在某些地地方喜欢将用用过的数据UUPDATEE回头，下次次运行时继续续使用（我在在做性能测试试的时候就喜喜欢这样，嘿嘿嘿）。其实实这样做也是是有一定的风风险的，因为为复杂的关联联性会让你不不小心漏掉某某张表或者某某个字段，这这样在运行的的时候要么运运行良好却发发现不了存在在的缺陷，要要么就出一些些莫名其妙的的问题让你花花费很多的时时间去排查。那那么多的触发发器，谁能保保证面面俱到到呢？当然有有时为了进行行复杂的操作作我们必须去去写一些PROCEDDURE、PPACKAGGE和JOBB来配合我们们的测试；有有些人喜欢在在脚本里直接接调用这些过过程或包，有有些人喜欢用用JOB与脚脚本并行操作作。我属于后后者，我觉得得在测试脚本本里执行浪费费时间，但是是并行可能会会出现LOCCK，需要计计算时间耦合合。这都是个个人习惯问题题，有问题大大家可以评论论哈。说了半天讲的都都是数据分离离的必要性，到到底怎么做呢呢？有没有一一个简单的方方法或者例子子呢？莫急，听听我慢慢摆。我使用QTP第第一个月（学学习阶段），傻傻乎乎的就把把数据固定或或者简单地参参数化一下以以显示我会这这个功能，接接下来我觉得得这样对流程程性的测试很很不利，于是是就把数据写写到本地本文文文件里，作作为参数传递递的方法。后后来就考虑使使用数据库，建建立本地数据据源，直接向向数据库伸手手了_，只只是一下子就就抛弃了EXXCEL和TTXT文件；过了很久才才明白过来，本本地文本可以以抛弃，但是是不抛弃却另另有好处。图2. 测试数数据使用流程如图所示，从数数据库中获取取测试数据的的同时在本地地文件里驻留留一份，运行行测试之后无无论数据变成成什么样我们们都可以知道道操作之前是是什么一个状状态。这为我我们在结果分分析的时候提提供了很大的的便捷，不用用再苦恼于查查看数据库修修改记录有多多么麻烦。在在我们使用我我们需要的数数据链接的同同时，我们必必须对它们进进行定期维护护。业务逻辑辑稍微变动，我我们的SQLL语句就需要要调整修改，数数据库迁移的的时候我们需需要及时更新新连接串。这这部分工作量量并不是很大大，但却比较较重要，我们们需要在第一一时间获取所所有的变更信信息，以确保保我们的测试试运行能够顺顺利、有效的的进行。否则则很可能为了了一些很小的的细节动用大大批人员排查查故障，到头头来却发现是是沟通出了问问题讲完我对这个个框架的认识识，想必有些些赞许（我不不脸红），有有些不屑（也也不心灰），但但是我希望大大家能够真诚诚的交流。虽虽然在以前做做测试的技术术含量没有写写代码高（其其实我们也在在写），但是是我们爱岗敬敬业，当然要要把测试做出出点声色来。最最后悄悄告诉诉大家一个小小秘密，我的的理想不是写写Chineese操作系系统，而是有有朝一日能亲亲自参与设计计、开发一个个集QTP、LLR、WR三三者优点于一一身的测试工工具（必须国国产，嘿嘿），抢抢HP生意，哈哈哈。我的联联系方式如下下：公司电话：0021-3886369774私人电话：11368166951200我的球球：55312899880主要邮箱： 公司邮箱： (只能收不不能发)个人主页：（与与工作无关）