需求可追蹤性
Azure DevOps Services |Azure DevOps Server 2022 - Azure DevOps Server 2019 |TFS 2018
需求可追蹤 性是能夠關聯並記錄開發程式的兩個或多個階段,然後可以從其原點往前或向後追蹤。 需求可追蹤性可協助小組深入瞭解指標 ,例如需求品質 或 寄送需求的整備程度。 需求可追蹤性的基本層面是與測試案例、Bug 和程式碼變更的需求關聯。
閱讀 詞彙 以瞭解測試報告術語。
注意
在 Microsoft Team Foundation Server (TFS) 2018 和舊版中,組建和發行管線稱為定義、執行稱為組建、服務連線稱為服務端點、階段稱為環境,而作業稱為階段。
執行自動化測試的敏捷式小組
敏捷式小組具有特性,包括但不限於下列各項
- 更快速的發行週期
- 管線中的持續測試
- 可忽略手動測試使用量;僅限於探勘測試
- 高度自動化
下列各節會從敏捷式小組 的品質、 Bug 和 來源 觀點探索可追蹤性。
品質可追蹤性
為了確保使用者需求符合品質目標,專案中的需求可以連結至測試結果,然後可在小組的儀表板上檢視。 這可讓您使用簡單的方法來監視測試結果的端對端追蹤性。 若要連結自動化測試與需求,請流覽組建或發行中的 測試報告 。
在組建或發行摘要的 [ 測試 ] 索引標籤下的結果區段中,選取要連結至需求的測試 () ,然後選擇 [ 連結]。
選擇要以其中一個指定方式連結至所選測試的工作專案, (s) :
- 從建議的工作專案清單中選擇適用的工作專案。 此清單是以最近檢視和更新的工作專案為基礎。
- 指定工作專案識別碼。
- 根據標題文字搜尋工作專案。
此清單只會顯示屬於 [需求] 類別的工作專案。
在需求連結至測試結果之後,您可以檢視依需求分組的測試結果。 需求是提供的許多「分組依據」選項之一,可讓您輕鬆地流覽測試結果。
Teams 通常會想要釘選儀表板需求可追蹤性的摘要檢視。 請使用此需求 品質 小工具。
使用必要選項設定 需求品質 小工具並加以儲存。
- 需求查詢:選取可擷取需求的工作專案查詢,例如目前反復專案中的使用者劇本。
- 品質資料:指定應追蹤需求品質的管線階段。
在小組儀表板中檢視小工具。 它會列出範圍中的所有 需求 ,以及測試 的通過率 和失敗測試計數。 選取 [失敗 的測試計數] 會開啟所選組建或發行的 [ 測試 ] 索引標籤。 小工具也有助於追蹤需求,而不需要任何相關聯的測試 () 。
為了確保使用者需求符合品質目標,專案中的需求可以連結至測試結果,然後可在小組的儀表板上檢視。 這可讓您使用簡單的方法來監視測試結果的端對端追蹤性。 若要連結自動化測試與需求,請流覽組建或發行中的 測試報告 。
在組建或發行摘要的 [ 測試 ] 索引標籤下的結果區段中,選取要連結至需求的測試 () ,然後選擇 [ 連結]。
選擇要以其中一個指定方式連結至所選測試的工作專案, (s) :
- 從建議的工作專案清單中選擇適用的工作專案。 此清單是以最近檢視和更新的工作專案為基礎。
- 指定工作專案識別碼。
- 根據標題文字搜尋工作專案。
此清單只會顯示屬於 [需求] 類別的工作專案。
Teams 通常會想要釘選儀表板需求可追蹤性的摘要檢視。 請使用此需求 品質 小工具。
使用必要選項設定 需求品質 小工具並加以儲存。
- 需求查詢:選取可擷取需求的工作專案查詢,例如目前反復專案中的使用者劇本。
- 品質資料:指定應追蹤需求品質的管線階段。
在小組儀表板中檢視小工具。 它會列出範圍中的所有 需求 ,以及測試 的通過率 和失敗測試計數。 選取 [失敗 的測試計數] 會開啟所選組建或發行的 [ 測試 ] 索引標籤。 小工具也有助於追蹤需求,而不需要任何相關聯的測試 () 。
Bug 可追蹤性
測試可測量將變更寄送給使用者的信賴度。 測試失敗表示變更發生問題。 失敗的原因有很多,例如測試來源中的錯誤、不正確的測試程式碼、環境變數、 Flaky 測試等等。 Bug 提供健全的方式來追蹤測試失敗,並在小組中推動責任,以採取必要的補救動作。 若要將 Bug 與測試結果產生關聯,請流覽組建或發行中的 測試報告 。
在 [ 測試 ] 索引標籤的結果區段中,選取應該建立 Bug 的測試,然後選擇 [ Bug]。 多個測試結果可以對應至單一 Bug。 這通常是當失敗的原因與單一原因有關時,例如相依服務無法使用、資料庫連線失敗或類似的問題。
開啟工作專案以查看 Bug。 它會擷取測試結果的完整內容,包括錯誤訊息、堆疊追蹤、批註等重要資訊。
在 [ 測試 ] 索引標籤內,直接在內容中檢視測試結果的錯誤。[ 工作專案 ] 索引標籤也會列出測試結果的任何連結需求。
從工作專案,直接流覽至相關聯的測試結果。 測試案例和特定測試結果都會連結到 Bug。
在工作專案中,選取 [ 測試案例 ] 或 [測試結果 ],直接移至所選組建或發行的 [ 測試 ] 頁面。 您可以針對失敗進行疑難排解、更新 Bug 中的分析,以及視需要進行變更來修正問題。 雖然這兩個連結都會帶您前往 [ 測試] 索引標籤,但顯示的預設區段分別為 [歷程記錄 ] 和 [ 偵錯 ]。
來源可追蹤性
針對在一段時間內持續發生的測試失敗進行疑難排解時,請務必回溯到初始變更集,其中發生失敗。 這有助於大幅縮小範圍,以找出有問題的測試或受測來源。 若要探勘測試失敗的第一個實例,並將其追蹤回相關聯的程式碼變更,請流覽組建或發行中的 [測試 ] 索引標籤。
在 [ 測試 ] 索引標籤中,選取要分析的測試失敗。 根據它是組建或發行,選擇測試的 [失敗組建 ] 或 [ 失敗發行 ] 資料行。
這會在新視窗中開啟 [ 測試 ] 索引標籤的另一個實例,其中顯示測試的第一個連續失敗實例。
根據組建或發行管線,您可以選擇時程表或管線檢視,以查看已認可的程式碼變更。 您可以分析程式碼變更,以識別測試失敗的潛在根本原因。
使用計劃性測試的傳統小組
從手動測試移至連續 (自動化) 測試的小組,且已自動化測試子集,可以在管線中或視需要執行這些測試, (查看 測試報告) 。 稱為計劃性測試,自動化測試可以與測試計劃中的測試案例相關聯,並從Azure Test Plans執行。 一旦相關聯,這些測試就會參與對應需求的品質計量。
說明及支援
- 請參閱我們的 疑難排解 頁面
- 取得Stack Overflow的建議,並透過開發人員社群取得支援