測試自動化的六大原則
?“測試”一詞最初是指“用于測定貴金屬的小容器”。這意味著測試是一種確定黃金或白銀質量的方法。它也用于精煉有價值的合金，如錫。
后來，該術語在其他領域被采用，如今，在教育，醫學或軟件開發等環境中經常會發現它。然而，它的本質并沒有改變：測試被用來提煉最終價值。
我們在軟件開發中使用測試來確保代碼按預期工作。測試可以是手動的，也可以是自動的。手動測試類似于汽車制造商撞車，以驗證它們在道路上是否安全。它可以工作，但經常這樣做太昂貴了，所以它通常在生產周期結束時完成。這種方法的問題在于，在此階段發現的問題可能會將產品的發布延遲數月。
自動化軟件測試具有完全不同的成本結構。有一個初始反轉和定期維護，但是一旦tes自動化到位，我們就可以根據需要隨時運行測試 - 只需幾分錢。
通過測試自動化，開發人員可以獲得持續的反饋，使他們能夠在生產周期的早期發現問題。快速迭代可改進設計、提高質量和更安全的發布。
測試自動化原理
整本書都是專門圍繞測試自動化主題編寫的。這是每個開發人員在某些時候都需要掌握的技能，最好盡早完成。
以下是簡化學習曲線的六個原則：
- 測試應能提高質量。
- 測試應降低引入故障的風險。
- 測試有助于理解代碼。
- 測試必須易于編寫。
- 測試套件必須易于運行。
- 測試套件應該需要最少的維護。
原則 1：測試自動化提高質量
質量是一個難以捉摸的概念。盡我們所能，不可能用數字來定義它。然而，當我們看到它時，我們就知道它。軟件行業提出了許多衡量質量的指標：缺陷數量、代碼覆蓋率、CI錯誤率、測試失敗率等。每一個都抓住了質量概念的某些方面。
自動化測試通過持續運行數百或數千個測試來改善質量指標;在缺陷進入生產環境之前發現缺陷，通知開發人員潛在的問題，并檢查系統是否偏離了用戶的期望。
撇開指標不談，我們知道可靠的設計是質量的先決條件。當測試驅動開發時，開發人員可以輕松嘗試不同的想法，并確定哪一個效果最好。測試驅動開發 （TDD） 和行為驅動開發 （BDD） 等實踐利用了這一特性，取得了巨大的成功。
原則2：測試自動化降低風險
代碼審查和同行編程雖然必要且富有成效，但不能依靠它來查找錯誤。經驗表明，更多的眼球并不能轉化為更少的錯誤。
可靠地發現錯誤的唯一方法是構建一個全面的自動化測試套件。測試可以從上到下檢查整個應用程序。它們在造成任何傷害、發現回歸并在各種設備和環境上運行應用程序之前捕獲錯誤，否則手動嘗試的成本會非常高昂。
即使團隊中的每個人都是一個非常聰明的開發人員，不知何故從未犯過錯誤，第三方依賴項仍然會引入錯誤并帶來風險。自動測試可以掃描項目中的每一行代碼，以查找錯誤和安全問題。
原則3：測試幫助您了解系統
很多時候，開發人員回到幾天前編寫的代碼，卻意識到他們已經完全忘記了它是如何工作的。當開發人員必須處理其他人編寫的代碼時，情況會更糟。
通常，閱讀測試是理解系統的最佳場所，因為它們通過示例來展示事物的工作原理。因此，當有疑問時，開發人員可以參考測試套件。
例如，測試可以向其他開發人員展示API應該如何響應，從而允許他們跳過查看文檔。
ctx := context.Background()result, _, err := env.Client.Server.Create(ctx, ServerCreateOpts { Name: "test", ServerType: &ServerType{ID: 1}, Image: &Image{ID: 2}, SSHKeys: []*SSHKey{ {ID: 1}, {ID: 2}, },})if err != nil { t.Fatalf("Server.Create failed: %s", err)}if result.Server == nil { t.Fatal("no server")}if result.Server.ID != 1 { t.Errorf("unexpected server ID: %v", result.Server.ID)}if result.RootPassword != "" { t.Errorf("expected no root password, got: %v", result.RootPassword)}if len(result.NextActions) != 1 || result.NextActions[0].ID != 2 { t.Errorf("unexpected next actions: %v", result.NextActions)}不確定是否需要一行代碼？注釋掉它以查看哪個測試失敗。有改進功能的想法嗎？需要重構一段代碼？嘗試一下并運行自動測試。你會驚訝于你能從系統的測試中學到多少東西。
原則4：自動化測試應該易于編寫
有些測試從手動測試開始，然后自動完成。但是，這通常會導致過于復雜，緩慢和尷尬的測試。當測試和代碼具有一定的協同作用時，最好的結果就會出現。編寫測試的行為促使開發人員生成更多的模塊化代碼，這反過來又使測試更簡單，更精細。
測試的簡單性很重要，因為為測試編寫測試是不切實際的。代碼也應該易于讀取和寫入。否則，我們就有可能在測試本身中引入失敗，從而導致誤報和片狀。
許多測試框架使用域特定語言 （DSL） 以簡單的英語定義測試。也許最值得注意的例子是小黃瓜測試框架使用的語言Gherkin：
Feature: Is it Friday yet?Everybody wants to know when it's FridayScenario: Sunday isn't Friday Given today is Sunday When I ask whether it's Friday yet Then I should be told "Nope"
總而言之，在編寫測試時堅持一些基礎知識是個好主意：
- 每個測試只寫一個斷言。
- 將代碼與測試分開，即生產代碼不應包含測試。
- 保持測試彼此獨立，因為依賴關系很快就會滾雪球般地變成令人頭痛的混亂。
- 將測試重疊保持在最低限度，即不要測試相同的代碼兩次。
- 不要破壞測試代碼的封裝。不，僅測試外部接口。
原則5：測試應易于運行
如果開發人員需要打開清單才能開始測試運行，則測試的運行頻率不會達到應有的水平。
理想情況下，每次代碼更改時都會運行測試，而無需任何干預。我們在這里很幸運，因為開發人員工具非常復雜。大多數現代IDE可以檢測文件中的更改并自動啟動測試套件，同樣可以通過nodemon，live reload，fswatch或testmon等命令行程序來實現。
說明：VS 代碼在后臺運行測試
為了使測試易于運行，必須滿足一些條件：
- 冪等性：測試不應有副作用。副作用包括寫入文件、保存到數據庫或通常更改數據。開發人員應該能夠安全地運行任意次數的相同測試。
- 確定性：在給定相同輸入的情況下，測試應始終給出相同的結果。當測試需要開發人員無法控制的外部數據（例如日期/時間或來自 API 的響應）時，應使用模擬或存根偽造這些數據。
- 獨立：測試應該彼此獨立，開發人員必須能夠以任何順序運行它們。
- 輕量級：測試必須足夠輕量級，以便在合理的時間內在開發人員的計算機上運行。
- 粒度：開發人員必須能夠逐個運行測試套件。
在開發人員的機器上運行測試只是等式的一部分。測試還必須在持續集成管道中進行。您的 CI/CD 管道充當質量門;它在每次提交時運行測試套件，提供即時反饋，并允許開發人員檢測何時引入故障。
原則6：自動化測試套件需要低維護
最后一個原則是前五個原則的必然結果。也就是說，如果你很好地滿足了其他人，你就可以免費獲得它。盡管如此，這很重要，所以最好把它說出來。
開發人員希望做有創意和有益的工作。自動化使機器能夠處理測試的苦差事。當測試易于編寫且頻繁執行時，將創建正反饋循環。開發人員傾向于欣賞自動化如何使他們的生活更輕松，因此被激勵編寫和維護測試。
當然，需要一些定期維護來保持測試的良好狀態。以下是編寫和維護測試套件的四條建議：
- 編寫足夠多的測試以使其有效（但不是更多）。如果錯誤溜走，則需要更多的測試。相反，如果您發現測試因小更改而中斷，則需要刪除一些測試。
- 選擇適合該情況的最佳測試類型。單元測試快速且以激光為重點，而端到端測試涵蓋 UI，并且更繁重且更全面。遵循測試金字塔的測試套件具有健康的各種測試。
- 保持測試的可靠性。當代碼正確時失敗的測試稱為誤報。有時無緣無故失敗的測試稱為片狀測試。兩者都會在測試套件中引起問題，因為它們是巨大的時間浪費者和挫折感的來源。
- 保持測試速度快。一個緩慢的測試套件將阻礙開發。
結論
那些認為測試成本高昂的人并不完全意識到質量差的代價。單獨來看，錯誤和缺陷對產品價值的影響可能難以衡量，但如果它們得不到解決，它們可能會迅速失控。幸運的是，您可以通過構建和完善自動化測試套件來防止這種情況，從而為出色的開發人員體驗和出色的高質量軟件奠定基礎。?
