背景:
随App产品不断迭代更新,给测试人员也增加了测试工作量,为了保证发布的内容确保没有问题,每次回归测试是保证发布前的最后一道防锁线,项目与迭代每次发布的时候打包平均要四次左右,每次打包都要回归测试或者回归测试的时候发现问题修改再次打包,就要再次整体回归测试,这样给测试增加了大量繁琐重复的测试,耗费了大量的时间与精力进行回归。
探索减少重复的回归测试,避免每次上限前重复的人工回归测试且保证发布版本的稳定,迫切的需要引进自动化测试来协助我们进行回归测试,最终目的是为了保证产品质量。
自动化实现过程:
1.框架的选取
常用的框架:Appium、Airtest、Robotium、UIAutomator等
选取Appium框架(相比其他框架):开源、实现跨平台(iOS、Android)、多语言(python、Java、JavaScript、nodejs )、丰富的定位元素方式、更高的脚本复用性等
2.框架的支撑(python+appium+unittest+ios/android)
备注:配置环境不在本章中涉及
2.1.设计自动化测试用例
自动化测试用例设计的要点:1.一个脚本是一个完整的场景;
2.尽量只做功能中正向逻辑的验证,不要考虑太多逆向逻辑的验证(除非有必要);
3.脚本之间不要产生关联性,也就是说编写的每一个脚本都是独立的,不能依赖或影响其他脚本;
简单来说就是不是所有的手工测试都可以转成自动化测试,自动化测试是协助配合手工测试而不是取代手工测试,毕竟手工测试看一下就知道是不是正确,但是自动化需要写一堆代码验证是否正确,这样会花费大量的时间编写脚本与维护,这样也不划算例如:考试任务主要验证作答、保存进度、提交、查看解析等主要功能点,至于同个用户在不同端提交、删除题目、提交失败等不需要考虑在自动化测试中。
2.2.测试数据驱动
说完测试用例设计思路,因为每个模块或者每个功能点都有测试用例数据(标题、数据、期望值、实际值等),就不得不提数据与代码分离(数据驱动)。修改测试数据而不影响代码。
实现(Excel+OpenPyXl):
1.Excel编写测试用例:
说明:id:测试用例的ID,读取写入方便定位、title:测试用例的标题,方便阅读、data:测试用到的数据、expected:测试用例的预期结果、result:实际测试的结果、actual:运行结果(成功:PASS、失败:FALL)
2.OpenPyXl读取数据:
OpenPyXl是一个Python的模块 可以用来处理excle表格,支持读取与写入数据。
读取数据的实现:用for循环读取excel中的数据,读取后存入一个数组中。方便后面用到的时候直接调用
写入数据(测试结果的写入到excel中):封装写入方法,执行用例后调用该方法写入数据
2.3.获取元素定位的方式
测试用例设计完成后,怎么执行呢?怎么把用例变成自动化测试呢?那就不得不提到执行自动化测试的基石:元素定位
自动化测试最根本的就是操作页面上的元素,首先我们要找到这些元素,然后才能操作这些元素。
Appium:
步骤1:
步骤2:
配置参数:platformVersion:系统版本、deviceName:设备名称、platformName:平台版本(Android/IOS)、appPackage:包文件名、appActivity:app启动的入口的activity
步骤3:获取元素定位
2.4.元素定位操作:
元素定位方式(八种方式定位):
备注:下面常用的定位方式也是我经常用到的
1.ID定位: find_element_by_id()
2.class定位:find_element_by_class_name()
3.文本定位Android独有:find_element_by_android_uiautomator()
4.xpath定位:find_element_by_xpath()
2.5.unittest框架:单元测试框架
获取了元素定位后,怎么执行用例断言是否符合预期与生成一份测试报告呢?
unittest是Python单元测试框架,类似于JUnit框架。
unittest的使用:
1.testcase必须继承unittest.testcase
2.常用的断言:
assertEqual(a, b) a == b
assertNotEqual(a, b) a != b
assertIn(a, b) a in b
assertNotIn(a, b) a not in b
3.执行测试用例生成报告:
1.添加testcase文件到TestSuite中,执行所有的test开头的py文件。
2.添加执行测试报告,添加执行标题、执行人员等,执行完成后存放的位置。
3.执行所有的testcase文件。
备注:HTMLTestRunner要下载引用,百度一下就可以找到
执行完成后的测试报告:
2.5.PO(Page Object)设计模式:
走到这一步后,实际上自动化测试已经走了90%(😁心里想着真是不容易呀😂),知道怎么获取元素与元素定位后,再通过unittest框架就可以实现自动化测试了,那为什么还引用PO设计模式呢?那请思考下面的问题😱?
问题:自动化测试就是通过大量的元素定位来操作,随着自动化测试的丰富,测试套件的增长,脚本也变得越来越多。如果我们需要维护10个页面,100个页面?那么页面元素的任何改变都会让我们脚本维护变得繁琐复杂,而且容易耗时易出错(干货来了)。
那么怎么解决呢?
UI自动化中,常用的一种方式,引入PO:页面对象模式来解决,PO能让我们的测试代码变得可读性更好,可维护性高,复用性高。
实现:在PO下,应用程序的每一个页面都有一个对应的page class,每一个pageclass维护这该元素集和操作这些元素的方法。
例如:进入网校的模块
元素定位:UI-page
测试执行:testcase
在testcase中调用joinschool中的方法,使得testcase中只有逻辑,没有大量的元素定位业务,假如进入网校界面中的元素修改,不用修改逻辑代码,只修改定位元素即可
优势:
1、PO提供了一种业务流程与页面元素操作分离的模式,这使得测试代码变得更加清晰。
2、页面对象与用例分离,使得我们更好的复用对象。
3、可复用的页面方法代码会变得更加优化
4、更加有效的命名方式使得我们更加清晰的知道方法所操作的UI元素。
总结:
以上就是APP实现自动化测试的思路(web自动化除框架不同,思路大致相同),看下来实现起来并没有那么难,但是难的是以后花费时间去维护自动化代码🙃。
但是APP自动化测试是趋势,执行自动化测试可以让测试有更多的精力来关注复杂场景,做更多更深层次的测试,特别是自动化回归测试来提高效率是很明确的目标。
😜加油吧 新时代的农民工🤪