常用的軟體測試方法

隨著軟體測試技術的不斷髮展，測試方法也越來越多樣化，針對性更強；選擇合適的軟體測試方法可以讓我們事半功倍。以下是一些常用的軟體測試方法：

　　β測試_Beta測試

　　β測試，英文是Beta testing。又稱Beta測試，使用者驗收測試（UAT）。

　　β測試是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發人員通常不在測試現場，Beta測試不能由程式員或測試員完成。

　　當開發與測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發行前找到。這種測試一般由終端使用者或其他人員完成，不能由程式員或測試員完成。

　　α測試_Alpha測試

　　α測試，英文是Alpha testing。又稱Alpha測試.

　　Alpha測試是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在類比實際作業環境下進行的受控測試，Alpha測試不能由該系統的程式員或測試員完成。

　　在系統開發接近完成時對應用系統的測試;測試後，仍然會有少量的設計變更。這種測試一般由終端使用者或其他人員來完成，不能由程式員或測試員完成。

　　可移植性測試

　　可移植性測試，英文是Portability testing。又稱相容性測試。

　　可移植性測試是指測試軟體是否可以被成功移植到指定的硬體或軟體平台上。

　　使用者介面測試-UI測試

　　使用者介面測試，英文是User interface testing。又稱UI測試。

　　使用者介面，英文是User interface。是指軟體中的可見外觀及其底層與使用者互動的部分（菜單、對話方塊、視窗和其它控制項）。

　　使用者介面測試是指測試使用者介面的風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等等。UI 測試的目標是確保使用者介面會通過測試對像的功能來為使用者提供相應的訪問或瀏覽功能。確保使用者介面符合公司或行業的標準。包括方便使用性、人性化、易操作性測試。

　　使用者介面測試使用者分析軟體使用者介面的設計是否合乎使用者期望或要求。它常常包括菜單，對話方塊及對話方塊上所有按鈕，文字，出錯提示，協助資訊 (Menu 和Help content)等方面的測試。比如，測試Microsoft Excel中插入符號功能所用的對話方塊的大小，所有按鈕是否對齊，字串字型大小，出錯資訊內容和字型大小，工具列位置/表徵圖等等。

　　煙霧測試 (Smoke Test)

　　煙霧測試 (Smoke Test)，英文是Smoke testing。

　　煙霧測試 (Smoke Test)的名稱可以理解為該種測試耗時短，僅用一袋煙功夫足夠了。也有人認為是形像地類比新電路板功準系統檢查。任何新電路板焊好後，先通電檢查，如果存在設計缺陷，電路板可能會短路，板子冒煙了。

　　煙霧測試 (Smoke Test)的對像是每一個新編譯的需要正式測試的軟體版本，目的是確認軟體準系統正常，可以進行後續的正式測試工作。煙霧測試 (Smoke Test)的執行者是版本編譯人員。

　　隨機測試

　　隨機測試，英文是Adhoc testing。

　　隨機測試沒有書面測試案例、記錄期望結果、檢查列表、指令碼或指令的測試。主要是根據測試者的經驗對軟體進行功能和效能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。

　　隨機測試主要是對被測軟體的一些重要功能進行複測，也包括測試那些當前的測試範例(Test Case)沒有覆蓋到的部分。另外，對於軟體更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環境、並發性、進行檢查。尤其對以前測試發現的重大Bug，進行再次測試，可以結合迴歸測試 (Regressive testing)一起進行。

　　本地化測試

　　本地化測試，英文是Localization testing。

　　本地化就是將軟體版本語言變更，比如將英文的windows改成中文的windows就是本地化。本地化測試的對像是軟體的語言版本。本地化測試的目的是測試特定目標地區設定的軟體本地化品質。本地化測試的環境是在本地化的作業系統上安裝本地化的軟體。從測試方法上可以分為準系統測試，安裝/卸載測試，當地地區的軟硬體相容性測試。測試的內容主要包括軟體本地化後的介面布局和軟體翻譯的語言品質，包含軟體、文檔和線上說明等部分。

　　本地化能力測試

　　本地化能力測試，英文是Localizability testing。

