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

《论基于QTP的金融软件自动化测试框架.docx》由会员分享，可在线阅读，更多相关《论基于QTP的金融软件自动化测试框架.docx（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

2、择的时候应该以脚本模拟程序真实有效为准，结合项目进度，开发难易程度等因素考虑。而脚本的开发也需要符合一种规范，也可以说是一种习惯，因为脚本不只是开发者一个人看，测试执行人员也需要看，这就要求可读性和可维护性提高；故而开发时应该考虑这层因素，规范一下。综合起来可以得到以下结论：1. 手写可读性好，流程清晰，检查点截取含义明确。业务级的代码读起来总比协议级的代码更易让人理解，手写可能花费更多时间，但是也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有维护的价值，现炒现卖。2. 其次，业务逻辑稍微复杂一点的系统单凭录制是不可能检查到绝大部分异常的，只有手工书写的时候边写边思考可能会发生哪

3、些异常，才能使脚本更具逻辑性、完整性和健壮性，给业务流程控制提供一个好的依据。 其次是如何做，做些什么规范1. 在做框架设计定义的时候，需要定义好代码规范，如变量名称定义规则、注释规则、变量声明规范、循环时间和次数上限、等待时间的处理方法、单个Action和脚本的大小限制等等，这些都是同C/C+、JAVA等程序员写代码的要求如出一辙，规范就是为了方便统一管理。2. 工具应用规范的制定，如：对象库管理方式、关联的驱动脚本和批处理、测试工具的设置（如Active Screen，Run mode等）、测试结果存放分析、数据源管理维护、场景错误恢复和资源、环境定义等等。3. 并不是所有进行自动化测试的

4、人员技术和经验都在一个层次上，所以在设计框架的时候需要对于一些疑难或者可能会出现麻烦的地方事先进行说明或者做出培训计划。这是风险规避的一条途径。4. 明确测试目标，规定对数据检查的程度和测试目的，FAT、ST还是UAT，否则在UAT阶段仔细校验数据，工作量就非常大了，当然如果有ST测试的脚本基础倒是也不会花很多工夫，只是有些公司用QTP都是单只做UAT的。对象库集中管理，为同一系统所有脚本提供共享库抑或不共享，这是8.2以前留下的习惯，其实在9.0、9.2来说也是可以考虑的。 测试脚本存储和运行管理有时候，我们没有（公司没有提供）QC/TD来管理我们的自动化测试（当然其他的自动化测试管理工具我

5、也没有见过、用过，就以QC/TD为例吧），而有时候我们拥有管理工具却缺少必要的主策略和网络协议（可能会出现这种情况吧），这就导致了QTP自动化测试管理的多样性；当然多数情况下，用得起QTP的也是能用得起QC/TD的，呵呵。1. 有QC/TD作为我们的测试脚本存储和运行管理（抛开需求和缺陷管理不说）的时候，我们的自动化测试流程管理显得简单的多。脚本编写、存储、测试实验室业务流程的建立、测试执行和结果分析等等。一般情况下，这些规则之需要简单的口述即可，当然一定需要阐明的话也是很简单的，只是需要结合我们要说的其他几个部分来叙述，这里不再赘述。2. 对于没有QC/TD的情况，可能大家见过很多管理方式，

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

7、成测试结果的定点存放。这个脚本一般可能都比较喜欢用VBS吧（我见到的都是）。3. 本地存储，QC/TD上执行是行不通的，想法也很愚昧，呵呵；而在QC/TD上存储、拿到本地执行也许是一种变通的法子，可以解决局域网网络协议和安全策略对QC/TD的封杀；但是在网络协议和安全策略正常的情况下，这种方法也是不可取的，因为这样远没有QC/TD管理起来方便。非要这么做的只有一种可能：那就是QC/TD只是作为存储工具，浪费啊，呵呵；坚持这种做法的大约会是很老的前辈了，因为以往QC/TD和QTP的功能没有像现在9.0、9.2这么全面，要求很高的技术，这些前辈在这种条件下练就一身好技术，有了技术当然可以和测试管理

