本章思維導圖：

1.? 軟件測試的生命周期

????????軟件測試貫穿于整個軟件的生命周期

流程階段	需求分析	測試計劃	測試設計/開發	測試執行	測試評估	上線	運行維護
具體工作內容	1. 閱讀需求文檔 2. 標記可測試需求 3. 確定測試類型	1. 制定測試范圍 2. 選擇測試工具 3. 分配資源	1. 編寫測試用例 2. 準備測試數據 3. 開發自動化腳本	1. 執行測試用例 2. 記錄結果 3. 提交缺陷	1. 統計缺陷 2. 計算覆蓋率 3. 編寫報告	1. 部署軟件 2. 驗證功能 3. 監控運行	1. 收集反饋 2. 修復缺陷 3. 性能優化

其中，上線流程并不是一步就完成的，而是分為多步進行，?環境分為線上環境和線下環境

• 線下環境：開發和測試人員測試使用?
• 線上環境：用戶使用

線下環境測試完成后，就需要進行上線，上線又分為 沙盒測試、小流量、全流量、全線上

• 沙盒測試：企業內部的員工使用
• 小流量：只有一部分的用戶能夠使用
• 全流量：大部分用戶能夠使用
• 全線上：所有線上的用戶都能夠使用

測試/發布類型	沙盒測試 (Sandbox Testing)	小流量 (Canary Release)	全流量 (Full Release)	全線上 (Production)
定義	在隔離的測試環境中模擬生產環境進行測試	將新版本先發布給少量真實用戶進行驗證	新版本對所有用戶開放，但尚未完全取代舊版本	新版本已完全取代舊版本，成為線上唯一版本
具體工作內容	1. 搭建與生產隔離的測試環境 2. 模擬用戶請求和數據 3. 驗證核心功能與異常場景	1. 選擇小部分用戶或流量（如1%-5%） 2. 監控用戶行為和數據指標 3. 快速回滾發現問題	1. 逐步擴大用戶覆蓋范圍（如50%-100%） 2. 持續監控系統穩定性 3. 與舊版本并行運行驗證	1. 完全下線舊版本 2. 全量用戶使用新版本 3. 長期監控和優化
目的	提前發現功能或性能問題，避免影響真實用戶	降低風險，通過真實用戶反饋驗證版本穩定性	確保新版本在大規模流量下的穩定性	完成版本迭代，進入穩定運維階段
風險等級	無用戶影響	低風險（影響范圍可控）	中風險（需快速響應問題）	高風險（需確保100%穩定性）
適用場景	新功能開發完成后內部驗證	重大更新或架構改動前的驗證	確認小流量無問題后的全面推廣	最終穩定版本的長期運行

2.? Bug

2.1? bug 的概念

「Debug」的由來

????????計算機史上第一個著名的“Bug”誕生于1947年9月9日，哈佛大學的Grace Hopper團隊在調試馬克II計算機時，發現一只飛蛾卡死在繼電器中導致機器故障。他們幽默地將這只蛾子貼在日志本上，標注"First actual case of bug being found"，從此"bug"成為程序缺陷的代名詞，"debug"則指排除故障的過程。這個真實的小故事不僅創造了計算機領域的經典術語，更生動展現了工程師們解決問題的智慧——再復雜的技術問題，往往源于最意想不到的細節。如今保存在史密森尼博物館的那只飛蛾，成為了計算機發展史上最有趣的文物之一。

定義：在軟件測試中，Bug（缺陷）?是指軟件系統中存在的任何不符合預期行為或需求的問題。Bug 可能導致功能失效、性能下降、安全漏洞或用戶體驗不佳。

簡單理解：任何與需求文檔、設計規范或用戶期望不一致的問題，均可稱為 Bug。

就比如說當需要一個列表功能，其中有幾千上萬個選項
但是需要用戶一個一個往下翻才能找到想要的，而不能直接檢索關鍵字來確定范圍

此時該功能和用過需求有了沖突，此時就可以提一個 bug

當我們進行測試的時候，我們不需要過分關注程序里的代碼是如何寫的，重點關注的是該程序的輸入輸出是否符合我們的預期

例如一個排序程序，里面的實現方式可能是冒泡排序，快速排序，歸并排序........

不用管，只需要看無序數組經過程序運行后是否變得有序就行

2.2? 描述 bug 的要素

