STLC 快速指南

---

---

STLC - 概述

STLC 代表軟體測試生命週期 (Software Testing Life Cycle)。STLC 是一系列由測試團隊執行的不同活動，以確保軟體或產品的質量。

• STLC 是軟體開發生命週期 (SDLC) 的組成部分。但是，STLC 只處理測試階段。

• STLC 在需求定義或利益相關者共享軟體需求文件 (SRD) 後立即開始。

• STLC 提供一個逐步的過程來確保軟體質量。

• 在 STLC 的早期階段，當軟體或產品正在開發時，測試人員可以分析和定義測試範圍、准入和準出標準以及測試用例。這有助於縮短測試周期時間並提高質量。

• 一旦開發階段結束，測試人員準備好測試用例並開始執行。這有助於在初始階段發現錯誤。

STLC 階段

STLC 包含以下不同的階段，但並非必須遵循所有階段。階段取決於軟體或產品的性質、分配給測試的時間和資源以及要遵循的 SDLC 模型。

STLC 有 6 個主要階段：

• 需求分析 - 當 SRD 準備好並與利益相關者共享時，測試團隊開始對被測應用 (AUT) 進行高級別分析。

• 測試計劃 - 測試團隊計劃策略和方法。

• 測試用例設計 - 根據範圍和標準開發測試用例。

• 測試環境搭建 - 整合環境準備好驗證產品時。

• 測試執行 - 產品的即時驗證和錯誤查詢。

• 測試結束 - 測試完成後，文件化矩陣、報告和結果。

比較 - STLC 和 SDLC

本章，我們將瞭解 STLC 和 SDLC 之間比較的因素。讓我們考慮以下幾點，從而比較 STLC 和 SDLC。

• STLC 是 SDLC 的一部分。可以說 STLC 是 SDLC 集的子集。

• STLC 僅限於確保軟體或產品質量的測試階段。SDLC 在軟體或產品的完整開發中發揮著巨大而重要的作用。

• 但是，STLC 是 SDLC 中非常重要的階段，在經過 STLC 流程之前，最終產品或軟體無法釋出。

• STLC 也是釋出後/更新週期（SDLC 的維護階段）的一部分，已知缺陷在此階段得到修復，或向軟體新增新功能。

下表列出了基於其階段的 SDLC 和 STLC 之間比較的因素：

STLC - 測試基本原則

測試的共同目標是儘早發現錯誤。並且，一旦錯誤被修復，確保它按預期工作並且不會破壞任何其他功能。

為了實現這些目標，給出了軟體測試的七個基本原則：

測試能顯示什麼？

測試可以顯示存在缺陷，但無法證明產品中沒有缺陷。測試階段確保被測應用程式根據給定的要求工作，並且有助於降低應用程式中未發現缺陷的可能性。但是，即使沒有發現缺陷，也不意味著它是完全正確的。我們可以假設 AUT 符合我們的退出標準並根據 SRD 維護需求。

是否可以進行詳盡測試？

除了瑣碎的情況外，不可能實現 100% 的覆蓋率或對所有輸入組合和可能組合進行測試。代替詳盡測試，使用風險分析和優先順序來定義測試範圍。在這裡，可以考慮包含大多數即時場景，包括最可能的負面場景。這將有助於我們跟蹤故障。

儘早測試

測試活動應儘早開始，並應關注測試策略和預期結果中定義的目標。測試的早期階段有助於識別需求缺陷或設計級別的差異。如果在初始階段捕獲到這些型別的錯誤，這將有助於我們節省時間，而且成本效益也更高。儘早開始測試的原因很簡單——一旦收到 SRD，測試人員就可以從測試的角度分析需求，並可以注意到需求差異。

缺陷聚集

根據以前的產品缺陷分析，可以說大多數缺陷是從對應用程式至關重要的一小部分模組中識別的。可以根據複雜性、不同的系統互動或對其他不同模組的依賴性來識別這些模組。如果測試人員可以識別這些關鍵模組，他們可以更關注這些模組以識別所有可能的錯誤。在一項研究中發現，80% 的缺陷是從 AUT 的 20% 的功能中識別的。