　　本地化能力測試是指不需要重新設計或修改代碼，將程式的使用者介面翻譯成任何目標語言的能力。為了降低本地化能力測試的成本，提高測試效率，本地化能力側是通常在軟體的偽語言版本上進行。

　　本地化能力測試中發現的典型錯誤包括：字元的寫入程式碼（即軟體中需要本地化的字元寫在了代碼內部），對需要本地化的字元長度設定了固定值，在軟體運行時以控制項位置定位，表徵圖和位元影像中包含了需要本地化的文本，軟體的使用者介面與文檔術語不一致等。

　　國際化測試

　　國際化測試，英文是International testing。又稱國際化支援測試。

　　國際化測試的目的是測試軟體的國際化支援能力，發現軟體的國際化的潛在問題，保證軟體在世界不同地區都能正常運行。國際化測試使用每種可能的國際輸入類型，針對任何地區性或地區設定檢查產品的功能是否正常，軟體國際化測試的重點在於執行國際字串的輸入/輸出功能。國際化測試資料必須包含東亞語言、德語、複雜指令碼字元和英語（可選）的混合字元。

　　國際化支援測試是指驗證軟體程式在不同國家或地區的平台上也能夠如預期的那樣運行，而且還可以按照原設計尊重和支援使用當地常用的日期，字型，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字串?又比如，日文版的Microsoft Excel對話方塊是否顯示正確翻譯的日語?一旦來說執行國際化支援測試的測試人員往往需要基本上瞭解這些國家或地區的語言要求和期望行為是什麼。

　　安裝測試

　　安裝測試，英文是Installing testing。

　　安裝測試是確保軟體在正常情況和異常情況下，例如，進行首次安裝、升級、完整的或自訂的安裝都能進行安裝的測試。異常情況包括磁碟空間不足、缺少目錄建立許可權等情境。核實軟體在安裝後可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進行安裝，安裝代碼提供安裝一些程式能夠啟動並執行基礎資料。

　　白盒測試-結構測試-邏輯驅動測試

　　白盒測試，英文是White Box Testing。又稱結構測試或者邏輯驅動測試。

　　白盒測試是把測試對像看作一個開啟的盒子。利用白盒測試法進行動態測試時，需要測試軟體產品的內部結構和處理過程，不需測試軟體產品的功能。

　　白盒測試法的覆蓋標準有邏輯覆蓋、迴圈覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。

　　白盒測試是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。

　　白盒測試常用工具有：Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。

　　黑箱測試-功能測試-資料驅動測試

　　黑箱測試，英文是Black Box Testing。又稱功能測試或者資料驅動測試。

　　黑箱測試是根據軟體的規格對軟體進行的測試，這類測試不考慮軟體內部的運作原理，因此軟體對使用者來說就像一個黑盒子。

　　軟體測試人員以使用者的角度，通過各種輸入和觀察軟體的各種輸出結果來發現軟體存在的缺陷，而不關心程式具體如何?的一種軟體測試方法。

　　黑箱測試常用工具有：AutoRunner、winrunner、loadrunner。

　　自動化測試

　　自動化測試，英文是Automated Testing。

　　使用自動化測試載入器來進行測試，這類測試一般不需要人幹預，通常在GUI、效能等測試和功能測試中用得較多。通過錄製測試指令碼，然後執行這個測試指令碼來實現測試過程的自動化。國內領先的自動化測試服務提供者是澤眾軟體。自動化測試載入器有AutoRunner和TAR等。

　　迴歸測試

　　迴歸測試，英文是Regression testing。

　　迴歸測試是指在發生修改之後重新測試先前的測試以保證修改的正確性。理論上，軟體產生新版本，都需要進行迴歸測試，驗證以前發現和修複的錯誤是否在新軟體版本上再次出現。

　　根據修複好了的缺陷再重新進行測試。迴歸測試的目的在於驗證以前出現過但已經修複好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。通常確定所需的再測試的範圍時是比較困難的，特別當臨近產品發布日期時。因為為了修正某缺陷時必需更改原始碼，因而就有可能影響這部分原始碼所控制的功能。所以在驗證修好的缺陷時不僅要服從缺陷原來出現時的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應當鼓勵對所有迴歸測試用例進行自動化測試。

　　驗收測試

　　驗收測試，英文是Acceptance testing。

