如何處理不穩定的自動化測試？

如何處理不穩定的自動化測試？

一、文章來源: mp.weixin.qq.com
忘記原文連結了

abluecolor
在解決這個問題之前，請停止編寫更多測試，因為這將花費你較高的測試維護成本。你需要儘快行動起來對不穩定的原因進行深入研究，找到不穩定的根因，並且嘗試在流程、環境和程式碼方面做一些最佳化工作解決它。
MasterKindew
如果你還沒有在測試裡增加測試日誌記錄，那麼專門花時間補充日誌會對你大有幫助，讓框架丟擲錯誤並明確測試的錯誤。如果你的用例透過使用前端自動化框架開發，那麼在發生故障時截圖的內容將會很有幫助。
hitchdev
這是一個非常普遍的問題，也是一個很難解決的問題。
我的解決方案：1 使測試完全閉環。測試是否有透過網路發起對外請求？如果有的話請使用模擬 API 代替。是否使用資料庫？使用固定資料在本地設定資料庫，並在每次測試後將其清除。在實踐中，我認為幾乎沒有人使端到端測試是密封的。這非常非常難。不過，這是一個值得實現的目標，原因不僅僅是脆弱。2 刪除測試中所有類似於 sleep 的內容並用顯式等待代替。3 識別程式碼中不穩定因素並修復或消除它們。4 這個問題確實很棘手，因為你要麼需要成為開發人員，要麼需要開發人員的支援來解決這些問題。問題如下：

• 迴圈訪問沒有確定順序的資料結構（如雜湊圖）。
• SELECT 查詢巢狀在程式碼中。
• 使用隨機數（這可以透過修復測試執行中的種子或模擬 RNG 來解決）。 ToddBradley 我最近一份工作的公司有遇到這個問題。當我加入時，我們遇到了測試結果不穩定的大問題。工程主管總是指責測試同學，而質量主管則不太確定這個鍋該不該背。所以我的工作就是把這一切問題都解決掉。這是一項巨大的工程，但最終我們發現該產品不穩定，而開發人員從未意識到這一點，整個過程蠻好玩的。因此，這裡的教訓是，“不穩定的自動化測試環境” 可能有很多原因：
• 測試用例設計不當
• 有缺陷的測試基礎設施（伺服器等）
• 被測系統不穩定，至少在測試環境中是如此 重試只是把問題掩蓋起來，所以我的建議是避免重試，除非問題出在產品方面並且沒有人願意修復它（在這種情況下，你需要首先詢問是否值得測試）。 Rough-Supermarket-97 你可以使用一些統計模型來量化這一點，但從我的角度來看，依賴點與滿足透過定義所需的測試步驟之間存在關係。對於依賴於穿過多個接縫的每個測試步驟結果（將 API -> 佇列 -> DB 視為 3 個獨立的接縫），失敗的可能性隨著接縫的數量呈指數級增加，並乘以依賴於的步驟數那些接縫。您可以想象，這種可能性可能會變得相當高，尤其是當您根據 I/O 瓶頸和其他更多基於基礎設施的故障點等因素考慮接縫發生一般故障的機率時。那麼如何穩定整合測試呢？其一，讓它們儘可能小。這將是我考慮的第一階段。其次，問問自己，“我真的關心測試基礎設施嗎？或者我更關心應用程式如何響應其依賴項？” - 這個問題應該引導您確定模擬在哪裡有用以及您可能仍然想在哪裡使用該依賴項。 Yogurt8
• 測試環境總是不穩定的。
• 良好的日誌記錄對於任何自動化專案都至關重要。 Ikeeki 我認為不穩定的測試程式碼是寫的質量差，如何處理質量不佳的程式碼？ 你會發現有時這是一個不穩定的測試，但有時它是一個真正的應用程式錯誤。我們越減少脆弱性，後者就越開始發生。但 IMO 的關鍵是測試指標、測試儀表板以及解決任何未達到 90% 以上成功率的測試。作為 SDET，我會第一個排查報錯問題，但如果我能證明測試程式碼之外存在某些問題，那麼我會找一個該領域測試專家一起解決這個問題。有一次，我編寫了一個 Slack 機器人，當新測試不穩定或在所有分支上開始失敗時，它會向我們發出警報，這個機器人對我們非常有用。 wegotallthetoys 顯示每個測試執行步驟的測試報告。我曾經處理過一組每天執行的 2000 個測試，每次執行可能會出現 60-70 個失敗測試，我們的測試報告意味著可以在幾個小時內 review 這些失敗。該套件測試報告包含：
• 每個執行動作的螢幕截圖
• 利用查詢來選擇要使用的測試資料
• 輸入任何操作的所有資料
• fwk 丟擲的任何異常 根據我在該測試集中的經驗，失敗的最常見原因是與測試資料相關，例如，測試正在嘗試完成某資料的操作，而該某資料未處於當前操作能處理的狀態。 Brankksss 我認為你可以使測試儘可能更加密封。模擬一些依賴項，在 Docker 容器上設定 SUT，並僅對 “不穩定” 環境進行測試。我不知道你的測試環境是如何構建的，我猜測你的依賴項每次都不會更新版本，所以這就是我對你的情況的看法。看了上述的回答，大家也許有體感了。針對不穩定的測試處理方法，可以歸結為以下幾種：
• 用例開發角度：適當記錄用例執行日誌；用例編寫自閉環，多使用 Mock。
• 識別並消除測試中不穩定因素，例如 sleep。
• 建議消除重試機制。
• 增加測試不穩定告警機器人。 今天為什麼分享這個問題，主要是團隊也面臨相似的問題。我們團隊自動化用例數量將近有 1w，因此排查不穩定測試用例耗費的大量人力。團隊處理這個問題也專門作為一個專項來處理。下面我分享一下我們團隊處理不穩定測試的經驗。處理這個難題的第一個問題就是 如何定義不穩定測試？我相信針對這個問題，每個團隊會基於自己的實際情況可能會有不同的定義。我們團隊的自動化用例 每天會執行 12 次。我們定義的不穩定的測試是每天執行成功率為 0 的用例，即 0 成功率用例。OK，問題已經定義，那麼如何處理不穩定測試？我們的處理方式分三步：
• 蒐集問題用例，分析報錯原因，對問題進行歸類。
• 針對已知問題進行優先修復。
• 增加 0 成功率機器人，用例每日告警。

