1.1 軟件的分類
1.1.1 軟件的定義
一系列按照特定順序組織的計算機數據和指令的集合。
軟件 = 數據 + 指令 + 文檔
問題：常見軟件有哪些？
1.1.2 根據應用場景分類
工具類軟件、游戲型軟件、媒體型軟件、電商型軟件等
1.1.3 根據軟件架構分類
單機版軟件、分布式軟件
單機版軟件：office、紅警等
分布式軟件：
C/S架構軟件：客戶端需安裝專門軟件，如QQ 微信等
B/S架構軟件：客戶端為瀏覽器 ，如百度、hao123等
1.2 軟件測試的定義與原則
1.2.1 為什么需要軟件測試
阿麗亞娜5號火箭.jpg
事故：阿麗亞娜5號火箭爆炸，造成重大經濟損失。
原因：程序中試圖將64位浮點數轉換成16位整數時發生溢出-----缺少錯誤程序對數據溢出進行管理
image.png
事故：拼多多2019年用戶可以領取100元無門檻券。
原因：程序中試圖將64位浮點數轉換成16位整數時發生溢出-----缺少錯誤程序對數據溢出進行管理
1.2.2 軟件測試的定義
通過人工或自動化的方式來驗證軟件的實際結果與用戶需求是否一致的過程
1.2.3 軟件測試的原則
原則一：測試顯示軟件存在缺陷
測試只能證明軟件中存在缺陷，但并不能證明軟件中不存在缺陷。軟件測試是為了降低存在缺陷的可能性，即便是沒有找到缺陷，也不能證明軟件是完美的。
原則二：窮盡測試是不可能的
現在軟件的規模越來越大，復雜度越來越高，想做到完全性的測試是不可能的。在測試階段，測試人員可以根據風險和優先級來進行集中和高強度的測試，從而保證軟件的質量。
原則三：測試盡早介入
為什么測試要盡早介入呢，簡單的說就是保證軟件質量，降低風險和成本。測試人員一般在需求階段就開始介入，使缺陷在需求或設計階段就被發現，缺陷發現越早，修復的成本就越小。
原則四：缺陷集群性（2/8原則）
缺陷集群性表明小部分模塊包含大部分的缺陷。軟件測試中存在Pareto原則：80%的缺陷發現在20%的模塊中。
一個功能模塊發現的缺陷越高，那存在的未被發現的缺陷也越高，故發現的缺陷與未發現的缺陷成正比。
原則五：殺蟲劑悖論
反復使用相同的殺蟲劑會導致害蟲對殺蟲劑產生免疫而無法殺死害蟲。軟件測試也一樣。如果一直使用相同的測試方法或手段，可能無法發現新的bug。
為了解決這個問題，測試用例應當定期修訂和評審，增加新的或不同的測試用例幫助發現更多的缺陷。
測試人員不能一直依賴于現有的測試技術，而要不斷的提升測試方法以提高測試效率。
原則六：測試活動依賴于測試內容
根據業務的不同，軟件測試內部也分為不同的行業，比如游戲行業、電商行業、金融行業。不同的行業，測試活動的開展都有所不同，比如測試技術、測試工具的選擇，測試流程都不盡相同，所以軟件測試的活動開展依賴于所測試的內容。
原則七：沒有錯誤是好是謬論
有可能99%沒有bug的軟件也是不能使用的。如果對錯誤的需求進行了徹底的測試，這種情況就發生了。軟件測試不僅是找出缺陷，同時也需要確認軟件是否滿足需求。如果開發出來的產品不滿足用戶的需求，即便找到和修復了缺陷也作用不大。
原則八：程序員應避免檢查自己的程序
原則九：嚴格執行測試計劃，排除測試的隨意性
原則十：應當對每一個測試結果做全面的檢查
原則十一：妥善保存測試計劃、測試用例、出錯統計和最終分析報告，為維護提供方便
原則十二：設計測試用例時，應當包括合理的輸入數據和不合理的輸入數據
原則十三：測試用例應由測試數據和與之對應的預期輸出結果這兩部分組成
1.3 開發與測試模型的介紹
1.3.1 開發模型
瀑布模型：
引入：做飯最終不能返回
定義：將軟件生命周期的各項活動規定為按固定順序而連接的若干階段工作，形如瀑布流水，最終得到軟件產品的項目。
瀑布模型.jpg
優點：
為項目提供了按階段劃分的檢查點
當前一階段完成后，只需要去關注后續階段。
缺點：
各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量。
由于開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。
通過過多的強制完成日期和里程碑來跟蹤各個項目階段。
瀑布模型的突出缺點是不適應用戶需求的變化。
快速原型模型：在需求分析階段對軟件的需求進行初步而非完全的分析和定義，用戶與開發者在過程中加強反饋，快速設計開發出軟件系統可以運行的模型；
增量模型：把待開發的軟件系統模塊化，第1個增量往往是產品的核心，將每個模塊作為一個增量組件，從而分批次地分析、設計、編碼和測試這些增量組件；
敏捷開發：先選擇產品，再進行開會、對產品計劃，然后對任務進行分工，分工后開始按照計劃執行，然后就做出了新的功能模塊，然后再進行演示、回顧，最后再領取新的任務，依次循環。
1.3.2 測試模型
V模型：
V 模型的左邊下降的是開發過程各階段，與此相對應的是右邊上升的部分，即各測試過程的各個階段。
V 模型的優點在于它非常明確地標明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發各階段的對應關系。
V模型.jpg
W模型：
相對于V模型，W模型更科學。W模型是V模型的發展，強調的是測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利于盡早地發現問題。
W模型.jpg
1.4 軟件測試的流程
階段名工作內容產出物測試準備階段項目立項、需求分析、需求評審需求文檔、產品PRD測試計劃階段編寫測試計劃、計劃評審測試計劃測試設計階段提取測試點、編寫測試用例、用例評審測試用例測試執行階段冒煙測試、執行測試用例、提bug、回歸測試缺陷報告測試完成階段驗收測試、編寫測試報告、項目上線測試報告
image.png
1.5 軟件測試的分類
image.png
1.5.1 按技術劃分
黑盒測試、白盒測試、灰盒測試
黑盒測試(Black Box -Test)：把被測試的軟件看做一個黑盒子，我們不去關心盒子里邊的結構是什么樣子，只關心軟件的輸入數據和輸出結果
有人把黑盒測試比作中醫，通過“望聞問切”來判斷是否有問題。
“望”：觀察軟件的行為是否正常。
“聞”：檢查輸出的結果是否正確。
“問”：輸入各種信息，結合“望”，“聞”來觀察軟件的響應。
“切”：像中醫一樣給軟件“把把脈”，敲擊一下軟件的某些“關節”
白盒測試：是一種按照程序內部邏輯結構和編碼結構設計測試數據并完成測試的測試方法
灰盒測試：一種基于程序運行時的外部表現同時又結合程序內部結構來設計測試數據的測試方法
image.png
1.5.2 按階段劃分
單元測試、集成測試、系統測試、驗收測試
單元測試：對一個模塊、一個函數或者一個類來進行正確性檢驗的測試方法
集成測試：單元測試后，將單獨的模塊按照設計要求組裝成為子系統或系統，作為整體進行測試的測試方法
系統測試：集成測試后，將硬件、軟件看作一個整體,對系統的功能及性能的總體測試
驗收測試：系統測試后以用戶測試為主，或有測試人員共同參與檢驗軟件質量的測試方法
image.png
1.5.3 按內容劃分
功能測試、性能測試、兼容性測試
1.5.3.1 功能測試：
界面測試、冒煙測試、回歸測試、業務邏輯測試、易用性測試
功能測試：根據產品操作描述和需求文檔，測試一個產品的特性和可操作行為是否滿足用戶需求的測試方法
界面測試：測試用戶界面的功能模塊的布局是否符合客戶使用習慣，界面操作便捷性、導航簡單易懂性的測試
冒煙測試：驗證系統的核心功能是否能夠正常運行的測試方法
回歸測試：指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤的測試方法
業務邏輯測試：在基本的功能點都已合格的基礎上，準備多種測試數據，來驅動各種約束條件下業務流程，確定最終輸出的結果是否符合預期的測試
易用性測試：指用戶使用軟件時是否感覺方便的測試
1.5.3.2 性能測試：
性能測試：通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行校驗的測試方法
壓力測試：通過逐步增加系統負載，測試系統性能的變化，并確定在什么條件下系統性能處于失效狀態
負載測試：通過逐步增加系統負載，測試系統性能的變化，在滿足性能指標的情況下，系統所能承受的最大負載量的測試
并發測試：是一個負載測試和壓力測試的過程，即逐漸增加并發用戶數負載直到系統的瓶頸，通過分析資源監控指標等來確定系統并發性能
1.5.3.3 兼容性測試：
冒煙測試、隨機測試、安全性測試、探索性測試、回歸測試、Alpha測試、Beta測試
隨機測試：隨機測試主要是根據測試者的經驗無需測試用例對軟件進行功能和性能抽查的測試方法
安全性測試：通過不同的測試方法，檢驗程序、網絡、數據庫安全性的測試方法
探索性測試：碰到問題時能隨機應變，強調測試人員的主觀能動性明確整體的測試計劃的測試方法
Alpha測試：俗稱內測，α測試。內部環境下的測試；開發人員或測試人員在現場
Beta測試：俗稱外測、公測，β測試。生產環境下的測試；開發人員和測試人員都不在現場
1.5.4 按其他劃分
冒煙測試、隨機測試、安全性測試、探索性測試、回歸測試、Alpha測試、Beta測試
隨機測試：隨機測試主要是根據測試者的經驗無需測試用例對軟件進行功能和性能抽查的測試方法
安全性測試：通過不同的測試方法，檢驗程序、網絡、數據庫安全性的測試方法
探索性測試：碰到問題時能隨機應變，強調測試人員的主觀能動性明確整體的測試計劃的測試方法
Alpha測試：俗稱內測，α測試。內部環境下的測試；開發人員或測試人員在現場
Beta測試：俗稱外測、公測，β測試。生產環境下的測試；開發人員和測試人員都不在現場3
