为什么开发慢？
据我不完全的观察，开发的过程是这样的
如果是测试环境，那为什么慢呢？
- 测试环境又不好使了，谁又改了什么
- 没有真实的流量，线下的小白鼠没有代表性
如果是生产环境，那为什么慢呢？
- 部署不能太快了，得慢慢来，免得挂了
- 开流量得小心又小心，免得挂了
所以要让开发速度变得更快，就是要更快地做想要的改动，然后更快地得到好使还是不好使的反馈。
以下为科学幻想
实现原理
愿景已经很清楚了。那么怎么实现呢？
大部分业务系统都是支持多用户的。用户与用户之间的数据是隔离的。我们可以通过在线上增加测试用户的方式，在生产环境直接跑测试。
然后我们可以在产生环境运行多个版本的代码，通过给流量打标签，中间件导流控制不同流量在模块之间的走向，从而起到引流到被测模块的目的。
- 被测模块部署到生产环境的隔离区域，不接真实流量
- 线上录制真实流量
- 根据捕获的真实流量构造测试请求
- 根据捕获的真实流量准备灌入测试数据
- 发测试请求，通过引流让其流经被测模块
- 查看响应，以及所有的副作用
第一步：部署模块到生产环境，但是不接流量
就是部署到一台独立的机器（可以是容器，节省成本）。然后通过中间件控制真实流量不要过来。如果在线有开发环境，比如基于浏览器的IDE，这个部署成本可以更低。
第二步：获取真实流量
把业务逻辑的入和出都劫持下来，通过网络代理获得所有的请求和响应数据。如果需要捕捉特定类型的请求，可以把预期的类型参数加到录制的逻辑，有选择的录制。
第三步：构造测试请求
- 圈定测试的scope
- 修改入口处的request
- 控制第三方模块的response
这里所有的request和response都不需要从头构造。是基于上一步捕捉的真实流量修改而来。
第四步：灌入测试数据
这一步很简单，就是测试司机开户，测试乘客开户这样的过程。把真实的司机乘客等业务流程参与方的数据灌入到数据库里。以便流量回放时使用。
特别注意此处相比线下测试可以节省大量的配置数据的复制和还原。
第五步：发测试请求
被测的模块未必是入口的模块。所以可能需要让流量穿过一些生产环境的正式模块，再流到测试中的被测模块版本。
在需要控制一些测试边界范围外的系统response时，可以通过出代理来mock数据
第六步：查看结果
这个就回到了流量录制这一步了。通过查看录制的请求处理过程，可以人工判断被测代码是否符合。如果需要变成自动化测试，人工再标记一些需要比对的结果字段，然后把处理过程保存到自动化测试系统里。
总结
好处
- 线下测试挂了，第一反应是不是环境问题。线上要可靠得多
- 节省大量构造测试数据的时间
- 需要灌入数据库的测试数据比线下搞要少
- 运营配置等依赖不再是问题
难点
- 测试数据不要污染正式的运营数据
- 根据Log复制用户，这一步和具体业务相关，需要理解log
- 支撑整个框架的中间件的稳定性和性能，不影响线上正式业务
但是如果这个科幻真的实现了，我们离
就不是很远了。
