测试框架之我见

什么是框架？
框架可以是被重用的基础平台；框架也可以是组织架构类的东西。我认为，框架就是一系列基础设施，这些设施起到一个基础工具的作用，是一个创建别的工具的工具。

其次，什么是自动化测试呢？
自动化测试是用软件（通常指有一系列测试配置前提下）去执行测试并且判断实际结果和期望结果是否一致的一种测试方法。

那么，什么是自动化测试框架呢？
自动化测试框架由一个或多个自动化测试基础模块、自动化测试管理模块、自动化测试统计模块等组成的工具集合。这些模块集合组合到一块，应具备以下特质：
· 测试框架与被测应用程序独立。即一套框架可以服务多种程序的自动化。
· 测试框架应被高度模块化，易于扩展、维护。各个模块之间应解耦，独立。
· 测试脚本所使用的测试语言应该是与框架独立的。不同的测试框架可能在不同的应用领域有不同的表现，有些适用于Java应用程序的测试， 有些可能适用于Web应用程序的测试，那么当需要从一个测试框架迁移到另外一个测试框架时，所有的测试脚本应该不需要重写。
· 测试框架应该简单易用。

最后，如何创建一个自动化测试框架呢？首先，你要有“自动化测试框架思想”，什么是“自动化测试框架思想”？
·模块化思想
·库思想
·数据驱动思想
·关键字驱动思想

我们举例说明：
譬如一个英文学习网站，有登录，学习页面（由PL, GL, 自我学习页面等组成），还有退出页面。
假设我要分别自动化测试测试PL， GL页面，那么我们应该怎么做呢？手工测试步骤是先登录，然后跳转到我要测试的页面，测试，然后退出。那么自动化测试就是分别写登录，跳转页面，测试，退出页面的代码，然后把它们按顺序组合到一起。我的代码看起来可能是这个样子的（）：

…代码块1…
…打开登录页面…
…输入用户名…
…输入密码…
…点击登录按钮…
…跳转后检查是否进入到首页…

…代码块2…
…找到Menu…
…找到PL/GL页面的链接…
…点击连接进入…
…判断是否进入目标页面…
…是，进行目标界面的测试，不是，报错退出…

…代码块3…
…具体的测试代码，断言等…

…代码块4…
…找到退出按钮…
…点击退出…

模块化思想就是将一个测试用例中的几个不同的测试点拆分并且将其单个点的测试步骤进行了封装，形成了一个模块。
举例来说：
对于PL 和GL， 我的代码块及代码顺序都是1，2，3，4. 唯一不同的是3里的具体实现，如下所示：

PL: 1, 2, 3(for PL), 4
GL: 1, 2, 3(for GL), 4

如果代码块1有改动，我需要把 PL 和GL测试代码里对应的模块也更改一遍，如果我有100个case，那么就要改100遍，太不make sense了。

模块化就是把1， 2， 4， 这些共用的操作分别封装，可以形成登录模块（login（）），跳转模块（redirect（）），退出模块（logout（））.
封装后我的代码看起来是这样的：

PL: login（）, redirect（）, 3(for GL), logout（）
GL: login（）, redirect（）, 3(for GL), logout（）

这样的话，当一个模块有变化，你只需单独维护那个模块即可，不再需要更改PL， GL的测试代码了， 是不是效率瞬间提升啊？

你肯定看出来了，模块化之后，redirect（）函数没有提供入参，这样我分别测试PL和GL的时候，需要更改redirect（）这个模块里的跳转url目标地址。还有如果我想针对特定账户测试PL， GL该怎么做呢？每次测试前再去修改模块化函数login（）的账户信息吗？如果我需要针对不同账户同时测试PL， GL该怎么办？

测试库思想，就是模块化思想的升华，其为应用程序的测试创造了库文件（可以是APIs、DLLs等），这些库文件为一系列函数的集合。其与模块化思想不同的是，其拓展了接口思想，即可以通过接口去传递参数，而不是一个封死的模块，可以说是一个多了一个“门”的交互型模块。
我们根据测试库思想来设计一个api，把login（）， redirect（）更改成 login（username, password）, redirect(url),是不是就解决了啊！
我们的代码变成了 ：

