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

為什麼開發慢?

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

如果是測試環境,那為什麼慢呢?

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

如果是生產環境,那為什麼慢呢?

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

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

以下為科學幻想

實現原理

願景已經很清楚了。那麼怎麼實現呢?

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

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

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

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

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

第二步:獲取真實流量

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

第三步:構造測試請求

  • 圈定測試的scope
  • 修改入口處的request

  • 控制第三方模塊的response

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

第四步:灌入測試數據

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

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

第五步:發測試請求

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

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

第六步:查看結果

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

總結

好處

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

難點

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

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

就不是很遠了。


推薦閱讀:

如何看待重型敏捷管理框架?
敏捷實際是迭代的瀑布模型的變種,這種觀點對嗎?
如何看待 PMI 推出的敏捷認證 PMI-ACP?

TAG:测试驱动开发 | 测试驱动 | 敏捷 |