殺蟲劑悖論

什麼是殺蟲劑悖論——如果經常在農作物上使用殺蟲劑，就會出現昆蟲產生某種抗藥性，並且逐漸噴灑的殺蟲劑對昆蟲似乎無效的情況。

同樣的概念也適用於測試。這裡，昆蟲是錯誤，而殺蟲劑是反覆使用的測試用例。如果反覆執行相同的測試用例集，這些測試用例在一段時間後會變得無效，並且測試人員將無法識別任何新的缺陷。

為了克服這些情況，應不時地檢查和審查測試用例，並且可以新增新的和不同的測試用例。這將有助於識別新的缺陷。

測試依賴於上下文

此原則指出，除非兩個應用程式的性質相同，否則不能使用相同的方法來測試兩種不同型別的應用程式。例如，如果測試人員對基於 Web 的應用程式和移動應用程式使用相同的方法，這是完全錯誤的，並且存在產品釋出質量較差的高風險。測試人員應針對不同型別和性質的應用程式使用不同的方法、方法、技術和覆蓋範圍。

無錯誤謬論

此原則指出，查詢缺陷並修復它們直到應用程式或系統穩定，既費時又會消耗資源。即使修復了 99% 的缺陷，應用程式仍然存在不穩定的高風險。首先要驗證應用程式的穩定性和環境的先決條件。如果這兩個條件滿足，只有這樣我們才能開始詳細測試。

STLC - 需求分析

需求分析是 STLC 的第一個階段，它在 SRD/SRS 與測試團隊共享後立即開始。讓我們考慮以下幾點來了解 STLC 中的需求分析。

• 此階段的准入標準是提供 SRS（軟體需求規範）；還建議應用程式架構可用。

• 在此階段，質量保證團隊在高級別上分析要測試的內容以及如何測試。

• 如果需要任何查詢或澄清以瞭解需求，質量保證團隊將與業務分析師、系統架構師、客戶、測試經理/負責人等各種利益相關者進行跟進。

• 需求可能是功能性的或非功能性的，例如效能、安全、可用性等，或功能性和非功能性兼而有之。

• 此階段的準出標準是完成 RTM 文件、自動化可行性報告以及如有必要更具體地說明需求的問題列表。

需求分析執行的活動

在此階段，質量保證團隊執行三個主要活動。下面描述了這些活動。

定義範圍

測試團隊在高層次上確定測試範圍，並將其劃分為不同的功能模組。團隊還確定需要執行的測試型別——冒煙測試、健全性測試、功能測試、迴歸測試等。測試團隊分析測試所需的前提條件和環境細節。團隊收集有關測試優先順序的詳細資訊，並重點關注要驗證的模組順序。如果模組之間存在矛盾，並且功能無法與其他模組一起延續，它還會識別需求缺陷。

準備RTM

需求追蹤是記錄需求與其為實現和驗證這些需求而開發的工作產品之間連結的過程。RTM在一個文件中捕獲需求分析中的所有需求及其可追溯性。所有這些都在生命週期結束時交付。

矩陣是在專案開始之初建立的，因為它構成了專案範圍和將要交付成果的基礎。

矩陣是雙向的，因為它透過檢查交付成果的輸出向前跟蹤需求，並透過檢視為產品特定功能指定的業務需求向後跟蹤需求。

自動化分析

在需求階段，測試團隊分析迴歸測試的自動化範圍。如果自動化被新增到範圍內，團隊將決定可以使用哪個工具，哪些功能將被覆蓋為自動化，以及自動化開發涉及的時間範圍和資源分配。一旦此分析完成，測試團隊將向不同的利益相關者提供自動化可行性報告以獲得簽字。

STLC - 准入和準出標準

在本章中，我們將瞭解STLC不同級別的進入和退出標準。需要考慮以下幾點才能理解這些標準。

理想情況下，除非當前階段的退出標準得到滿足，否則測試團隊不會進行下一階段的工作。進入標準應包括上一階段退出標準的完成。

