錄製線上流量做迴歸測試的正確開啟方式

目錄

• 目錄
• 線上流量
  • 什麼是錄製線上流量回放
  • 為什麼需要錄製線上流量回放
  • 線上流量回放的限制是什麼
• 回放差異 diff
  • diff 實現對比和去噪
• demo 實現
  • docker-compose
  • diff 效果
  • diff 限制
• 缺陷
• 嘗試的解決方案
  • 可以透過複製貼上人為構造回放所需的測試資料日誌
  • 解決所有問題以後還有什麼不優雅的地方
• 進一步完善

線上流量

什麼是錄製線上流量回放

為什麼需要錄製線上流量回放

• 專案大迭代更新，容易漏測，或者有很多沒用評估到的地方。

• 如果用線上流量做一次迴歸測試，可以進一步減少 bug 的風險。

• 大大節省構造測試資料，或者構造測試資料指令碼的時間，提高效率。

線上流量回放的限制是什麼

• 只回放 GET 請求

因為其他請求的回放，會對使用者資料進行操作，有風險，需要排除。

除非構建多套備份資料庫，但成本太高，不是很有必要。

• 需要對比回放前後的流量

不然回放就沒有意義了，你都不知道回放前後對比的差異是什麼。

• 需要去噪音

對比完了，對於一些類似時間戳的值，其實就是噪音，這些不一樣很正常，我們需要剔除，不然差異沒有價值。

由此可見，想要正確開啟線上流量錄製回放，需要解決很多問題。

而重中之重，就是 diff。

回放差異 diff

diff 實現對比和去噪

demo 實現

docker-compose

version: '2'
services:

  http-demo-record:
    image: shaonian/http-demo:gor-test-v2.9
    ports:
      - "8080:8080"

  http-demo-replay-old:
    image: shaonian/http-demo:diff-old-1

  http-demo-replay-old-noise:
    image: shaonian/http-demo:diff-old-2

  http-demo-replay-new:
    image: shaonian/http-demo:diff-new

  diff:
    image: shaonian/diff:v0.1
    command:
      - -candidate=http-demo-replay-new:8080
      - -master.primary=http-demo-replay-old:8080
      - -master.secondary=http-demo-replay-old-noise:8080
      - -service.protocol=http
      - -serviceName='Diff Test'
      - -proxy.port=:8880
      - -admin.port=:8881
      - -http.port=:8888
      - -rootUrl=localhost:8888
      - -summary.email='your@email.com'
    ports:
      - "8881:8881"
      - "8888:8888"

diff 效果

diff 限制

diff 的歸類有問題。

因為 url 能攜帶各種各樣的 param，所以 diff 設計裡面不會直接把 url 作為歸納名，需要透過在請求的 header 裡面增加 Canonical-Resource: http-demo 來設定。

這就出來一個問題，線上轉發的流量，無法根據具體的路由來動態設定歸納名，只能統一設定成是一個服務的，比如 http-demo 這樣，但是我這個 http-demo 下有很多 api，出來的差異具體是哪一個 api 呢，我也不知道，得看返回欄位去猜，就很華而不實。

所以做到這裡，只能自嗨，無法落地到實際專案中，想要真正落地，這一步也是一定一定要解決的！

缺陷

以上實現的方法總結起來，就是把錄製 gor 元件寫進 Dockerfile，並在專案執行的時候，實時錄製線上流量，轉發到測試環境，然後進行 diff 去噪對比。

但是這樣就大功告成了嗎？

並沒有。

還有幾個問題需要自我反問一下。

• 我們真的需要實時錄製轉發嗎？

其實不需要。

我們只是希望能夠錄製線上請求，然後根據再迭代之後用來回放測試。

如果開啟實時回放，會在我們不需要測試的時候，浪費伺服器的效能和資源。

• 線上錄製的回放，真的就代表全部場景嗎？

其實也不對。

使用者不一定不觸發的場景，其實我們也需要覆蓋。

錄製只是讓我們更容易更便捷生成測試資料而已。

• 線上錄製會有效能損耗嗎？

或多或少都有影響，畢竟 gor 和 服務處於同一個容器中。

所以三個反問以後，我們的需求逐漸明確了。

我們需要一個不會影響線上服務效能的，又能快速生成測試資料回放，並且能自定義補全更多場景的測試回放。

同時，我們還需要解決 diff 的路由智慧匹配的問題。

這樣可以嗎？

我覺得可以。

嘗試的解決方案

可以透過複製貼上人為構造回放所需的測試資料日誌

