前言：

為什么要將測試進行分類呢？

軟件測試是軟件生命周期中的?個重要環節，具有較高的復雜性，對于軟件測試，可以從不同的角度加以分類，使開發者在軟件開發過程中的不同層次、不同階段對測試工作進行更好的執行和管理測試的分類方法。

按照測試目標進行分類

界面測試

肉眼所能看見的任何元素都要進行測試。

• 驗證界?內容顯示的完整性，?致性，準確性，友好性。?如界?內容對屏幕大小的自適應，換 行，內容是否全部清晰展示；
• 驗證整個界?布局和排版是否合理，不同板塊字體的設計，圖?的展示是否符合需求；
• 對界?不同控件的測試，比如，對話框，?本框，滾動條，選項按鈕等是否可以正常使用，有效 和無效的狀態是否設計合理；
• 界面的布局和?調符合當下時事的發展。

功能測試

功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要 求的功能。

如何進行功能測試？ 設計功能測試用例，參考產品規格說明書進行用例的編寫，具體的測試用例需要使用黑盒設計測試用例的方法，如等價類、邊界值、判定表法、正交法、場景法、錯誤猜測法等。

性能測試

我們在使用軟件的時候有時會碰到軟件網頁打開時越來越慢，查詢數據時很長時間才顯示列表，軟件運行越來越慢等問題，這些問題都是系統的性能問題引起的。

要進行軟件產品的性能問題，要對產品的性能需求進行分析，然后基于系統的性能需求和系統架構， 完成性能測試的設計和執行，最后要進行持續的性能調優。

可靠性測試

可靠性（Availability）即可用性，是指系統正常運行的能力或者程度，一般用正常向用戶提供軟件 服務的時間占總時間的百分比表示。?可靠性=正常運行時間/（正常運行時間+非正常運行時間）*100%

系統?正常運?的時間可能是由于硬件，軟件，網絡故障或任何其他因素（如斷電）造成的，這些因素能讓系統停止?作，或者連接中斷不能被訪問，或者性能急劇降低導致不能使?軟件現有的服務 等。

可用性指標?般要求達到4個或5個“9”，即99.99%或者99.999%，如果可用性達到99.99%，對于?個全年不間斷（7*24的?式）運行的系統，意味著全年 （252600min)不能正常?作的時間只有52min，不到?個小時。如果可用性達到99.999%，意味著全年不能正常?作的時間只有5min。不同的應?系統，可用性的要求是不?樣的，非實時性的信息系統或?般網站要求都很低，99%和 99.5%就可以了，但是軍事系統，要求則很高；

安全性測試

安全性是指信息安全，是指計算機系統或網絡保護用戶數據隱私，完整，保護數據正常傳輸和抵御 黑客，病毒攻擊的能力。

• 安全性測試屬于非功能性測試很重要的?個方面，系統常見的安全漏洞和威脅如下
• 輸?域，如輸?惡性或者帶有病毒的腳本或長字符串；
• 代碼中的安全性問題，如SQL/XML注?
• 不安全的數據存儲或者傳遞
• 數據文件，郵件文件，系統配置文件等??有危害系統的信息或者數據；
• 有問題的訪問控制，權限分配等
• 假冒ID：?份欺騙
• 篡改，對數據的惡意修改，破壞數據的完整性

安全性測試的方法有代碼評審，滲透測試，安全運維等，常?的靜態安全測試工具有，Coverity， IBM、Appscan、Source，HPFortify，常用的動態安全測試有OWASP的ZAP，HP、WebInspect等。其 中靜態安全測試是常用的安全性測試的方法。

易用性測試

許多產品都應用人體工程學的研究成果，是產品在使用起來更加靈活和，舒適。軟件產品也始終關注用戶體驗，讓用戶獲得舒適，易?的體驗，針對軟件這方面的測試稱之為易用性測試。

易?性在ISO25020標準中指容易發現，容易學習和容易使?。易?性包含七個要素：符合標準和規范，直觀性，?致性，靈活性，舒適性，正確性和實?性。我們主要討論以下幾個方面

1.標準性和規范性

對于現有的軟件運?平臺，通常其UI標準已經不知不覺地被確?了，成為?家的共識。多數用戶已 經習慣并且接受了這些標準和規范，或者說已經認同了這些信息所代表的的含義。?如安裝軟件的 界?的外觀，在什么場合使?恰當的對話框等。

所以用戶界?上的各中信息應該符合規范和習慣，否則用戶使?起來會不舒適，并得不到??的認 可。測試?員需要把與標準規范，習慣不?致的問題報告為缺陷

