Web UI自动化使用Page Object设计实例分享

声明：
1.本文使用java语言描述，使用TestNG框架执行测试
2.请原谅，我又拿百度首页做实验了，实在是因为百度首页太简洁了，当实验例子太好用了…… 

很多小伙伴在使用selenium进行web系统的ui自动化的时候，一开始大家估计都是兴高采烈的写出类似下面这种代码：

package baiduSearch;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.By;


public class TestBaiduSearch{
    public void test(){
        //定义浏览器
        WebDriver driver = new FirefoxDriver();

        //打开百度首页并搜索selenium
        driver.get("http://www.baidu.com");
        driver.findElement(By.id("kw")).sendKeys("selenium");
        driver.findElement(By.id("su")).click();
    }
}

脚本一跑起来，刷刷的就把我们想要的业务执行出来了。但这只是一个简单到不能再简单的例子，真实的项目远要比我们想的复杂的多。我们要考虑业务复杂度，我们并没有可能用if...else...和for循环解决所有代码重复的问题。因为我们不可预料业务会有什么样的变化。如果我们不用if...else...和for循环，那就会出现，业务一改，我们就要跟着改N多行代码，导致工作效率的大大降低，也就失去了自动化存在的意义。

为了解决这个问题，下面有请我们今天的主角：Page Object设计模式（以下简称PO）隆重登场。

概述：
PO的设计思想重新定义了UI自动化测试，它把Web测试中的每一个页面当作一个对象进行封装（实际实现的时候把它当作一个包），然后把这个对象进行分层设计，拆分为了元素管理层，操作管理层以及业务管理层（三个层分别都是单独的一个类）。顾名思义，元素管理层就是管理页面元素的，操作管理层就是管理对这些元素的操作的，而业务管理层就是为了把这些元素，操作串联成为真实的业务场景，而实际测试的时候，我们写脚本的工程师，可以只调用业务管理层里面的方法就可以完成测试，并不需要关心到底点击了哪些元素，对元素做了怎么样的操作，同时，我们在维护脚本时，也不必担心页面设计发生了变化，元素变了，我们维护元素，操作变了，我们维护操作，业务变了，我们维护业务就好了。这样大大提高了测试用例的重用性和测试代码的维护量。同时分层管理也让代码可读性提高了很多，不会有满篇的driver.findElement(****).

下面我们把上面这段百度搜索的代码改造成为PO给大家看看。

首先，我们封装元素层，我们看到我们这段操作一共用到了两个元素，分别是id为kw的输入框和id为su的搜索按钮。那么我们对其进行封装。代码如下：

package baiduSearchPage;

import org.openqa.selenium.WebElement;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.By;

public class BaiduSearchPageElements {
    //封装搜索关键字输入框 
    public WebElement inputFrame(WebDriver driver){
        return driver.findElement(By.id("kw"));
    }

    //封装搜索按钮 
    public WebElement searchButton(WebDriver driver){
        return driver.findElement(By.id("su"));
    }
}

然后，我们我们看到针对这两个元素我们一共使用了sendKeys和click方法，下面我们对这个操作进行封装，代码如下：

package baiduSearchPage;

import org.openqa.selenium.WebElement;

public class BaiduSearchPageAction {
    //定义输入操作
    public void input(WebElement element,String inputKey){
        element.sendKeys(inputKey);
    }

    //点击按钮操作
    public void click(WebElement element){
        element.click();
    }
}

下面我们把业务流程写出来，代码如下： 

package baiduSearchPage;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;

public class BaiduSearch {
    //声明元素类和操作类
    BaiduSearchPageElements elements = new BaiduSearchPageElements();
    BaiduSearchPageAction action = new BaiduSearchPageAction();
    //定义浏览器
    WebDriver driver = new FirefoxDriver();

    //定义百度搜索操作类
    public void search(String inputKey){
        //打开搜索页
        driver.get("http://www.baidu.com");
        //输入搜索词
        action.input(elements.inputFrame(driver),inputKey);
        //点击搜索按钮
        action.click(elements.searchButton(driver));
    }
}

之后，我们对这个业务进行测试的时候，只需要如下写代码就可以了。

package testcase;

import org.testng.annotations.Test;

public class TestBaiduSearch {
    BaiduPageElementsAction testSearch = new baiduSearchPage.BaiduSearch();

    @Test
    //测试搜索Hello,world!
    public void searchHelloWorld() {
        testSearch.search("Hello,world!");
    }

    @Test
    //测试输入随机字符
    public void searchCode() {
        testSearch.search("Q￥#@%Y……");
    } 

    @Test
    //测试留空
    public void searchBlock() {
        testSearch.search("");
    } 
} 

这时候，
如果页面元素发生变化，我们只要修改元素类即可。操作和业务流程类及用例都不用改
如果页面元素有增加，我们只要把新的元素和操作加入对应类，然后更新业务流程即可，用例不用改。
如果只是业务流程更改，我们只要更新业务流程，其他几个类都不用改。

相信大家已经能够看得出这样设计模式的好处了。
但是值得一提的是，PO作为一个设计模式，很好的提高了UI测试的重用性，但并不代表这个模式任何时候都能一力降十会。所以还需要结合业务需求进行深度更新。
为了更清楚的表达PO的思想，本文并没有对selenium的方法进行二次封装，在实际过程中，其实我们可以对selenium的方法再进行二次封装，让测试流程里的driver.get和driver.close也变得更易用。
好了，关于PO如果有不明白之处，请恕我表达能力欠佳。