實際上，不可能等到退出標準滿足後再開始下一階段。現在，如果上一階段的關鍵交付成果已完成，則可以啟動下一階段。

在STLC的每個階段，都應定義進入和退出標準。

進入標準

STLC階段的進入標準可以定義為特定條件；或者，在進入任何STLC階段之前，應該存在所有需要啟動特定階段的文件。

進入標準是一組允許執行任務的條件，如果沒有這些條件中的任何一個，則無法執行該任務。

在設定進入標準時，還必須定義進入標準項可用於啟動流程的時間範圍。

例如，要啟動測試用例開發階段，應滿足以下條件：

• 需求文件應該可用。
• 需要完全理解應用程式流程。
• 測試計劃文件應該準備就緒。

退出標準

STLC階段的退出標準可以定義為在結束當前階段並進入下一階段之前必須完成的專案/文件/操作/任務。

退出標準是一組期望；在結束STLC階段之前，應該滿足這些期望。

例如，要結束測試用例開發階段，應滿足以下期望：

• 測試用例應該已經編寫並審查。
• 測試資料應該已經確定並準備就緒。
• 如果適用，測試自動化指令碼應該準備就緒。

STLC - 驗收標準

驗收標準是指需求文件中列出的功能、模組和應用程式的預期行為。它是驗證階段/檢查點，用於確定軟體系統是否滿足需求規範。此測試的主要目的是評估系統是否符合業務需求，並驗證其是否滿足所需標準。

驗收標準是一組語句，清楚地說明了預期的透過/失敗結果。驗收標準指定了功能性和非功能性需求。這些需求代表“滿意條件或預期行為”。沒有部分驗收；要麼滿足標準，要麼不滿足標準。

這些標準定義了功能/模組的邊界和引數，並確定功能/模組是否已完成以及是否按預期工作。

高階驗收標準在測試計劃級別提到。驗收標準轉換為在測試用例級別要驗證的要點或預期結果列表。

驗收標準基於以下屬性定義：

• 功能正確性和完整性
• 資料完整性
• 資料轉換
• 可用性
• 效能
• 及時性
• 機密性和可用性
• 安裝和升級能力
• 可擴充套件性
• 文件

STLC - 測試計劃

測試計劃概述了將用於測試應用程式的策略、將使用的資源、將執行測試的測試環境以及測試的侷限性和測試活動的進度安排。通常，質量保證團隊負責人將負責編寫測試計劃。

測試計劃包含什麼？

測試計劃包括以下內容。

• 測試計劃文件的介紹。
• 測試應用程式時的假設。
• 測試應用程式中包含的測試用例列表。
• 要測試的功能列表。
• 測試軟體時要使用的方法。
• 需要測試的交付成果列表。
• 分配給測試應用程式的資源。
• 測試過程中涉及的任何風險。
• 要實現的任務和里程碑的進度安排。

測試計劃的重要事項

在STLC中進行測試計劃時，需要考慮以下幾點。

• 理想情況下，測試分析師（主管）/經理準備測試策略/測試計劃文件。

• 分析更側重於應用程式相關的資料/資訊。

• 這是實際測試任務的第一階段。

• 本階段回答“要測試什麼”和“需要哪些資源來測試”。

• 本階段的基本進入標準是提供需求文件（不清楚/缺失/已澄清的需求的更新版本）以及需求可追溯性矩陣。

• 如果自動化在範圍內，則應在進入此階段之前準備自動化可行性報告。

• 本階段的退出標準是完成測試策略/測試計劃文件和測試工作量估算文件。

測試計劃階段的各個方面

本階段的主要目標是準備測試計劃/測試策略文件。它包括三個主要方面：交付成果範圍、工作量估算和資源計劃。

交付成果範圍

需要執行以下活動才能得出交付成果的範圍：

• 確定合適的參與和交付模型。
• 定義測試目標、測試範圍、測試階段和活動。
• 審查業務需求和系統需求以確定測試可行性。
• 定義測試流程、測試型別和程式。
• 定義缺陷管理和變更管理程式。
• 確定測試工具、技術和最佳實踐。
• 定義風險分析。
• 定義自動化解決方案，並確定合適的自動化候選者（如果適用）。

