100% 測試自動化或許很理想，但實際上可行嗎？

作者：Jonny Steiner，產品行銷經理

 

如果我能弄到一台時光機，或者即使是我剛剛編造出來的、能穿越時空的神奇望遠鏡，我都會用它們做很多事情。不過，就這篇文章而言，我想用我的時光望遠鏡看看未來。具體來說，我想看看我們是否真的能實現持續測試的100%自動化。

100%自動化測試可能是不可能的

這是每個人都夢寐以求​​的。實現持續測試的100%自動化是每個品質保證和測試團隊成員的夢想。然而，在某些方面，這確實是一個挑戰。首先，有些程式碼過於複雜，難以編寫自動化測試。另一方面，有些程式碼又不夠重要，無需進行自動化測試。其核心理念在於，採用基於風險的自動化測試方法，確保將重點放在軟體最重要的部分。

一些專家建議放棄100%自動化的目標。他們認為，在不斷變化的軟體開發過程中，沒有時間實現完全自動化。他們指出，重點應該放在投資報酬率以及能夠讓企業領導者和利害關係人滿意的事情上。

若？

假設實現 100% 的持續測試自動化是可行的。有跡象表明，一些組織已經在嘗試這樣做。隨著無程式碼開發和自動化測試解決方案的興起，未來應用程式的開發和運行都將完全自動化，這為未來奠定了基礎。唯一需要人工幹預的情況是，當新版本發布或缺陷修復後，重新啟動每次測試。

這樣做的好處在於，能夠在無需人工幹預的情況下，在流程早期就消除缺陷，同時進一步提高發布速度。然而，正如我們將看到的，自動化測試雖然能創造價值，但並非總是以我們預期的方式。

測試自動化的“價值”

自動化測試流程如下：測試運行使用起始位置、變更和預期結果。測試運行完成後，表示自動化流程已完成，但測試功能尚未完成，只有在所有檢查運行完畢後才算真正完成。價值在於測試/修復/重新測試的循環過程。這個過程最終會產生清晰的錯誤修正指南。

需要注意的是，在建立自動化檢查時，初始測試執行完成後，進行變更並重新執行測試，此時測試會在預期結​​果不正確時偵測到缺陷。

持續測試領域有一句老話：“一次軟體變更就會把測試自動化變成變更檢測。”

自動化是所有問題的根源

簡而言之，持續測試可能會帶來更多挑戰。一旦開發中的應用程式發生變更，自動化測試套件就會過時。測試維護常常被忽視，但它同樣至關重要。一些組織面臨的問題是缺乏對現有測試維護和刪除過時測試的監管，從而導致測試債務。

測試覆蓋率在自動化測試中也至關重要。每個場景都需要覆蓋，否則即使測試“通過”，其準確性可能不如你想像的那樣。誠然，你的測驗可能達到了 100% 通過，但那些遺漏的場景呢？它們不會被包含在測試結果中。

其次是測試失敗的問題。這些問題都需要調查。更棘手的是，有時測試失敗並非技術問題，而是環境因素造成的。在這個分秒必爭的世界裡，「假陰性」測試結果同樣寶貴。

此外，還需要考慮測試失敗的情況，因為每項失敗都需要調查。有些測試是“假陰性”，例如，由於環境問題導致測試逾時。這種情況會浪費時間，而不是節省時間。

自動化測試的最後一個挑戰在於，測試程序本身並不具備思考能力。它們只會按照預設的路徑和程式碼執行。但這與人類與應用程式互動的方式截然不同。我們會分心、被其他事情分散注意力，有時還會誤點。而自動化測試只能涵蓋使用者預先選擇的行為。

自動化程度達到什麼程度才算足夠？

從企業領導和主管到開發人員和測試人員，人們在使用或瀏覽應用程式時總是會不斷產生想要測試和探索的想法。你可能只會嘗試一次，看看它是否有效。但你不會，也不應該為所有這些小場景編寫測試案例。

我們目前還無法做到直接向測試工具輸入需求並等待預期結果。但是，測試人員已經希望能夠一鍵執行測試並立即獲得結果。如果我們談到實現100%的自動化測試，這意味著測試通過後，軟體就可以直接上線生產環境，無需任何進一步的分析。

好消息是我剛剛描述的是自動化回歸測試。雖然這不包括效能測試和安全測試，但這意味著一旦應用程式在隔離環境中完成測試並通過，就可以將其部署到生產環境。

與真相共處

所以，或許100%的測試自動化是不可能的。這固然是個好主意，但並非最實用。總是會有一些程式碼難以編寫自動化測試，它們可能難以閱讀，但有時某些程式碼並不重要到需要自動化。我在此提倡的基於風險的方法，重點是軟體中最重要的部分。

或許從投資報酬率的角度來看這個問題會更好。想想你的企業真正需要的覆蓋範圍。了解高階主管和領導者的態度，看看他們對正在開發的軟體的風險承受能力如何。

請記住，並非所有缺陷都相同，因此，並非所有測試都需要自動化。