何謂功能測試？
在本節中，您會加入 Tailspin 小組，因為它們會定義其管線的「功能測試」。 功能測試會驗證軟體的每個功能是否正常運作。
小組會先定義功能測試涵蓋的內容。 他們會探索某些類型的功能測試。 然後，他們會決定要新增至管線的第一個測試。
每週會議
小組正在舉行每週會議。 Andy 正在示範發行管線。 小組會監看成功的組建通過管線，從一個階段到另一個階段。 最後，Web 應用程式會升階至「預備」。
Amita：我很高興使用管線。 其讓我的生活變得更輕鬆。 一方面，我會自動使發行部署至「測試」環境。 這表示我不必在測試伺服器上手動下載並安裝組建成品。 這可節省大量時間。
此外，Mara 和 Andy 撰寫的單元測試會在取得發行之前，先消除所有迴歸錯誤。 這會移除挫折感的主要來源。 我不會花時間尋找和記錄迴歸錯誤。
但是我擔心我的所有測試仍需手動執行。 過程很慢，而且直到完成前，我們都無法顯示任何要管理的項目。 這很難，因為測試很重要。 測試可確保使用者獲得正確的體驗。 但壓力是更快地交付。
Andy：我確定我們可以協助您。 哪種測試佔用您的大部分時間？
Amita：我認為是 UI 測試。 我必須逐一按一下每個步驟，以確定得到的是正確的結果，而且必須針對我們支援的每個瀏覽器執行此動作。 這非常耗時。 隨著網站越來越複雜，UI 測試終究不切實際。
Mara：UI 測試被視為「功能」測試。
Tim：相較下，「非功能」測試呢？
Mara：當然。 非功能測試則是您特別重視的測試。
Tim：好吧，我不太明白。
何謂功能測試和非功能測試？
Mara：「功能測試」會驗證軟體的每個功能是否做其應做的事情。 在這些測試中，軟體如何實作每個功能不重要。 重要的是軟體可正常運作。 您會提供輸入，並檢查輸出是否如您預期。 這就是 Amita 測試 UI 的方式。 例如，如果選取排行榜上的頂級玩家，她希望看到該玩家的設定檔。
「非功能測試」會檢查效能和可靠性等特性。 非功能測試的範例是確認有多少人可以同時登入應用程式。 負載測試是非功能測試的另一個範例。 這些效能和可靠性問題是你重視的事情，Tim。
Tim：沒錯。 我需要考慮一下這一點。 我可能也想要為管線新增一些自動化程序，但我不確定我要做什麼。 我可以執行哪些種類的自動化測試？
Mara：目前，讓我們將專注於功能測試。 這是 Amita 所執行的測試種類。 這聽起來好像是我們想要改進的領域。
我可以執行哪些種類的功能測試？
有多種功能測試。 具體取決於您需要測試的功能，以及執行它們通常所需的時間或投入量。
下列各節會提供一些常用的功能測試。
煙霧測試
「煙霧測試」會驗證應用程式或服務的最基本功能。 這些測試通常會在更完整且詳盡的測試之前執行。 煙霧測試應快速地執行。
例如，假設您正在開發網站。 您的煙霧測試可能會使用 curl 來驗證網站是否可連線，以及擷取首頁是否會產生 200 (OK) HTTP 狀態。 如果擷取首頁產生另一個狀態碼，例如 404 (找不到) 或 500 (內部伺服器錯誤)，則您知道網站無法運作。 您也知道沒有必要執行其他測試。 相反地，您會診斷錯誤、加以修正，然後重新啟動測試。
單元測試
您已使用了使用 Azure Pipelines 在組建管線中執行品質測試課程模組中的單元測試。
簡言之，「單元測試」會驗證程式或程式庫最基本的元件，例如個別的函式或方法。 您可以指定一或多個輸入，以及預期的結果。 測試執行器會執行每個測試，並查看實際結果是否符合預期的結果。
例如，假設您有一個函式可執行包括除法的算術運算。 您可以指定一些預期使用者會輸入的值。 您也可以指定邊緣案例值，例如 0 和 -1。 如果預期特定輸入產生錯誤或例外狀況，則您可以驗證函式是否產生該錯誤。
您稍後將在此課程模組中執行的 UI 測試為單元測試。
整合測試
「整合測試」會驗證多個軟體元件是否會一起運作，以形成完整的系統。 例如，電子商務系統可能包括網站、產品資料庫，以及付款系統。 您可以撰寫將商品新增至購物車，然後購買這些商品的整合測試。 測試會驗證 Web 應用程式能否連線到產品資料庫，然後履行訂單。
您可以結合單元測試和整合測試，以建立多層式測試策略。 例如，您可以在執行整合測試之前，在每個元件上執行單元測試。 如果所有單元測試都通過，您就可以更有信心地開始進行整合測試。
迴歸測試
當現有的行為在您新增或變更功能之後變更或中斷時，就會發生「迴歸」。 「迴歸測試」可協助判斷程式碼、組態或其他變更是否會影響軟體的整體行為。
迴歸測試很重要，因為某個元件的變更可能會影響另一個元件的行為。 例如，假設您在最佳化資料庫以提高寫入效能。 該資料庫由另一個元件處理的讀取效能可能會意外下降。 讀取效能的下降就是迴歸。
您可以使用各種策略來測試迴歸。 這些策略通常會因您所執行的測試數目而異，而這些測試會確認新功能或錯誤修正不會中斷現有的功能。 但是，當您將測試自動化時，迴歸測試可能涉及只需要在每次軟體變更時，執行所有單元測試和整合測試。
健全性測試
「健全性測試」涉及測試一個軟體的每個主要元件，以確認軟體似乎正常運作，並可進行更徹底的測試。 您可能會認為健全性測試不如迴歸測試或單元測試徹底，但健全性測試的範圍比煙霧測試更廣。
雖然健全性測試可以自動執行，但通常是針對功能變更或錯誤修正手動執行。 例如，正在驗證錯誤修正的軟體測試人員也可以輸入一些一般值，來驗證其他功能是否可以運作。 如果軟體似乎如預期般運作，則其可以通過更徹底的測試。
使用者介面測試
「使用者介面 (UI) 測試」會驗證應用程式使用者介面的行為。 UI 測試可協助驗證使用者互動的「序列」(或順序) 是否產生預期的結果。 這些測試也可協助驗證輸入裝置 (例如鍵盤或滑鼠) 是否會適當地影響使用者介面。 您可以執行 UI 測試，以驗證原生 Windows、macOS 或 Linux 應用程式的行為。 或者，您可以使用 UI 測試，來驗證 UI 在整個網頁瀏覽器中的行為是否符合預期。
單元測試或整合測試可能會驗證 UI 是否正確地「接收」資料。 但是，UI 測試可協助驗證使用者介面是否正確地「顯示」，以及結果是否如使用者預期般運作。
例如，UI 測試可能會驗證正確的動畫是否出現，以回應按鈕的點擊。 第二個測試可能會在調整視窗大小時，驗證相同的動畫是否正確出現。
在本課程模組中，您會使用手動編碼的 UI 測試。 但是，您也可以使用「捕捉並重新播放」系統來自動組建 UI 測試。
可用性測試
「可用性測試」是一種手動測試的形式，其會從使用者的觀點驗證應用程式的行為。 可用性測試通常是由組建軟體的小組執行。
雖然 UI 測試著重於功能是否如預期般運作，但是可用性測試可協助驗證軟體是否直觀易用，並符合使用者的需求。 換句話說，可用性測試可協助驗證軟體是否「好用」。
例如，假設您有一個網站，其中包含使用者設定檔的連結。 UI 測試可以驗證連結是否存在，並在按一下連結時，是否顯示使用者的設定檔。 但是，如果人們無法輕易找到此連結，則可能會在嘗試存取其設定檔時感到沮喪。
使用者接受度測試
從使用者的觀點來看，「使用者驗收測試 (UAT)」(例如可用性測試) 著重於應用程式的行為。 和可用性測試不同的是，UAT 通常是由實際終端使用者執行。
視軟體而定，可能會要求終端使用者完成特定的工作。 或者，允許他們可在不遵循特定指導方針的情況下探索軟體。 若是自訂軟體，UAT 通常直接在用戶端上進行。 若是更一般用途的軟體，小組可能會執行 Beta 測試。 在技術預覽版測試中，來自不同地理區域的使用者或具有特定興趣的使用者，都能提早存取軟體。
測試人員的意見反應包括直接或間接兩種。 直接意見反應可能採用口頭評論的形式。 間接意見反應可能是以下列形式：測量測試人員的肢體語言、眼睛移動，或完成特定工作所花費的時間。
我們已介紹了撰寫測試的重要性。 不過為了強調重要性，可參照下列 Microsoft 雲端大使 Abel Wang 的短片，了解如何在 DevOps 計劃中協助確保維持品質。
詢問 Abel
小組的選擇為何？
Tim：所有這些測試聽起來都很重要。 我們應該首先進行哪個測試？
Andy：我們已有運作中的單元測試。 我們尚未準備好執行使用者驗收測試。 根據我所聽到的內容，我認為應該專注於 UI 測試。 目前，這是我們流程中最慢的部分。 Amita，您是否同意？
Amita：是的，我同意。 我們在這次會議中還留下一些時間。 Andy 或 Mara，您想要協助我規劃自動化 UI 測試嗎？
Mara：當然可以。 但是，讓我們先做一些準備工作。 我想要討論我們應該使用的工具，以及我們將如何執行測試。
我可以使用哪些工具來撰寫 UI 測試？
Mara：撰寫 UI 測試時，我們有哪些選項？ 我知道有很多選項。 部分工具是開放原始碼。 其他工具則提供付費的商業支援。 以下是我想到的一些選項：
- Windows Application Driver (WinAppDriver)：WinAppDriver 可協助您將 Windows 應用程式上的 UI 測試自動化。 這些應用程式可以通用 Windows 平台 (UWP) 或 Windows Forms (WinForms) 撰寫。 我們需要可在瀏覽器中運作的解決方案。
- Selenium：Selenium 是適用於 Web 應用程式的可攜式開放原始碼軟體測試架構。 其會在大部分的作業系統上執行，並支援所有新式瀏覽器。 您可以採用數種程式設計語言 (包括 C#) 撰寫 Selenium 測試。 事實上，您可以使用 NuGet 套件，輕鬆地以 NUnit 測試的形式執行 Selenium。 我們已使用 NUnit 進行單元測試。
- SpecFlow：SpecFlow 適用 .NET 專案。 其是由稱為 Cucumber 的工具所啟發。 SpecFlow 和 Cucumber 都支援行為驅動開發 (BDD)。 BDD 會使用稱為 Gherkin 的自然語言剖析器，協助技術小組和非技術小組定義商業規則和需求。 您可以結合 SpecFlow 或 Cucumber 與 Selenium 來組建 UI 測試。
Andy 看向 Amita。
Andy：我知道這些選項對您來說是新的，所以您介意我們挑選 Selenium 嗎？ 我有一些使用 Selenium 的體驗，並且其支援我已知道的語言。 Selenium 也可讓我們自動支援多個瀏覽器。
Amita：當然。 如果我們有人具備一些經驗，那會更好。
如何在管線中執行功能測試？
在 Azure Pipelines 中，您可以執行功能測試，就像執行任何其他流程或測試一樣。 詢問自己：
- 測試會在哪個階段中執行？
- 測試會在哪個系統上執行？ 測試是否會在代理程式或裝載應用程式的基礎結構上執行？
讓我們加入小組，因為他們會回答這些問題。
Mara： 我很高興的是，現在我們可以在類似生產的環境中進行測試，而應用程式實際上是在此環境中執行。 在這種脈絡下，像 UI 測試這樣的功能測試是有意義的。 我們可以在管線的「測試」階段中執行它們。
Amita：我同意。 如果我們在執行手動測試的同一階段中執行自動化 UI 測試，則可以維持相同的工作流程。 自動化測試可節省我們的時間，並讓我專注於可用性。
Tim：Amita 會從她的 Windows 膝上型電腦測試網站，因為這是大部分使用者造訪網站的方式。 但是，我們會在 Linux 上進行組建，然後部署 Linux 上的 Azure App Service。 您要如何處理該情況？
Mara：很棒的問題。 我們也可以選擇要在何處執行測試。 我們可以在下列位置執行測試：
- 在代理程式上：Microsoft 代理程式或我們裝載的代理程式
- 在測試基礎結構上：內部部署或在雲端中
我們現有的「測試」階段包含一個作業。 該作業會從 Linux 代理程式將網站部署至 App Service。 我們可以新增第二個作業，從 Windows 代理程式執行 UI 測試。 Microsoft 裝載的 Windows 代理程式已設定為執行 Selenium 測試。
Andy：再次，讓我們堅持我們所知道的。 讓我們使用 Microsoft 裝載的 Windows 代理程式。 稍後，如果需要額外的測試涵蓋範圍，我們可以從執行 macOS 和 Linux 的代理程式執行相同的測試。
方案
Mara：好的。 以下是所要執行的步驟：
- 從 Microsoft 裝載的 Windows 代理程式執行 Selenium UI 測試
- 在「測試」階段中，讓測試從 App Service 上執行的應用程式擷取 Web 內容
- 在所有支援的瀏覽器上執行測試
Andy：我將與 Amita 合作處理此問題。 Amita，讓我們明天早上見個面。 我想要在我們見面之前先研究一下。
Amita：很好！ 到時候見。
建立功能測試計劃
我們看到小組決定如何實作其第一個功能測試。 如果您的小組只是開始將功能測試併入其管線中 (或即使您已這樣做)，請記住，您一律需要一個計劃。
當有人詢問小組成員有關其效能測試計劃時，他們往往會用即將使用的工具清單作為回應。 然而，工具清單並不是計劃。 您也必須設想如何設定測試環境。 您需要決定要使用的流程，並判斷成功或失敗的要素。
請確定您的計劃：
- 將企業的期望列入考慮。
- 將目標使用者的期望列入考慮。
- 定義您將使用的計量。
- 定義您將使用的 KPI。
從一開始，效能測試需要是您規劃的一部分。 如果使用故事或工作流程看板，您可以考慮在其附近設置一個區域，以便在其中規劃測試策略。 作為反覆項目計劃的一部分，應該特別強調測試策略中的落差。 同時請務必在應用程式部署後設想如何監視效能，而不僅僅是在發行之前測量效能。