舉個例子：八寶粥都是罐裝的，你一下整個盒裝的，用戶已經潛移默化的適應了罐裝的，這時候就容易出現用戶反饋。

2.直觀性?

用戶界面的直觀性，要求軟件功能特性易懂，清晰。用戶界?布局合理，對操作的響應在用戶的預期 之中。比如數據統計結果?報表的形式（條形圖，扇形圖等）展?清晰直觀；現在主流的很多搜索引 擎和日歷的設計也有直觀性的特點；

3.靈活性

軟件可以有不同的選項以滿?不同使?習慣的??來完成相同的功能。但是靈活性的設計要把握好 度，不然可能由于太多的??狀態和?式的選擇，增加了軟件設計的復雜性，和程序實現的難度。

例如 ?機鍵盤有九宮格和全鍵盤，還?持?寫，滿?了不同??的需求

4.舒適性

舒適性主要強調界?友好，美觀，操作過程順暢，?彩?運恰當，按鈕的?體感等。例如左??標的 設置給習慣?左?的?帶來了便利，也為右??分勞累時提供了另?種途徑； 舒適性主要強調界?友好，美觀，操作過程順暢，?彩?運恰當，按鈕的?體感等。例如左??標的 設 置給習慣?左?的?帶來了便利，也為右??分勞累時提供了另?種途徑；

按照執行方式進行分類

靜態測試

靜態測試 就是不運行程序，而是通過檢查代碼、設計文檔或者其他軟件結構來找出潛在的問題。就像你在做作業之前，先認真讀一遍題目，確保每個細節都沒錯。這種方式的好處是你不用實際運行程序，就能找到一些明顯的錯誤。

動態測試

動態測試 則是實際運行程序，輸入數據，查看輸出結果是否符合預期。這就像你完成了作業后，直接去考試，看看自己在實際情境下表現得如何。動態測試是大多數軟件測試的主要方式。

按照測試方法進行測試

白盒測試

白盒測試也稱為結構測試或邏輯測試，主要關注程序內部結構，通過分析程序的邏輯路徑來設計測試用例。它的目的是確保軟件的各個邏輯路徑被覆蓋，程序能夠按照預期運行。

常見的白盒測試方法：

• 語句覆蓋：確保程序中的每個語句至少被執行一次。

• 判定覆蓋：測試程序中的條件判斷語句，確保每個條件都得到了測試。

• 路徑覆蓋：確保程序的每條執行路徑都被測試。

• 條件組合覆蓋

• 條件覆蓋

?

總結

• ?盒測試主要應?于單元測試階段
• 先執?靜態設計?例的?法，再執?動態設計測試?例的?法
• 設計?例?般使?路徑測試，重點模塊追加使?邏輯覆蓋?法

黑盒測試

黑盒測試與白盒測試不同，它不關注程序的內部實現，而是關注軟件的功能是否滿足需求。黑盒測試的重點是驗證軟件的輸入和輸出是否符合預期，確保軟件能夠按照需求正常工作。

常見的黑盒測試方法：

• 等價類劃分：通過將輸入數據分為多個等價類來減少測試數據的數量。

• 邊界值分析：特別關注輸入數據的邊界值，比如最大值、最小值、越界值等。

• 因果圖法：根據需求規格定義輸入和輸出之間的關系，設計測試用例。

舉個例子：假設你有一個登陸表單，黑盒測試時，你會測試以下幾種情況：

• 輸入正確的用戶名和密碼，檢查是否能夠成功登陸。

• 輸入錯誤的用戶名或密碼，檢查是否會給出錯誤提示。

灰盒測試

灰盒測試是介于白盒測試和黑盒測試之間的一種方法。它通常用于集成測試階段，不僅關注輸出和輸入的正確性，還會檢查程序的內部情況。灰盒測試可以基于部分內部實現進行設計，但不需要完全了解程序的內部結構。

舉個例子：你正在測試一個電商平臺的購物車功能，灰盒測試人員知道購物車和支付模塊如何交互，但不需要完全了解支付模塊的內部實現。測試的重點是確保數據能夠正確從購物車模塊流向支付模塊。

按照測試階段進行分類

單元測試

與編碼同步進?，針對軟件最?組成單元進?測試，主要采??盒測試?法，從被測對象的內部結構出發設計測試?例

所謂的最小單元就是人為規定的方法、接口、功能。

• 測試階段：編碼后或者編碼前（TDD）
• 測試對象：最小模塊
• 測試?員：白盒測試?程師或開發?程師
• 測試依據：代碼和注釋+詳細設計?檔
• 測試?法：?盒測試
• 測試內容：模塊接?測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測

