本文根据2018云栖大会深圳峰会·EMAS专场—移动互联的进化论，阿里巴巴技术专家字白《泛质量管理解决方案》的演讲整理而成，文中就EMAS泛质量管理解决方案如何一体化构建高效、专业、立体的质量管理体系进行了分享。
今天的演讲主题叫“泛质量管理解决方案”，为什么叫泛质量呢？这也是根据之前的思考，包括我们集团内手机淘宝的成长路线，慢慢有些不一样的理解。之前我们做测试，我们就是发现Bug，去解决Bug，现在看起来只是这个点还是不够的，比如说我们可以在研发阶段做一些事情，我们在线上监控做一些事情，这样我们才能更好地去做整个全流程的质量保证，不单单是找Bug这一点，我们在前、中、后要做很多事情，保证APP到用户手上是一个很好的状态，这就是这个泛的由来。
移动测试的现状和问题
今天分这样几个阶段给大家讲讲，我对整个泛质量管理解决方案的理解，然后看看大家有没有一些共鸣。
先讲一下移动测试的现状和问题。我们现在做移动端的测试，因为移动端测试本身机器也比较多，碎片化也比较严重，另外APP的业务逻辑不像PC端那么简单，可能我们写了很多脚本，花了很大力气，但是发现下一个版本来的时候，大部分都用不了，要么就重新写一遍，要么就人工去点，这实际上是很痛苦的过程。
主要的问题有四个，第一是我们做移动端的测试，在发版前做回归测试。正常我们是三周做开发，一周做测试，测试完之后修改Bug，然后就发布，基本上是这样的流程。我们只关注了上线前这一个点，实际上在研发阶段，这个点是空白的，要么就是要人工去点点，这个还是不够，一会儿我会讲讲我们的解决方案怎么帮助大家提升效率，解决问题。
第二点就是整个过程还是比较被动的。现在我们有一些bug提出来，开发同学可能觉得这个问题没什么价值，也不去改，但是客户给我们客服打电话说这个问题很严重，我用不了了，尤其客户是一个VIP的时候，我们就很上心，很努力地把这个事情解决掉。这反应一个问题，我们的APP上线之后，用户这边有些比较严重投诉的时候，能反推我们去做很多的改进。那我们是不是应该有一套更好的监控体系，在用户发现问题之时，我们就立马也能知道有多少人有问题，这个问题有多严重，我是不是立马要解决掉，这个背后是要有一套度量标准支撑的
我们要做线上监控，做线下测试，很重要的一点就是能够发现程序问题。这里面有一个点，就是说问题是需要被界定的。我们知道崩溃是一个问题，这个大家都好理解，但是性能是一个问题，这个就不好理解，比如说我的启动时间是一秒钟，他的启动时间是三秒钟，哪个是问题，这是不确定的，这是要根据我们业务来的，真正用户感受有问题的时候，那个就是有问题，所以这时候我们需要有一套标准，这个APP到2.5秒的时候就不合格了，因为用户已经受不了了。这是另外一点，没有一个数据化的支撑帮助你感知到线上的问题。
最后一点是我们做很多的测试活动，有一个很不好的地方，我们做测试的时候雇一些外包同学做测试项，但是业务的经验是跟人走的，这是很不好的，一旦这个人走了，我们要再找一个人，再积累一段时间让他熟悉这个业务，这是一个很不好的事情，但是是不是有一种方式，有一个人做得很好，他能够不断地把他的测试方法、测试技术沉淀到这个平台上来，后面的人就可以很好地利用前面这些人积累的经验，做很好的质量保障，这也是一个问题。
泛质量管理解决方案
第二部分讲讲泛质量管理解决方案。核心就是一句话，以数据为驱动力的智能DevOps。
什么意思？以数据为驱动力，这里面涉及到几个点，线上我们的整个用户数据没有很好地被利用起来，比如说我们真正去解决线上问题的时候，大家可以想一想，有一个人说这个有问题，你帮我去看一下是什么问题，赶紧给我解决掉。
一般情况下研发团队就是打个电话或者通过其它的渠道联系上他，问他是什么样的手机，是什么样的环境，是怎么操作的。然后按照用户的反馈，再一点点去摸索，找这个问题在哪儿，这个过程很痛苦，整个问题的发现到分析到解决，大部分时间都集中在分析这个阶段，最后解决那一下可能一行代码或者几行代码就搞定了。这里面就暴露一个问题，我们对于用户的整个行为，对当时的现场，其实数据是不全的，这就导致我们解决问题就很困难。
实际上我们就提供这样一套数据的采集方式，让大家能够在问题发生的时候不单单是把你的崩溃栈拿出来，还要把你的内存信息拿出来，甚至把全量的日志拿出来。怎么拿呢？定向的捞取当时哪些同学、哪些人、哪些手机上出现了这个问题，非常有针对性的定向获取这些更详细的信息。只要这个问题出现了，我一定帮你把全量的信息找回来，这样我们解决问题就不用去猜了。这是一个线上的场景。
再举一个线下的场景。我们去做线下测试的时候，我是做APP的开发，或者我做APP的测试，我对业务很了解。但是实际上我们发现，到线上整个质量的情况并不是像我们想的那么好，崩溃率有可能是百分之几，有可能是千分之几，当然千分之几已经不错了，但是质量情况并没有百分之百。这就有一个问题，用户怎么用APP跟我们理解的其实不一定是一样的，可能90%用户跟我们想象的是一样的，但是10%不一样，这个10%的人群就造成了90%的Bug。这是对线上的用户怎么理解我们的APP没有感知，没有数据支撑。这也是一个点，我们能够帮助大家去把用户怎么用APP这样一个画像给画出来，其实就是一个概率的统计，我们可以告诉你，有50%的用户他是怎么用这个APP的，他这个流程里面是不是有些问题挡到他，然后影响他使用了，这些问题是不是崩溃问题，是不是性能问题，这样就可以让大家解决掉。
那这个“智能”什么意思呢？是指我们通过数据可以驱动大家做一些决策。
举一个发布的例子，我们把APP灰度到线上之后，可以看到数据，现在的崩溃率可能是10%、20%，但是这个数据背后我们应该做什么？这是需要我们去思考的。可能20%的时候，我们这个标准的模型里面就应该是打回到线下再去做整个的复现、验证、改Bug，然后再去做灰度，1%的时候，我们就扩大整个的灰度量，这个流程都是完全智能化、自动化的，当然还有其它的点，刚才我讲的线上怎么用，这些数据都可以在线下的智能引擎里体现，他在做自动化的时候就看你的用户是怎么用，这样帮你做测试，这样的效果就更全面、更准确。
面对刚才说的那几个问题，我们的泛质量解决方案是不一样的。首先是整个质量管理过程横跨全研发流程。从写代码开始，我们就可以通过专有云去做持续集成，不断地做迭代、做UI自动化测试。因为这些脚本都是在平台上的，我们可以通过自动化，持续触发这个测试活动。测试阶段我们有全量的机型，帮助大家做专家测试服务，在上线之后，我们有线上的监控，不管是崩溃也好，还是性能问题也好，还是其它的一些问题也好，我们都会有各种监控。大家在尝试修复线上问题的时候，不可能有一个严重Bug等着下个月发大版本的时候再解决，所以我们提供热修复能力，可以快速把这个问题解决掉，这是从发现问题到分析问题到解决问题，这样一个全面的链路，不单单是一个点。
另外一点就是数据驱动，刚才讲了，我们这里面有大量的数据场景，能够把线上的数据通过一定的训练模型，能够告诉大家，当时是发生了什么事情。比如说线上的崩溃问题，崩溃问题怎么解决，可能单单看某一个崩溃问题，它是一个孤零零的个例，如果你把它做数据统计方面的分析，你会发现它有些内在的关联性。比如说我会发现可能我这个Bug大部分问题发生在深圳，或者说那个Bug大部分都是在用户切到后台5秒钟之后崩溃的，这些实际上都是需要我们把这些数据挖掘出来，然后给我们开发者一些具像化的理解。
第三个就是主动感知。这就是刚才讲的两个点，一是我们要有一套比较好的估量标准，告诉大家什么是问题，尤其是那些我们不好界定是不是问题的，这个要用用户的感知来界定，我们有这样一套标准。这个感知之后，出现问题之后，我们要告诉大家，发一条短信或者发一条告警给大家，现在你的用户在线上有多少的比例，已经遇到什么问题了，已经影响到业务的活跃度了等等。
最后一个就是整个泛质量管理解决方案的功能或者模块，其实很大的一点是有很高的开放性，不管是open API，还是这个平台在基座上支持的很多插件，客户的技术同学、开发同学都可以基于这个基座做横向的扩展，这样每做一个模块进去，我们这个模块就沉淀到这个系统里面来，后面再来的同学可以直接享用前人的成果，不需要再去一点点研究，这样的话，实际上加快我们整个团队的技术建设，包括我们对业务的快速理解，其实都会有很好的帮助。当然这个点一旦提升起来，我觉得可能对我们整个测试团队的技术使命感会有很大的帮助。我知道有一些APP开发者没有专门的测试同学，有的可能雇一两个外包，这样整个技术氛围会有点差，这个平台会把很多你没有遇到的问题摆到你的面前。而阿里云会站在客户背后给予最大的支持，帮助大家解决问题。
这是我们整个泛质量管理解决方案的大图，功能全部在这里，覆盖了研发、测试、运维、运营，今天我会主要讲研发、测试、运维这三个阶段，运营阶段最后大概介绍一下。
这里说的是我们通过数据怎么去驱动我们做一些质量方面的决策。
首先是一定要有统一的度量标准，这个度量标准不单单是我们画一条线，这条线要根据用户的感知来定。
第二，这个线要在线上跟线下完全统一起来，是一条平的，不能说线下没有发现问题，但是线上问题爆发了，这就是两边不平等，线上线下一定要完全统一。
另外一点是数据驱动，刚才讲过了，我们通过数据的方式可以告诉大家，背后的因子是哪些，你的质量问题、性能问题、崩溃问题跟哪些因子是有关系的。这样我知道这是一个地域性的问题，还是一个弱网场景下会出现的问题。我们第一感官就有一个非常清晰的判断，不至于一个Bug一个Bug的去看，人工去找这个相关性。
还有一个是我们通过自动化的方式，帮助大家去做决策：当前这个阶段，面对现在的质量问题，你应该做什么。
研发阶段 质量管理
介绍一下我们在研发阶段的产品，我们叫移动测试的专有云，其实就是把我们现在公有云的硬件和软件平台一体化的给客户服务，这样在内部就实现了一个小的测试云，我们可以通过它不断地做每天的自动化测试，可以不断地通过复制的方式把我们的脚本生成到这个平台上来。客户可以通过生成的脚本，每天做APP自动化回归，这样就能很清晰地知道前一天开发同学提交的代码有哪些Bug。
这是我们的专有云架构图，最下面就是我们的硬件层，也就是我们的无线机架、机房、手机等等设备，包括电量测试的解决方案也在里面，它也是通过硬件的方式解决。
上面就是我们的中间件，这个中间件里面就提供一些基础的服务，像一些OSS文件存储、MySql等等中间件服务。再上面就是我们开发的测试技术，像弱网怎么做测试，智能探索怎么测试，一会儿我会介绍一下智能探索的案例，这一层我们也会把我们的一些二次开发的接口或能力开放出来让大家接入。最上面是我们现在封装出来的主要测试能力，这个测试能力也同样可以让客户自己去横向的扩展，这样就可以很好地实现客户自己测试技术的积累。
然后讲讲这几个主要的功能。其实在研发阶段，很重要的一个事情就是做UI自动化回归，所以第一个我就讲功能自动化。我们现在已经支持3种框架：appium、robotium、robot framework。这里面我们支持了很多复杂的业务场景，比如说金融场景下有随机密码键盘，在做自动化的时候这个脚本很难写，要么你去点这个坐标，但是点坐标，这个位置是变化的，所以这种场景是比较困难的案例，那我们就通过图象识别的方式，可以把整个键盘解析到，每个按键在什么位置很好地分析，然后去做这个自动化测试。还有一些短信验证码，游戏相关的一些自动化，最后这个测试报告里面，我们会把我们的测试视频截图，性能情况等等都给大家分析出来。
这里主要讲一下我们的思路，为什么会把视频也放出来？因为我们之前发展，我们把这个Bug找出来之后，这个地方这个用例失败了，或者说这个地方应用崩溃了，用户在解决的时候，根据截图做判断发现很多关键信息会丢失，我们发现这种视频是一个很好的保留上下文的方式。现在在Android、iOS上都标配了这样的视频，只要它的机型有问题，这个用例失败了，我们就会把整个视频放出来，发生问题之后我们可以看一下整个的测试流程。你可以看到我们做自动化测试的每一个点击是什么样的情况，以此来解决这些问题。但是功能自动化有一个比较大的瓶颈，需要我们去写脚本，这是一个比较麻烦的事情，尤其是在移动端的APP都是迭代比较快的情况下，我写一套完整的脚本可能要花一个月，但是一个月以后，这个APP很多应用都已经变了，我再用原先的脚本去跑的时候基本上跑不了了，所以效率上存在很大的瓶颈。
我们解决这种问题是通过在线的录制方式帮助大家生成这个脚本，这个在线录制，我们只需要把我们的手机统一管理在这个平台上，其他的所有人都可以通过远程的方式去打开这个界面，操作这个手机，你每一步动作它都会给你记录下来，最后生成一个用例。通过在线录制可以生成脚本，然后通过手动或者是自动化的触发做测试。
第三个是用例管理，我们发现大家的业务复杂度上升之后，一个简单的用例管理的功能很难覆盖到我们的需求，比如说我们有不同的测试环境，或者我们有几套环境，有测试环境、线上环境，这些环境都对应了不同的参数或者不同的空间，我们如果用一套简单的模型覆盖这样的流程，实际上是比较困难的，在专有云里面我们提供了更加复杂的用例库的管理，每个用例之间有关联关系，可以组成更强大的用例集，最后可以看到每个执行的用例是不是有问题，它的问题是什么，每个用例都有一段小的视频，可以看到当时的场景是什么样的。
还有一个是智能探索测试，尽量降低大家录脚本的成本。录脚本的成本虽然比较低，但是还是要维护的，业务往前走了，页面是需要改的，录制的用例还是需要维护。我们想通过这种方式来解决这个问题。我们通过大盘可以看到线上的用户是怎么使用APP的，是怎么用APP的。这些数据都可以放到这个引擎里面，作为这个引擎的训练样本，它就会自动化的帮我们做APP的探索，这个探索就是用户怎么用，我就去怎么自动化的模仿，这样就可以很大程度地提高我们做这个测试的效果。
当然像一些特殊场景，比如说输入用户名、密码，现在我们也是标配了各种场景的支持，它能够自动地识别到我们有些登录的场景，有些可能看一些特征，比如说有两个框、一个按钮，有一些登录的文本，可以判断这是不是一个登录界面，是登录界面的概率有多高。其它一些场景也会支持。现在我们的智能探索引擎，用100台手机测试，可以发现30台手机是有问题的。
另外一个是二次开发能力。这个专有云不是说想把一台iphone给大家，你用它就可以了，我们更想给你一个树莓派，你可以自己DIY，可以自己搞很多事情。我们提供了大量的开放API的接口，提供了很多插件化的机制，让客户基于自己的业务逻辑，更面向自己业务需求的方式编写新的插件，这些插件就可以很好地被平台去调度，去执行我们想要的测试任务。客户可以增加很多自己想要的测试项，这样平台会随着我们的业务不断地丰富，增加很多独特的能力，这是与众不同的，是非常贴近业务的。
还有一个是深度性能测试。也是基于我们的观察和思考，如果说我们只是把性能数据采集出来，没办法判断这个问题的根因在哪里，解决起来就没有目的性。基于这个问题，我们就做了这个深度性能测试，我们把很多专项的测试项放进去，比如说做内存泄露的检测，做启动时间的分析，最后我也告诉你，你这个APP是不是有问题，是不是发生了内存泄露，内存泄露发生之后，我要告诉你整个泄露的原因是什么，这样一套完整的定向、定性、定量的数据就拿出来了，这样我们可以很好地推动这个东西的改进，因为你很清楚这个东西发生问题的原因是什么。现在的深度性能测试里面加了8到10项专项的测试，例如卡顿、严苛模式等等都会在里面，带会有精确的代码行告诉你哪里有问题。
这是刚才讲的智能探索引擎的测试效果，这是我们做智能探索的一个动作的丰富程度，它现在大概集成了8到10种操作类型，正常我们做APP测试可能就是点击、滑动占了99%，其它的只占一点点，实际上我们是把整个模型重新升级了一下，有单击、连击、长案、多点触控、按键、输入指令，都会放到里面。另外，你也会发现你用智能探索引擎做这个测试的时候，它会做一些这种边界场景探索，比如说输入框我写的是输入一个手机号，但是我会输入一段中文进去，去看它会不会崩溃，这些都是积累的场景。
另外一个数据就是我们的引擎覆盖控件程度，一个是5分钟，一个是跑了10分钟。我们写了大概有二三十个界面的APP，每个界面的复杂度还是蛮高的，有很多按钮，然后去看每个按钮的覆盖程度有多高。5分钟我们就做到了92%，我们现在的智能引擎基本上可以做到每秒钟做两次点击，当然它不是漫无目的的，实际上是要做一个分析，把当前的场景分析到，然后去做一个判断，我要去对哪个按钮做什么动作，然后做这样一套判断，用0.5秒钟。所以说你会看到我们机房里这些手机会飞快地做这个测试，实际上也不是瞎点。
这是动作数，5分钟做了540个，另外一个是10分钟做了1050个。
这是我们给客户部署的一个专有云的实施场景，这是客户帮我们拍的图片。这其实就是我们的机架，每个机架里面放10台手机，Android、iOS都可以，后面是我们的云管控平台，当然这个云是客户的专有云，基于这个专有云可以实现对所有这些手机的远程调试、在线录制、智能探索，手机在哪怕在异地接入，所有人仍然可以远程访问这些手机。
测试阶段 质量管理
研发阶段讲完了再讲一下测试阶段。我说的这个测试阶段更多的是发布之前做的一个全量回归的测试。现在大家知道移动端，尤其是Android端机型碎片化特别严重，我的APP对质量要求很高，我不想把它发上去之后，我的很多用户用不了，很多机型都不适配，就可以通过这种方式做一个测试。我们是把专有云里面讲的功能项打包在一起，由测试专家提供这样一个测试服务，包括他会帮你去回归测试用例。你只需要提需求，然后审核设计的这个测试用例是不是合适的。之后就由测试专家执行这个测试，测试完之后， 会帮你做一个完整的测试报告，报告里会表明复现路径，每个Bug的复现率有多高，影响面有多大，都会做一个评估。
专家测试服务的几个点，第一是测试效率，我们现在是48小时提供测试报告，基本上就是两天时间，从您这边提交测试物料之后，48小时会反馈这个报告。另外是我们覆盖600款Android机型，70款iOS机型，基本上市面上主流的机型都有。另外一个是我们的专家分析，我们发现Bug之后会帮助大家看看这个Bug是什么问题，甚至对一些复杂的问题，我们都可以提供定向、一对一的解决方案，当然我们不会帮大家写代码，但是会形成解决方案出来。
线上质量管理
然后再讲一下线上这部分。这部分我们叫APM或者是线上监控，这个图刚才大家已经看到了，为什么会选取这些点呢？大家可以看看，像启动时间、页面响应时间、流畅度、崩溃、卡顿、功耗，这些都是用户感知非常强烈的点，比如说不流畅，一个游戏如果不流畅，这个游戏肯定做不好，如果说打开一个APP要超过5秒钟，除了强需求的可以忍耐，其它的我都不会再打开，这些都是用户感知很强烈的点，这些点背后的问题都是需要我们解决的，这样才能帮助用户提升他的体验。
我们可以通过整个线上的监控和度量体系去找到线上是不是有这种启动时间比较慢的问题，是不是流畅度是有问题的，会把整个信息收集过来。
SDK都是all in one的，我们把它加进去，几行代码就搞定了，可以通过无痕的方式把信息采集上来。
我们看到这个启动时间或者是流畅度有问题，接下来我们要找到这个问题的原因。第一是我们通过这个质量体系知道这个是有问题的，它是不达标的。第二步我们给大家一个多维的分析，把背后的因子、因素、关联关系找出来。第三个是我们可以帮助大家把问题出现的页面上下文采集到，我们通过这些信息可以做线下的复现。到第三步很多问题都可以解决了，但是仍有一小部分疑难问题还是很难解决，可能用户当时用的场景，就是一些很偶然的因素，你再怎么复现都复现不了，我们可以通过移动日志或者日志分析，定向地去捞取相关的日志和信息，可以看到它的上下文是怎么出现这个问题的，这样就有很多数据帮我们做分析，而且是定向的。
分析了问题之后，首先做动态部署，然后是做热修复，还有一个是远程配置，这是我们的修复方案。
这是我们整个线上高可用体系的一个架构图，最下面这些是度量的组件，中间是我们的网络接口，通过这些接口可以把这些数据抛到最上面去，最上面就是一个大型的计算平台，这个计算平台帮大家把内在的关联因子、关联关系找到，把这些数据做一些合并、去重分析等等。最后实际上就是我们的告警，出现问题之后，大家可以去设置我的崩溃，比如说某个地方崩溃超过多少的时候就很严重了，不用天天盯着它，如果有问题会告诉你。
这是一个高可用的功能界面，这是整个性能的监控大盘。大家可以看看，这是当天的性能数据，这里有启动时间，这是跟某个版本的性能对比，这是一个趋势，这是聚合的日志。这些Bug因为很多、很乱、很杂，需要很多特征帮我们做分析，我们把一样的Bug放在一起，哪个Bug出现的概率高，影响问题多，我们就把它往前排，客户就优先把这个问题解决掉。
这边是所有的错误类型。如果说出现了问题，我想拉取某个用户的信息，就可以通过用户日志的方式捞取这样一个特定设备的信息。当时这个机型出现了问题，我们可以看到全量的上下文，解决起问题来会非常有针对性。
这是一个线下测试、线上监控的最佳实践流程大图，前面是研发阶段去做自动化的打包，然后去做自动化回归，去做问题的修复。我们在解决问题的时候，如果说问题的原因是我们不知道的，我们就发一条调试的指令到APP上，APP就会把这些数据、当时的上下文、内存信息等等通过这种方式拉取到这个平台上来。我们可以通过这些信息在线下，在我们的专有云里面做回放的验证，知道用户当时是怎么样的操作流程，看看线下能不能复现，如果能复现的话，基本这个问题八九不离十就可以很好地被解决掉了。这个问题我们找到之后，就可以通过热修复的方式，通过CDN发到APP上，APP在快速启动的时候，就可以把原先的问题代码替换掉，整个就是这样一个大的流程。线下跟线上的数据流转就完成了。
这是一个实际效果，从原先的发布周期30天一个版本，到现在基本上每天都会有一个版本的状态。我们现在的崩溃率是万分之二，问题在10秒钟之内就能发现，一个小时内就可以修复，把问题解决。
原文发布时间为：2018-05-4
本文作者：字白
