自动化测试框架

    对这一概念有些模糊。整理一下。

 

    定义1--模糊的定义和解释：

 

    框架（Framework），Wikipedia：一种用于解决复杂问题的基本概念性的结构。具体来说，好比我们要盖一座房子，那么先用钢把它的外形搭建出来，再由工人进行内部搭建，这层外形就是测试框架。

 

    又有：框架，整个系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。

 

    自动化测试框架（Automation Framework），实际上就是某种应用的半成品，或者是一组组件，供用户选用完成特定的系统。简单来说就是使用已经搭好的舞台，用户自行演出。自动化测试框架是一组自动化测试整体解决方案，可以让组内的成员更好、更便捷的使用自动

化测试工具。

 

    一个完备的自动化测试框架由启动引擎、关键字驱动、数据驱动、异常处理、报表引擎、

 

日志记录组成。

 

    框架一般是成熟的且不断升级的软件。

 

    如SAFS(software Automation Framework Support)是一个开源的支持多平台的自动化测试框架。它支持包括关键字驱动、邮件服务、自动部署服务、分布式服务、日志服务、文件服务等一整套解决方案，并且开放了Robot、QTP、Selenium、Abbot工具的接口。

 

   Watir，是能够提供Web测试的开源自动化测试框架，它的原生语言是强大的Ruby，相对于庞大的商业测试工具，它的小巧、灵活、开源、精彩的Library、足够的扩展性是目前很多公司选择Ruby+Watir的理由。

 

 

   定义2-稍精确一些的

   真正实现自动化测试，并不是掌握了某个自动化测试工具，掌握了脚本的编写技术就能够达成的。

 

  在正式实施自动化之前，必须搭建一套适合的自动化测试框架，将脚本能够有效地组织、连贯应用起来，提高测试脚本的可维护性和可靠性。

 

   1）要实现的目标

  

   高复用性 高可维护性  稳定性  快速编写脚本  自动执行 正确输出结果  能够不断提升自动化测试用例

 

  

   实现思路

　　● 分层设计：业务流程、功能点、操作组件

　　我们在进行测试时，首先会验证各个页面、各个字段的正确性，到验证功能点的正确性，再组合各个功能点进行业务逻辑、业务流程的验证，最终确保 系统满足业务需求。

　　* 对于自动化脚本，采用分层的思想，先实现最底层的操作组件，通过调用操作组件、及业务逻辑实现对功能点的验证，再通过调用业务逻辑组合功能点实现对业务流程的验证。不同的业务流程，对于底层的操作组件、中间层的功能点函数是完全可以复用的，只是调用的业务逻辑的差异，或者是测试数据的差异性。

　　* 尽可能做到各脚本之间具备独立性，不相互依赖，便于进行各种基本场景的组合运行。

　　如销售系统中的选择房间操作，在做预约、小订、认购等操作时，都需要用到选择房产，因此可以将选择房产做为一个公共的操作组件，详细描述选择 房产的操作步骤，在测试新增预约、新增小订、新增认购等功能点时都需要调用到选择房产的操作组件，只是业务的校验逻辑与所选择的数据不一致。

　　再看业务流程，新增一个小订单后可以作废，也可以由小订转认购，业务流程就有两个：新增小订单—作废订单，新增小订单—转认购，这两个业务流 程中“新增小订单”这个功能点是一致的，可以通过调用不同的用例数据组合成不同的业务流程。

● 脚本分离设计：对象、操作、测试数据、业务逻辑相互剥离、灵活调用

　　对某个功能进行自动化测试，实际上就是对这个功能涉及的对象进行操作，输入测试数据来验证其结果的正确性，复杂的验证点需要编写业务逻辑。如 果全部用脚本的方式编写，针对每一条测试数据就需要编写一份脚本，脚本量相当巨大，同时任何改动（程序、测试用例、GUI对象）都需要调整大量的脚本。

　　为了达到可维护性、可复用性，将对象、操作、测试数据、业务逻辑剥离、分开管理，通过调用关系去组合实现不同的测试用例。

　　* 对象资源库

　　* 测试数据资源库

　　* 操作组件（描述操作步骤）

　　* 脚本：业务逻辑

　　分离后，如果要增加测试用例，只需要维护测试数据，如果程序修改，增加了对象，那么只需要维护对象库、操作组件，增加对这个对象的操作。

　　● 封装基础函数、基本的业务逻辑、验证点

　　通过对基本业务逻辑、验证点的封装、调用，实现快速的脚本开发

　　如一个数据保存的功能，每一条数据在做了增、删、改的操作后，都需要验证保存至后台数据库的数据正确性，通过预期结果与数据库实际产生的数据 集进行比较验证，在获取数据库实际产生的数据集的方式是通用的，只是不同的功能所要验证的数据表、字段及Where条件不一致，获取数据集的方式就可以封 装成一个基础函数，传入不同的SQL语句做为参数即可。同时预期结果与实际结果集的比较也可以封装为基础函数。

　　再如，系统页面中在某些操作或条件下，部分字段是只读不允许编辑的，或者是隐藏不显示的，编写脚本时需要对每一个对象写一条语句验证其只读和 隐藏属性的正确性，如果将只读和隐藏属性的验证进行封装，针对每一个页面进行验证，那么只需要传入这个页面只读或隐藏的对象名称，调用封装的函数执行验证。可以大大减少脚本量，也更易于维护。

　　● 有效的执行体系

　　* 批量、定制执行、自动运行

　　自动化测试真正达到提升测试效率，需要实现无人值守情况下的批量自动执行，并且可以定制执行。

　　* 异常处理机制

　　脚本执行过程中，因程序错误或环境问题、脚本自身问题经常会出现非预期的错误：如意料外的弹出窗口、发现错误的数据、未找到对象、输入文件打 不开或不能读等，有些情况下当前用例出错，并不影响后续用例的执行，需要支持异常处理机制，终止执行或者终止当前用例，继续后续用例的执行，亦或者跳过当前步骤，继续执行后续操作，并输出当前的错误报告。

　　* 业务数据还原初始状态

　　自动化测试需要循环执行，执行完成后，需要恢复初始状态（主要是业务数据），以使得程序重新提交版本后能够循环执行，不断的对新版本进行回归 验证。

　　* 版本管理

　　随着待验证版本的不一致，自动化测试脚本也会不断的更新、维护，同样需要进行版本管理。

　　● 结果体系

　　* 针以每条用例，输出用例执行结果

　　* 针对每个检查点，输出详细的检查点执行结果

　　* 输出执行日志

　　● 结构化管理

　　对象、操作组件、基础函数、测试数据、功能点脚本、业务流程组合，如此多的层级、调用关系，必须进行结构化管理，采用高度组织化的目录结构、 分级管理，方便进行正确及快速的调用，方便能够快速定位、查找问题。


版权声明：本文后半部分出自liqf的51Testing软件测试博客：http://www.51testing.com/?4340