自动化测试的四种框架

本文节选自https://www.cnblogs.com/40406-jun/p/6642112.html
https://www.cnblogs.com/40406-jun/p/6642184.html

KiKi Zhao 的翻译文章
中文原文地址：http://www.cnblogs.com/nckiki/articles/244202.html

英文原文地址：http://www.ibm.com/developerworks/rational/library/591.html

四种常用的自动化测试框架

框架到底用来做什么，最终的目的无非是将不同层次的对象和逻辑进行抽象和分离封装，从而使得被测试程序的变更所导致的测试脚本框架的变更维护工作量减少到最少。

原文对自动化测试架构做了如下四种分类：

1、数据驱动测试框架（The Data-Driven Testing Framework）
仅仅是将测试数据从测试脚本中分离出来，开始了非混沌状态的第一步。

2、测试脚本模块化框架（The Test Script Modularity Framework）
测试脚本中包含了各功能点中涉及到的控件识别和业务逻辑操作，其中包含了外部测试数据的调用。

3、测试库构架框架（The Test Library Architecture Framework）
将所有的针对测试系统本身的控件识别和控件支持的操作封装在测试库中，测试脚本调用测试库的同时传递外部的测试数据，测试库的编写由自动化测试开发工程编写（可以不懂业务），负责控件的变更和维护。

4、关键字驱动或表驱动测试框架（The Keyword-Driven or Table-Driven Testing Framework）
如果不懂自动化编程的普通测试工程师能不需要了解测试工具和框架本身的知识就能维护控件对象和业务逻辑，这样就可以将自动化测试工程的工作量进行很好的分摊。具体实施就是将控件对象，动作，参数等等从框架或工具本身剥离出来放在普通Excel表格中，框架本身所要做的就是识别Excel表格中的这些控件对象以及Action。

自动化测试框架思想

模块化思想
库思想
数据驱动思想
关键字驱动思想

1、所谓模块化思想，就是将一个测试用例中的几个不同的测试点拆分并且将其单个点的测试步骤进行了封装，形成了一个模块。

例如：一个测试用例要对一个登录程序进行测试，其中包括：用户名输入、密码输入、以及确定登录；

那么就可以将用户名输入、密码输入、确定登录、取消登录四个操作分别封装在四个不同的模块中。测试时，只需调用其模块即可。这样的话，当一个模块有变化，你只需单独维护那个模块即可，也可以根据模块的不同组合成不同的测试用例。

2、所谓测试库思想，就是模块化思想的升华，其为应用程序的测试创造了库文件（可以是APIs、DLLs等），这些库文件为一系列函数的集合。其与模块化思想不同的是，其拓展了接口思想，即可以通过接口去传递参数，而不是一个封死的模块，可以说是一个多了一个“门”的交互型模块。

例如：还是以上那个测试用例，只是将用户名输入、密码输入、确定登录、取消登录封装成一个库，这个库含有一个函数Login，这个函数Login接收两个参数“用户名、密码”，对输入不同的用户名和密码可以进行不同的测试用例。也可以另外一个函数Cancle。

3、所谓数据驱动思想，众说纷纭，很多人都觉仅仅依靠用EXCLE表进行不同数据的读取仅是一个高级的参数化，其实怎么理解并不重要，关键是其思想能够好的应用到你的框架中。而我的理解就是变量不变，数据驱动结果，不同的数据导致了不同的结果的产生。而对于数据的导入，可以通过很多方式，例如：EXCLE表、XML（用在WEB中）、数据库（DB）、CSV文件、TXT等都可以。

4、所谓关键字思想，这个思想，我曾经一直思考，它与面向对象的关系，与交互模块化思想的区别。后来个人理解，其实关键字驱动就是一种面向对象的思想，例如：QTP、RFT中，对象可以为一个数据或者一个关键字，对对象的抓取，可以将其测试对象封装为一个关键字（即可以将gui元素封装成了一个个关键字），这样可以对其关键对象进行各种操作了，不同的对象可以驱动不同的测试流向与结果。

简单的应用的方式可以用一个EXCEL表，里面包括“对象类型”“对象名称”“对象操作名称”“判断方式”“预期结果”。这样的话，可以通过导入不同的对象类型和名称、不同的对象操作来构建成了一个测试用例表了。

以上只是对这些思想的个人理解，做好自动化测试，不是说你掌握了一个框架，而是要掌握其自动化的思想，然后根据这些思想，结合你不同的测试环境和流程来构建你自己的自动化测试框架。