一、前言

??萬字長文，只為精品，這是一篇你閱讀后能夠對測驗術語和解釋有明顯提升認知的文章，同時也能在大致的介紹中指引你方向的文章，還可能是你看完以后會隨手點個收藏、反復閱讀的文章，

??本文章主要講解軟體、游戲測驗行業的測驗術語，并對測驗專業術語進行概要補充，筆者進行一次整理，這里并不會提及到整個軟體行業或游戲行業的所有術語，但所介紹的內容都是大家常用的術語或未來很可能會碰到的一些術語或目前已經在使用的術語，也包括跨領域的知識學習，沒學習的萌新可以快速了解，學習過的大佬也可以通過目錄快速進入到想了解的內容~

??下面列舉的內容是筆者所知悉的一些測驗行業術語，希望能對廣大讀者有一定的幫助，文章內部格式有一定的復制操作，如果有錯誤、遺漏或有更好的建議、疑問，歡迎評論或私信補充，筆者看到都會解答對本文章內所產生的疑問哦！~ ??

二、按照測驗階段劃分：

2.1 單元測驗（Unit Test）：

??單元測驗，目的是為了驗證軟體中最小單元（類、函式）的正確性，測驗的物件即是最小單元，

• 測驗階段：最小單元開發完成后
• 測驗物件：類、函式等最小單元
• 測驗人員：開發工程師、白盒測驗工程師、自動化測驗工程師
• 測驗依據：代碼與注釋、需求檔案、腳本除錯
• 測驗技術：白盒測驗
• 測驗優點：穩固底層代碼邏輯
• 測驗內容：介面測驗、區域資料測驗、路徑測驗、容錯處理測驗、邊界值測驗

補充說明：

1、單元測驗是白盒測驗，白盒測驗并非單元測驗

2、測驗依據可以根據自身需要來進行制定

3、測驗驅動開發在撰寫某個功能的代碼之前先撰寫測驗代碼，只撰寫測驗通過的功能代碼，通過測驗推動整個開發的進行

2.2 集成測驗（Integration?Test）：

??集成測驗，是單元測驗的邏輯擴展，將已經測驗過的軟體單元組合在一起測驗它們之間的互動和依賴，對系統的介面及集成后的功能進行測驗，以驗證正確性，集成測驗主要目的是檢查軟體單位之間的介面是否正確，

• 測驗階段：單元測驗階段后、功能集合前的單項功能正常
• 測驗物件：類合集的多個函式物件、軟體介面、業務系統與模塊的互動
• 測驗人員：開發工程師、白盒測驗工程師、自動化測驗工程師、功能測驗工程師
• 測驗依據：服務端設計檔案的單元設計、概要檔案、業務需求檔案
• 測驗技術：黑盒測驗、白盒測驗、灰盒測驗
• 測驗優點：保障模塊間互動與獨立功能的穩定性
• 測驗內容：介面測驗、模塊間資料傳輸、模塊間功能沖突、模塊組裝功能正確性、全域資料結構、單模塊缺陷對系統的影響

補充說明：

1、單元測驗是單個函式或類方法的測驗，只針對代碼層面的測驗

2、集成測驗是多個函式、類方法的集合測驗，集成測驗至少包括兩個以上的關聯函式或類方法的測驗

3、集成測驗與單元測驗不同的是，集成測驗不僅用于代碼測驗，也用于功能層面測驗兩個或以上系統模塊之間的聯系

2.3 系統測驗（System Test）：

??系統測驗，將整個軟體看作一個系統，在實際運行環境下對軟體系統進行一系列嚴格有效地測驗（包括功能、性能、自動化、安全等領域的測驗），以發現軟體潛在的問題，保證系統的正常運行，

• 測驗階段：集成測驗階段后
• 測驗物件：整個軟體系統以及關聯的硬體系統
• 測驗人員：系統測驗工程師、黑盒測驗工程師、自動化測驗工程師、性能測驗工程師等
• 測驗依據：需求檔案說明書
• 測驗技術：黑盒測驗、白盒測驗、灰盒測驗
• 測驗優點：全范圍、全方位保證系統的穩定性、健壯性、功能正確性等
• 測驗內容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

補充說明：

1、系統測驗是針對整個軟體系統進行的全域測驗，不針對單一的模塊、單元

2、冒煙測驗以及回歸測驗包含在系統測驗中且為重要組成部分，順序：冒煙 ＞系統 ＞回歸

3、只會單一的測驗技術也可以完成系統測驗的部分，并非需要技術精湛的系統測驗工程師或同類工種測驗人員完成

??冒煙測驗（Smoke Test）：

??
??回歸測驗（Regression Test）：指代碼進行修改后的復查，重新對修改內容以及相關聯的內容進行測驗確保沒有出現新增Bug且該問題修復成功，

??
??

2.4 驗收測驗（Acceptance Test）：

??驗收測驗主要是對軟體產品說明進行驗證，逐行逐字地按照說明書的描述對軟體產品進行測驗，確保其符合各項要求，

• 測驗階段：系統測驗通過后
• 測驗物件：整個軟體系統以及關聯的硬體系統
• 測驗人員：需求方或用戶方
• 測驗依據：用戶需求、驗收標準
• 測驗技術：黑盒測驗
• 測驗優點：避免冗余、重復性開發
• 測驗內容：軟體系統的功能是否符合標準（用戶需求、驗收標準、各類需求檔案）

補充說明：

1、驗收測驗不同于系統測驗，系統測驗是系統化的流程測驗，而驗收測驗是驗證各項需求檔案中所提及的需求內容

2、驗收測驗主要是對于需求中所提及的需求點進行驗證測驗，無需在驗收測驗時考慮各類例外點或非需求提及內容

3、完全獨立的系統模塊可以考慮提前介入驗收測驗的環節，但測驗的結果不可當成最終的驗收結果，只是提前檢查是否符合需求規劃，如不符合盡快改進的一個推動手段

??

三、按照測驗技識訓分：

3.1 黑盒測驗（Black-box Testing）：

