我們在測試項目管理中，初期預研階段，就要通過仔細分析和研究，確定以后工作中所要采用的測試類型。不同的測試項目，所選取的測試類型也必定不同。具體選用哪些，需視項目實際情況而定！
簡單來說，這些不同的測試類型，是按照不同的測試對象和測試范圍劃分的。
我們以手機終端軟件的測試項目為例，具體分類及包含關系如下圖示：
版本測試（Build Check/ Release Test）是開發完成代碼設計和Code review、集成并發布后，測試人員拿到該測試版本，首先要做的一類測試。
它的測試范圍極窄，大概包括20~30條用例，都是最基本的功能用例，需保證1人在半小時內測完。
對軟件項目來說，根據子模塊的大小、需求粒度等，每個子模塊只選取3-5條基本用例。
Build Check的目的是為了第一時間驗證版本的正確性/穩定性，保證之后的測試中，各子模塊不會出現嚴重的、阻塞基本功能的Block Issues。
如果在版本測試中發現阻塞正常測試的嚴重問題，需第一時間提交給開發解決。測試工作暫時Block，轉而關注問題的分析、解決與跟進。
如版本測試順利通過，才能開展后續的所有測試，所以它是測試工作的一個前提條件。
目前很多持續集成工具如Hudson等均可加入實現了自動化測試執行的版本測試套件，當自動生成Daily Build后，馬上開始后續的Unit Test、Coverage Test、Lint Test、Build Check等。
在項目開始的需求開發階段，敏捷開發模式下，我們執行的是迭代測試，包括功能測試和健全測試。
因在開發階段，PD/UI都不夠穩定，開發也在頻繁進行代碼修訂，這個時期不適合采用大規模的產品測試。
而迭代測試是適合于敏捷開發模式下的一類測試，它可以緊跟開發/需求/UI的變更步伐，做一些小規模、針對性的測試工作。
其中，功能測試（Function Test）是測的最基本功能點和需求，也就是UI上的功能模塊設計、業務流程設計、需求點設計實現等。它模擬是正常用戶的正常行為，一般均為單任務，不牽扯交互、壓力、異常操作等。而健全測試（Sanity Test）是系統測試的一個子集，它包含的是系統測試用例中的基本部分，相當于在系統測試之前所做的一次預測試。
健全測試達到標準，表示已達系統測試開始的準入條件之一，決定是否可進行全面的系統測試！
一般健全測試用例數量占系統測試數的1/3左右，包括了所有K（Key）、M（Mandatory）型的測試用例，不包含O（Optional）型。
系統測試是在產品測試階段進行，它的覆蓋范圍極廣，是對于軟件產品的最重要測試內容之一。
當前期敏捷開發階段的需求測試（REQ Test）和基本功能測試、健全測試執行通過后，可認為產品質量已基本穩定，將前期測試結果作為準入條件，就可以開展后續的全面系統測試了。
應注意的是：系統測試（System Test）是針對整個產品、整個軟件系統所做的全面測試，而不是只針對單個功能、REQ或單一業務流程。
它一般是在通過了Alpha release，迭代測試結束后，已經確保80%的功能集成且均REQ被分別測試，此時再開展系統測試，才有作用和意義。
我們在系統測試中，定義了如上圖示所列的各種測試類型。
當然在不同的項目中，有時還需要定義一些Special Test Category如安全性測試、完整性測試、一致性測試、集成測試等。
舉例如手機上的客戶端項目中，比較特殊的用例類型就是三層結構測試，因客戶端設計原因，它是處于底層數據連接和上層App應用之間的夾層。
所以可以設計基于“數據連接——客戶端——上層應用”的三層結構測試，考核數據連接/設置/數據傳輸、上層App的啟動、退出和異常場景等使用情況對于客戶端的影響。
交互測試（Interaction Test）是指的在同一測試機型上，被測模塊（如手機客戶端）與本機其它模塊之間的交互測試，
尤其是涉及接口調用和功能交叉的一些模塊，類似客戶端代碼中調用的其它模塊、客戶端狀態與數據連接設置的交叉、客戶端計時與本地計時的功能交叉等。
互操作測試（Inter-Operability Test）是指的被測產品與其它機型之間的交互，主要涉及信息、協議、信號解析的匹配與兼容性問題。
例如不同機型對于短信的解析方式不同，可能導致互發后字符顯示亂碼，所以測信息時必須考慮互操作測試。
但這主要針對不同解析方式和協議兼容性的，如果客戶端有統一定義的業務/測試協議規范，不涉及這個問題，系統測試中就可以不考慮這個類型！
性能測試（Performance Test）是針對產品/軟件性能所做的度量測試，同時包括軟件產品與競品的性能對比測試。
首先要在各種業務規范、測試規范、SW設計文檔、需求規格文檔等各規范文檔及UI/PD設計中，采集了所有的性能指標。
然后可使用本機自帶工具、自己開發測試工具、自動化測試腳本、網上搜尋的工具等，對這些性能指標進行精準度量，得到性能指標的測試結果。
壓力測試（Stress Test）是指在各種壓力情況和異常場景下，產品/軟件功能使用的測試工作。
如客戶端的連續登錄、下線100次，連續查詢100次，各種異常下線，多用戶同時登錄，網絡信號變弱等，尤其應關注各種異常場景下的功能使用狀況。
這部分測試，如果能用自動化測試工具完成的，可測試100次。
一些涉及網絡覆蓋、信息接收、驗證碼輸入等無法通過自動工具完成的，可手動執行20次。
邊界測試（Boundary Test）是指各種功能使用在極限情況下的測試，不僅是界面上的邊界，也包括功能中的極大/極小邊界、極多/極少值等。
例如客戶端的安裝包，所能正常安裝的最長路徑長度（chars），最深存儲文件夾層數（層），登陸用戶名的最小字符數（個）等，都應當作為測試點。
如果邊界測試的用例數較少，可以直接并入系統測試用例中，不必單獨列為一類，以免增加統計難度。
兼容性測試（Compatibility test）是指產品或軟件對于各種環境、設備、網絡、解析規范等的適配能力測試。
比如普通的軟件產品，要測試基于各種OS（例Windows XP/ Win 2000/ Linux/ Mac OS/ Ubantu）、不同支持軟件（例Outlook2003/ Outlook2007）的兼容能力。
而手機客戶端，主要通過四類測試來考核其兼容適配能力：終端適配測試、SIM卡兼容性測試、設備兼容性測試、網絡兼容性測試。
終端適配測試就是上圖中所說的適配測試，因手機客戶端是一個嵌入式系統，軟硬件不可分割，故并入兼容性測試中。
它測試的是不同分辨率、不同OS平臺、不同硬件配置的機型對于客戶端的適配兼容能力，我們在測試過程中，主要基于以下考慮：
市場主流機型Top 20，主流分辨率，市場占據較多的OS前三位及其版本、主流設計商的芯片、對大字體設置的支持能力等等。
SIM卡兼容性測試，是針對不同運營商、不同業務類型的SIM卡所做的兼容能力測試。
如客戶端是基于移動SIM卡開發的業務功能，則其中的短線接收，必須用移動卡才能正常接收，而在項目初期研發階段，可能開發未考慮處理SIM卡兼容問題，就會導致使用聯通/電信SIM卡會死在短線發送界面。此類測試解決的就是這些漏洞和問題！
設備兼容性測試，這類測試需要借助一些專業的模擬網絡環境和實驗室，它可以模擬不同廠商的設備，保證客戶端產品在所需的各種設備下都可以正常工作！
網絡兼容性測試，對于客戶端來說，主要就是外場測試，包括企業內部外場區域和外部區域、移動區域等。
它的測試目的是為了驗證客戶端在各種網絡環境下的功能適配能力，執行的是全部功能+系統測試用例，在發現問題后還應做針對性測試。
系統測試中，還包括內存泄漏測試（Memory-Leak Test）、數據庫測試（Database Test）。
內存測試主要針對應用軟件的內存管理和釋放機制，測試當大數據量傳輸、數據阻塞、頻繁操作等異常情況下，內存使用和釋放的正常性。
一般使用自動化工具來進行此類測試，少量的內存測試用例可并入性能測試用例中。
數據庫測試是一類重要測試類型，主要測客戶端與后臺Server之間的數據傳輸、并發、準確同步等。
一般手機客戶端和后臺的各類服務器等都有數據交互，應當針對這些Server進行專門的服務器測試，其中數據庫測試和文件系統測試自然是重要組成部分！
項目開發前期，即自Kick off至Alpha release階段，跟隨軟件的快速變化，我們所做的是迭代測試（REQ Test/ Function Test/ Sanity Test）。此間每天采用CIS自動生成的Daily build，在更新版本上進行迭代式測試。在Scrum Team內隨時與開發、產品進行溝通，快速反應解決問題。
項目中期，自Alpha release ~ Beta release階段，功能模塊已基本集成，需要開始執行大規模的系統測試，并穿插周期性的功能測試。測試頻度和范圍視項目的測試周期、人力而定，但一般開始要先執行一輪全面系統測試（Full ST），以正確、完整地評估軟件產品質量。
之后再根據各模塊成熟度和缺陷狀況，決定如何對FT和ST進行針對性裁剪，選擇新增模塊、薄弱模塊和重點模塊的關鍵項用例來對軟件產品做局部測試。
此期間延長軟件版本的迭代周期，每周更換2~3個測試版本，而不是每天更新版本。但需隨時監察Release note和與開發及時溝通，知道有較大的功能性改動或重要的bug-fix時，就及時更換新版本進行測試！
最后一個階段——項目后期，也就是Beta release ~ Final/Product release之間的階段，是產品發布測試期。此時已進入產品穩定和待發布期，在此期間，就不能像以前一樣頻繁更換測試版本了。一般產品質量較好時，我們采用每周更換一次新版本的更新頻度。
在這個階段內，需要做的就是針對發布版本（Release candidate）的產品級測試，包括所有系統測試類型、驗收測試、缺陷跟進及處理等。
在產品發布之前1~2周，一定要最后做一次全面覆蓋測試（Full Test），包含功能測試、系統測試的全部用例執行，以在最大程度上保證發布產品的總體質量！
如上所述，當功能測試、系統測試、缺陷數量等均已達QA所訂的質量目標后，在正式發布之前，當PD/UI已完全確定、穩定時，我們要做一輪驗證測試。
驗證測試（Verification Test）是針對PD/UI/GUI的核查和驗證，主要包括需求測試和UI驗證。
需求測試是核查所有需求點，看其所標示的功能是否已在軟件發布版本上正確、完整實現。
UI/GUI驗證是核查軟件產品的功能，是否與UI上標示的業務流程、界面顯示完全一致，GUI中的每個Text/Graphic/Icon大小、顏色、色階色深是否與定義一致。
最后一類測試，就是穩定性測試，主測兩個指標——MTBF和MTTF，均使用自動化測試工具實現。
MTBF也就是平均無故障運行時間，應使用自動化Tool，在4臺測試機上進行連續的、模擬用戶行為的功能測試，取其均值作為考核指標。
另外MTTF測試是在Android系統下直接運行adb命令，模擬在測試機上亂點亂劃的行為，考察無故障運行時間。這是另一類穩定性測試！
注意：為通過Alpha/Beta/Final release，我們有時會在里程碑截止日期（Milestone Deadline）到達之前，針對未達質量目標的功能測試/系統測試，再做一輪回歸測試，以驗證通過Release standard。
而各階段測試期間，我們也會針對局部的重點問題、嚴重缺陷和關鍵功能，做一些針對性測試，如焦點測試、集中測試、探索測試、自由測試等。其實從真正意義上來說，這些已經不屬于測試類型的范疇，而是一些不同的測試方法！
回歸測試（Regression Test），是針對之前的一輪測試進行的再次測試驗證，以達到QA定義的質量指標。FT/ST等都可以做回歸，但以ST Regression較為重要。
回歸測試的范圍主要包括以下三部分：上輪測試中的Fail case，需重新驗證看是否已Pass；目前遺留的所有缺陷，進行修復驗證；針對缺陷集中的薄弱模塊、重點模塊，進行引申測試。
焦點測試（Focus Test）也就是專題測試。當測試過程中發現嚴重且普遍、涉及模塊較多、影響較大的缺陷或問題時，應馬上安排人手進行專門性測試。Test Leader圍繞此問題設計專題測試用例，測試人員在執行過程中，也要自己進行思維發散和延伸，多做一些周邊的操作測試，以在最大程度上發現可能的隱藏缺陷！
集中測試（Test Workshop），亦稱圓桌測試，也是在產品測試過程中經常采用的一種測試方式。顧名思義，它就是把一群用戶級測試人員集中起來，在一個封閉會議室中，大家圍著圓桌共同進行產品使用和測試。這些人可以是真正不了解產品的最終用戶（End User），也可以是相互交換測試模塊后的專職測試人員。測試的目的就是為了集中發現問題，尤其是那些因測試習慣性思維和行為盲區導致的潛在缺陷和風險點。
探索測試（Exploratory Test），簡稱ET，其實是一種有導向、有目的的自由測試方法。它采用了一些科學統計和分析方法，針對性地對一些重要、關鍵測試點和模塊、范圍進行測試。主要由一名ET Leader做主導，負責定義Test point、安排測試內容/人力/時間、一對一開會討論、總結編寫ET Report等。
自由測試（Free Test）就很簡單了，大家都知道，就不多做贅述了。FreeTest可以隨便找人來使用軟件產品，尋找潛在的風險和隱藏的問題。也可以設定特定的目標用戶群，從其中各抽出一部分人來集中進行自由測試。這樣對樣本點采集的全面性和可靠性更有意義，有時我們也會這樣做！
總之，測試類型千變萬化，但萬變不離其宗。我們在真正的測試項目管理中，一定要認真考慮、分析清楚當前處于哪個階段、面臨哪些重要問題、針對這些情況應采取何種測試類型來應對。
天底下所有的技術、知識都是死的，運用存乎一心，只有它們變成了你身體的一部分，真正能夠掌握、運用和創新改進的時候，你才能說“我真的會了！”
版權聲明：本文出自 cmriqa 的51Testing軟件測試博客：http://www.51testing.com/?489136
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。