2017年1月23日周一晚8点30分，饿了么技术&创新中心MT移动技术部工具开发组负责人任海燕带来了主题为“饿了么移动测试平台探索之路”的Chat交流。以下是主持人赫阳整理的问题精华，记录下了作者与读者之间的问答精彩片段。
2017年1月23日周一晚8点30分，饿了么技术&创新中心MT移动技术部工具开发组负责人任海燕带来了主题为“饿了么移动测试平台探索之路”的Chat交流。以下是主持人赫阳整理的问题精华，记录下了作者与读者之间的问答精彩片段。
问：一定要自己重新研发移动测试平台么？是否可用云测平台或者其他自动化测试工具来代替？
答： 其实这个要根据公司和团队的具体情况来做选择，并不一定非要自己重新研发移动测试平台。我们之所以选择自己研发是因为云测平台无法满足我们目前的测试场景。如果使用云测平台，或者用自动化测试工具就能满足公司或团队的测试场景，那么可以不用自己研发测试平台。
问：可否介绍一下饿了么Mobile Infrastructure Platform？
答：饿了么Mobile Infrastructure Platform是移动技术部研发的一套移动基础平台，主要包括持续集成、灰度发布、Hotpatch功能，将从代码提交到最终发布的整个流程统一起来。文章中提到的Stellar系统将作为测试平台与之进行紧密协作，在原有的流程上增加自动测试的部分，最大程度的保证发布质量。这套移动基础平台其实还是比较复杂的，几句话很难介绍详尽。
1月8日在饿了么举行的移动技术开放日上，饿了么架构师王朝成老师有介绍过，感兴趣的可以到这个链接查看。
问：在踩坑经验中提到了任务调度问题，能否具体说一下目前是怎样进行调度的？
答：任务调度的难点在于任务可以并行下发，但是设备只能串行执行。其实文章中有提到过，我们也没有特别好的解决方案，还在调研中，目前先采取设备任务排队的策略，即如果设备上有任务正在执行，则当前任务处于等待队列中，待执行完当前任务后再从队列中取出下一个任务下发给设备。在界面设计上，任务下发以后可以不用在原页面等待，任务的所有设备都执行完成后给用户一个邮件反馈通知。 希望大家如果有好的想法也提出来，可以一起研究一下。
问：你说的这个移动测试平台是如何解决APK 与APP 之间的自动化执行的问题，还有你说的你们内部开发的自动化执行平台能具体介绍下吗？
答：第一个问题我按照自动化测试具体包含哪些内容来回答一下，主要包括App的自动安装、自动启动、自动跑测试脚本、自动卸载，并且会记录测试过程中的log和CPU、内存等信息，并在执行完毕后以测试报告的形式反馈给客户。
关于自动化执行平台，是指的饿了么Mobile Infrastructure Platform吧？在上面的回答有介绍过，可以参考。
问：关于大量场景的case 你是怎样结合平台进行执行的？
答： 大量场景的case如果是指的UI自动化的话，考虑到业务迭代快、UI自动化的投入产出比很低，我们暂时没有把UI自动化的部分加入到平台中。
问：不知道有没这种场景，把每个分发平台都作为不同的渠道，对于app的交易，拉新，留存等活动每个渠道都可能有不同的规则属性，不知道当前的系统有没考虑到类似规则分类场景？
答： 这个问题涉及到了渠道包分发。目前饿了么合作的渠道商有上百家，而且不是每一家都提供自动分发的API，即使有提供的，我们去做自动分发，投入产出比也比较低。所以我们现在的做法是打好包，交给运营人员，由运营人员自己根据情况与渠道进行对接。
问：对于app闪退如何获取信息来排查？控制手机的机器是linux？没有看见在docker里运行的是什么？
答：先说一下app闪退的排查。app闪退发生以后，其实通过log中的stack trace已经可以定位90%的问题了。剩下的10%，要通过闪退时系统信息的快照来排查，比如内存、CPU、耗电量、网络状况等等。所以在进行app的测试时，需要同时监控log输出、内存、CPU等等一系列的系统参数，尽可能的保留闪退发生时刻的系统快照。
docker这个问题，是否是想知道我们使用docker部署，具体docker里面运行的是什么吗？如果是这个问题，我可以回答，我们主要是用docker来进行手机管理的分布式部署，里面跑的是STF的provider服务。
问：饿了么移动规划是怎么样的？都有什么需求？觉得困难在哪儿？
答：饿了么移动规划这个范围比较广，我可能了解的不是很全面，那么就说一下移动测试方面的规划吧。未来移动测试平台会作为移动基础平台的重要部分，将代码提交 -> 代码扫描 -> 自动构建 -> 自动打包 –> 自动测试 -> 灰度发布 –> Hotpatch的整个流程连接起来，最终目的是提高生产效率，开发人员提交代码以后可以很快的得到反馈，测试人员也能通过平台进行一部分自动化测试来提高效率。
问：你觉得STF使用过程中有什么困难，经验可以分享给大家？
答： STF使用过程中确实有一些困难。第一个就是STF源码阅读需要一定的技术门槛，涉及到nodejs、angularjs、zmq、protocol buffer等等，这个对我们算是一个不小的挑战；第二个困难是手机连接限制的问题，我们试过mac book pro的配置，用usb hub1拖6就开始不太稳定了，很容易断开连接。
问：测试回归覆盖率怎么提升，有什么比较好的UI自动化的测试方案？
答： 首先说一下如何提升测试覆盖率。首先是从需求方面着手，要从需求评审开始就接入，尽量把需求理解透彻，带着设计用例的角度去看需求，可能会把一些隐藏的问题挖掘出来。
举个例子，测试我们的发布系统的时候，需求写明app在测试环境测试通过后可以推送到生产环境作为预发布版本，带着用例设计的角度，就需要考虑一些错误处理的场景了，比如生产环境已经有这个版本了怎么处理、生产环境的版本比推送过去的大怎么处理、推送过去还能撤回吗等等，有了这些问题，再去看需求，理解就会深一些了。需求理解深刻，测试用例覆盖度就会提高。另外一点，在测试执行过程中以及系统上线后，如果发现了测试用例之外的bug，一定要及时将复现步骤补充到用例中。有了这些，可以提高测试回归覆盖率。
再说一下UI自动化测试方案。我曾经使用Android的UIAutomator做过一段时间的UI自动化测试，但是我个人不是很推崇UI自动化。原因：一是现在的App的构成越来越复杂，有H5、native、hybird，很难找到在这些情况下完美识别UI控件的自动化测试工具；二是业务迭代比较快，界面时常变化，导致UI自动化用例的维护工作量变大，测试人员疲于奔命，投入产出比太低；三是UI自动化仅在App最上层做验证，有些后台逻辑可能会覆盖不全。所以这位同学，如果你的被测产品是界面比较稳定的，你可以考虑使用UI自动化工具(Appium、UIAutomator等)，如果不是，就放弃UI自动化吧。
用例设计的面比较广，其实最痛的地方还是需要把功能测试用例在尽可能多的手机上执行一遍，这个可以通过云测平台解决。目前我们平台上还没有增加业务场景定制的测试部分，因为大部分都是UI自动化，我在刚才的回答里面也有提到，UI自动化投入产出比比较低的。
问： 你说的app闪退 排查信息 也是在自动化工具里面嘛？
答： 已经包含进来了。自动测试中包含了自动启动App和执行测试脚本，启动、执行过程中，会监控系统log和系统参数，最后把结果以测试报告的形式反馈到界面上。app闪退其实log中是会有stack trace记录的，出现闪退，测试报告中的测试结果就是测试失败。
问： 你们在stf的实践中，是如何排除限制连接数的问题的？我知道开源的那个貌似有限制，140多台吧。感觉这套平台主要还是应对安卓的，ios平台来说有什么好的实践吗？
答： 是的，我们基本是作为冒烟测试来执行的，主要看在不同的手机品牌、rom上能否正常启动app、点击页面是否会crash。其实目前痛点比较大的还是安卓，碎片化很严重，所以我们这个平台主要针对安卓系统。iOS系统暂时没有考虑进来。
stf的连接限制问题我们也是比较头疼，曾经试过单台mac book pro，用usb hub 1拖4的方式接了8台手机，然后连接就开始频繁断开了。现在是在尝试分布式部署，就是把stf的provider分布式的部署在其他几台机器上，然后与主服务通信。stf的provider是可以单独部署的，查看一下源码中的DEPLOYMENT.md的说明即可。
问：自动化测试用例是不是最后还是交给业务测试来做？平台端的测试开发来搭架子和底层实现？
答：我们的想法是，自动化测试让业务人员介入的越少越好，所以如果以后有需求需要增加业务的自动化测试用例，一定是由平台端的测试开发来提供用例步骤、用例数据的配置界面，以及服务端的mock，业务测试人员只要写DSL的用例即可，由平台通过DSL和测试数据来生成自动化测试用例去执行。
DSL是测试步骤的描述语言。比如一个测试步骤为点击OK按钮，DSL可以为 click button "OK 也就是说，我们提供控件、动作的选项，由测试人员将之组合起来成为测试步骤，然后根据步骤去生成用例，这样能最大限度的减少给自己挖坑的机会。
问：目前这个平台使用下来还有哪里内外部的困难？因为我们知道做一个平台，前期花了很大的人力物力，最后做评价的还是最终生产力。
答：其实平台的研发是大约16年底启动的，目前还在持续迭代中。研发过程确实投入了很多，前期的需求调研、技术选型，还有过程中踩了好多坑。目前已经完成了雏形，还处于内测状态，接下来可能还需要几个迭代去完善平台的功能、多与业务部门的测试同学沟通需求才能真正投入实用。
我们一直在努力，其实研发最开始由我们组的小伙伴们启动的，但是后来得到了很多其他组同事的支持，包括对我们的技术架构提出很好的意见和建议，在此也对他们表示感谢。
在此感谢人民邮电出版社，为本场Chat的获奖读者提供了《优质代码》一书。
（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文：《任海燕：饿了么移动测试平台实践解析》）
