1.线上灰度
记得之前在jd上线，都会等到很久，如果是app发版，有很大几率会通宵。上线时间长的原因有很多，比如上线的需求多，需要排队; 上线过程中出现问题，卡住需要运维协助查看；上线后验证发现有问题，需要回滚再重新上线；上线后需要验证的用户身份或者功能过多，难免有遗漏等。
针对于这种情况，我们怎么提效呢？目前我司的落地方案为:
1.1 上线项目由测试同事发布
目的: 从测试用例评审后，测试一直掌握着需求的主动权。和其他公司不同的点，我司测试地位较高，从上线项目排序、上线时间、回滚等都是由测试主控的。初期上线会觉得很混乱，尤其是不同需求如果共用一个项目，到底谁发，上线顺序等，都需要协调和沟通。
1.2 督促devlops部门开发出灰度上线放量
目的: 以服务器为维度，控制可以访问灰度区的用户数量。以前上线都是将所有项目组成班车，然后每个项目都是全量上线。根据上线前的项目上线顺序沟通，全量上线不仅时间长，如果项目间有依赖关系，还需要先将依赖方回滚，然后再回滚被依赖方。这将是一个非常漫长的过程。
如果我们采用先将所有服务器上线，但是发布是根据1%、5%、10%这种阶梯式的方式，将1天全量上线改为当天5%上线，第二天10%、20%,如果没有报错，功能正常，第三天50%，最后再100%放量。这样不仅研发和测试减少了熬夜的风险，也减少了线上用户反馈。当有报错或者用户反馈时，可以及时快速地回滚项目。研发修复后再次快速上线，继续放量观察。完全符合敏捷开发，快速迭代，保质保量。
有个点需要明确下，如果是活动类的需求，一般都是全量发布，不能造成一部分用户可以参加活动，一部分看不到活动的情况。这种情况下上线就需要放全量，大家就需要多小心了。
自从我司施行灰度放量上线政策后，基本看不到通宵上线的情况了。
2.创建测试数据，也就是造数
2.1 使用mock来造数
2.2 平台化，如我司用户身份一般为猎头/HR/求职者，创建测试数据时需要在不同的链接进行注册。如果将三者统一，在一个链接下造数，调用不同的接口，就会大大提高效率。
可以设计为以下的造数平台:
手机号、用户身份、地区、企业、位置等，将三者对应的id也统一展示
这里可以用手机号为基准id, 用户身份关联手机号，这样就可以将所有信息联系起来。
2.3 实名认证/人脸识别/审核认证等
注册账户时，很多app都需要收集个人信息。如实名认证，在测试环境可以使用身份证生成器来找合适的身份证号，但是预生产or线上环境，再使用身份证生成器就不合适了。使用一次，就可能占用一个潜在用户的坑位。这种情况就可以找认证的同事，创建一个白名单系统，加入测试同事的身份证号后，就可以无限次进行实名认证。
对于人脸识别，除了创建白名单系统，还可以mock特殊的数据来通过人脸识别认证。审核认证也是同理，例如发布敏感职位，上架商品，可以直接mock接口通过。
3.整个业务流程线上化
1.测试计划创建和需求关联
2.需求中各个节点留痕，如预估工时、排期等
3.提测时前后端项目对应分支在流程中标出，消息提醒
4.测试中提交的bug和需求关联，可实时查看项目进展、error数等
5.上线项目排序、如果回滚，项目回滚顺序等
6.业务需求和技术需求都需要创建需求链接
今天先到这里，周五了，祝大家周末快乐~
