作者简介：博主是一位测试管理者，同时也是一名对外企业兼职讲师。
主页地址：【Austin_zhai】
目的与景愿：旨在于能帮助更多的测试行业人员提升软硬技能，分享行业相关最新信息。
声明：博主日常工作较为繁忙，文章会不定期更新，各类行业或职场问题欢迎大家私信，有空必回。

阅读目录

• 1. 目的
• 2. 意义
• 3. 设计理念
• 4. PO模式
• 5. 框架设计
• • 5.1 目录结构
  • 5.2 实现步骤
  • 5.3 具体实现
  • • 5.3.1 base部分
    • 5.3.2 po部分
    • 5.3.3 test_case部分
    • 5.3.4 run部分
• 6. 注意点

1. 目的

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

2. 意义

  说到UI自动化，不同的公司、不同的团队往往看待它的态度也存在着很大的差异。项目或产品是否值得做UI自动化？执行的方向是否正确？落地的成本是否过大？大部分的测试团队都会有同样的疑问，不管初衷如何，（KPI” />
这里简单说明下目录的结构：
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自动化的话可能就需要将团队中的成员定位做好一定的有效安排。框架设计与实现的问题不大，有专业的业务理解与一定的代码功底一般都可以很好的完成对应的测试框架，这里只针对维护层面的工作来说，是专职人员定岗安排还是团队成员穿插进行都需要根据各自的团队实际情况来分配，各有利弊，毕竟维护是一件费时费力的持久性工作。