1 驗收階段監理工作的重點
   
    監理單位應按照項目合同查看承建單位提供的各種審核報告和測試報告內容是否齊全，再根據平時對承建單位工作情況的了解，可以初步判斷開發方是否已經進行了足夠的正式測試。
   
    驗收可以分為兩個大的部分：軟件配置審核和驗收測試，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執行程序測試。
   
    驗收階段的每一個相對獨立的部分，都應該有目標（本步驟的目的）、啟動標準（著手本步驟必須滿足的條件）、活動（構成本步驟的具體活動）、完成標準（完成本步驟要滿足的條件）和度量（應該收集的產品與過程數據）。
   
    2 驗收組織
   
    2.1 組織機構及人員組成
   
    業主單位與監理單位協調成立專門的驗收委員會，作為驗收的組織機構。委員會一般不少于5人（單數）組成，設主任1人，委員若干人；并成立驗收測試組和配置審核組，委員可分別參與這兩個組的工作。另外，測試員、配置審核員和記錄員若干人。
   
    驗收委員會由業主單位代表、監理單位代表、承建單位代表以及邀請的技術專家組成員組成。
   
    2.2 驗收委員會的任務及權限
   
    1）驗收委員會的任務
   
    驗收委員會主持整個軟件驗收工作，包括下列任務：
   
    （1）判定所驗收的軟件是否符合合同的要求；
    （2）審定驗收環境，軟件驗收環境應與業主單位的實際運行環境一致，驗收環境按合同或驗收方案規定，或由三方協商，驗收委員會審定；
    （3）審定驗收測試計劃，驗收委員會對軟件驗收測試組制訂的驗收測試計劃進行審定，以保證測試計劃能滿足驗收要求；
    （4）組織驗收測試和配置審核，進行驗收評審，并形成驗收報告；
   
    2）驗收委員會的權限
   
    （1）有權要求業主單位、監理單位及承建單位對開發過程中的有關問題進行說明；
    （2）決定軟件是否通過驗收。
   
    2.3 驗收地點和條件
   
    軟件驗收地點應符合合同或驗收方案規定。若在承建單位進行，承建單位應提供驗收計劃中要求的設備、資源和各種條件；若在業主單位進行，則業主單位必須提供相應的設備、資源和各種條件，并預先通知承建單位提供其應提供的設備和支持軟件。
   
    2.4 驗收記錄及報告
   
    驗收工作的全過程必須詳細記錄，記錄驗收過程中驗收委員會提出的所有問題與建議，業主單位、監理單位及承建單位的解答和驗收委員會對被驗收軟件的評價。

   
   
    3 驗收的基本原則
   
    3.1 基本原則
   
    （1）驗收測試和配置審核是驗收評審前必須完成的兩項主要檢查工作，由驗收委員會主持；  
    （2）測試組在認真審查需求規格說明、確認測試和系統測試的計劃與分析結論的基礎上制訂驗收測試計劃；
    （3）配置審核組在需求規格說明、確認測試、系統測試等過程中形成的產品的變更變更管理及審核工作的基礎上開展審計；
    （4）原有測試和審核結果凡可用的就利用，不必重作該項測試或審核。同時可根據業主單位的要求臨時增加一些測試和審核內容；
    （5）測試組在完成驗收測試的同時，完成功能配置審核，即驗證軟件功能和接口與合同的一致性；
    （6）配置審核組完成物理配置審核，檢查程序和文檔的一致性、文檔和文檔的一致性、交付的產品與合同要求的一致性及符合有關標準的情況。
   
    3.2 驗收測試和配置審核步驟
   
    （1）制訂驗收測試計劃、配置審核計劃，作好驗收測試、配置審核準備；
    （2）驗收委員會審定測試計劃、配置審核計劃和測試準備、配置審核準備情況；
    （3）進行驗收測試、配置審核，建立完整的測試、配置審核記錄；
    （4）編寫測試報告、配置審核報告；
    （5）驗收委員會評審。
   
    3.3 驗收測試和配置審核內容
   
    （1）檢查合同或驗收標準要求的所有功能；
    （2）檢查合同或驗收標準要求的所有質量特性；
    （3）檢查開發各個階段的文檔、評審結論是否齊全規范；
    （4）驗證功能和接口與需求規格說明的一致性；檢查程序和文檔的一致性、文檔和文檔的一致性、交付的產品與合同或驗收標準要求的一致性及符合有關標準的情況；
    （5）由雙方商定所進行的一些特殊測試和配置審核。
   
    4 配置審核
   
    4.1 審查
   
    承建單位應當在驗收前提供相應軟件配置內容，監理單位應對其進行審查，審查的內容主要包括以下幾個部分。
   
    （1）可執行程序、源程序、配置腳本、測試程序或腳本。
    （2）主要的開發類文檔：《需求說明書》、《概要設計說明書》、《詳細設計說明書》、《數據庫設計說明書》、《測試計劃》、《測試報告》、《程序維護手冊》、《程序員開發手冊》、《用戶操作手冊》、《項目總結報告》。
    （3）主要的管理類文檔：《項目計劃書》、《質量控制計劃》、《配置管理計劃》、《用戶培訓計劃》、《質量總結報告》、《評審報告》、《會議記錄》、《開發進度月報》。
   
    在開發類文檔中，容易被忽視的文檔有《程序維護手冊》和《程序員開發手冊》。
   
    《程序維護手冊》的主要內容包括：系統說明（包括程序說明）、操作環境、維護過程、源代碼清單等，編寫目的是為將來的維護、修改和再次開發工作提供有用的技術信息。
   
    《程序員開發手冊》的主要內容包括：系統目標、開發環境使用說明、測試環境使用說明、編碼規范及相應的流程等，實際上就是程序員的培訓手冊。
   
    不同大小的項目，都必須具備上述的文檔內容，只是可以根據實際情況進行重新組織。

   
   
    4.2 審核
   
    通常，正式的審核過程分為5個步驟：計劃、預備會議（可選）、準備階段、審核會議和問題追蹤。預備會議是對審核內容進行介紹并討論。準備階段就是各責任人事先審核并記錄發現的問題。審核會議是最終確定工作產品中包含的錯誤和缺陷。
   
    審核要達到的基本目標是：根據共同制定的審核表，盡可能地發現被審核內容中存在的問題，并最終得到解決。在根據相應的審核表進行文檔審核和源代碼審核時，還要注意文檔與源代碼的一致性。
   
    在實際的驗收測試執行過程中，常常會發現文檔審核是最難的工作，一方面由于市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。
   
    5 驗收測試
   
    在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成，就可以進行驗收測試的最后一個步驟--可執行程序的測試，它包括功能、性能等方面的測試，每種測試也都包括目標、啟動標準、活動、完成標準和度量等五部分。
   
    5.1 測試的前提條件
   
    在真正進行用戶驗收測試之前一般應該已經完成了以下工作（也可以根據實際情況有選擇地采用或增加）：
   
    （1）軟件開發已經完成，并全部解決了已知的軟件缺陷。
    （2）驗收測試計劃已經過評審并批準，并且置于文檔控制之下。
    （3）對軟件需求說明書的審查已經完成。
    （4）對概要設計、詳細設計的審查已經完成。
    （5）對所有關鍵模塊的代碼審查已經完成。
    （6）對單元、集成、系統測試計劃和報告的審查已經完成。
    （7）所有的測試腳本已完成，并至少執行過一次，且通過評審。
    （8）使用配置管理工具且代碼置于配置控制之下。
    （9）軟件問題處理流程已經就緒。
    （10）已經制定、評審并批準驗收測試完成標準。
   
    5.2 測試工作實施
   
    要注意的是不能直接使用承建單位提供的可執行程序用于測試，而要按照承建單位提供的編譯步驟，從源代碼重新生成可執行程序。
   
    具體的測試內容通常可以包括：安裝（升級）、啟動與關機、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負載、容量變化）、壓力測試（臨界的負載、容量變化）、配置測試、平臺測試、安全性測試、恢復測試（在出現掉電、硬件故障或切換、網絡故障等情況時，系統是否能夠正常運行）、可靠性測試等。
   
    性能測試和壓力測試一般情況下是在一起進行，通常還需要輔助工具的支持。在進行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于承建單位已經事先進行過性能測試和壓力測試，因此可以直接使用承建單位的輔助工具。也可以通過購買或自己開發來獲得輔助工具。具體的測試方法可以參考相關的軟件工程書籍。
   
    如果執行了所有的測試案例、測試程序或腳本，驗收測試中發現的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在驗收測試中所發生的變化，驗收測試就完成了。
   
    6 驗收評審
   
    6.1 評審會
   
    在完成驗收測試和配置審核的基礎上，召開評審會，進行綜合評價。
   
    6.2 驗收準則
   
    （1）軟件產品符合合同或驗收標準規定的全部功能和質量要求；
    （2）不同安全性關鍵等級的軟件均通過《軟件測試細則》文檔所要求的各項測試；
    （3）文檔齊全，符合合同或驗收標準要求及有關標準的規定；
    （4）文檔和文檔一致，程序和文檔相符；
    （5）對被驗收軟件的可執行代碼，在驗收測試中查出的錯誤總數，依錯誤嚴重性不超過業主單位事先約定的限定值；
    （6）配置審核時查出的交付文檔中的錯誤總數不超過業主單位事先約定的限定值。

   
   
    6.3 評審結論
   
    評審會在綜合評價驗收測試和配置審計結果的基礎上，根據驗收準則，給出驗收結論。
   
    驗收結論分為兩種：
   
    （1）通過。表示同意通過驗收的委員人數超過按事先約定人數（重要系統由全體驗收委員協商一致同意；一般系統需有三分之二以上的委員同意）。
    （2）不通過。表示同意通過驗收的委員人數達不到通過的要求。
   
    7 驗收報告
   
    在軟件驗收評審后，必須填寫軟件驗收報告（見圖3-22），詳盡地記錄驗收的各項內容、評價與驗收結論，驗收委員會全體成員應在驗收報告上簽字。根據驗收委員會表決情況，由驗收委員會主任在軟件驗收報告上簽署意見。
   
    8 驗收未通過的處理
   
    承建單位應根據驗收評審意見盡快修正有關問題，重新進行驗收或者轉入合同爭議處理程序。
   
    9 系統移交和系統保障監理
   
    1）系統移交和系統保障的重點
   
    系統移交的監理
    系統驗收通過便可進行系統移交，此階段的監理重點是確保文檔及軟件的完整、版本一致。
   
    系統保障的監理
    系統保障的監理工作重點是確保承建單位按照合同和業主要求及時高效地提供系統保障服務。
   
    2）系統移交和系統保障監理的措施
   
    （1）系統移交的監理措施
   
    審查承建單位的項目資料清單
    協助業主和承建單位交接項目資料
    確保軟件文檔和軟件的一致性
    開發軟件作好備份，保管在安全地方，文件材料歸檔
   
    （2）系統保障期的監理措施
   
    督導承建單位按合同規定及時進行系統保障，抽查系統保障的執行情況；
    對項目業主方提出的質量問題進行記錄；
    督促承建單位進行修復和維護；
    對承建單位進行修復的內容進行確認。

來源：巨靈鳥 歡迎分享本文