Microsoft AZ-400: 測試策略與品質工程 — 學習指南

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

屬於 Microsoft DevOps Engineer Expert AZ-400 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Azure DevOps 中的測試策略與品質工程，旨在透過在整個交付生命週期中提供快速、具確定性的回饋來建立對軟體的信心，同時利用平台原生功能來強制執行品質閘門與可追溯性。有效的策略結合了平衡的測試金字塔、早期且持續的驗證 (TDD/BDD)、管線中穩健的自動化、嚴謹的測試資料管理，以及負載測試、混沌工程、無障礙檢查和強制執行覆蓋率的部署等進階技術。Azure Test Plans、Azure Pipelines、Azure Load Testing 和 Azure Chaos Studio 提供了大規模實施這些實踐所需的工具。

測試策略基礎

一個務實的測試金字塔，以底層快速、低成本的測試和頂層少量高擬真度的測試來降低風險：

單元測試驗證獨立的邏輯，應在測試套件中佔主導地位。目標是快速執行和高確定性。對於大多數產品，關鍵服務的單元測試覆蓋率目標應設定在 70-90% 的範圍內，同時要認識到覆蓋率是一個代理指標，並非品質的保證。
整合測試使用真實的邊界和短暫的相依性來驗證元件間的契約 (例如，資料庫、訊息傳遞、外部服務)。盡可能在容器化或沙箱環境中並行執行它們，並以透過整合層級情境所執行的 30-60% 關鍵程式碼路徑為目標。
端對端 (E2E) 測試驗證跨越整個技術堆疊的使用者旅程。應保持其數量最少，並專注於最高價值的路徑 (通常佔測試套件的 5-15%)，以避免脆弱、緩慢的回饋。

左移測試實踐能更早地減少缺陷：

測試驅動開發 (TDD) 強制執行「紅燈–綠燈–重構」的循環，為設計提供資訊，並提高單元層級的信心。透過為工程師提供快速的本地測試執行器，並保持測試的封閉性與確定性，使 TDD 更具實用性。
行為驅動開發 (BDD) 使用 Gherkin 以共享的詞彙來捕捉意圖。.NET 團隊可以使用 SpecFlow；Java 和 JavaScript 團隊通常使用 Cucumber。將 BDD 情境與 Azure Boards 的驗收標準連結，並將其結果發布到 Azure Test Plans 以實現可追溯性。

測試資料管理可消除不確定性：

合成資料為單元和整合測試提供具確定性、保障隱私安全的資料集。使用特定語言的 faker 函式庫和種子值來生成，以實現可重現性。
資料遮罩能夠在不暴露個人或敏感資訊的情況下，建立真實的測試資料集。使用資料庫遮罩工具或應用不可逆轉換的資料管線。對於 Azure SQL Database，可將快照匯出到一個預備訂閱，並在測試使用前應用遮罩。
環境對等性確保測試結果有意義。使用基礎設施即程式碼 (ARM/Bicep/Terraform) 來佈建測試環境，使系統元件、組態和網路拓撲盡可能與生產環境匹配。保持各環境間的結構描述遷移同步。

不穩定測試的偵測與管理可保護回饋循環：

原因包括時序競爭、外部相依性、測試順序耦合和資源競爭。使用 Azure Pipelines 的 Visual Studio Test 工作並啟用 rerunFailedTests，以在您調查期間減少暫時性的雜訊。
隔離不具確定性的測試以保持管線綠燈，將它們標記並隔離到一個獨立的套件中，該套件會執行並回報，但不會導致建置失敗。使用 Azure Boards 工作項目來追蹤隔離的技術債。
根本原因分析需要檢測。在執行期間擷取日誌、計時指標和環境詳細資訊；使用相同的種子值和相依性在本地重現問題；移除對未被模擬的系統時鐘、網路和檔案系統的依賴；並從源頭修復不確定性。

Azure DevOps 與 Azure 測試能力

Azure Test Plans 提供一流的手動與探索式測試，外加可追溯性：

測試案例定義了步驟、預期結果與參數；共用步驟與參數化測試案例可減少重複。以需求為基礎的套件能將案例對應到產品待辦項目或使用者故事，而靜態與以查詢為基礎的套件則將測試分組以供執行。
測試回合會將套件與組態指派給測試人員、記錄結果與持續時間，並擷取診斷資訊。豐富的錯誤提報功能包括螢幕截圖、影片、環境資料與操作記錄。
探索式測試使用 Test & Feedback 瀏覽器擴充功能，在臨時性的探索過程中擷取章程、工作階段筆記與產出。將發現的項目連結到工作項目，並分析需求與測試工作階段的涵蓋範圍。