工作量估算

估算是尋找估計值或近似值的過程，即使輸入資料可能不完整、不確定或不穩定，該值也可用於某種目的。

估算確定構建特定系統或產品需要多少資金、工作量、資源和時間。估算基於：

• 過去的資料/過去的經驗
• 可用文件/知識
• 假設
• 已識別的風險

測試估算的四個基本步驟是：

• 估計被測應用 (AUT) 的大小。
• 估計以人月或人時計的工作量。
• 以日曆月為單位估計進度安排。
• 以商定的貨幣單位估計專案成本。

資源計劃

資源計劃是測試階段的關鍵要素。這些計劃與測試團隊完成特定任務所需的時間成反比。增加資源數量將在一定限度內減少完成天數，之後它將達到飽和，增加資源不會產生太大影響，並且可能不會導致完成天數減少。

資源請求者（通常是專案經理）建立資源計劃以請求資源、跟蹤工作量和成本。資源經理可以在使用資源計劃之前修改和批准資源計劃。

資源計劃的正常工作流程為：

• 專案經理的計劃
• 專案經理提出的請求
• 資源經理批准/修改/拒絕
• 完成——在資源經理簽字後關閉請求

STLC - 測試用例開發

測試計劃準備就緒後，測試團隊將啟動測試用例的開發。本階段的主要目標是為單個單元準備測試用例。這些功能性和結構性測試用例涵蓋了測試計劃中提到的功能、驗證點和驗證點。

在STLC中進行測試用例開發時，需要考慮以下幾點。

• 在此階段，測試團隊採用逐步方法編寫測試用例。然後，業務分析師在審查或修改測試用例（如果需要修改）後簽字。

• 測試用例準備就緒後，測試團隊將根據前提條件準備測試資料。

• 本階段的進入標準是測試計劃中的活動應該完成並且測試計劃應該準備就緒。

• 本階段的退出標準是測試用例應該簽字，測試資料應該準備就緒，並且如果自動化在範圍內，測試指令碼應該準備就緒。

• 測試用例應與需求可追溯性矩陣對映，以便跟蹤需求的覆蓋範圍，如果遺漏任何內容。

測試用例開發階段中的活動

以下是測試用例開發階段中執行的三個活動：

測試場景識別

場景簡化了複雜系統的測試和評估。以下策略有助於建立良好的場景：

• 列舉可能的使用者、他們的行為和目標。

• 以駭客思維評估使用者，並列出系統濫用的可能場景。

• 列出系統事件以及系統如何處理這些請求。

• 列出優勢並建立端到端任務來檢查它們。

• 閱讀關於類似系統及其行為的資料。

• 研究關於競爭對手產品及其前代產品的投訴。

測試用例編寫

測試用例是一個文件，其中包含測試資料、前提條件、預期結果和後置條件，為特定的測試場景而開發，用於驗證對特定需求的符合性。

測試用例作為測試執行的起點。應用一組輸入值後；應用程式有一個確定的結果，並將系統留在了某個端點，這也稱為執行後置條件。

測試資料準備

測試資料用於在測試件上執行測試。測試資料需要精確且詳盡，才能發現缺陷。為了實現這三個目標，採用以下分步方法：

• 確定測試資源或需求
• 確定要測試的條件/功能
• 設定優先順序測試條件
• 選擇要測試的條件
• 確定測試用例處理的預期結果
• 建立測試用例
• 記錄測試條件
• 進行測試
• 根據修改驗證和更正測試用例

活動流程圖

下圖顯示了構成測試用例開發一部分的不同活動。

STLC - 測試環境搭建

測試環境由支援測試執行的元素組成，包括已配置的軟體、硬體和網路。測試環境配置必須模擬生產環境，以便發現任何與環境/配置相關的問題。

測試環境設定需要考慮以下幾點。

• 它是將執行測試的軟硬體環境的組合。

