Appium PO模式UI自动化测试框架——设计与实践

 
 

1. 目的

  相信做过测试的同学都听说过自动化测试而UI自动化无论何时对测试来说都是比较吸引人的存在。相较于接口自动化来说它可以最大程度的模拟真实用户的日常操作与特定业务场景的模拟那么存在即合理自动化UI测试自然也是广大测试同学职业道路上必不可少的必修课题之一了。

 
 

2. 意义

  说到UI自动化不同的公司、不同的团队往往看待它的态度也存在着很大的差异。项目或产品是否值得做UI自动化执行的方向是否正确落地的成本是否过大大部分的测试团队都会有同样的疑问不管初衷如何KPI? 晋升内部推广效率优化最大的难点一般都在于落地后如何保持一个稳定的使用周期与实际维护的成本是否小于团队投入期望值说人话就是用来UI自动化之后是否大家都能用且可以长久的持续与维护下去。这里博主建议的是在做UI自动化之前先想清楚动机是什么如果真的只是自我拓展、KPI或者个人成果展示那就掌握掌握原理与实操一下即可没有必要在团队内进行推广如果真的是解决团队的实际需求历次回归都需大量的手工每次右移后需要全功能回归功能数量大、场景多、功能增量后耦合较低的情况则可以简单的评估一下引入自动化UI测试预计带来的成果与提升效果。

 
 

3. 设计理念

  之所以选用PO模式也正是因为一般的APP项目或产品功能都是增量式迭代开发的那么必定会面临需要维护的功能页面越来越多的处境。如果是传统的设计模式页面的元素与业务的操作会全部放在一个脚本内有点类似于面向过程的编程理念。这样的模式必定会导致编写与维护的周期与成本增加同样也不利于团队内成员共同维护的模式。
  相较于传统模式POPage Object模式则是将一个页面的所有元素对象定位和对元素对象的操作封装成类测试用例的编写也依照单个页面来进行目的就是实现页面对象和测试用例的分离。

这样做的好处有3点
1 . 低耦合将每个页面单独进行封装类似与面向对象互相之间低耦合即时需要业务流程连续执行也不会互相影响
2 . 易维护当界面发生变化时只需修改对应的页面类中的元素即可其他相关的不会受到影响也无需修改
3 . 易上手基于PO模式的设计理念页面类的实现与细节不会暴露在外都通过公共方法进行提供使用者无需对代码的实现逻辑进行学习只需要对业务与编程语言有足够的了解后直接编写与使用。

  接下来了解了PO模式的优势之后就需要对自动化框架进行设。先考虑清楚使用了自动化测试框架是要解决什么问题这里的问题不能是模糊且没有边界的之后将要自动化的产品、模块、流程进行分类与整理这里一般来说推荐产品的核心主流程一般覆盖happy path即可但如果需要加入一些反向用例与使用场景也是可以的但切忌不要一股脑的把团队的手工测试用例都加进去到了后期你会体验到什么叫维护的时间比测试的时间更长。决定好以上这些了之后就可以进行技术栈与框架的选择了那这里我们选用的是appium+python+unittest的组合来进行PO模式测试框架的设计。当然这里还是推荐大家根据自己的技术栈与公司环境现状来进行有效选择。

 
 

4. PO模式

  这里先声明一点所有的框架都不是一蹴而就的和我们熟知的软件一样无论是结构还是代码都是的一版一版优化出来的所以大家现在看到的框架不会是最初与最终的模样无论是拿来优化、二开还是直接使用都是可以的。如果是自己写哪怕一开始写的很简单也无所谓要始终记住你落地自动化的目的是什么只要能针对产品持续优化与反复总结相信会有令人满意的结果的。

  这里我们先将一个页面类分成两层一个是对象操作层、另一个是业务层。对象操作层指的是页面中的元素定位与单个元素操作业务层顾名思义是把对应的元素操作组合起来形成一些列的业务操作。

  基于PO模式设计框架之前我们还需要了解一下PO模式的6大原则了解了原则之后才能更好的在实现过程中将PO模式的优势融入自己的框架之中。

