专场:测试自动化 

今天,测试自动化成了团队的标配,同时,我们面对新型应用架构,需要采取新的技术或新的策略,如基于容器技术和K8S构建新型的、分布式的自动化测试框架、测试中台,测试虚拟化、服务化,自动化测试效率也需要持续提升等。
张南,Google中国工程生产力团队总监,2007年加入Google,目前负责Google中国工程生产力技术团队。负责移动产品开发效率的提升,自动化框架的设计。之前领导过Google地图,搜索等移动产品项目的自动化流程和框架设计开发。硕士毕业于清华大学。
专场出品人:张南
出品人:熊志男
Google中国工程生产力团队 总监
京东科技研发效能团队 负责自动化测试平台开发
2014年加入京东,在研发效能工具开发和工程实践的落地方面都有丰富的经验。参与并主要推动的持续集成和代码扫描实践从20人左右的小团队做起,逐步扩展到百人团队,主要参与建设的代码质量平台也从团队内部的工具,逐步发展成为公司级的上千人使用的工具平台。掌握持续集成流程中的单元测试、代码审查、自动部署和自动化测试各个阶段的工具方案和实现原理,并了解研发团队的实际痛点,有丰富的实际落地经验。是《京东系统质量保障技术实战》作者之一,翻译《Selenium自动化测试—基于Python语言》一书。

同时也是公益测试社区测试窝的核心成员之一,多次参与组织测试和质量相关的公益沙龙活动。
传统的自动化测试技术解决了测试手段从0到1的转变,伴随着自动化测试的快速普及,测试的频度与量级急剧增长。工程师们已经习惯将自动化测试作为一种基础能力,为了追求更极致的测试质量与效能,产生了新的思考:
        1. 如何将 case 书写成本降低
        2. 如何让 case 更有针对性的测试        
        3. 如何进一步压榨自动化 case 执行时间
        4. 测试结果如何快速分析定位
        5. Case 质量如何评估
围绕上述疑问,以 API 自动化测试为例,展开介绍测试流程各个阶段,是如何通过智能化测试思维进行创新改变,赋能加强测试效率与质量。


1. API 自动化测试平台的功能设计简介
2. 面临的质效问题分析
        a) 人效问题:仍大量投入人力的阶段,如写 case、维护 case
        b) 机效问题:量级多了之后 case 执行的过程也成为了瓶颈
3. 自动化Case全周期的智能化改造思路
        a) Case 生成
                i. 从api 定义到 case
                ii. json-schema 校验的应用
                iii. 应用场景:diff 测试与契约测试
        b) Case 推荐:精准测试
        c) Case 分组并发执行:解决长尾问题
        d) 测试结果定位:减少冗余干扰
        e) Case 评估:评判自动化 case 的有效性
4. 总结与展望
1. 了解API 测试的智能化改造可行思路
3. 了解部分业务场景的测试实践经验
薛大伟
百度 资深测试开发工程师
自加入百度以来,经历了各类业务平台、商业与用户产品的项目测试,在各个测试领域方向都有比较丰富的经验,负责建设 web/api的自动化测试框架平台,当前作为百度质效研发团队的功能测试中台技术负责人,致力于打造更加易用、聪明的测试。

擅长领域:具备丰富的业务系统、用户产品、商业产品测试经验,长期致力于面向各类产品的自动化框架平台设计开发,积极探索与研究智能化测试的创新落地。
待定
待定
智能化思维赋能API自动化测试
内容大纲
听众收益
一.智能设备的自动化测试在向深度拓展时的挑战
a)外在的测试需求挑战
i.多机互动型的测试 – 如2台手机互相拨打电话,互发短信/彩信,微信互相聊天、分享(朋友圈),3台及以上的微信/QQ等IM软件进行群聊,等等
ii.涉及到需要硬件辅助的测试 – 如手机横竖屏切换,接听电话时的贴近耳朵(遮挡距离感应器),按压电源键,环境配合的测试(如扫描二维码需要镜头前有二维码,语音播放以测试语音助手,等等),等等
b)内在的困难
i.贴近用户场景的测试用例开发难度高 – 如刷抖音的时候接听微信来电
ii.自动化测试用例的开发工作量太多太大 – 几十个系统App+几百个三方App,数以千计的用例开发量

