反複無常的測試的危害:第1部分

今天，我們的軟件被大量交織在一起的自動化測試所覆蓋。通過我們DevOps員工的出色工作，我們讓數百台vm日夜不停地運行著我們的所有測試——單元測試、功能測試、端到端測試、集成測試、性能測試、穩定性測試。多虧了我們驚人的測試自動化係統，我們甚至能夠實現高質量的每月發布!

也就是說，我參與的每個使用自動測試的項目都遭受著同樣的刺激——不穩定的測試。Flaky測試是指有時會失敗的測試……但並不總是失敗。不像糕點的片狀，當涉及到軟件測試時，片狀的質量是有害的!我們的測試每30萬次中就有一次失敗。對文獻的回顧表明，所有主要的軟件公司都在與不靠譜的測試作鬥爭。

不靠譜的考試快把我逼瘋了!它們總是讓人分心;擔心他們可能隱藏了一個大問題;它們很難解。更糟糕的是，隨著時間的推移，他們往往會使團隊士氣低落。

我在Kinaxis工作的這些年裏，我們一直在與不可靠的測試做鬥爭，我認為我們最終會贏。以下是我們所做的一些事情:

步驟1:確定並處理最脆弱的測試

為了幫助我們控製問題，我們的第一個策略是專注於失敗最多的測試。我們對測試框架進行了擴充，使每個片狀測試運行三次。如果一個測試通過了三次中的兩次，我們就認為它通過了。

接下來我們討論最不靠譜的測試。我們考慮了他們提供的保險。在某些情況下，一個脆弱的測試覆蓋了與另一個(非脆弱的)測試相同的功能。我們可以簡單地取消片狀測試。在其他情況下，我們可以對現有的非片狀測試進行少量添加，以覆蓋片狀測試的功能。然後我們可以去掉片狀測試。

一些不可靠的測試已經過時，需要重新編寫。一些不可靠的測試覆蓋了非常奇怪的邊緣情況。我們暫時將其中一些設備離線以去除噪音。

步驟2:生成測試代碼

調查顯示，對於我們鬆散測試的一個子集，鬆散的原因是測試代碼中的線程錯誤。多線程代碼寫起來很複雜，很容易出錯!

為了解決這個問題，我們編寫了一個生成測試部分的測試代碼生成器。測試人員隻需要填寫其他部分。這有兩個重要的好處——首先，它使我們的測試人員更快地創建新的測試;其次，使用生成代碼的測試不太可能不可靠。

步驟3:找出測試幹擾的原因

測試有時會調整環境的某個方麵，比如當它們設置注冊表設置或在磁盤上創建文件時。有時測試作者忘記將環境恢複到其原始狀態(例如清除注冊表設置，刪除文件，等等)。結果，由於環境中的這些更改，後續測試將失敗。這被稱為測試幹擾，或者更隨意地稱為“不自我清理”的測試。

為了檢測這些問題，我們編寫了在每次測試後檢查環境各個方麵的工具。我們發現這種方法非常有效，但隨著測試數量的增長，它最終無法擴展。

步驟4:消除超時

我們的一些測試有“超時”或“等待”，猜測另一個操作需要多長時間。當這些測試間歇性失敗時，常用的快速修複方法是增加超時時間。然而，這使得我們的測試套件花費了更長的時間。

我們通過使用回調來可靠地指示操作何時完成，從而消除了這個問題。這也使我們的測試運行得更快。
多虧了這些技術，我們發現自己在消除不靠譜測試的道路上走得很好。

閱讀我們的下一篇文章(第2部分)，了解我們進化到更高級技術的細節。