阿里巴巴新零售事业部李海静谈《实时质量》
李海静：大家上午好，我是李海静，来自阿里巴巴新零售事业部下面的B2B，我分享的题目是《实时质量》，下面来看下详细内容：这次分享包括五部分，分别为背景、概述、实践、规划，还有互动共5个环节。
我们先看背景部分，在进行详细内容讲解之前我们先简单回顾一下传统的软件测试工作经历的几个阶段，互联网兴起前软件测试是作为项目研发中一个非常重要的流程存在的，因为当时软件的交付存在着非常大成本，现在很多人可能会对以前的光盘或者软盘有比较深的印象，那个时候如果软件出现质量问题的话成本会非常高，所以整个项目流程测试周期会比较长，这个阶段我们把它定义为测试1.0阶段。
李海静
互联网兴起以后，软件交付方式发生非常大变化，一次发布就可以将一个产品发布上线，这时候如何快速驱动产品发布上线是这个阶段测试面临的非常大的问题，所以这时候测试内部孵化出一些非常专业性的测试产品，比如说自动化，比如说环境、数据等等，这时候我们最大目的是通过技术手段驱动一些产品交付效率的提升，这个阶段我们把它定义为测试2.0阶段。随着移动互联网兴起，产品交付和迭代速度更加快速，产品触达用户的时间更短，而且随着大数据技术的普及，我们测试的范畴不仅仅局限于项目的测试过程当中，而是要对产品进行全生命周期的质量保证。这时候我们面临着工作内容的转变，如何将原来的产品交付前的测试转变到整个产品周期的质量保障是我们面临的场景，如何基于线上运行态数据实时分析和发现可能存在的质量问题是我们遇到的问题，实时质量是我们在这个背景下提出来测试方向。我们对实时质量的定义有两个核心，我们希望达到运行含测试、测试即服务的效果，我们希望质量保障作为运行过程中必须因素存在，测试活动与Runtime向融合，实时、高效暴露运行质量问题。运行含测试，测试即服务难度非常大。从正向层面看应该怎么做呢？运行含测试，我们希望对线上运行的每一个流量都有测试活动在里面，比如说用例执行，这是正向层面的解决方式，一会会详细讲到。另外从逆向层面应该怎么做？逆向层面来看我们可以对运行时的作用产物比如所有数据进行详细分析和挖掘，明确出里面可能产生的质量问题，这是两个方向，一会我会详细的讲。下面看一下我们具体怎么落地的。
这是一个产品思路图，这个是从数据分析的角度来看怎么落地实时质量，这里包括数据分析、搜集、精确定位，恢复策略、恢复验证等5个部分。我们针对线上运行流量、运行机器情况、容器的健康情况、应用本身日志等实时搜集，通过对数据进行分析、挖掘出来里面可能存在的异常，针对存在的异常基于我们已有问题恢复的手段推荐出恢复策略输出到第三方平台促进问题恢复，同时基于自动化验证手段和前面阶段数据收集分析能力，验证问题收敛情况，这是一个总体核心思路，在整个过程中除了自己做的事情之外还会综合我们整个电商网站所有配置变更、应用发布变更等等所有变更信息和用户反馈信息，还有第三方监控平台信息作为输入，用以提升我们对异常判断的准确率。
下面来看一下我们具体怎么落地的，具体有三个案例讲一下我们数据分析怎么做的。用户访问电商网站的流量首先到达我们的统一接入层，经过调度分发到达具体的机房应用，完成逻辑流转和结果响应，这是一个总体过程。如果用户出现问题，流量层是第一时间可以感知到的；如果应用逻辑出现异常，我们在应用这一层也可以实时感知到；同时如果流量分发控制这一层出现影响非常大的异常在流量层也可以及时感知的。
我们先来看下流量层具体应该怎么做的，我们在这一层对线上留存日志进行全面实时采集和分析，我们主要关注几个信息，含用户访问资源时的状态码信息和响应时间信息，基于这两个信息我们对用户访问目标、状态、资源进行聚类，挖掘出来影响用户的因素，比如说现在页面响应时间严重超长，页面打开异常等，我们第一时间可以发现问题，然后把问题推送给开发同学并且提供问题上下文信息，另外我们对线上正常流量进行采样，因为会有一些非法调用引起误判，所以我们基于正常访问数据结合算法来提升我们判断的准确性。
这是一个真实情况，我们的线上资源访问出现访问异常，系统将最近5分钟内出现异常详情以消息的形式推送出来，点击查看详情后可以看到详细信息，比如访问来源、后端服务器IP地址、异常详情等，基于这些信息开发同学可以在浏览器中访问当前资源确认到底存在什么情况，或者可以去服务器看可能产生该问题的详细日志，这个是流量层的实践。流量进一步向下流转到达应用之后，我们重点关注结果层面的信息，但是应用是和我们的部署容器或者虚拟机容器是强相关联的，同时由于电商网站复杂性这里也会涉及到很多中间件的信息，在这一层会综合多个因素进行判断，重点从接口、容器、虚拟机等方面来判断，当每个因素出现比较大异常时我们会综合分析判断当前的影响面是什么，当前影响的链路是什么。我先分个讲一下，后面有一个例子更加具像一点。在接口层，主要对接口异常及性能情况进行分析，如果接口性能和异常指标出现在正常指标范围之外我们会进行自动化校验，自动化校验是选择策略。如果问题严重程度超出阈值范围会直接进行报警，另外在jvm而层面上我们对线程、内存等信息进行判断，比如说热点内存、热点代码等情况，同时把堆内存信息dump出来进行分析。机器情况主要是CPU、Load、Memory等，如果这几个因素出现异常都会触发我们的异常诊断。
大家看这个例子，这个接口是查询后台配置的接口，当该接口的响应时间超长或者出现明显异常时会触发我们实时诊断！诊断会开启接口的全链路采样和输入输出全链路采样、慢链路诊断等，基于诊断结果，如果出现严重异常，会以消息的形式明确在某个时间段出现多少严重异常，代码在多少行，开发人员针对这个消息可以进一步排查，比如说点击详情可以看到具体异常内容，输入输出详细值，如果基于这个信息无法判断排查，可以点击链路信息查询更进一步调用链路的详细信息。这张图是本次异常流量的详细调用链路，基于这个调用链路开发同学可以非常快速的找到的异常上下文场景信息。
以上是我们在PC端的实践案例，无线app端如何快速感知线上异常也是我们当前的主要场景，比如说由于使用环境网络抖动导致APP稳定性受到影响，如果没有明确的问题场景及上下文信息在处理问题时会比较困难，所以我们将APP本身的稳定性信息、业务状态信息、用户反馈信息、用户总体流量信息进行实时分析，当某一个部分或者某几个部分出现异常时，我们会实时挖掘出来当前问题的用户群体信息和区域性信息，尽可能最大化的提供问题的上下文、用户访问路径等，同时输出针对该问题可能的恢复策略，提供给人或者其他的系统进行快速恢复。
下面来看一个例子，这是手机阿里APP中的挑货页面，该页面出现了比较大的流量下跌，用户反馈信息有个例，我们可以看到详细情况流量和异常情况是这样的，用户反馈信息是这样的，还有自动化的验证结果信息是这样的，如果说开发同学在这个场景下无法进行问题准确判断，可以扫描二维码准确场景还原。
我们为什么提供异常用户群体画像在这里？主要是因为APP千人千面的场景越来越多，如果没有用户特征，很难进行准确场景的重现，所以必须对异常用户信息进行特征分析，为问题的快速定位提供有效数据支持！下面的图示是异常问题出现的路径详情，基于有效的目标用户群体和访问路径，可以快速对问题场景进行重现和定位。这个图示是详细的流量入口来源分析，可以快速判断问题的响应面。
说完典型案例实践，我们看一下实时质量的具体效果怎么样，去年7月份我们平台发布，在流量治理方面7月份一共在整个CBU发现216万多流量异常，经过一个月的治理以后流量异常降低到1万左右。另外我们应用层总共发现异常问题40例(这个数据为上个月的数据，当前总共发现100多例应用层异常)。发现的异常问题中，一些典型案例如下，比如说我们下单页面图文详情异常，APP图片异常，这些问题如果没有发现都会对用户造成比较大的影响。
下面是比较典型场景的示例，这是流量异常情况提醒信息，这是单机情况提醒信息，这个RT超出严重允许的范围内，这个是详细的调用链路和异常点的信息。
后面来看一下重点规划，刚才都是从数据层面逆向分析我们如何做实时质量，其实实时质量最重要的是从正面突破，正面怎么做呢？实时质量应该和运行态相融合，实时快速高效发现运行时候的问题，所以我们希望将来实时质量可以将测试用例作用于每一个输入和每一个输出上，快速的对这个流量调用做出质量结果响应，但是这里就存在着比较大难点。第一个数据量比较大，因为我们针对线上情况，所以整个调用流量比较大，第二调用频繁，第三实时质量要求快速做出响应，所以难点比较多。经过分析我们将正向过程划分几个阶段，第一个阶段为实时数据能力建设，要做实时质量必须具备对线上每一个流量的数据进行实时采集的能力。而且这个实时采集要求是低损或者无损的。那现在建设到什么程度了呢？我们目前可以针对线上APP每一个流量接口进行低损采样，对持久层数据进行完全无损的获取，这是一个非常重要的能力，基于这个能力我们可以做什么事情呢？我们可以做线上数据的对账，线上数据测试，线上数据的分析，而且是零延时无损的能力。
第二个阶段是基于现在的实时数据能力，怎么样落地实时质量，我们要找到合适测试方法、合适的执行机制，然后这种机制下把能力利用起来，孵化出我们实时质量能力，这是我们后续计划和规划。
这个事例是我们正在做的一个产品，我们希望可以将线下功能测试过程当中所做的功能测试中的校验自动生成等价于接口测试的语义校验逻辑模板，基于该逻辑模板，当接口上线后可以自动针对线上流量进行自动化测试达到完全运行含测试的效果。具体怎么做的？当用户在浏览器操作的时候，实时通过数据统计方式分析出当前用户IP地址的调用链路、调用链路每一个接口调用信息，这些信息包括调用输入、输出、持久层数据情况等。基于接口的输入输出，除了UI的校验，我们把数据输出校验形式转换成语义的配置，然后把持久化存储在我们平台里，如果语义配置较复杂，可以提供UDF的自定义输入，我们可以把用户整个功能测试过程中校验点转化成接口和一些校验点的映射关系，基于映射关系当整个业务上线后，如果接口被触发，接口的对应断言关系会自动执行，达到功能测试过程中自动生成接口测试、多个环境无缝运行的效果。这里有几个难点，第一流量获取，接口层面怎么样无损或者低损获得这些输入输出的数据(测试环境比较简单)，线上是基于采样的形式(给大家推荐我们集团开源的、实例比较好的产品（jvm-sandbox），可以实时获取流量输入输出)，这是第一个层面；第二个层面怎么实时获取线上持久层数据，线上数据都是隔离的，另外为了避免我们的测试过程对线上用户产生影响，我们通过读取备库数据的方式来达到无损的获取线上数据的目的，这个对我们实时质量能力提升有很大帮助。而且这个能力可以对数据一致性要求比较高的对账业务或者其他的数据测试业务有非常大的促进作用和效果，这是第二点。第三点是逻辑语义的转化，这主要难在什么地方？因为我们通用接口不涉及过多逻辑复杂，单纯从输出、输入就可以做数据校验，但是有复杂的接口涉及到逻辑判断，单纯从数据上不能直接转换成逻辑语言，就需要UDF支持，通过UDF自定义逻辑把数据转换成逻辑配置，逻辑配置转换成映射关系达到测试效果，这是三个难点，前面两个问题我们都解决了，第三个问题正在实践过程当中，预计下个月会有效果。
因为时间关系我讲的比较快，大家如果有问题可以提问一下。
提问：你提到一个开源软件是什么？
李海静：jvm-sandbox，可以通过搜索引擎找一下。
提问：关于最后包括线上数据采集，通过采样分析数据，您是怎么评估质量的？能详细说一下吗？比如说你产品质量最后通过什么样数据，或者什么流程评定达到什么样的标准？
李海静：实时质量是我们去年新提出的测试方向，具体怎么衡量质量，怎么样才能达到测试标准和交付标准不在我们解决问题范围之内，但是从稳定性层面来讲，功能测试过程中的逻辑校验沉淀在线上如果可以第一时间发现遗漏的问题的话，实时质量的价值还是非常大的。另外，针对已沉淀的逻辑模板可自动进行测试校验，如果出现分支遗漏，系统可以自动进行提升。
本文来自：2018中国首届云测试峰会，举办方：Testin 云测
Testin，让应用更有价值：www.testin.cn
关注公众号“Testin”，了解更多测试行业动态和测试知识。