二.解决方案
a)分布式框架
i.测试用例的逻辑执行层与动作实现/硬件抽象管理层分离
1.例如,要做的点击/滑动动作,是由adb 完成,或是 机械手 来做;
2.例如,获取UI界面上的内容,是通过adb ,或是通过 摄像头 来获取;
b)基于流程图的自动化用例开发
i.分层 – 把针对专业模块/接口的测试代码封装成组件,在大量的测试用例中使用
ii.分工 – 做功能测试自动化用例,画流程图开发的方式优点多(上手快,开发快,开发者多)

三.实践成果
a)TMach系统上已经实现了大量的高复杂度的自动化测试用例,且能够在大规模的智能手机上跑测试
i.互相拨打电话
ii.互发短信/彩信
iii.微信/QQ等IM软件的聊天互动、群聊,等等
iv.抖音、拼多多,等等

四.未来演进
a)完善的动作执行层+硬件抽象管理层(TOS – Test OS)
i.支持测试更多类型的智能设备,如手环,手表,车机,等等
ii.支持更多专业场景的测试需求,如提供环境光源、温度、湿度控制的测试柜
b)更智能的测试
i.游戏测试需要更多的智能算法的辅助,如决策树
ii.测试任务中,各种测试资源(测试设备,软件帐号,测试辅助硬件,测试用例,等等)的智能调度
iii.测试经验的学习和应用
通过测试建模自动生成接口测试脚本,提升 。
郑小川
安和瑞福  创始人 产品架构师
17年创建北京安和瑞福,开始TMach自动化测试系统的设计研发;
11~16年在小米从事智能手机的系统研发、测试方面的工作;
05~11年在微软亚洲工程院从事 Windows CE/Mobile 操作系统开发/BSP开发工作;
05年开始进入智能手机行业;
03~05年从事芯片固件开发;
03年毕业于南京邮电大学(硕士学历);
待定
待定
智能手机深度测试的挑战与应对
智能手机的深度自动化测试很难 – 在大规模的自动化测试平台上控制多机互动,控制多种硬件;
自动化用例的开发很难 – 复杂的用例开发,以及庞大的开发工作量;
内容大纲
听众收益
一、技术考虑
1. 纯代码自动化门槛高且生产业务存在无规律弹框、动态业务变更等问题,自动化工作量巨大,如何规划设计自动化框架,降低自动化难度以及提升自动化代码通过率。
2. 如何利用视觉人工智能技术,在生产业务中提高自动化脚本的全域适配。
3. 持续拨测业务,如何构建业务图谱、自研语言脚本快速适配竞品业务变更
二、实践
1. 某银行生产业务以及竞品持续拨测实践
2. 券商行情高灵敏度延迟持续拨测以及竞品分析
虽然自动化技术已经相对成熟,但是在持续监控生产业务表现以及竞品分析上,依然存在大量的问题,无法全天候全适配的进行。又比如对于高度一致化同业务,如同交易所行情等场景,高精度的数据获取以及对比均存无法低沉本自动化的痛点。
本议题通过一些人工智能技术、方法论以及工程化实践,解决全天候自动化生产环境业务拨测、竞品业务持续拨测问题,通过构建业务图谱以及自然语言自动化框架智能化管理用例生命周期,低沉本高效率完成脚本持续更新、业务持续监控的目的。
 1. 自动化高成功率低成本落地
 2. 生产业务自动化实践以及高精度业务监控数据获取

徐祥
AITest 掌动智能研究院移动应用研究部技术顾问
 Tinypace 跬步技术合伙人
待定
待定
业务自动化持续拨测智能化实践
内容大纲
听众收益
掌动智能科技有限公司研究院 移动应用研究部技术顾问
兼任跬步信息技术有限公司产品总监
兼任百度MTC自动化私有云平台顾问
负责自动化平台研发工作,擅长UI自动化工具以及新兴AI技术的研发及应用;主持实施了多项大型企业自动化私有云工作。

我们通过独特的思路和设计,摸索了一套最佳实践的方案,并在捷信各个业务团队取得非常好的效果
安卓端:
a) 通过底层非入侵方式改造ui automator源码使它具备极其精准和快速的flutter控件识别的能力
b) 统一的接口支持原生控件+flutter控件
c) 非入侵非插桩方式精准截获flutter页面加载事件
d) 结合页面哈希算法,环路算法,页面倒计时算法等各种创新的设计可以精准计算出flutter页面加载时间
ios端也是通过·底层改造,结合独特的设计和算法可以非常快速的实现flutter控件的操控和加载事件的截获计算,ios速度根据在公司推广情况效果一点不比安卓慢,甚至还快(appium给我们的错觉是安卓自动化快一些,ios慢一些)在安卓和ios两端采用了不同的设计和解决方案,摸索了一套flutter自动化方案的最佳实践,在捷信全公司核心业务部门都取得了很好的效果,为大家提供一直不同的思路去解决这个难题。
内部工具SuperMelody的背景:
捷信各大业务团队需要对移动端app(ios和Android)进行页面加载数据的性能分析以便改进终端用户的使用体验:
 开发需要单独开发通过代码插桩来记录页面起始和离开时间,所以需要单独开发一个版本的android和ios
 业务测试工程师需要手动去运行各个页面,然后还需要从开发插桩日志里去分析数据
 每次测完一轮页面耗时耗力