• 它包括硬體配置、作業系統設定、軟體配置、測試終端以及執行測試的其他支援。

• 這是測試過程中最關鍵的方面。環境設定的不可用或故障可能會破壞所有測試工作。

• 實際上，如果沒有合適的測試環境，QA 團隊無法開始實際工作。

• 這是一個獨立的活動，可以與測試用例開發同時開始。

• 最普遍的是，開發人員執行技術方面的此活動，而需求條件可以由客戶/業務分析師完成。

• 測試環境的準備情況可以透過冒煙測試進行驗證，並由 QA 團隊執行。

• 理想情況下，可以說此階段的進入標準是提供測試計劃、冒煙測試用例的準備以及測試資料的準備。

• 此階段的退出標準是測試環境應該已準備好，並且冒煙測試應該以預期結果成功執行。

測試環境設定執行的活動

此階段執行以下活動。

設計測試環境

以下因素在測試環境的設計中起著重要作用。

• 確定測試環境是否需要存檔以進行備份。

• 驗證網路配置。

• 確定所需的伺服器作業系統、資料庫和其他元件。

• 確定測試團隊所需的許可證數量。

環境設定

分析環境設定需求，並準備設定的軟體和硬體需求列表。獲得測試環境設定的正式確認，並配置以訪問測試環境。

冒煙測試

一旦環境設定好並且 QA 團隊可以訪問它，就應該進行快速一輪冒煙測試，以驗證測試環境構建的穩定性。如果結果符合預期，QA 團隊可以進入下一階段，否則指出差異，並在修復後等待部署。

STLC - 測試執行

測試執行是執行程式碼並將預期結果與實際結果進行比較的過程。測試執行過程需要考慮以下因素：

• 根據風險，選擇要在本週期執行的測試套件的子集。
• 將每個測試套件中的測試用例分配給測試人員執行。
• 持續執行測試、報告錯誤並捕獲測試狀態。
• 解決出現的阻塞問題。
• 每天報告狀態、調整分配並重新考慮計劃和優先順序。
• 報告測試周期結果和狀態。

測試執行需要考慮以下幾點。

• 在此階段，QA 團隊根據準備好的測試用例對 AUT 進行實際驗證，並將逐步結果與預期結果進行比較。

• 此階段的進入標準是完成測試計劃和測試用例開發階段，測試資料也應該準備好。

• 在正式進入測試執行之前，始終建議透過冒煙測試驗證測試環境設定。

• 退出標準要求成功驗證所有測試用例；缺陷應已關閉或延期；測試用例執行和缺陷彙總報告應已準備就緒。

測試執行活動

此階段的目標是在繼續進行生產/釋出之前對 AUT 進行即時驗證。為了從此階段簽字，QA 團隊執行不同型別的測試以確保產品質量。除此之外，缺陷報告和重新測試也是此階段的關鍵活動。以下是此階段的重要活動：

系統整合測試

產品的真實驗證/AUT 從這裡開始。系統整合測試 (SIT) 是一種黑盒測試技術，用於評估系統對已準備好的指定需求/測試用例的符合性。

系統整合測試通常在系統的子集上執行。SIT 可以使用最少的測試工具來執行，驗證交換的互動，並調查各個層中每個資料欄位的行為。整合後，資料流有三個主要狀態：

• 整合層中的資料狀態
• 資料庫層中的資料狀態
• 應用程式層中的資料狀態

注意 - 在 SIT 測試中，QA 團隊試圖發現儘可能多的缺陷以確保質量。這裡的主要目標是發現儘可能多的錯誤。

缺陷報告

當預期結果與實際結果不匹配時，就會出現軟體錯誤。它可能是計算機程式中的錯誤、缺陷、故障或錯誤。大多數錯誤是由開發人員或架構師犯下的錯誤造成的。

在執行 SIT 測試時，QA 團隊會發現這些型別的缺陷，這些缺陷需要向相關團隊成員報告。成員採取進一步行動並修復缺陷。報告的另一個優點是它可以輕鬆跟蹤缺陷的狀態。許多流行的工具（如 ALM、QC、JIRA、Version One、Bugzilla）都支援缺陷報告和跟蹤。