自動化測試直接整合到管線中：

使用 Visual Studio Test 工作 (VsTest) 來執行 MSTest、NUnit 與 xUnit 測試，並發布 TRX 結果。對於 .NET，通常使用 dotnet test 搭配適當的記錄器 (trx, junit)。
對於 Java，透過 Maven 或 Gradle 執行 JUnit，並使用 Publish Test Results 工作來發布 JUnit XML。對於 JavaScript，設定執行器 (Jest, Mocha) 以產出 JUnit XML。
Publish Test Results 整合跨回合的結果與趨勢。將結果格式標準化 (TRX 或 JUnit XML) 以統一報告並啟用不穩定測試分析。
將自動化測試回合與 Azure Test Plans 連結，方法是將測試案例對應到自動化測試方法，確保從需求、執行到缺陷的端對端可追溯性。

程式碼涵蓋率是一個可衡量的品質護欄：

使用 Coverlet (用於 .NET)、JaCoCo (Java) 或 Cobertura/lcov (JavaScript) 來收集涵蓋率。轉換為 Azure DevOps 能理解的格式，並透過 Publish Code Coverage Results 發布，以呈現趨勢與差異。
在建置時強制執行最低閾值。對於 .NET，使用 Coverlet 的閾值參數，如果行或分支涵蓋率低於策略，則讓建置失敗。或者，使用 Build Quality Checks 擴充功能來強制執行涵蓋率與基於趨勢的策略。
以涵蓋率為閘門的部署可在品質下降時防止進程。在 YAML 中，如果涵蓋率低於目標，則讓品質階段失敗；對於傳統發行，使用閘門來叫用 Azure Function 或 REST 檢查，以便在升級前驗證測得的涵蓋率。

效能、混沌與韌性

負載與效能測試能及早且持續地驗證非功能性需求：

Azure Load Testing 大規模地協調基於 JMeter 的負載，同時關聯來自 Application Insights 的後端遙測資料。匯入 JMX 測試計畫，設定通過/失敗的標準 (例如：p95 延遲、錯誤率)，並將結果呈現於管線中。當未達到基準時，使用 Azure Monitor 閘門或環境檢查來阻擋進程。
Apache JMeter 仍然是用於協定層級負載測試的多功能選擇。為 CI 將執行緒群組與斷言參數化。將 JMX 與 CSV 資料集與程式碼一同儲存，並與情境一起進行版本控制。
k6 實現了對開發人員友善的「負載測試即程式碼」。透過容器或 Node 執行環境在 Azure Pipelines 中執行 k6，擷取結果，並匯出為 JUnit 或 JSON 以供發布。在 k6 指令碼中使用閾值表達式來確定性地讓回合失敗。
基準線管理至關重要。追蹤每個環境的延遲、吞吐量與資源使用率趨勢。建立 SLO，並確保測試在具代表性的資料量與組態下執行。

混沌工程驗證在故障情況下的韌性：

Azure Chaos Studio 以受控的爆炸半徑與安全措施對 Azure 資源注入故障。實驗類型包括 VM 上的 CPU/記憶體壓力、網路延遲/黑洞、程序終止與服務節流。
先在預備生產環境中執行實驗，並使用 Application Insights 與 Azure Monitor 進行檢測，以擷取失敗模式、錯誤預算與自動復原行為。
韌性驗證將混沌與健康探測及綜合交易結合，以確保使用者關鍵路徑保持可用或優雅地降級。只有在韌性假設被確認且警示行為符合設計時，才進行升級。

無障礙性、合規性與治理

無障礙性與合規性是品質的基礎：

對於面向公眾的體驗，至少要符合 WCAG 2.1 AA 標準。將需求轉化為 Azure Boards 中的驗收標準，並在 Azure Test Plans 中建立專門的無障礙性測試案例。
透過將 axe-core 整合到 UI 測試框架（如 Playwright、Cypress 或 Selenium）中來自動化檢查。當偵測到嚴重違規時，讓建置失敗，並將無障礙性報告發布為管線產出物。
透過手動稽核（鍵盤導覽、螢幕閱讀器支援、動態情境下的色彩對比）來輔助自動化，並使用 Test & Feedback 擴充功能在探索式測試會話中擷取發現。
Azure Pipelines 中的合規性與品質治理使用環境檢查與閘門。對於效能和可用性，在部署前查詢 Azure Monitor 或 Azure Load Testing 以取得基準。對於覆蓋率或無障礙性的把關，可調用一個 function 或 REST 檢查，該檢查會解析已發布的報告並回傳通過/失敗。這強制將非功能性品質作為發布的先決條件，而非事後才考慮。