6大原则

1.The public methods represent the services that the page offers
2.Try not to expose the internals of the page
3.Generally don’t make assertions
4.Methods return other PageObjects
5.Need not represent an entire page
6.Different results for the same action are modelled as different methods

1.用公共方法代表页面提供的功能
2.不要暴露页面元素到外部
3.一般不在方法内加断言
4.方法应该返回其他PO对象
5.不需要封装页面内所有元素
6.同样的行为不同的结果可以封装成不同的方法

个人解读

1.一些可复用的操作可以用公共的方法进行统一封装即使不在同一页面
2.封装实现方法对外只提供方法名或接口名
3.封装的实现方法中不要使用断言把断言可以统一放在测试用例中
4.可以使用其他对象作为一个方法的返回结果比如页面的跳转就可以用方法的结果进行返回
5.页面中只对重要的元素进行PO设计不重要的、非主流程的可以舍弃这里可以更好的迎合只覆盖happy path
6.如果一个操作可能有多种结果的时候将结果封装成不同的方法比如保存成功与保存失败。

 
 

5. 框架设计

5.1 目录结构

这里简单说明下目录的结构
base存放一些框架与页面的公共方法
po存放所有的页面这里就是被测对象相关的被测页面不需要放全部页面
result存放相关的自动化测试结果报告
test_case存放测试用例
根目录下还有一个run文件这个是运行主入口可以设置运行哪些测试用例集与使用什么样的测试报告套件。

 

5.2 实现步骤

  这里的PO模式设计其实没有那么的复杂从目录就可以看出首先将一些基础的元素定位、通用操作封装到对应的BasePage类中这里插一句其实做APP自动化也好做web自动化也好很大程度上开发的代码规范性决定了你的框架实现过程是否顺畅。所以这里大家也可以在平时的工作中与开发事先沟通好一些元素的属性写法规范别觉得不可能行不行事在人为。

  然后根据事先整理好的业务操作流程与页面跳转关系3.设计理念中提到的前置工作输出进行功能的封装这里推荐根据6大原则对相关操作进行实现顺了之后就是熟练工了大同小异的。如果日后出现了布局变更或者业务变更统一在对应的po页面中进行修改即可。另外一些业务逻辑的判断比如是否存在该用户不存在新建存在直接进入也可以放在po中但是需要谨慎这里比较推荐的还是放在测试用例内也方便大家根据不同的情况做断言。

  最后在页面元素、业务操作齐全的状态下进行测试用例的实现一般来说可以先使用冒烟测试的测试用例来进行简单的业务验证当然直接使用系统测试的测试用例也是完全没问题的之后只需要根据之前整理好的用例选单进行转化即可。至于用例的存放目录结构可以根据po页面维度来存放也可以根据业务维度来进行存放见仁见智。

 

5.3 具体实现

5.3.1 base部分

---

这边先定义一个BasePage类用来实现一些公共方法与元素定位的实现webdriver

class BasePage:

    def __init__(self, driver):
        self.driver = driver
        self.driver.implicitly_wait(10)
        
    def by_id(self, id):
        return self.driver.find_element(By.ID, id)
        
    def by_xpath(self, xpath):
        return self.driver.find_element(By.XPATH, xpath)

    def by_class_name(self, class_name):
        return self.driver.find_element(By.CLASS_NAME, class_name)

    def by_uiautomator(self, uiautomator):
        return self.driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, uiautomator)

 

另外后续的一些触屏的操作、元素判断也可以按需放在这里面

    def is_element(self, element):
        source = self.driver.page_source
        if element in source:
            return True
        else:
            return False

    def drag(self, bx=0.50, bw=0.05, by=0.4, bz=0.9):
        x = self.driver.get_window_size()['width']
        y = self.driver.get_window_size()['height']
        sx = x * bx
        ex = x * bw
        sy = y * by
        ey = y * bz
        return self.driver.swipe(sx, sy, ex, ey, 1000)

 

