監(jiān)理單位應(yīng)按照項目合同查看承建單位提供的各種審核報告和測試報告內(nèi)容是否齊全，再根據(jù)平時對承建單位工作情況的了解，可以初步判斷開發(fā)方是否已經(jīng)進(jìn)行了足夠的正式測試。驗收可以分為兩個大的部分：軟件配置審核和驗收測試，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執(zhí)行程序測試。
1 驗收階段監(jiān)理工作的重點(diǎn)
監(jiān)理單位應(yīng)按照項目合同查看承建單位提供的各種審核報告和測試報告內(nèi)容是否齊全，再根據(jù)平時對承建單位工作情況的了解，可以初步判斷開發(fā)方是否已經(jīng)進(jìn)行了足夠的正式測試。
驗收可以分為兩個大的部分：軟件配置審核和驗收測試，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執(zhí)行程序測試。
驗收階段的每一個相對獨(dú)立的部分，都應(yīng)該有目標(biāo)（本步驟的目的）、啟動標(biāo)準(zhǔn)（著手本步驟必須滿足的條件）、活動（構(gòu)成本步驟的具體活動）、完成標(biāo)準(zhǔn)（完成本步驟要滿足的條件）和度量（應(yīng)該收集的產(chǎn)品與過程數(shù)據(jù)）。
2 驗收組織
2.1 組織機(jī)構(gòu)及人員組成
業(yè)主單位與監(jiān)理單位協(xié)調(diào)成立專門的驗收委員會，作為驗收的組織機(jī)構(gòu)。委員會一般不少于5人（單數(shù)）組成，設(shè)主任1人，委員若干人；并成立驗收測試組和配置審核組，委員可分別參與這兩個組的工作。另外，測試員、配置審核員和記錄員若干人。
驗收委員會由業(yè)主單位代表、監(jiān)理單位代表、承建單位代表以及邀請的技術(shù)專家組成員組成。
2.2 驗收委員會的任務(wù)及權(quán)限
1）驗收委員會的任務(wù)
驗收委員會主持整個軟件驗收工作，包括下列任務(wù)：
（1）判定所驗收的軟件是否符合"合同"的要求；
（2）審定驗收環(huán)境，軟件驗收環(huán)境應(yīng)與業(yè)主單位的實際運(yùn)行環(huán)境一致，驗收環(huán)境按"合同"或"驗收方案"規(guī)定，或由三方協(xié)商，驗收委員會審定；
（3）審定驗收測試計劃，驗收委員會對軟件驗收測試組制訂的驗收測試計劃進(jìn)行審定，以保證測試計劃能滿足驗收要求；
（4）組織驗收測試和配置審核，進(jìn)行驗收評審，并形成驗收報告；
2）驗收委員會的權(quán)限
（1）有權(quán)要求業(yè)主單位、監(jiān)理單位及承建單位對開發(fā)過程中的有關(guān)問題進(jìn)行說明；
（2）決定軟件是否通過驗收。
2.3 驗收地點(diǎn)和條件
軟件驗收地點(diǎn)應(yīng)符合合同或驗收方案規(guī)定。若在承建單位進(jìn)行，承建單位應(yīng)提供驗收計劃中要求的設(shè)備、資源和各種條件；若在業(yè)主單位進(jìn)行，則業(yè)主單位必須提供相應(yīng)的設(shè)備、資源和各種條件，并預(yù)先通知承建單位提供其應(yīng)提供的設(shè)備和支持軟件。
2.4 驗收記錄及報告
驗收工作的全過程必須詳細(xì)記錄，記錄驗收過程中驗收委員會提出的所有問題與建議，業(yè)主單位、監(jiān)理單位及承建單位的解答和驗收委員會對被驗收軟件的評價。
3 驗收的基本原則
3.1 基本原則
（1）驗收測試和配置審核是驗收評審前必須完成的兩項主要檢查工作，由驗收委員會主持；
（2）測試組在認(rèn)真審查需求規(guī)格說明、確認(rèn)測試和系統(tǒng)測試的計劃與分析結(jié)論的基礎(chǔ)上制訂驗收測試計劃；
（3）配置審核組在需求規(guī)格說明、確認(rèn)測試、系統(tǒng)測試等過程中形成的產(chǎn)品的變更變更管理及審核工作的基礎(chǔ)上開展審計；
（4）原有測試和審核結(jié)果凡可用的就利用，不必重作該項測試或?qū)徍?。同時可根據(jù)業(yè)主單位的要求臨時增加一些測試和審核內(nèi)容；
（5）測試組在完成驗收測試的同時，完成功能配置審核，即驗證軟件功能和接口與"合同"的一致性；
（6）配置審核組完成物理配置審核，檢查程序和文檔的一致性、文檔和文檔的一致性、交付的產(chǎn)品與"合同"要求的一致性及符合有關(guān)標(biāo)準(zhǔn)的情況。
3.2 驗收測試和配置審核步驟
（1）制訂驗收測試計劃、配置審核計劃，作好驗收測試、配置審核準(zhǔn)備；
（2）驗收委員會審定測試計劃、配置審核計劃和測試準(zhǔn)備、配置審核準(zhǔn)備情況；
（3）進(jìn)行驗收測試、配置審核，建立完整的測試、配置審核記錄；
（4）編寫測試報告、配置審核報告；
（5）驗收委員會評審。
3.3 驗收測試和配置審核內(nèi)容
（1）檢查"合同"或"驗收標(biāo)準(zhǔn)"要求的所有功能；
（2）檢查"合同"或"驗收標(biāo)準(zhǔn)"要求的所有質(zhì)量特性；
（3）檢查開發(fā)各個階段的文檔、評審結(jié)論是否齊全規(guī)范；
（4）驗證功能和接口與需求規(guī)格說明的一致性；檢查程序和文檔的一致性、文檔和文檔的一致性、交付的產(chǎn)品與"合同"或"驗收標(biāo)準(zhǔn)"要求的一致性及符合有關(guān)標(biāo)準(zhǔn)的情況；
（5）由雙方商定所進(jìn)行的一些特殊測試和配置審核。
4 配置審核
4.1 審查
承建單位應(yīng)當(dāng)在驗收前提供相應(yīng)軟件配置內(nèi)容，監(jiān)理單位應(yīng)對其進(jìn)行審查，審查的內(nèi)容主要包括以下幾個部分。
（1）可執(zhí)行程序、源程序、配置腳本、測試程序或腳本。
（2）主要的開發(fā)類文檔：《需求說明書》、《概要設(shè)計說明書》、《詳細(xì)設(shè)計說明書》、《數(shù)據(jù)庫設(shè)計說明書》、《測試計劃》、《測試報告》、《程序維護(hù)手冊》、《程序員開發(fā)手冊》、《用戶操作手冊》、《項目總結(jié)報告》。
（3）主要的管理類文檔：《項目計劃書》、《質(zhì)量控制計劃》、《配置管理計劃》、《用戶培訓(xùn)計劃》、《質(zhì)量總結(jié)報告》、《評審報告》、《會議記錄》、《開發(fā)進(jìn)度月報》。
在開發(fā)類文檔中，容易被忽視的文檔有《程序維護(hù)手冊》和《程序員開發(fā)手冊》。
《程序維護(hù)手冊》的主要內(nèi)容包括：系統(tǒng)說明（包括程序說明）、操作環(huán)境、維護(hù)過程、源代碼清單等，編寫目的是為將來的維護(hù)、修改和再次開發(fā)工作提供有用的技術(shù)信息。
《程序員開發(fā)手冊》的主要內(nèi)容包括：系統(tǒng)目標(biāo)、開發(fā)環(huán)境使用說明、測試環(huán)境使用說明、編碼規(guī)范及相應(yīng)的流程等，實際上就是程序員的培訓(xùn)手冊。
不同大小的項目，都必須具備上述的文檔內(nèi)容，只是可以根據(jù)實際情況進(jìn)行重新組織。
4.2 審核
通常，正式的審核過程分為5個步驟：計劃、預(yù)備會議（可選）、準(zhǔn)備階段、審核會議和問題追蹤。預(yù)備會議是對審核內(nèi)容進(jìn)行介紹并討論。準(zhǔn)備階段就是各責(zé)任人事先審核并記錄發(fā)現(xiàn)的問題。審核會議是終確定工作產(chǎn)品中包含的錯誤和缺陷。
審核要達(dá)到的基本目標(biāo)是：根據(jù)共同制定的審核表，盡可能地發(fā)現(xiàn)被審核內(nèi)容中存在的問題，并終得到解決。在根據(jù)相應(yīng)的審核表進(jìn)行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。
在實際的驗收測試執(zhí)行過程中，常常會發(fā)現(xiàn)文檔審核是難的工作，一方面由于市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續(xù)時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。
5 驗收測試
在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成，就可以進(jìn)行驗收測試的后一個步驟--可執(zhí)行程序的測試，它包括功能、性能等方面的測試，每種測試也都包括目標(biāo)、啟動標(biāo)準(zhǔn)、活動、完成標(biāo)準(zhǔn)和度量等五部分。
5.1 測試的前提條件
在真正進(jìn)行用戶驗收測試之前一般應(yīng)該已經(jīng)完成了以下工作（也可以根據(jù)實際情況有選擇地采用或增加）：
（1）軟件開發(fā)已經(jīng)完成，并全部解決了已知的軟件缺陷。
（2）驗收測試計劃已經(jīng)過評審并批準(zhǔn)，并且置于文檔控制之下。
（3）對軟件需求說明書的審查已經(jīng)完成。
（4）對概要設(shè)計、詳細(xì)設(shè)計的審查已經(jīng)完成。
（5）對所有關(guān)鍵模塊的代碼審查已經(jīng)完成。
（6）對單元、集成、系統(tǒng)測試計劃和報告的審查已經(jīng)完成。
（7）所有的測試腳本已完成，并至少執(zhí)行過，且通過評審。
（8）使用配置管理工具且代碼置于配置控制之下。
（9）軟件問題處理流程已經(jīng)就緒。
（10）已經(jīng)制定、評審并批準(zhǔn)驗收測試完成標(biāo)準(zhǔn)。
5.2 測試工作實施
要注意的是不能直接使用承建單位提供的可執(zhí)行程序用于測試，而要按照承建單位提供的編譯步驟，從源代碼重新生成可執(zhí)行程序。
具體的測試內(nèi)容通?？梢园ǎ喊惭b（升級）、啟動與關(guān)機(jī)、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負(fù)載、容量變化）、壓力測試（臨界的負(fù)載、容量變化）、配置測試、平臺測試、安全性測試、恢復(fù)測試（在出現(xiàn)掉電、硬件故障或切換、網(wǎng)絡(luò)故障等情況時，系統(tǒng)是否能夠正常運(yùn)行）、可靠性測試等。
性能測試和壓力測試一般情況下是在一起進(jìn)行，通常還需要輔助工具的支持。在進(jìn)行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于承建單位已經(jīng)事先進(jìn)行過性能測試和壓力測試，因此可以直接使用承建單位的輔助工具。也可以通過購買或自己開發(fā)來獲得輔助工具。具體的測試方法可以參考相關(guān)的軟件工程書籍。
如果執(zhí)行了所有的測試案例、測試程序或腳本，驗收測試中發(fā)現(xiàn)的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在驗收測試中所發(fā)生的變化，驗收測試就完成了。
6 驗收評審
6.1 評審會
在完成驗收測試和配置審核的基礎(chǔ)上，召開評審會，進(jìn)行綜合評價。
6.2 驗收準(zhǔn)則
（1）軟件產(chǎn)品符合"合同"或"驗收標(biāo)準(zhǔn)"規(guī)定的全部功能和質(zhì)量要求；
（2）不同安全性關(guān)鍵等級的軟件均通過《軟件測試細(xì)則》文檔所要求的各項測試；
（3）文檔齊全，符合"合同"或"驗收標(biāo)準(zhǔn)"要求及有關(guān)標(biāo)準(zhǔn)的規(guī)定；
（4）文檔和文檔一致，程序和文檔相符；
（5）對被驗收軟件的可執(zhí)行代碼，在驗收測試中查出的錯誤總數(shù)，依錯誤嚴(yán)重性不超過業(yè)主單位事先約定的限定值；
（6）配置審核時查出的交付文檔中的錯誤總數(shù)不超過業(yè)主單位事先約定的限定值。
1 驗收階段監(jiān)理工作的重點(diǎn)
監(jiān)理單位應(yīng)按照項目合同查看承建單位提供的各種審核報告和測試報告內(nèi)容是否齊全，再根據(jù)平時對承建單位工作情況的了解，可以初步判斷開發(fā)方是否已經(jīng)進(jìn)行了足夠的正式測試。
驗收可以分為兩個大的部分：軟件配置審核和驗收測試，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執(zhí)行程序測試。
驗收階段的每一個相對獨(dú)立的部分，都應(yīng)該有目標(biāo)（本步驟的目的）、啟動標(biāo)準(zhǔn)（著手本步驟必須滿足的條件）、活動（構(gòu)成本步驟的具體活動）、完成標(biāo)準(zhǔn)（完成本步驟要滿足的條件）和度量（應(yīng)該收集的產(chǎn)品與過程數(shù)據(jù)）。
2 驗收組織
2.1 組織機(jī)構(gòu)及人員組成
業(yè)主單位與監(jiān)理單位協(xié)調(diào)成立專門的驗收委員會，作為驗收的組織機(jī)構(gòu)。委員會一般不少于5人（單數(shù)）組成，設(shè)主任1人，委員若干人；并成立驗收測試組和配置審核組，委員可分別參與這兩個組的工作。另外，測試員、配置審核員和記錄員若干人。
驗收委員會由業(yè)主單位代表、監(jiān)理單位代表、承建單位代表以及邀請的技術(shù)專家組成員組成。
2.2 驗收委員會的任務(wù)及權(quán)限
1）驗收委員會的任務(wù)
驗收委員會主持整個軟件驗收工作，包括下列任務(wù)：
（1）判定所驗收的軟件是否符合"合同"的要求；
（2）審定驗收環(huán)境，軟件驗收環(huán)境應(yīng)與業(yè)主單位的實際運(yùn)行環(huán)境一致，驗收環(huán)境按"合同"或"驗收方案"規(guī)定，或由三方協(xié)商，驗收委員會審定；
（3）審定驗收測試計劃，驗收委員會對軟件驗收測試組制訂的驗收測試計劃進(jìn)行審定，以保證測試計劃能滿足驗收要求；
（4）組織驗收測試和配置審核，進(jìn)行驗收評審，并形成驗收報告；
2）驗收委員會的權(quán)限
（1）有權(quán)要求業(yè)主單位、監(jiān)理單位及承建單位對開發(fā)過程中的有關(guān)問題進(jìn)行說明；
（2）決定軟件是否通過驗收。
2.3 驗收地點(diǎn)和條件
軟件驗收地點(diǎn)應(yīng)符合合同或驗收方案規(guī)定。若在承建單位進(jìn)行，承建單位應(yīng)提供驗收計劃中要求的設(shè)備、資源和各種條件；若在業(yè)主單位進(jìn)行，則業(yè)主單位必須提供相應(yīng)的設(shè)備、資源和各種條件，并預(yù)先通知承建單位提供其應(yīng)提供的設(shè)備和支持軟件。
2.4 驗收記錄及報告
驗收工作的全過程必須詳細(xì)記錄，記錄驗收過程中驗收委員會提出的所有問題與建議，業(yè)主單位、監(jiān)理單位及承建單位的解答和驗收委員會對被驗收軟件的評價。
3 驗收的基本原則
3.1 基本原則
（1）驗收測試和配置審核是驗收評審前必須完成的兩項主要檢查工作，由驗收委員會主持；
（2）測試組在認(rèn)真審查需求規(guī)格說明、確認(rèn)測試和系統(tǒng)測試的計劃與分析結(jié)論的基礎(chǔ)上制訂驗收測試計劃；
（3）配置審核組在需求規(guī)格說明、確認(rèn)測試、系統(tǒng)測試等過程中形成的產(chǎn)品的變更變更管理及審核工作的基礎(chǔ)上開展審計；
（4）原有測試和審核結(jié)果凡可用的就利用，不必重作該項測試或?qū)徍?。同時可根據(jù)業(yè)主單位的要求臨時增加一些測試和審核內(nèi)容；
（5）測試組在完成驗收測試的同時，完成功能配置審核，即驗證軟件功能和接口與"合同"的一致性；
（6）配置審核組完成物理配置審核，檢查程序和文檔的一致性、文檔和文檔的一致性、交付的產(chǎn)品與"合同"要求的一致性及符合有關(guān)標(biāo)準(zhǔn)的情況。
3.2 驗收測試和配置審核步驟
（1）制訂驗收測試計劃、配置審核計劃，作好驗收測試、配置審核準(zhǔn)備；
（2）驗收委員會審定測試計劃、配置審核計劃和測試準(zhǔn)備、配置審核準(zhǔn)備情況；
（3）進(jìn)行驗收測試、配置審核，建立完整的測試、配置審核記錄；
（4）編寫測試報告、配置審核報告；
（5）驗收委員會評審。
3.3 驗收測試和配置審核內(nèi)容
（1）檢查"合同"或"驗收標(biāo)準(zhǔn)"要求的所有功能；
（2）檢查"合同"或"驗收標(biāo)準(zhǔn)"要求的所有質(zhì)量特性；
（3）檢查開發(fā)各個階段的文檔、評審結(jié)論是否齊全規(guī)范；
（4）驗證功能和接口與需求規(guī)格說明的一致性；檢查程序和文檔的一致性、文檔和文檔的一致性、交付的產(chǎn)品與"合同"或"驗收標(biāo)準(zhǔn)"要求的一致性及符合有關(guān)標(biāo)準(zhǔn)的情況；
（5）由雙方商定所進(jìn)行的一些特殊測試和配置審核。
4 配置審核
4.1 審查
承建單位應(yīng)當(dāng)在驗收前提供相應(yīng)軟件配置內(nèi)容，監(jiān)理單位應(yīng)對其進(jìn)行審查，審查的內(nèi)容主要包括以下幾個部分。
（1）可執(zhí)行程序、源程序、配置腳本、測試程序或腳本。
（2）主要的開發(fā)類文檔：《需求說明書》、《概要設(shè)計說明書》、《詳細(xì)設(shè)計說明書》、《數(shù)據(jù)庫設(shè)計說明書》、《測試計劃》、《測試報告》、《程序維護(hù)手冊》、《程序員開發(fā)手冊》、《用戶操作手冊》、《項目總結(jié)報告》。
（3）主要的管理類文檔：《項目計劃書》、《質(zhì)量控制計劃》、《配置管理計劃》、《用戶培訓(xùn)計劃》、《質(zhì)量總結(jié)報告》、《評審報告》、《會議記錄》、《開發(fā)進(jìn)度月報》。
在開發(fā)類文檔中，容易被忽視的文檔有《程序維護(hù)手冊》和《程序員開發(fā)手冊》。
《程序維護(hù)手冊》的主要內(nèi)容包括：系統(tǒng)說明（包括程序說明）、操作環(huán)境、維護(hù)過程、源代碼清單等，編寫目的是為將來的維護(hù)、修改和再次開發(fā)工作提供有用的技術(shù)信息。
《程序員開發(fā)手冊》的主要內(nèi)容包括：系統(tǒng)目標(biāo)、開發(fā)環(huán)境使用說明、測試環(huán)境使用說明、編碼規(guī)范及相應(yīng)的流程等，實際上就是程序員的培訓(xùn)手冊。
不同大小的項目，都必須具備上述的文檔內(nèi)容，只是可以根據(jù)實際情況進(jìn)行重新組織。
4.2 審核
通常，正式的審核過程分為5個步驟：計劃、預(yù)備會議（可選）、準(zhǔn)備階段、審核會議和問題追蹤。預(yù)備會議是對審核內(nèi)容進(jìn)行介紹并討論。準(zhǔn)備階段就是各責(zé)任人事先審核并記錄發(fā)現(xiàn)的問題。審核會議是終確定工作產(chǎn)品中包含的錯誤和缺陷。
審核要達(dá)到的基本目標(biāo)是：根據(jù)共同制定的審核表，盡可能地發(fā)現(xiàn)被審核內(nèi)容中存在的問題，并終得到解決。在根據(jù)相應(yīng)的審核表進(jìn)行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。
在實際的驗收測試執(zhí)行過程中，常常會發(fā)現(xiàn)文檔審核是難的工作，一方面由于市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續(xù)時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。
5 驗收測試
在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成，就可以進(jìn)行驗收測試的后一個步驟--可執(zhí)行程序的測試，它包括功能、性能等方面的測試，每種測試也都包括目標(biāo)、啟動標(biāo)準(zhǔn)、活動、完成標(biāo)準(zhǔn)和度量等五部分。
5.1 測試的前提條件
在真正進(jìn)行用戶驗收測試之前一般應(yīng)該已經(jīng)完成了以下工作（也可以根據(jù)實際情況有選擇地采用或增加）：
（1）軟件開發(fā)已經(jīng)完成，并全部解決了已知的軟件缺陷。
（2）驗收測試計劃已經(jīng)過評審并批準(zhǔn)，并且置于文檔控制之下。
（3）對軟件需求說明書的審查已經(jīng)完成。
（4）對概要設(shè)計、詳細(xì)設(shè)計的審查已經(jīng)完成。
（5）對所有關(guān)鍵模塊的代碼審查已經(jīng)完成。
（6）對單元、集成、系統(tǒng)測試計劃和報告的審查已經(jīng)完成。
（7）所有的測試腳本已完成，并至少執(zhí)行過，且通過評審。
（8）使用配置管理工具且代碼置于配置控制之下。
（9）軟件問題處理流程已經(jīng)就緒。
（10）已經(jīng)制定、評審并批準(zhǔn)驗收測試完成標(biāo)準(zhǔn)。
5.2 測試工作實施
要注意的是不能直接使用承建單位提供的可執(zhí)行程序用于測試，而要按照承建單位提供的編譯步驟，從源代碼重新生成可執(zhí)行程序。
具體的測試內(nèi)容通?？梢园ǎ喊惭b（升級）、啟動與關(guān)機(jī)、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負(fù)載、容量變化）、壓力測試（臨界的負(fù)載、容量變化）、配置測試、平臺測試、安全性測試、恢復(fù)測試（在出現(xiàn)掉電、硬件故障或切換、網(wǎng)絡(luò)故障等情況時，系統(tǒng)是否能夠正常運(yùn)行）、可靠性測試等。
性能測試和壓力測試一般情況下是在一起進(jìn)行，通常還需要輔助工具的支持。在進(jìn)行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于承建單位已經(jīng)事先進(jìn)行過性能測試和壓力測試，因此可以直接使用承建單位的輔助工具。也可以通過購買或自己開發(fā)來獲得輔助工具。具體的測試方法可以參考相關(guān)的軟件工程書籍。
如果執(zhí)行了所有的測試案例、測試程序或腳本，驗收測試中發(fā)現(xiàn)的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在驗收測試中所發(fā)生的變化，驗收測試就完成了。
6 驗收評審
6.1 評審會
在完成驗收測試和配置審核的基礎(chǔ)上，召開評審會，進(jìn)行綜合評價。
6.2 驗收準(zhǔn)則
（1）軟件產(chǎn)品符合"合同"或"驗收標(biāo)準(zhǔn)"規(guī)定的全部功能和質(zhì)量要求；
（2）不同安全性關(guān)鍵等級的軟件均通過《軟件測試細(xì)則》文檔所要求的各項測試；
（3）文檔齊全，符合"合同"或"驗收標(biāo)準(zhǔn)"要求及有關(guān)標(biāo)準(zhǔn)的規(guī)定；
（4）文檔和文檔一致，程序和文檔相符；
（5）對被驗收軟件的可執(zhí)行代碼，在驗收測試中查出的錯誤總數(shù)，依錯誤嚴(yán)重性不超過業(yè)主單位事先約定的限定值；
（6）配置審核時查出的交付文檔中的錯誤總數(shù)不超過業(yè)主單位事先約定的限定值。