??黑盒測驗，即資料驅動測驗、功能測驗，測驗中把被測的軟體（程式）當成一個黑盒子，它把程式當作一個輸入域到輸出域的映射，不關心盒子的內部結構是什么，只關心軟體的輸入資料和輸出資料正確即可，

• 測驗階段：開發功能基本穩定到發布階段前
• 測驗物件：軟體系統的功能
• 測驗人員：功能測驗工程師
• 測驗依據：業務需求檔案
• 測驗技術：黑盒測驗
• 測驗優點：保障基礎功能的正確性與穩定性
• 測驗內容：軟體各項功能

補充說明：

1、黑盒測驗主要驗證功能的正確性，業務功能的集成內容也屬于黑盒測驗

2、黑盒測驗程序中不可用作窮舉測驗，需要考慮合法的輸入場景和特定的例外場景

3、黑盒測驗的基礎前提上是以用戶的角度出發結合例外點與發散思維進行的測驗

3.2 灰盒測驗（Gray-Box?Testing）：

??灰盒測驗是介于白盒測驗和黑盒測驗之間的一種，灰盒測驗多用于集成測驗階段，不僅關注輸入、輸出的正確性，同時也關注程式內部的情況，

• 測驗階段：單元測驗階段后集成階段前
• 測驗物件：程式介面、集成項
• 測驗人員：黑盒測驗工程師、介面測驗工程師、自動化測驗工程師
• 測驗依據：業務需求檔案、介面需求檔案
• 測驗技術：黑盒測驗、灰盒測驗
• 測驗優點：保障集成階段的正確性與穩定性
• 測驗內容：介面測驗、模塊間資料傳輸、模塊間功能沖突

補充說明：

1、灰盒測驗主要是功能測驗與介面測驗

2、灰盒測驗在內部程序中把程式看作一個必須從外面進行分析的黑盒

3、灰盒測驗涉及輸入和輸出，但使用關于代碼和程式操作等通常在測驗人員視野之外的資訊設計測驗，

3.3 白盒測驗（White-Box?Testing）：

??白盒測驗又稱結構測驗、透明盒測驗、邏輯驅動測驗或基于代碼的測驗，白盒測驗不同于黑盒測驗，不會關注或過多關注盒子的表面，而是關注盒子的內部，去研究里面的“容貌”與“結構”等（等價于源代碼和程式結果）

• 測驗階段：單元測驗階段
• 測驗物件：程式源代碼、程式結構體
• 測驗人員：白盒測驗工程師、開發人員、高級自動化測驗工程師
• 測驗依據：服務端代碼設計檔案、客戶端代碼設計檔案、程式設計概要、業務需求檔案
• 測驗技術：白盒測驗
• 測驗優點：保證底層代碼邏輯功能實作正常，為后續其他測驗的便捷與穩定做鋪墊
• 測驗內容：程式判斷邏輯、陳述句覆寫、條件覆寫等

補充說明：

1、白盒測驗也是介面測驗的一種

2、白盒測驗是直接對源代碼進行測驗

3、白盒測驗其中一部分需要語言對標，在挑選工具時要選擇工具語言支持的

??

四、按照程式運行劃分：

4.1 靜態測驗（Static Testing）：

??靜態方法是指不運行被測程式本身，僅通過分析或檢查源程式的語法、結構、程序、介面等來檢查程式的正確性，對需求規格說明書、軟體設計說明書、源程式做結構分析、流程圖分析、符號執行來找錯

• 測驗階段：可測驗情況下的任意階段
• 測驗物件：程式代碼、需求說明書、介面等非程式運行環境的檢查
• 測驗人員：任意測驗工程師、開發人員
• 測驗依據：需求檔案、程式概要設計、程式結構圖等
• 測驗技術：黑盒測驗、灰盒測驗、白盒測驗
• 測驗優點：穩固底層代碼邏輯與集成互動功能、優化流程等
• 測驗內容：程式代碼的正確性、需求檔案的正確性與合理性等

補充說明：

1、我們所說的發現需求檔案中的設計缺陷就屬于靜態測驗的一種方式

2、靜態測驗主要的測驗層面為代碼測驗、界面測驗以及需求檔案測驗

3、靜態測驗不同于大多數的測驗，在測驗完成后需要有專人進行多次的復核

4.2 動態測驗（Execution-Based?Testing）：

?? 動態測驗是指通過運行被測程式，檢查運行結果與預期結果的差異，并分析運行效率、正確性、健壯性、性能等，

• 測驗階段：專案框架比較完善且程式可運行
• 測驗物件：整個軟體系統及其硬體設備
• 測驗人員：任意測驗工程師、開發人員
• 測驗依據：用戶手冊、需求檔案、對標產品資料
• 測驗技術：黑盒測驗、灰盒測驗、白盒測驗
• 測驗優點：系統的二次質量保證
• 測驗內容：運行效率、正確性、健壯性、性能等

補充說明：

1、動態測驗主要有三部分組成：構造測驗用例、執行程式、分析程式的輸出結果，

2、大多數的軟體和少部分的游戲都在進行動態測驗

3、動態測驗與靜態測驗最明顯的區別就在于靜態測驗不運行程式，而動態測驗是在程式運行下進行的

??

五、按照測驗物件劃分：

5.1 性能測驗（Performance Testing）：

?? 性能測驗是通過自動化的測驗工具模擬多種正常、峰值以及例外負載條件來對系統的各項性能指標進行測驗，

• 測驗階段：開發功能基本穩定到發布階段前
• 測驗物件：整個軟體系統及其硬體設備
• 測驗人員：性能專項測驗工程師
• 測驗依據：用戶手冊、概要方案、對標產品資料
• 測驗技術：專項測驗
• 測驗優點：系統的二次質量保證
• 測驗內容：資源利用、執行間隔、回應時間、吞吐量等

補充說明：

1、App主要測驗CPU消耗、記憶體消耗、電量消耗、流量消耗等，這是與Web測驗與PC端的明顯區別，游戲App亦是如此

2、如果系統的性能相對于較好的時候，可以考慮上線后介入，如果不理想需要在上線前進行測驗，亦可在單一的某塊穩定后針對測驗