所以我们需要一种工具可以解决以上痛点,实现以下功能:
1 完全自动化的完成app页面切换
2. 需要快速且精准的机制和算法计算页面加载时间(页面所有元素都需要加载完成)
3支持Native页面,WebView页面和flutter页面
随着安卓和iOS前端的开发都逐步转移到flutter框架的大背景下,flutter自动化目前各公司都在探索中,谷歌的flutter driver和integration test,appium flutter driver都不能很好的解决实际项目中的问题。
我们注意到有些公司采用了图片识别+OCR方式, 这样虽然可以一定程度解决问题,但存在很大问题,肯定不是最佳实践,理由如下:
a) 图片识别和OCR速度肯定没有从底层出发的控件识别快,我们认为图片识别+OCR仅仅只能当作一个辅助的手段
b) 对于我们项目中要判断页面加载时间,也就是要极短的时间内观察所有控件的状态和加载事件,用此方法是几乎很难做到精准的
c) 图片识别和OCR有一定出错率
d) 模拟人类视觉未必是最智能的方式,比如你明明可以通过仪器拍胸片却非要靠肉眼去评估,失去了获取内部机制的机会
e) 如果说native+ocr 能基本解决自动化的问题,那么该方案第2个问题是无法能精准解决的
为什么这么说呢? Flutter自动化就是你需要先识别某一个flutter元素,然后对它进行一个action而页面加载时间需要截获底层的时间,同时需要页面加载算法,需要监控整个页面flutter元素,所以自然要求就高了很多。
启发 借鉴,少走弯路
陈希
捷信消费金融 资深测试开发技术专家
先后任职于网易,网际快车,诺基亚,微软,目前担任捷信专家组资深测试开发技术专家。

擅长领域:移动端测试开发(安卓端+ios端)AI对测试开发的应用(预测+分类)
待定
待定
捷信QE团队移动端Flutter自动化及页面性能最佳实践
内容大纲
听众收益
1. 目前业内移动端UI自动化现状和一直存在的痛点
2. KRunner的设计理念
3. KRunner的核心特性
        a. 脚手架(自动生成用例工程)
        b. 强大的图像识别模块 (召回率和精确率问题/ 特征点少的情况/ 指定区域识别)
        c. js注入实现定制化的webview定位元素
        d. Android和iOS驱动服务管理        
        e. 操作标记流
        f. 异步弹窗处理模块(安装弹窗/系统弹窗/应用内弹窗一键配置化)
        g. 丰富的结果产物(log/截图/录屏/html报告)
4. KRunner如何解决稳定性问题(核心是WDA的稳定性)
5. KRunner如何降低用例的维护成本
6. 目前在快手的使用情况和后续规划
7. 现场实操
UI自动化已死?移动端自动化稳定性差?移动端自动化维护成本高?这些老生常谈的问题,这次分享主要围绕上面的问题,从问题出发,介绍如何打造一款好用且稳定的移动端自动化框架,如何保证大规模用例场景,7x24小时运行场景下的框架稳定性执行,并结合快手内部自动化业务使用情况,提出UI自动化使用的新思路和新场景以及后续规划。
1. 了解移动端自动化的痛点和常见的坑
2. 站在开发者的角度,如何打造一款好用的移动端自动化测试框架
3. 如何保证自动化测试的稳定性
4. 如何提升自动化测试的异常处理能力
5. 了解UI自动化使用的新思路和新场景
陈立
快手 效能开发专家
曾经就职于腾讯/字节跳动/蚂蚁金服, 目前在快手音视频技术部从事多媒体效能平台的开发工作,包括任务调度平台,云测真机平台,移动端自动化框架开发等等。

擅长领域:
移动端开发,移动端自动化技术
待定
待定
移动端自动化测试新利器KRunner的设计和实践
内容大纲
听众收益
本站使用百度智能门户搭建 管理登录