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