在4月9日的云栖techday活动上，卞伟为大家分享了钉钉客户端自动化的应用。
钉钉产品是阿里的一款企业级im工具，版本更新也很迅速，在迭代过程中，团队通过ui自动化对核心功能进行验证，节约回归的人力成本，并在自动化框架的基础上，针对特定场景的性能、弱网下的聊天功能也进行了自动化的改造。
下面是tech君整理的技术观点。
<b>简介</b>
钉钉是一个工作方式。从需求的层面出发，钉钉是一个im聊天的客户端工具，对于用户而言，最关注的是app的实际运行的效果，所以主要针对安卓和ios进行测试，pc和外国版目前也是通过人力测试来保证的。测试的场景有功能场景(包括核心场景、聊天场景、设置场景等)、弱网场景。
<b>图1自动化的结构</b>
自动化的结构，最核心的是ui操作。作为ui自动化肯定要有一个机制去驱动界面的元素识别和ui操作，安卓和ios分别使用了两套基础ui操作库。安卓是一个叫sword的内部操作框架的一些实现原理，与appium比较类似；ios采用的是苹果原生的instruments（ui automation）。 ui操作是最核心的功能，在此之上，如果把它自动化建立起来，在它的外围就需要有一个基础库，所谓基础库，比如case运行的信息打印、日志收集，包括设备本身产生的一些日志等，这是作为辅助排查问题的手段，截图跟日志的功能相辅相成，还包括配置、变量管理等。接下来是测试框架，选用的是常见的junit，并且在其之上做了一些自定义runner的封装。最外层ci用jenkins去执行，ptm工作台让客户端测试的人也能去方便的发现执行和查看结果，分布式执行是指把case分成不同的模块，和不同的等级，根据需要去驱动不同的等级和模块的case执行，万一需要全量执行，就采用分布式的方式在不同的机器、不同的手机上去执行，再做一个结果的汇总。报表邮件是自动化的延伸，让执行者和开发者能清楚的知道case运行的效果怎么样。
<b>应用</b>
<b>基础自动化</b>
基础的自动化是核心，在它周围有一些功能、性能、弱网。基础自动化是多机执行的，用sword作为安卓自动化的元素驱动，比如，多机case在聊天、设置、ding各个场景上都会用到，在业务utils封装上肯定也要考虑到多机执行。多组执行就是分布式执行，要考虑时间、设计系统配置，运行时在两组之间是并行执行，统一收集，在一组之间是串行执行的。多场景配置，比如，运行一个全量或核心的case，全量的case两百多个，三四十分钟，有时候可能只需要去验证很关键的点，在不会对其他的功能造成影响的情况下，就可以运行最核心的case。还有，性能case、弱网case也是通过场景列表的方式传给自动化的框架的。
<b>功能自动化</b>
<b> </b>
<b>图</b><b>2 ptm</b><b>工作台</b>
我们有一个ptm工作台提供给客户端测试的人，他只需要去关心怎么发起执行，怎么查看执行结果，怎么判断当前版本的健康程度。经过简单的配置之后，它就可以执行并且收到一些结果。
<b>图</b><b>3</b><b>结果展现</b>
在这个结果中可以看到，最上面是一个简单的统计。比如，这次运行用了多少case，跑了多少时间，是否有疑似crash。运行的是哪个版本，通过了多少，失败了多少，有多少个被跳过的。每个case，它的状态是通过或者没通过，如果这个case失败了，自然有相应的截图，每个case之外的截图都有展现。比如，第一台设置在哪个界面，每个操作按照时间顺序一一记下来，并且作设备的标注，这样就方便事后复现在自动化中发现的一些问题。
<b>性能</b>
性能测试有两个需求：
第一，
在业务中人工去测试app的时候，做一些监控，比如，监控cpu、mem等等。
第二，
在自动化里面做一些固定的场景，就要去评判做一些很简单的功能case，然后把新功能的数据采集到，性能case就可以这样做出来了。
所以性能测试的流程就是初始化操作，采集数据（包括cpu、mem、流量、电量、响应时间），按照功能自动化的时间把功能一步步用自动化的case写好，结束采集，上下滑动或者左右滑动去采集fps。这些指标怎么去获得的呢？流量可以通过安卓系统希望文件直接获得上下行流量信息。加载时间通过打点的方式去做，通过服务端和客户端埋点日志。cpu由安卓系统本身拿到。内存可以通过安卓dumpsys meminfo拿到。电量把一个简单app装载在手机上，根据时间方式来获得最终的电量消耗，app装在手机端通话时，采集的时候去交货。fps使用安卓的surfacefinger。
<b>图</b><b>4</b><b>指标信息</b>
图中，在不同的场景看它的每个指标的信息。比如，首次打开、首次登陆、非首次登陆就有五百条未读信息等等。不同场景列下来，每一个场景有不同的性能指标。
<b>图</b><b>5</b><b>钉钉</b><b>android</b><b>最近三个版本性能消耗</b>
图为最进三个版本的性能消耗的对比，我们可以和历史数据进行比较。通过自动化采集信息的时候，我们都会给它一个版本，每次在采集数据的时候在数据库里会有记录，当需要版本对比的时候，直接拿历史数据进行对比就可以知道两个版本之间或者三个版本之间的差异有多大。
<b>弱网</b>
<b>图</b><b>6</b><b>网络类型的速度</b>
弱网测试是一个很实际的例子，2g、3g、所谓的3.5g到最后的4g，不同的就是移动通信的标准，它对速度的标准要求差别是比较大的。itu规定的第三代移动通信无线传输技术的最低要求中，必须满足在以下三个环境的三种要求。即：快速移动环境，最高速率达144kb/s；室外到室内或步行环境，最高速率达384kb/s；室内环境，最高速率达2mb/s。在实际的应用、测试当中，离这个标准差的还是很远的，2g下载是12kb/s，到4g是比较快的，离真正的itu标准还是有一定距离的。那么，在不同的网络情况下，怎么样进行弱网测试呢？
<b>图</b><b>7</b><b>屏蔽箱的使用</b>
屏蔽箱的手段是指，一个屏蔽箱隔绝了所有的信号，把手机放在屏蔽箱后，按照一定的设备通过显现式把它放大然后再衰减，先将它放大到一个值，然后再信号衰减，让我们方便控制衰减到一定的值时，把信号引入屏蔽箱中。在这种场景下，可以比较方便的进行弱网下的模拟和相应的测试。
<b>图</b><b>8</b><b>更简单的方案</b>
但是，屏蔽箱比较昂贵，怎么办呢？有一个更简单、更便宜的方案。用树莓派加上开源的弱网控制模块（facebook的atc）去达到模拟弱网测试的效果，就可以设置上下行流量等等。把手机连接wifi时，树梅派实现模拟弱网的测试，这也是不同场景弱网的一个消耗。
<b>图</b><b>9</b><b>问题分类报告</b>
<b>图</b><b>10</b><b>分析汇总</b>
执行层面还有哪些需要去解决？客户端同学通过ptm工作台发起case，怎样评判效果？或者发现case失败了，怎么看case是因为什么原因失败的？我们对自动化进行专门维护，针对失败进行分析，把失败的原因分类通过这个报告记录下来，下一次客户端同学可以根据这个分析结果进行判断，比如，它的每一次执行，每个分类去分析每个结果。
我们现在采用的策略是什么？一方面是执行，执行是指每日构建，每天至少跑一次针对mate版本去进行完整的构建，每周发布、每周报告。另一方面是维护，维护是外包的专人维护。目前的case数量在ui层面比较多，安卓和ios加起来大概有三四百个，满足性能的case有一百多个，弱网大概是几十个，因为ui自动化成本比较大，只有最核心的功能评估后才放到ui自动化的层面做。
<b>卞伟</b>
2009年加入百度，负责网页搜索核心模块测试，包括服务端模块的自动化、性能测试等，后负责众测平台、自动化测试框架的开发；2014年加入阿里巴巴，主要方向是手机端应用（来往、钉钉）的安卓端ui自动化建设，目前主要负责微应用的h5功能、性能等测试。