前言
本篇學習，測試相關基礎概念、常見的開發模型測和測試模型，搞懂4個問題：
- 什么是需求
- 什么是 bug
- 什么是測試用例
- 開發模型和測試模型
目錄
1. 什么是需求
1.1 為什么要有需求
1.2 測試人員眼里的需求
1.3 如何深入了解需求
2. 測試用例
2.1 什么是測試用例
2.2 為什么要有測試用例
2.3 練習
3. 認識 BUG
4. 軟件生命周期
5. 開發模型
5.1 瀑布模型
5.2 螺旋模型
5.3 增量模型與迭代模型
5.3.1 增量模型
5.3.2 迭代模型
5.4 敏捷模型
6. 測試模型
6.1 ?V?模型
6.2 ?W?模型(雙 V 模型)
1. 什么是需求
1.1 為什么要有需求
當程序猿開發一產品或者測試一個產品時，需要拿著軟件需求來進行開發和測試。
1.2 測試人員眼里的需求
對一個大的需求進行子拆分為一些小需求以解決原需求。如一個登錄功能：
1.3 如何深入了解需求
開一個需求評審會議，內容大概有：為什么做這樣一個需求、這個需求能帶來多少收益、軟件需要做成什么樣子。或查詢文檔(需求文檔、技術文檔)，亦或者找產品經理了解軟件功能、找開發了解軟件的實現。因此，如何深入了解需求有三點:
- 參加需求評審會議
- 查詢文檔
- 溝通
2. 測試用例
2.1 什么是測試用例
測試用例是一組集合，如：測試環境、測試數據、預期結果、操作步驟等。粗獷的理解為:
- 測試環境：力扣刷題時會給我們提供一個測試平臺
- 測試數據：字節輸入測試數據 70%
- 操作步驟：寫代碼然后提交
- 預期結果：100% 通過
例如，一個登錄功能，此時：
- 測試環境：windows 系統 + chrome 瀏覽器 + idea 編譯器
- 測試數據：賬號 + 密碼
- 測試步驟：輸入賬號密碼點擊登錄
- 測試結果：登錄成功
2.2 為什么要有測試用例
測試用例能夠提高測試人員的工作效率，降低測試人員工作的重復性。如一個測試登錄功能，同一個功能多個人去測，當有了測試用例后，假設有 100 個用例，幾個人分別測試這 100 個用例。這樣即可以提高工作效率。
測試用例是建立自動化的基礎，自動化就是使用代碼來實現測試人員解放雙手，用代碼來代替測試人員執行用例。
2.3 練習
一個練習題：設計手機打電話這個功能的測試用例。
此時，大家腦海里肯定有許多想法如：手機號是否為正確格式，測試網絡是否暢通，手機是否有充足話費等等。這樣盲目列出讓人有一種沒有條例毫無思路的感覺，因此可以列出一個集合，如下圖所示：
3. 認識 BUG
史上的第一只 Bug ，真的是因為一只飛蛾意外走入一電腦而引致故障，因此 Bug 從原意為臭蟲引申為程序錯誤。在軟件測試概念中：
- 當規格說明書存在且正確時，程序與規則之間不匹配則認為是一個錯誤(bug)
- 當規格說明書沒有提到某些功能，程序沒有實現最終用戶心里需求時則認為是一個軟件錯誤。
以上 bug 容易理解，軟件錯誤可理解為：假設規格說明書中沒有明確密碼隱藏顯示(日常中會默認隱藏顯示)，用戶在登錄時發現自己密碼容易被旁人看到，因此向甲方提出訴求，而這就是一個軟件錯誤。
4. 軟件生命周期
簡單理解為：需求分析、計劃、設計、編碼、測試、運行維護。詳細理解：
- 需求分析：分析需求是否合理，需求是否完整。例如，一個登陸頁面，光有登錄沒有注冊，這就是一個不合理、不完整。
- 計劃：誰開發、誰測試、開發和測試的周期。
- 編碼：前后端程序員根據需求開始編寫代碼。
- 測試：測試人員根據開發者編寫的代碼進行測試，會制定一個測試報告，把測試報告則給上級，上級覺得合適則上線。
- 運行維護：如果線上有問題，測試人員需要協助開發定位問題、解決問題。
測試報告大致為：
5. 開發模型
5.1 瀑布模型
瀑布模型（Waterfall Model）是一種經典的軟件開發模型，將項目劃分為若干個嚴格按順序執行的階段，每個階段完成后才能進入下一個階段，形如瀑布流水，故得名“瀑布模型”。常見流程為下圖：
- 需求分析：需求文檔，分析需求是否合理，需求是否完整。
- 計劃：什么時候開始，什么時候結束
- 設計：技術文檔(數據庫、實現功能等)、UI視覺稿(簡單理解為精美的頁面)
- 編碼：前后端程序員編寫代碼
- 測試：執行測試用例，提交 bug，驗收等。
特點：它是一種線性的路程。
優點：階段清晰，易于管理；文檔驅動，便于溝通；適合需求穩定的項目。
缺點：缺乏靈活性(進入下個階段，很難回頭修改)；風險后置；用戶參與度低；不適合需求頻繁改變的項目。
5.2 螺旋模型
螺旋模型（Spiral Model）是一種結合了瀑布模型和快速原型模型特點的軟件開發模型，核心在于通過迭代式開發和風險驅動的方式，逐步推進項目，降低開發風險，特別適用于大型、復雜且高風險的系統開發項目。常見流程如下：
- 制定計劃：確定項目目標、約束條件、備選方案；制定迭代計劃，明確資源需求和時間安排。
- 風險分析：識別潛在風險（如技術風險、需求風險、管理風險等）；評估風險影響，制定應對策略。
- 實施工程：根據計劃進行系統設計、編碼、測試等開發活動；構建原型或增量版本，驗證關鍵功能。
- 客戶評估：向客戶展示迭代成果，收集反饋；根據反饋調整后續迭代計劃。
優點：降低風險，每個階段都會進行風險分析，避免一些線上問題發生
缺點：管理復雜度高、成本較高、依賴客戶參與。
適用項目：大型項目、風險較高項目、需求不明確或需求易變項目。
5.3 增量模型與迭代模型
5.3.1 增量模型
定義：
- 逐步交付：將系統劃分為多個獨立的“增量”（模塊或功能），每個增量獨立開發、測試并交付用戶。
- 線性擴展：每個增量在上一版本基礎上擴展功能，逐步完善系統。
特點：
- 階段性交互：用戶可以提前獲得某些功能
- 并行開發：不同的增量可以由不同的程序猿開發
- 需求變化靈活：后增量的需求可在開發前調整，適應變化。
5.3.2 迭代模型
定義：
- 重復開發周期：將開發過程劃分為多個“迭代”，每個迭代包含需求分析、設計、編碼、測試等完整階段。
- 逐漸細化：通過多次迭代逐步完善系統，需求和設計在迭代中不斷調整。
特點：
- 循環迭代：每個迭代產出可運行的軟件版本，但功能可能不完整。
- 分線驅動：早期迭代優先解決高風險問題（如技術驗證）。
- 用戶反饋驅動：基于用戶反饋調整后續迭代內容。
假設有一個網站，包含注冊、登錄、修改個人信息等功能，增量和迭代模型分別對應如下操作：
增量：注冊功能完成 -> 登錄功能完成 -> 修改個人信息
迭代：注冊功能開發一部分 -> 登錄功能開發一部分 -> 修改個人信息開發一部分
5.4 敏捷模型
個體與交互重于過程和工具?可用的軟件重于完備的文檔?客戶協作重于合同談判響應變化重于遵循計劃在每對比對中，后者并非全無價值，但我們更看重前者
- 以人為核心：
強調團隊成員的協作、溝通和創造力，而非過度依賴流程和工具。 - 迭代與增量開發：
將項目分解為多個短周期的迭代（通常為2-4周），每個迭代產生可用的軟件增量。 - 快速響應變化：
通過頻繁的迭代和反饋，快速適應需求變化，減少項目風險。 - 客戶協作：
客戶作為團隊的一部分，參與需求定義、驗收測試和反饋，確保產品符合實際需求。 - 持續交付價值：
每個迭代結束時交付可用的軟件，使客戶盡早獲得價值
常見的敏捷測試有 Scrum ，它用于管理復雜產品的開發、交付和持續支持。它通過短周期的迭代（稱為 Sprint）和持續反饋，幫助團隊高效協作、快速響應變化，并持續改進產品。
- 特點：基于短周期的迭代（Sprint），強調團隊自組織和持續改進。
- 角色：產品負責人（Product Owner）、Scrum Master、開發團隊。
- 適用場景：需求不明確或頻繁變化的項目，如互聯網產品開發。
大概流程為：
（1）項目經理收集用戶需求，對需求進行優先級的劃分、計劃項目開始與結束時間。
（2）每日站會，匯報昨日工作完成狀況、遇到問題，今日計劃等。
（3）演示，給不同的人進行演示。
（4）總結，總結上述過程中發生的問題，避免今后遇到。
6. 測試模型
6.1 ?V?模型
- 用戶需求：PM(產品經理)將用戶需求進行收集形成軟件需求?
- 需求分析和系統設計：驗證需求是否正確，確定語言，確定框架?
- 概要設計：項目的一個結構?
- 詳細設計：每個結構對應的表名、接口等?
- 編碼：編寫代碼
- 單元測試：測試每個方法/函數功能是否正確實現?
- 集成測試：將眾多方法/函數集中在一起進行測試
- 系統測試：測試模塊與模塊之間沒有影響
- 驗收測試：產品經理，運營進行驗收
特點：左邊是開發，右邊是測試，分工明確類似于瀑布模式。
優點：測試被劃分為許多類型。
缺點：測試人員介入太晚，導致問題發現較晚。
6.2 ?W?模型(雙 V 模型)
特點：開發一個 V，測試一個 V。
優點：測試人員盡早的進入了測試。
缺點：測試人員和開發人員一定程度上還是串行的，不能擁抱變化，不適于敏捷模型。
