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