8、工具抗衡了，呵呵，不知道怎么表达，反正没有笑话的意思，表见怪哈。其实无论使用共享磁盘管理还是使用QC/TD管理都是可以的，只是QC/TD提供了一种比较省事的方法而已，当然，代价是昂贵的license，在本地运行管理相对来说需要更强的技术和更为细致的规划设计，二者效果是一样的。 业务功能模块划分熟悉一个应用系统的业务流程是非常关键的，因这为不仅在方法上给我们带来很大的便利，而且从根本上将，我们做自动化（回归）测试，多数都是为了某些个系统核心业务的完整性和正确性作保证，这当然要求我们精通“业务”。明确一个较为庞大的业务系统的业务流程不是件容易的事情，在多数情况下需要将精通的业务的同事拉进来参与我们

9、的流程制定、选取和覆盖设计。对业务模块的精确划分是我们完成一份高效的自动化测试的良好基础，否则，我们的自动化可能为杂乱无章，甚至徒劳无功。那么业务模块划分的准则和依据到底是什么呢？不同的系统有着不同的标准，下面饮用一个案例对金融系统做个粗略的介绍。对金融系统来说，我们进行业务分解和设计业务流程的时候需要做如下要求：1. 较为模块化的设计，避免重复的脚本，减少建立或维护脚本的成本。 2. 在应用软件开发的同时，就可以同步进行脚本建立的动作，而且当应用软件功能变动时，只需要修改业务功能脚本。 3. 由于应用软件的功能已经被分解成独立的业务功能脚本，测试人员可以随意组合业务功能脚本成为更复杂多样的测

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

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

12、易处理中心项目自动化测试为例，看看这份业务分解和脚本规范会带来什么样的效果。（注：附件文档乃非正式发布文档，系个人私有，不牵涉兴业银行商业秘密，诸位放心！）系统说明：前台Teller（银行柜员操作界面）、电子验印系统（印章校验）、Integrator（信息管道）、工作流系统（IBM的FileNet）、后台交易集中处理系统（中间业务平台）、核心（联想亚信的FTS）等。考虑金融系统的安全性，所有交易流程的处理采用独占的方式，后台界面交易处理按交易优先级次、时间先后进行，同等条件下FileNet随机分配，所以自动化的难度相当的大。交易功能分解按照操作员岗位职责划分为前台柜员，CPC（中间业务平台）的

13、录入岗、审核岗、报文审核岗、异常处理岗、监控岗等部分。实际应用：这样的框架设计会带来什么结果呢？我们来计算一下：1. 前台发起的交易大约有60多个，每个交易的典型业务覆盖需要大约20个流程，这样共计1200个测试流程；2. 每个测试流程除去操作员登陆、签退之后大约有10个脚本，这样如果没有采取公用的话，每个健全的脚本应该在200行左右，不计算重复的测试流程，总的脚本的行数应该是：10*200*60=120000行； 3. 但是采用了子模块的公用，我们完整地写了不到300个脚本（其中包含近百个10行以内的登陆、登出脚本），平均每个脚本只有不到100行，并且通文件系统操作覆盖了所有的流程，即：30

14、0*100=30000行；4. 这样可以清楚地看到，同样覆盖了1200个流程，我们节省了75%的脚本行数，减轻至少50%的工作量（考虑技术问题甚至80%），为QC/TD服务器也减轻了75%的存储压力，虽然在技术上带来一定难度，但是也没有产生多大的影响。如果在没有外界压力的情况下，这种框架设计是非常有效的。很明显，稍微加大一些技术层面的工作量会给我们带来很大的好处：1. 减少30%到50%甚至更多的脚本编写的工作量，系统越大，有点越明显。2. 后期维护难度和工作量在同一的管理下大幅度下降。3. 减轻了测试管理服务器的存储压力，对于QC/TD和QTP的license不多的企业和单位来说，统一协调运

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

16、这儿说的数据是完全剥离开的，从脚本中独立出来了。做到数据驱动不是很简单的事情，因为这些金融业务系统的业务逻辑是非常复杂的，凡是接触过这些业务的核心系统的朋友可能都有这个体会。为了完成数据驱动，我们必须熟知每一个我们要测试的业务节点的功能，这比性能测试对业务流程的掌握要高一些，同时还要掌握数据库相关的表结构，当然其中最麻烦的就数表的关联性了。熟悉了系统的需求、设计、数据库表结构，听起来可能有点危言耸听，但是考虑到将来的使用，系统的不断升级，我们花一些功夫还是值得的；一个上线了的核心业务系统一般不会在一两年之内就淘汰的，金融业务的日新月异其实并不影响我们自动化测试的流程，一系列的升级和数据集中会体

