『測試』測試基礎

文章目錄

- 1. 調試與測試的區別
- 2. 開發過程中的需求
- 3. 開發模型
- - 3.1 軟件的生命周期
  - 3.2 瀑布模型
  - - 3.2.1 瀑布模型的特點/缺點
  - 3.3 螺旋模型
  - - 3.3.1 螺旋模型的特點/缺點
  - 3.4 增量模型與迭代模型
  - 3.5 敏捷模型
  - - 3.5.1 Scrum模型
    - 3.5.2 敏捷模型中的測試
- 4 測試模型
- - 4.1 V模型
  - 4.2 W模型(雙V模型)

1. 調試與測試的區別

調試與測試兩詞只有一字之差, 但兩者目的并不相同, 調試的目的在于發現并解決問題, 而測試的目的在于發現問題;

權限

通常在gitee等代碼倉庫中都具有權限管理, 而一般測試人員只有讀權限, 沒有寫權限, 因此測試人員只能讀, 不能寫;
參與角色

測試與調試的人員角色也不同, 通常大部分情況, 調試由開發人員進行, 而測試通常由測試人員進行;

測試人員的主要工作職責是為了保障產品質量, 但產品質量并不只由測試人員保障, 產品質量由整個項目組(產品經理, 前/后端開發, 測試, 交互, 設計…)共同保障;

階段

測試與調試的階段也不同, 調試通常只在開發階段進行, 而測試需要貫穿項目(軟件)的整個生命周期;

測試人員通常是產品質量最后的把關者;

2. 開發過程中的需求

開發過程中一般分為兩種需求, 分別為用戶需求與軟件需求;

用戶需求

一般用戶需求指甲方或是終端用戶使用產品時必須要完成的任務, 通常用戶需求較為簡單;

如:
- 用戶可以隨時查看商品庫存量
軟件需求

軟件需求通常是用戶需求轉化而來, 通常是技術化的描述;

如:
- 系統需為管理員提供實時庫存量查詢接口, 響應時間<=1s;

總而言之用戶需求是用戶(甲方/客戶)以自然語言提出, 反映業務目標和使用場景的, 而軟件需求是由開發團隊通過分析用戶需求轉化而來, 更加表現為技術化的描述;

用戶需求與軟件需求的表現形式不同, 通常用戶需求以業務視角描述, 可能存在模糊性和主觀性, 通常情況下, 用戶需求不會第一時間就被解決, 而是需要對用戶需求進行評估, 分析, 細化等過程轉化為對應的軟件需求才能著手被解決;

軟件需求通常使用結構化文檔, 如例圖, User Story, SRS文檔等進行描述;

用戶需求	軟件需求
口頭描述, 郵件/會議記錄, 業務流程圖	功能需求, 非功能需求, 數據模型

其次用戶需求更關注高層次需求, 如"做什么", 不涉及實現方式;

而軟件需求明確"怎么做", 需具備技術實現細節;

用戶需求典型問題	軟件需求典型問題
- 表述模糊（如"更方便"） - 隱性需求未明示 - 不同用戶需求沖突	- 技術要求不完整（如缺少性能指標） - 需求不可測試（如"代碼要優雅"） - 技術可行性判斷失誤

簡要軟件需求文檔示例(實現用戶注冊功能)

1.1.1.1 注冊賬號
1.1.1.1.1 功能概述
1.1.1.1.1.1 匿名用戶通過郵箱注冊賬戶，需激活后登錄。
1.1.1.1.2 輸入規則

字段名稱	必填性	長度/位數	格式要求	附加規則
姓名	必填	6~15字符	漢字/字母/空格	-
郵箱	必填	-	標準郵箱格式	格式錯誤時提示
密碼	必填	6~15字符	字母+數字組合	兩次輸入不一致時提示
驗證碼	必填	6位數字	純數字	郵箱發送，有效期5分鐘

1.1.1.1.3 處理規則

1.1.1.1.3.1 用戶同意協議后填寫信息，提交時校驗字段合法性：
1.1.1.1.3.1.1 校驗失敗：高亮錯誤字段并提示原因。
1.1.1.1.3.1.2 校驗成功：發送含24小時有效激活鏈接的郵件。

