第五阶段
在趋向稳定之后，我们也做了不同类型的测试，比如基于Monkey的稳定性测试、性能测试、升级包测试、安全测试等。自动化执行一段时间之后，我们收集了很多脚本用例方面的数据和崩溃的数据，也通过图表对这些数据做了一些趋势的分析。
不同于原来的只有UI自动化，第五阶段我们用了“任务类型”的概念，为了适配这些稳定性测试和压力测试的场景，我们通过区分任务类型，在APP端执行不同逻辑来收集不同的报告，然后归类，上传到web端展示。
1. 稳定性测试
有时候我们需要对一个固件进行7×24小时的持续稳定性监测，同时希望控制整体时间和初始的种子，对于运行崩溃或无响应问题，做到持续监控和收集，对执行期间APP的基本性能信息进行监控。基于这些要求，我们做了一些稳定性测试的功能。
上图是我们执行稳定性测试过程中的报告，会展示一些具体的执行命令。下面的时间轴展示执行过程中哪些时间点出现崩溃、无响应或重启等信息。这只是具体崩溃的截图，是整个页面的一部分，比如某个时间点发生了崩溃，下面就会有具体时间点的截图，可以在这个截图的控件上找到它崩溃的Log信息。还有一个图表来展示整体的CPU内存曲线以及FPS变化曲线。
有些人可能觉得只有崩溃信息是重要的，但是我们把崩溃信息和性能信息联系在一起，并经过一段时间的收集之后发现，不仅是崩溃异常栈，一些性能的信息展示对具体问题场景的分析也很重要。比如我们发现一些APP在无响应之前会有比较高的内存占用，或者在崩溃之前会有一些异常的波动信息。
这是具体查看崩溃Log的页面，这里可以看到崩溃的异常栈。有了这个页面之后收集崩溃信息就很方便，不用再专门用Logcat查看。
2. 性能测试
性能是一个比较难讲的问题。举个例子：一个固件，我们只针对某一个指标高低是否就能判断固件的性能问题？应该是不能的，我觉得只有对一系列指标的整体对比才能正确的描述这类问题，比如通过API获取系统启动时的一些信息。本次启动用了多少秒？系统启动时有多少线程和进程？这些线程和进程的内存占用是多少？系统整体内存占用多少？常用应用需要多少毫秒完成冷启动，这些数据跟上几个版本有怎样的差异？
这是性能测试的具体页面，可能有时候这个曲线的波动会稍微大一点，但是整体趋势基本是这样。我们针对某一个系统常驻的进程，跟踪他的线程数量，可以在早期发现一些性能问题。比如开发写了一个新的功能，我们可以通过这个曲线的变化为新功能的性能信息提供参考数据。对于多个版本持续的指标升高或者降低我们也会提供额外的预警信息。
3. 升级测试
我们现在主要的测试对象是以固件为单位。这个固件会针对不同的机型编出来，所有机型加起来可能有几十个。这些固件有很多增量包，我们需要对整包和增量包的质量做监控，比如检查收集升级前后它的基带是否符合预期，Recovery、kernel版本是否匹配，同时评估升级的耗时。
现在固件特别大，一个基本上都是上G的体量，这个工作起初都是需要人工去检验的，后来机型越来越多、固件越来越大，人工去做会比较繁琐，我们就做了这样一个工具来检查。上图展示的是检测具体增量包和整包的升级结果。
4. 安全测试
前段时间有些APP爆出来端口开放问题，为了通讯方便，一些APP没有用系统的AIDL接口，而使用HTTPRPC这样的协议通讯。这就导致同局域网的人可以利用这些RPC接口做一些比较危险的操作比如读取隐私数据、打电话等。针对这样类似的情况我们做了这样的尝试，监控系统主要组件的暴露情况，监控一些端口的开放以及使用特殊的intent触发组件，检查会不会暴露出来特定的敏感信息等，然后把这些信息推送到平台，形成一些开发课题或者安全缺陷告警。
这是安全测试的页面。我们会收集某些特定的APP版本信息并做一些基础的安全性展示，包括：它暴露哪些组件、这些组件是什么，是否开启debug等。
第五阶段我们主要做的工作是专项测试，我们觉得专项测试在现在的场景下是比较重要的，能有效补充UI自动化的不足。UI自动化是通过关键点的点击去检查不足，而专项测试可以从不同角度检查产品是否存在问题，包括性能方面、流畅度和安全方面等。
魅族的ATS平台
魅族自动化测试发展的5个阶段都是在我们内部的ATS平台上产生的。我们在整个自动化的研究过程中遇到了各式各样的问题，比如最开始的初始条件和脚本稳定性，到后来需要集中资源，再后来需要专项测试，我们希望有一个统一的测试平台来完成这些工作，所以就开发了ATS，它整合了UI自动化测试，压力测试、性能测试等。
我们也通过一些配置和调度功能去降低UI自动化的使用成本。以前UI自动化只有特定的代码编写人员才能使用，平台完善之后基本上整个测试体系的人员都可以通过平台对一些特定的APP做特定场景的测试，比如UI测试、稳定性测试和性能测试等。在测试的过程中，我们也把整个测试的数据做了一个有效的收集，比如我们通过形成各个阶段的流畅度、性能报告，向不同的测试和项目经理展示项目的质量情况。
这是ATS平台的截图。ATS平台主要分为在线设备列表、任务管理。调度计划是我们通过衔接整个流程去达到固件产出后自动执行自动化的功能点。还有一些模块管理和其他类型的报告，比如升级测试、稳定性测试等，还有一些收集缺陷的功能。
这个界面是具体的在线设备的展示。我们会定时收集设备的状态、电量等，方便用户了解设备的状况。
自动化过程中遇到的问题
我们经常遇到的问题是：有一些控件是通过API找不到的，比如一些状态栏上的控件，还有一些WEBVIEW，无法有效地从WEBVIEW中选择到控件，API基本上达不到预期的效果。
从我们的角度理解，有很多这样的操作是没有办法完成自动化，或没有办法按照我们预期的成本去实现自动化的。有一些解决方案不是最优却更合理，比如一些控件，其实我们的目的只是检查它到底存不存在（从可见性上讲），虽然我们可能拿不到控件，但是我们可以用预期的图像与当前做对比，这样也能达到测试的目的。
现在我们面临的另一个问题是内部整个平台流程的流通都是依赖WIFI传递信息，但是很多公司会出现信道干扰严重、固件尺寸越来越大、WIFI质量特别差的情况，在做固件的下载或特别大的资源包的下载工作时，这些情况就会严重困扰到我们。我们采用了另一种方式：通过ADB的命令把PC端的端口映射到设备上，下载的过程就可以通过USB线来传递，很大程度上解决了这方面的问题。
我们当然没有办法把所有用例都实现自动化，比如多设备之间的交互和验证码的问题。验证码有办法实现，但成本比较高。对于这方面的问题，我们认为既然有些东西没办法实现自动化，那就干脆不要做自动化。自动化要尽量保持简洁、稳定、高效，做了大量的工作去实现而稳定性却不好，这样的尝试是得不偿失的。
多设备的交互，我们内部也有一些用例会涉及。例如手机A给手机B发短信、打电话的场景，我们有了推送之后，可以点对点的将命令从A推送到B，这样A和B之间便可以协调起来验证一些电话或短信功能。当然这样的场景是很简单的的，具体到一些复杂的多设备交互场景，自动化可能难以低成本的去实现。
UI自动化的理解
UI自动化无法替代人工，受限于现有的技术和测试复杂度，很多地方没有办法用UI自动化。它的容错性也差，辛辛苦苦写了UI自动化脚本又要根据开发的变化时时维护。另外，除了回归验证以外，收益不高，UI自动化的介入基本上在大量的人工测试之后，能发现的问题并没有想象的那么多。很多人对UI自动化的期望是：UI自动化能代替人工作，就不用人工去做了，只要写一个自动化脚本就可以了。这是不可能的，它发现的问题并不是很多，不能期望UI自动化帮你做太多事情。
让“自动化”自动化，意思是在实现整体的自动化之后，我们希望自动化可以为上游的固件产出提供测试接口，把整个流程连接起来，为下游报告提供一系列的统计分析结果，为产品质量提供有说服力的数据。
很多公司可能在自动化上还要人工做一些干预，比如一些测试的预置条件需要人工干预。自动化如果不能完全自动起来，需要人工干预，需要人来执行，那就不是成功的自动化。一个理想的自动化就像一个黑盒子，数据从这里流入流出，为我们提供一些信息和质量数据。
UI或专项测试做完之后，我们现在的方向是通过底层的东西了解系统的问题。安卓发展到今天，应用质量趋向于稳定，很少有线上APP崩溃的体验了，但是不崩溃并不代表它已经做到足够优秀的程度了。我们希望通过调用栈的信息去获悉耗时和卡顿的具体原因，或对流畅度、资源占用做分析。
将来，我们能在专项测试上做得更好。我们之前做了一些专项测试，包括安全、稳定性等，但也有很多专项测试还没有做，比如现在APP耗电严重，我们希望能在我们的层面评估一个APP到底耗电多严重？为什么这么严重？为什么不流畅？还有哪些安全问题我们没有分析和挖掘出来？……我们希望能做进一步的研究和探索，让APP质量更好，让用户体验更好。
