什麼是自動化測試？
在此單元中，您將了解自動化測試的優點，以及您可以執行的測試類型。 您也會學到什麼是良好的測試，並引進可供您使用的一些測試工具。
什麼是自動化測試？
自動化測試會使用軟體來執行您的程式碼，並將實際結果與您預期的結果相比較。 將此與探勘測試或手動測試進行比較，後者通常會由使用者遵循測試方案中的指示，驗證軟體是否如預期般運作。
手動測試有其優點。 但隨著程式碼基底大小的成長，手動測試所有功能 (包括邊緣案例) 可能會變得重複性高又冗長乏味，而且容易發生錯誤。 自動化測試有助於消除此部分負擔，並使手動測試人員能夠專注於其最擅長的工作：確保您的使用者對您的軟體有正面的體驗。
測試金字塔
在考慮自動化測試時，將測試分成幾層十分常見。 Mike Cohn 在他的著作 Succeeding with Agile 中，提出這個稱為測試金字塔的概念。
雖然這是 Cohn 模型的簡化版本，但此概念說明您大部分的工作都是在撰寫測試，其驗證您軟體的基礎層級 (金字塔中的標註 1)，例如函數、類別和方法。 隨著功能的組合，您漸漸會投注較少的心力，例如在使用者介面 (UI) 層 (金字塔中的標註 2)。 其概念是，如果您可以確認每個較低層級的元件各自如預期般運作，則較高層級的測試只需要確認多個元件是否一起運作以獲得預期的結果。
我什麼時候應該撰寫測試？
答案主要取決於您在撰寫測試方面的需求與經驗。
針對您已經撰寫並部署的程式碼開始加入測試，永遠不嫌遲。 這特別適用於經常毀壞或需要測試團隊付出最大努力的功能。
當測試涉及持續整合和持續傳遞管線時，您將聽到的兩個概念是連續測試和儘早測試。
連續測試指的是測試會在開發程序的早期階段執行，因為每次變更都會在管線中進行。 儘早測試指的是在開發程序考慮軟體品質並提早測試。
例如，開發人員通常會在開發其功能時新增測試案例，並在將變更提交到管線之前，執行整個測試套件。 這有助於確保其所建置的功能如預期般運作，而且也不會中斷現有的功能。
以下是 Microsoft 雲端大使 Abel Wang 的短片，說明如何確保您在 DevOps 方案中維持品質。
詢問 Abel
儘早測試通常也會要求測試人員在撰寫任何功能的程式碼之前，參與設計過程。 將這個項目與「遞交」模型進行比較後，測試小組只會在設計和撰寫軟體之後，才會顯示新功能。 在程序後期探索到的錯誤 (bug) 可能會影響小組的傳遞排程，而錯誤 (bug) 可能會在開發人員最初建置此功能後的數週甚至數月才發現。
取捨
使用自動化測試需要進行取捨。 雖然自動化測試可讓測試人員能夠集中時間來驗證最終使用者體驗，但開發人員可能需要投注更多時間來撰寫和維護其測試程式碼。
不過，自動化測試的重點是協助確保測試人員只會收到最高品質的程式碼，已經過證實的程式碼會如預期般運作。 因此，開發人員可能會因為最初沒有考慮到邊緣情況，而不必處理許多錯誤 (bug) 也不需要重新撰寫其程式碼，藉此獲得一些時間。
附加優點
文件以及能夠更輕鬆地重構程式碼是自動化測試的兩個附加優點。
文件
手動測試方案可以作為一種文件，說明軟體應該如何運作，以及某些功能存在的原因。
自動化測試可以具有相同用途。 自動化測試程式碼通常會使用人類看得懂的格式。 您提供的一組輸入代表使用者可能會輸入的值。 每個相關聯的輸出都會指定您的使用者應該預期的結果。
事實上，許多開發人員都會在實作新功能「之前」，依照「測試導向開發」(TDD) (撰寫其測試程式碼的方法) 進行。 其概念是編寫一組通常稱為「規格」的測試，而且此測試一開始會失敗。 之後，開發人員會逐步撰寫程式碼來實作功能，直到通過所有測試為止。 規格不僅可記載需求，而且 TDD 程序還有助於確保只撰寫所需數量的程式碼來實作該功能。
重構
假設您有一個您想要重構的大型程式碼基底，讓特定部分執行地更快。 您如何知道您的重構工作不會導致部分應用程式毀壞？
自動化測試可作為合約類型。 也就是說，您可以指定輸入和預期的結果。 當您有一組通過測試時，最好能夠實驗並重構程式碼。 當您進行變更時，您只需要執行您的測試，並確認會繼續通過這些測試。 一旦您達到重構目標之後，您就可以提交您對組建管線的變更，讓每個人都能夠獲益，但是中斷的風險較低。
自動化測試有哪些類型？
自動化測試有許多種類型。 每個測試都可以作為個別的用途。 例如，您可能會執行安全性測試，以協助確認只有獲授權的使用者可以存取軟體片段或其中一個功能。
說到持續整合與組建管線，我們通常指的是「開發測試」。 開發測試是指您將應用程式部署至測試或生產環境之前，您可以執行的測試。
例如，「lint 測試」是一種形式的靜態程式碼分析，可檢查您的原始程式碼以確定是否符合您小組的樣式指南。 以一致的方式設定格式的程式碼更易於每個人讀取及維護。
在本課程模組中，您將使用單元測試和程式碼涵蓋範圍測試。
單元測試會驗證程式或程式庫最基本的元件，例如個別的函式或方法。 您可以指定一或多個輸入，以及預期的結果。 測試執行器會執行每個測試，並檢查實際與預期的結果是否相符。
例如，假設您有一個函式可執行包括除法的算術運算。 您可以指定一些您預期使用者輸入的值，以及邊緣案例的值，例如 0 和 -1。 如果特定的輸入產生錯誤或例外狀況，則您可以驗證函數會產生相同的錯誤。
程式碼涵蓋範圍測試會計算單元測試所涵蓋程式碼的百分比。 程式碼涵蓋範圍測試可以在您的程式碼中包含條件式分支，以確保涵蓋函數。
您的程式碼涵蓋範圍百分比越大，您就可以越有信心以後不會在程式碼中發現未經過完整測試的錯誤。 您不需要達到 100% 程式碼涵蓋範圍。 事實上，當您開始時，可能會發現您的百分比不高，但是，這可為您提供起點，讓您可以從該處新增可涵蓋有問題或常用程式碼的其他測試。
將單元測試保留隔離狀態
當您正在學習單元測試時，可能會聽到「模擬」、「虛設常式」和「相依性插入」這類字詞。
請記住，單元測試應該驗證個別的函數或方法，而不是多個元件如何互動。 但是，如果您有會呼叫資料庫或網頁伺服器的函數，則該怎麼加以處理？
該函式不只會對外部服務中斷隔離進行呼叫，還會減緩速度。 如果資料庫或網頁伺服器當機，或無法使用時，也可能會導致您的測試回合中斷。
模擬和相依性插入這類技巧可讓您建立模擬此外部功能的元件。 您稍後將會在本課程模組中取得範例。
之後，您可以執行「整合測試」來驗證您的應用程式是否能與實際的資料庫或網頁伺服器一起正確運作。
什麼是好的測試？
當您獲得撰寫自己的測試以及閱讀其他人所撰寫測試的體驗時，將能夠確定這是一個好的測試。 以下是開始使用的一些指導方針：
- 請不要為了測試而進行測試：您的測試目的不應該只是劃掉檢查清單項目。 撰寫測試來驗證您的重要程式碼如預期般運作，而且不會毀壞現有的功能。
- 讓測試保持簡短：測試應該儘快完成，特別是在開發和建置階段期間進行的測試。 如果測試在每個變更於管線中移動時執行，則您不會希望測試成為瓶頸。
- 確認測試為可重複：測試回合每次都應該產生相同的結果，不論您是在您的電腦上、您同事的電腦上還是組建管線中執行。
- 讓測試保持聚焦：一個常見的誤解是測試應該涵蓋其他人所撰寫的程式碼。 一般而言，您的測試應該只涵蓋您的程式碼。 例如，如果您在專案中使用開放原始碼圖庫，則不需測試該圖庫。
- 選取適當細微性：例如，如果您正在執行單元測試，則個別的測試不應該合併或測試多個函數或方法。 個別測試每個函式，並於稍後撰寫「整合測試」來驗證多個元件可正確地進行互動。
有哪些種類的測試工具可供使用？
您使用的測試工具取決於您要建置的應用程式類型和您要執行的測試類型。 例如，您可以使用 Selenium，在多種網頁瀏覽器與作業系統上執行 UI 測試。
無論您的應用程式是以何種語言所撰寫，都會有許多測試工具可供您使用。
例如，針對 Java 應用程式，您可以選擇 Checkstyle 來執行 lint 測試，以及選擇 JUnit 來執行單元測試。
在本課程模組中，我們將會使用 NUnit 進行單元測試，因為它在 .NET 社群中很受歡迎。