这里我定义了另一个driver_setup的方法方便每次设备启动使用

def driver_setup():
    desired_caps = dict()
    desired_caps['platformName'] = 'Android'
    desired_caps['platformVersion'] = '10'
    desired_caps['deviceName'] = '你自己的设备名'
    desired_caps['appPackage'] = '包名'
    desired_caps['appActivity'] = '启动名'
    desired_caps['noReset'] = True # 不重置session信息
    desired_caps['fullReset'] = False # 效果类似与卸载APP 如果不想每次重新登录设为False
    return desired_caps

 

5.3.2 po部分

---

目录大致如上这里值得注意的是不要把APP里所有的页面都加入到自动化测试中100%的自动化测试覆盖率会让你苦不堪言也大可不必。将每次必须回归的重要流程与高重复业务流程、场景加入即可。

 

以下就是po中的创建顾客页面的实现方法了直接继承BasePage类这里有几个例子需要关注的是性别选择可以封装成两个方法尽量不用同一个另一个如果是点击类事件单结果事件直接click就行不用单独在封装完元素后再进行业务操作封装备注这样的多结果事件则要在下面单独进行业务指定。

class CustomerCreatePage(BasePage):
    """
    定义封装创建客户页面的各类操作
    创建客
    创建客户并开卡
    """

    # 定义会员编号输入框
    def customer_number(self):
        return self.by_id('com.tiffany.rta.debug:id/edt_customer_number')

	# 定义姓名输入框
    def customer_name(self):
        return self.by_id('com.tiffany.rta.debug:id/edt_customer_name')

    # 定义手机输入框
    def customer_mobile(self):
        return self.by_id('com.tiffany.rta.debug:id/edt_customer_mobile')

    # 定义性别选择
    def customer_sex(self):
        return self.by_id('com.tiffany.rta.debug:id/tv_customer_sex')

    # 定义性别内选择项目-男
    def customer_sex_item_male(self):
        return self.by_id('com.tiffany.rta.debug:id/tv_customer_boy').click()
        
    # 定义性别内选择项目-女
    def customer_sex_item_female(self):
        return self.by_id('com.tiffany.rta.debug:id/tv_customer_girl').click()
        
    # 定义生日选择框
    def customer_birthday(self):
        return self.by_id('com.tiffany.rta.debug:id/tv_customer_birthday')

    # 定义备注输入框
    def customer_memo(self):
        return self.by_id('com.tiffany.rta.debug:id/ed_remark')

    # 定义保存并开卡按钮
    def save_and_register_card_button(self):
        return self.by_id('com.tiffany.rta.debug:id/mb_save_open_card').click()

 

接下来就是组合多个元素进行业务操作的定义

    # 定义新建顾客操作
    def do_create_customer(self):
        self.customer_number().send_keys('00001')
        self.customer_name().send_keys('自动化测试01')
        self.customer_mobile().send_keys('13200000000')
        self.customer_sex()
        self.customer_sex_item_male()
        self.save_button()

 

5.3.3 test_case部分

---

测试用例类继承unittest下的TestCase初始化的时候将对应的用例业务流程加入到里面另外在具体的测试用例中需要加对应的判断逻辑与操作步骤完整的添加在里面。使用try捕获异常的时候记得把对应的报错名也写上一是方便定位问题二是有可能会导致即使用例失败测试报告上的结果也是pass。