上圖是錄製流量以後儲存的 log 檔案，我們可以清楚看到它的結構，所以這是不是意味著，只要我們寫出來這份相同格式的 log，我們就能直接憑藉這份 log 來回放呢？

對的。

此外，這個 log 裡面，你可以直接根據具體的 url，設定好相應的 Canonical-Resource，就直接解決了 diff 路由歸納名的問題。

而且，我們根本不需要真的到線上去錄製，偽造一份這樣格式的 log，甚至還可以直接修改補全一些沒有的場景進去，就可以直接以此為範本，作為回放 log 的效果了。

這樣也根本不需要擔心線上錄製會影響線上伺服器的效能和資源。

解決所有問題以後，還有什麼不優雅的地方

那 log 我也得複製貼上去生成，而且 log 裡面的時間戳排序，我也得自己造，這樣看似方便，其實只是方便了不用手寫程式碼來編造測試資料，可以直接透過編寫 log 就能回放流量。

也就是，這樣的方案，只是降低了測試技術棧的門檻，提高了一點點的效率。

而且還有個問題，很多的資料，我其實是動態生成的，我傳進去之前，還得透過其他介面去獲取返回值，再動態填進去，這樣寫 log 並不能實現啊。

還有，很多引數也有時效問題，過段時間 token 過期了，我替換 token 也很麻煩。

就算，設定成萬能的 token，那涉及到使用者的資料，比如有些業務場景 token 裡面包含了某類使用者具體資訊的時候，萬能 token 就不管用了，因為有很多自定義的資料要去測。

所以，看似解決完所有技術棧問題以後，其實還有很多業務問題，導致它使用場景有限，甚至無法完全落地。

正確開啟方式

為什麼要拘泥於用線上流量來回放呢？

如果我的指令碼能夠批次構造大量且覆蓋眾多場景，且可高度自定義的請求，再將這些請求直接去請求 diff，不就能直接對比出前後有什麼差異嗎？

何況，就算我的內部 rpc 服務呼叫更改，變得更加複雜，但是暴露在外給使用者的業務操作，是不會發生大改的。

而且此前，基於專案 shaonian/boomer_locust 的壓測工具，我之前已經實現了全鏈路壓測的業務邏輯覆蓋。

所以這裡完全可以引出一個全新的概念，用可控速度的壓測工具，以及高度靈活的程式設計指令碼，實現大批次構造測試資料，模擬業務場景壓力，並直接實現前後對比差異的不同。

因為資料全部都是新構造好的，所以不止 GET 請求我可以做，POST PUT DELETE 請求我也可以，因為資料都是我構造上傳的，如果在測試環境中，完全刪掉都不會有影響，而且只要設定好前後的測試髒資料的清理，其實線上資料庫都能做。（當然，直接做到 stage 環境資料庫就可以了，prod 沒必要。）

進一步完善

既然正確開啟了前後版本的快速 diff 測試，那麼如何進一步完善呢？

當然是提高指令碼的業務覆蓋場景，已經程式碼覆蓋率。

如何判斷自己的構造迴歸流量，儘可能覆蓋完全呢？

我們可以引入程式碼的實時染色，在本地就先測好覆蓋率，再去部署上線。

這個程式碼實時染色，可以基於 goc 在 vscode 的外掛來實現。

至此，快速構造測試資料，對比前後版本的方案成型，且可根據業務定製指令碼，可落地實現，真正意義上地實現迴歸 diff 測試。

由此為基礎以後，下一步，當然就是精準化測試，也是未來測試的大勢所趨。

精準測試的概念:
藉助一定的技術手段、透過輔助演算法對傳統軟體測試過程進行視覺化、分析及最佳化的過程，使得測試過程更加視覺化、智慧、可信和精準。


精準測試的目標:
精準測試的核心思想就是使用非常精確和智慧的軟體來解決傳統軟體測試過程中存在的問題，從根本上引領從經驗型方法向技術型方法的轉型。
質量的評估不再完全靠個人經驗和業務熟悉度，而是透過精準的資料來判定。
在測試資源有限的前提下，將用例精簡到更加有針對性，提高測試效率，有效的減少漏測風險。

精準測試的核心 - 雙向追溯:

正向追溯: 開發人員可以看到測試人員執行用例的程式碼細節，以方便進行缺陷的修復，測試資料可以直接為開發除錯提供依據，快速定位並修復缺陷。
逆向追溯: 測試人員透過修改的原始碼快速確定測試用例的範圍，極大減少迴歸測試的盲目性和工作量，快速修訂測試用例，達到測試覆蓋率最大化。

PS：技術交流 QQ 群 552643038