3、性能測驗中有負載測驗、壓力測驗、容量測驗等等，測驗的主流程工具是Loadrunner、Jmeter等等

5.2 安全測驗（Security?Testing）：

?? 安全測驗是在IT軟體產品的生命周期中，特別是產品開發基本完成到發布階段，對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的程序，

• 測驗階段：開發功能基本穩定到發布階段前
• 測驗物件：軟體系統及其硬體設備
• 測驗人員：安全測驗工程師
• 測驗依據：違反權限與能力的約束
• 測驗技術：專項測驗
• 測驗優點：建立在安全需求定義基礎上的質量保證
• 測驗內容：日志資料、用戶資料隱私、用戶權限等

補充說明：

1、測驗理論通常而言很難適用于安全測驗領域，其主要原因是因為實操性過強且理論知識范圍寬泛

2、功能測驗主要是以運用各類方法發現Bug為主，安全測驗則以發現安全隱患為主，兩者的關聯性很低

3、web安全、軟體安全與游戲安全的測驗方向差距很大，想學習安全測驗的朋友需要明確方向進行學習

5.3 兼容性測驗（Compatibility?Testing）：

?? 兼容性測驗是指測驗軟體在特定的硬體平臺上、不同的應用軟體之間、不同的作業系統平臺上、不同的網路等環境中是否能夠很友好的運行測驗，

• 測驗階段：開發功能基本穩定到發布階段前
• 測驗物件：軟體系統及其硬體設備
• 測驗人員：兼容專項測驗工程師、功能測驗工程師
• 測驗依據：軟硬體兼容性測驗指標
• 測驗技術：專項測驗
• 測驗優點：與平臺軟硬體獨立、完好運行
• 測驗內容：作業系統兼容性、異構資料庫兼容性、應用軟體兼容性、資料兼容性等

補充說明：

1、最常見的兼容性測驗是Web兼容，一個網頁中在不同的瀏覽器不同的Windows系統解析度的情況下兼容的展示

2、App型別的兼容性測驗以資料庫兼容、資料兼容測驗最為常見，硬體也是如此，例如手機系統升級更新，就需要測驗資料兼容

3、游戲的App存在最多的是軟體兼容以及資料兼容，軟體兼容即在運行其他軟體時游戲的獨立性，無沖突，資料兼容主要是游戲合服

5.4 檔案測驗（Documentation?Testing）：

?? 檔案測驗是檢驗樣品用戶檔案的完整性、正確性、一致性、易理解性、易瀏覽性，測驗檔案是提供測驗資訊的一組檔案，而并非單純地指檔案測驗，

• 測驗階段：測驗方案撰寫完成
• 測驗物件：專案各類流程檔案、需求檔案、測驗用例、測驗總結報告等
• 測驗人員：功能測驗工程師、專項領域工程師等
• 測驗依據：專案各類流程檔案、需求檔案、測驗用例、測驗總結報告等
• 測驗技術：黑盒測驗
• 測驗優點：提高測驗效率、閱讀理解性、間接提高產品質量等
• 測驗內容：檔案的完整性、正確性、一致性、易理解性、易瀏覽性等

補充說明：

1、黑盒測驗中的需求評審、用例評審等都屬于檔案測驗，根據測驗內容對需求檔案進行測驗

2、檔案測驗的介入通常是在正式執行某一項事務或事件前進行的測驗

3、通常在測驗方案階段進行測驗介入，在專案發布前的最終測驗報告屬于階段性檔案測驗，上線后仍需對各類檔案測驗及維護

5.5 易用性測驗（Usability?Testing）：

?? 易用性測驗又稱為用戶體驗測驗，是檢查軟體系統中各項內容是否方便用戶使用，用戶使用軟體時是否具有一定的便捷性，

• 測驗階段：開發功能基本穩定持續到軟體生命周期結束
• 測驗物件：軟體系統中的各功能、圖形化界面、檔案等
• 測驗人員：功能測驗工程師、軟體體驗師
• 測驗依據：用戶自主認知、用戶基礎認知及基礎行為操作
• 測驗技術：黑盒測驗
• 測驗優點：提高軟體使用的便捷性
• 測驗內容：易理解性、易學習性、易操作性、吸引性、易用依從性

補充說明：

1、依從性是軟體在遵循與某一特性相關的標準、約定或法規以及類似規定的能力，這些標準要考慮國際標準、國家標準、行業標準等

2、易用性測驗大多數情況下是以用戶的角度去思考、進而驗證軟體是否符合易用性的標準，部分標準會參照行業標準或依從性

3、易用性測驗主要是由功能測驗人員在日常測驗中以及專業的體驗師進行的體驗作業，但大多數國內行業的公司，其他部門也會介入尋找、挖掘用戶的體驗問題，以更好的保障軟體易用性

5.6 適配測驗（Adaptation Test）：

?? 適配測驗是為了讓軟體系統能夠在不同的硬體設備上均能夠有良好的運行，達到最佳用戶體驗而進行的一種測驗，

• 測驗階段：系統測驗完成后
• 測驗物件：軟體系統中的各功能、圖形化界面等
• 測驗人員：適配專項工程師、功能測驗工程師
• 測驗依據：主流手機型號、平板等硬體設備，主流解析度
• 測驗技術：專項測驗
• 測驗優點：提高用戶體驗、使用舒適度
• 測驗內容：設備系統、解析度等

補充說明：

1、適配與兼容性的主要區別在于兼容性是檢查設備兼容，資料兼容，更多關注的是功能的正常使用以及資料繼承，而適配更多的關注的是在不同系統與解析度下的界面適應能力與系統適應能力

2、測驗主要選擇市場主流的手機型號、品牌、系統以及解析度，具體可以參考：百度統計流量研究院

3、適配的測驗時機并非一定是在系統測驗完成后，時間及設備條件允許的情況下可以考慮提前介入測驗，但不應在系統模塊頻繁調整期間介入，至少需要模塊比較穩定后在考慮介入測驗

5.7 介面測驗（Interface Testing）：

