精华内容
下载资源
问答
  • 今天我会详细的描述一个【UI自动化实战在实际工作中的应用】,这是之前贝壳找房我们团队做的一个真实UI自动化案例,由于APP版本更新迭代太多次,代码也有缺失,所以一些细节没法完全描述清楚。

    大家好,我是小怡。之前测试交流群里有同学问“有没有自动化测试在工作中的案例可以分享“,有是有的。

    今天我会详细的描述一个【UI自动化实战在实际工作中的应用】,这是之前贝壳找房我们团队做的一个真实UI自动化案例,由于APP版本更新迭代太多次,代码也有缺失,所以一些细节没法完全描述清楚。
    但我会把做这个项目的思路和流程,详细的分享出来,希望能帮到大家。

    一、自动化测试的主要分类

    自动化的形式主要可以分为接口自动化和UI自动化

    根据测试金字塔理论,越往顶层,ROI(投入产出比)就越高。
    在这里插入图片描述
    一般大家都会加大力度投入到接口自动化的建设当中,而UI自动化因为投入产出比太低了,所以基本上对UI自动化的建设会投入比较少。

    但这并不代表UI自动化就完全没有必要做,在下边部分我会列举3种【适合做UI自动化的场景】。

    二、适合做UI自动化的场景

    一般来说有3种场景是比较适合做UI自动化的:回归验证、巡检、移动端埋点测试。

    1)回归验证

    项目上线或者APP发版,传统的手工测试耗时较多。一到上线发版日,尤其是改动较大的发版,同事们都是采用手工用例走查的方式去进行验证回归,压力非常大!

    当时一般一次上线回归验证,基本上都要花费30分钟-2个小时,对于测试人员和开发人员来说,都是一种煎熬。

    有时候人手不够了,还需要产品、运营一块协助回归验证,效率十分低下。

    这个时候,可以用UI自动化去覆盖一些功能改动较少的功能。

    2)巡检

    线上环境复杂,容易出现各种意想不到的问题,而手工巡检测试压力大。

    比如:

    运营配置错误;

    用户的一些非常规的操作;

    不同手机终端的兼容性问题。

    这些问题从暴露给用户,到反馈到开发这边,再到开发修复解决,可能都已经过去很长时间。

    以往,同事一般会定期人工线上巡检去发现一些线上问题。

    这么做确实也有效果,但问题在于:

    人工巡检也会耗费不少测试时间,有时候忙起来,就很难坚持执行下去。

    这个时候,可以用UI自动化去覆盖一些主流程,确保主流程不要出问题。

    3)移动端的埋点测试

    如果一直做简单且重复性高的测试工作,不仅效率低,也非常严重打击测试人员的工作积极性。

    最典型的就是移动端的埋点测试,传统的测试方法,就是在手机上操作,触发埋点上报,然后通过手机抓包,获取埋点数据,然后再依据埋点文档,去对每个字段进行一一人工校验。

    这一通操作很无脑,但是实际上花费的时间是相当多的,埋点需求一多起来,可能测一天都测不完,还非常消磨测试人员的精力:每次测试完埋点,都感觉自己的视力下降了很多(对数据废眼)。

    这个时候,可以尝试用UI自动化去自动触发埋点,并通过一些校验逻辑,对埋点进行自动校对。

    4)除此之外,UI自动化还可以解决:

    APP 兼容性测试

    APP 竞品对比测试

    APP 数据抓取

    如果你还有更多的UI自动化实践案例,欢迎评论区交流。

    三、UI自动化实战案例

    目录如下:

    1)项目背景

    2)项目选型

    3)开始安装部署

    4)执行测试方案

    1)项目背景

    之前我还在贝壳找房的时候,随着公司业务的不断增长,APP功能越来越多,每一次APP大发版,测试人员都需要花费比以往更多的精力去进行线上回归验证。
    据统计,我们部门目前线上回归验证的手工用例数大概在1000条左右,如果全部用例都需要进行回归测试,需要花费至少2个小时才能完成,这无疑给APP的测试同学带来极大的挑战。
    如果用例回归不充分,把Bug遗留到生产环境上,将会给用户带来不好的体验。
    传统的手工测试,已经很难满足日常的测试需要,我们发现,不少用例其实是可以通过自动化的形式去实现的,这将大大缓解APP测试同学的压力。
    下面给大家展示部分“手工用例”转换成“自动化“的表格截图,虽然方法很笨,但是我们当时就是这么来统计自动化的场景覆盖率的。在这里插入图片描述
    既然用例已经梳理清楚了,我们就开始准备着手开发UI自动化框架和脚本了,从头开发肯定是不可能的,实际工作中没有那么多时间去重复造轮子,所以我们首先要做的,是要选一个好的轮子,然后在此基础上去做开发。

    2)项目选型

    在 APP 的UI自动化领域,近几年涌现了很多很多优秀的 UI自动化测试框架(工具)。

    比如:Appium、Robotium、Instrumentation、UIAutomator、ATX等等。

    因为团队内的小伙伴,基本上都是 Pythoner,所以我们在测试框架选型时,优选考虑对 Python 有良好支持的框架。

    经过一轮对比,发现 Appium 和 ATX 对 Python 的支持比较好,并且都有 Android 和 iOS 的成熟解决方案。

    所以后面决定在 Appium 和 ATX 之间进行选择。

    以下是Appium和ATX的一些对比情况:在这里插入图片描述
    项目开始初期,我们也同时搭建了 Appium 和 ATX 的运行环境。
    后来因为 Appium 安装部署相对来说比较复杂、项目启动和运行比 ATX 稍微慢一些(框架比较重)、Appium 配置比较繁琐。
    所以我们逐步放弃了 Appium,最终采用 ATX 进行 UI自动化工程的搭建。

    这里可以再简单介绍一下 ATX 的生态圈:
    在这里插入图片描述
    可以看出来 ATX 还是很强大的,项目也在不断维护和更新。
    不过,光有底层的UI自动化驱动框架还不行,你还得需要有专业的测试框架来管理你的自动化测试项目(用例)。
    pytest 和 unittest 是最流行的解决方案。
    我们欣喜的发现,在GitHub上已经有人把脚手架工程给做出来了:ATX-Test。
    ATX-Test是基于ATX-Server的UI自动化测试框架,可以实现多设备的并行测试,并生成统一的测试报告。
    采用的技术栈包括:
    在这里插入图片描述
    既然已经有比较好用的项目了,我们直接在该框架下进行二次开发就好了,避免重复造轮子。
    ATX-Test目前不支持iOS,我们在二次改造的时候,就可以把 facebook-wda的驱动给集成进去。

    3)安装部署的步骤

    使用ATX的前提条件有:
    Python 运行环境(Python 3.6+ (社区反馈3.8.0不支持, 但是3.8.2支持)
    Android版本 4.4+(需要安装uiautomator2)
    iOS(需要安装 facebook-wda)

    安装部署步骤
    第一步,安装uiautomator2
    (适合 Android)

    pip install --upgrade --pre uiautomator2
    

    对 Android 手机进行初始化

    # init 所有的已经连接到电脑的设备
    python -m uiautomator2 init
    
    # 高阶用法
    # init and set atx-agent listen in all address
    python -m uiautomator2 init --addr :7912
    

    关于 u2 的详细使用文档,可以参考:

    https://github.com/openatx/uiautomator2

    此处不再赘述。

    第二步,安装 weditor

    pip install -U weditor
    

    启动 weditor

    python -m weditor
    

    weditor 可以抓取安卓控件元素、自动生成脚本代码并进行Debug。在这里插入图片描述
    第三步,安装 facebook-wda(适合iOS)

    需要 MacOS 运行环境,并且需要安装 Xcode。

    打包 WebDriverAgentRunner

    xcodebuild -project WebDriverAgent.xcodeproj -scheme
    WebDriverAgentRunner -destination 'platform=iOS Simulator

    WDA在真机上运行需要一些配置,可以参考这篇文章:

    ATX 文档 - iOS 真机如何安装

    WebDriverAgent:

    https://testerhome.com/topics/7220

    配置完之后运行下面的命令即可(需要用到Mac的密码,以及设备的UDID)

    # 解锁keychain,以便可以正常的签名应用
    security unlock-keychain -p $your-mac-password-here ~/Library/Keychains/login.keychain
    
    # 获取设备的UDID
    UDID=$(idevice_id -l | head -n1)
    
    # 运行测试
    xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination "id=$UDID" test
    

    安装 facebook-wda

    pip3 install -U facebook-wda
    关于 facebook-wda 的使用文档,可以参考:

    https://github.com/openatx/facebook-wda
    此处不再赘述。

    第四步,iOS抓取控件的方法,一般有常用的有两种方式:
    Appium 团队提供的 appium-ios-inspector 项目地址:
    https://github.com/mykola-mokhnach/Appium-iOS-Inspector

    Macaca的app-inspector工具 项目地址:
    https://macacajs.github.io/app-inspector/cn/

    第五步,关于云真机集群部署
    什么是云真机集群,说白了也就是能够在云平台上远程去调度移动端真机(手机管理平台)。
    现有的云真机集群,一般可以分为:公有云真机集群和私有云真机集群。

    公有云真机集群,是测试行业内一些公司提供的云真机服务。
    比较著名的有Testin、WeTest等。
    优点:无需自建,而且有海量手机设备可以选。
    缺点:要钱,贵。
    在这里插入图片描述
    私有云真机集群,需要自己采购真机设备和专用机柜在这里插入图片描述
    我们最后决定搭建私有云真机环境,来行真机调度和管理。
    真机采用测试淘汰下来的机器,有时候也会针对性的去买一些热门机型进行UI自动化测试。

    私有云真机有没有什么优缺点?
    优点:机器是自己的,平台是自己的,想怎么玩就怎么玩。
    缺点
    真机成本也很高。

    如果是有线连接的话,电池长时间充电,有较大耗损,电池会鼓包,如果假期无人值守,最坏的情况会导致机柜爆炸。

    如果是无线连接的话,电池的监控又是一大问题,需要频繁的进行人工看护。

    现在常用的私有云真机管理平台,可以采用:
    STF:https://github.com/openstf/stf
    或者,
    atxserver2:https://github.com/openatx/atxserver2在这里插入图片描述
    atxserver2 可以无缝对接 ATX,所以我们采用的是 atxserver2 来管理我们的云真机。

    4)执行测试方案

    先来看一下我们的整个测试架构:在这里插入图片描述
    生成测试报告:在这里插入图片描述
    如果比较喜欢用pytest的话,可以把 uiautomator2 + htmltestrunner 换成 pytest + allure 也挺香的。
    因为涉及到一些公司机密,这部分就不做具体的演示了。
    感兴趣大家可以自己去搭建一套UI自动化测试运行环境。

    四、对UI自动化的思考

    如果真正去接触 UI 自动化的话,你会发现 UI 自动化的可玩性也挺强的,而且对于新手测试来说,从 UI 自动化开始入门去学习自动化测试,是一条很不错的线路。
    当你看到你的手机按照你预设的脚本去操作 APP,会有一种莫名的成就感,并且会激励你继续深入学习下去。
    我看到很多 ”XXX 从入门到放弃“ 的案例,绝大多数都是因为学习路径过于陡峭,导致对知识的获取感到了彷徨,慢慢的就放弃了。
    但是 UI自动化 本身实操起来并不难,可能也就环境的搭建稍微要麻烦一些,总的来说,UI自动化 对新手来说,还是很友好的。

    当然UI 自动化并不能解决所有的问题,比如:
    APP 版本迭代太快,UI 变化频繁。
    操作流程复杂的测试场景。比如,经常会有各种弹窗(拼多多让你砍一刀),用例的通过率就会很低。
    垒代码没有意义,测试场景设计优于实现。比如,为了追求极致的自动化测试的覆盖率,可能会为一些很边缘化的功能做自动化测试,这些功能甚至极少有用户去触发,做这部分功能自动化,显然是没有意义的。
    平台化是趋势,有些团队把自动化脚本的编写都抽象成平台上”点点点”的操作了,看似更方便了,但实际上编写效率还不如 Coding,所以应该权衡利弊之后,选择适合自己团队的自动化方案。

    最后,不管是接口自动化还是UI自动化,都有自己的局限性和适用范围,二者应该是互补的。
    千万不要把 UI自动化 不擅长的工作,丢给 UI自动化 去做。

    UI 自动化 还有更多玩法,感兴趣的同学可以根据自己公司的业务去尝试:
    利用 AI 技术,预测定位元素,提升编写脚本的效率。
    UI 自动化可以利用图像识别进行对比测试。
    结合 Maxim、Monkey 或者 遍历测试 工具,进行稳定性精准测试。
    结合 Perfdog 等性能测试工具,进行移动端性能测试。

    最后我也整理了一些软件测试学习资料,对于学软件测试的小伙伴来说应该会很有帮助,为了更好地整理每个模块,我也参考了很多网上的优质博文和项目,力求不漏掉每一个知识点,很多朋友靠着这些内容进行复习,拿到了BATJ等大厂的offer,这份资料也已经帮助了很多的软件测试的学习者,希望也能帮助到你。需要的进群 644956177 自取喔。软件测试,与你同行!陪你成为优秀的测试工程师!

    既然都看到这里啦,请你帮个忙:

    1、点赞,让更多小伙伴看到;

    2、关注我,持续更新测试干货。

    敲字不易,如果此文章对你有帮助的话,点个赞收个藏,给作者一个鼓励。也方便你下次能够快速查找。

    干货分享

    北漂4年,做开发13K,转行自动化测试,真的靠谱吗···

    从一个萌新小白到一次拿下5个测试offer,我的测试成长之路···

    95后,刚工作2-3年就年薪50W+ ,才发现打败我们的,从来不是年龄···

    自动化测试6年后,终于有了属于我自己的团队···

    双非流本科毕业,自学软件测试也能成功进入阿里···

    展开全文
  • UI自动化测试介绍

    2021-12-03 17:07:30
    1.框架搭建 UI自动化框架跟接口自动化框架相似,我们拿到一个项目之后,首先把需要的框架先搭建好,然后再一点一点去进行优化,不要急着一步到位,先把...2.UI自动化测试在整个测试过程中占据的地位 这个比例主要还

    1.框架搭建

     优化前的框架:                                 优化后的框架:

    UI自动化框架跟接口自动化框架相似,我们拿到一个项目之后,首先把需要的框架先搭建好,然后再一点一点去进行优化,不要急着一步到位,先把基本的流程跑通

    gitignore文件:存放不上传到git上的内容

    README文件:这个是框架的简单说明,供同事,领导等查看,以及自己时间长了记不清楚查看

    requirements.txt文件:需要安装的第三方库

    run.py文件:收集并运行用例

    tests文件:存放所有的测试用例

    data文件:存放所有的测试数据,如登录的账号密码

    drivers文件:存放不同版本的驱动

    output文件:存放allure生成的测试报告文件

    pages文件:存放所有的页面元素操作封装的内容

    report文件:pytest生成的测试报告(测试报告二选一即可)

    setting文件:存放配置文件

    2.UI自动化测试的地位

    UI自动化测试在整个测试过程中占据的地位:

    这个比例主要还是看公司,手工测试/自动化测试,60%/40%(比较厉害的公司)大多数公司自动化占据的比例还是相对要少的,自动化占20%左右

    自动化测试又分:接口自动化/UI自动化/性能/安全  

                                70-80%/20-30%

    优先实现正向用例,回归

    3.UI自动化测试的特征

    1. 界面修改频繁(前端喜欢加<div></div>)
    2. 界面需求变动也大
    3. 运行速度很慢(浏览器打开速度慢,页面加载速度慢,占用CPU很多)
    4. 界面稳定性不够
    5. 界面排版是不方便做自动化

    4.UI自动化测试流程

    1. 需求分析
    2. 用例设计:提供什么参数以及数据,测试步骤
    3. 用例评审(这步就不详细介绍了,主要看公司如何做)
    4. 编写代码
    5. 测试报告

    4.1需求分析 

    拿到一个项目后,首先是分析这个产品是做什么的,都有什么样的功能,例如课堂派web端,先整理出都分什么角色,分别对应什么功能,进行自动化测试前,肯定是手工测试已经进行了测试,并且功能稳定没有bug

    4.2用例设计

    编写UI自动化测试用例的流程:

    1. 手工测试用例编写
    2. 自动化测试用例代码编写

    测试用例其实就是一个脚本script(这里指的不是代码中的脚本),作用是为了记录自己的一个思路,方便下次再去根据这个脚本去测试,方便管理,以免漏测等

    我这里为了介绍就不一一去编写了,实际工作中需要把所有的用例测试点都转化成测试用例 ,有了测试用例之后,我们就可以把用例转化成自动化测试代码了

    4.3编写代码

    根据编写的测试用例,进行代码编写,如登录功能

    步骤:

    1. 输入登录url:https://v4.ketangpai.com/Home/User/login.html
    2. 输入用户名:aaa  name="account"
    3. 输入密码:123  name="pass"
    4. 点击登录按钮:class="btn-btn" (虽然找到两个相同元素,但fide_element只取第一个,正好我们需要的是第一个)
    5. 进行断言

     具体代码如下:

    from selenium import webdriver
    from selenium.webdriver.common.by import By
    
    
    class TestSignIn:
        def test_sing_in_01(self):
            username = 'aaa'
            password = '123'
            expected = '密码有效长度是6到30个字符'
            with webdriver.Chrome(executable_path=r'E:\lemon\lianxi\day39_web框架搭建\chromedriver_96.exe') as browser:
                browser.implicitly_wait(5)
                browser.maximize_window()
                # 访问url
                url = 'https://v4.ketangpai.com/Home/User/login.html'
                browser.get(url)
                # 输入用户名
                el_user = browser.find_element(By.NAME, 'account')
                el_user.clear()
                el_user.send_keys(username)
                # 输入密码
                el_pwd = browser.find_element(By.NAME, 'pass')
                el_pwd.clear()
                el_pwd.send_keys(password)
                # 点击登录按钮
                browser.find_element(By.CSS_SELECTOR, '.btn-btn').click()
                # 获取登录后报错的文本
                actual = browser.find_element(By.CSS_SELECTOR, '.error-tips').text
                # 通过属性名称获取属性值
                # actual = browser.find_element('xpath', '//p[@class="error-tips"]').get_attribute('name')
                assert expected == actual

    注意:

    executable_path=r'E:\lemon\lianxi\day39_web框架搭建\chromedriver_96.exe'这个是可以不用填写的前提是:把该驱动放到了环境变量中了,前面有介绍,可以参考此篇文章:selenium-webdriver环境搭建_晒不黑的黑煤球的博客-CSDN博客
    之所以编写此名代码,是在实际项目中,可能会测试多个不同版本的驱动与浏览器时方便管理
    

    这是拿到一个项目后,先保证编写的代码可以顺利的执行没有报错,再去进行优化,我这里是演示就不一一编写所有用例代码了,编写过程是一样的,就是输入的数据与断言有所有更改

    接下来,我们就对代码进行各种封装及优化

    4.3.1优化代码

    优化方向:

    • 更好用
    • 更易懂
    • 维护代码方便
    • 更通用
    • 扩展性

    优化点:

    1. 隔离测试数据,当需要添加或修改数据时,可以在单独的模块中进行修改
    2. 浏览器管理可以重复使用,所以可以进行单独封装
    3. 需要把驱动进行隔离管理:1.可以存储多个浏览器驱动,2.想用哪个用哪个
    4. base url域名ip
    5. 登录操作可以重复使用(项目通用)
    6. 登录操作:已经登录过了,不需要重新再登录,记住用户登录状态
    7. PO模式

    优化第一点:

    测试数据我们可以从配置文件,或者execl表格获取,也可以直接新建一个模块来保存数据,我这里新建了一个login_data.py来存储

    login_fail = {'username': 'aaa', 'password': '123', 'expected': '密码有效长度是6到30个字符'}
    

     自动化测试用例修改如下:

     

     优化第二点:

    因为我们执行测试用例之前是先打开浏览器操作,用例执行后再进行浏览器关闭,因此把浏览器的封装放到夹具中最合适,之前我们介绍过共享fixture,就是把所有的夹具放到固定的conftest.py文件中,这样不需要导入,pytest会自动调用

    注意:conftest.py文件不能放到其他包下,放在根目录或tests包下即可,否则会报错

    import pytest
    from selenium import webdriver
    
    
    # 打开浏览器
    def get_browser():
        # 因为要在测试用例后执行闭关浏览器,因为不要使用with的打开方式
        browser = webdriver.Chrome(executable_path=r'E:\lemon\lianxi\day39_web框架搭建\chromedriver_96.exe')
        browser.implicitly_wait(5)
        browser.maximize_window()
        return browser
    
    # 设置夹具
    @pytest.fixture()
    def browser():
        driver = get_browser()
        yield driver
        driver.quit()

    自动化测试用例修改如下:

    把相关打开浏览器,设置隐性等待,窗口最大化的代码删除掉,只传入夹具browser即可

    优化第三点:

    把所有的驱动放到一个目录中,这样方便管理与操作,我新建了drivers目录存放驱动,新建了setting包,config.py配置文件(为了动态获取驱动的目录)

    config.py代码如下:

    import os
    
    # 获取config.py当前文件的路径
    curren_path = os.path.abspath(__file__)
    # 配置文件目录的路径
    config_dir = os.path.dirname(curren_path)
    # setting包的路径
    cf_dir = os.path.dirname(config_dir)
    # host地址
    host = 'https://v4.ketangpai.com/'
    # 驱动的路径
    driver_dir = os.path.join(cf_dir, 'drivers')

    修改conftest.py代码如下:

    4.3.2PO模式

    PO/POM模式(Page Object 或Page Object Model)是UI测试模式,字面意思就是页面对象模型,从本质上来说就是把页面的元素操作封装成类当中的方法,在测试过程中不再需要关注页面的结构,只需要关心执行的操作,这样测试用例中的代码看起来简单明了易懂

    具体操作就是上面优化第七点的过程,好处就是:

    1. 测试用例中的代码变更加精简
    2. 代码可读性变强
    3. 页面操作封装完成,进行隔离管理(也就是分层设计理念):前端发生变化,只需要维护PO封装后的代码,如果测试数据修改了,只需要修改测试数据即可
    4. PO封装的页面操作是可以重复使用的

    PO的封装有以下原则,如果遵守的话会达到更好的效果:

    最后两条可以不参考

    • 页面封装里不应该包含断言或者测试,否则就不能做到页面操作和测试操作分离
    • 唯一可以放在页面当中的测试是判断一个元素是否能找到
    • 不需要封装所有的页面操作,用到什么封装什么
    • 页面封装也可以使用组件方式:如导航栏,object,footer object等在多个页面重复出现的,使用组件可以增强代码复用性
    • 封装方法返回self,其他po,或者基础数据结构,string,dates,不应该element对象等
    • 如果同一个操作引发不同的结果,可以封装多个方法,如:login_failed,login_success

    优化第七点: 

    就是使用PO模式进行封装代码,把页面操作的相关代码都封装到单独的类方法中,具体操作如下

    新建page目录下login_page.py文件,代码如下:

    from selenium.webdriver.common.by import By
    
    
    class LoginPage:
        def __init__(self, browser):
            self.browser = browser
    
        def login(self, username, password):
            """登录"""
            # 输入用户名
            el_user = self.browser.find_element(By.NAME, 'account')
            el_user.clear()
            el_user.send_keys(username)
            # 输入密码
            el_pwd = self.browser.find_element(By.NAME, 'pass')
            el_pwd.clear()
            el_pwd.send_keys(password)
            # 点击登录按钮
            self.browser.find_element(By.CSS_SELECTOR, '.btn-btn').click()
    
        def get_error_tips(self):
            """获取错误信息"""
            return self.browser.find_element(By.CSS_SELECTOR, '.error-tips').text

     自动化测试用例修改如下:

    此步还可以进一步优化,设置一个夹具,依赖browser夹具,然后测试用例就不需要初始化loginpage了,直接调用login_page夹具即可

    修改conftest.py代码如下:

    import pytest
    import os
    from selenium import webdriver
    from setting import config
    from pages.login_page import LoginPage
    
    driver = os.path.join(config.driver_dir, 'chromedriver_96.exe')
    
    
    # 打开浏览器
    def get_browser():
        # 因为要在测试用例后执行闭关浏览器,因为不要使用with的打开方式
        browser = webdriver.Chrome(executable_path=driver)
        browser.implicitly_wait(5)
        browser.maximize_window()
        return browser
    
    
    # 设置夹具
    @pytest.fixture()
    def browser():
        driver = get_browser()
        yield driver
        driver.quit()
    
    # 依赖上一个夹具(上一个夹具是这个夹具的前置条件)
    @pytest.fixture()
    def login_page(browser):
        return LoginPage(browser)

    夹具的套娃:(一个夹具可以依赖另一个夹具)

    夹具 --> 用例的依赖关系

    夹具 --> 夹具的依赖关系

    自动化测试用例修改如下: 

    这个封装的过程就是PO模式,所有的页面操作代码都不会编写在测试用例代码中,而是放在一个类中独立管理

    优化第四点: 

    url也放到login_page.py文件中,增加一个加载登录页面的方法,代码如下

    from selenium.webdriver.common.by import By
    from setting import config
    
    
    class LoginPage:
        url = config.host + 'User/login.html'
    
        def __init__(self, browser):
            self.browser = browser
    
        def load(self):
            """加载页面"""
            self.browser.get(self.url)
    
        def login(self, username, password):
            """登录"""
            # 输入用户名
            el_user = self.browser.find_element(By.NAME, 'account')
            el_user.clear()
            el_user.send_keys(username)
            # 输入密码
            el_pwd = self.browser.find_element(By.NAME, 'pass')
            el_pwd.clear()
            el_pwd.send_keys(password)
            # 点击登录按钮
            self.browser.find_element(By.CSS_SELECTOR, '.btn-btn').click()
    
        def get_error_tips(self):
            """获取错误信息"""
            return self.browser.find_element(By.CSS_SELECTOR, '.error-tips').text

    自动化测试用例修改如下:

    from data.login_data import login_fail
    
    
    class TestSignIn:
        def test_sing_in_01(self, login_page):
            # 数据
            username = login_fail['username']
            password = login_fail['password']
            expected = login_fail['expected']
            # 获取实际结果
            login_page.load()
            login_page.login(username, password)
            actual = login_page.get_error_tips()
            # 断言
            assert expected == actual

    调用过程图如下:

    剩下还没优化的点,在之后的文章中会详细介绍,此篇就介绍到这里

    4.4测试报告

    获取当前系统时间戳来生成测试报告名+时间戳来存储测试报告,具体代码如下:

    import pytest
    import datetime
    
    # 获取当前时间戳
    ts = datetime.datetime.now().strftime('%Y-%m-%d-%H-%M-%S')
    # 路径拼接
    filename = f'reports/report-{ts}.html'
    # 收集并执行用例(注意加上[])
    pytest.main([f'--html={filename}'])
    展开全文
  • UI自动化测试一直都是如此的令人纠结,自动化测试初学者总是拿它入门,但有些经验丰富者对其又是毁誉参半,抑或抛出分层自动化测试那个经典的“金字塔”,来说明UI自动化测试还是少做为好。

      UI自动化测试一直都是如此的令人纠结,自动化测试初学者总是拿它入门,但有些经验丰富者对其又是毁誉参半,抑或抛出分层自动化测试那个经典的“金字塔”,来说明UI自动化测试还是少做为好。

      笔者在从事7年产品研发之后,临危受命转向测试领域,至今又7年有余。期间最关注的一直是UI端/用户端的自动化技术:从Web应用到移动App、从测试到RPA(机器人流程自动化)、从框架研发到应用推广。

      本文主要分享为什么要做UI自动化测试、UI自动化测试框架设计要点、团队合作方式、推广注意事项以及其他的心得体会,希望能给各位同行带来思想上的碰撞。

      1.UI自动化测试要不要做?

      如果一个组织真正重视软件质量,UI自动化测试是有必要做。有如下几点理由:

      任何自动化工具都是在简单、机械、重复的任务场景下最能发挥作用,UI测试非常符合这个特点。

      对于很多组织来说,UI测试是当前耗费测试团队人力最多的环节,大部分专职测试人员日常工作就是UI测试。“工欲善其事必先利其器”,测试人员也需要自动化工具来提升其日常工作效率。

      无论后台多复杂、多重要,用户接触的终究还是前端界面。现在的软件除了后台逻辑之外,还有很多前端脚本逻辑和样式,单纯靠后台接口/单元测试,无法证明用户端的可用性。

      自动化测试确实是要分层的(单元测试、接口测试、UI测试),从测试团队的角度来说,非常希望有足够充分的单元测试和接口测试来保证提测版本的质量,但实际情况往往是开发团队所维护单元测试和接口测试也是非常不充分、甚至几乎没有。

      所以任何项目中有人拿“分层自动化测试”跟我讲不要做UI自动化测试的时候,我都会先请他们把接口测试和单元测试展示给我看看,然后再跟他们探讨自动化测试的实施策略。

      但是从实践的角度,为什么很多质疑的声音呢?

      归根结底就是三个字“不稳定”!

      测试环境构建不稳定、被测软件界面不稳定、测试框架运行不稳定。

      其实只要适当的过程改善和开发团队配合,这些问题基本都是能够解决或者明显改善的。

      以测试环境为例,在纯手工测试阶段,有些项目的测试环境可以被随时停止、随意更新。这样对手工测试也是有影响的(工作进度受干扰、测试计划被打乱),但是可以忍受。自动化测试会对测试环境提出更规范的要求,至少不能随时停止,这就需要对研发测试过程进行必要的改善。

      然而被测软件界面不稳定、测试框架运行不稳定,就没有测试环境不稳定那么容易解决了。这里面主要涉及与开发团队的配合、测试框架的设计。

      2.与开发团队配合提高UI端的可测试性

      在分层自动化测试理论中,提到单元测试和接口测试是比较稳定和容易实现的。除了底层代码受用户需求变化影响相对较少、编写自动化用例成本较低之外,其实隐含了一个很少被提及的原因:单元测试和接口测试通常是开发团队内部的工作,当发现一个方法或服务接口设计的不合理导致自动化测试用例编写困难的时候,即便没有直接对应到一个缺陷上,他们也通常会进行调整,使代码设计实现更加优化、更规范。

      UI自动化测试需要开发团队配合指的当然不是不允许开发团队随便修改UI实现,指的主要是约定并遵守良好的UI编码规范、及时修正未对应功能缺陷但却影响UI自动化测试的编码问题等。

      UI自动化测试最关键的步骤是“定位页面对象”,下面举一个具体的例子,说明开发团队一些分内的、简单的配合,对自动化测试是多么的重要。

      定位页面对象的方法有很多,除了ID、XPath、CSS等之外,笔者推荐根据上下文文本定位对象。

      以下图界面为例:

      如果测试脚本想要使用上下文文本定位对象的方法(如下所示):

      在测试框架中就要解决怎么根据文本准确定位到后面的输入域/下拉框的问题。

      其实只要开发团队遵守HTML的基本标准,规范使用Label标签及for属性(如下所示),测试框架中实现上述效果就会变得很容易的。

      如果不遵守基本的UI编码规范,每个开发人员都随意编写前端代码,UI自动化测试的成本和难度就会明显增加。

      3.匹配开发模式设计自动化测试框架

      自动化测试框架的设计方法有很多,笔者这些年一直坚持的自动化测试框架设计核心思想是要“与开发模式匹配”。

      以WebUI开发为例,现在主要有两类模式:

      采用统一UI类库,企业或项目组采用统一的前端UI组件库进行开发,如,JQuery。

      采用统一开发框架,包括UI开发工具(甚至采用UI模型驱动开发),在采用统一UI类库的基础上,通过工具或模型来确保UI代码的规范性和一致性。

      在这两种模式下由于大量的UI类库,前端会解析出大量的、动态的、机器生成的页面源码,不再适合采用传统的脚本录制和页面对象识别的方式来制作测试脚本。

      对应这两种开发模式,笔者经常采用的自动化测试框架设计模式有:UI组件封装模式、开发框架对接模式等。

      1)UI组件封装模式

      PageObject模式是自动化测试最常采用的模式,但是在基于UI类库开发的系统中,页面对象数量太多,而且很多工具识别页面对象也变得更加的不准确和不智能。

      所谓UI组件封装模式,指的是根据开发所采用UI类库提供的UI组件类型(比如,input、select、date、button、tree、grid等)对应提供相应的自动化测试控件。

      将每类UI控件的定位方式和交互逻辑都封装到对应的自动化测试控件中,测试人员通过简单的DSL语言即可描述测试过程(如下所示),具体的解析执行交个测试框架进行统一处理。

      通过这种测试框架设计模式,可以降低脚本编写难度和脚本代码量,提高对象识别和执行稳定性,将UI类库变更带来的影响限制到测试框架中,不往测试脚本中扩散。

      2)开发框架对接模式

      当企业采用了统一开发框架,特别是通过工具生成大量UI代码时,我们可以先了解哪些代码是开发人员写的、哪些代码是工具生成的、哪些信息是在开发框架中统一管理的。

      在自动化测试框架设计时,充分利用这些资源可以大幅提升框架的易用性。如下图所示,对接开发框架之后,我们可以轻易的一键获取项目完整菜单结构(作为测试用例大概),并且准确识别页面对象。

      有了完整的测试用例大纲和页面对象之后,测试脚本的编写就会更加容易。另外,当未来项目版本升级之后,可以通过再次探测对比,识别页面对象的变更及影响的测试脚本,进而提醒测试人员批量修改脚本。降低在回归测试过程中发现脚本执行不过,带来的反复修改、反复回归验证的成本。

      4.什么样的项目更适合做自动化测试

      在有些人看来,质量不高的原因是没有采用先进的测试技术,比如自动化测试。

      但质量不高的真正原因是项目本身的质量要求就是不高的。否则哪怕堆人肉,也要实现充分的回归测试。如果在这种情况下,如果采用适合的测试框架和实施策略推行自动化测试,通常会取得比较明显的成效。

      所以关于什么类型的项目适合做自动化测试,我想回答的并不是什么项目周期长、需要长期维护、采用敏捷开发模式、组织推行DevOps、测试团队有基本编码技能,balabala…

      这些年笔者建议不要做UI自动化测试的项目也有很多,一些被我拒绝支持的项目也符合上述特点。后来我在评估一个项目是否适合做自动化测试时,引入了一些非技术指标:

      当前测试覆盖度、质量风险及测试投入;

      目标测试覆盖度、质量风险,以及如果不引入自动化手段需要的测试投入;

      这个目标是谁制定的或者是向谁承诺要达成的?

      如果项目没有制定一个在当前人力资源下无法达成的回顾覆盖范围目标,或者仅仅是项目组内定的目标,都没有向老板汇报或向客户承诺此目标。我觉得在这种情况下说要做自动化测试都是不太有诚意的。

      对于真心实意要做自动化测试的项目,接下来我会引导他们把现有所有测试用例拿出来,具体分析每个(每类)用例的自动化执行可行性、实现技术方案(UI、接口),以及前期需要投入的成本。

      在做完自动化测试ROI分析之后,如果确定要引入自动化测试,那么再辅以适当的自动化测试框架,实施成功的可能性是非常大的。


    对软件测试感兴趣的也可以关注我的公众号:程序员二黑,专注于软件测试分享,主要分享测试基础、接口测试、性能测试、自动化测试、TestOps架构JmeterLoad、Runner、Fiddler、MySql、Linux、简历优化、面试技巧以及大型测试项目实战视频资料,感兴趣的可以关注一下

    精彩的内容要和朋友分享哦

    展开全文
  • iOS UI自动化测试详解

    2021-01-24 21:10:41
    在能够保证业务的足够稳定性的条件下,UI自动化测试能够节省很多回归功能的人力。这就是我的一个小目标。 测试需要全面,需要对结果去做判断。如果熟悉单元测试或接口自动化的朋友,应该知道这些其实就是功能覆盖、...

    前言:

    小目标

    关于UI自动化的定义,我想要的是自动地按照流程去点击页面、输入数据,不需要人去参与,节省人工时间。比如登录,能够自己去填写用户名&密码,然后点击按钮跳转到下一个页面等。在能够保证业务的足够稳定性的条件下,UI自动化测试能够节省很多回归功能的人力。这就是我的一个小目标。

    测试需要全面,需要对结果去做判断。如果熟悉单元测试或接口自动化的朋友,应该知道这些其实就是功能覆盖、用例设计、断言……这些概念。于是小目标就升级成了,一个可以重复执行,多场景的,结果可预测的UI自动化测试。

    正文:

    测试基础

    软件测试是为了发现错误而执行程序的过程。或者说,是根据软件开发各阶段的规格说明和程序内部结构而精心设计的一批测试用例(即输入数据及预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程。

    白盒测试(White Box Testing) 又称结构测试、逻辑驱动测试,完全了解程序的结构和处理过程,按照程序的内部逻辑测试程序,检验程序中的每条通路是否都能按预定要求准确工作;对应到实际工作中,代码diff就是白盒测试。

    黑盒测试(Black Box Testing) 又称功能测试,在程序接口进行的测试,已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。对应到工作中,Checklist&Case就是功能测试。UI自动化测试,是将功能测试中大量的重复性操作(例如线上回归)提取出来,用脚本的形式驱动设备进行测试,有着可重复运行,执行效率高的特点。

    测试用例

    测试用例是为特定的目的而设计的一组测试输入、 执行条件和预期的结果。

    1.测试用例需要能够覆盖被测试的功能。
    2.测试的结果的正确性是可判定的,每一个测试用例都应该有相应的期望结果。
    3.即对同样的测试用例,系统的执行结果应当是相同的。

    如何覆盖被测试功能,我们需要对输入进行分类划分:等价类划分方法,边界值分析方法。

    等价类划分方法,将程序的输入域划分为若干个等价类(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。可以有效减少输入类型。例如用户名输入,可以划分为允许的字符类型:数字、字母,不允许的字符类型:特殊字符,汉字,空格等。

    边界值分析方法,边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。例如用户名长度是4-10位,我们依据边界值,就需要对3、4、10、11这四个边界值分别做测试。

    相对的,输出类划分后,对每一种输入都有唯一对应的输出,这个输出和功能无关,不管是正常流还是异常流,都需给出唯一结果。我们称之为断言,断言一般分为这这几类:等于、不等于、包括、不包括 或复杂的组合逻辑。

    UI自动化测试用例

    UI自动化在用例设计上也需满足上述性质,此外在输入中需要过程中需要定义UI的操作,同时在结果的判定上,会依赖UI元素的展示和页面的状态。比如某种异常状态下会弹窗提示,我们则需要去获取这个弹窗,然后对弹窗上UI元素进行比对和判断,而无法去做返回码的比较判断。关于页面状态的断言,相对于直接数据的比较判断不够直接、难度较大,当前还有很多难点。

    2.UIAutomation

    iOS4时代,Apple发布了一个名为UIAutomation的测试框架,它可以用来在真实设备和iPhone模拟器上执行自动化测试。UIAutomation的功能测试代码是用Javascript编写的。UIAutomation和Accessibility有着直接的关系,你将用到通过标签和值的访问性来获得UI元素,同时完成相应的交互操作。

    UIAutomation的js测试脚本,需要在Instrument的Automation控件上测试。但是在Xcode8.0之后,Instrument已经不再有这个模块了。而Apple也不再对它维护了,推广使用UITest来替代它。

    Accessibility

    UIAutomation的实现原理依赖于UI控件的Accessibility,这项技术是为了辅助身体不便的人士使用 app。VoiceOver 是 Apple 的屏幕阅读技术,UI Accessibility 的基本原则就是对屏幕上的 UI 元素进行分类和标记,两者配合,通过阅读或者聆听这些元素,用户就可以在不接触屏幕的情况下通过声音来使用 app。

    如果一个控件的Accessibility是可以被访问的,你就可以设置和读取它的值,作相关的操作,而当一个控件的Accessibility不可见时,你就没有办法通过automation访问它。每一个可以被访问(Accessibility enable)的UIKit控件都可以用一个Javascript对象来描述,它就是一个UIAElement。UIAElement有几个属性:name, value, elements, parent。UIKit层次树结构,可以直接映射到UIAElement的层次树。有了基本属性和层次树结构,我们就可以方便的使用JS对App中的空间进行操作了。

    看这个简单的小栗子,操作流程:找到tabbar->找到名称是“First”的button点击->给第一个textField设值->点击键盘的return->取id是“RecipeName”的staticTexts(label)的值->断言该label内容和之前输入内容的相等。

    可以看出寻找控件的两种方式:依据控件Accessibility identitifer查找;依据控件在数组的下标查找。前者需要你去设置,增加开发时成本。后者的变化性高,UI层级改变导致你的用例改变。

    test("Test 1", function(target, app) {
         
         target.logDevice();
         
         var window = app.mainWindow();
         app.logElementTree();
         
         //-- select the elements
         UIALogger.logMessage( "Select the first tab" );
         var tabBar = app.tabBar();
         var selectedTabName = tabBar.selectedButton().name();
         if (selectedTabName != "First") {
            tabBar.buttons()["First"].tap();
         }
         
         //-- tap on the text fiels
         UIALogger.logMessage( "Tap on the text field now" );
         
         var recipeName = "Unusually Long Name for a Recipe";
         window.textFields()[0].setValue(recipeName);
         
         target.delay( 2 );
         
         //-- tap on the text fiels
         UIALogger.logMessage( "Dismiss the keyboard" );
         app.logElementTree();
         app.keyboard().buttons()["return"].tap();
         
         var textValue = window.staticTexts()["RecipeName"].value();
    
         assertEquals(recipeName, textValue);
    });
    

    3.UITest

    UITest是Apple随着Xcode 7和iOS 9新的UI自动化测试框架。较之前不同的是,在UITest框架下,我们可以使用自己熟悉的Objc和Swift语言来编写自动化测试的脚本。除此之外,UITest最大的亮点是支持屏幕录制——通过对App的操作自动生成相应的测试脚本代码。这意味着非专业人士,也可以很方便地参与到自动化测试里来。

    原理和UIAutomation一样,UITest也依赖控件的Accessibility属性,UITest为所有UIKit控件提供了一个XCUI开头的代理类。比如UIApplication,对应的是XCUIApplication,在 UI Testing 中代表整个 app 的对象。

    对于一般的UIKit对象,Apple提供XCUIElement对象作为映射。我们不能直接通过得到的 XCUIElement 来直接访问被测 app 中的元素,而只能通过 Accessibility 中的像是 identifier 或者 frame 这样的属性来获取 UI 的信息。关于具体的可用属性,可以参看 XCUIElementAttributes 的文档。虽然不能直接通过Element得到属性,但是可以通过- descendantsMatchingType:,访问子节点,从而得到层级结构。

    hello world和屏幕录制操作,可以参考喵大的笔记,附有demo哦。

    4.Appium

    UITest支持iOS开发熟悉的编程语言、屏幕录制等多项强大功能,但这些都是和Xcode这个IDE绑定的。当我们在Xcode里写完代码,本地运行,这种种更像是单元测试,而没有太多自动化的味道了。一段真正的自动化测试脚本,应该和被测代码分开,能够部署到一台服务器上自动运行,让一项自动化测试真正自动化起来,成为了我的小目标3.0版本。在这里,Appium这个强大的自动化测试工具登场了,看看他的自我介绍。
    在这里插入图片描述
    跨平台、开源、多设备多系统的支持,而且文档详细,还有中文版本,实在是业界良心。

    背景

    关于Appium的介绍,官方的文档已经说得很清楚了,我这儿大致提炼一下几个重要的点。

    1.无需为了自动化,而重新编译或者修改你的应用
    在iOS上,这个特性是显然的。前面也说道了,因为Apple提供了Accessibility特性,让你可以得到控件响应的id,frame等。还可以通过代理,从而得到树形层级结构。

    2.跨平台
    这主要归功于Appium的自动化统一接口WebDriver API.WebDriver(也就是 “Selenium WebDriver”)。我们使用这套统一的接口,在各自平台上去解释,得到不同的底层实现。比如iOS这边是UIAutomation和UITest,Android则是UiAutomator和Instrumentation。

    3.多种语言编写&执行测试脚本
    这得益于Appium的C/S架构,我们将编写执行脚本的部分称为客户端(Clinet),脚本内容遵循统一接口。每一行,其实就是Client向服务器去发送一条Http消息,然后Server解析并翻译成对应平台(iOS/Adr)的实际测试命令,再发送给Device,再执行。可以通过下面的示意图简单了解。
    在这里插入图片描述
    因为Server层的存在,和统一接口的隔离,实现了脚本实现和执行条件的多样性。现已知的就支持Java、Python、js、Ruby等方式的Client API。

    安装指南

    同样,官方文档的快速开始也给出了详尽的步骤。但是实际上我在MAC上安装Appium的时候,还是遇到了各种各样的坑。这个指南部分,希望能帮助大家趟过这些坑。
    0.下载图形化桌面应用 Appium App
    目前更新到1.5,不支持Xcode8 和UITest。如果还在使用Xcode 7系列的版本可以直接下载使用。

    1.安装 homebrew & node 如果接触过web前端的同学应该不会陌生。

    2.node安装appium

    npm install -g appium
    

    到这里需要挂代理翻墙。如果没有条件的话,可以使用淘宝的NPM 镜像。

    安装到一半,应该会遇到/usr/local目录权限问题。这里给个小提示,建议给/usr/local/lib/node_modules/appium开全权限sudo chmod -R 777 ./ ,不建议使用sudo,据说会遇到别的问题。如果中途遇到错误,使用

    npm uninstall -g  appium
    

    命令卸载,然后重装。如果卸载不了,就直接去Finder/usr/local/lib/node_modules/appium目录删除就好了。

    安装好之后,运行

     $ appium &
    

    命令就可以启动Appium的server了。

    Hello World!
    安装好了Appium server之后,可以开始运行第一个程序了。去官网下载示例代码。下载之后你能看到有一个apps的文件夹和examples文件夹,前者放的是示例程序,后面是不同语言客户端的测试脚本。打开 apps/TestApp,运行能看到这是一个单页面的程序,最上方有两个输入框,输入数字,点击Compute Sum按钮,就能得出两者相加的和。
    在这里插入图片描述
    下面我们就来做这个部分的UI自动化测试。找一个自己熟悉的Client语言去执行自动化脚本,比如Java。打开,是一个Maven工程,下载了相应依赖库。之后打开SimpleTest文件,因为Xcode 8不支持UIAutomation框架,所以需要在setup中指定capability方式为XCUItest。

    capabilities.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");
    capabilities.setCapability("platformVersion", "10.0");
    capabilities.setCapability("deviceName", "iPhone 6");
    

    运行testUIComputation方法。可以看到模拟器启动了,但是之后会遇到Carthage找不到的问题
    在这里插入图片描述
    装上之后
    在这里插入图片描述
    官方Issues中找到了答案,WebDriverAgent缺少webpack。使用npm i -g webpack安装就好。PS:和之前一样使用淘宝源或者挂一个代理。

    完成了以上步骤之后,你就能看到你的Test在模拟器中自动运行,随着Terminal大量的log输出,测试结果也成功返回到Java的Client,在IDEA中看到执行结果,PASS!到此为止,第一个自动化测试被执行成功了~

    在这里插入图片描述
    Client - Server - Device交互
    driver.findElements
    我们以java代码driver.findElements(By.className(“UIATextField”))找到textField数组的过程为例子,去分析一下log,看看一次交互式怎么进行的。

    // client ----http----> server
    [HTTP] --> POST /wd/hub/session/94f7526c-94ba-4ece-8740-d94bd3d4f50f/elements {"using":"class name","value":"UIATextField"}
    
    [MJSONWP] Calling AppiumDriver.findElements() with args: ["class name","UIATextField","94f7526c-94ba-4ece-8740-d94bd3d4f50f"]
    [debug] [XCUITest] Executing command 'findElements'
    [debug] [BaseDriver] Valid locator strategies for this request: xpath, id, name, class name, -ios predicate string, accessibility id
    [XCUITest] Rewrote incoming selector from 'UIATextField' to 'XCUIElementTypeTextField' to match XCUI type. You should consider updating your tests to use the new selectors directly
    [debug] [BaseDriver] Waiting up to 0 ms for condition
    
    // server ----http----> device
    [JSONWP Proxy] Proxying [POST /elements] to [POST http://localhost:8100/session/79CBBB84-DB6E-48BA-B79F-91539E1E4708/elements] with body: {"using":"class name","value":"XCUIElementTypeTextField"}
    
    // device ----http----> server
    [JSONWP Proxy] Got response with status 200: {"value":[{"ELEMENT":"1A29AE60-5433-4B52-83F8-B4E2C794972E","type":"XCUIElementTypeTextField","label":"TextField1"},{"ELEMENT":"575EE2C2-4AFF-4320-B4D0-C30F59410DA9","type":"XCUIElementTypeTextField","label":"TextField2"}],"sessionId":"79CBBB84-DB6E-48BA-B79F-91539E1E4708","status":0}
    
    [MJSONWP] Responding to client with driver.findElements() result: [{"ELEMENT":"1A29AE60-5433-4B52-83F8-B4E2C794972E","type":"XCUIElementTypeTextField","label":"TextField1"},{"ELEMENT":"575EE2C2-4AFF-4320-B4D0-C30F59410DA9","type":"XCUIElementTypeTextField","label":"TextField2"}]
    // server ----http----> client
    [HTTP] <-- POST /wd/hub/session/94f7526c-94ba-4ece-8740-d94bd3d4f50f/elements 200 225 ms - 285 
    

    其中
    [MJSONWP] 打印的是S内部的处理日志。

    [JSONWP Proxy] 打印的是S/D之间的通信日志。

    可以看到,Client、Server、Device是通过Http协议通信的,大致流程为:
    Client通过http协议,将指定格式的命令发送给server。server调用中间层AppiumDriver解析命令,发送给实际的处理者。实际处理者依据平台、版本不同而不一样,这里是XCUITest(iOS)。而Device(iphone、模拟器)和Server的通讯也是通过http协议。

    到这里,大家会有疑问了,Server怎么找到对应的Device,他们之间如何通过Http通讯的?这里就要引出WebDriverAgent。它的作用:

    在这里插入图片描述
    WDA的inspector演示:直接在浏览器端打开 http://192.168.0.105:8100/inspector

    TextField赋值
    再看TextField赋值java代码elem.sendKeys(String.valueOf(rndNum));的执行步骤

    [HTTP] --> POST /wd/hub/session/94f7526c-94ba-4ece-8740-d94bd3d4f50f/element/1A29AE60-5433-4B52-83F8-B4E2C794972E/value {"id":"1A29AE60-5433-4B52-83F8-B4E2C794972E","value":["1"]}
    
    [MJSONWP] Calling AppiumDriver.setValue() with args: [["1"],"1A29AE60-5433-4B52-83F8-B4E2C794972E","94f7526c-94ba-4ece-8740-d94bd3d4f50f"]
    [debug] [XCUITest] Executing command 'setValue'
    
    [JSONWP Proxy] Proxying [GET /element/1A29AE60-5433-4B52-83F8-B4E2C794972E/attribute/type] to [GET http://localhost:8100/session/79CBBB84-DB6E-48BA-B79F-91539E1E4708/element/1A29AE60-5433-4B52-83F8-B4E2C794972E/attribute/type] with no body
    [JSONWP Proxy] Got response with status 200: "{\n  \"value\" : \"XCUIElementTypeTextField\",\n  \"sessionId\" : \"79CBBB84-DB6E-48BA-B79F-91539E1E4708\",\n  \"status\" : 0\n}"
    [debug] [BaseDriver] Set implicit wait to 0ms
    [debug] [BaseDriver] Waiting up to 0 ms for condition
    [JSONWP Proxy] Proxying [POST /element] to [POST http://localhost:8100/session/79CBBB84-DB6E-48BA-B79F-91539E1E4708/element] with body: {"using":"class name","value":"XCUIElementTypeKeyboard"}
    [JSONWP Proxy] Got response with status 200: {"value":{"using":"class name","value":"XCUIElementTypeKeyboard","description":"unable to find an element"},"sessionId":"79CBBB84-DB6E-48BA-B79F-91539E1E4708","status":7}
    [debug] [XCUITest] No keyboard found. Clicking element to open it.
    [JSONWP Proxy] Proxying [POST /element/1A29AE60-5433-4B52-83F8-B4E2C794972E/click] to [POST http://localhost:8100/session/79CBBB84-DB6E-48BA-B79F-91539E1E4708/element/1A29AE60-5433-4B52-83F8-B4E2C794972E/click] with body: {}
    [JSONWP Proxy] Got response with status 200: {"status":0,"id":"1A29AE60-5433-4B52-83F8-B4E2C794972E","value":"","sessionId":"79CBBB84-DB6E-48BA-B79F-91539E1E4708"}
    [debug] [BaseDriver] Waiting up to 0 ms for condition
    [JSONWP Proxy] Proxying [POST /element] to [POST http://localhost:8100/session/79CBBB84-DB6E-48BA-B79F-91539E1E4708/element] with body: {"using":"class name","value":"XCUIElementTypeKeyboard"}
    [JSONWP Proxy] Got response with status 200: {"value":{"ELEMENT":"FB515A63-3249-419E-8106-2681A1FEBA24","type":"XCUIElementTypeKeyboard","label":null},"sessionId":"79CBBB84-DB6E-48BA-B79F-91539E1E4708","status":0}
    [debug] [BaseDriver] Set implicit wait to 0ms
    [JSONWP Proxy] Proxying [POST /element/1A29AE60-5433-4B52-83F8-B4E2C794972E/value] to [POST http://localhost:8100/session/79CBBB84-DB6E-48BA-B79F-91539E1E4708/element/1A29AE60-5433-4B52-83F8-B4E2C794972E/value] with body: {"value":["1"]}
    [JSONWP Proxy] Got response with status 200: {"status":0,"id":"1A29AE60-5433-4B52-83F8-B4E2C794972E","value":"","sessionId":"79CBBB84-DB6E-48BA-B79F-91539E1E4708"}
    
    [MJSONWP] Responding to client with driver.setValue() result: null
    [HTTP] <-- POST /wd/hub/session/94f7526c-94ba-4ece-8740-d94bd3d4f50f/element/1A29AE60-5433-4B52-83F8-B4E2C794972E/value 200 2247 ms - 76 
    
    

    这看出setValue命令,包含几个步骤:检查是否打开键盘、获取输入框、弹出键盘、输入框赋值,每一个步骤都会和Device通讯。

    发送数据
    在这里插入图片描述
    session/94f7526c-94ba-4ece-8740-d94bd3d4f50f 这个指定了当前这个case的唯一id,在第一次通信时确立。由于第一次通信比较复杂,在最后会讲到。之后是id为1A29AE60-5433-4B52-83F8-B4E2C794972E 的Element,刚好是上一次请求列表的第一个元素,表明这次是对这个元素做操作。再看value,是一个json,定义的刚好是这个Eelemet和它的值,这些就是自动化统一接口的格式,一个简单命令的定义。

    建立Session

    [Appium] Appium REST http interface listener started on 0.0.0.0:4723
    [HTTP] --> POST /wd/hub/session {"desiredCapabilities":{"app":"/Users/zhiyu.zhao/Desktop/appiumTest/sample-code/sample-code/examples/java/junit/../../../apps/TestApp/build/release-iphonesimulator/TestApp.app","automationName":"XCUITest","platformName":"iOS","deviceName":"iPhone 6","platformVersion":"10.0"}}
    [MJSONWP] Calling AppiumDriver.createSession() with args: [{"app":"/Users/zhiyu.zhao/Desktop/appiumTest/sample-code/sample-code/examples/java/junit/../../../apps/TestApp/build/release-iphonesimulator/TestApp.app","automationName":"XCUITest","platformName":"iOS","deviceName":"iPhone 6","platformVersion":"...
    
    [Appium] Creating new XCUITestDriver session
    [Appium] Capabilities:
    [Appium]   app: '/Users/zhiyu.zhao/Desktop/appiumTest/sample-code/sample-code/examples/java/junit/../../../apps/TestApp/build/release-iphonesimulator/TestApp.app'
    [Appium]   automationName: 'XCUITest'
    [Appium]   platformName: 'iOS'
    [Appium]   deviceName: 'iPhone 6'
    [Appium]   platformVersion: '10.0'
    
    [debug] [XCUITest] XCUITestDriver version: 2.0.33
    [BaseDriver] Session created with session id: 94f7526c-94ba-4ece-8740-d94bd3d4f50f
    [debug] [XCUITest] Xcode version set to '8.0'
    [debug] [XCUITest] iOS SDK Version set to '10.0'
    [iOSSim] Constructing iOS simulator for Xcode version 8.0 with udid 'B9747B0B-C664-4C44-A651-9C3D8F7A980A'
    
    // 开启模拟器
    [XCUITest] Determining device to run tests on: udid: 'B9747B0B-C664-4C44-A651-9C3D8F7A980A', real device: false
    [BaseDriver] Using local app '/Users/zhiyu.zhao/Desktop/appiumTest/sample-code/sample-code/examples/java/junit/../../../apps/TestApp/build/release-iphonesimulator/TestApp.app'
    [debug] [XCUITest] Checking whether app '/Users/zhiyu.zhao/Desktop/appiumTest/sample-code/sample-code/examples/java/junit/../../../apps/TestApp/build/release-iphonesimulator/TestApp.app' is actually present
    [debug] [XCUITest] App is present
    [debug] [ios-app-utils] Getting bundle ID from app '/Users/zhiyu.zhao/Desktop/appiumTest/sample-code/sample-code/examples/java/junit/../../../apps/TestApp/build/release-iphonesimulator/TestApp.app': 'io.appium.TestApp'
    [debug] [iOSLog] Starting iOS 10.0 simulator log capture
    [debug] [iOSLog] System log path: /Users/zhiyu.zhao/Library/Logs/CoreSimulator/B9747B0B-C664-4C44-A651-9C3D8F7A980A/system.log
    [XCUITest] Setting up simulator
    [debug] [iOS] No reason to set locale
    [debug] [iOS] No iOS / app preferences to set
    [XCUITest] Simulator with udid 'B9747B0B-C664-4C44-A651-9C3D8F7A980A' not booted. Booting up now
    [debug] [iOSSim] Killing all iOS Simulators
    zhiyu.zhao@999999999:~|⇒  [iOSSim] Starting simulator with command: open /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app --args -CurrentDeviceUDID B9747B0B-C664-4C44-A651-9C3D8F7A980A
    [iOSSim] Tailing simulator logs until we encounter the string "SMS Plugin initialized"
    [iOSSim] We will time out after 60000ms
    [debug] [iOSSim] Waiting an extra 10000ms for the simulator to really finish booting
    [debug] [iOSSim] Done waiting extra time for simulator
    [iOSSim] Simulator booted in 26076ms
    
    // 安装TestApp、开启WebDriverAgent
    [debug] [XCUITest] Installing app '/Users/zhiyu.zhao/Desktop/appiumTest/sample-code/sample-code/examples/java/junit/../../../apps/TestApp/build/release-iphonesimulator/TestApp.app' on device
    [XCUITest] Using default agent: /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj
    [XCUITest] Using default bootstrap: /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent
    [XCUITest] Launching WebDriverAgent on the device
    [debug] [XCUITest] Carthage found: /usr/local/bin/carthage
    [debug] [XCUITest] Killing hanging processes
    [debug] [XCUITest] Beginning test with command 'xcodebuild build test -project /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id=B9747B0B-C664-4C44-A651-9C3D8F7A980A -configuration Debug' in directory '/usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent'
    [XCUITest] Waiting for WebDriverAgent to start on device
    
    
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:33 999999999 CoreSimulatorBridge[56212]: Pasteboard change listener callback port <NSMachPort: 0x7ff8707030a0> registered
    
    [Xcode] === BUILD TARGET WebDriverAgentLib OF PROJECT WebDriverAgent WITH CONFIGURATION Debug ===
    
    [Xcode] === BUILD TARGET WebDriverAgentRunner OF PROJECT WebDriverAgent WITH CONFIGURATION Debug ===
    
    // WebDriverAgentRunner-Runner.app
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:42 999999999 CoreSimulatorBridge[56212]: Requesting installation of file:///Users/zhiyu.zhao/Library/Developer/Xcode/DerivedData/WebDriverAgent-brdadhpuduowllgivnnvuygpwhzy/Build/Products/Debug-iphonesimulator/WebDriverAgentRunner-Runner.app/ with options: {
    
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:46 999999999 CoreSimulatorBridge[56212]: [Common] [FBSSystemService][0xc2a4] Sending request to open "com.apple.test.WebDriverAgentRunner-Runner"
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:46 999999999 CoreSimulatorBridge[56212]: [Common] [FBSSystemService][0xc2a4] Request successful: <FBSProcessHandle: 0x7ff870505830; XCTRunner:56563; valid: YES>
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:47 999999999 XCTRunner[56563]: assertion failed: 15G31 14A345: libxpc.dylib + 62597 [37A9DF49-35C1-3D93-B854-B35CACF0100F]: 0x7d
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:47 999999999 XCTRunner[56563]: Running tests...
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:48 --- last message repeated 4 times ---
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:48 999999999 XCTRunner[56563]: Continuing to run tests in the background with task ID 1
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:48 --- last message repeated 13 times ---
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:48 999999999 XCTRunner[56563]: Built at Nov  2 2016 16:50:41
    
    
    [XCUITest] Detected that WebDriverAgent is running at url 'http://10.86.132.138:8100'
    [debug] [WebDriverAgent] Sim: Nov  2 16:50:48 999999999 XCTRunner[56563]: ServerURLHere->http://10.86.132.138:8100<-ServerURLHere
    [XCUITest] WebDriverAgent started at url 'http://10.86.132.138:8100'
    
    [JSONWP Proxy] Proxying [POST /session] to [POST http://localhost:8100/session] with body: {"desiredCapabilities":{"bundleId":"io.appium.TestApp","arguments":[],"environment":{},"shouldWaitForQuiescence":true}}
    [JSONWP Proxy] Got response with status 200: {"value":{"sessionId":"79CBBB84-DB6E-48BA-B79F-91539E1E4708","capabilities":{"device":"iphone","browserName":"TestApp","sdkVersion":"10.0","CFBundleIdentifier":"io.appium.TestApp"}},"sessionId":"79CBBB84-DB6E-48BA-B79F-91539E1E4708","status":0}
    
    [Appium] New XCUITestDriver session created successfully, session 94f7526c-94ba-4ece-8740-d94bd3d4f50f added to master session list
    [MJSONWP] Responding to client with driver.createSession() result: {"webStorageEnabled":false,"locationContextEnabled":false,"browserName":"","platform":"MAC","javascriptEnabled":true,"databaseEnabled":false,"takesScreenshot":true,"networkConnectionEnabled":false,"app":"/Users/zhiyu.zhao/Desktop/appiumTest/sample...
    [HTTP] <-- POST /wd/hub/session 200 59127 ms - 520 
    

    Client发送建立Session请求->Server接受,打开模拟器->安装被测试APP->启动WDARunner->完成后Device返给Server Device Session id->Server返给Client 设备信息和本次Session id
    在这里插入图片描述
    5.ATX:AutomatorX
    项目GITHUB
    在这里插入图片描述
    特点

    完全的黑盒测试框架,无需知道项目代码,非侵入式
    支持iOS, Android的自动化测试,两个平台都支持测试第三方应用
    对于iOS的真机,安卓模拟器都能很好的支持
    可以用来测试Windows应用
    对于游戏的测试使用了图像识别
    同一个测试脚本可以通过图像的缩放算法,适配到其他分辨率的手机上
    主要特点集中在图像识别上,通过图像识别来寻找某控件和页面状态判断的断言。

    6.最终目标
    小目标3.0让自动化自动起来,也就是搭建云测试平台,实现设备和测试脚本分离、透明化。同一App的测试脚本可以由多个Client来编写,然后由平台合理分配设备资源来运行这些测试脚本。而由于UI界面本身多变的特性,脚本的维护会比接口的自动化测试成本高很多,所以最终目标是在3.0的基础上,在Client端加上屏幕录制技术,类似于Xcode的录制操作生成代码的功能。这样就能够建立起一整套维护成本低,自动化程度高,拓展性好的自动化测试平台。

    在这里推荐一个软件测试交流群,QQ:642830685,群中会不定期的分享软件测试资源,测试面试题以及行业资讯,大家可以在群中积极交流技术。

    展开全文
  • UI自动化测试 浅谈

    2021-11-22 11:37:53
    UI自动化测试,Selenium自动化路线,Selenium重要步骤之定位元素
  • 1、自动化测试基础 1.1 自动化测试的定义 ...1)UI本身的变化性,要想达到和手工测试相同的覆盖率,单纯的UI自动化测试往往很难 证明自己的投资回报; 2)UI控件元素本身识别的复杂性; 3)UI自
  • UI自动化测试框架

    2021-03-09 02:57:22
    第一步是了解目前已有的自动化开发技术,上面说了,最底层的就那几种,根据实际要去测试的业务需求选择合适的自动化框架,如我这边要负责pc、无线m站、无线app(android、ios)四个大用户入口的自动化测试,...
  • 自动化测试是研发人员进行质量保障的重要一环,...如果能将UI自动化测试与主流程回归结合到一起,一方面保证了代码质量,另一方面大大节约人力成本,可谓一举两得。为什么需要UI自动化测试原因主要是以下三点:保证...
  • 目前项目组的所负责的系统需求较多,测试案例数量也较多,测试场景复杂,测试数据制作复杂,并且有部分系统已经趋于成熟,所以打算开始进行UI自动化测试UI自动化测试其实是一门【水】很深的工作,因为UI自动化...
  • 什么是 UI 自动化测试

    千次阅读 2020-12-26 21:51:10
    白码会说:Time will tell. UI 自动化是 Web 页面自动化测试的解决方案,可以用来...相比其他 Web-UI 自动化测试框架,UI 自动化测试脚本的创建和维护都不需要接触脚本代码,所有交互都是在 Web 页面上在线可视化.
  • UI自动化测试

    2021-10-13 14:04:01
    UI自动化测试,就是通过编写自动化测试脚本和执行自动化测试用例,来实现对B/S、C/S的应用做自动化测试,实现测试自动化,以及自动化回归测试,进而降低版本迭代的测试成本。 缺乏自动化测试工具 UI自动化测试工具...
  • 使用 Python+Selenium+第三方库实现WebUI自动化测试框架,具备 web 服务,用例组织可以在界面上拖拽。 项目目录 AutoIt: 操作界面ui的第三方插件 Config: 配置文件 Data: 测试数据 Drivers: 浏览器驱动 ...
  • 随着互联网的高速发展,软件技术日新月异...本文所探讨的就是软件自动化测试框架的实现,首先是对需求进行分析,然后通过对比国内外成熟的自动化测试框架技术进行技术选型,最终确定使用基于Python语言的,结合Selenium
  • 【软件测试】APP UI自动化测试,思路全总结在这里了
  • 一、 自动化测试简介 1. 自动化测试本质 通过自动化的形式来模拟人工一系列操作(面试可能会问,结合一个场景来回答) 打开项目->定位元素->操作元素->模拟页面动作->断言结果(判断预期结果与实际结果...
  • 框架选型自动化测试框架SeleniumWebDriverSelenium Grid四 功能介绍平台化国际化分布式并发执行跨环境分支的用例管理合并同步H5 UI自动化自定义定位表达式动态的预期值前/后置动作数据Mock页面Mock页面数据校验接口...
  • 目前项目组的所负责的系统需求较多,测试案例数量也较多,测试场景复杂,测试数据制作复杂,并且有部分系统已经趋于成熟,所以打算开始进行UI自动化测试UI自动化测试其实是一门【水】很深的工作,因为UI自动化...
  • 本篇记录基于Python+Selenium.webdriver实现WEB端UI自动化测试,其中测试用例使用excel维护。为了在实际项目种的扩展应用,建议学习webdriver的元素定位方法,欢迎在评论区沟通讨论。 1.项目选取(登录页无验证码...
  • 通过数据文件存储数据,读取数据,参数化测试用例并驱动测试执行 7.通过第三方插件pytest-html生成测试报告 8.通过yagmail第三方库,编写发送报告接口,测试工作完成后自动发送测试报告 代码分析 目录结构 1 ...
  • driver.find_element_by_name('file').click() sleep(5) os.system("sc.exe") 具体autoIT: 在做Python UI自动化测试时遇到这种情况,我们可以借助一个工具autoIT来实现上传图片或者是文件; 一、具体操作步骤如下...
  • web UI自动化测试使用了unittest框架,内容如下图: 1. case 放自动化测试用例 1.1 app(APP与web可以使用同一套测试框架,后续会详细说明) 1.2 web web下有具体的模块用例,一个模块的case对应一个py文件,如...
  • RF之UI自动化测试

    2021-11-02 19:34:44
    打开谷歌浏览器,访问百度 2:设置睡眠时间 sleep 时间(秒) Set Browser Implicit Wait 时间(秒) 3:窗口最大 Maximize Browser Window 成功 4:设置窗口位置 Set Window Position 20 40 5:返回上一步 Go Back 6:...
  • 1 # 镜像环境:UOS23 # 安装pip34 sudo apt-get install python3-pip5 # 安装pyautogui和依赖包67 sudo pip3 install pillow8 sudo pip3 install python3-xlib9 sudo apt-get install scrot10 sudo apt-get install ...
  • 自动化测试流程通常会以两种方式来使用这些工具。  自动化用录制和回放  在录制和回放的两种方法中,必须打开录制并且手动完成manual tester的测试应用程序的步骤。后端记录器将记录操作(识别控制,点击按钮,填充...
  • 自助机UI自动化测试方案 导读: 机器不具备理解能力和逻辑思考,不能像人一样通过一系列探索性思维去理解描述。如果给出的描述不精确,机器是不会自发性的进行探索和脑补的。控件定位就是精确的描述控件特征并告诉...
  • 功能强大、应用灵活,适用于功能测试、协议测试、跨系统测试、webUI页面测试等,今天就来和大家聊聊关于webUI自动化测试的一些使用技巧或功能吧。 close browser关键字配置不可缺少 测试webUI,不可避免的就是...
  • UI自动化测试工具-AirTest

    千次阅读 2021-05-06 11:00:35
    UI自动化测试工具-AirTestUI自动化测试工具-AirTest下载与安装app操作步骤平台系统级 UI自动化测试工具-AirTest Airtest是网易自研的一款基于图像识别和poco控件识别的UI自动化测试工具,Airtest的整体封装的框架由...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 156,530
精华内容 62,612
关键字:

ui自动化测试

友情链接: URLDownload.rar