　　驗收測試是指系統開發生命週期方法論的一個階段，這時相關的使用者或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統使用者決定是否接收系統。它是一項確定產品是否能夠滿足合約或使用者所規定需求的測試。

　　驗收測試一般有三種策略：正式驗收、非正式驗收或Alpha 測試、Beta 測試。

　　動態測試

　　動態測試，英文是Moment Testing。

　　動態測試是指通過運行軟體來檢驗軟體的動態行為和運行結果的正確性。

　　根據動態測試在軟體開發過程中所處的階段和作用，動態測試可分為如下幾個步驟：

　　1、單元測試

　　2、整合測試

　　3、系統測試

　　4、驗收測試

　　5、迴歸測試

　　探勘測試

　　探勘測試，英文是Exploratory Testing。

　　探勘測試是指通常用於沒有產品說明書的測試，這需要把軟體當作產品說明書來看待，分步驟逐項探索軟體特性，記錄軟體執行情況，詳細描述功能，綜合利用靜態和動態技術來進行測試。探勘測試人員只靠智能、洞察力和經驗來對bug的位置進行判斷,所以探勘測試又被稱為自由形式測試。

　　單元測試

　　單元測試，英文是Unit Testing。

　　單元測試是最微小規模的測試;以測試某個功能或代碼塊。典型地由程式員而非測試員來做，因為它需要知道內部程式設計和編碼的細節知識。這個工作不容易做好，除非應用系統有一個設計很好的體繫結構; 還可能需要開發測試磁碟機模組或測試套具。

　　整合測試

　　整合測試，英文是Integration Testing。

　　整合測試是指一個應用系統的各個組件的聯合測試，以決定他們能否在一起共同工作並沒有衝突。組件可以是代碼塊、獨立的應用、網路上的用戶端或伺服器端程式。這種類型的測試尤其與客戶服務器和分布式系統有關。一般整合測試以前，單元測試需要完成。

　　整合測試是單元測試的邏輯擴充。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的介面。從這一層意義上講，組件是指多個單元的整合彙總。在現實方案中，許多單元組合成組件，而這些組件又彙總成程式的更大部分。方法是測試片段的組合，並最終擴充進程，將您的模組與其他組的模組一起測試。最後，將構成進程的所有模組一起測試。此外，如果程式由多個進程組成，應該成對測試它們，而不是同時測試所有進程。

　　整合測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元，並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的介面有關。這種方法將可能發生的情況數量減少到更簡單的分析層級

　　系統測試

　　系統測試，英文是System Testing。

　　系統測試是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的組件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。

　　系統測試的對像不僅僅包括需要測試的產品系統的軟體，還要包含軟體所依賴的硬體、外設甚至包括某些資料、某些支援軟體及其介面等。因此，必須將系統中的軟體與各種依賴的資源結合起來，在系統實際運行環境下來進行測試。

　　端到端測試

　　端到端測試，英文是End to End Testing。

　　端到端測試類別似於系統測試，測試級的“宏大”的端點，涉及整個應用系統內容在一個現實世界使用時的類比情形的所有測試。例如與資料庫對話，用網路通訊，或與外部硬體、應用系統或適當的系統對話。端到端架構測試包含所有訪問點的功能測試及效能測試。端到端架構測試實質上是一種"灰盒"測試，一種集合了白盒測試和黑箱測試的優點的測試方法。

　　健全測試

　　健全測試，英文是Sanity testing。

　　健全測試是指一個初始化的測試工作，以決定一個新的軟體版本測試是否足以執行下一步大的測試能力。例如，如果一個新版軟體每5分鐘與系統衝突，使系統陷於泥潭，說明該軟體不夠“健全”，目前不具備進一步測試的條件。

　　衰竭測試

　　衰竭測試，英文是Failure Testing。

　　衰竭測試是指軟體或環境的修複或更正後的“再測試”。可能很難確定需要多少遍再次測試。尤其在接近開發週期結束時。自動化的測試工具對這類測試尤其有用。

　　接受測試

　　接受測試，英文是Accept Testing。

　　接受測試是基於客戶或終端使用者的規格書的最終測試，或基於使用者一段時間的使用後，看軟體是否滿足客戶要求。一般從功能、使用者介面、效能、業務關聯性進行測試。