17、现出我们高质量脚本的价值所在。举例来说，*保险公司一个养老险业务系统，无论业务需求怎么逐步更改，系统始终都会稳固的摆在那儿；因为不到实在非废弃不可的程度，谁愿意花费巨大的代价重新去做一个新的系统呢？为了保证对公众业务的连贯性，一个系统始终会以改造升级的方式去运作。说这些无非就是想告诉大家，做一个优秀的自动化个案，尤其在金融这个行业里，是值得的，绝对不会让我们觉得浪费了太多精力而没有实现他的价值。在外包公司，可以将这部分作为服务和系统开发成果的一部分移交到“甲方”；而在“甲方”，这些东西就可以直接应用于自己的运营测试。据我所知，很多公司在持续集成的时候配合LR、JUNIT等工具也使用了QUICK

18、TEST PROFESSIONAL，大频率的集成对我们的脚本的要求也是非常高的，如果做不好就会阻碍这部分工作。不花功夫去研究这些业务功能和数据逻辑会还有什么不利呢？从开篇的结果草图可以看到，我将测试数据分为两部分：动态部分和静态部分。静态数据是哪些呢：审核意见、客户地址这些信息在Staging环境里是无关紧要的，后台不会进行校验，也不会影响到我们业务流程的走向，所以我们一般采用一些随机函数将其带过，还可以很大程度的上保证数据的唯一性。若是某个模块不进行任何校验，或者只有查询之类的功能，抑或是一个不关紧要外围（非核心）系统，我们大可以使用MI（HP）跟我们说的那样Recording、Replay

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

20、好几次，呵呵。3. 有些人在某些地方喜欢将用过的数据UPDATE回头，下次运行时继续使用（我在做性能测试的时候就喜欢这样，嘿嘿）。其实这样做也是有一定的风险的，因为复杂的关联性会让你不小心漏掉某张表或者某个字段，这样在运行的时候要么运行良好却发现不了存在的缺陷，要么就出一些莫名其妙的问题让你花费很多的时间去排查。那么多的触发器，谁能保证面面俱到呢？当然有时为了进行复杂的操作我们必须去写一些PROCEDURE、PACKAGE和JOB来配合我们的测试；有些人喜欢在脚本里直接调用这些过程或包，有些人喜欢用JOB与脚本并行操作。我属于后者，我觉得在测试脚本里执行浪费时间，但是并行可能会出现LOCK，需

21、要计算时间耦合。这都是个人习惯问题，有问题大家可以评论哈。说了半天讲的都是数据分离的必要性，到底怎么做呢？有没有一个简单的方法或者例子呢？莫急，听我慢慢摆。我使用QTP第一个月（学习阶段），傻乎乎的就把数据固定或者简单地参数化一下以显示我会这个功能，接下来我觉得这样对流程性的测试很不利，于是就把数据写到本地本文文件里，作为参数传递的方法。后来就考虑使用数据库，建立本地数据源，直接向数据库伸手了_，只是一下子就抛弃了EXCEL和TXT文件；过了很久才明白过来，本地文本可以抛弃，但是不抛弃却另有好处。图2. 测试数据使用流程如图所示，从数据库中获取测试数据的同时在本地文件里驻留一份，运行测试之后无

22、论数据变成什么样我们都可以知道操作之前是什么一个状态。这为我们在结果分析的时候提供了很大的便捷，不用再苦恼于查看数据库修改记录有多么麻烦。在我们使用我们需要的数据链接的同时，我们必须对它们进行定期维护。业务逻辑稍微变动，我们的SQL语句就需要调整修改，数据库迁移的时候我们需要及时更新连接串。这部分工作量并不是很大，但却比较重要，我们需要在第一时间获取所有的变更信息，以确保我们的测试运行能够顺利、有效的进行。否则很可能为了一些很小的细节动用大批人员排查故障，到头来却发现是沟通出了问题讲完我对这个框架的认识，想必有些赞许（我不脸红），有些不屑（也不心灰），但是我希望大家能够真诚的交流。虽然在以前做测试的技术含量没有写代码高（其实我们也在写），但是我们爱岗敬业，当然要把测试做出点声色来。最后悄悄告诉大家一个小秘密，我的理想不是写Chinese操作系统，而是有朝一日能亲自参与设计、开发一个集QTP、LR、WR三者优点于一身的测试工具（必须国产，嘿嘿），抢HP生意，哈哈。我的联系方式如下：公司电话：021-38636974私人电话：13681695120我的球球：531289880主要邮箱： 公司邮箱： (只能收不能发)个人主页：（与工作无关）