1.1.1.1.4 異常規則
1.1.1.1.4.1 未收到激活郵件：登錄界面可重新發送，每郵件限24小時有效。

1.1.1.1.5 數據規則
1.1.1.1.5.1 存儲表user_account，含user_id（自增主鍵）、email（唯一）、is_activated（默認false）。
1.1.1.1.5.2 密碼SHA-256加鹽存儲，激活鏈接含一次性Token。

1.1.1.1.6 后置條件
1.1.1.1.6.1 未激活賬戶禁止登錄及操作系統功能。

需要明確一點的是并不是所有的用戶需求都是合理的, 因此用戶需求才需要經過評估, 分析等過程轉化為軟件需求;

用戶需求不能直接作為開發和測試的依據, 針對用戶需求, 產品經歷需要進行需求分析(技術可行性, 市場可行性, 成本投入和收益占比等)后才可轉變為軟件需求;

3. 開發模型

3.1 軟件的生命周期

實際上軟件的生命周期就是軟件的開發模型;

軟件生命周期是指軟件從規劃, 需求分析, 設計, 開發, 測試, 部署, 維護到最終退役的完整過程, 是軟件開發的全流程框架, 覆蓋軟件"從生到死"的各個階段;

常見的幾種開發模型有: 瀑布模型, 敏捷模型, 螺旋模型…

瀑布模型生命周期(嚴格線性, 不可逆)

需求分析 -> 設計 -> 編碼 -> 測試 -> 維護
敏捷模型生命周期(持續迭代)

需求 -> 開發 -> 測試 -> 交付 -> 反饋 -> 新需求
螺旋模型生命周期(強調風險管理)

計劃 -> 風險分析 -> 開發 -> 評估 -> 下一輪循環

假設存在一個用戶需求為"郵箱注冊功能", 其生命周期大概為如下:

計劃
1. 目標：明確功能范圍和用戶場景。
  用戶通過郵箱注冊賬號（必填項）。
  需驗證郵箱有效性（發送驗證鏈接或驗證碼）。
  防止重復注冊或惡意注冊（如頻率限制、CAPTCHA）。
需求分析
1. 功能定義：
  郵箱注冊為核心流程，需覆蓋驗證、防重復、安全防護。
  非功能需求：郵件送達率 > 95%，響應時間 < 2秒。
設計
1. 前端設計：
  注冊頁面布局（郵箱輸入框、驗證碼/驗證鏈接觸發按鈕）。
  錯誤提示（郵箱格式錯誤、重復注冊、驗證碼超時）。
2. 后端設計：
  郵箱格式校驗（正則表達式）。
  驗證郵件/短信服務集成（如SMTP、第三方API）。
  數據庫設計（存儲郵箱、密碼哈希、驗證狀態）。
編碼
1. 前端開發：
  實現表單提交邏輯，綁定郵箱驗證接口。
  處理驗證成功/失敗的交互反饋。
2. 后端開發：
  實現郵箱驗證碼生成、存儲（Redis緩存）。
  郵件發送服務調用（異步隊列）。
  用戶信息加密存儲（如bcrypt哈希密碼）。
測試
1. 功能測試：
  正常流程：輸入有效郵箱 → 接收驗證郵件 → 激活賬號。
  異常流程：無效郵箱格式、重復注冊、驗證碼過期/錯誤。
2. 安全測試：
  SQL注入、XSS攻擊防御。
  驗證碼防爆破（限流策略）。
3. 部署驗證：
  灰度發布：先小范圍開放注冊功能，監控異常。
  配置生產環境：郵件服務參數、數據庫連接、日志監控。
運行維護
1. 修復性維護
2. 完善性維護
3. 預防性維護
退役
1. 替代方案：
  逐步遷移用戶至新注冊方式（如手機號登錄）。
2. 數據清理：
  標記廢棄郵箱賬號，歸檔或刪除歷史數據。

不同企業對不同的軟件的生命周期的框架不同, 如可能針對軟件特定的特色功能在不同的階段將會有不同的差異;

3.2 瀑布模型

瀑布模型是最早提出的軟件生命周期模型, 其特點是:

