驗收測試是部署軟件之前的最后一個測試操作。在軟件產品完成了單元測試、集成測試和系統測試之后，產品發布之前所進行的軟件測試活動。它是技術測試的最后一個階段，也稱為交付測試。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執行軟件的既定功能和任務。
驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試后，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接著就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
驗收測試，系統開發生命周期方法論的一個階段，這時相關的用戶和獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。這是管理性和防御性控制。
在工程及其他相關領域中，驗收測試是指確認一系統是否符合設計規格或契約之需求內容的測試，可能會包括化學測試、物理測試或是性能測試。在系統工程中驗收測試可能包括在系統（例如一套軟件系統、許多機械零件或是一批化學制品）交付前的黑箱測試。軟件開發者常會將系統開發者進行的驗收測試和客戶在接受產品前進行的驗收測試分開。后者一般會稱為使用者驗收測試、終端客戶測試、實機（驗收）測試、現場（驗收）測試。在進行主要測試程序之前，常用冒煙測試作為一個此階段的驗收測試。
常用策略
實施驗收測試的常用策略有三種，它們分別是：
· 正式驗收
· 非正式驗收或 Alpha 測試
· Beta 測試
您選擇的策略通常建立在合同需求、組織和公司標準以及應用領域的基礎上。
正式測試
正式驗收測試是一項管理嚴格的過程，它通常是系統測試的延續。計劃和設計這些測試的周密和詳細程度不亞于系統測試。選擇的測試用例應該是系統測試中所執行測試用例的子集。不要偏離所選擇的測試用例方向，這一點很重要。在很多組織中，正式驗收測試是完全自動執行的。
對于系統測試，活動和工件是一樣的。在某些組織中，開發組織（或其獨立的測試小組）與最終用戶組織的代表一起執行驗收測試。在其他組織中，驗收測試則完全由最終用戶組織執行，或者由最終用戶組織選擇人員組成一個客觀公正的小組來執行。
這種測試形式的優點是
· 要測試的功能和特性都是已知的。
· 測試的細節是已知的并且可以對其進行評測。
· 這種測試可以自動執行，支持回歸測試。
· 可以對測試過程進行評測和監測。
· 可接受性標準是已知的。
缺點包括
· 要求大量的資源和計劃。
· 這些測試可能是系統測試的再次實施。
· 可能無法發現軟件中由于主觀原因造成的缺陷，這是因為您只查找預期要發現的缺陷。
非正式測試
在非正式驗收測試中，執行測試過程的限定不象正式驗收測試中那樣嚴格。在此測試中，確定并記錄要研究的功能和業務任務，但沒有可以遵循的特定測試用例。測試內容由各測試員決定。這種驗收測試方法不象正式驗收測試那樣組織有序，而且更為主觀。
大多數情況下，非正式驗收測試是由最終用戶組織執行的。
這種測試形式的優點是
· 要測試的功能和特性都是已知的。
· 可以對測試過程進行評測和監測。
· 可接受性標準是已知的。
· 與正式驗收測試相比，可以發現更多由于主觀原因造成的缺陷。
缺點包括
· 要求資源、計劃和管理資源。
· 無法控制所使用的測試用例。
· 最終用戶可能沿用系統工作的方式，并可能無法發現缺陷。
Beta測試
在以上兩種驗收測試策略中，Beta 測試需要的控制是最少的。在 Beta 測試中，采用的細節多少、數據和方法完全由各測試員決定。各測試員負責創建自己的環境、選擇數據，并決定要研究的功能、特性或任務。各測試員負責確定自己對于系統當前狀態的接受標準。
Beta 測試由最終用戶實施，通常開發（或其他非最終用戶）組織對其的管理很少或不進行管理。Beta 測試是所有驗收測試策略中最主觀的。
β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程序員或測試員完成。
當開發和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其他人員員完成，不能由程序員或測試員完成。
該測試形式的優點
· 測試由最終用戶實施。
· 大量的潛在測試資源。
· 提高客戶對參與人員的滿意程度。
· 與正式或非正式驗收測試相比，可以發現更多由于主觀原因造成的缺陷。
缺點
· 未對所有功能和/或特性進行測試。
· 測試流程難以評測。
· 最終用戶可能沿用系統工作的方式，并可能沒有發現或沒有報告缺陷。
· 最終用戶可能專注于比較新系統與遺留系統，而不是專注于查找缺陷。
· 用于驗收測試的資源不受項目的控制，并且可能受到壓縮。
· 可接受性標準是未知的。
· 您需要更多輔助性資源來管理 Beta測試員。
總體思路
用戶驗收測試是軟件開發結束后，用戶對軟件產品投入實際應用以前進行的最后一次質量檢驗活動。它要回答開發的軟件產品是否符合預期的各項要求，以及用戶能否接受的問題。由于它不只是檢驗軟件某個方面的質量，而是要進行全面的質量檢驗，并且要決定軟件是否合格，因此驗收測試是一項嚴格的正式測試活動。需要根據事先制訂的計劃，進行軟件配置評審、功能測試、性能測試等多方面檢測。
用戶驗收測試可以分為兩個大的部分：軟件配置審核和可執行程序測試，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執行程序測試。
要注意的是，在開發方將軟件提交用戶方進行驗收測試之前，必須保證開發方本身已經對軟件的各方面進行了足夠的正式測試（當然，這里的“足夠”，本身是很難準確定量的）。
用戶在按照合同接收并清點開發方的提交物時（包括以前已經提交的），要查看開發方提供的各種審核報告和測試報告內容是否齊全，再加上平時對開發方工作情況的了解，基本可以初步判斷開發方是否已經進行了足夠的正式測試。
用戶驗收測試的每一個相對獨立的部分，都應該有目標（本步驟的目的）、啟動標準（著手本步驟必須滿足的條件）、活動（構成本步驟的具體活動）、完成標準（完成本步驟要滿足的條件）和度量（應該收集的產品與過程數據）。在實際驗收測試過程中，收集度量數據，不是一件容易的事情。
配置審核
對于一個外包的軟件項目而言，軟件承包方通常要提供如下相關的軟件配置內容：
●可執行程序、源程序、配置腳本、測試程序或腳本。
●主要的開發類文檔：《需求分析說明書》、《概要設計說明書》、《詳細設計說明書》、《數據庫設計說明書》、《測試計劃》、《測試報告》、《程序維護手冊》、《程序員開發手冊》、《用戶操作手冊》、《項目總結報告》。
●主要的管理類文檔：《項目計劃書》、《質量控制計劃》、《配置管理計劃》、《用戶培訓計劃》、《質量總結報告》、《評審報告》、《會議記錄》、《開發進度月報》。
在開發類文檔中，容易被忽視的文檔有《程序維護手冊》和《程序員開發手冊》。
《程序維護手冊》的主要內容包括：系統說明（包括程序說明）、操作環境、維護過程、源代碼清單等，編寫目的是為將來的維護、修改和再次開發工作提供有用的技術信息。
《程序員開發手冊》的主要內容包括：系統目標、開發環境使用說明、測試環境使用說明、編碼規范及相應的流程等，實際上就是程序員的培訓手冊。
不同大小的項目，都必須具備上述的文檔內容，只是可以根據實際情況進行重新組織。
對上述的提交物，最好在合同中規定階段提交的時機，以免發生糾紛。
通常，正式的審核過程分為5個步驟：計劃、預備會議（可選）、準備階段、審核會議和問題追蹤。預備會議是對審核內容進行介紹并討論。準備階段就是各責任人事先審核并記錄發現的問題。審核會議是最終確定工作產品中包含的錯誤和缺陷。
審核要達到的基本目標是：根據共同制定的審核表，盡可能地發現被審核內容中存在的問題，并最終得到解決。在根據相應的審核表進行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。
在實際的驗收測試執行過程中，常常會發現文檔審核是最難的工作，一方面由于市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。
程序測試
在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成，就可以進行驗收測試的最后一個步驟——可執行程序的測試，它包括功能、性能等方面的測試，每種測試也都包括目標、啟動標準、活動、完成標準和度量等五部分。
要注意的是不能直接使用開發方提供的可執行程序用于測試，而要按照開發方提供的編譯步驟，從源代碼重新生成可執行程序。
在真正進行用戶驗收測試之前一般應該已經完成了以下工作（也可以根據實際情況有選擇地采用或增加）：
●軟件開發已經完成，并全部解決了已知的軟件缺陷。
●驗收測試計劃已經過評審并批準，并且置于文檔控制之下。
●對軟件需求說明書的審查已經完成。
●對概要設計、詳細設計的審查已經完成。
●對所有關鍵模塊的代碼審查已經完成。
●對單元、集成、系統測試計劃和報告的審查已經完成。
●所有的測試腳本已完成，并至少執行過一次，且通過評審。
●使用配置管理工具且代碼置于配置控制之下。
●軟件問題處理流程已經就緒。
●已經制定、評審并批準驗收測試完成標準。
測試內容
通常可以包括：安裝（升級）、啟動與關機、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負載、容量變化）、壓力測試（臨界的負載、容量變化）、配置測試、平臺測試、安全性測試、恢復測試（在出現掉電、硬件故障或切換、網絡故障等情況時，系統是否能夠正常運行）、可靠性測試等。
性能測試和壓力測試一般情況下是在一起進行，通常還需要輔助工具的支持。在進行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于開發方已經事先進行過性能測試和壓力測試，因此可以直接使用開發方的輔助工具。也可以通過購買或自己開發來獲得輔助工具。具體的測試方法可以參考相關的軟件工程書籍。
如果執行了所有的測試案例、測試程序或腳本，用戶驗收測試中發現的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在用戶驗收測試中所發生的變化，用戶驗收測試就完成了。
過程
1. 軟件需求分析：了解軟件功能和性能要求、軟硬件環境要求等，并特別要了解軟件的質量要求和驗收要求。
2. 編制《驗收測試計劃》和《項目驗收準則》：根據軟件需求和驗收要求編制測試計劃，制定需測試的測試項，制定測試策略及驗收通過準則，并經過客戶參與的計劃評審。
3. 測試設計和測試用例設計：根據《驗收測試計劃》和《項目驗收準則》編制測試用例，并經過評審。
4. 測試環境搭建：建立測試的硬件環境、軟件環境等。（可在委托客戶提供的環境中進行測試）
5. 測試實施：測試并記錄測試結果。
6. 測試結果分析：根據驗收通過準則分析測試結果，作出驗收是否通過及測試評價。
7. 測試報告：根據測試結果編制缺陷報告和驗收測試報告，并提交給客戶。
有關標準
通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步——驗收測試即可開始。驗收測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。
標準
實現軟件確認要通過一系列黑盒測試。驗收測試同樣需要制訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無論是計劃還是過程，都應該著重考慮軟件是否滿足合同規定的所有功能和性能，文檔資料是否完整、準確人機交互和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。驗收測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與用戶協商，尋求一個妥善解決問題的方法。
配置復審
驗收測試的另一個重要環節是配置復審。復審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節。
αβ測試
事實上，軟件開發人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數據組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統的測試。有時，驗收測試長達數周甚至數月，不斷暴露錯誤，導致開發延期。一個軟件產品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，用來發現那些似乎只有最終用戶才能發現的問題。 α測試是指軟件開發公司組織內部人員模擬各類用戶行對即將面市軟件產品（稱為α版本）進行測試，試圖發現錯誤并修正。α測試的關鍵在于盡可能逼真地模擬實際運行環境和用戶對軟件產品的操作并盡最大努力涵蓋所有可能的 用戶操作方式。經過α測試調整的軟件產品稱為β版本。緊隨其后的β測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發公司再對β版本進行改錯和完善。一般包括功能度、安全可靠性、易用性、可擴充性、兼容性、效率、資源占用率、用戶文檔八個方面。
注意事項
驗收測試業務恰談
雙方就測試項目及合同進行洽談
簽訂測試合同委托方提交測試樣品及相關資料
委托方需提交的文檔有：
¨基本文檔：（驗收測試必需的文檔）
用戶手冊
安裝手冊
維護手冊
軟件樣品（可刻錄在光盤）
¨特殊文檔：（根據測試內容不同，委托方所需提交下列相應的文檔）
軟件產品開發過程中的測試記錄
軟件產品源代碼。
編制測試計劃并通過評審進行項目相關知識培訓測試設計
國家信息中心軟件評測中心編制測試方案和設計測試用例集。
方案評審
評測中心測試組成員、委托方代表一起對測試方案進行評審。
實施測試
評測中心對測試方案進行整改，并實施測試。在測試過程中每日提交測試事件報告給委托方。
編制驗收測試報告并組織評審
評測中心編制驗收測試報告，并組織內部評審。
提交驗收測試報告。
評測中心提交驗收測試報告。
參考資料 >