项目上线之后的代码运行才是直接检测测试人员劳动的成果，上线之后没有报错、没有异常、没有重大bug出现，代码无需进行回滚，这时吊起来的心终于落了一半，这也代表上线已经成功了一半。但作为一个谨慎的软件测试人员，在测试项目功能未正式使用之前，我们都需要报有一种心态：代码随时都有报错的可能。那我们需要通过做一些事情来检查一下。
根据项目的大小都有后续操作，一般小项目上线之后就是观察一下数据，中型项目和大改动的项目代码上线之后会做一个重要的操作：灰度。
这就是为什么我们所说的代码上线之后不代表测试的工作就结束了，反而更像是一个开始，这个时候测试人员需要开始跟踪线上数据和灰度方案执行情况。
灰度策略及流程：
代码上线后——》检查数据，无误——》切很少的量——》检查数据，若无误——》切更大的量——》检查数据，若无误——》切全量
1、让代码跑一会儿策略，对于比较重大功能的项目或影响面很广的功能上线之后，会先让代码在线上跑一天，通过跟踪数据确认本次的代码对业务流程无影响再引入本次项目的新功能和新业务。
2、若代码没有影响，这时打开开关，配置很小的灰度量，让业务数量或用户数只跑那么几个或几十个左右，再次检查数据确认无误，才会放心开更多的量。
第二步灰度有二种方案：一种是开关打开+配置数量；另一种是开关关闭状态+白名单，根据项目和开发人员的设计来选择哪一种方案更好。
举一个简单的例子：
对于微信发红包的功能，大家应该都很清楚，这里我就来针对发红包来设计一个灰度方案：
首先是 将发红包功能的开关打开，发红包功能代码上线，用户无法查看到这一功能，观察线上用户其他功能使用情况，这里就是判断发红包功能对程序原本功能是否有影响。
然后是 发红包功能的灰度方案，通过白名单来灰度，将某个ID配置到白名单，该用户可以使用发红包功能，给自己的亲友发送红包，检查数据，确认无误。
再然后是 控制使用发红包功能的群体数量，针对某一种分类先对一个小群体来使用该功能，观察数据。
最后是 全量切，所有用户都可能使用该功能。
王豆豆并不知道实际的发红包灰度方案是如何的，上面只是举一个例子说明一下灰度方案可以如何来设计。
从上面可以看出来，上线前和上线后不管是流程还是处理方案来说，都需要做到尽善尽美，完无一失，这主要是因为公司业务所致，对于金融公司的业务来说，一旦出错都会直接带来金钱上的损失，所以我们在测试和上线方案都需要做有的放矢，在bug出现之前，就要想好解决方案。
文章源自公众号 王豆豆的测试观