? ? ? ? 為什么描述 bug 還要有要求？
? ? ? ? 在心理學上說，在編寫文檔是，人們想要表達的和實際書寫的文檔往往會南轅北轍。而不清楚，不確定的描述更是可能誤導開發人員，倒是溝通低效，工作質量低。因此，一個清晰、完整的 Bug 描述能幫助開發人員快速定位和修復問題。

描述 bug 的基本要素：

問題標題、問題出現的版本、問題出現的環境、問題出現的步驟、預期結果、實際結果

拿瀏覽器打開同一個網址來舉例：

同一個網址，某些瀏覽器打開會出現頁面顯示錯誤，會出現圖片錯位的情況，以這個 bug 來描述

問題標題：瀏覽器兼容性問題導致頁面圖片錯位

問題出現的版本：網站版本 v2.1.0（舉例）

問題出現的環境：Safari 16.6 / Edge 117（異常環境）??Chrome 118 / Firefox 118 （正常環境）

問題出現的步驟：

1. 使用?Safari 16.6?或?Edge 117?瀏覽器。

2. 訪問網址：https://example.com/product/123。

3. 滾動頁面至「產品詳情」模塊。

預期結果：圖片應與文字描述對齊，布局符合設計稿

實際結果：圖片向右偏移?50px，與文字重疊

2.3??bug 級別

級別	類型	描述	示例
Critical	嚴重程度 (Severity)	導致系統崩潰、數據丟失或核心功能完全不可用	支付失敗但扣款成功、數據庫數據損壞
Major	嚴重程度 (Severity)	重要功能異常，但系統可降級運行	商品搜索返回錯誤結果、圖片錯位影響操作
Minor	嚴重程度 (Severity)	非核心功能問題，用戶體驗受損	字體顏色不符設計稿、次要按鈕無響應
Trivial	嚴重程度 (Severity)	微小瑕疵，不影響功能	控制臺無關警告、拼寫錯誤
P1	優先級 (Priority)	必須立即修復（阻塞開發/上線）	所有用戶無法登錄、關鍵業務流程中斷
P2	優先級 (Priority)	高優先級，需在當前版本修復	部分用戶遭遇數據展示錯誤（如瀏覽器兼容性問題）
P3	優先級 (Priority)	可延期至后續版本修復	低頻率UI錯位，不影響核心功能
P4	優先級 (Priority)	修復成本高于收益，可能永不修復	IE11瀏覽器下的邊緣樣式問題

2.4? bug 的生命周期

狀態	描述	常見操作
New	測試人員新發現的缺陷，尚未分配	提交Bug報告
Assigned	缺陷已分配給開發人員，等待修復	開發認領任務
In Progress	開發人員正在修復中	代碼修改、本地測試
Fixed	開發完成并部署到測試環境，等待驗證	標記為“已修復”
Verified	測試人員確認缺陷已解決	回歸測試通過
Closed	缺陷完全關閉，流程結束	歸檔至歷史記錄
Rejected	開發認為不是缺陷（如需求理解錯誤）	需產品經理仲裁
Deferred	暫不修復（如低優先級、下個版本處理）	記錄延期原因
Reopened	驗證時問題復現，重新激活（從Verified/Fixed回到Assigned）	重新分配開發

流程圖：

2.5? 與開發發生爭執應該怎么做

1) 先檢查自己，是否 bug 描述不清楚

2) 站在用戶的角度考慮并拋出問題 ---- 功能正常只是測試的一部分，還要考慮用戶的感受

3)?bug 定級需要有理有據 ---- bug 級別描述文檔

4)?提高業務水平，做到不僅能夠提出問題，最好也能夠提出解決方案

舉例：雙十一活動

測試新手：雙十一活動時間邊界值不符合預期
測試大牛:? 雙十一活動時間邊界值不符合預期? 修改建議：.......

注意，不要以命令式的口吻去告訴開發人員，術業有專攻，建議只是建議

5)??bug 評審

如果確實是 bug ，但不能友好溝通，就召開 bug 評審

Bug評審是軟件開發過程中由跨職能團隊共同評估、分類和處理缺陷的關鍵環節，其核心目標是高效分配資源并確保產品質量。

bug 評審需要三個代表參加：測試代表、開發代表、產品代表

bug 評審主要解決兩個問題：

• 決定如何處理 bug
• 分析缺陷產生的原因，并找出預防的對策