##### `（一）軟體測試的定義` 在`規定的條件`下對程式進行操作，以`發現程式錯誤`，`衡量軟體質量`，並對其是否能`滿足設計要求`進行評估的過程。 ##### `（二）軟體測試方法的分類` > 按開發階段劃分： 1. 單元測試（Unit Testing） 又稱`模組`測試。對軟體的組成單位進行測試，其目的是`檢驗軟體基本組成單位的正確性`。測試的物件是軟體測試的最小單位：模組。【例如：登入測試】 2. 整合測試（Integration Testing） 整合測試也稱`聯合測試（聯調）、組裝測試`：將程式模組採用適當的整合策略組裝起來，`對系統的介面及整合後的功能進行正確性檢測`的測試工作。整合主要目的是檢查軟體單位之間的介面是否正確。【例如：京東購物用微信支付】 3. 系統測試（System Testing） 將軟體系統看成是一個系統的測試。包括`對功能、效能以及軟體所執行的軟硬體環境進行測試`。時間大部分在系統測試執行階段，包括迴歸測試和冒煙測試。 【例如：房子能不能住人（功能） 房子抗不抗颱風（效能）； ​ QQ能不能註冊，能不能登入，能不能聊天發訊息（功能） 人數太多會不會卡頓（效能）】 :monkey:==Tips：系統測試如何開展？== ==需求評審（功能需求、效能需求、介面需求） - 測試計劃 - 測試用例 - 用例評審 - 測試環境搭建（平臺、架構、web伺服器、資料庫） - 執行用例 - 提交問題 - 缺陷的跟蹤和迴歸測試 - 測試報告== 4. 驗收測試（Acceptance Testing） 是部署軟體前的最後一個測試操作。它是技術測試的最後一個階段，也稱為`交付測試`。`向軟體購買者展示該軟體系統滿足原始需求`。 ==實施驗收測試的策略有三種：== - `正式驗收測試` - 非正式驗收測試或`α測試` - `β測試` > 按是否手工執行劃分： 1. 手工測試（Manual Testing） 手工測試是`由人一個一個的輸入用例，然後觀察結果`，和機器測試（指使用機器去測試，例如：手機、電腦）相對應，屬於`比較原始但是必須的一種`。 2. 自動化測試（Automation Testing） 所謂自動化測試，就是`在預設條件下執行系統或應用程式，評估執行結果`。（預先條件包括：正常條件和異常條件）。簡單來說，自動化測試就是`把人為驅動的測試行為，轉化為機器執行`的一種過程。 > 按是否檢視程式碼劃分： 1. 黑色測試（Black-Box Testing） 黑盒測試也是功能測試，測試中把被測的軟體當做一個黑盒子，不關心盒子的內部結構是什麼，只關心軟體的`輸入`資料和`輸出`資料。 2. 白盒測試（White-Box Testing） 白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於程式碼的測試。白盒測試是指開啟盒子，去研究裡面的`原始碼和程式`結果。 3. 灰盒測試（Gray-Box Testing） 灰盒測試是介於白盒測試和黑盒測試之間的一種，灰盒測試多用於整合測試階段，`不僅關注輸入、輸出的正確性，同時也關注程式內部的情況`。 > 按是否執行劃分： 1. 靜態測試（Static Testing） 靜態方法是指`不執行被測程式本身`，僅通過分析或檢查源程式的語法、結構、過程、介面等來檢查程式的正確性，對需求規格說明書、軟體設計說明書、源程式做結構分析、流程圖分析、符號執行來找錯。【靜態測試屬於白盒測試】 2. 動態測試（Dynamic Testing） 動態測試是指通過`執行被測程式`，檢查執行結果與預期結果的差異。【黑盒測試屬於動態測試】 > 按測試物件劃分： （一）非功能測試 1. 效能測試（Performance Testing） 檢查系統是否滿足需求規格說明書中規定的效能。 通常表現在以下方面： - 穩定性【例如：一萬人的時候和十萬人的時候，甚至一百萬的時候系統會不會卡頓】 - 響應時間【例如：等待相應的時間是否過慢】 - 吞吐量（TPS） 2. 安全測試（Safety Testing） 安全測試是一個相對獨立的領域，需要更多的專業知識。 如：WEB的安全測試、需要熟悉各種網路協議、防火牆、CDN、熟悉各種作業系統的漏洞、熟悉路由器等。 3. 相容性測試（Compatibility Testing） 相容性測試主要指軟體之間能否很好的運作，會不會有影響、軟體和硬體之間能否發揮很好的效率工作，會不會影響導致系統的崩潰。 - 平臺測試【例如：各種不同品牌型號、不同作業系統（如：android、iOS）的手機是否相容】 - 瀏覽器測試【例如：不同瀏覽器相容性測試（火狐、谷歌、360等）】 - 軟體本身是否向前或向後相容【例如：本版本和上一版本是否相容】 - 測試軟體是否與其他相關軟體相容【例如：同時下載兩款軟體是否都能正常使用】 - 資料相容性測試【資料之間有一定的隔離性，兩個軟體裡面的資料不會串、相互隔離、相容】 4. 文件測試（Document Testing） - 開發檔案：可行性研究報告、`軟體需求說明書`、資料要求說明書、概要設計說明書、詳細設計說明書、資料庫設計說明書、模組開發卷宗。 - 使用者檔案：使用者手冊、操作手冊，使用者文件的作用：改善易安裝性；改善軟體的易學性與易用性；改善軟體可靠性；降低技術支援成本。 - 管理檔案：專案開發計劃、測試計劃、測試分析報告、開發進度月報、專案開發總結報告。 ==在實際的測試中，最常見的就是使用者檔案的測試，例如：使用者操作說明書等。== 文件測試關注的點： - ​ 文件的術語 - ​ 文件的正確性 - ​ 文件的完整性 - ​ 文件的一致性 - ​ 文件的易用性 5. 易用性（使用者體驗性測試）（User Ability Testing） 易用性是`互動的適應性、功能性和有效性`的集中體現。又叫使用者體驗測試。 6. 介面測試（User Interface Testing） 介面測試（簡稱UI測試），測試使用者介面的功能模組的佈局是否合理、整體風格是否一致、各個控制元件的放置位置是否符合客戶使用習慣，此外還要測試介面操作便捷性、導航簡單易懂性，頁面元素的可用性，介面中文字是否正確，命名是否統一，頁面是否美觀，文字、圖片組合是否完美等。 7. 安裝測試（Installation Testing） 安裝測試是指：測試程式的安裝、解除安裝。最經典的就是APP的安裝、解除安裝。 （二）功能測試（Functional Testing） > 按測試實施的組織劃分： 1. α測試（Alpha Testing） 2. β測試（Beta Testing） :monkey:**α測試與β測試區別：** 1. 測試的`場所不同`：Alpha測試是指把使用者請到開發方的場所來測試，Beta測試是指在一個或多個使用者的場所進行的測試。【例如：遊戲內測版本】 2. Alpha測試的`環境是受開發方控制`的，`使用者的數量相對比較少`，`時間比較集中`。 Beta測試的`環境是不受開發方控制`的，`使用者數量相對比較多`，`時間不集中`。 3. Alpha測試`先於`Beta測試執行。通用的軟體產品`需要較大規模的Beta測試`，`測試周期比較長`。 3. 第三方測試（Third-party Testing） 介於開發方和使用者之前的測試組織。【例如：眾測網】 > 按測試地域劃分： 1. 國際化測試（International Testing） 軟體的國際化和軟體的本地化是開發面向全球不同地區使用者使用的軟體系統的兩個過程。而本地化測試和國際化測試則是針對這類軟體產品進行的測試。由於軟體的全球化普及，還有軟體外包行業的興起，軟體的本地化和國際化測試儼然成為一個獨特的測試專門領域。 2. 本地化測試（Localization Testing） 本地化測試的物件是軟體的本地化版本。  ##### `（三）軟體測試的原則` 1. 測試應該`儘早進行`，最好在需求階段就開始介入，因為最嚴重的錯誤不外乎是系統不能滿足使用者的需求。 2. 程式設計師`（開發）應該避免檢查自己的程式`，軟體測試應該由第三方（測試人員）來負責。 3. 設計測試用例時應考慮到`合法的輸入和不合法的輸入`。 4. 在測試程式時，不僅要檢驗程式是否做了該做的事，`還要檢驗程式是否做了不該做的事`，多餘的工作會帶來副作用，影響程式的效率，有時會帶來潛在的危害或錯誤。 5. 應`長期保留所有測試用例`，保留測試用例有助於以後修改程式後的迴歸測試。 ##### `（四）軟體測試策略` 1. 選擇測試方法：選擇`最合適當前專案`的測試方法（比如專案緊急的時候？專案頻繁發版）（例如：重複測試的工作可以採用自動化測試） 2. 角色和職責：需要在測試策略裡面`明確定義各個角色`，以及`該角色的職責`。比如專案經理、測試組長、測試工程師。 3. 環境需求：這一點非常重要，它將描述測試時需要的系統環境（軟體，伺服器Linux，windows，資料庫MySQL），包括`軟硬體以及網路環境`等等。在澄清環境需求的時候，測試組織可以識別出資源方面的風險。 4. 風險分析：影響測試過程的風險都應該儘早被識別出來，而且必須有相應的解決辦法以便消除或減輕這些風險。（例如：人員休假、軟體是否完成） 5. 測試進度評估：測試進度將會評估完成測試`所需要的時間`。在設定進度的時候，首先需要明測試範圍（比如說這次增加一個D模組，部分功能會影響原來已經上線的B模組的功能）然後根據測試資源的多少來指定能被各方面認可的測試進度計劃。 6. 迴歸測試（Regression Testing）策略：迴歸測試用來保證之前fix bug的程式碼不會影響軟體的其他部分，這樣需要我們選擇已經執行過的測試用例重新執行。測試人員需要找到一個方法來確定哪些測試用例應該在迴歸測試中執行，用例不能太多，因為資源有限，用例也不能太少，否則會達不到必須的測試強度。 7. 優先順序：測試範圍內的東西不會都是一樣重要的，加上測試資源各種有限，所以為測試的模組排定優先順序是十分的必要。 ##### `（五）軟體測試模型` 1. 瀑布模型 瀑布模型適合於結構化方法。 軟體專案或產品選擇瀑布模型必須滿足下列條件： - 在開發時間內需求沒有或很少變化 - 分析設計人員應對應用領域很熟悉 - 低風險專案（對目標、環境很熟悉） - 使用者使用環境很穩定 - 使用者除提出需求以外，很少參答與開發工作  2. V模型 - 優點：包含了底層測試（單元測試）和高層測試（系統測試）；清楚的標識了開發和測試的各個階段；自上而下逐步求精，每個階段分工明確，便於整體專案的把控。 - 缺點：自上而下的順序導致測試工作在編碼後，不能及時的進行修改；實際工作中，需求經常變化，導致V模型步驟反覆執行，返工量很大，靈活度較低。  V模型和瀑布模型有一些共同的特性，V模型中的過程從左到右，描述了基本的開發過程和測試行為。 - 優點：V模型的價值在於它非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各個階段的對應關係。 - 侷限性：（測試介入太晚）把測試作為編碼之後的最後一個活動，需求分析等前期產生的錯誤知道後期的驗收測試才能發現。 3. 敏捷模型  4. W模型 **定義：**開發一個v，測試一個v，組合起來的模型（w模型也叫雙v模型）。  5. H模型 相對於V模型和W模型，H模型將測試活動完全獨立出來，形成了一個完全獨立的流程，將測試準備活動和測試執行活動清晰地體現出來。  6. 探索性測試 探索性測試可以說是`一種測試思維模式`。 他沒有很多實際的測試方法、技術和工具，但是卻是所有測試人員都應該掌握的一種測試思維方式。 探索性測試強調測試人員的主觀能動性，拋棄繁雜的測試計劃和測試用例設計過程，強調在碰到問題時及時改變測試策略。 ##### `（六）軟體測試生命週期`