集成測試

集成測試也稱聯合測試（聯調）、組裝測試，將程序模塊采?適當的集成策略組裝起來，對系統的接?及集成后的功能進?正確性檢測的測試?作。集成主要?的是檢查軟件單位之間的接是否正確。

• 測試階段：?般單元測試之后進?
• 測試對象：模塊間的接?
• 測試?員：?盒測試?程師或開發?程師
• 測試依據：單元測試的模塊+概要設計?檔
• 測試?法：?盒測試與?盒測試相結合
• 測試內容：模塊之間數據傳輸、模塊之間功能沖突、模塊組裝功能正確性、全局數據結構、單模缺陷對系統的影響

系統測試

在軟件開發生命周期中，系統測試是確保軟件系統整體功能和性能達到預期要求的關鍵環節。它不僅驗證了軟件各個模塊的正確性，還確保不同模塊之間的協作無縫進行，從而提升了軟件的可靠性和穩定性。

系統測試的目標

• 全面檢查功能：系統測試的首要目標是驗證軟件是否按照需求文檔所描述的功能執行。

• 驗證集成模塊的協同工作：系統測試會檢查所有子系統或模塊是否能夠順利協作，確保系統在集成后的運行效果。

• 性能與安全性驗證：除了基本功能外，系統測試還包括對性能的測試（如負載測試、壓力測試）以及安全性的檢測。

系統測試的分類

系統測試通常分為幾類不同的測試方式：

1. 冒煙測試（Smoke Testing）

   • 定義：冒煙測試又稱為基本功能測試，通常在開發過程中或新版本發布時進行，目的是驗證軟件是否能夠順利啟動并且執行最基本的操作。

   • 目的：通過冒煙測試，開發團隊能夠迅速發現顯而易見的重大問題。

   • 實施方式：通常由開發人員進行，測試的重點是是否能順利打開系統，執行一些基本的功能。

2. 回歸測試（Regression Testing）

   • 定義：回歸測試用于確認新代碼的變更沒有破壞現有功能。

   • 目的：保證代碼的修改沒有引入新的問題，確保軟件的穩定性。

   • 實施方式：每當系統更新時，回歸測試會重新測試相關功能，確保系統在更新后依舊能夠正常工作。

驗收測試

針對??需求，對通過系統測試的軟件進?交付性測試，以確定系統是否滿?驗收標準，由??或其他授權機構決定是否接受系統。驗收測試是部署軟件之前的最后?個測試操作。它是技術測試的最后?個階段，也稱為交付測試。驗收測試的?的是確保軟件準備就緒，按照項?合同、任務書、雙?約定的驗收依據?檔，向軟件購買都展?該軟件系統滿?原始需求。

• 測試階段：系統測試通過之后
• 測試對象：整個系統（包括軟硬件）。
• 測試?員：主要是最終??或者需求?。
• 測試依據：??需求、驗收標準
• 測試?法：?盒測試
• 測試內容：同系統測試(功能...各類?檔等)

單元測試，集成測試，系統測試，回歸測試之間的關系

類比開上小汽車的過程

造?需要原材料，如?輪、發動機等零部件不是?企??制造出來的，?是通過購買零部件來造?。對買來的零部件進?檢查，零部件是否符合造?標準（單元測試）

零件確認完畢，接下來就是復雜的造??藝，將零部件集成起來構成了?輛?，并初步檢查拼?的?是否能正常運作（集成測試）

?輛?成型之后并不意味著就可以直接銷售給客?了，需要?企專業的測試?員進?詳細?完整的測試。（系統測試）

專業的測試?員對企業測試完畢，通過測試的汽?將會在?展或者4S店進?展?，供??進?選擇和購買。??在選擇汽?的過程中也會對?外觀以及性能等??進?校驗（驗收測試）

按照是否手工測試

手工測試

??測試就是由?去?個?個的輸??例，然后觀察結果，和機器測試相對應，屬于?較原始但是必須的?個步驟。

自動化測試

就是在預設條件下運?系統或應?程序，評估運?結果，預先條件應包括正常條件和異常條件。簡單說

?動化測試是把以?為驅動的測試?為轉化為機器執?的?種過程。

?動化測試?如功能測試?動化、性能測試?動化、安全測試?動化。

?動化測試按照測試對象來分，還可以分為接

測試、UI測試等。接?測試的ROI（產出投??）要?UI測試?。（這?了解?下，等到將?動化的時候再詳細展開）

按照實施組織劃分

α測試

β測試