UI自动化测试之设计框架
目的相信做过测试的同学都听说过自动化测试，而UI自动化无论何时对测试来说都是比较吸引人的存在。
相较于接口自动化来说它可以最大程度的模拟真实用户的一样平常操作与特定业务场景的模拟，那么存在即公道，自动化UI测试自然也是广大测试同学职业门路上必不可少的必修课题之一了。
意义
说到UI自动化，差异的公司、差异的团队往往对待它的态度也存在着很大的差异：
项目或产品是否值得做UI自动化？
执行的方向是否正确？
落地的成本是否过大？
大部分的测试团队都会有同样的疑问，不管初衷如何（KPI、晋升、内部推广、服从优化），最大的难点一般都在于落地后如何保持一个稳固的利用周期与实际维护的成本是否小于团队投入盼望值，说人话就是用来UI自动化之后是否各人都能用且可以长久的持续与维护下去。
这里博主建议的是，在做UI自动化之前先想清楚动机是什么：
假如真的只是自我拓展、KPI或者个人成果展示，那就掌握掌握原理与实操一下即可，没有必要在团队内举行推广；
假如真的是办理团队的实际需求：历次回归都需大量的手工，每次右移后需要全功能回归，功能数目大、场景多、功能增量后耦合较低的情况，则可以简单的评估一下引入自动化UI测试预计带来的成果与提拔结果。
设计理念
之以是选用PO模式，也正是因为一般的APP项目或产品功能都是增量式迭代开辟的，那么肯定会面对需要维护的功能页面越来越多的处境。
假如是传统的设计模式，页面的元素与业务的操作会全部放在一个脚本内，有点类似于面向过程的编程理念。这样的模式肯定会导致编写与维护的周期与成本增加，同样也不利于团队内成员共同维护的模式。
相较于传统模式，PO（Page Object）模式则是将一个页面的所有元素对象定位和对元素对象的操作封装成类，测试用例的编写也依照单个页面来举行，目的就是实现页面对象和测试用例的分离。
这样做的好处有3点：
低耦合：将每个页面单独举行封装，类似与面向对象，相互之间低耦合，即时需要业务流程一连执行也不会相互影响；
易维护：当界面发生变化时，只需修改对应的页面类中的元素即可，其他相关的不会受到影响也无需修改；
易上手：基于PO模式的设计理念，页面类的实现与细节不会暴露在外，都通过公共方法举行提供，利用者无需对代码的实现逻辑举行学习，只需要对业务与编程语言有足够的相识后直接编写与利用。
接下来相识了PO模式的优势之后，就需要对自动化框架举行设。
先思量清楚利用了自动化测试框架是要办理什么标题，这里的标题不能是模糊且没有边界的，之后将要自动化的产品、模块、流程举行分类与整理，这里一般来说推荐产品的核心主流程，一般覆盖happy path即可，但假如需要参加一些反向用例与利用场景也是可以的，但切忌不要一股脑的把团队的手工测试用例都加进去，到了后期你会体验到什么叫维护的时间比测试的时间更长。
决定好以上这些了之后，就可以举行技能栈与框架的选择了，那这里我们选用的是appium+python+unittest的组合来举行PO模式测试框架的设计。当然，这里还是推荐各人根据自己的技能栈与公司情况现状来举行有用选择。
PO模式
这里先声明一点，所有的框架都不是一蹴而就的，和我们熟知的软件一样，无论是结构还是代码都是的一版一版优化出来的，以是各人如今看到的框架不会是最初与终极的模样，无论是拿来优化、二开还是直接利用都是可以的。
假如是自己写，哪怕一开始写得很简单也无所谓，要始终记住你落地自动化的目的是什么，只要能针对产品持续优化与反复总结，相信会有令人满意的结果的。
这里我们先将一个页面类分成两层，一个是对象操作层、另一个是业务层。
对象操作层指的是页面中的元素定位与单个元素操作；
业务层顾名思义是把对应的元素操作组合起来形成一些列的业务操作。
基于PO模式设计框架之前，我们还需要相识一下PO模式的6大原则，相识了原则之后才能更好地在实现过程中将PO模式的优势融入自己的框架之中。
6大原则
1.用公共方法代表页面提供的功能；
2.不要暴露页面元素到外部；
3.一般不在方法内加断言；
4.方法应该返回其他PO对象；
5.不需要封装页面内所有元素；
6.同样的行为差异的结果可以封装成差异的方法。
个人解读
1.一些可复用的操作，可以用公共的方法举行统一封装，即使不在同一页面；
2.封装实现方法，对外只提供方法名或接口名；
3.封装的实现方法中不要利用断言，把断言可以统一放在测试用例中；
4.可以利用其他对象作为一个方法的返回结果，比如页面的跳转，就可以用方法的结果举行返回；
5.页面中只对重要的元素举行PO设计，不重要的、非主流程的可以舍弃（这里可以更好的迎合只覆盖happy path）；
6.假如一个操作大概有多种结果的时候，将结果封装成差异的方法，比如保存乐成与保存失败。
框架设计
目次结构
https://i-blog.csdnimg.cn/blog_migrate/dca8b8a78566afae9301dbf58df57d97.png
这里简单说明下目次的结构：
base：存放一些框架与页面的公共方法；
po：存放所有的页面，这里就是被测对象相关的被测页面，不需要放全部页面；
result：存放相关的自动化测试结果报告；
test_case：存放测试用例。
根目次下还有一个run文件，这个是运行主入口，可以设置运行哪些测试用例集与利用什么样的测试报告套件。
实现步调
这里的PO模式设计其实没有那么的复杂，从目次就可以看出，首先将一些基础的元素定位、通用操作封装到对应的BasePage类中。
这里插一句，其实做APP自动化也好，做web自动化也好，很大程度上开辟的代码规范性决定了你的框架实现过程是否顺畅。以是这里各人也可以在平常的工作中与开辟事先沟通好一些元素的属性写法规范，别以为不大概，行不行事在人为。
然后根据事先整理好的业务操作流程与页面跳转关系（设计理念中提到的前置工作输出）举行功能的封装，这里推荐根据6大原则对相关操作举行实现，顺了之后就是纯熟工了，大同小异的。假如日后出现了布局变更或者业务变更，统一在对应的po页面中举行修改即可。
另外，一些业务逻辑的判断，（比如是否存在该用户，不存在新建，存在直接进入），也可以放在po中，但是需要谨慎，这里比较推荐的还是放在测试用例内，也方便各人根据差异的情况做断言。
末了在页面元素、业务操作齐备的状态下举行测试用例的实现，一般来说可以先利用冒烟测试的测试用例来举行简单的业务验证，当然直接利用体系测试的测试用例也是完全没标题的，之后只需要根据之前整理好的用例选单举行转化即可。至于用例的存放目次结构可以根据po页面维度来存放，也可以根据业务维度来举行存放，见仁见智。
详细实现
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
po部分
https://i-blog.csdnimg.cn/blog_migrate/6cefcf4098125c44246ad2ee1db403d4.png
目次大抵如上，这里值得注意的是，不要把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() 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() 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()) 注意点
1、PO模式固然可以办理UI自动化测试中设计的部分标题，也仍旧是目前比较主流的设计方案，后期面对大量的业务页面增加的情况，固然可以利用通用页面来办理部分标题，但仍旧制止不了界面与业务改动后大量调试代码的情况出现。
以是这也是许多公司无法将大量成本聚焦在UI自动化测试的缘故原由，将UI自动化应用于部分主要业务的做法还是值得提倡的，它也只是提高测试团队工作服从与投入产出比的一项本领而已，千万不可舍本逐末。
2、测试用例的公道设计与执行安排，假如你的测试用例的相关命名、流程设计、存放路径过于凌乱与潦草的话，相信我，后期当框架具有一定的规模后，你会发现往往在维护测试用例时耗费的精神要远远大于你的执行时间。
与手工测试用例一样，无效用例始终都会出如今你的框架之中，这是无可制止的，但如何快速定位与规整这些用例就成了后期需要面对的一样平常标题之一，以是用例实现之初的命名规则、存放路径、实现时的备注就成了日后淘汰维护工作量的良好开端。
3、相较于接口自动化，UI自动化的性价比还是有一定的局限性，针对这样的情况，测试团队中假如要投入UI自动化的话大概就需要将团队中的成员定位做好一定的有用安排。
框架设计与实现的标题不大，有专业的业务明白与一定的代码功底一般都可以很好的完成对应的测试框架，这里只针对维护层面的工作来说，是专职职员定岗安排还是团队成员穿插举行都需要根据各自的团队实际情况来分配，各有利弊，毕竟维护是一件费时费力的持久性工作。
末了感谢每一个认真阅读我文章的人，礼尚往来总是要有的，固然不是什么很值钱的东西，假如你用得到的话可以直接拿走：
https://i-blog.csdnimg.cn/blog_migrate/e030ef1dc3d8bab491eea55196fbfb4e.png
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战堆栈，这个堆栈也陪伴上万个测试工程师们走过最艰巨的路程，盼望也能帮助到你!有需要的小同伴可以点击下方小卡片领取
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]