基于QTP的金融软件自动化测试框架何谓自动化测试框架呢？我认为它就是一个关于自动化测试总体设计规划和一个关于设计细节的规范，同时我认为自动化测试框架至少应该包含下面三个部分：测试工具使用规范、业务功能模块分解、测试数据分离与管理。图1.自动化测试框架草图下面分别对这三个方面进行简单的阐述，不只针对回归测试，大家可以把系统测试也考虑进去，希望能起到抛砖引玉的作用。我呢，经验不多参加工作才一年，可能有些看法比较偏颇或者错误，希望大家不吝指教。测试工具使用规范先谈谈规范化的必要性(引用来源51Testing)脚本的生成方式就两种，一种是自写脚本，一种是录制生成。脚本不管录制也好，还是手写也好，选择的时候应该以脚本模拟程序真实有效为准，结合项目进度，开发难易程度等因素考虑。而脚本的开发也需要符合一种规范，也可以说是一种习惯，因为脚本不只是开发者一个人看，测试执行人员也需要看，这就要求可读性和可维护性提高；故而开发时应该考虑这层因素，规范一下。综合起来可以得到以下结论：1.手写可读性好，流程清晰，检查点截取含义明确。业务级的代码读起来总比协议级的代码更易让人理解，手写可能花费更多时间，但是也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有维护的价值，现炒现卖。2.其次，业务逻辑稍微复杂一点的系统单凭录制是不可能检查到绝大部分异常的，只有手工书写的时候边写边思考可能会发生哪些异常，才能使脚本更具逻辑性、完整性和健壮性，给业务流程控制提供一个好的依据。其次是如何做，做些什么规范1.在做框架设计定义的时候，需要定义好代码规范，如变量名称定义规则、注释规则、变量声明规范、循环时间和次数上限、等待时间的处理方法、单个Action和脚本的大小限制等等，这些都是同C/C++、JAVA等程序员写代码的要求如出一辙，规范就是为了方便统一管理。2.工具应用规范的制定，如：对象库管理方式①、关联的驱动脚本和批处理、测试工具的设置（如ActiveScreen，Runmode等）、测试结果存放分析、数据源管理维护、场景错误恢复和资源、环境定义等等。3.并不是所有进行自动化测试的人员技术和经验都在一个层次上，所以在设计框架的时候需要对于一些疑难或者可能会出现麻烦的地方事先进行说明或者做出培训计划。这是风险规避的一条途径。4.明确测试目标，规定对数据检查的程度和测试目的，FAT、ST还是UAT，否则在UAT阶段仔细校验数据，工作量就非常大了，当然如果有ST测试的脚本基础倒是也不会花很多工夫，只是有些公司用QTP都是单只做UAT的。①对象库集中管理，为同一系统所有脚本提供共享库抑或不共享，这是8.2以前留下的习惯，其实在9.0、9.2来说也是可以考虑的。测试脚本存储和运行管理有时候，我们没有（公司没有提供）QC/TD来管理我们的自动化测试（当然其他的自动化测试管理工具我也没有见过、用过，就以QC/TD为例吧），而有时候我们拥有管理工具却缺少必要的主策略和网络协议（可能会出现这种情况吧），这就导致了QTP自动化测试管理的多样性；当然多数情况下，用得起QTP的也是能用得起QC/TD的，呵呵。1.有QC/TD作为我们的测试脚本存储和运行管理（抛开需求和缺陷管理不说）的时候，我们的自动化测试流程管理显得简单的多。脚本编写、存储、测试实验室业务流程的建立、测试执行和结果分析等等。一般情况下，这些规则之需要简单的口述即可，当然一定需要阐明的话也是很简单的，只是需要结合我们要说的其他几个部分来叙述，这里不再赘述。2.对于没有QC/TD的情况，可能大家见过很多管理方式，类如FTP、共享磁盘等等；一个共同的要点就是“共享”。如果一个系统或项目有多个自动化脚本设计者协同工作，而大家各自为战把脚本存储在自己的私人空间里就会产生很不好的效果。因为整个系统的测试被割裂，很多需要关联的业务流程就无法组合，尤其对于金融软件来说，功能测试也好、回归测试也好，这样自动化就成了一个摆设：它无法覆盖很多的关联性很强的业务流程。其次，在本地空间存储有一个潜在的安全隐患，因为可能由于误操作或者磁盘的损坏导致一个月的工作付诸东流。而共享服务目录和FTP器一般都是...