　　負載測試

　　負載測試，英文是Load testing。

　　負載測試是測試一個應用在重負荷下的表現。例如測試一個 Web 網站在大量的負荷下，何時系統的響應會退化或失敗，以發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對像承擔不同的工作量，以評測和評估測試對像在不同工作量條件下的效能行為，以及持續正常啟動並執行能力。

　　負載測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估效能特徵，例如，回應時間、交易處理速率和其他與時間相關的方面。

　　強迫測試

　　強迫測試，英文是Force Testing。

　　強迫測試是在交替進行負荷和效能測試時常用的術語。也用於描述像在異乎尋常的重載下的系統功能測試之類的測試，如某個動作或輸入大量的重複，大量資料的輸入，對一個資料庫系統大量的複雜查詢等。

　　壓力測試

　　壓力測試，英文是Stress Testing。和負載測試差不多。

　　壓力測試是一種基本的品質保證行為，它是每個重要軟體測試工作的一部分。壓力測試的基本思路很簡單：不是在常規條件下運行手動或自動化的測試，而是在電腦數量較少或系統資源匱乏的條件下運行測試。通常要進行壓力測試的資源套件括內部記憶體、CPU 可用性、磁碟空間和網路頻寬等。一般用並發來做壓力測試。

　　效能測試

　　效能測試，英文是Performance Testing。

　　效能測試是在交替進行負荷和強迫測試時常用的術語。理想的“效能測試”(和其他類型的測試)應在需求文檔或品質保證、測試計劃中定義。效能測試一般包括負載測試和壓力測試。

　　通常驗證軟體的效能在正常環境和系統條件下重複使用是否還能滿足效能指標。或者執行同樣任務時新版本不比舊版本慢。一般還檢查系統記憶容量在運行程式時會不會流失(memory leak)。比如，驗證程式儲存一個巨大的檔案新版本不比舊版本慢。

　　可用性測試

　　可用性測試，英文是Practical Usability Testing。

　　可用性測試是對“方便使用性”的測試。顯然這是主觀的，且將取決於目標終端使用者或客戶。使用者面談、調查、使用者對話的錄影和其他一些技術都可使用。程式員和測試員通常都不宜作可用性測試員。

　　卸載測試

　　卸載測試，英文是Uninstall Testing。

　　卸載測試是對軟體的全部、部分或升級卸載處理過程的測試。主要是測試軟體能否卸載，卸載是否乾淨，對系統有無更改，在系統中的殘留與後來的組建檔案如何處理等。還有原來更改的系統值是否修改回去

　　恢複測試

　　恢複測試，英文是Recovery testing。

　　恢複測試是測試一個系統從如下災難中能否很好地恢複，如遇到系統崩潰、硬體損壞或其他災難性問題。恢複測試指通過人為的讓軟體（或者硬體）出現故障來檢測系統是否能正確的恢複，通常關注恢複所需的時間以及恢複的程度。

　　恢複測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啟動系統。恢複測試首先要採用各種辦法強迫系統失敗，然後驗證系統是否能儘快恢複。對於自動回復需驗證重新初始化（reinitialization）、檢查點(checkpointing mechanisms)、資料恢複(data recovery)和重新啟動 (restart)等機制的正確性；對於人工幹預的恢複系統，還需估測平均修複時間，確定其是否在可接受的範圍內。

　　安全性測試

　　安全性測試，英文是Security Testing。

　　安全性測試是測試系統在防止非授權的內部或外部使用者的訪問或故意破壞等情況時怎麼樣。這可能需要複雜的測試技術。安全性測試檢查系統對非法侵入的防範能力。安全性測試期間，測試人員假扮非法入侵者，採用各種辦法試圖突破防線。例如：

　　①想方設法截取或破譯口令；

　　②專門定做軟體破壞系統的保護機制；

　　③故意導致系統失敗，企圖趁恢複之機非法進入；

　　④試圖通過瀏覽非保密資料，推導所需資訊，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的準則是，使非法侵入的代價超過被保護資訊的價值。此時非法侵入者已無利可圖。

　　相容性測試

　　相容測試，英文是Compatibility Testing。

