自从17年开始就不再怎么关注UI自动化测试了，也就很少关注Selenium的知识体系，在当时的背景和环境下有很多的思考和选择点，基于UI的自动化测试并不是所有的场合下都使用它合适，任何一个技术，要把它应用在合适的场景下才能够显示出它的最大的价值。今天这里就简单的对Page Objects做一个介绍。
基于UI的自动化测试的痛点在于如何可以高效的维护并且满足业务迭代的需求，或者说这是自动化测试的基本诉求，高效，维护方便，能够提升测试效率，从而带来研发效率的提升，最大达到工程效率的提升。在UI自动化测试中，产品的快速迭代，导致页面元素的属性经常变来变去，另外一点是数据如何分离，和大批量的自动化测试用例如何可以在很短的时间范围内执行完成并且给出比较权威的测试报告，能够反馈出覆盖到的所测试产品的产品质量，从而给管理者带来有价值的信息。坦白说，这个过程是复杂的，做不代表就存在价值，但是存在就是合理，合理不代表就是正确，所以就有了持续不断的优化和持续改进的过程。
基于页面对象设计模式存在这么几个优点，主要是：
1、创建可以跨多个测试用例共享的代码
2、减少重复代码执行的数量
3、如果用户界面发生变化后，只需要在一个地方维护就可以了
那么基于如上的思想，是否能够写一个框架来达到这样的一个诉求了？另外一点比较困难的是在元素定位中存在8种方法，如何进行整合。在看Appium源码的时候，Appium中元素定位的类MobilyBy，见它的源码：
在如上的源码中，让人惊喜的是看到了By类，也就是说MobileBy类继承了By类，这也就意味着完全可以把Selenium和Appium整合起来，特别是在元素定位的部分，但是依然存在任何把这么多的元素定位的方法整合起来，在Selenium的源码的WebElement类中，存在方法find_element，在该方法中可以看到对元素各个属性的判断，见源码：
基于如上的源码，可以得到，关于元素属性的整合可以使用find_element方法来完成，那么关于如何Selenium和Appium，可以使用工厂设计模式来完成这个整合的任务，基于如上的分析，编写一个工厂类，编写工厂方法，创造对应的实例来达到要测试的产品到底是WEB还是APP，编写基础类base.py，它的源码：
注释：在上面的代码中，在Factory类中定义了工厂类，Factory类生成WebDriver对象。定义Factory类创建不同的WebDriver对象。WebUI类和AppUI类继承自WebDriver类，WebUI和AppUI可以看作是具体的测试对象产品（Web和App）。在Factory类中定义了工厂方法createDriver，工具字符串类型driver的值，生成不同的WebDriver对象。如果driver对象是“web”，则调用WebUI，返回WebUI类的实例。如果driver对象是“app”，则调用AppUI，返回AppUI类的实例。
解决了如上的问题后，下来的代码相对来说比较好写，在对象层中继承WebUi或者AppUi，然后定位元素属性，编写对应的方法，这里以百度搜索为案例，在百度搜索输入框输入搜索的关键字，并且获取到这个关键字，使用到的方法是get_attribute()，创建模块baidu.py，它的源码为：
下来在测试层编写具体的测试代码，但是测试固件要分离，在之前的文章中也介绍过这部分，我今晚再解释下，在每一个测试模块的测试类中，都需要继承unittest模块中的TestCase，在测试固件中需要初始化Webdriver，和指定要测试的浏览器，测试地址，打开浏览器和关闭浏览器的操作，问题是一个系统的测试会编写很多的测试模块以及测试类，如果需要在测试的浏览器由Chrome替换为Firefox，或者测试地址由A变为B，那么需要在测试测试固件中来修改测试地址，和指定要测试的浏览器，利用继承的思想，把测试固件分离后，只需要修改一个地方即可，在对象层增加模块init.py，编写类分离测试固件，见这部分的源码：
下来就是测试具体的测试用例，在tests包下创建测试模块，编写测试类，继承测试固件的类和对象层的类，同时编写的测试用例一定要加断言，没有断言的自动化测试用例是无效的，测试用例这部分代码简单，搜索关键字，获取搜索的关键字，然后断言验证它，它的源码为：
如上代码执行后的结果为：
下来是UI自动化测试中测试数据的分离，这部分后面再详解。关于UI的自动化测试，目前应用的场景可能在快速迭代的产品中应用不是很合
网友评论