class TestCustomerListPage(unittest.TestCase):
    """
    定义客户列表界面的测试用例
    创建客户
    """
    
    # 初始化必要的设备信息与业务页面
    def setUp(self):
        self.driver = webdriver.Remote('http://localhost:4723/wd/hub', driver_setup())
        self.base_page = BasePage(driver=self.driver)
        self.home_page = HomePage(driver=self.driver)
        self.customer_list = CustomerListPage(driver=self.driver)
        self.customer_detail = CustomerDetailPage(driver=self.driver)
        self.customer_create = CustomerCreatePage(driver=self.driver)
	
	# 测试用例1 -- 创建顾客
    def test_1_create_customer(self):
        self.home_page.go_customer()
        customer_name = '自动化测试01'
        # 业务逻辑判断 -- 是否存在该新客
        if self.base_page.is_element(customer_name):
            self.customer_list.select_customer()
            self.customer_detail.do_delete_customer()
            self.home_page.go_index()
            self.home_page.go_customer()
            if self.base_page.is_element(customer_name):
                self.customer_check.check_pass()
            else:
                self.customer_list.goto_create_customer()
                self.customer_create.do_create_customer()
                self.customer_detail.back_button()
        else:
            self.customer_list.goto_create_customer()
            self.customer_create.do_create_customer()
            self.customer_detail.back_button()
        try:
            self.assertTrue(self.driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR,
                                                     'new UiSelector().text("自动化测试01")'))
        except NoSuchElementException as e:
            return e
        sleep(5)

    def tearDown(self):
        self.driver.quit()


if __name__ == "__main__":
    unittest.main()

 

5.3.4 run部分

---

具体的测试用例报告模板大家可以自由选择这边使用的是HTMLTestReportCN启动的方式都是大同小异的无非就是根据自己的测试场景进行定制就行。另外测试模板的组合和样式有兴趣的同学可以自己对报告脚本进行修改打造更适合自己团队需求的测试报告。

# 两套测试报告模板路径只用一个的可以就定义一个
report_path = os.path.join(os.getcwd() + '\\result')
result_path = os.path.join(report_path, 'report.html')
# 测试套件路径根据需求修改
test_dir = os.path.join(os.getcwd() + '\\test_case\\trade')


# 执行指定测试用例
def test_suit():
    suit = unittest.TestSuite()
    suit.addTest(TestOrderResultPage('test_1_order_result'))
    suit.addTest(TestOrderResultPage('test_2_order_result_home_page'))
    return suit


# 执行测试用例集
dis = unittest.defaultTestLoader.discover(test_dir, pattern="test*.py")


if __name__ == "__main__":
    with open(result_path, 'wb') as fp:
        runner = HTMLTestReportCN.HTMLTestRunner(stream=fp, title='自动化APP测试报告',
                                                 description='基于自动化APP测试框架产生的测试报告')
        runner.run(test_suit())

 
 

6. 注意点

1.PO模式虽然可以解决UI自动化测试中设计的部分问题也仍然是目前比较主流的设计方案后期面对大量的业务页面增加的情况虽然可以使用通用页面来解决部分问题但仍然避免不了界面与业务改动后大量调试代码的情况出现。所以这也是很多公司无法将大量成本聚焦在UI自动化测试的原因将UI自动化应用于部分主要业务的做法还是值得提倡的它也只是提高测试团队工作效率与投入产出比的一项手段而已千万不可本末倒置

2.测试用例的合理设计与执行安排如果你的测试用例的相关命名、流程设计、存放路径过于凌乱与潦草的话相信我后期当框架具有一定的规模后你会发现往往在维护测试用例时花费的精力要远远大于你的执行时间。与手工测试用例一样无效用例始终都会出现在你的框架之中这是无可避免的但如何快速定位与规整这些用例就成了后期需要面对的日常问题之一所以用例实现之初的命名规则、存放路径、实现时的备注就成了日后减少维护工作量的良好开端

3.相较于接口自动化UI自动化的性价比还是有一定的局限性针对这样的情况测试团队中如果要投入UI自动化的话可能就需要将团队中的成员定位做好一定的有效安排。框架设计与实现的问题不大有专业的业务理解与一定的代码功底一般都可以很好的完成对应的测试框架这里只针对维护层面的工作来说是专职人员定岗安排还是团队成员穿插进行都需要根据各自的团队实际情况来分配各有利弊毕竟维护是一件费时费力的持久性工作。