針對前兩步我這裡分享一下解決方法。我們的不穩定用例主要有以下幾類：

1. 用例不閉環，調下游的服務不穩定導致用例頻繁失敗。
2. 用例有查詢 DB 的模組，因為經常出現慢查詢的情況。
3. 測試環境伺服器不穩定，這裡表現為與線上環境相比，配置不一致甚至缺失。
   1. 這裡的配置有 DB 的表結構、引數中心等 那麼對應的解決方法：
4. 對依賴下游的服務進行 mock。
5. 慢查詢 SQL 進行最佳化，實現基於索引查詢資料。如果無法實現基於索引查詢，就對查詢 DB 的 SQL 增大 timeout。 解決不穩定用例是一個持久仗。問題的關鍵在於 如何做到用例的保鮮？ 目前我們用例保鮮的方法就是 透過增加 0 成功率機器人，每日更新 0 透過率用例，頻繁處理不穩定用例。當然這個方案仍不是治本的最終策略，但是在一定程度上能解決了迴歸耗時較長的問題。

*以上文字均來源前面連結的文章 && 下面為個人簡短思考 *

二、個人思考
Author：xxx
今天在公眾號看到上面這篇文章，有感而發，對上面文章及思考， 針對不穩定的因素有部分補充及同感，
一句話：沒有解決不了的穩定性因素，如果有那就是處理不夠好

1. 用例設計不當，(用例設計不當分好幾種)
   1. 編寫的程式碼邏輯不夠嚴謹，程式碼本身不夠穩定，
   2. 等待獲取資料， sleep 過多，
   3. 用例不夠獨立，依賴上游資料導致失敗，或者依賴太多，
   4. 用例和測試資料不夠獨立，
   5. 慢查詢

總結：個人認為 這種均可以解決，且也好解決，但是這也是目前遇到的不穩定因素中比較多的，
解決：需要詳細分析不穩定的因素 - 需要對日誌分級，對不穩定的因素分類，給出詳細的解決方案，