?? 介面測驗是測驗系統組件間介面的一種測驗，介面測驗主要用于檢測外部系統與系統之間以及內部各個子系統之間的互動點，測驗的重點是要檢查資料的交換，傳遞和控制管理程序，以及系統間的相互邏輯依賴關系等，

• 測驗階段：單元測驗完成后
• 測驗物件：軟體系統
• 測驗人員：介面測驗工程師、開發人員
• 測驗依據：介面需求檔案
• 測驗技術：專項測驗
• 測驗優點：縮短專案測驗時間、提高系統健壯性等
• 測驗內容：業務功能覆寫、業務規則覆寫、引數驗證、介面及代碼覆寫率等

補充說明：

1、介面測驗的關注點是服務器代碼的邏輯驗證為核心點出發的

2、介面測驗分為內部介面和外部介面，例如部分軟體的登錄有微信登錄和QQ登錄，即是呼叫了外部介面，而內部介面是自研介面

3、外部介面通常被當成系統測驗來對待且外部介面通常在介面測驗有著很高的優先級，嚴格的意義上講，在進行功能測驗前需要對外部介面測驗通過，而內部的介面而言先后順序的影響并不是很重要，任意順序均可

5.8 界面測驗（UI?Testing）：

?? ?? 界面測驗（簡稱UI測驗)，測驗用戶界面的功能模塊的布局是否合理、整體風格是否一致、各個控制元件的放置位置是否符合客戶使用習慣，此外還要測驗界面操作便捷性、導航簡單易懂性，頁面元素的可用性，界面中文字是否正確，命名是否統一，頁面是否美觀，文字、圖片組合是否完美等，

• 測驗階段：集成測驗階段
• 測驗物件：軟體系統中的各個UI界面
• 測驗人員：功能測驗工程師
• 測驗依據：UI需求檔案
• 測驗技術：黑盒測驗
• 測驗優點：提升便捷性與用戶視覺體驗等
• 測驗內容：規范性、合理性、美觀性、獨特性等

補充說明：

1、游戲行業也會存在大量的界面測驗，通常會參考美術的UI檔案，而部分UI美術圖是由策劃（產品）所提供的

2、UI測驗的目標在于確保用戶界面向用戶提供了適當的訪問和瀏覽測驗物件功能的操作，除此之外，UI 測驗還要確保 UI 功能內部的物件符合預期要求，并遵循公司或行業的標準，

3、界面測驗在日常的作業中大多數都會被稱為UI測驗，但我們所說的UI自動化測驗可不是界面自動化測驗哦，萌新們要注意這一點哦，具體可以查找一些資料詳細了解，

5.9 安裝測驗（Installation?Testing）：

?? 安裝測驗是確保該軟體在正常情況和例外情況的不同條件下，能夠正常的進行安裝、升級、卸載，

• 測驗階段：可打包較為穩定的Apk或Ipa后
• 測驗物件：軟體系統的安裝流程
• 測驗人員：功能測驗工程師
• 測驗依據：各類需求檔案的綜合集成
• 測驗技術：黑盒測驗
• 測驗優點：提升用戶體驗
• 測驗內容：安裝、升級、卸載

補充說明：

1、測驗的階段并非絕對的，在上線前進行測驗也并非不可，具體依據專案需要決定，即使安裝測驗的流程在最后進行測驗，也不會過多的影響專案的流程或其他質量性問題，更多的是應用外部的獨立

2、對于安裝測驗而言不僅僅只是“安裝”，“升級”，“卸載”，也需要考慮到一定的例外點，例如安裝時鎖屏、卸載時手機斷電關機、升級時接到了移動電話等

3、無論什么樣的App軟體，什么形式的生命周期，都會經歷安裝測驗，在App領域中安裝測驗又被稱為經典測驗

六、按測驗實施的組織：

6.1 α測驗（Alpha Testing）：

?? α測驗又稱alpha測驗，是由一個用戶在開發環境下進行的測驗，也可以是公司內部的用戶在模擬實際操作環境下進行的測驗，α測驗的目的是評價軟體產品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)，

• 測驗階段：單元測驗、集成測驗、系統測驗
• 測驗物件：功能、局域化、可使用性、可靠性、性能和支持
• 測驗人員：開發人員、功能測驗工程師、性能專項工程師、軟體體驗師
• 測驗依據：各類需求檔案的綜合集成
• 測驗技術：黑盒測驗、專項技術
• 測驗優點：提升用戶體驗、正式驗收前的風險降低
• 測驗內容：軟體的功能、穩定性、軟體性能等

補充說明：

1、α測驗也稱之為內測，通常來說是內部的用戶進行的測驗，并非會涉及到外部人員

2、α測驗作業不可以由開發人員或測驗人員相關的專業人員進行測驗，通常而言是其他部門進行的測驗，將發現的問題反饋至開發人員，并有開發人員進行分析、跟進、處理

3、α測驗可以在單元、集成、系統測驗的階段進行，但絕大多數的情況下，α測驗只會在單元測驗完成后進行測驗，即專案的初期，通常為軟體的第一個大版本，可用、可測、核心功能已實作的版本，

6.2 β測驗（Alpha Testing）：

?? β測驗又稱beta測驗，β測驗是指軟體開發公司組織各方面的典型用戶在日常作業中實際使用β版本，即發放一部分給用戶進行測驗，并要求用戶報告例外情況、提出批評意見，然后軟體開發公司再對β版本進行改錯和完善，

• 測驗階段：集成測驗、系統測驗
• 測驗物件：系統功能、系統體驗
• 測驗人員：用戶群體
• 測驗依據：用戶自主行為以及軟體認知
• 測驗技術：黑盒測驗
• 測驗優點：提升用戶體驗、發現潛在問題
• 測驗內容：系統全功能及體驗

補充說明：

1、β測驗也稱之為公測，通常是由不同的用戶在不同的場所進行的測驗，β測驗的用戶會在各式各樣的環境下進行測驗

2、β測驗的進行的前提條件是已經解決了軟體中大部分的不完善之處，但仍有可能還存在缺陷和體驗問題，通常會提供給測驗的用戶群體進行測驗，得到用戶反饋后加以修正改善