每個流程只執行一次
線性的開發流程

3.2.1 瀑布模型的特點/缺點

瀑布模型最大的缺點在于一個可以運行的產品很遲才能被看到;

假設一個非常簡單的用戶需求被提出, 那么在上述過程, 包括"問題定義, 問題可行性…"等過程的階段時間都很短, 上線過程也會比較快;

但若是出現一個非常復雜的用戶需求被提出時, 對應的各個過程的時間開銷將被延長, 因此可能當前較為流行的功能或者板塊在長時間未上線后在對應功能板塊不再流行時上線, 對應的資源開銷將會貶值(沒有收益/收益太低);

同時瀑布模型還有一個缺點就是, 由于所有流程只執行一次并且是線性執行, 因此如果在開發過程當中某個流程出現了問題后將需要向前追溯, 如測試人員在測試階段發現問題需要反饋給編碼對應人員, 開發人員認為沒有問題將會繼續向前追溯(設計), 以此類推, 這意味追溯甚至可能一直到源頭, 即重新從問題定義, 即瀑布模型的源頭, 否則如果出現問題并未解決的問題將暴露給用戶, 將會降低用戶的使用體驗;

優點/特點	缺點
- 強調開發的階段性 - 線性結構, 每個階段只執行一次 - 是其他模型的基礎框架	1. 測試后置: - 各階段的遺留風險推遲到測試階段才被發現, 導致大面積返工, 失去及早修復的機會 - 必須留有足夠的時間給測試, 否則導致測試不充分, 將缺陷直接暴露給用戶(產品質量差) 2. 周期太長, 產品可能在需求/功能過時時才被看到和使用

瀑布模型的適用場景一般是需求固定的小型項目, 一般不適用于規模龐大, 復雜度高, 風險大的項目;

3.3 螺旋模型

螺旋開發模型的適用場景通常是一些規模龐大, 復雜度高, 風險大的項目;

螺旋模型是基于瀑布模型進行修改的模型, 將螺旋模型進行展開后得到的是一個類似于瀑布模型的"迭代式瀑布模型";

螺旋模型與瀑布模型最大的差別就在于螺旋模型在各階段都引入了風險分析;

同時螺旋模型還引入了原型, 其中原型在螺旋模型中屬于風險緩解工具, 主要用于驗證關鍵技術的可行性與確認需求理解一致性, 原型通常不進入生產代碼, 其生命周期僅限于當前迭代, 若原型驗證失敗, 觸發的則是風險對應策略;

每個階段均以 計劃 -> 風險分析 -> 原型開發 -> 用戶評估 的順序進行;

3.3.1 螺旋模型的特點/缺點

螺旋模型引入了風險分析和原型, 其目的是減少各階段遺留的風險問題, 避免把問題留到后面的階段;

螺旋模型同樣具有缺點, 對一個項目而言, 使用了螺旋模型進行開發, 那么意味著項目組需要存在對應的風險分析人員來進行風險分析;

各階段是否遺留問題取決于風險分析人員, 該項與風險分析人員的技術能力直接掛鉤;

優點/特點	缺點
- 強調嚴格的全過程分析管理 - 強調各開發階段的質量 - 增加風險分析和原型	- 項目中可能存在的風險性與風險管理人員的技能水平有直接關系 - 需求人員, 資金, 時間的增加和投入可能會導致項目成本提高

3.4 增量模型與迭代模型

增量模型

當存在一個需求時, 增量模型旨在將大需求拆分成若干個小需求, 將每個小需求獨立開發上線;

增量模型的每個增量都是一個完整的功能子集, 按照順序開發并逐步集中到系統中;
迭代模型

相比于增量模型而言, 迭代模型同樣會將一個需求細化為幾個小需求, 隨后對小需求進行基本實現, 隨后進行上線, 通過由抽象逐步細化實施將抽象轉化為具象, 不斷優化;

迭代模型中的每一次迭代都可以是一個可運行的版本, 逐步優化功能和設計;

通常情況下迭代模型和增量模型會在一個項目的開發中配合使用;

迭代模型和增量模型的適用場景通常為大型項目, 且需求不明確的場景;

3.5 敏捷模型