1. 測試環境伺服器的不穩定，

   1. 這種需要運維和研發，測試 共建穩定的測試環境，這是做好自動化的前提，不細說；
   2. 當然存在測試環境不穩定的情況 (只是相對 online 環境)， 需要有部分重試的機制，得需要根據場景來細說；

2. 自動化用例都有，但是沒有發現問題

   1. 遇到過很多人寫的指令碼執行就是發現不了問題，有的人寫的能夠發現一些問題，
   2. 用例設計的場景是關鍵，好的用例可節約很多的迴歸時間！
   3. 用例效驗的資料，

================ 針對上文原作者內容評論 ======================

• 測試用例設計不當 -> 大部分都是這個因素導致 ！
• 有缺陷的測試基礎設施（伺服器等） -> 我認為自動化正好可以檢測一套新的環境部署是否 ok
• 被測系統不穩定，至少在測試環境中是如此 -> 應該是相對而言，所以需要有對應的自動化策略；
• 測試環境總是不穩定的。 -> 存在，需要有對應的策略來應對，例如獲取資料可以動態等待，如果經常如此，則需要共建環境了；
• 良好的日誌記錄對於任何自動化專案都至關重要。 ->Important

測試報告包含：

• 每個執行動作的螢幕截圖 -> 建議針對報錯才截圖，否則佔用資源，
• 利用查詢來選擇要使用的測試資料 -> 如果查詢沒有怎麼辦 ？ 建議資料最好閉環，
• 輸入任何操作的所有資料 -> 贊同
• fwk 丟擲的任何異常 -> 贊同

不穩定的測試處理方法，可以歸結為以下幾種：

1. 用例開發角度：適當記錄用例執行日誌；用例編寫自閉環，多使用 Mock。 -> 用例閉環很重要，很多人沒意識到！ 資料的獨立性 ！
2. 識別並消除測試中不穩定因素，例如 sleep。 -> 贊同
3. 建議消除重試機制。 -> 贊同，我這指的是單個用例的贊同，整個工程可定製配置重試機制，可排除部分環境因素導致的失敗！
   1. 重試機制有個作用就是排除環境因素，不好的地方穩定性問題可能沒有暴露，但是如果每天都執行，不穩定因素遲早會暴露的，
   2. 重試機制 - 會增大用例執行時間，
4. 增加測試不穩定告警機器人。 -> 贊同，可指令碼可平臺檢視用例執行的歷史記錄，

那麼如何處理不穩定測試？我們的處理方式分三步：

1. 蒐集問題用例，分析報錯原因，對問題進行歸類。 -> 贊同
2. 針對已知問題進行優先修復。 -> 贊同
3. 增加 0 成功率機器人，用例每日告警。 -> 贊同

建議增加程式碼評審環節，排除程式碼本身不夠嚴謹導致的問題或者其他問題，集思廣益，一起探討思考不足之處；

針對前兩步我這裡分享一下解決方法。我們的不穩定用例主要有以下幾類：

1. 用例不閉環，調下游的服務不穩定導致用例頻繁失敗。-> 用例不閉環，資料不閉環導致！
2. 用例有查詢 DB 的模組，因為經常出現慢查詢的情況。 -> 分場景處理
3. 測試環境伺服器不穩定，這裡表現為與線上環境相比，配置不一致甚至缺失。-> 建議執行之前先 setup，初始化或者自動化檢查配置資訊即可，沒有就建立 (均自動化流程實現)

解決不穩定用例是一個持久仗。問題的關鍵在於 如何做到用例的保鮮？
目前我們用例保鮮的方法就是 透過增加 0 成功率機器人，每日更新 0 透過率用例，頻繁處理不穩定用例。當然這個方案仍不是治本的最終策略，但是在一定程度上能解決了迴歸耗時較長的問題。
用例不穩定主要還是人為因素導致，建議 框架清晰，用例及資料獨立，增加程式碼 review 環節，排查程式碼本身存在的處理邏輯，設計等等不合理的場景，可以解決 97% 以上的不穩定因素；

需求變動或者介面變動導致的用例修改的場景，怎麼樣才能更快更好的重構相關用例的場景，主要是高質量的用例，這是需要思考和探究的地方 ？
監控變動記錄均已實現，簡單的重構用例也可以實現，重在高質量 ！

• END -