3、β測驗的環境不受開發方控制，測驗用戶群體是對軟體具有一定認知性、對測驗職業以及軟體有一定的掌握性和了解性的特定人群

6.3 λ測驗（Final Testing）：

??λ測驗又稱最終測驗、終測，λ測驗是指軟體發布前使用相當成熟穩定的軟體所面向廣大用戶群體或特定用戶群體的最終版本測驗，λ測驗的實際版本與正式發布版本沒有很大的差異，會根據用戶最終報告的一些建議和潛在的風險做最后的調整及修正

• 測驗階段：驗收測驗
• 測驗物件：系統功能、系統體驗
• 測驗人員：用戶群體
• 測驗依據：用戶自主行為以及軟體認知
• 測驗技術：黑盒測驗
• 測驗優點：提升用戶體驗、發現潛在問題
• 測驗內容：系統全功能及體驗

補充說明：

1、在游戲領域中λ測驗其實就是所謂的游戲終測，及游戲上線前所發布的版本，游戲與軟體在終測上無明顯的差別，大多數情況下，軟體以及游戲都需要經歷的相同的λ測驗

2、λ測驗只能夠存在于驗收測驗之后，各項功能完善、齊全、幾乎無明顯問題或體驗問題的最終版本，否則進行公開測驗的版本都只能算做β測驗，因為實際軟體條件不符合λ測驗，只是名義字眼上的終測

3、對于α測驗、β測驗以及λ測驗，越后置的測驗，人力消耗越大、經辦費用越高、維護成本越高，通常而言在國內只有少數技術實力強勁的公司會進行λ測驗

6.4 三方測驗（Third party testing）：

??三方測驗又稱合作方測驗，是軟體系統產品與用戶需求方或合作發行、開發的公司的第三方合作伙伴，目前很多軟體系統都會有一些相關聯的開發或發行的合作伙伴，

• 測驗階段：軟體大版本之后
• 測驗物件：整個軟體系統
• 測驗人員：合作方內部人員
• 測驗依據：研發需求檔案、用戶軟體認知及理解
• 測驗技術：黑盒測驗
• 測驗優點：提升用戶體驗、發現潛在問題
• 測驗內容：功能、易用、吸引性、美觀性等

補充說明：

1、三方測驗通常而言在某個大版本之后會有合作方協助進行測驗，但并非絕對，具體依據各個公司及專案的實際情況來綜合考慮測驗介入的時機

2、三方測驗通常而言只會存在功能測驗，如果發現表層的問題也會及時反饋給研發合作方，予以修復，例如軟體使用時的卡頓問題等，更多出現在游戲領域

3、三方測驗也包括用戶測驗，即β測驗階段以及λ測驗階段

七、按執行方式劃分：

7.1 手工測驗（Manual Testing）：

??手工測驗又稱功能測驗，是軟體系統測驗執行方式的常見手段，俗稱“點點點”，手工測驗也是最原始的測驗手段，用于驗證功能是否正確，

• 測驗階段：單元測驗階段后
• 測驗物件：整個軟體系統
• 測驗人員：功能測驗工程師
• 測驗依據：研發需求檔案、UI需求檔案、美術需求檔案等
• 測驗技術：黑盒測驗
• 測驗優點：保證系統的功能穩定性
• 測驗內容：功能、UI界面、集成邏輯等

補充說明：

1、手工測驗不需要任何的三方工具，只需要具備測驗理論即可進行最基礎的軟體測驗

2、有很多人認為當今的軟體/游戲市場，任何人都可以進行手工測驗，這種想法是完全錯誤的，手工測驗的要求很高并且需要專業的理論知識具備，只是在特定的行情、門檻又低的情況下，大批量的人力涌入導致所顯示的手工測驗低廉罷了

3、手工測驗大多數情況下依據測驗用例來進行執行，少部分專業性較強的測驗工程師會使用錯誤推測法以及探索性測驗的方法來進行進階的功能保障，手工測驗不能100%的找出所有問題，它只可以將軟體產品的質量無限推進于完美

7.2 自動化測驗（Automation Testing）：

??自動化測驗就是將手工測驗的行為以及流程使用自動化的方式進行代替，從而減少人力成本與時間成本，達到高效、穩定，便捷的最佳效果，

• 測驗階段：系統測驗階段
• 測驗物件：整個軟體系統
• 測驗人員：自動化測驗工程師
• 測驗依據：研發需求檔案、開發設計概要與設計檔案
• 測驗技術：白盒測驗、專項技術測驗
• 測驗優點：減少繁瑣的步驟、人力資源，提升測驗效率等
• 測驗內容：業務功能、集成邏輯等

補充說明：

1、自動化測驗不可代替手工測驗，無論軟體處于生命周期的任何階段，自動化也不可能完全取代，自動化測驗的建立是在手工測驗的基礎上進行的

2、自動化測驗分多個測驗方向領域、介面自動化、性能自動化、安全自動化等且學習成本較高，時間成本較大，各位萌新們仔細思考對應的路線并進行學習哦~

3、自動化測驗更多的情況下是進行回歸測驗，而非第一次測驗，一次測驗往往是由手工代替，自動化測驗更多做的是重復性的作業，其主要的代表性作業就是回歸測驗

八、按測驗地域劃分：

8.1 本地化測驗（Localization Testing）：

??本地化測驗就是軟體的本地化測驗，例如一個西方版本的微信，那么換成國內版本的微信就是本地化測驗，一個特定的人文區域的測驗也是本地化測驗，我們所從事的大多數測驗作業都是本地化測驗

• 測驗階段：專案全階段
• 測驗物件：整個軟體系統
• 測驗人員：功能測驗工程師、自動化測驗工程師、性能測驗工程師等
• 測驗依據：研發需求檔案、UI需求檔案等
• 測驗技術：黑盒測驗、灰盒測驗、白盒測驗、專項技術測驗
• 測驗優點：保障在本地環境運行的兼容性、正確性等
• 測驗內容：軟體本地運行的文化、喜好、UI、文本內容等

補充說明：

