Appium第二弹！学习分层思想与实战中的一些小技巧

在上一篇小文中，我们已经能够独立写出一个自动化小程序，可是对于自动化的实现，这还是远远不够的。我们刚好走出了起跑线一步而已。现在，我们开始深入学习appium工具吧。
在学会分层之前，我是这样写脚本代码的，例如：

driver.find_element_by_name("1").click()
driver.find_element_by_name("5").click()
driver.find_element_by_name("9").click()
driver.find_element_by_name("delete").click()
driver.find_element_by_name("9").click()
driver.find_element_by_name("5").click()
driver.find_element_by_name("+").click()
driver.find_element_by_name("6").click()
driver.find_element_by_name("=").click()
driver.quit()

这种形式的代码，优势是易编写，找到元素，再对元素操作，很容易上手；可是它的劣势也很明显，如果元素发生改变，或者操作逻辑发生变化，需要修改的地方很多，维护的工作非常负责和麻烦，与自动化可持续集成的思想是背道而驰，对后续工作造成非常大的困扰。所以，我们需要对代码分层。
分层，顾名思义，就是讲所写的代码分开处理，那怎么分开，用什么方式定义为一层最为简便呢？我们可以先看一下测试金字塔：

相信很多人对这个金字塔是不陌生的，那么如果你能理解这个金字塔，你就能够理解分层思想了。分层就是构建高效率地测试金字塔，将风险控制在易发生变动和改变的UI层，维护工作也尽量放在UI层中；server层放置对UI层元素的所有操作方法，不需要重新定位元素，而是直接调用UI层中已经定义的元素；unit层则是放置我们的一个个测试用例，将需要的用到server层中的方法一个一个调用起来，构成我们的测试集。
当然，在实际工作汇中，我们可以依据这个分层思想做出最适应的改动以达到我们更高效的自动化测试。
讲到分层，就不能不提PageObject（以下简称PO）封装思想。PO思想，顾名思义，就是将一个页面的所有元素和方法封装成一个类，在测试用例中需要用到某个方法的时候，直接调用这个类的方法就可以了，操作简单，而且维护也极为方便。
在UI层：

 @FindBy(className = "android.widget.TextView")
    private List<WebElement> textVieWs;
   @AndroidFindBy(className = "android.widget.TextView")
    private List<WebElement> androidTextViews;
   @FindBy(className = "android.widget.TextView")
    private List<MobileElement> mobiletextVieWs;
   @AndroidFindBy(uiAutomator = "new    UiSelector().resourceId(\"android:id/text1\")")
   private List<RemoteWebElement> remoteElementViews;

通过@FindBy查找元素，再给元素定义，findby的用法稍后会详细解释。
在对页面所有元素定义后，再编写构造方法：

     @Before public void setUp() throws Exception {
        if (!populated) {
            //This time out is set because test can be run on slow Android SDK emulator
            PageFactory.initElements(new AppiumFieldDecorator(driver, 5, TimeUnit.SECONDS), this);
        }
        populated = true;
    }
    @Test public void findByElementsTest() {
        assertNotEquals(0, textVieWs.size());
    }
    @Test public void findByElementTest() {
        assertNotEquals(null, textView.getAttribute("text"));
    }
    @Test public void androidFindByElementsTest() {
        assertNotEquals(0, androidTextViews.size());
    }

将页面元素和元素操作方法封装成一个类，易于管理和维护，UI发生变动时，只需修改这个页面的相关元素，而不需要改动其他层代码。
当然，有的时候，如果一个页面可以操作和用到的元素很少，封装成一个类感觉很麻烦，那怎么办呢？
我个人想法，如果这个页面和其他页面元素，只与一个特殊业务相关，那可以将几个页面封装成一个业务常用类，如果说这个页面很多业务需要用到，那还是需要封装成独立的页面类，这样，其他的业务都能独立调用这个类，而不用牵扯到其他页面。
当然，如果这个页面有很多元素需要定义，当然是需要封装成独立的页面类。如果时间充裕的话，我还是建议一个页面只封装成一个页面类，而不是与其他页面混合封装。
前面有说到，我们需要有一个层，放置公用的方法，我个人觉得这个很有必要，如果某个方法会被重复调用，那当然得放在一个公用层中，达到方便管理的目的。
server层可以快速的找到功能操作对应参与的基本页面元素。在UI层，页面类是有很多个元素和方法，可是有的业务测试是不需要用到页面所有的元素和方法的，那这个时候怎么办呢？我们就需要server层了，把case模块之间的方法互相调用，组合成复合功能操作，最后将各模块封装好的功能操作通过一个类似基本功能操作的工厂封装起来，以便于模块化的维护。
那unit层就很好理解了，我们在测试用例中不用再做元素查找工作，和对元素编写方法操作，我们要做的，只是把server层中的方法调用，集中和安排方法顺序，或者为需要做等待的方法添加隐性等待等等，以达到更高效和高覆盖测试用例。
@FindBy()使用注解获取页面元素
Appium 滑动有两种：
第一种：

JavascriptExecutor js = (JavascriptExecutor) driver; 
WebElement  element = driver.findElementBy.className("classname");  
HashMap<String, Double> swipeObject = new HashMap<String, Double>();  
swipeObject.put("startX", startX);  
swipeObject.put("startY", startY);  
swipeObject.put("endX", endX);  
swipebject.put("endY", endY);  
swipeObject.put("duration", duration);  
swipeObject.put("element", Double.valueOf(((RemoteWebElement) element).getId()));  
js.executeScript("mobile: swipe", swipeObject);  

X,Y可为coordinator，也可以是percent，大于1 为coordinator， 小于1 为percent，比如0.5 代表50%
duration单位为秒， Android 可以设置0.1-60，iOS设置0.5-60
需要滑动特定的对象时需要指定的element，只是在名目上滑动式就可以不指定element
第二种： flick 区别swipe是没有duration：

JavascriptExecutor js = (JavascriptExecutor) driver; 
WebElement  element = driver.findElementBy.className("classname");  
HashMap<String, Double> flickObject = new HashMap<String, Double>();  
flickObject.put("startX", 0.8);  
flickObject.put("startY", 0.5);  
flickObject.put("endX", 0.2);  
flickObject.put("endY", 0.5);  
flickObject.put("element", Double.valueOf(((RemoteWebElement) element).getId()));  
js.executeScript("mobile: flick", flickObject);