　　相容測試是測試軟體在一個特定的硬體/軟體/作業系統/網路等環境下的效能如何。向上相容向下相容，軟體相容硬體相容。軟體的相容性有很多需要考慮的地方。

　　比較測試

　　比較測試，英文是Compare Testing。

　　比較測試是指與競爭夥伴的產品的比較測試，如軟體的弱點、優點或實力。來取長補短，以強化產品的競爭力。

　　可接受性測試

　　可接受性測試，英文是Acceptability Testing。

　　可接受性測試是在把測試的版本交付測試部門大範圍測試以前進行的對最準系統的簡單測試。因為在把測試的版本交付測試部門大範圍測試以前應該先驗證該版本對於所測試的功能基本上比較穩定。必須滿足一些最低要求。比如不會很容易程式就掛起或崩潰。如果一個新版本沒通過可測試性的驗證，就應該阻攔測試部門花時間在該測試版本上測試。同時還要找到造成該版本不穩定的主要缺陷並督促儘快加以修正

　　邊界條件測試

　　邊界條件測試，英文是Boudary Testing。又稱邊界值測試。

　　一種黑箱測試方法，是對等價類別分析方法的一種補充,由長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出的邊界上。因此針對各種邊界情況設計測試案例，可以查出更多的錯誤。

　　邊界條件測試是環繞邊界值的測試。通常意味著測試軟體各功能是否能正確處理最大值，最小值或者所設計軟體能夠處理的最長的字串等等。

　　強力測試

　　強力測試，英文是Mightiness Testing。

　　強力測試通常驗證軟體的效能在各種極端的環境和系統條件下是否還能正常工作。或者說是驗證軟體的效能在各種極端環境和系統條件下的承受能力。比如，在最低的硬碟空間或系統記憶容量條件下，驗證程式重複執行開啟和儲存一個巨大的檔案1000次後也不會崩潰或死機。

　　裝配/安裝/配置測試

　　裝配/安裝/配置測試是驗證軟體程式在不同廠家的硬體上，所支援的不同語言的新舊版本平台上，和不同方式安裝的軟體都能夠如預期的那樣正確運行。比如，把英文版的 Microsoft Office 2003安裝在韓文版 的Windows Me 上，再驗證所有功能都正常運行。

　　靜態測試

　　靜態測試，英文是Static Testing。

　　靜態測試指測試不啟動並執行部分，例如測試產品說明書，對此進行檢查和審閱.。靜態方法是指不運行被測程式本身，僅通過分析或檢查來源程式的文法、結構、過程、介面等來檢查程式的正確性。靜態方法通過程式靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的迴圈嵌套和分支嵌套、不允許的遞迴、未使用過的變數、null 指標的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，並為測試案例選取提供指導。

　　靜態測試常用工具有：Logiscope、PRQA；

　　隱藏資料測試

　　隱藏資料測試在軟體驗收和確認階段是十分必要和重要的一部分。程式的品質不僅僅通過使用者介面的可視化資料來驗證，而且必須包括遍曆系統的所有資料。

　　假設一個應用程式要求使用者兩條資訊-----使用者名稱和密碼來建立帳戶。這個使用者輸入這兩條資料後儲存。最後，一個確認視窗將通過資料庫中找到這條資料來顯示使用者名稱和密碼給使用者。為了驗證所有的資料儲存是否正確，一個QA測試人員會在這個確認視窗簡單的查看下使用者名稱和密碼。如果他們成功了？假設資料庫記錄了第三條資訊----建立日期，它可能不會出現在確認視窗，而只在存檔中才出現。如果建立日期保留的不正確，而QA測試人員只驗證螢幕上的資料，那麼這個問題就不可能被發現。建立日期可能就是一個bug，由於一個使用者帳戶儲存了一個錯誤的日期到資料庫中，這個問題也不可能會被引起注意，因為它被使用者介面所隱藏。這隻是一個簡單的例子，但是它卻演化出了一點：隱藏資料測試的重要性。

　　等價劃分測試

　　等價劃分測試的英文是equivalence partition testing。