1、評判一個軟體是否是本地化測驗的直接標準就是這個軟體的服務器運行時間是否是東八區的時間即國內的北京時間，其次的標準是是否為簡體中文的國內語言，符合上述兩個條件才能夠稱之為本地化測驗，這是所有本地化測驗最核心的前提

2、本地化測驗中還存在地域測驗，日常的測驗中并非所有的測驗工程師都在進行本地化測驗，本地化測驗具有一定的領域劃分，你可以理解成我們所認知的麻將有四川麻將、東北麻將，以四川麻將舉例，如果要進行四川麻將的測驗，那么這套麻將的玩法就必須符合四川本地人的喜好、文化，也就是所謂的本地化測驗

3、本地化測驗具有一定顯著的鮮明、特征，例如國內的軟體測驗，那么軟體需要符合一定的行業標準、執行標準等，類似于依從性

8.2 國際化測驗（International Testing）：

??國際化測驗的目的是測驗軟體的國際化支持能力，發現軟體的國際化的潛在問題，保證軟體在世界不同區域中都能正常運行，國際化測驗使用每種可能的國際輸入型別，針對任何區域性或區域設定檢查產品的功能是否正常，

• 測驗階段：集成測驗階段、系統測驗階段、驗收測驗階段
• 測驗物件：整個軟體系統
• 測驗人員：功能測驗工程師、自動化測驗工程師
• 測驗依據：研發需求檔案、UI需求檔案等、國際標準依從性
• 測驗技術：黑盒測驗
• 測驗優點：保障在國際化環境運行的兼容性、正確性等
• 測驗內容：軟體國際化運行的正確性、兼容性、文化習慣、政治要求等

補充說明：

1、本地化測驗的重點更多在于本地的文化習俗內容，而國際化測驗重點在于國際的政治要求，雖然其他內容也需要測驗，這是兩種測驗對比的明顯差距

2、國際化測驗更多的測驗的是輸入域、輸出域，語言的輸入、輸出，不同的時間時區、貨幣格式、文化習慣、政治要求，特定圖片檢測等（例如某宗教不吃豬，這個產品又要發布在這個國家地區，理論上不應存在與豬負面的相關圖片等一系列的負面言論，甚至部分國家有明確的寫進法律法規中，這也是對政治要求、文化習慣的測驗）

3、國際化測驗前的準備環境通常是軟體為對應地區的版本軟體（對應地區是指對應地區本地的測驗版本，并非國內版本修改語言的形式）且硬體設備服務器的時間也同為對應國際化地區的時間

??

九、其他類合集：

9.1 全量測驗（Omnidirectional Test）：

??全量測驗屬于黑盒測驗技術的一種也屬于手工測驗，全量測驗是指對整個軟體系統的二次全覆寫測驗，主要為執行業務層面的測驗用例達到系統全覆寫，進而避免問題二次修復或遺漏的內容的進階保障手段，

• 測驗階段：系統測驗階段
• 測驗物件：整個軟體系統
• 測驗人員：功能測驗工程師
• 測驗依據：研發需求檔案、UI需求檔案等
• 測驗技術：黑盒測驗
• 測驗優點：排查軟體系統中的疑難雜癥以及遺漏問題等，進階保證產品質量
• 測驗內容：軟體功能、集成內容等

補充說明：

1、全量測驗只針對于軟體系統的業務功能測驗，其他部門所謂的“全量測驗”稱之為回歸測驗

2、全量測驗并非只能由業務功能的測驗工程師完成測驗，其他的測驗人員通常而言可以給予一些建議性或指導

3、全量測驗的次數不定，時間不定，依據各個專案需要決定，部分公司為了快速上線可能只會進行一次全量測驗甚至沒有全量測驗，而一些實力強勁的公司會在上線前組織2到5次不等的全量測驗，專案越大，意味著全量測驗的次數越多，暴露風險的可能性才會越大，不少國外的3A游戲巨作就會存在多次的全量測驗，

9.2 隨機測驗（Ad hoc testing）：

??隨機測驗又稱即興測驗，主要是對被測軟體系統的重要核心功能以及關鍵集成邏輯進行的復測，通常而言如果專案時間不完全無法進行全量測驗，那么可以由特定且專業的測驗工程師進行即興測驗，從全量測驗的所有覆寫點中挑取最核心、最重要的內容進行測驗，

• 測驗階段：系統測驗階段
• 測驗物件：整個軟體系統
• 測驗人員：功能測驗工程師、性能測驗工程師
• 測驗依據：研發需求檔案、性能測驗需求
• 測驗技術：黑盒測驗、專項技術測驗
• 測驗優點：排查軟體系統中的疑難雜癥以及遺漏問題等，進階保證產品質量
• 測驗內容：軟體功能、集成內容、軟體性能等

補充說明：

1、隨機測驗不僅僅用作于全量測驗的備用手段，也用作于日常支援性作業以及日常需求冒煙的測驗手段

2、隨機測驗不僅僅要對軟體系統的功能進行測驗也需要對軟體系統的性能進行測驗，所測驗的場景可以為核心主干場景，也可是其他場景，依據專案時間、人力等多因素安排

3、隨機測驗可以是組員內的互動進行，并非必須由一個人來完成，隨機測驗沒有明確的起點和終點，可隨時停止，亦可由其他人反復的檢驗和交替測驗

9.3 煙霧測驗（Smoke Testing）：

??煙霧測驗是指開發人員在個人版本的軟體上執行目前的煙霧測驗專案，確定新的程式代碼不出故障，

• 測驗階段：任意階段
• 測驗物件：私有的公用軟體版本
• 測驗人員：開發人員、自動化測驗工程師、測驗開發工程師
• 測驗依據：軟體測驗理論基礎
• 測驗技術：黑盒測驗
• 測驗優點：階段性的復查
• 測驗內容：軟體版本功能

補充說明：

1、煙霧測驗又稱為自測，所謂的開發自測其實就是煙霧測驗的一種說法，煙霧測驗不僅僅用于開發，自動化工程師對于自己的自動化腳本也需要進行煙霧測驗， 測驗開發的工程師亦是如此

