This article is based on the 2018 Yunqi Conference Shenzhen Summit · EMAS Special Session - Evolution of Mobile Internet, Alibaba technical expert Zibai's speech on "Pan-Quality Management Solutions". Professional and three-dimensional quality management system was shared.
The topic of today's speech is "Pan-Quality Management Solutions". Why is it called Pan-Quality? This is also based on previous thinking, including the growth route of mobile Taobao within our group, and gradually has a different understanding. Before we did tests, we just found bugs and solved them. Now it seems that this is not enough. For example, we can do some things in the research and development stage, and we can monitor and do some things online, so that we can better Doing the quality assurance of the whole process is not just about finding bugs. We have to do a lot of things before, during and after to ensure that the APP is in a good state for users. This is the origin of this pan.
The Current Situation and Problems of Mobile Testing
Today, I will tell you in several stages, my understanding of the whole pan-quality management solution, and then see if you have some resonance.
Let’s talk about the current situation and problems of mobile testing first. We are doing mobile testing now, because the mobile testing itself has more machines and is more fragmented. In addition, the business logic of the APP is not as simple as that on the PC side. Maybe we wrote a lot of scripts and spent a lot of effort, but found that When the next version comes, most of them are useless, either rewrite or manually click, which is actually a very painful process.
There are four main problems. The first is that we do mobile testing and regression testing before release. Normally, we do development in three weeks, do testing in one week, modify bugs after testing, and then release, basically this is the process. We only paid attention to this point before the launch. In fact, in the research and development stage, this point is blank, or we need to manually touch it. This is still not enough. I will talk about how our solutions can help you improve efficiency and solve problems in a while. .
The second point is that the whole process is relatively passive. Now we have some bugs raised. The developers may think that this problem is of little value and will not fix it, but the customer called our customer service and said that the problem is very serious and I can't use it anymore, especially when the customer is a VIP, we will Seriously, trying very hard to get this out of the way. This reflects a problem. After our APP is launched, when users have some serious complaints, they can push us back to make a lot of improvements. Then should we have a better monitoring system? When users find a problem, we can immediately know how many people have the problem, how serious the problem is, and should I solve it immediately? backed by a set of metrics
We need to do online monitoring and offline testing. It is very important to be able to find program problems. There is a point here, that is, the problem needs to be defined. We know that crashing is a problem, which everyone understands, but performance is a problem, which is not easy to understand. For example, my startup time is one second, and his startup time is three seconds. Which is the problem? It is uncertain, it depends on our business, when the real user feels a problem, that is a problem, so at this time we need to have a set of standards, this APP will be unqualified when it reaches 2.5 seconds, because the user Can't take it anymore. This is another point, there is no data support to help you perceive online problems.
The last point is that we do a lot of testing activities. There is a very bad point. When we do the testing, we hire some outsourced students to do the testing items, but the business experience is to follow people, which is very bad. If someone is gone, we need to find another person, and let him get familiar with the business for a while. This is a very bad thing, but is there a way that a person who does a good job can continuously It is also a problem that the latest test methods and test technologies are deposited on this platform, and the people behind can make good use of the experience accumulated by the previous people and do good quality assurance.
Pan Quality Management Solutions
The second part talks about pan-quality management solutions. The core is a sentence, intelligent DevOps driven by data.
What's the meaning? With data as the driving force, there are several points involved. Our entire user data online is not well utilized. For example, when we really solve online problems, you can think about it. One person said There is a problem with this, please help me find out what the problem is, and quickly solve it for me.
一般情况下研发团队就是打个电话或者通过其它的渠道联系上他，问他是什么样的手机，是什么样的环境，是怎么操作的。然后按照用户的反馈，再一点点去摸索，找这个问题在哪儿，这个过程很痛苦，整个问题的发现到分析到解决，大部分时间都集中在分析这个阶段，最后解决那一下可能一行代码或者几行代码就搞定了。这里面就暴露一个问题，我们对于用户的整个行为，对当时的现场，其实数据是不全的，这就导致我们解决问题就很困难。
实际上我们就提供这样一套数据的采集方式，让大家能够在问题发生的时候不单单是把你的崩溃栈拿出来，还要把你的内存信息拿出来，甚至把全量的日志拿出来。怎么拿呢？定向的捞取当时哪些同学、哪些人、哪些手机上出现了这个问题，非常有针对性的定向获取这些更详细的信息。只要这个问题出现了，我一定帮你把全量的信息找回来，这样我们解决问题就不用去猜了。这是一个线上的场景。
再举一个线下的场景。我们去做线下测试的时候，我是做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的，我们把它加进去，几行代码就搞定了，可以通过无痕的方式把信息采集上来。
我们看到这个启动时间或者是流畅度有问题，接下来我们要找到这个问题的原因。第一是我们通过这个质量体系知道这个是有问题的，它是不达标的。第二步我们给大家一个多维的分析，把背后的因子、因素、关联关系找出来。第三个是我们可以帮助大家把问题出现的页面上下文采集到，我们通过这些信息可以做线下的复现。到第三步很多问题都可以解决了，但是仍有一小部分疑难问题还是很难解决，可能用户当时用的场景，就是一些很偶然的因素，你再怎么复现都复现不了，我们可以通过移动日志或者日志分析，定向地去捞取相关的日志和信息，可以看到它的上下文是怎么出现这个问题的，这样就有很多数据帮我们做分析，而且是定向的。
分析了问题之后，首先做动态部署，然后是做热修复，还有一个是远程配置，这是我们的修复方案。
这是我们整个线上高可用体系的一个架构图，最下面这些是度量的组件，中间是我们的网络接口，通过这些接口可以把这些数据抛到最上面去，最上面就是一个大型的计算平台，这个计算平台帮大家把内在的关联因子、关联关系找到，把这些数据做一些合并、去重分析等等。最后实际上就是我们的告警，出现问题之后，大家可以去设置我的崩溃，比如说某个地方崩溃超过多少的时候就很严重了，不用天天盯着它，如果有问题会告诉你。
This is a highly available functional interface, which is the monitoring panel for the entire performance. You can see, this is the performance data of the day, here is the startup time, this is the performance comparison with a certain version, this is a trend, this is the aggregated log. Because these bugs are many, messy, and complicated, they need many features to help us analyze them. We put the same bugs together. If a bug has a high probability of occurrence and has many problems, we will put it in the front row, and customers will be given priority. Get this out of the way.
Here are all the error types. If there is a problem and I want to pull the information of a certain user, I can obtain the information of such a specific device through the user log. At that time, there was a problem with this model, we can see the full context, and it will be very targeted to solve the problem.
This is a big picture of the best practice process for offline testing and online monitoring. The front is the R&D stage to do automated packaging, and then do automated regression to fix problems. When we solve the problem, if we don't know the cause of the problem, we will send a debugging command to the APP, and the APP will pull the data, the context at that time, memory information, etc. in this way. to this platform. We can use this information to verify the playback offline and in our proprietary cloud, know what the user's operation process was at that time, and see if it can be reproduced offline. If it can be reproduced, the problem is basically It can be solved very well without leaving ten. After we find this problem, we can send it to the APP through the CDN by hot-fixing. When the APP starts up quickly, the original problem code can be replaced. The whole process is such a big process. The data flow between offline and online is completed.
This is a practical effect. From the original release cycle of one version every 30 days, there will basically be a version status every day. Our current crash rate is 2 in 10,000, and the problem can be found in 10 seconds, and it can be fixed and solved in an hour.
The original release time is: 2018-05-4
The author of this article: word white
This article is from the Yunqi community partner " Taobao Technology ". For relevant information, you can follow " Taobao Technology ".