敏捷模型又被成為增量開發迭代模型;

目前的開發人員在使用迭代瀑布模型來進行軟件開發時將面臨各種問題, 主要的困難包括在項目開發期間處理來自客戶的變更請求以及合并這些變更所需的高成本時間, 而敏捷模型主要來解決這種問題;

雖然上述的螺旋模型中可以有效的避免問題的遺留, 但在開發過程中, 一款產品的功能是在不斷變化的, 螺旋模型只能避免在計劃過程中的問題遺留, 但無法避免用戶/甲方的需求變更;

相比長期計劃而言, 敏捷模型更強調靈活性和適應性, 相對其他模型而言, 敏捷模型是較為彈性的;

敏捷模型的主要目的是促進項目的快速完成;

通常情況下在敏捷模型中, 需求將被分節為許多可以增量開發的小部分, 敏捷模型采用迭代開發, 每次的迭代都旨在小而易于管理;

一次為客戶計劃, 開發和部署一個迭代, 通常不制定長期計劃, 同時沒有固定的風險分析階段;

在敏捷模型中有一個非常重要的《敏捷宣言》, 其內容為:
- “個體與交互重于過程和工具”
  
  即團隊成員的溝通與合作比講話的流程和工具更為重要, 強調高效的溝通;
- “可用的軟件重于完備的文檔”
  
  即優先交付實際可運行的軟件, 而非追求完美的文檔, 強調輕文檔;
- “客戶協作重于合同談判”
  
  即與客戶持續合作, 而非通過合同條款固定需求, 主動及時了解當下的需求;
- “響應變化重于遵循計劃”
  
  即靈活適應需求變化, 而非死守原始計劃, 能主動迎接變化;
敏捷宣言強調人本, 實用, 協作, 靈活;

目標是快速交付價值并適應變化;

即輕文檔, 輕流程, 重目標, 重產出;

3.5.1 Scrum模型

Scrum模型是敏捷模型中的一種, 其中Scrum中, 主要由三類角色和五個重要會議組成;

三類角色

三類角色分別為產品經理(Product Owner), 項目經理(Scrum Master)以及研發團隊(Team)組成;
- 產品經理(Product Owner)
  
  產品經理通常負責整理User Story, 定義其商業價值, 對其進行排序, 制定發布計劃并對產品負責;
  
  即收集需求, 產出軟件需求文檔;
- 項目經理(Scrum Master)
  
  項目經理負責召開各種會議, 協調項目, 為研發團隊服務;
- 研發團隊(Team)
  
  研發團隊則由不同技能的組員組成, 通過緊密協同, 完成每一次迭代的目標并交付產品;

與瀑布模型不同, Scrum模型將會把產品開發分節為若干個小迭代(Sprint), 其中每個小迭代周期為一周到四周不等, 但通常不會超過四周, 參與的團隊成員通常是5-9人, 每期迭代要完成的User Story是固定的, 每次迭代完成后都會進行向上交付(重目標, 重交付), 而通常瀑布模型需要集所有人的能力進行開發;

在 Scrum 模型的流程中, 主要圍繞五個會議(事件), 分別為發布計劃會議, 迭代計劃會議, 每日例會, 演示會議, 回顧會議;

發布計劃會議(Release Planning Meeting)

通常情況下, 在發布會議中, 產品經理需要負責講解User Story, 對其進行估算和排序, 發布計劃會議產出就是制定出這一期迭代要完成的Story列表, 即Sprint Backlog;
- 目的
  
  確定產品發布的長期目標和范圍, 規劃多個Sprint(迭代)的總體方向;
- 參與者
  
  產品經理, 項目經理, 開發團隊和關鍵利益相關者;
- 關鍵內容
  - 梳理產品代辦列表(Product Backlog)并確定優先級
  - 估算整體時間框架和資源需求
  - 制定發布路線圖
迭代計劃會議(Sprint Planning Meeting)

該會議中項目團隊將要對每一個Story進行任務分解, 分解的標準是完成該Story的所有任務, 每個任務都有明確的負責人, 并完成工時的初估計;
- 目的
  
  為單個Sprint制定詳細任務目標并明確交付內容;