2、煙霧測驗最重要的就是版本的功能驗證，其他的內容也會驗證，但會比較少，大多數情況下的煙霧測驗都是進行功能測驗，以檢驗新的程式代碼的正確性

3、煙霧測驗的英文與冒煙測驗的英文一致，不用驚慌，設計如此，但煙霧測驗并非同冒煙測驗，冒煙測驗更多的是針對公用版本的即產品版本的核心功能檢查，而煙霧測驗則是開發私有的特殊化公用版本或自行的腳本檢查，兩者有本質上的區別

9.4 敏捷測驗（Agile Testing）：

??敏捷測驗即是不斷修正質量指標，正確建立測驗策略，確認客戶的有效需求能得以圓滿實作和確保整個生產的程序安全的、及時的發布最終產品，

• 測驗階段：任意階段
• 測驗物件：整個軟體系統
• 測驗人員：功能測驗工程師
• 測驗依據：軟體測驗理論基礎
• 測驗技術：黑盒測驗、白盒測驗
• 測驗優點：提升測驗效率，推動專案流程建設等
• 測驗內容：全方位內容，主要為自動化測驗

補充說明：

1、強調從客戶的角度，即從使用系統的用戶角度，來測驗系統，重點關注持續迭代地測驗新開發的功能，而不再強調傳統測驗程序中嚴格的測驗階段

2、敏捷測驗通常具有敏捷性且擁有敏捷開發的相關特性，例如測驗驅動開發（TDD）、驗收測驗驅動開發（ATDD）等，建議盡早開始測驗，對于高度迭代的內容、有周期性的高效率反饋以及測驗驅動開發的思想就是敏捷測驗思想的核心

3、敏捷測驗在國內的軟體及游戲行業盛行，其主要原因是能夠加快專案的進度流程效率，但不巧的是，往往很多公司的測驗人員不能夠很好的掌握敏捷測驗的技術要點和思想，在發布的時候往往會因為敏捷測驗的方式，遺漏很多問題在正式服上，造成測驗遺漏，筆者建議大家學習敏捷測驗，但應在熟練掌握各類軟體測驗理論的基礎上加以使用，才能更好的保證測驗質量哦~

9.5 配置測驗（Configuration Testing）：

??配置測驗是指使用各種硬體來測驗軟體運行的程序，配置測驗方法是指通過對被測系統軟硬體環境的調整，了解各種不同環境對系統性能影響的程度，從而找到系統各項資源的最優分配原則，

• 測驗階段：系統測驗階段
• 測驗物件：整個軟體系統的硬體運行
• 測驗人員：硬體測驗工程師、硬體性能測驗工程師
• 測驗依據：性能測驗需求
• 測驗技術：專項測驗
• 測驗優點：找到系統資源的最佳分配
• 測驗內容：各個介面、外設、設備驅動、主板以及內部設備等

補充說明：

1、配置測驗多數是硬體，在游戲行業中配置測驗大多數指明的是配置表的測驗，配置表測驗則是對一系列Excel格式的csv表的各個欄位進行測驗，以便于服務端及客戶端對于資料的讀取，實時呈現最終的游戲效果展示，或是實作特定的功能等

2、硬體的配置測驗實行難度較大，它與手工測驗相同，也有一套完整的測驗體系以及測驗流程，硬體的配置學習更新較快，主要源于現階段的硬體更新迭代速度，測驗人員需要不斷的學習、探索，才能掌握最新的硬體資訊和行情

3、硬體配置測驗在人們的認知中大多數情況下出現在游戲領域，例如登錄王者榮耀后，系統會默認識別你的手機型號、品牌以及各項引數，來默認調整你的畫質、辨識度等內容，在一些PC游戲上，大多數游戲都會有最低配置以及推薦配置的硬體配置表，主要就是根據配置測驗的最終結果來得出的結論

9.6 通過性測驗（Passability Test）：

??通過性測驗實際上是確認軟體至少能做什么，而不會考驗其能力，軟體測驗人員并不需要要想盡辦法讓軟體崩潰，僅僅運用最簡單、最直觀的測驗用例，

• 測驗階段：單元測驗階段后
• 測驗物件：整個軟體系統
• 測驗人員：功能測驗工程師
• 測驗依據：業務測驗用例
• 測驗技術：黑盒測驗
• 測驗優點：確保各個模塊的基本保證
• 測驗內容：系統模塊間的各項基礎功能

補充說明：

1、通過性測驗不等同于冒煙測驗，冒煙測驗是測驗每一個模塊中最核心的主流程，而通過性測驗是不僅僅測驗主流程，還需要測驗其他的簡單的、直觀的功能，測驗量要大于冒煙測驗

2、筆者更建議大家在日常的需求測驗或版本測驗之前先進行通過性測驗，這樣有助于快速發現一些明顯問題，避免執行測驗用例到尾聲以后才進行問題暴露，會拖慢測驗進度

3、通過性測驗可以由功能測驗人員進行，也可以由其他人員進行測驗，例如性能測驗也存在有性能測驗用例、安全領域也是相同的，不僅僅只運用于功能測驗，但大多數情況下我們所說的通過性測驗都是功能測驗，性能、安全等專項領域的測驗工程師，也可根據組內所設計的測驗用例進行通過性測驗

9.7 失效性測驗（Failure Test）：

??失效性測驗與通過性測驗是對立面，失效性測驗會考驗被測軟體系統的能力，軟體測驗人員需要想盡一切辦法攻破軟體系統，盡可能使其崩潰，

• 測驗階段：單元測驗階段后
• 測驗物件：整個軟體系統
• 測驗人員：功能測驗工程師
• 測驗依據：業務測驗用例
• 測驗技術：黑盒測驗
• 測驗優點：確保各個模塊的基本保證
• 測驗內容：系統模塊間的功能、性能、安全等方面

補充說明：

1、失效性測驗沒有明確要求具體需要哪一方面的測驗用例，與通過性測驗比較接近，可以是功能、性能、安全領域的測驗用例，但目的不會發生改變，就是想盡辦法使其軟體系統崩潰

