PageObject模型和自动化框架（一）

本文是我对UI自动化测试和基于Appium自动化框架的一点点浅显的总结，如果表述中有什么谬误，欢迎博友热心指出，在此提前表示感谢；另外，该文也算是学习过程中的一个笔记，如有入门自动化相关行业的朋友，欢迎交流。

UI自动化测试

Web app和Android app现在已经很普遍了，软件开发者完成一个app的开发部署后，需要测试工程师进行测试验收，最终才为用户提供一个稳定的应用平台；从用户或者产品的角度来看，一个app需要完成特定的业务流程，为客户返回一个想要的结果或者异常提示信息。所以如果作为业务测试工程师，我们关心的是产品的业务流程，不关心底层数据流和实现原理，在自动化框架未出现之前，测试工程师需要手工模拟所有业务流程并保证app的正确性和稳定性；随着不同平台的自动化工具的推出，测试工程师可以借助这些自动化工具完成业务流程测试，自动化平台现在已经比较多了，比如Selenium，Appium，RobotFramework和Uiautomator等等，关于这些自动化平台的使用方法、底层原理和API等大家自己查一下，本篇文章重点是总结PO设计和自动化框架内容，其他内容不(ˇˍˇ） 想赘述。

PageObject

本人在基于Appium平台上进行UI自动化开发也有一年多了，有一天同行朋友随口问说：PO模型的优缺点有哪些？可以列举出来吗？当时含糊其辞，优点说了一些，缺点没怎么说出来，后来查阅博客和重新阅读《Selenium2自动化测试实战–基于Python语言》，对其优缺点进行清晰罗列，并进行个人解释。

优点：
1. 减少冗余
  个人理解：减少代码重复应该是说，我们可以通过PO模型，对页面进行封装，将页面公用的一些代码封装成API形式，提供给上层Case调用，举个例子：有一个登陆窗口，输入账户和密码，点击登陆按钮，对于这个简单的业务流程，按照测试用例设计中条件组合，有如下几条case需要执行：

		case1：账户非空，密码空，登陆；
		
		case2：账户空，密码非空，登陆；
		
		case3：账户密码均非空，登陆；
		
		case4：正确的账户密码，登陆；
				......

  如果你直接面对页面，进行自动化测试用例的编写，每条用例中都会涉及大量定位输入框，设定输入框内容，定位确认按钮，点击确认按钮这些重复的操作；对登陆页面的功能进行封装后：input_username()，input_password()，login()，然后测试用例直接调用这些页面级的API进行业务测试即可，寻找控件等操作我们就不用重复写多次.
2. 提高测试用例可读性
  还是上面的例子，通过page的封装，账户密码非空的测试用例就变成如下格式：

		def test_login_with_username_and_pwd()
			self.login_page.input_username("hahah")
			self.login_page.input_password("123456")
			self.login_page.login()

  如上所示，代码中的调用过程和人为操作过程完全一致，看不到定位元素和操作元素的底层代码，所以让测试用例可读性提高了很多。
3. 提高测试用例的可维护性。
  之前学习过一点点java web知识，其中的MVC模型非常受欢迎，该模型将webapp的视图、控制、业务和持久化处理完美的进行了解耦，并开发出了针对各个层的框架，比如专门转发请求的struts框架，专门处理持久化数据的Hibernate和mybaits等等。我们这里，PO模型也起到了解耦的作用，page对页面定位元素、操作元素的原始操作进行封装，为case层提供业务接口，case专注于业务流程的组合和覆盖。这对于页面经常变动的app有重要作用，如果app的页面随业务复杂化进行增量开发，那么页面元素也会经常改动，这时候，我们只需要改动Page中相应接口（如果仅仅是控件ID变动，我们只需要改变管理控件文件的相关字段即可，无需改动代码），case层不需要太多调整就可以适配新版本，这就大大较低了用例维护成本。
4. 提高测试框架的可扩展性
  这一点是根据我自己的理解加的。综上，PO的主要作用是将Case更加业务化，不要掺杂太多非业务的元素，如果按照这个思路，我们还可以用AppObject（我随口说的，没有这个模型），就是说针对一个App，编写一个Common类，所有对该App的公共操作接口都封装到这个Common中（工作中真的这么干过），case只需要调用自己app的common类的相应接口就可以完成业务流程处理。但是后来想想，还是PO模型更胜一筹。个人理解是这样的，App之所以由多个html或者activity组成，就是为了职责清晰，编码方便管理，Page对应一个页面，也是这个原理，该Page封装的API和其他页面完全分离，其他页面的任何变化不影响该页面。将一个Common class拆分成多个Page class是合理的，对于app新增的页面只需要扩展一个轻量级的Page class，而不需要去更改调试重量级的Common class。

自动化框架

  我是做android自动化相关工作的，所以也学过一点点Android，android系统是典型的分层架构，下面这张图大家应该见过很多次：

  Android系统设计多层架构，为不同层面的开发者提供了便利，对上层App开发者而言，如果需要系统的某个服务，只需要context.getSystemService()就可以获取系统服务的代理，完成相应功能，Android Frameword层为App开发者和ROM App开发者完美地封装了底层细节。
  综上，我们的自动化框架也是这个道理，Google和其他公司提供的自动化平台只是对UI元素进行原始操作的API，对测试业务的封装没有太多意义。待续