优品软件培育计划【第四期】③ —— 追求高投入产出比的测试左移与测试右移（测试右移）
2020/11/27
优品软件培育计划百场前沿技术系列讲座直播的第四场为大家请到的是字节跳动网络架构质量保障负责人赵悦，他同时还承担质量保障团队的测试平台搭建和测试方案设计等工作，在业务测试、测试平台设计、测试流程管理等方面拥有丰富经验。直播结束后，不少朋友都在点赞其深厚的专业积淀和给大家带来的精彩内容，也在期待视频的回放，现在就将整场讲座的内容整理如下，供大家继续学习使用。
我们都知道最近“测试左移”跟“测试右移”这两个概念被炒的比较火，今天我们也来探讨一下“追求高投入产出比的测试左移与测试右移”这个话题。首先我们先来思考三个问题：“凭借测试动作可以保障质量吗？”、“测试左移和测试右移指的是什么？”、“左移和右移过程中需要掌握什么概念、工具以及思想？”今天的讲座会从【软件工程生命周期】、【测试左移】、【测试右移】、【数据度量】这四个部分去展开。
测试右移很可能是需要把这个测试放到发布之后，可能会有一些风险，所以我们要考虑如何去规避它。另外一个是，测试右移了之后，他其实也有一个产出。这个产出跟上线之前的产出到底怎么去对齐？怎么去衡量？这也是一个问题。第一部分我们来看“灰度”，不是说所有产品都会用灰度，我这边只是讲一下，有灰度的产品的情况。可以看到下图中有一个原始的版本，灰度的版本相当于就是要去覆盖原始的版本。灰度的程度会随着灰度的过程慢慢变大，我们在这个过程中会慢慢去观察灰度的效果。观察灰度的过程中有没有出现问题，如果出现了问题我们可能会回滚，如果没有问题就继续灰度，直到整个新的版本能够上线。从灰度的角度来说，主要有服务端灰度和客户端灰度这两种。有的产品它并不存在客户端，所以它也就没有客户端灰度。服务端灰度大概指的是，我有这么多服务端的机器，我按照机器或者按照机房去一个一个上线新的版本。也可以通过域名来做灰度，域名本身是用来控制流量的，比如说我现在有10个域名，我可以先灰度其中的两个域名、再慢慢加大。从客户端方向来说，客户端本身是通过配置下发来做灰度的，比如说移动端的手机，拿到了灰度的配置之后，有可能是使用新的灰度的一个版本，也有可能是把流量打到一个新的域名上面去，这几方面都有。它一方面可以按照比例下发，比如说随机用户的，也可以指定下发，某一个机型、某个省份，或者某种用户分类。按照机型和用户的分类是有一定的特殊含义的，比如说，我怀疑我现在的这个功能有可能在低端机上不行，那么就可以选择先在低端机上进行一些灰度。再就是我这个功能有可能会影响付费，那么我就可以先在非付费用户身上去做下发。这些都是一些灰度的策略。接下来我们一起来看一下监控，监控也会有两个方向，一个方向是服务端监控，一个方向是客户端监控的上报。服务端的监控一般会有两种方向，一种是机器和进程本身的一种情况，它可能会涉及到硬件指标，线程数等，再就是从流量和请求方面去做监控，一般会有QPS、带宽、响应时间、成功率等客户端的监控就比较多，因为客户端本身的信息是比较多的。请求和流量维度上报，成功率和响应时间（卡顿率），这相当于是网络层的一个监控。从业务层来看，可以有一些业务层的监控，比如说订单失败、业务请求异常等。第三部分是人工监控，我们的app里一般都会有用户反馈这样的一个模块，这个模块也可以视作灰度时的一个反馈。客户端在做监控的时候，实际上是可以将这些监控信息以数据的形式上报到数据中心，经过聚合和运算后，可以形成一个曲线或者监控图，如果对这个监控设置一个阈值，就会形成报警。举个例子，我现在预期全网的卡顿率是0.1，我认为全网的卡顿率升到0.12的时候就是不可接受的，就可以把这个0.12设置成一个阈值，一旦到达0.12就会触发一个监控。不同的时间段可以设置不同的阈值，比如说，在晚高峰和午高峰的时候，这个卡顿率是会上升的，监控的阈值就不可能是一个固定的值，它可能是一条曲线。所谓的归因分析指的是，如果线上出现了一个问题，我如何去分析这个问题是由什么因素导致的。为什么要提到归因分析呢？因为我们前面提到了灰度，灰度实际上是一个配置下发。在相对比较大的公司里面，在一个产品线可能会同时经历多个下发。在这样的情况下，如何去分析当前监控到的问题到底是被谁影响的？到底是由谁导致的，这个时候我们就要引入一个概念，叫做流量染色。通过染色可以去分析失败的原因，就相当于我把流量染色之后，每个流量上面带了哪些灰度的配置我是知道的。
现在有个产品正在进行http到https的改造，全网开了5%的https的灰度量级，发现视频的播放失败率有了一定的提升，所以我们就开始排查这些失败的染色特征，就可以发现是这样的
通过排查可以发现，我们有一个版本，这个版本之下是不支持https的，当时就没有设计这个功能。再就是Android4.3.3以下没有办法升级到这个版本以上。那解决的办法就是，需要把这个配置回滚，重新下发https开关的时候做一个配置下发的覆盖，不对这个版本以下的版本开启https。
通过这个案例我们就可以看到灰度配合监控配合流量染色进行分析的这样一个过程。测试右移它本身的概念是比较广泛的，举一个比较简单的例子，我们现在比较常见的手游，他一般都会开启几轮的内测，开内测之后甚至可能都不需要任何的测试就直接发布正式的版本了。为什么会选择这样的策略呢？这个策略也就是我们说的众测，就是把用户当做免费的小白鼠来做你的测试员，当然可能会给这些用户一些好处。因为一个手游的运营周期可能在两年左右，两年到三年左右它可能就不再运营了，也就是说如果用两到三年的时间招一个测试，搭建一个测试体系，还要维护这个测试用例，成本是非常高的，这个时候倒不如把测试这件事去投放给市场，投放给众测，而游戏的众测又是成本比较低的一个方案。所以我们可以看到，针对不同的项目，测试右移的方案它是完全不同的。第一件事情是心细。心细指的是我们要保稳。所有灰度下发的配置都可以快速的撤回，所有的东西都需要上监控，并且上了监控一定要上报警。配置下发、监控和报警这三件事情其实是一个链条，必须每一个都做到。
必要的时候，比如说灰度下发的风险特别大，就需要设计兜底（fall back策略），比如说你的网络调度模块出问题了，一定拿不到一个域名的时候，就写死一个兜底的域名给它，那就保障了最起码有一个东西还可以访问。在这样一套完善的机制保障了以后，就可以胆子大了，所有的东西都可以进行灰度发布，进行实验。误区1：既然可以测试右移来试错，那么就内场别测了，赶紧发版本。内场测试在一开始的收益是很高的，我们都知道bug这种东西是一开始发现很多，后来会越来越少，所以说是有一个边界收益的，有一个均衡点。到了均衡点之后，就可以选择性地停止测试进行右移了。还有一点，To B的产品它其实是不能够试错的，也不能灰度，一旦出了一个问题，就直接丢单了，这种产品是不能进行试错的。你的右移可以选择在交付之前先测，但是不能在用户身上试错。这样说也对，但是这只是其中的一半，另外一半其实是用户反馈。因为监控有时候并不能监控到一些用户体验的一些东西，用户本身的反馈毕竟是人的一个体验，它对监控是一种补充。还有一种情况是运营和产品可能会发布一个活动，或者发布一个策略变更之类的，这些一般都不会被技术性的监控所拦截，一般都靠用户的体验反馈。用户反馈也是测试右移中对质量监控一个重要的手段。
