驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。

      驗收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進一步驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。

      通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步——驗收測試即可開始。驗收測試應(yīng)檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。

       1.驗收測試標準   實現(xiàn)軟件確認要通過一系列墨盒測試。驗收測試同樣需要制訂測試計劃和過程，測試計劃應(yīng)規(guī)定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無是計劃還是過程，都應(yīng)該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復(fù)能力和可維護性等）是否令用戶滿意。驗收測試的結(jié)果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn)嚴重錯誤和偏差一般很難在預(yù)定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。

       2.配置復(fù)審   驗收測試的另一個重要環(huán)節(jié)是配置復(fù)審。復(fù)審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節(jié)。

      3.α、β測試  事實上，軟件開發(fā)人員不可能完全預(yù)見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設(shè)計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗收測試長達數(shù)周甚至數(shù)月，不斷暴露錯誤，導(dǎo)致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。 α測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為α版本）進行測試，試圖發(fā)現(xiàn)錯誤并修正。α測試的關(guān)鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過α測試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨其后的β測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對β版本進行改錯和完善。一般包括功能度、安全可靠性、易用性、可擴充性、兼容性、效率、資源占用率、用戶文檔八個方面。

一、施驗收測試的常用策略

      施驗收測試的常用策略有三種，它們分別是：

· 正式驗收
· 非正式驗收或 Alpha 測試
· Beta 測試
      您選擇的策略通常建立在合同需求、組織和公司標準以及應(yīng)用領(lǐng)域的基礎(chǔ)上。

      正式驗收測試

      正式驗收測試是一項管理嚴格的過程，它通常是系統(tǒng)測試的延續(xù)。計劃和設(shè)計這些測試的周密和詳細程度不亞于系統(tǒng)測試。選擇的測試用例應(yīng)該是系統(tǒng)測試中所執(zhí)行測試用例的子集。不要偏離所選擇的測試用例方向，這一點很重要。在很多組織中，正式驗收測試是完全自動執(zhí)行的。

      對于系統(tǒng)測試，活動和工件是一樣的。在某些組織中，開發(fā)組織（或其獨立的測試小組）與最終用戶組織的代表一起執(zhí)行驗收測試。在其他組織中，驗收測試則完全由最終用戶組織執(zhí)行，或者由最終用戶組織選擇人員組成一個客觀公正的小組來執(zhí)行。

      這種測試形式的優(yōu)點是：

· 要測試的功能和特性都是已知的。
· 測試的細節(jié)是已知的并且可以對其進行評測。
· 這種測試可以自動執(zhí)行，支持回歸測試。
· 可以對測試過程進行評測和監(jiān)測。
· 可接受性標準是已知的。

      缺點包括：

· 要求大量的資源和計劃。
· 這些測試可能是系統(tǒng)測試的再次實施。
· 可能無法發(fā)現(xiàn)軟件中由于主觀原因造成的缺陷，這是因為您只查找預(yù)期要發(fā)現(xiàn)的缺陷。

      非正式驗收測試

      在非正式驗收測試中，執(zhí)行測試過程的限定不象正式驗收測試中那樣嚴格。在此測試中，確定并記錄要研究的功能和業(yè)務(wù)任務(wù)，但沒有可以遵循的特定測試用例。測試內(nèi)容由各測試員決定。這種驗收測試方法不象正式驗收測試那樣組織有序，而且更為主觀。

      大多數(shù)情況下，非正式驗收測試是由最終用戶組織執(zhí)行的。

      這種測試形式的優(yōu)點是：

· 要測試的功能和特性都是已知的。
· 可以對測試過程進行評測和監(jiān)測。
· 可接受性標準是已知的。
· 與正式驗收測試相比，可以發(fā)現(xiàn)更多由于主觀原因造成的缺陷。

      缺點包括：

· 要求資源、計劃和管理資源。
· 無法控制所使用的測試用例。
· 最終用戶可能沿用系統(tǒng)工作的方式，并可能無法發(fā)現(xiàn)缺陷。
· 最終用戶可能專注于比較新系統(tǒng)與遺留系統(tǒng)，而不是專注于查找缺陷。
· 用于驗收測試的資源不受項目的控制，并且可能受到壓縮。

      Beta 測試

      在以上三種驗收測試策略中，Beta 測試需要的控制是最少的。在 Beta 測試中，采用的細節(jié)多少、數(shù)據(jù)和方法完全由各測試員決定。各測試員負責(zé)創(chuàng)建自己的環(huán)境、選擇數(shù)據(jù)，并決定要研究的功能、特性或任務(wù)。各測試員負責(zé)確定自己對于系統(tǒng)當(dāng)前狀態(tài)的接受標準。

      Beta 測試由最終用戶實施，通常開發(fā)（或其他非最終用戶）組織對其的管理很少或不進行管理。Beta 測試是所有驗收測試策略中最主觀的。

      這種測試形式的優(yōu)點是：

· 測試由最終用戶實施。
· 大量的潛在測試資源。
· 提高客戶對參與人員的滿意程度。
· 與正式或非正式驗收測試相比，可以發(fā)現(xiàn)更多由于主觀原因造成的缺陷。

      缺點包括：

