线下测试很难覆盖线上的所有场景，即便是测试设计得非常完善，但仍旧会有差别，简单来说，线下测试与线上至少存在四个方面的不同：
- 配置不同。线下环境与线上环境的应用版本保持一致不难，但配置方面往往存在差异，如服务规格、调试开关等。
- 数据不同。线上的数据更真实、更丰富，场景也更多样。比如做网络开发，即使在线下模拟了各种各样的场景，但在线上可能还会出现问题。
- 依赖不同。依赖的外部服务，比如某些金融软件会依赖人行的接口，这种情况线下环境无法满足，必须使用模拟接口。
- 负载不同。线上负载更高，且波动性的特征也更真实。如某个时间点产生突增流量，流量峰谷值不同。在线下环境，考虑到资源成本，一般负载较低，高负载的压测会单独考虑。而压测时，场景的覆盖度也会比正常测试有所降低。
我们需要通过灰度发布或线上测试弥补线下测试的不足，其本质是为了降低开发者的心智负担。但是否真的需要灰度测试仍需要从业务场景等方面进行多番考虑：
- 我们是否允许做线上灰度验证，比如对于某些有明确监管要求的行业，无法使用线上灰度验证。
- 因为线上线下的不一致无法消除，且成本较高，若在考虑成本的基础上，认为不进行灰度验证带来的风险可以接受，则可以不做灰度验证；
- 是否有自主运维的能力做线上灰度验证
- 我们能够做线上灰度验证，还需要具备相应的工程和技术的能力，以及相应工具的准备等
灰度策略：
- 简单分批，根据负载均衡动态分配
版本一致，对业务没有影响
有监控措施，可以观察容器、业务状态
服务比例、持续时间
- 外部流量灰度
根据流量按比例分布 或者按照某一特征分配(header cookie等)
1、运营商、IP属地等特征
2、hash分组
3、header cookie等特征
4、提前做好灰度标识
ingress 做外部流量灰度，设置好灰度标识后，灰度验证的流程如下
客户端 ingress网关 配置服务 灰度策略
业务请求之前，先获取灰度配置，然后所有请求都携带灰度配置
版本一致，对业务没有影响
有监控措施，可以观察容器、业务状态
服务比例、持续时间
先流量切换，再清理工作负载，观察一段时间
内部服务之间调度没有根据特征做调度
- 外部流量 + 内部流量灰度
istio实现内部rpc调度
要保证版本的兼容性(包括中间件、缓存、数据库等)
应用版本更新和流量的调整要串行处理，先调整版本依赖关系，再进行灰度测试
对于灰度场景，我们的建议是，首先，按优先级逐步建设；其次，先解决数据库之外的中间件问题；第三，尽量寻求专业的技术团队获取实施方案，如 MSE 团队。
灰度测试:将自己的产品首先拿出来给一部分目标人群使用，通过她们的使用结果和反馈来修改产品的一些不足，做到查漏补缺，完善产品的功能，使产品的质量得到提高。这样产品尽早的与用户接触能为以后产品的正式发布打下基础
黑盒测试:不知道内部实现，功能性测试，测试输入输出正确
白盒测试:程序逻辑、结构测试，穷举所有可能
