軟體在上線前需要經過測試。以驗證軟體是否滿足使用需求，同時盡可能減少軟體中的 BUG 缺陷，保證軟體質量。
分類#
按開發階段劃分#
- 單元測試 (Unit Testing)：測試程式碼模組（如函數）是否能正常工作，通常由開發人員自己進行。
- 集成測試 (Integration Testing)：也稱聯合調試。將已經通過單元測試的模組組合起來進行測試，驗證它們之間的介面是否正確。（確保協同工作時候沒問題）
- 系統測試 (System Testing)：將整個系統作為一個整體進行測試，驗證其功能和非功能需求（包括相容性測試、性能測試、安全性測試等）是全面的驗證。通常會根據內部文件來執行。
- 驗收測試 (Acceptance Testing)：由實際用戶或客戶進行的測試，以確定系統是否滿足業務需求。形式上分為：內測（Alpha 測試）、公測（Beta 測試）。通常以公測的形式，確保產品在發布前盡可能發掘項目缺陷，更好地達到用戶的期望，減少上線後的風險。
單元測試是一個模組內部的測試；集成測試是多個模組間的測試
按代碼可見度劃分#
-
黑盒測試 (Black Box Testing)：源代碼不可見。UI 功能可見。不關心實現細節，只關心輸入輸出。主要是在用戶的角度來驗證系統的功能和性能。（比如功能上的，相容性的和用戶體驗方面的測試）
-
白盒測試 (White Box Testing)：測試人員完全了解內部結構和實現細節，直接測試源代碼。主要是開發人員做白盒測試。一般是在單元測試裡使用。
-
灰盒測試 (Gray Box Testing)：黑盒測試和白盒測試的折中。測試從用戶角度出發，但也對內部的實現邏輯有一定的了解。主要在集成測試裡使用，用作介面測試等。
評估：軟體質量模型#
八個質量維度均達標，則是一個優秀的軟體
- 功能性 (Functionality) ：主要考慮軟體提供的功能是否滿足用戶需求。包括：功能的數量和完整性，功能是否正確實現（如登錄功能的正確性和錯誤處理），錯誤處理情況（如輸入錯誤密碼時的提示信息）
- 性能 (Performance)：主要考慮軟體在高負載下的表現。包括：伺服器每秒能處理多少請求數、現有硬體配置是否滿足需求（如 CPU、記憶體）、優化以滿足預期的用戶數量（如 20 萬在線用戶）。
- 相容性 (Compatibility)：主要考慮軟體在不同軟硬體環境下的表現。包括瀏覽器相容性（如 Chrome、Firefox、Safari、IE、Edge 等五大瀏覽器）、操作系統相容性（如 Windows 7/8/10/11, macOS, Linux 等）、移動設備相容性（如解析度、品牌、操作系統版本、網路類型等）以及與其他應用的相容性（如支付寶、微信等）。
- 易用性 (Usability)：主要考慮軟體是否易於使用。包括：介面簡潔性、用戶友好性（如操作流暢、文字清晰）、美觀度（如介面設計）。
- 可靠性 (Reliability)：主要考慮軟體在各種條件下的穩定性和無故障運行能力。包括：無響應（如登錄時無反應）、卡頓（如遊戲過程中卡頓）、死機（如軟體崩潰）。
- 安全性 (Security)：主要考慮軟體在數據傳輸和存儲過程中的安全性。包括數據傳輸加密（如登錄時的密碼傳輸）、數據存儲加密（如資料庫中的敏感信息）。
- 可維護性 (Maintainability)：主要考慮軟體在後期維護和更新時的便利性。包括代碼的整潔性和註釋、代碼模組化和分離、網路和硬體的標籤和整理。
- 可攜帶性 (Portability)：主要考慮軟體在不同平台和環境下的遷移能力。包括數據遷移的便捷性（如伺服器升級時的數據遷移）、軟體在不同硬體上的安裝和運行。
功能性、性能、相容性、易用性和安全性是重中之重，通常也是必測的內容。
測試流程#
- 需求評審 (Requirement Review)：專案開始時，產品、開發和測試團隊共同審查需求文件，確保各方對需求的理解一致，並識別核心功能和重要需求。
- 計劃編寫 (Test Planning)：根據需求評審的結果，編寫詳細的測試計劃。哪些功能需要測試，誰來做這些測試，如何進行測試（採取什麼測試策略。比如相容性、性能等），測試時間表安排等等。
- 用例設計 (Test Case Design)：根據測試計劃，設計具體的測試用例。每個測試用例包含測試步驟、輸入數據和預期結果。用例需要覆蓋所有需求和功能點。以確保測試的全面性和可重複性。
- 用例執行 (Test Case Execution)：按照設計好的測試用例進行實際測試，並記錄實際結果。以驗證軟體的功能和性能是否符合需求。同時發現並記錄缺陷。
- 缺陷管理 (Defect Management)：管理和跟蹤發現的缺陷，返給開發人員，直到其被修復。確保所有發現的缺陷都得到及時處理和驗證。
- 測試報告 (Test Report)：總結測試過程和結果，生成測試報告。報告需體現測試覆蓋率、缺陷統計和分析、測試結論和建議。以提供專案的整體測試情況。為決策者提供依據，評估軟體是否可以發布。
編寫測試用例#
編寫測試用例的作用
- 防止漏測：確保所有需求點都被覆蓋，避免遺漏。
- 標準化：提供明確的測試步驟和預期結果，確保測試過程的一致性和可重複性。
格式#
- 用例編號 (Case ID)
格式：專案簡稱_模組簡稱_編號（如：ProjectName_ModuleName_001）
目的：唯一標識每個測試用例，便於管理和追蹤。 - 用例標題 (Title)
格式：期望結果 + 功能描述
目的：簡明扼要地描述該用例的測試目標，方便評審人員快速理解。 - 專案 / 模組 (Project/Module)
內容：指出該用例屬於哪個專案或模組。
目的：明確測試範圍，便於分類管理。 - 優先級 (Priority)
等級：P0 (最高) 到 P4 (最低)
目的：確定測試用例的執行順序，核心功能（用戶使用頻率最高）通常設為 P0。 - 前置條件 (Preconditions)
內容：執行該用例前必須滿足的條件。
目的：確保測試環境和狀態正確，避免因環境問題導致測試失敗。 - 操作步驟 (Steps)
內容：詳細的測試步驟，包括每一步的具體操作。
目的：提供清晰的操作指南，確保測試人員能夠按照相同的步驟進行測試。 - 測試數據 (Test Data)
內容：測試過程中使用的具體數據。
目的：確保測試數據的一致性和準確性，便於復現問題。 - 期望結果 (Expected Result)
內容：測試執行後應達到的結果。
目的：對比實際結果與預期結果，判斷測試是否通過。
測試用例設計#
等價類劃分法#
屬於黑盒測試技術。將輸入數據劃分為不同的等價類。選取代表性的數據進行測試。減少用例數量，提高測試效率。
等價類分類
- 有效等價類：滿足需求的數據集合。
- 無效等價類：不滿足需求的數據集合。
如何劃分等價類
- 明確需求：理解需求並確定劃分依據（如性別、年齡等）。
- 劃分等價類：根據需求將數據劃分為有效和無效等價類。
- 提取數據：從每個等價類中選擇代表性數據。
- 編寫測試用例：基於提取的數據編寫測試用例
案例 1
假設有一個驗證 QQ 帳號合法性的需求，要求 QQ 帳號為 6 到 10 位自然數。以下是如何使用等價類劃分法來設計測試用例：
- 有效等價類：
8 位自然數（例如：12345678）【長度校驗】 - 無效等價類：
小於 6 位的自然數（例如：123）【長度校驗】
大於 10 位的自然數（例如：12345678901）【長度校驗】
8 位非自然數（例如：1234567a）【類型校驗】
QQ 號為空【類型校驗】
邊界值分析法#
需要分別考慮：
- 上點（On Point）：剛好等於邊界值的數據。
- 離點（Off Point）：距離邊界值最近的數據，包括剛好大於和剛好小於邊界值的數據。
- 內點（In Point）：區間內的數據，通常取居中的值。
案例 2
假設有一個需求，判斷一個數是否小於 - 99 或大於 99，如果滿足條件則給出錯誤提示。
- 上點：-99，99
- 離點：-100，-98，100，98
- 內點：0（或其他區間內的值，如 50）
然後分別設計測試用例來考慮
判定表（Decision Table）法#
判定表是一種黑盒測試技術，通過表格的形式將多個條件及其組合與相應的操作結果進行羅列，從而幫助設計測試用例。【解決條件依賴問題】
關鍵名詞
- 條件樁（Condition Stubs）：列出所有條件。
- 動作樁（Action Stubs）：列出所有可能的操作或結果。
- 條件項（Condition Entries）：每個條件的具體取值（通常是 “是” 或 “否”）。
- 動作項（Action Entries）：根據條件項的組合確定的動作結果。
步驟
- 明確需求：理解需求中的條件和結果。
- 繪製判定表：
- 填寫條件樁和動作樁。
- 根據條件樁填寫條件項。
- 根據條件項組合填寫動作項。
- 編寫測試用例：基於判定表生成測試用例。
案例
假設有一個需求，涉及兩個條件：用戶是否欠費和用戶手機是否關機。具體規則如下：
如果用戶欠費且手機關機，則不允許撥打電話。
如果用戶欠費但手機未關機，則允許撥打電話。
如果用戶不欠費且手機關機，則允許撥打電話。
如果用戶不欠費且手機未關機，則允許撥打電話。
| 用戶是否欠費（條件樁） | 手機是否關機（條件樁） | 是否允許撥打電話（動作樁） |
|---|---|---|
| 是 | 是 | 不允許 |
| 是 | 否 | 允許 |
| 否 | 是 | 允許 |
| 否 | 否 | 允許 |
然後根據判定表設計用例。
場景法#
通過模擬用戶使用軟體的實際過程來設計測試用例。這種方法通常基於業務流程圖或使用案例來確保整個業務流程能夠順利運行。
作用
- 覆蓋業務流程：確保所有關鍵業務流程都能被正確執行。
- 提高用戶體驗：從用戶角度出發，確保軟體滿足實際使用需求。
步驟
- 明確需求：理解業務流程的具體要求。
- 繪製流程圖：包括開始、結束、判斷和處理步驟。
- 編寫測試用例：基於流程圖生成測試用例，確保覆蓋所有業務路徑。
案例
假設有一個簡單的登錄系統，用戶需要輸入用戶名和密碼進行驗證。具體規則如下：
如果用戶名為 admin 且密碼為 123456，則登錄成功。
否則，登錄失敗。
首先要繪製流程圖。（省略）
然後編寫測試用例。
錯誤推測法#
錯誤推測法是一種基於經驗和直覺來設計測試用例的方法。它依賴於測試人員的經驗和對類似專案的了解，以推測系統可能出現的問題。
- 快速發現缺陷：通過經驗快速識別可能存在的問題。
- 補充其他方法：作為其他測試方法的補充，確保測試覆蓋更全面
主要思想
- 列舉問題清單：根據經驗列出可能出現的問題。
- 分析問題原因：對每個可能的問題進行分析，找出可能的原因。
- 發現缺陷：根據分析結果設計測試用例，驗證並發現缺陷。
使用場景 - 時間緊、任務量大：當專案時間緊迫且任務繁重時，無法進行全面詳細的測試。
- 專案後期：當所有計劃內的測試用例都已執行完畢，並且已知的缺陷已被修復，但距離上線還有一段時間時，可以使用錯誤推測法進行最後的復測。
案例
假設一個電商專案即將上線，所有的計劃內測試用例已經執行完畢，並且已知的缺陷也已經被修復。此時距離上線還有幾個小時的時間，可以採用錯誤推測法進行最後的檢查。
測試步驟
- 回顧經驗：回憶過去在類似專案中遇到的問題。
- 列出問題清單：
a) 用戶登錄過程中可能的異常情況（如密碼輸入錯誤次數限制、驗證碼失效等）。
b) 購物車功能中的邊界條件（如添加大量商品後的響應）。
c) 支付過程中的網路中斷或支付失敗的情況。 - 設計測試用例：基於上述清單設計測試用例。
- 執行測試：根據設計的測試用例進行測試，驗證是否存在這些問題。
軟體缺陷管理#
軟體缺陷是指在使用過程中存在的任何問題，不僅僅是代碼錯誤，還包括功能缺失、性能問題、易用性問題等
產生原因
- 需求階段：需求描述不清晰或有歧義。
- 設計階段：設計錯誤或不合理。
- 編碼階段：編寫代碼時的錯誤（如邏輯錯誤、語法錯誤或其他編程錯誤）
- 運行階段：比如相容性問題或其他環境問題。（比如在某個系統某個版本上程式會崩潰）
評定標準
- 未實現需求規格說明中的明確要求的功能：如果軟體沒有實現客戶或產品文件中明確要求的功能，則視為缺陷。
例如，如果合同規定了十個功能，但實際交付了八個功能，即使這八個功能完美無缺，仍然是有缺陷的。 - 出現需求說明書指明不應該出現的錯誤：這包括功能上的邏輯錯誤，如計算錯誤或不符合預期的行為。
例如，要求 1+1=3，但軟體實現了 1+1=2；或者要求只能通過身份證號登錄，但軟體允許手機號登錄。 - 超出需求說明書指明的範圍：即使是額外的功能，如果這些功能未經請求且可能帶來負面影響，也會被視為缺陷。
例如，電商軟體提供了一個未經請求的功能，允許用戶隨意退貨，而實際上應該有一個嚴格的審批流程。 - 未實現需求規格書中雖未指明但應實現的要求：指的是隱性功能，即雖然需求文件中沒有明確指出，但根據常識和用戶體驗應該實現的功能。
例如，預期結果中的一些非功能性需求，如用戶友好性和交互體驗。 - 軟體難以理解、不易使用、運行緩慢：
從測試人員的專業角度出發，如果軟體難以理解、不易使用或運行緩慢，也被視為缺陷。
測試人員需要站在用戶的角度考慮軟體的易用性和用戶體驗。
缺陷管理流程
- 發現缺陷：在測試過程中發現不符合上述標準的問題。
- 記錄缺陷：使用工具（如 JIRA、Bugzilla 等）或 Excel 記錄缺陷，包括缺陷描述、重現步驟、嚴重程度等。
- 分配缺陷：將缺陷分配給相應的開發人員進行修復。
- 修復缺陷：開發人員修復缺陷，並提交修復後的版本。
- 驗證缺陷：測試人員驗證修復後的版本，確認缺陷是否已解決。
- 關閉缺陷：如果缺陷已解決，關閉缺陷；否則，重新分配並繼續修復。
缺陷生命周期
- 注入缺陷：在需求、設計、編碼等階段，由於各種原因（如需求不明確、設計錯誤、編碼錯誤）而引入的缺陷。
- 發現缺陷：測試人員通過測試用例執行，發現並記錄缺陷。
- 分類和優先級劃分：根據缺陷的嚴重程度和影響範圍，對其進行分類和優先級劃分。
- 分配和修復：將缺陷分配給相應的開發人員進行修復。
- 驗證缺陷：測試人員驗證修復後的缺陷，確認是否已解決。
- 關閉缺陷：如果缺陷已解決，關閉缺陷；否則，重新分配並繼續修復。
- 回歸測試：修復缺陷後，進行回歸測試以確保新修復的代碼沒有引入新的缺陷。
工具
缺陷管理工具：JIRA, Bugzilla, Mantis, TestRail 等。
電子表格：Excel 也可以用於簡單的缺陷跟蹤。
任何一個階段的問題都會影響整個專案的質量（木桶效應） 所以每個階段都需要嚴格把關。
缺陷報告與提交#
如何描述軟體缺陷
- 缺陷標題：簡潔明瞭地描述缺陷的核心問題。例如：“用戶登錄時密碼輸入框無法顯示星號。”
- 前置條件：描述在復現缺陷之前必須滿足的條件。例如：“用戶已註冊帳號，並處於未登錄狀態。”
- 復現步驟：詳細列出復現缺陷的具體步驟。例如：“1. 打開登錄頁面；2. 輸入用戶名；3. 輸入密碼；4. 點擊登錄按鈕。”
- 預期結果：描述執行上述步驟後應得到的結果。
例如：“用戶成功登錄系統。” - 實際結果：描述執行上述步驟後實際得到的結果。例如：“用戶無法登錄，頁面提示‘密碼格式錯誤’。”
- 附件（可選）：提供有助於理解和復現缺陷的附加信息，如截圖、日誌文件等。例如：附上登錄頁面的截圖和錯誤日誌。
缺陷提交
一般通過缺陷管理工具來填寫。通常還需要包括以下信息。
- 缺陷編號：每個缺陷都有一個唯一的編號，便於跟蹤和管理。
- 嚴重程度：通常分為 S1（非常嚴重）、S2（嚴重）、S3（一般）、S4（輕微）等。例如：主功能模組的問題通常是 S1 或 S2，次要功能模組的問題可能是 S3 或 S4。
- 優先級：通常分為 P1（緊急）、P2（高）、P3（中）、P4（低）等。例如：P1 級別的缺陷要求 24 小時內解決，P2 級別的缺陷要求發布前解決。
- 缺陷類型：包括代碼錯誤、相容性問題、設計缺陷、性能問題等。例如：選擇 “代碼錯誤” 表示是編程上的問題，“相容性問題” 表示不同環境下的問題。
- 缺陷狀態：常見的狀態有新建（New）、打開（Open）、關閉（Closed）、延期（Deferred）等。例如：新建表示剛剛提交的缺陷，打開表示正在處理中的缺陷，關閉表示已修復的缺陷。
缺陷類型
- 功能性錯誤：軟體的功能沒有按預期工作。例如：某個按鈕點擊後沒有響應。
- 介面 / UI 錯誤：用戶介面的問題，如佈局不正確、圖片顯示不全等。例如：登錄頁面的 Logo 顯示不完整。
- 相容性問題：軟體在不同的操作系統或瀏覽器中表現不一致。例如：在 Chrome 中正常，在 Firefox 中無法使用。
- 數據問題：資料庫相關的問題，如數據丟失、數據不一致等。例如：用戶數據在資料庫中未能正確存儲。
- 易用性問題：軟體的用戶體驗問題，如操作複雜、導航不直觀等。例如：用戶難以找到某個功能的入口。
- 建議性問題：對軟體功能或介面的改進建議。例如：建議增加夜間模式。
- 架構設計缺陷：軟體架構設計上的問題，可能導致整體性能或穩定性問題。例如：資料庫連接池配置不合理導致性能瓶頸。
缺陷管理工具
可以使用 DevOps 工具即可代勞。比如禪道。或其他軟體。
集成了產品管理、專案管理和質量管理。能夠明確產品、研發、測試和專案管理的角色及其職責。
DevOps 一詞的來自於 Development 和 Operations 的組合。突出重視軟體開發人員和運維人員的溝通合作。通過自動化流程來使得軟體構建、測試、發布更加快捷、頻繁和可靠。