2、失效性測驗的測驗順序嚴格意義上必須在通過性測驗之后進行，在未進行過通過性測驗后所進行的失效性測驗是不符合軟體測驗規范的，很可能會引起一些不必要的質量麻煩

3、失效性測驗的測驗方面更廣泛，時間不定，在大多數情況下都可以進行失效性的測驗且不受具體的人員限制

9.8 健壯性測驗（Robustness Testing）：

??健壯性測驗又稱為容錯性測驗，用于測驗系統在出現故障時，是否能夠自動恢復或者忽略故障繼續運行，

• 測驗階段：系統測驗階段
• 測驗物件：整個軟體系統
• 測驗人員：系統測驗工程師
• 測驗依據：部分研發需求檔案、預期系統健壯性目標等
• 測驗技術：無技識訓分
• 測驗優點：提高系統的穩定性以及容錯能力
• 測驗內容：軟體系統遇到報錯例外的解決能力

補充說明：

1、健壯性測驗關注整個軟體系統出現例外解決的能力，如果出現了例外是否能夠做到忽略例外或常識性的自主解決例外，保證系統的正常運行

2、健壯性測驗通常在系統測驗階段或系統測驗階段后，過早的提前介入健壯性測驗的意義不大，并且可能有其他風險

3、健壯性測驗不等同于恢復性測驗，容錯測驗一般是輸入例外資料或進行例外操作，以檢驗系統的保護性，而恢復性測驗是通過各種手段，讓軟體強制性地發生故障，然后驗證系統已保存的用戶資料是否丟失、系統和資料是否能很快恢復

9.9 恢復性測驗（Recovery Testing）：

??恢復性測驗是測驗一個系統從災難或出錯中能否很好地恢復的程序，如遇到系統崩潰、硬體損壞或其他災難性出錯，可恢復測驗一般是通過人為的各種強制性手段讓軟體或硬體出現故障，然后檢測系統是否能正確的恢復（自動恢復和人工恢復），

• 測驗階段：系統測驗階段
• 測驗物件：整個軟體系統
• 測驗人員：系統測驗工程師
• 測驗依據：部分研發需求檔案、預期系統健壯性目標等
• 測驗技術：無技識訓分
• 測驗優點：提高系統的穩定性以及容錯能力
• 測驗內容：軟體系統遇到報錯例外的解決能力

補充說明：

1、可恢復測驗通常需要關注恢復所需的時間以及恢復的程度，主要包括硬體、軟體、資料、通信四大方面

2、實際的硬體設備是有很多恢復性測驗的手段，例如多生成樹的網路技術、服務器負載均衡等，這些都可以有效的保證硬體服務器設備出現致命級錯誤時能夠快速回應恢復，軟體系統也有很多恢復性測驗的手段，最重要需要防止的就是資料丟失

3、恢復性測驗在我們身邊是非常常見的測驗手段，需要引起高度重視，一旦出現問題，對于軟體產品來說是致命級的打擊，以筆者的建議，大家都應該學習或至少了解并應用到實際專案當中

十、游戲行業術語：

10.1 封閉測驗（Closed Test）：

??封閉測驗又稱為封測，是指游戲在很初期且有一些成型的時候，開放少部分名額對外的測驗手段，封閉測驗在內測之前，相當于在軟體測驗中的α測驗前，主要用于收集玩家對于游戲第一印象以及對玩法的部分規劃喜好等收集，同時也收集部分玩家所反饋的Bug以及建議性內容用以完善，

• 測驗階段：單元測驗階段之前或單元測驗階段
• 測驗物件：整個游戲系統
• 測驗人員：外部玩家
• 測驗依據：玩家對游戲的自主認知
• 測驗技術：黑盒測驗
• 測驗優點：快速反饋出游戲當前所存在的問題，提升游戲優化
• 測驗內容：游戲玩法、系統的易用性、美觀性、可玩性等

補充說明：

1、在游戲行業中大多數公司已經不實行封閉測驗了，其主要原因有兩種，第一種是大型的游戲不想過早的暴露給競爭市場，告訴市場我要出一款這一類的游戲，這樣可能會增大其他競爭對手的打擊力度，第二種是因為整個游戲有過多可以優化的內容和方向，內部策劃可以完全不需要用戶提供反饋以及建議性內容仍然可以繼續進行游戲的開發制作，通常而言部分參與到游戲體驗的體驗人員有一定的獎勵且有在簽署保密協議，具有保密義務

2、封閉測驗雖然很少公司在實行甚至是寥寥無幾，但封閉測驗更核心的點在于能夠提前暴露出玩家的喜好和游玩意愿，如果做出一款自認為的精品游戲但玩家卻不愿意買單，那么終究也是功虧一簣

3、封閉測驗只能在單元測驗階段或之前介入，在單元測驗階段之后所對外的測驗無法稱之為封閉測驗

10.2 刪檔測驗（Delete file test）：

??刪檔測驗多數屬于對封測、內測的一種附加條件，很多游戲會有一定的存盤資料，會明確告知玩家游戲會進行刪檔測驗，其主要的刪檔原因是因為需要保證游戲上線后玩家的起點水平線一致

• 測驗階段：封測、刪檔測
• 測驗物件：整個游戲系統
• 測驗人員：外部玩家、內部玩家
• 測驗依據：玩家對游戲的自主認知
• 測驗技術：黑盒測驗
• 測驗優點：保證游戲上線后的資料公平性
• 測驗內容：游戲玩法、系統的易用性、美觀性、可玩性等

補充說明：

1、刪檔測驗通常只存在于游戲行業，軟體行業幾乎沒有類似的說法

2、刪檔測驗可用于封測或本身刪檔測驗，我們所說的公測是面向廣大玩家的測驗，并非刪檔測驗，換而言之，如果存在刪檔行為，那么就不是公測

3、這里的“檔”指的是玩家在測驗期間在游戲內產生了游戲資料，而刪檔則是在停止測驗后對玩家資料的清除

??

??
??
??好啦~以上就是本次文章分享的全部內容啦，你學會了嗎？希望能給大家帶來幫助哦！
??