什麼是測試軟體：
軟體測試是指對軟體系統進行評估和驗證的過程，以發現軟體中存在的缺陷、錯誤和不符合規範的行為。
測試從以下角度考慮：
功能性測試、需求測試、介面測試、安全性測試、相容性測試、可靠性測試、可移植測試、易用性測試、壓力測試、
軟體測試知識：
1、為什麼要測試？
（1）程式碼是人寫的，難免會出錯
（2）軟體本身就會存在問題，非正常執行也會問題
（3）環境會影響軟體出現問題
（4）軟體測試活動是保證軟體測試質量之一
2、測試的定義什麼？（重點）
製造業定義：以檢驗產品是否滿足需求為目標
軟體行業定義：
a、驗證軟體的正確性
b、發現軟體中的缺陷（找bug）
3、軟體生命週期？
指的是軟體從產生到報廢的整個過程，是一種時間的概念。
4、軟體生命週期包括哪些階段？
（1）問題引入或定義
（2）可行性分析（涉及經濟，政治，法律，技術）
（3）專案招投標
（4）專案立項
（5）需求分析
（6）開發階段（設計，編碼，測試）
（7）維護
5、軟體什麼週期模型有些？
• --瀑布模型(waterfall) 目前已經淘汰
• --V模型（重點講解）
• --W模型
• --H模型 （重點講解）
• --敏捷開發模型 （重點講解）
• --迭代開發模型
• --增量開發模型
V模型
需求（簡稱：srs） 產品輸出
全稱：軟體需求規格說明書
1、使用者需求
型別：一個文件；
內容：對整個專案的設計、框架、功能、模組的描述
2、概要設計 （開發輸出）
簡稱：（HLD）
型別：文件
內容：架構的初步設計文件，使用說明什麼型別資料庫，架構的描述，設計，模組的名稱
（可理解為：蓋房子的大概設計，基本框架結構）
3、詳細設計
簡稱（LLD）
型別：也是一個文件
內容：針對功能具體的實現，模組的具體實現，具體設計，架構的具體描述，
（可理解為：房子的具體的裝飾設計）
單元測試：
是指驗證軟體單元是否滿足詳細設計文件的規格，能正確的執行，主要是對程式碼的測試.
單元測試也是最小的測試單位；
在工作中單元測試一般情況是開發自測，如果需要測試進行單元測試，對測試的技術要求非常高，必須要懂開發語言；
理解：單元測試，課本上有10個單元一本書（一單元測試）
（2）整合測試
整合測試是指多個單元組合驗證軟體是否滿足概要設計文件的規格，能正常執行，主要是模組與模組之間的資料互動。
理解：課本上有10個單元（有2個單元或2個單元模組以上測試，比如期中考試1-6單元）
（3）系統測試
系統測試是指把軟體進行正常執行，對整個軟體系統進行測試，驗證這個系統能正常的執行，主要是測試一個整體業務的流程。
理解：課本上有10個單元（測試1-10 單元綜合測試）
（4）驗收測試
驗收測試是指：站在使用者角度去對軟體進行測試，驗證系統滿足使用者需求；
驗收測試測試分為兩種：alpha測試（α） 和 bete測試（β）
α測試是內部驗收測試
β測試是客戶方測試
α測試和β測試區別：
1、α測試測試地點：是在自己公司 ；β測試一般在客戶方
2、α測試都是內部人員進行測試，開發在現場及時發現問題，及時解決；
β測試是在客戶方的員工測試，發現問題在反饋給開發在解決
3、α測試測試時間短，技術人員比較集中；
β測試測試時間較長，測試人員不集中；
（1）整合測試（it）和系統測試（st） 合併成（sit測試）
（2）sit測試（系統整合測試）【 技術測試】 ；uat測試（驗收測試）
（3）sit環境 （sit1環境，sit2環境，sit3環境）；uat環境（專門用來驗收環境）
（4）環境：
a.線上環境（也叫生成環境）
b.測試環境：測試人員使用
c、開發環境：開發人員使用
b/s架構和c/s架構（重點）
（1）bs： 瀏覽器------伺服器（web）
b：broeser 瀏覽器
s：server 伺服器
bs的應用：
論壇，百度，知乎，豆瓣，csdn，部落格園
（2）cs架構： 客戶端-----伺服器（app）
c：client 客戶端
s：server 伺服器
cs應用：抖音 ，微信，qq，快手，酷狗
區別：
（1）bs 不需要更新，直接透過瀏覽器輸入網址進行訪問；
cs需要下載客戶端才能使用，需要定期更新；
（2）bs 架構對伺服器效能要求高，
cs架構客戶端能分攤部分效能壓力
（3）bs 不會佔用儲存記憶體，
cs會佔用儲存記憶體
優缺點：
（1）bs優點：不需要安裝直接訪問， 伺服器好維護，資訊量比較大，資料多
bs缺點：安全性不高、資訊容易洩露，容易病毒
（2）cs的優點：手機攜帶方便，操作簡單，上傳下載相對較快，安全性高
缺點：需要安裝，升級，更新，維護，服務性相對來說難維護
測試線：
（1）需求澄清會議（產品經理會組織需求會議）
（2）拿到需求，深入分析和了解需求文件
（3）測試經理編寫測試計劃 （重點)
測試計劃：（內容：測試目的，背景，範圍，測試准入，測試準出，環境和資源，測試任務和測試進度，風險及風險管理，測試交付文件）
准入：
開發：需求分析報告，需求規格說明書，概要設計說明書，詳細設計說明書，版本說明書及開發自測報告；
測試：寫好測試計劃，測試用例透過，測試環境搭建好
準出:
a.用例100%執行
b.0bug
c.輸出測試報告
（4）安排任務，測試分析需求，編寫用例
（5）評審用例（測試人員：組內評審（專案評審人員：開發，測試，產品都參加），交叉評審（測試人員之間評審：測試a、測試b、測試c））
（6）用例評審透過以後匯入到用例管理工具中；如：禪道.testlink
(7) 搭建測試環境（運維搭建，自己搭建，測試管理搭建）
（8）開發提交程式碼包，提測（也叫轉測） 要達到准入要求；
（9）測試將程式碼包部署到環境，
（10）進行冒煙測試，冒煙測試透過，進入sit測試，如果，冒煙測試不透過，就把版本打回給開發，開發修改，在提測。
冒煙測試（也叫版本驗證測試）定義：指對新版本的主要功能，基本功能進行測試。
如果透過，那麼冒煙測試透過，如果冒煙測試失敗，那麼就把版本打回給開發進行修改，直到冒煙測試透過
（11）sit系統整合測試（一般一個專案有3次系統整合測試，有些專案週期長也有4次，5次）
（12）第一次sit測試也叫全量測試（把前面寫的所有用例都要進行測試），測試出來的bug，指派給開發（透過bug工具如：禪道），測試小結
(13)開發修改bug，在提交程式碼
（14）測試在第二次部署專案包，在進行第二次sit測試前也要進行冒煙測試，冒煙測試透過以後才能進行第二次sit測試；
第二sit測試和第三sit測試都叫做迴歸測試
迴歸測試：是系統維護階段進行的驗證測試
區別：測試階段不同
冒煙測試是版本提交時第一個測試，迴歸測試是在維護階段測試
（14）第二次sit測試，在將bug提交給開發，開發修改，
（15）第三sit測試，先冒煙測試，在去測試，驗證。。。。。。以此類推，
備註：測試用例的來源：
a、冒煙測試用例
b、驗證上一個版本提交bug的用例
c、測試與bug有關聯的模組用例
d、你認為可疑的測試場景和測試用例
e、測試補充的測試用例和測試場景
（16）直到達到準出：用例100%執行，0bug，
（17）輸出測試報告=========================說明sit測試測完（表示技術測完）
測試報告：
內容：測試目的，測試範圍，測試背景，測試實施日期，測試人員，bug 清單，用例清單，測試結果，
（18）sit測完通知 uat 測試，uat驗收透過，
（19）封板（封裝版本）
（20）等待上線
（21）上線前準備線上資料
（22）上線後線上上測試，
（23）測試沒有bug，如有bug就要分析bug，bug影響程度，影響大，就回退版本，如果影響小就備註下次版本修改
（24）上線成功
================================================
主流程：
產品開需求會議測試和開發拿到需求分析需求=編寫測試計劃（測試經理）編寫測試用例=評審用例，評審透過將用例匯入用例管理工具=搭建環境開發提測，達到准入要求部署專案包到環境中=開始冒煙測試sit1系統整合測試有bug提交給開發開發修改好提交第二次程式碼包=部署專案包到環境中在冒煙測試sit2測試=以此類推直到達到準出要求0bug，用例100%執行輸出測試報告通知uat測試=uat驗收透過封裝版本=等待上線=準備線上資料=上線==線上測試=測試無bug表示上線成功。
================================================
根據講解的H模型：梳理（重點記）
產品拿出需求規格說明書（srs）；召開需求會議，分析需求，熟悉需求；測試負責人拿到需求開始編寫測試計劃；安排測試任務，各自編寫測試用例；編寫完用例後在對用例進行評審（有組內評審，有交叉評審）；評審透過以後，匯入到用例管理工具中；在搭建好環境（運維或測試人員）；開發開發完也要進行提測（達到准入）；測試將程式碼包部署到環境中；在進行冒煙測試，冒煙測試透過（如果冒煙失敗，就打回版本），就進行sit1系統整合測試，將所有測試用例都執行一遍；有bug提交給開發，開發修改，再提交程式碼包；進行第二次sit系統整合測試，也要冒煙測試，冒煙測試以後就開始進行sit2系統整合測試，測試中發現的bug，提交給開發，開發修改，再提交第三次程式碼包，進行第三sit系統整合，以此類推，直到測試用例100%執行，0bug（達到測試準出），輸出測試報告；通知uat驗收，驗收透過；封裝版本，打包，準備線上資料，上線，線上測試，線上測試透過，上線成功。（如果線上有bug根據影響程度判斷：影響大就回退版本，如果影響小，備註好下一個版本解決)
===============================================
自動化部署H模型：（擴充）jenkins自動化部署工程，是自動化部署環境
產品拿出需求規格說明書（srs）；召開需求會議，分析需求，熟悉需求；測試負責人拿到需求開始編寫測試計劃；安排測試任務，各自編寫測試用例；編寫完用例後在對用例進行評審（有組內評審，有交叉評審）；評審透過以後，匯入到用例管理工具中；在搭建好環境（運維或測試人員）；開發開發完也要進行提測（達到准入）；搭建自動部署環境平臺；透過jenkins去構建對應的工程；將程式碼包部署到環境中，在進行冒煙測試，冒煙測試透過（如果冒煙失敗，就打回版本），就進行sit1系統整合測試，將所有測試用例都執行一遍；有bug提交給開發，開發修改，開發體提交程式碼包，合併分支；透過jenkins去構建對應的工程拉取最新的程式碼，進行第二次sit系統整合測試，也要冒煙測試，冒煙測試以後就開始進行sit2系統整合測試，測試中發現的bug，提交給開發，開發修改，透過jenkins去構建對應的工程拉取最新的程式碼，進行第三sit系統整合，以此類推，直到測試用例100%執行，0bug（達到測試準出），輸出測試報告；通知uat驗收，驗收透過；封裝版本，打包，準備線上資料，上線，線上測試，線上測試透過，上線成功。（如果線上有bug根據影響程度判斷：影響大就回退版本，如果影響小，備註好下一個版本解決)