· 未對所有功能和/或特性進行測試。
· 測試流程難以評測。
· 最終用戶可能沿用系統(tǒng)工作的方式，并可能沒有發(fā)現(xiàn)或沒有報告缺陷。
· 最終用戶可能專注于比較新系統(tǒng)與遺留系統(tǒng)，而不是專注于查找缺陷。
· 用于驗收測試的資源不受項目的控制，并且可能受到壓縮。
· 可接受性標準是未知的。
· 您需要更多輔助性資源來管理 Beta 測試員。

二、驗收測試過程

1. 軟件需求分析：了解軟件功能和性能要求、軟硬件環(huán)境要求等，并特別要了解軟件的質(zhì)量要求和驗收要求。
2. 編制《驗收測試計劃》和《項目驗收準則》：根據(jù)軟件需求和驗收要求編制測試計劃，制定需測試的測試項，制定測試策略及驗收通過準則，并經(jīng)過客戶參與的計劃評審。
3. 測試設(shè)計和測試用例設(shè)計：根據(jù)《驗收測試計劃》和《項目驗收準則》編制測試用例，并經(jīng)過評審。
4. 測試環(huán)境搭建：建立測試的硬件環(huán)境、軟件環(huán)境等。（可在委托客戶提供的環(huán)境中進行測試）
5. 測試實施：測試并記錄測試結(jié)果。
6. 測試結(jié)果分析：根據(jù)驗收通過準則分析測試結(jié)果，作出驗收是否通過及測試評價。
7. 測試報告：根據(jù)測試結(jié)果編制缺陷報告和驗收測試報告，并提交給客戶。

三、驗收測試的總體思路

　　用戶驗收測試是軟件開發(fā)結(jié)束后，用戶對軟件產(chǎn)品投入實際應(yīng)用以前進行的最后一次質(zhì)量檢驗活動。它要回答開發(fā)的軟件產(chǎn)品是否符合預(yù)期的各項要求，以及用戶能否接受的問題。由于它不只是檢驗軟件某個方面的質(zhì)量，而是要進行全面的質(zhì)量檢驗，并且要決定軟件是否合格，因此驗收測試是一項嚴格的正式測試活動。需要根據(jù)事先制訂的計劃，進行軟件配置評審、功能測試、性能測試等多方面檢測。

　　用戶驗收測試可以分為兩個大的部分：軟件配置審核和可執(zhí)行程序測試，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執(zhí)行程序測試。

　　要注意的是，在開發(fā)方將軟件提交用戶方進行驗收測試之前，必須保證開發(fā)方本身已經(jīng)對軟件的各方面進行了足夠的正式測試（當(dāng)然，這里的“足夠”，本身是很難準確定量的）。

　　用戶在按照合同接收并清點開發(fā)方的提交物時（包括以前已經(jīng)提交的），要查看開發(fā)方提供的各種審核報告和測試報告內(nèi)容是否齊全，再加上平時對開發(fā)方工作情況的了解，基本可以初步判斷開發(fā)方是否已經(jīng)進行了足夠的正式測試。

　　用戶驗收測試的每一個相對獨立的部分，都應(yīng)該有目標（本步驟的目的）、啟動標準（著手本步驟必須滿足的條件）、活動（構(gòu)成本步驟的具體活動）、完成標準（完成本步驟要滿足的條件）和度量（應(yīng)該收集的產(chǎn)品與過程數(shù)據(jù)）。在實際驗收測試過程中，收集度量數(shù)據(jù)，不是一件容易的事情。

　　軟件配置審核

　　對于一個外包的軟件項目而言，軟件承包方通常要提供如下相關(guān)的軟件配置內(nèi)容：

　　●可執(zhí)行程序、源程序、配置腳本、測試程序或腳本。

　　●主要的開發(fā)類文檔：《需求分析說明書》、《概要設(shè)計說明書》、《詳細設(shè)計說明書》、《數(shù)據(jù)庫設(shè)計說明書》、《測試計劃》、《測試報告》、《程序維護手冊》、《程序員開發(fā)手冊》、《用戶操作手冊》、《項目總結(jié)報告》。

　　●主要的管理類文檔：《項目計劃書》、《質(zhì)量控制計劃》、《配置管理計劃》、《用戶培訓(xùn)計劃》、《質(zhì)量總結(jié)報告》、《評審報告》、《會議記錄》、《開發(fā)進度月報》。

　　在開發(fā)類文檔中，容易被忽視的文檔有《程序維護手冊》和《程序員開發(fā)手冊》。

　　《程序維護手冊》的主要內(nèi)容包括：系統(tǒng)說明（包括程序說明）、操作環(huán)境、維護過程、源代碼清單等，編寫目的是為將來的維護、修改和再次開發(fā)工作提供有用的技術(shù)信息。

　　《程序員開發(fā)手冊》的主要內(nèi)容包括：系統(tǒng)目標、開發(fā)環(huán)境使用說明、測試環(huán)境使用說明、編碼規(guī)范及相應(yīng)的流程等，實際上就是程序員的培訓(xùn)手冊。