測試結果的發布與分析形成回饋閉環：

標準化結果格式與覆蓋率報告，以填入 Test Analytics、追蹤通過率趨勢，並自動浮現不穩定的測試 (flaky tests)。
使用建置原則與分支保護，要求在合併前必須有綠色的測試與足夠的覆蓋率。保持快速回饋；平行化測試階段、分片大型測試套件，並快取相依性以縮短週期時間。

實務問題情境

Adobe 正在將一個文件處理平台現代化，改造成 Azure 上的微服務。工程領導團隊要求在沒有回歸問題的情況下加快發布節奏、建立可證明的效能基準、具備對區域性網路故障的韌性，並符合 WCAG 2.1 AA 合規性。目前的管線受到不穩定的 E2E 測試和不一致的測試資料所困擾。

建立測試金字塔與左移實踐

為核心函式庫與服務採用 TDD，以建立一個龐大且具確定性的單元測試基礎，對 .NET 元件使用 NUnit 和 xUnit，對 Java 使用 JUnit。透過 SpecFlow 和 Cucumber 的 BDD 將跨團隊的驗收標準擷取為可執行的規格。這確保了快速回饋與共同的理解。

在 Azure Pipelines 中自動化測試並發布結果

使用 VsTest 執行 .NET 的單元與整合測試，使用 Maven/Gradle 執行 Java 的測試。使用 Publish Test Results 發布測試結果，並用 Publish Code Coverage Results 發布覆蓋率，以集中化報告並啟用不穩定測試分析。內建的任務提供了與 Azure DevOps 的緊密整合，並減少了自訂工具的需求。

強制執行程式碼覆蓋率閾值並把關部署

設定 Coverlet 和 JaCoCo 的閾值，若關鍵服務的程式碼行覆蓋率低於 80% 或分支覆蓋率低於 60%，則讓建置失敗。新增一個發布檢查，該檢查會呼叫一個 Azure Function 來讀取最新的覆蓋率產出物並回傳通過/失敗，從而防止在覆蓋率低於政策時進行部署。這無需人工介入即可將品質閘門正式化。

實施測試資料管理以確保確定性

使用 faker 函式庫為單元與整合測試生成合成資料集。對於系統測試，透過一個使用 Data Factory 的自動化管線來複製 Azure SQL 資料庫的遮罩複本，以應用不可逆的遮罩。使用 Bicep 來佈建環境以確保一致性。這消除了隱私風險和與資料相關的不穩定性。

控制並消除不穩定的測試

在 VsTest 中啟用 rerunFailedTests 以減輕暫時性失敗的影響，並用一個隔離標記來標註不穩定的規格，將它們從阻擋性套件中排除，但仍會執行和報告。為每個被隔離的測試建立 Azure Boards 工作項目。透過收集時間與網路日誌並移除非確定性的等待來進行根本原因分析。這在推動永久性修復的同時，保持了管線的可靠性。

使用 Azure Load Testing 與 k6 驗證效能

將關鍵使用者旅程模型化為 JMeter 計畫，並在部署到預備環境 (staging) 後於 Azure Load Testing 中執行，並設定 p95 延遲與錯誤率的通過/失敗標準。對於 API 層級的開發者測試，在 CI 中使用內建閾值執行 k6 腳本。新增一個 Azure Monitor 閘門，如果預備環境的基準未被滿足，則阻止部署到生產環境。這些工具提供了與 Q&A 的閘門概念一致的可擴展、可衡量的效能強制執行。

使用 Azure Chaos Studio 證明韌性

設計實驗，在預備環境中對選定的微服務注入網路延遲和 CPU 壓力，同時由 Application Insights 追蹤錯誤預算與恢復情況。要求所有韌性實驗在晉升到下一個環境前都必須滿足 SLO。Chaos Studio 的治理控制符合 Adobe 對於受控爆炸半徑與可稽核實驗的需求。

確保無障礙性與合規性

將 axe-core 整合到 Playwright UI 測試中，以自動偵測核心畫面上違反 WCAG 2.1 AA 的問題。將違規報告發布為建置產出物，並在出現嚴重問題時讓建置失敗。使用 Azure Test Plans 和 Test & Feedback 擴充功能安排探索式無障礙測試會話，以進行手動驗證。這結合了自動化覆蓋與以人為本的檢查。