这些美团点评和阿里专家分享的移动测试最新实践，你应该学习一下

点击上方蓝字可以订阅哦

美团点评技术沙龙第024期沙龙在上周六举行，天气虽冷但抵挡不了大家的热情，座无虚席。

这次沙龙的主题是移动专项测试，由3位美团点评技术讲师及1位阿里云讲师带来一线的测试实践分享。

本文主要整理了现场互动问答环节的内容。关注“美团点评技术团队”微信公众号回复“测试沙龙”可以获取四场演讲的PPT。

 

演讲一：《移动客户端健壮性测试工具》

郭舜/美团酒旅高级测试工程师

【演讲主题】

App常常会因为接口的异常或者不稳定的异常返回而Crash，这样一来一些小模块的接口不稳定可能直接导致主流程不通，通过人工不可能完全发现这些客户端的健壮性的问题，针对这个问题开发了客户端健壮性检测工具，依据权重算法，根据接口字段的类型和配置的权重随机去修改接口的返回字段，来检测页面针对这些随机数据的健壮性如何，UI如何表现，是否会Crash。

【QA】

Q1：刚才介绍了一个流程图【见下图】，中间有自动挂代理，对代理就比较好奇，您说的那种带代理是什么类型的？

A1：http&https协议类型的代理，在手机上直接把WIFI挂上代理以后，会把整个手机App的http流量转到looper，像抓包一样，如果加了这个工具以后可以对接口整个生命周期进行控制。因为我们是纯黑盒，所以需要给手机挂代理，而不是直接在App里面切Server的Host。

Q2：数组越界是什么意思？

A2：App代码Crash类型的一种，举个简单的例子，一个广告模块可能会有多个Banner，如果在代码固定了最大的宽度（开辟了一个定量的比如5个length的长度数组），后台如果返回6个，当你取index为6的Banner的时候App就会直接Crash。

Q3：专门负责破坏的部分，应该有针对某一个接口的好多Crash、脚本去做，这时候当开发团队把接口自动化了，该怎么去维护这些脚本，大概要占多大的工作量？

A3：我们不是以脚本方式，而是以半随机的方式去进行接口破坏的。拿到代理的接口，我们会根据权重破坏，不会为每个接口维护Case，因为维护的工作会是巨大的。如果命中不改就不改，命中改就改，具体怎么改，这是一个半随机的过程，不会进行每个接口Case的维护，如果按照接口去分析这个量太大了。

演讲二：《问道移动测试在线录制技术》

竹逊/阿里云高级开发工程师   

【演讲主题】

功能测试脚本的编写，一直是很多测试人员头疼的问题。工作量大，效率低，脚本兼容性问题，脚本不稳定等等，都是阻碍自动化功能测试实施的元凶。因此，在线录制技术应运而生，它是如何产生的，如何解决这些问题，又该如何发展，我们一起探讨。

【QA】

Q1：回放的频率和成功率是怎么样的？利用回放手段既有ToB，也有ToC，在商家接单是两个独立的App，这个怎么解决呢？

A1：回放的成功率需要分开来看，假如说现在是按照控件来布置，基本上能够95%以上，控件回放成功率是非常高的。但是对于一些没有拿到控件，或者是拿到的不是一个正确的控件的情况，回放成功率不高，只能通过坐标或者是一些文本信息、其他信息去判断，其实成功率卡就卡在控件获取上。

如果成功率大概在百分之六七十的时候，需要人工去适用脚本。我们也在做一些方案，目前是在做一个图像识别的方案，希望在录制的时候结合当前录制到的信息，以及录制的时候在这个手机上截取一些图像信息，结合这些信息，能够辅助回放时定位更准确。

 

至于后面两个App互动的场景，我们现在还没有支持，这还只是单独一个App的场景。

Q2：在线录制的时候刚才听您说优先XPath的方式去定位，不知道为什么选择这个定位和元素，因为通过这种方式效率比较低一些。另外，我们在录制的时候点击这个元素，如果存在ID或者是XPath，Text都存在，是否有一个优先级、闪用的机制存在。

