本文轉自測試人社群，原文連結：Jck28-Lucio-測試開發體系介紹 - 學習筆記 - 測試人社群
一、測試體系介紹L1
1、軟體測試基礎概念
1.1、概念
- 通過手工或者工具對 “被測對象”進行測試
- 驗證明際結果與預期結果之間是否存在差異
1.2、 軟體測試作用：
- 通過測試工作可以發現并修複軟體當中存在的缺陷，進而提高使用者對産品的使用信心
- 測試可以降低同類型産品開發遇到問題的風險
2、軟體開發流程
- 為了使軟體開發的工作系統化并且可控制；
- 需要采用合适的軟體開發模型和開發過程管理所有的活動。
2.1、 瀑布模型
- 軟體開發的各項活動嚴格按照線性方式進行。
- 目前活動接受上一項活動的工作結果。
- 目前活動的工作結果需要進行驗證。
需求分析—>設計—>編碼—>實作—>軟體測試—>完成—>維護
:制定計劃;
:需求分析;
:軟體設計;
:程式編碼;
:軟體測試;
:運作維護;
2.2、 靈活開發模型
- 适用于需求頻繁變化和需要快速開發的場景。
- XP
- SCRUM
2.2.1 、 XP - 極限程式設計
2.2.2、 SCRUM
2.3、 DevOps
2.3.1、 DevOps 生命周期
- 持續開發
- 持續測試
- 持續內建
- 持續部署
- 持續監控
2.3.2、 CI/CD
- 持續內建（Continuous Integration，縮寫為 CI）：
- 一種軟體開發實踐。
- 團隊開發成員每天可能會發生多次內建。
- 每次內建都通過自動化的建構（包括編譯，釋出，自動化測試）來驗證。
- 根據測試結果确定新代碼和原有代碼能否正确地內建在一起。
- 持續傳遞（Continuous Delivery，縮寫為 CD）
- 是一種軟體工程手法。
- 讓軟體産品的産出過程在一個短周期内完成。
- 保證軟體可以穩定、持續的保持在随時可以釋出的狀況。
- 目标：
- 讓軟體的建構、測試與釋出變得更快以及更頻繁。
- 減少軟體開發的成本與時間，減少風險。
3、測試流程體系
3.1、軟體測試的原則
- 測試顯示缺陷的存在
- 窮盡測試是不可能的
- 測試盡早介入
- 缺陷叢集性（2/8原則）—缺陷集種在20%的子產品中
- 殺蟲劑悖論—測試用例不能拿來用多次
- 測試活動依賴于測試内容
- 沒有錯誤是号的謬論
3.2、軟體測試對象
- 需求分析階段：需求文檔、接口文檔
- 編碼實作階段：源代碼
- 系統功能使用：軟體程式
3.3、軟體測試模型
3.3.1、V模型
需求分析—>概要設計—>詳細設計—>編碼—>單元測試–>內建測試—>系統測試—>驗收測試
3.3.2、W模型
3.3.2、H模型
3.4、系統測試流程
需求分析—>測試計劃—>測試設計—>用例評審—>測試執行—>-bug關系–>釋出維護
3.5、bug管理流程
3.6、測試左移
- 左移是往測試之前的開發階段移
- 測試團隊在軟體開發周期早起就介入
- 對代碼進行測試
- 發現bug到預防bug
- 代碼評審
- 代碼審計
- 單元測試
- 自動化冒煙測試
- 研發自測
3.7、測試右移
- 右移是往釋出之後移
- 産品上線後進行線上監控
- 閉環的線上問題回報-檢查-解決-更新流程
- 更便捷的日志檢視、回傳服務
- 豐富有效的log、便于問題定位
- 豐富的監控名額（例如業務異常點名額）
- 業務監控（例如短信發送等）
- 關鍵名額每日監控（伺服器名額）
- 生産資料監控（警報）
軟體測試開發免費視訊教程分享 - 公衆号 - 測試人社群