　　等價劃分測試是根據等價類別設計測試案例的一種技術。是黑箱測試的典型方法之一，通過把被測試程式所有可能的輸入資料域劃分成若干部分。從每一部分中選取少數有代表性的資料作為測試案例，可有效減少測試次數，極大提高軟體測試效率，縮短軟體開發週期．等價類別劃分測試的目的就是為了在有限的測試資源的情況下，用少量有代表性的資料得到比較好的測試效果。有效等價類別盒無效等價類別。有效等價類別中的資料代表的是一組符合需求文檔的正確的有意義資料。無效等價類別則正相反。

　　判定表

　　判定表的英文是decision table，是指一個表格，用於顯示條件和條件導致動作的集合。

　　定義：判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。

　　判定表的優點：能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試案例集合。

　　在一些資料處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合於處理這類問題

　　深度測試

　　深度測試的英文Depth test ，是指執行一個產品的一個特性的所有細節，但不測試所有特性。

　　當比較函數返回真的時候才顯示出效果來。必須啟用“#深度測試”，才能執行測試。不使用的時候需要關閉。

　　基於設計的測試

　　基於設計的測試的英文是design-based testing，是根據軟體的構架或詳細設計引出測試案例的一種方法。

　　一種基於設計模型的測試方法(Model Based Testing System, MATIS).該方法利用使用者介面自動產生方法，把設計模型中的類屬性定義和實現中的控制項屬性群組織在一起，構建描述介面的邏輯對照表,輔助測試指令碼引擎執行自動化的測試指令碼.藉助設計模型中擴充的類定義，MATIS方法可以自動產生測試案例和測試資料。

　　文檔測試

　　文檔測試的英文是documentation testing，測試關注於文檔的正確性。

　　文檔測試有三大類分別是開發檔案、使用者檔案、管理檔案。

　　1. 開發檔案：可行性研究報告、軟體需求說明書、資料要求說明書、概要設計說明書、詳細設計說明書、資料庫設計說明書、模組開發卷宗。

　　2.使用者檔案：使用者手冊、操作手冊。

　　3.管理檔案：項目開發計劃、測試計劃、測試分析報告、開發進度月報、項目開發總結報告。

　　軟體測試中的文檔測試主要是對相關的設計報告和使用者使用說明進行測試，對於設計報告主要是測試程式與設計報告中的設計思想是否一致；對於使用者使用說明進行測試時，主要是測試使用者使用說明書中對程式操作方法的描述是否正確，重點是使用者使用說明中提到的操作例子要進行測試，保證採用的例子能夠在程式中正確完成操作。

　　一般來識,文檔是軟體的重要組成部分,因此文檔測試也是軟體測試的主要內容。在軟體的整個生命週期中會出現很多文檔，通常可以把文檔粗略地分為三類:開發文檔,管理文檔和使用者文檔。

　　由於文檔與代碼不同,不能直接運行,對於文檔的測試通常只能以文檔審查的方式進行。對於管理文檔和審查通常歸屬於管理範疇，而不是軟體測試範疇,因為對於管理文檔審查的目的不是為了發現和消除使用者所看到的軟體中的缺陷,而是為了更好地管理軟體開發的過程。對於開發文檔，由於這些文檔本身體現了所在開發階段的軟體實際形態,對於這些文檔的測試實際上是早期軟體測試的主要活動。使用者文檔是那些隨程式一起交付給使用者的文檔，它們實際上是交付給使用者的軟體的重要組成部分。對於這些文檔的測試是對最終軟體產品測試的一部分。

　　域測試

　　域測試的英文是domain testing，定義參考等價劃分測試（equivalence partition testing）；

　　一般分為單域測試和多域測試，其中單域測試包括裝置測試和業務測試，裝置測試包括測試某個系統的軟交換裝置、中繼媒體網關裝置、信令網關裝置、接入媒體網關和IAD等裝置。

　　等價類別劃分有兩種不同的情況：有效等價類別和無效等價類別。設計時要同時考慮這兩種等價類別，因為軟體不僅要能接收合理的資料，也要能經受意外的考驗。

　　一有效等價類別：是指對於程式的規格說明來說是合理的、有意義的輸入資料構成的集合。利用有效等價類別可檢驗程式是否實現了規格說明中所規定的功能和效能。

　　二無效等價類別：與有效等價類別的定義恰巧相反。