- 參與者
  
  產品經理, 項目經理, 開發團隊
- 關鍵內容
  - 從產品代辦列表中選取本Sprint要完成的高優先級需求
  - 將需求拆解為具體的開發任務 (Sprint Backlog)
  - 估算任務工作量并分配職責
每日例會(Sprint Planning Meeting)

每天項目經理將會召集站立會議, 團隊成員回答昨天做了什么, 今天計劃做什么, 有什么問題;
- 目的
  
  同步團隊進度, 快速識別障礙, 確保Sprint目標順利推進;
- 參與者
  
  開發團隊, 項目經理(主持)
- 關鍵內容(每人回答三個問題)
  - 昨天完成了什么
    
    明確知道每個人的進度;
  - 今天計劃做什么
    
    今日的目標和計劃;
  - 遇到了什么阻礙
    
    及時解決問題能夠保證產品在規定的迭代周期內正常交付;
演示會議(Sprint Review Meeting)

迭代結束后, 召開演示會議, 相關人員受邀參加, 團隊負責向大家展示本次迭代取得的成果, 期間大家的反饋記錄下來, 由產品經理整理, 形成新的Story;
- 目的
  
  向客戶或利益相關者展示Sprint成果, 收集反饋;
- 參與者
  
  產品負責人, 開發團隊, Scrum Master, 客戶/用戶代表;
- 關鍵內容
  - 演示可運行的增量功能
  - 討論反饋并調整后續需求優先級
回顧會議(Sprint Retrospective Meeting)

回顧上一次迭代流程中的問題, 不斷優化;
- 目的
  
  總結Sprint的優缺點, 持續改進團隊協作和流程;
- 參與者
  
  開發團隊, 產品經理, 項目經理
- 關鍵內容
  - 討論"哪些做得好", “哪些需要改進”, “下一步行動”
  - 制定具體的改進措施

會議	核心作用	關鍵產出
發布計劃會議	明確長期目標與路線圖	發布計劃, 優先級排序
迭代計劃會議	制定短期任務清單	Sprint目標, Sprint Backlog
每日例會(站會)	同步進展與解決問題	每日任務清單, 障礙解決方案
演示會議	交付成果并獲取反饋	可運行增量, 需求調整方向
回顧會議	優化團隊協作與流程	改進措施清單(如流程調整)

3.5.2 敏捷模型中的測試

敏捷模型中的測試主要要求輕文檔和快速迭代;

快速迭代

在敏捷模型中的測試需要進行快速迭代, 如在測試過程中的測試用例的迭代速度要快, 需要及時發生變化, 且測試用例要盡可能完整的去寫一確保全面, 確保不會將問題暴露給用戶;
輕文檔

測試人員在測試過程中通常需要撰寫多種文檔, 包括但不限于測試用例, 測試計劃文檔, 測試報告等;

在敏捷開發模型過程中, 測試人員不應該使用傳統的Excel編寫測試用例的方法, 更多的是需要使用類似于思維導圖, 探索性測試(強調自由度, 設計和執行同時進行, 根據測試結果不斷調整測試計劃), 自動化測試等;

在敏捷開發模型過程中, 測試人員應該多主動和開發人員了解需求, 討論設計, 研究Bug出現的原因;

4 測試模型

下文中出現的兩個模型, 即V模型和W模型本質上也是開發模型, 被稱作測試模型的原因在于下列兩個模型更加注重測試, 因此被稱作測試模型;

4.1 V模型

在V模型中, 明確標注了測試過程中存在不同類型的測試;

其中每一階段的測試都需要參考之前的設計或者需求, 如單元測試需要參考詳細設計, 集成測試需要參考概要設計, 系統測試需要參考需求分析與系統, 驗收測試需要參考用戶需求;

通常在V模型中不同的測試階段由不同的人員進行
- 單元測試
  
  一般由開發人員進行測試, 如一個類或是一個函數;
- 集成測試
  
  由開發人員與測試工程師完成, 其中開發人員主導, 測試人員輔助;
- 系統測試
  
  由測試工程師完成;
- 驗收測試
  
  驗收測試通常由客戶或業務代表(最終用戶, 產品經理)進行;