PL: login（username, password）, redirect(url), 3(for GL), logout（）
GL: login（username, password）, redirect(url), 3(for GL), logout（）

另外，针对login 和redirect模块里的跳转检查和目标页面确认检查，我们也可以封装成一个函数 target_check（target）， 这样我们的代码是不是又少了很多，且方便维护扩展了呢 ：）

这样，我们的测试脚本开发人员，只需要focus在具体的测试页面上（例如PL或者GL页面）就可以了，不需要关心通用模块的开发维护了，这样是不是有了测试框架的雏形了？：）

我们满足的把这个框架运行了一段时间，忽然有一天，老板说，我们新开发了100个市场，我们需要这100个市场的用户从登录界面登录后，根据用户country把用户redirect到不同的domain上去，这个需求很紧急，你多久能搞定？
创建100个test case，更改这100个case里login模块的username， password? 你傻不傻？

我们弄一个Excel，封装一个读写Excel的api，然后只写一个测试用例，循环100次，每次读取不同的username和password，我们的代码变成了：

For i in range(0,100):
login（username[i], password[i]）, redirect(url), 3(for GL), logout（）

老板开心死了，再来100个市场，你也分秒搞定！这个时候你让他加工资，你说他‘滋瓷’不‘滋瓷’?

这就是所谓数据驱动思想。利用数据驱动结果，不同的数据导致了不同的结果的产生。而对于数据的导入，可以通过很多方式，例如：EXCLE表、XML（用在WEB中）、数据库（DB）、CSV文件、TXT等都可以。

时光如梭，你带了个新人妹子，你来手把手教她如何新写自动化代码如何维护自动化框架，她很笨，代码写的慢，而且调用的api一多她就头晕，经常拖着你加班，一加就到晚上十点多，你还得送她回家，每次送到家她还请你上去坐坐，坐个头啊，已经十点多了，回到家就要12点了, 回去不要打游戏了？回去不要看球赛了？回去不要老婆孩子热炕头了？第二天上不上班了？叔可忍婶不可忍，你鼓捣出这个来：

你告诉妹子，她只要在Excel里按格式更新就可以了，不需要再去调用API了，妹子讪讪的去了，世界清静多了，一切都很美好，并没有哪里不对～

这就是关键字思想。就是不仅把测试数据放到文件里，还把关键指令（用来决定做什么操作，做这个操作要执行哪个测试脚本）也放到外部文件里， 这就叫关键字驱动。
上面的例子中， MethodName 这一列是关键字，代码会根据这一列里的方法名调用相应的代码。
我们给出一个关键字的实现例子：

def open_browser(browser_name):
    browser_name = browser_name.lower()

    if not browser_name in {'chrome', 'firefox', 'ff', 'ie'}:
        browser_name = 'chrome'
    if browser_name == 'ie':
        browser = webdriver.Ie()
    elif browser_name in ('firefox', 'ff'):
        binary = None   
        profile = None
        if settings.FIREFOX_BINARY:
            binary = FirefoxBinary(settings.FIREFOX_BINARY)
        if settings.FIREFOX_PROFILE:
            profile = webdriver.FirefoxProfile(settings.FIREFOX_PROFILE)
        browser = webdriver.Firefox(firefox_profile=profile, firefox_binary=binary)
    else：
          options = webdriver.ChromeOptions()
          options.add_argument("--use-fake-device-for-media-stream")
          options.add_argument("--use-fake-ui-for-media-stream")
          browser = webdriver.Chrome(chrome_options=options)
    browser.maximize_window()

    return browser

这个例子实现好后，你在代码里写open_browser(‘chrome’)这个关键字, 系统就会自动知道如何执行，执行什么， 以什么配置。
以上你都明白了吗？自动化测试框架，不过是一系列文件，代码，组件的集合，这些集合放到一起，方便了我们自动化测试代码的编写，大大的提升了工作效率。
后面我们来看看如何根据以上思想实现Web自动化测试框架和Mobile自动化测试框架。