缺陷報告是透過測試或記錄客戶反饋來查詢被測應用程式或產品中的缺陷，並根據客戶反饋製作修復缺陷的新產品版本的流程。

缺陷跟蹤也是軟體工程中的一個重要流程，因為複雜的和業務關鍵的系統有數百個缺陷。最具挑戰性的因素之一是管理、評估和優先處理這些缺陷。缺陷的數量隨著時間的推移而成倍增加，為了有效地管理它們，缺陷跟蹤系統被用來簡化工作。

缺陷對映

一旦缺陷被報告和記錄，它應該與需求可追溯性矩陣中相關的失敗/阻塞的測試用例和相應的要求進行對映。此對映由缺陷報告人完成。它有助於製作適當的缺陷報告並分析產品中的缺陷。一旦測試用例和需求與缺陷對映後，利益相關者可以分析並決定根據優先順序和嚴重性來修復/延遲缺陷。

重新測試

重新測試是對 AUT 執行先前失敗的測試，以檢查問題是否已解決。修復缺陷後，將執行重新測試以檢查相同環境條件下的場景。

在重新測試期間，測試人員會檢視功能更改區域的細粒度細節，而回歸測試涵蓋所有主要功能，以確保由於此更改而沒有破壞任何功能。

迴歸測試

一旦所有缺陷都處於關閉、延期或拒絕狀態，並且沒有任何測試用例處於進行中/失敗/未執行狀態，就可以說系統整合測試完全基於測試用例和需求。但是，需要進行一輪快速測試，以確保由於程式碼更改/缺陷修復而沒有破壞任何功能。

迴歸測試是一種黑盒測試技術，它包括重新執行由於程式碼更改而產生影響的那些測試。這些測試應該在整個軟體開發生命週期中儘可能頻繁地執行。

迴歸測試型別

• 最終迴歸測試 - “最終迴歸測試”用於驗證一段時間內未發生更改的構建。此構建被部署或交付給客戶。

• 迴歸測試 - 常規迴歸測試用於驗證最近的程式碼更改（用於缺陷修復或增強）是否未破壞應用程式的其他任何部分。

活動流程圖

下圖顯示了此階段執行的重要活動；它還顯示了與先前階段的依賴關係：

STLC - 缺陷生命週期

缺陷生命週期，也稱為錯誤生命週期，是缺陷的歷程，缺陷在其生命週期中所經歷的週期。它因組織而異，也因專案而異，因為它受軟體測試流程的約束，也取決於所使用的工具。

缺陷生命週期 - 工作流程

下圖顯示了缺陷生命週期的工作流程。

缺陷生命週期的狀態

以下是缺陷生命週期的不同狀態。

• 新建 - 已提出但尚未驗證的潛在缺陷。

• 已分配 - 分配給開發團隊以解決。

• 活躍 - 缺陷正在由開發人員解決，並且調查正在進行中。在此階段，有兩種可能的結果 - 延期或拒絕。

• 測試/已修復/準備重新測試 - 缺陷已修復並準備進行測試。

• 已驗證 - 已重新測試並且測試已由 QA 驗證的缺陷。

• 已關閉 - 缺陷的最終狀態，可以在 QA 重新測試後關閉，如果缺陷是重複的或被認為不是缺陷，也可以關閉。

• 已重新開啟 - 當缺陷未修復時，QA 會重新開啟/重新啟用缺陷。

• 已延期 - 當在特定週期中無法解決缺陷時，它會被延遲到將來的版本。

• 已拒絕 - 由於以下三個原因之一，缺陷可能會被拒絕 - 重複缺陷、不是缺陷、不可重現。

STLC - 缺陷分類

缺陷從QA團隊的角度被分類為優先順序，從開發的角度被分類為嚴重程度（修復程式碼的複雜性）。這是兩個主要的分類，它們在修復缺陷的時間範圍和工作量方面起著重要的作用。

什麼是優先順序？

