一.演化
♦1960年代的趨勢:
♦1990年代的趨勢：
♦2000年代的趨勢：
測試的趨勢和能力正在發生變化。現在要求測試人員更加注重技術和流程。現在的測試不僅僅局限於發現錯誤，而且范圍更廣，從項目一開始就需要甚至沒有最終確定。 由於測試也是標准化的。就像軟件開發有生命周期一樣，測試也有生命周期。在隨后的章節中，我將討論生命周期是什么以及它與軟件測試有何關系，並將嘗試詳細說明。
開始吧！
二. 什么是生命周期？
簡單術語中的生命周期是指從一種形式到另一種形式的變化順序。
這些變化可能發生在任何有形或無形的事物上。
每個實體從開始到退休/消亡都有一個生命周期。
以類似的方式，軟件也是一個實體。
就像開發軟件涉及一系列步驟一樣，測試也有一些應該以一定順序執行的步驟。
這種以系統和有計划的方式執行測試活動的現象稱為測試生命周期。
三. 什么是軟件測試生命周期（STLC）
軟件測試生命周期是指一個測試過程，其具有以確定順序執行的特定步驟，以確保滿足質量目標。
在STLC過程中，每個活動都以有計划和系統的方式進行。
每個階段都有不同的目標和可交付成果。
不同的組織在STLC中有不同的階段;但基礎保持不變。
以下是STLC的各個階段：
- 需求階段
- 計划階段
- 分析階段
- 設計階段
- 實施階段
- 執行階段
- 結論階段
- 關閉階段
#1. 需求階段:
在STLC的這個階段，分析和研究要求。與其他團隊進行頭腦風暴會議，並嘗試確定這些要求是否可測試。此階段有助於確定測試范圍。如果任何功能不可測試，請在此階段進行通信，以便可以規划緩解策略。
#2. 計划階段:
在實際情況中，測試計划是測試過程的第一步。在此階段，我們確定有助於實現測試目標的活動和資源。在規划期間，我們還嘗試確定指標，收集和跟蹤這些指標的方法。
在什么基礎上進行規划？只有要求？
答案是不。要求確實構成了基礎之一，但是還有另外兩個影響測試計划的非常重要的因素。這些是:
–-組織測試策略。
–-風險分析/風險管理和預防。
#3. 分析階段:
STLC階段定義了要測試的“WHAT”。我們基本通過需求文檔，產品風險和其他測試依據來確定測試條件。測試條件應該可追溯到要求。影響測試條件識別的因素有很多：
– 測試的級別和深度
– 產品的復雜性
– 產品和項目風險
– 涉及軟件開發生命周期。
– 測試管理
– 團隊的技能和知識。
– 利益相關者的可用性。
我們應該嘗試以詳細的方式寫下測試條件。例如，對於電子商務Web應用程序，您可以將測試條件設置為“用戶應該能夠進行付款”。或者您可以通過說“用戶應該能夠通過NEFT，借記卡和信用卡付款”來詳細說明。編寫詳細測試條件的最重要的優點是它增加了測試覆蓋率，因為測試用例將根據測試條件編寫，這些細節將觸發編寫更詳細的測試用例，最終會增加覆蓋范圍。還要確定測試的退出標准，即確定停止測試的一些條件。
#4. 設計階段:
這個階段定義了“HOW”進行測試。此階段涉及以下任務：
– 詳細說明測試條件。將測試條件分解為多個子條件以增加覆蓋率。
– 識別並獲取測試數據
– 識別並設置測試環境。
– 創建需求可跟蹤性度量標准
– 創建測試覆蓋率指標。
#5. 實施階段:
STLC階段的主要任務是創建詳細的測試用例。確定測試用例的優先級，還可以確定哪個測試用例將成為回歸套件的一部分。在最終確定測試用例之前，重要的是進行審查以確保測試用例的正確性。另外，在實際執行開始之前，不要忘記取消測試用例的簽名。如果您的項目涉及自動化，請確定自動化的候選測試用例並繼續編寫測試用例的腳本。別忘了查看它們！
#6. 執行階段:
顧名思義，這是實際執行的軟件測試生命周期階段。但在開始執行之前，請確保滿足您的輸入條件。執行測試用例，記錄任何差異時的缺陷。同時填寫可追溯性指標以跟蹤您的進度。
#7. 結論階段:
該STLC階段集中於退出標准和報告。根據您的項目和利益相關者的選擇，您可以決定報告是否要發送每周報告/每日報告等。您可以發送不同類型的報告（DSR - 每日狀態報告，WSR - 每周狀態報告）但重要的是，報告的內容會發生變化，具體取決於您發送報告的對象。如果項目經理屬於測試背景，那么他們對項目的技術方面更感興趣，因此請在報告中包含技術內容（通過的測試用例數，失敗，引發的缺陷，嚴重性1缺陷等）。但是，如果您向上層利益相關方報告，他們可能對技術問題不感興趣，因此請報告他們通過測試減輕的風險。
#8. 關閉階段:
關閉活動的任務包括以下內容：
–檢查測試是否完成。是否所有測試用例都執行或缺少的。檢查是否沒有打開嚴重性1的缺陷。
–取經驗教訓會議並創建經驗總結文件。（包括哪些方面進展順利，哪些方面有改進，哪些方面可以改進）
四. 總結:
讓我們試着總結軟件測試生命周期（STLC）吧！
| S.No | 階段名稱 | 入境標准 | 活動執行 | 交付 |
|---|---|---|---|---|
| 1 | 需求 | 要求規范文件 應用設計文件 用戶驗收標准文件 |
集思廣益的需求。創建需求列表並澄清您的疑慮。. 了解需求是否可測試的可行性 如果您的項目需要自動化，請進行自動化可行性研究 |
RUD ( 需求理解文檔. 測試可行性報告 自動化可行性報告 |
| 2 | 計划 | 更新的需求文檔. 測試可行性報告 “ 自動化可行性報告 |
定義項目的范圍 進行風險分析並制定風險緩解計划。 執行測試評估 確定整體測試策略和流程。 確定工具和資源，並檢查是否有任何培訓需求. 識別環境 |
測試計划文檔. 風險預防文件 測試評估文件 |
| 3 | 分析 | 更新的需求文檔 測試計划文檔 風險文檔 測試評估文檔 |
確定詳細的測試條件 | 測試概要文件。 |
| 4 | 設計 | 更新的需求文檔 測試概要文件 |
詳細說明測試條件。 識別測試數據 創建可跟蹤性指標 |
詳細的測試條件文件 需求可追溯性指標 測試覆蓋指標 |
| 5 | 實施 | 詳細的測試條件文件 | 創建並查看測試用例。 創建並查看自動化腳本。 確定回歸和自動化的候選測試用例. 識別/創建測試數據 簽下測試用例和腳本。. |
測試用例 測試數據 測試腳本 |
| 6 | 執行 | 測試用例 測試腳本 |
執行測試用例 記錄 bugs / 出現差異的缺陷 報告狀態 |
測試執行報告 缺陷報告 測試日志，缺陷日志 更新需求可跟蹤性指標 |
| 7 | 結論 | 更新了包含結果的測試用例 測試關閉條件 |
提供准確的數字和測試結果 確定減輕的風險 |
更新了可追溯性指標 測試總結報告 更新風險管理報告 |
| 8 | 關閉 | 測試閉合條件 測試總結報告 |
進行回顧性研究並了解所學到的經驗教訓 | 經驗教訓文件 測試矩陣 測試結束報告. |
HAPPY TESTING!!