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