　　介面測試

　　介面測試的英文是interface testing，介面測試測試系統組件間介面的一種測試。

　　介面測試的好處：

　　由於介面測試代碼本身就是用junit（當然介面的類型不同，不一定是Junit來實現）來實現的，是屬於自動化測試的範疇，因此必定也包含自動化測試所固有的優勢。

　　1） 提高測試品質

　　軟體開發的過程是一個持續整合和改進的過程，而每一次的改進都可能引進新bug,因此當軟體的一部，或者全部修改時，都需要對軟體產品重新進行測試。其目的是要驗證修改後的產品是符合需求的，而當沒有自動化測試代碼時，往往會由於各種各樣的原因，迴歸不充分，導致bug遺漏。

　　2） 提高測試效率

　　軟體系統的規模越來越大，功能點越來越多，開發人員的自測或者測試人員的人工測試非常耗時和繁瑣，勢必導致測試效率的低下，而自動化測試正好解決這些耗時繁瑣的任務，在對外介面功能不變的情況下，達到了一次編寫，永久使用的效果。

　　3） 提高測試覆蓋

　　通過手工測試很難測試到一些更深層次的異常和安全的問題，通過一些輔助的一些測試載入器，能分析出代碼的覆蓋率，通過覆蓋率的提高來提高測試的深度。

　　4） 更好地重現軟體缺陷

　　由於每次執行都是相同的代碼，一旦代碼出錯，必定迴歸出錯

　　5） 更好定位錯誤

　　由於介面測試是一種自下向上的測試，因此一旦出錯，非常容易定位出錯，不向系統測試那樣了，一旦有Bug，需要幾層驗證之後才能確定出錯位置

　　6） 降低修改bug的成本介面測試基本和開發人員的編碼平行工作，因此發現問題會比系統測試早很多，因此減少了修改bug的成本。

　　7） 增進測試人員和開發人員之間的合作關係，測試工程師為了更好地開展工作，需要對開發技術有深入的理解和實踐，有了與開發工程師更多的交流。

　　8） 降低了項目不能按時發布的風險由於介面測試很早就介入，在提交給系統測試前對項目代碼的核心模組已經做了詳盡的測試，必定加速系統測試的時間，由此來保證項目的按時發布。

　　9）提升測試人員的技能。做介面測試必須瞭解開發人員的開發流程和一些開發技能，也需要瞭解測試載入器的一些使用方法和一些測試思想，提升了測試人員的技術附加值，提高了自身的競爭力。

　　10）促使項目開發過程的正常化

　　要進行介面測試，需要完善的文檔進行保障，沒有測試文檔，介面測試將寸步難行，介面測試將增加開發過程正常化產出，而正常化產出也保證了項目品質。

　　逆向測試，反向測試，負面測試

　　逆向測試/反向測試/負面測試的英文是Negative Testing，測試瞄準於使系統不能工作。

　　負面測試與正面測試的比較：

　　負面測試（Negative testing）是相對於正面測試（Positive testing）而言的。它們也是測試設計時的兩個非常重要的劃分。簡單點說，正面測試就是測試系統是否完成了它應該完成的工作；而負面測試就是測試系統是否不執行它不應該完成的操作。形像一點，正面測試就像一個畢恭畢敬的小學生，老師叫我做什麼，我就做什麼；而負面測試就像一個調皮搗蛋的孩子，你叫我這樣做，我偏不這樣做，而且和你對著幹。開發人員也是最討厭修改此類bug的。

　　非功能性需求測試

　　非功能性需求測試的英文是non-functional requirements testing ，是與功能不相關的需求測試，如：效能測試、可用性測試等。

　　為什麼非功能性需求很重要？

　　在您設計解決方案的過程中滿足功能性需求當然是很重要的。但是，如果沒有考慮非功能性需求，您的解決方案則很難取得實效。

　　非功能性需求特點：1.不要脫離實際環境；2.可靠性；3.可用性；4.有效性；5.可維護性；6.可移植性。

　　極限測試

　　極限測試本質上是為了滿足極限測試的思想和流程而設計的一套測試策略和流程,其本身並不局限於使用特定的測試技術和方法。

　　過程

　　1.單元測試  2.驗收測試