　　不同大小的項目，都必須具備上述的文檔內(nèi)容，只是可以根據(jù)實際情況進行重新組織。

　　對上述的提交物，最好在合同中規(guī)定階段提交的時機，以免發(fā)生糾紛。

　　通常，正式的審核過程分為5個步驟：計劃、預(yù)備會議（可選）、準備階段、審核會議和問題追蹤。預(yù)備會議是對審核內(nèi)容進行介紹并討論。準備階段就是各責(zé)任人事先審核并記錄發(fā)現(xiàn)的問題。審核會議是最終確定工作產(chǎn)品中包含的錯誤和缺陷。

　　審核要達到的基本目標是：根據(jù)共同制定的審核表，盡可能地發(fā)現(xiàn)被審核內(nèi)容中存在的問題，并最終得到解決。在根據(jù)相應(yīng)的審核表進行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。

　　在實際的驗收測試執(zhí)行過程中，常常會發(fā)現(xiàn)文檔審核是最難的工作，一方面由于市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續(xù)時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。

　　可執(zhí)行程序的測試

　　在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成，就可以進行驗收測試的最后一個步驟——可執(zhí)行程序的測試，它包括功能、性能等方面的測試，每種測試也都包括目標、啟動標準、活動、完成標準和度量等五部分。

　　要注意的是不能直接使用開發(fā)方提供的可執(zhí)行程序用于測試，而要按照開發(fā)方提供的編譯步驟，從源代碼重新生成可執(zhí)行程序。

　　在真正進行用戶驗收測試之前一般應(yīng)該已經(jīng)完成了以下工作（也可以根據(jù)實際情況有選擇地采用或增加）：

　　●軟件開發(fā)已經(jīng)完成，并全部解決了已知的軟件缺陷。

　　●驗收測試計劃已經(jīng)過評審并批準，并且置于文檔控制之下。

　　●對軟件需求說明書的審查已經(jīng)完成。

　　●對概要設(shè)計、詳細設(shè)計的審查已經(jīng)完成。

　　●對所有關(guān)鍵模塊的代碼審查已經(jīng)完成。

　　●對單元、集成、系統(tǒng)測試計劃和報告的審查已經(jīng)完成。

　　●所有的測試腳本已完成，并至少執(zhí)行過一次，且通過評審。

　　●使用配置管理工具且代碼置于配置控制之下。

　　●軟件問題處理流程已經(jīng)就緒。

　　●已經(jīng)制定、評審并批準驗收測試完成標準。

　　具體的測試內(nèi)容通?？梢园ǎ喊惭b（升級）、啟動與關(guān)機、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負載、容量變化）、壓力測試（臨界的負載、容量變化）、配置測試、平臺測試、安全性測試、恢復(fù)測試（在出現(xiàn)掉電、硬件故障或切換、網(wǎng)絡(luò)故障等情況時，系統(tǒng)是否能夠正常運行）、可靠性測試等。

　　性能測試和壓力測試一般情況下是在一起進行，通常還需要輔助工具的支持。在進行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于開發(fā)方已經(jīng)事先進行過性能測試和壓力測試，因此可以直接使用開發(fā)方的輔助工具。也可以通過購買或自己開發(fā)來獲得輔助工具。具體的測試方法可以參考相關(guān)的軟件工程書籍。

　　如果執(zhí)行了所有的測試案例、測試程序或腳本，用戶驗收測試中發(fā)現(xiàn)的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在用戶驗收測試中所發(fā)生的變化，用戶驗收測試就完成了。

四、測試報告形式

      《驗收測試報告》
      《缺陷報告》
      《驗收測試計劃》中規(guī)定的其他文檔

五、驗收測試工作流程圖

六、驗收測試工作流程說明和注意事項

驗收測試業(yè)務(wù)恰談

雙方就測試項目及合同進行洽談

簽訂測試合同

委托方提交測試樣品及相關(guān)資料

委托方需提交的文檔有：

¨基本文檔：（驗收測試必需的文檔）

用戶手冊

安裝手冊

操作手冊

維護手冊

軟件開發(fā)合同

需求規(guī)格說明書

軟件設(shè)計說明

軟件樣品（可刻錄在光盤）

¨特殊文檔：（根據(jù)測試內(nèi)容不同，委托方所需提交下列相應(yīng)的文檔）

軟件產(chǎn)品開發(fā)過程中的測試記錄

軟件產(chǎn)品源代碼。

編制測試計劃并通過評審

進行項目相關(guān)知識培訓(xùn)

測試設(shè)計

評測中心編制測試方案和設(shè)計測試用例集。

方案評審

評測中心測試組成員、委托方代表一起對測試方案進行評審。

實施測試

評測中心對測試方案進行整改，并實施測試。在測試過程中每日提交測試事件報告給委托方。

編制驗收測試報告并組織評審

評測中心編制驗收測試報告，并組織內(nèi)部評審。

提交驗收測試報告

評測中心提交驗收測試報告。