優先順序定義為應解決缺陷的順序。優先順序狀態通常由QA團隊在針對開發團隊提出缺陷時設定，同時說明修復缺陷的時間範圍。優先順序狀態是根據終端使用者的需求設定的。

例如，如果公司徽標在公司網頁上的位置不正確，則優先順序很高，但嚴重程度很低。

優先順序列表

優先順序可以按以下方式分類：

• 低 - 在修復關鍵缺陷後可以修復此缺陷。

• 中 - 應在後續版本中解決此缺陷。

• 高 - 必須立即解決此缺陷，因為此缺陷會嚴重影響應用程式，並且相關模組在修復之前無法使用。

• 緊急 - 必須立即解決此缺陷，因為此缺陷嚴重影響應用程式或產品，並且在修復之前產品無法使用。

什麼是嚴重程度？

嚴重程度定義為缺陷對應用程式的影響程度以及從開發角度來看修復程式碼的複雜性。它與產品的開發方面相關。嚴重程度可以根據缺陷對系統的嚴重程度/重要程度來決定。嚴重程度狀態可以說明由於缺陷導致的功能偏差。

示例 - 對於航班運營網站，生成預訂對應的票號的缺陷屬於高嚴重性和高優先順序。

嚴重程度列表

嚴重程度可以按以下方式分類：

• 嚴重/嚴重程度1 - 缺陷影響應用程式最關鍵的功能，並且在修復之前，QA團隊無法繼續驗證被測應用程式。例如，應用程式/產品頻繁崩潰。

• 主要/嚴重程度2 - 缺陷影響功能模組；QA團隊無法測試該特定模組，但可以繼續驗證其他模組。例如，航班預訂功能無法正常工作。

• 中等/嚴重程度3 - 缺陷存在於單個螢幕或與單個功能相關的問題，但系統仍在執行。此處的缺陷不會阻塞任何功能。例如，票號的表示方式不遵循正確的字母數字字元，例如前五個字元為字母，後五個字元為數字。

• 低/嚴重程度4 - 它不影響功能。它可能是一個外觀缺陷、UI欄位不一致或來自UI方面的改進終端使用者體驗的建議。例如，“提交”按鈕的背景顏色與“儲存”按鈕的背景顏色不匹配。

STLC - 測試周期結束

對測試退出標準進行檢查對於宣告測試已完成至關重要。在結束測試過程之前，根據測試完成標準衡量產品質量。

本階段的進入標準是測試用例的執行已完成，測試結果可用且缺陷報告已準備就緒。

測試完成標準包括以下內容：

• 已達到指定的覆蓋率。
• 沒有阻礙性或嚴重缺陷
• 只有很少已知的，中低優先順序的缺陷。這些缺陷不會影響產品的用途。

本階段的退出標準是提供測試結束報告和準備矩陣，之後由客戶簽字確認。

現在讓我們討論測試周期結束所涉及的活動。

測試完成報告

測試完成報告是一個過程，透過該過程，測試指標以彙總格式報告以更新利益相關者。這使他們能夠做出明智的決策。

測試完成報告包含以下資訊。

• 測試彙總報告識別符號
• 摘要
• 差異
• 彙總結果
• 評估
• 計劃與實際工作量
• 簽字確認

一份良好的測試完成報告表明質量、衡量突出風險並確定已測試軟體的級別。

測試完成矩陣

測試完成後，將收集各種矩陣以準備測試報告。準備報告的標準包括以下內容：

• 已執行的測試數量
• 已透過的測試數量
• 已失敗的測試數量
• 每個模組中失敗的測試數量
• 執行週期中提出的測試缺陷數量
• 已接受的測試缺陷數量
• 已拒絕的測試缺陷數量
• 已推遲的測試缺陷數量
• 活動缺陷的狀態
• 計算版本的質量指標

測試結果

在執行測試用例、重新測試缺陷和執行迴歸測試用例時，應儲存測試結果說明，並可以與測試周期結束文件一起提供，以支援測試執行的完成。

說明可以是螢幕截圖、資料庫查詢結果、記錄、日誌檔案等。