（一）軟件測試的定義
在規定的條件下對程序進行操作，以發現程序的錯誤，衡量軟件質量，並對其是否能滿足設計要求進行評估的過程。
規定條件 --> 測試用例
發現程序的錯誤 --> 找bug
衡量軟件質量 --> 根據各項指標評估軟件的質量
滿足設計要求 --> 是否滿足用戶需求、需求規格說明書、概要設計、軟件設計等
（二）軟件測試方法的分類
按開發階段划分：
-
單元測試（Unit Testing）
又稱
模塊測試。對軟件的組成單位進行測試，其目的是檢驗軟件基本組成單位的正確性。測試的對象是軟件測試的最小單位：模塊。【例如：登錄測試】 -
集成測試（Integration Testing）
集成測試也稱
聯合測試（聯調）、組裝測試：將程序模塊采用適當的集成策略組裝起來，對系統的接口及集成后的功能進行正確性檢測的測試工作。集成主要目的是檢查軟件單位之間的接口是否正確。【例如：京東購物用微信支付】 -
系統測試（System Testing）
將軟件系統看成是一個系統的測試。包括
對功能、性能以及軟件所運行的軟硬件環境進行測試。時間大部分在系統測試執行階段，包括回歸測試和冒煙測試。
【例如：房子能不能住人（功能） 房子抗不抗台風（性能）；QQ能不能注冊，能不能登錄，能不能聊天發消息（功能） 人數太多會不會卡頓（性能）】
系統測試如何開展？
需求評審（功能需求、性能需求、接口需求） - 測試計划 - 測試用例 - 用例評審 - 測試環境搭建（平台、架構、web服務器、數據庫） - 執行用例 - 提交問題 - 缺陷的跟蹤和回歸測試 - 測試報告
-
驗收測試（Acceptance Testing）
是部署軟件前的最后一個測試操作。它是技術測試的最后一個階段，也稱為
交付測試。向軟件購買者展示該軟件系統滿足原始需求。實施驗收測試的策略有三種：
正式驗收測試- 非正式驗收測試或
α測試 β測試
按是否手工執行划分：
-
手工測試（Manual Testing）
手工測試是
由人一個一個的輸入用例，然后觀察結果，和機器測試（指使用機器去測試，例如：手機、電腦）相對應，屬於比較原始但是必須的一種。 -
自動化測試（Automation Testing）
所謂自動化測試，就是
在預設條件下運行系統或應用程序，評估運行結果。（預先條件包括：正常條件和異常條件）。簡單來說，自動化測試就是把人為驅動的測試行為，轉化為機器執行的一種過程。
按是否查看代碼划分：
-
黑色測試（Black-Box Testing）
黑盒測試也是功能測試，測試中把被測的軟件當做一個黑盒子，不關心盒子的內部結構是什么，只關心軟件的
輸入數據和輸出數據。 -
白盒測試（White-Box Testing）
白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是指打開盒子，去研究里面的
源代碼和程序結果。 -
灰盒測試（Gray-Box Testing）
灰盒測試是介於白盒測試和黑盒測試之間的一種，灰盒測試多用於集成測試階段，
不僅關注輸入、輸出的正確性，同時也關注程序內部的情況。
按是否運行划分：
-
靜態測試（Static Testing）
靜態方法是指
不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性，對需求規格說明書、軟件設計說明書、源程序做結構分析、流程圖分析、符號執行來找錯。【靜態測試屬於白盒測試】 -
動態測試（Dynamic Testing）
動態測試是指通過
運行被測程序，檢查運行結果與預期結果的差異。【黑盒測試屬於動態測試】
按測試對象划分：
（1）非功能測試
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的安裝、卸載。
(2) 功能測試（Functional Testing）
功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。也是黑盒測試，測試中把被測的軟件當做一個黑盒子，不關心盒子的內部結構是什么，只關心軟件的輸入數據和輸出數據。
按測試實施的組織划分：
-
α測試（Alpha Testing）
-
β測試（Beta Testing）
α測試與β測試區別：
-
測試的
場所不同：Alpha測試是指把用戶請到開發方的場所來測試，Beta測試是指在一個或多個用戶的場所進行的測試。【例如：游戲內測版本】 -
Alpha測試的
環境是受開發方控制的，用戶的數量相對比較少，時間比較集中。Beta測試的
環境是不受開發方控制的，用戶數量相對比較多，時間不集中。 -
Alpha測試
先於Beta測試執行。通用的軟件產品需要較大規模的Beta測試，測試周期比較長。
-
-
第三方測試（Third-party Testing）
介於開發方和用戶之前的測試組織。【例如：眾測網】
按測試地域划分：
-
國際化測試（International Testing）
軟件的國際化和軟件的本地化是開發面向全球不同地區用戶使用的軟件系統的兩個過程。而本地化測試和國際化測試則是針對這類軟件產品進行的測試。由於軟件的全球化普及，還有軟件外包行業的興起，軟件的本地化和國際化測試儼然成為一個獨特的測試專門領域。
-
本地化測試（Localization Testing）
本地化測試的對象是軟件的本地化版本。
（三）軟件測試的原則
-
測試應該
盡早進行，最好在需求階段就開始介入，因為最嚴重的錯誤不外乎是系統不能滿足用戶的需求。 -
程序員
（開發）應該避免檢查自己的程序，軟件測試應該由第三方（測試人員）來負責。 -
設計測試用例時應考慮到
合法的輸入和不合法的輸入。 -
在測試程序時，不僅要檢驗程序是否做了該做的事，
還要檢驗程序是否做了不該做的事，多余的工作會帶來副作用，影響程序的效率，有時會帶來潛在的危害或錯誤。 -
應
長期保留所有測試用例，保留測試用例有助於以后修改程序后的回歸測試。
（四）軟件測試策略
-
選擇測試方法：選擇
最合適當前項目的測試方法（比如項目緊急的時候？項目頻繁發版）（例如：重復測試的工作可以采用自動化測試） -
角色和職責：需要在測試策略里面
明確定義各個角色，以及該角色的職責。比如項目經理、測試組長、測試工程師。 -
環境需求：這一點非常重要，它將描述測試時需要的系統環境（軟件，服務器Linux，windows，數據庫MySQL），包括
軟硬件以及網絡環境等等。在澄清環境需求的時候，測試組織可以識別出資源方面的風險。 -
風險分析：影響測試過程的風險都應該盡早被識別出來，而且必須有相應的解決辦法以便消除或減輕這些風險。（例如：人員休假、軟件是否完成）
-
測試進度評估：測試進度將會評估完成測試
所需要的時間。在設定進度的時候，首先需要明測試范圍（比如說這次增加一個D模塊，部分功能會影響原來已經上線的B模塊的功能）然后根據測試資源的多少來指定能被各方面認可的測試進度計划。 -
回歸測試（Regression Testing）策略：回歸測試用來保證之前fix bug的代碼不會影響軟件的其他部分，這樣需要我們選擇已經執行過的測試用例重新運行。測試人員需要找到一個方法來確定哪些測試用例應該在回歸測試中運行，用例不能太多，因為資源有限，用例也不能太少，否則會達不到必須的測試強度。
-
優先級：測試范圍內的東西不會都是一樣重要的，加上測試資源各種有限，所以為測試的模塊排定優先級是十分的必要。
（五）軟件測試模型
1.瀑布模型
瀑布模型適合於結構化方法。
軟件項目或產品選擇瀑布模型必須滿足下列條件：
- 在開發時間內需求沒有或很少變化
- 分析設計人員應對應用領域很熟悉
- 低風險項目（對目標、環境很熟悉）
- 用戶使用環境很穩定
- 用戶除提出需求以外，很少參答與開發工作
2.V模型
-
優點：包含了底層測試（單元測試）和高層測試（系統測試）；清楚的標識了開發和測試的各個階段；自上而下逐步求精，每個階段分工明確，便於整體項目的把控。
-
缺點：自上而下的順序導致測試工作在編碼后，不能及時的進行修改；實際工作中，需求經常變化，導致V模型步驟反復執行，返工量很大，靈活度較低。
V模型和瀑布模型有一些共同的特性，V模型中的過程從左到右，描述了基本的開發過程和測試行為。
- 優點：V模型的價值在於它非常明確地標明了測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各個階段的對應關系。 - 局限性：（測試介入太晚）把測試作為編碼之后的最后一個活動，需求分析等前期產生的錯誤知道后期的驗收測試才能發現。
3.敏捷模型
4.W模型
定義：開發一個v，測試一個v，組合起來的模型（w模型也叫雙v模型）。
5.H模型
相對於V模型和W模型，H模型將測試活動完全獨立出來，形成了一個完全獨立的流程，將測試准備活動和測試執行活動清晰地體現出來。
-
探索性測試
探索性測試可以說是
一種測試思維模式。他沒有很多實際的測試方法、技術和工具，但是卻是所有測試人員都應該掌握的一種測試思維方式。
探索性測試強調測試人員的主觀能動性，拋棄繁雜的測試計划和測試用例設計過程，強調在碰到問題時及時改變測試策略。
（六）軟件測試生命周期
