如何能讓開發效率快10x倍？

為什么開發慢？

據我不完全的觀察，開發的過程是這樣的

如果是測試環境，那為什么慢呢？

• 測試環境又不好使了，誰又改了什么
• 沒有真實的流量，線下的小白鼠沒有代表性

如果是生產環境，那為什么慢呢？

• 部署不能太快了，得慢慢來，免得掛了
• 開流量得小心又小心，免得掛了

所以要讓開發速度變得更快，就是要更快地做想要的改動，然后更快地得到好使還是不好使的反饋。

以下為科學幻想

實現原理

愿景已經很清楚了。那么怎么實現呢？

大部分業務系統都是支持多用戶的。用戶與用戶之間的數據是隔離的。我們可以通過在線上增加測試用戶的方式，在生產環境直接跑測試。

然后我們可以在產生環境運行多個版本的代碼，通過給流量打標簽，中間件導流控制不同流量在模塊之間的走向，從而起到引流到被測模塊的目的。

1. 被測模塊部署到生產環境的隔離區域，不接真實流量
2. 線上錄制真實流量
3. 根據捕獲的真實流量構造測試請求
4. 根據捕獲的真實流量準備灌入測試數據
5. 發測試請求，通過引流讓其流經被測模塊
6. 查看響應，以及所有的副作用

第一步：部署模塊到生產環境，但是不接流量

就是部署到一臺獨立的機器（可以是容器，節省成本）。然后通過中間件控制真實流量不要過來。如果在線有開發環境，比如基于瀏覽器的IDE，這個部署成本可以更低。

第二步：獲取真實流量

把業務邏輯的入和出都劫持下來，通過網絡代理獲得所有的請求和響應數據。如果需要捕捉特定類型的請求，可以把預期的類型參數加到錄制的邏輯，有選擇的錄制。

第三步：構造測試請求

• 圈定測試的scope
• 修改入口處的request
• 控制第三方模塊的response

這里所有的request和response都不需要從頭構造。是基于上一步捕捉的真實流量修改而來。

第四步：灌入測試數據

這一步很簡單，就是測試司機開戶，測試乘客開戶這樣的過程。把真實的司機乘客等業務流程參與方的數據灌入到數據庫里。以便流量回放時使用。

特別注意此處相比線下測試可以節省大量的配置數據的復制和還原。

第五步：發測試請求

被測的模塊未必是入口的模塊。所以可能需要讓流量穿過一些生產環境的正式模塊，再流到測試中的被測模塊版本。

在需要控制一些測試邊界范圍外的系統response時，可以通過出代理來mock數據

第六步：查看結果

這個就回到了流量錄制這一步了。通過查看錄制的請求處理過程，可以人工判斷被測代碼是否符合。如果需要變成自動化測試，人工再標記一些需要比對的結果字段，然后把處理過程保存到自動化測試系統里。

總結

好處

• 線下測試掛了，第一反應是不是環境問題。線上要可靠得多
• 節省大量構造測試數據的時間
• 需要灌入數據庫的測試數據比線下搞要少
• 運營配置等依賴不再是問題

難點

• 測試數據不要污染正式的運營數據
• 根據Log復制用戶，這一步和具體業務相關，需要理解log
• 支撐整個框架的中間件的穩定性和性能，不影響線上正式業務

但是如果這個科幻真的實現了，我們離

就不是很遠了。

 

來自：https://zhuanlan.zhihu.com/p/25598924