本文轉(zhuǎn)自測試人社區(qū)，原文鏈接：Jck28-Lucio-測試開發(fā)體系介紹 – 學習筆記 – 測試人社區(qū)

一、測試體系介紹L1

1、軟件測試基礎概念

1.1、概念

• 通過手工或者工具對 “被測對象”進行測試
• 驗證實際結(jié)果與預期結(jié)果之間是否存在差異

1.2、 軟件測試作用：

• 通過測試工作可以發(fā)現(xiàn)并修復軟件當中存在的缺陷，從而提高用戶對產(chǎn)品的使用信心
• 測試可以降低同類型產(chǎn)品開發(fā)遇到問題的風險

2、軟件開發(fā)流程

• 為了使軟件開發(fā)的工作系統(tǒng)化并且可控制；
• 需要采用合適的軟件開發(fā)模型和開發(fā)過程管理所有的活動。

2.1、 瀑布模型

• 軟件開發(fā)的各項活動嚴格按照線性方式進行。
• 當前活動接受上一項活動的工作結(jié)果。
• 當前活動的工作結(jié)果需要進行驗證。

需求分析—>設計—>編碼—>實現(xiàn)—>軟件測試—>完成—>維護
:制定計劃;
:需求分析;
:軟件設計;
:程序編碼;
:軟件測試;
:運行維護;

2.2、 敏捷開發(fā)模型

• 適用于需求頻繁變化和需要快速開發(fā)的場景。
• XP
• SCRUM

2.2.1 、 XP – 極限編程

2.2.2、 SCRUM

2.3、 DevOps

2.3.1、 DevOps 生命周期

• 持續(xù)開發(fā)
• 持續(xù)測試
• 持續(xù)集成
• 持續(xù)部署
• 持續(xù)監(jiān)控

2.3.2、 CI/CD

• 持續(xù)集成（Continuous Integration，縮寫為 CI）：
• 一種軟件開發(fā)實踐。
• 團隊開發(fā)成員每天可能會發(fā)生多次集成。
• 每次集成都通過自動化的構(gòu)建（包括編譯，發(fā)布，自動化測試）來驗證。
• 根據(jù)測試結(jié)果確定新代碼和原有代碼能否正確地集成在一起。

• 持續(xù)交付（Continuous Delivery，縮寫為 CD）
• 是一種軟件工程手法。
• 讓軟件產(chǎn)品的產(chǎn)出過程在一個短周期內(nèi)完成。
• 保證軟件可以穩(wěn)定、持續(xù)的保持在隨時可以發(fā)布的狀況。
• 目標：
• 讓軟件的構(gòu)建、測試與發(fā)布變得更快以及更頻繁。
• 減少軟件開發(fā)的成本與時間，減少風險。

3、測試流程體系

3.1、軟件測試的原則

• 測試顯示缺陷的存在
• 窮盡測試是不可能的
• 測試盡早介入
• 缺陷集群性（2/8原則）—缺陷集種在20%的模塊中
• 殺蟲劑悖論—測試用例不能拿來用多次
• 測試活動依賴于測試內(nèi)容
• 沒有錯誤是號的謬論

3.2、軟件測試對象

• 需求分析階段：需求文檔、接口文檔
• 編碼實現(xiàn)階段：源代碼
• 系統(tǒng)功能使用：軟件程序

3.3、軟件測試模型

3.3.1、V模型

需求分析—>概要設計—>詳細設計—>編碼—>單元測試–>集成測試—>系統(tǒng)測試—>驗收測試

3.3.2、W模型

3.3.2、H模型

3.4、系統(tǒng)測試流程

需求分析—>測試計劃—>測試設計—>用例評審—>測試執(zhí)行—>-bug關(guān)系–>發(fā)布維護

3.5、bug管理流程

3.6、測試左移

• 左移是往測試之前的開發(fā)階段移
• 測試團隊在軟件開發(fā)周期早起就介入
• 對代碼進行測試
• 發(fā)現(xiàn)bug到預防bug
• 代碼評審
• 代碼審計
• 單元測試
• 自動化冒煙測試
• 研發(fā)自測

3.7、測試右移

• 右移是往發(fā)布之后移
• 產(chǎn)品上線后進行線上監(jiān)控
• 閉環(huán)的線上問題反饋-檢查-解決-更新流程
• 更便捷的日志查看、回傳服務
• 豐富有效的log、便于問題定位
• 豐富的監(jiān)控指標（例如業(yè)務異常點指標）
• 業(yè)務監(jiān)控（例如短信發(fā)送等）
• 關(guān)鍵指標每日監(jiān)控（服務器指標）
• 生產(chǎn)數(shù)據(jù)監(jiān)控（警報）

軟件測試開發(fā)免費視頻教程分享 – 公眾號 – 測試人社區(qū)