A2：其实我们之前也没有考虑XPath，是用Id和Text，很多跑的时候还会存在一些问题，因为有些东西确实Id和Text都没有，这种情况下只能通过XPath去做。至于XPath的效率比较低的问题，对回放来说，不会特别要求它的效率问题，它不会影响到App的响应；相对于App响应来说，进行真正回放时，一个App启动一个网络请求可能会需要好几秒，这就已经是比较长的时间了。通过XPath去定位，延迟可能会有一些，但也不会超过一秒，对于App本身的响应速度来说，该延迟可以忽略，因此后来就没有考虑XPath的性能问题。

当XPath、Text、Id都存在的时候，目前还是选择XPath，它是最准确的，当然最近也发现，App应用的XPath也存在一些问题，对于Webview来说，不同的手机对应的XPath可能会不一样，外部控件整个XPath整套路径会多一个控件，所以Webview中的XPath需要进行一些适配。

Q3：我们有可能会测全流程的自动化，假如下单之前有一个余额的检测，下单之后有一个账户余额的验证，怎么把这个验证点加入进去？

A3：余额怎么去验证，这也是在我们的展望里面未来要做的事情，目前在录制的时候有封装几个动作，比如等待、滑动，后面会加上其他的动作，封装一些常见的操作。

举一个例子，有些App在第一次安装手机上的时候会有一些特定行为，假如说把它卸载掉第二次装的时候这些行为就没有了，这种情况就需要判断某个控件或文本是否存在，存在就做相应的动作，假如不存在就直接跳过去。这其实就是需要一个IF的动作。断言我们也会封装成一个单独的动作以及其他动作，这里就先不展开说了。

Q4：现在好多团队都在做自动化测试，我们也在尝试，比如，做图像识别时会发现图像匹配非常慢，耗时虽然优化算法，目前没达到一秒以下。我想问一下，你们团队有没有遇到过耗时、准确度等问题？

A4：准确度的问题是有的，录制通过图像识别，而且在录制的时候会在手机动作之前的截图拿到，在里面鼠标点击的动作截取周围一块小的区域，回放时把图截下来，通过小的区域以及当时点击的动作坐标去进行匹配。现在准确率还比较高，个人觉得能够达到90%以上。

但是有一个问题，有时做游戏测试，假如录制时有某一个小精灵，截到它的图，在回放时精灵位置发生了变化，这时候再用坐标去辅助定位就有问题了，所以对于随机性的东西，会发生一些错误。现在我们的策略是做一些调整，图像本身匹配的会有一个可信度，再结合坐标，将坐标和图像匹配综合起来放一个权重，去调节这个权重。针对游戏可能不会把坐标的权重加的很高，但是Webview应用的东西，还会用坐标辅助，准确率比较高。

关于时间的问题，不会特别快，只要功能测试时间不是特别离谱都还可以，一秒、二秒在接受范围内。

Q5：一个场景是用来抓非常不容易的Crash，有的Crash自己都弄不出来，用户弄出来一千多个Crash，必须要去修，需要很快的点击掉，你们有考虑在脚本里加一些质量控制，活着用户自己设置时间可行吗？

A5：根据我们的经验来看，功能测试追求稳定性的话，每一步是不能太快的，太快会导致脚本不稳定，所以我们没有做相关控制。如果快速点击才能出现的Crash，推荐我们团队自己研发的一套东西Ripper，它会解析当前App的状态，拿到里面的一些控件，根据这个控件去做一些操作，快速点击或者是多次双击，从而发现隐藏比较深的Crash。个人觉得功能测试更多是要回归一些主流程的东西，我们不会用功能测试来发现bug。

演讲三：《SDK深入专项测试》

张迪/美团点评高级测试工程师    

【演讲主题】

随着业务和技术团队的不断扩大，越来越多的基础通用功能以SDK的形式集成在客户端应用中。以往针对SDK的质量都是需要上层调用接入方做兜底保障，使得SDK的质量保障很被动，也给调用方带了不少风险。 本次Topic主要介绍美团定位SDK的质量保障实践，主要包括：测试方法论、测试工具和测试流程，分别从单元测试、集成测试、专项性能测试等纬度保障SDK产品等质量。

【QA】

Q1：想问一下利用ADB是否也可以实现自动化？Python脚本是否可以以API方式抓取性能数据？

A1：第一个问题，ADB可以结合脚本进行操作，从而实现自动化，我们这样做的是因为需要进行户外测试，使用PC连接ADB不方便，所以实现了脱机方案。第二个问题，目前我们是在Android的内部去抓取一些性能数据，比较依赖于Android平台，是基于Java技术栈的，通用的性能抓取功能可以打成一个jar包，利用Python也可以调用。

Q2：下载的时候会实时刷新吗？数据进行保存

A2：有一个间隔，没有办法把这个数据做收集，这块用的App脚本，应该是可以设定执行的频率，以这个频率去抓取数据，数据可以进行二次处理，进而获取你比较关心的数据。

Q3：AS上的网络或者是数据不准，我问过一些人，他说这个工具不准，只是看看，不能作为数据实时显示刷新等

A3：具体准不准我也没有做过具体的对比，不同测试工具和测试方法得到的测试结果是有一定差异的，按照原理Android有一个专门记录流量的数据文件，都是从属一个数据源体系的，理论来讲数据是一样的，如果不放心，自己去处理这个文件和数据应该是最准的。其实只要保证每次测试使用的工具和方法是一样的，数据坐横向对比也是有意义的。

Q4：我们现在没有做API，是用SDK去实现的，但是有一些API是没有界面的，刚才看到的地图调用的时候界面会展示出来，并同步CPU以及其他的性能的，有些API是没有界面去展示的，这种情况您怎么看？

A4：其实刚才讲到的定位SDK也是没有界面的，有界面是那部分包括地图、按钮、数据展示都是自己实现的，所以我们需要在刚才的专测工具上面有一个UI Demo层去画一个，这样就解决了SDK的易测性。

Q5：怎样写一个App，然后去调用，因为这个在实际使用过程中会和别的模块有关联？

A5：测试的时候有耦合，我相信还是使用测试隔离的方式，只测你要被测的模块就可以了，如果其他模块引入有不确定性因素，个人觉得这不是你所控制的范围之内的事情。

Q6：比如这个依赖于另外一个API的返回结果，你们是怎么单独做的呢？

A6：依赖使用Mock工具，要测试A方法把B方法返回进行一个Mock，常用的Mock工具Mockito，EasyMock等，写一个大数据进行返回，也是做测试隔离，解除各模块的依赖性。

演讲四：《服务端自动化测试体系》

孟国军/美团点评高级测试工程师  

【演讲主题】

本次Topic围绕自动化测试体系将从框架建设、持续集成、应用性、度量几个方面介绍，重点介绍框架特点，持续集成方式和度量角度三个方面。中间包含接口管理方案，自动化用例管理方案，持续集成方案，自动化报表统计方案。

【QA】

Q1：做接口自动化测试有一些字段是非必须的，如果校验会有误报的情况，这种是怎么处理的？

A1：做接口测试的时候，从业务需求出发，你只需要关心你待测需求的接口字段。RD、QA在做技术方案评审的时候，已经确定了哪些待测字段。

Q2：做接口自动化代码覆盖，如果是线下去测代码覆盖率，这块是怎么做的？

A2：解决方案基本上都是类似的，我们QA的环境都是自己的，包括QA有两套环境，都是自己维护，服务启动的时候会自动加载Jacoco插件，测试时会拿到代码覆盖率。

Q3：环境是装在Docker上吗？

A3：不完全是。其实Docker就是一个虚拟化技术，就是提供给我们部署环境使用的，除非对网络要求或者是易用性的要求比较高，如果没有这些要求采用Docker物理机都差不多。我们这边有一部分都是通过Docker去实现的，还有通过其他的，这个关系没有多大。

Q4：Docker不是执行项？

A4：Docker是一个容器，可以做到隔离，包括Linux的资源，CPU、内存、容器、网络，只是做一个隔离，可以快速部署服务或者自动化，对于QA不需要感知。

无法到现场的长三角技术同学无须遗憾，本周六下午两点，上海站启动，欢迎点击阅读原文报名参加~