1、項目驗收過程驗收作為項目執行過程中的一個重要的里程碑，對公司和客戶具有重要的 意義。一、驗收申請二、驗收準備2. 1開發商資料收集根據軟件項目的特點，在驗收時應收集以下文檔:編號名稱形式介質1項目開發計劃文檔電子、紙質2軟件需求說明書文檔電子、紙質3系統概要設計說明書文檔電子、紙質4總體設計說明書文檔電子、紙質5數據庫設計說明書文檔電子、紙質6詳細設計文檔文檔電子、紙質7為本項目開發的軟件源代碼文檔電子、紙質8FAT&SA用艮告文檔電子、紙質9試運行報告文檔電子、紙質10性能測試報告、功能測試報告文檔電子、紙質11項目實施報告文檔電子、紙質12培訓計劃文檔電子、紙質13服務計劃文檔電子

2、、紙質14維護手冊文檔電子、紙質15用戶手冊文檔電子、紙質16應用軟件清單文檔電子、紙質17系統參數配置說明文檔電子、紙質18所提供的第三方產品的技術說明和操作、維護資料文檔電子、紙質19系統崩潰及恢復步驟文檔文檔電子、紙質20技術服務和技術培訓等相關資料文檔電子、紙質21項目總結報告文檔電子、紙質除上述文檔外，還應單獨收集、保存各應用軟件源程序代碼及開發商所用 第三方資源信息。開發商所使用的第三方控件，除已經得到審計署的許可之外， 必須提供控件的源代碼，并擁有授權使用的證明或保證(由開發商提供無版權爭 議承諾書)；對于原始程序代碼，要求能夠在本地不經過任何特殊設置，即可編 譯并正常運行。源程

3、序清單中列舉的項目應該和源程序一一對應。2. 2最終用戶資料收集依據軟件開發需求說明書和概要設計說明書，編寫相關軟件的用戶滿意度 調查表，該調查表應該涵蓋軟件在需求說明書中列舉的所有模塊，包含軟件在不同操作系統下的運行情況等。最終用戶或甲方項目組按照實際情況填寫該調查三、驗收測試驗收測試是軟件開發結束后，用戶對軟件產品投入實際應用以前進行的最后一次質量檢驗活動，它要回答開發的軟件產品是否符合預期的各項要求，以及用戶能否接受的問題。由于它不只是檢驗軟件某個方面的質量， 而是要進行全面 的質量檢驗，并且要決定軟件是否合格，因此驗收測試是一項嚴格的正式測試活 動。需要根據事先制訂的計劃，進行軟件配置

4、評審、功能測試、性能測試等多方 面檢測。軟件驗收測試分為三部分：文檔代碼一致性審核、軟件配置審核和可執行 程序測試，其順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序、 平臺API測試、集成測試、驗收測試等。文檔代碼一致性審核、軟件配置審核是 軟件部署和實施全面驗收測試的基礎，由各應用軟件驗收責任人檢查它們的完整 性；由于工程開發的各軟件運行環境均基于審計管理系統、審計實施系統平臺， 最終的集成測試、驗收測試由德華工貿員工、驗收專家所有參與驗收工作的人員 一起完成。3.1文檔審核文檔審核的主要要求是確定軟件開發的所有過程都在提交文檔的控制下， 對文檔的具體要求如下：(1)文檔完備性：是

5、否按照合同及其附件要求提交了全部文檔；(2)內容針對性：指文檔是否是甲方要求的文檔；文檔的內容應該按照功 能模塊的重要性在論)上達到不同的詳細程度；(3)內容充分性：指該文檔全面、詳細的程度；(4)文檔的價值：文檔應該能夠反映軟件開發的整個過程，即需求中提到 的功能在概要設計中體現，在詳細設計中實現，在測試計劃中檢驗；(5)圖表翔實性：是否包含了足夠的圖形和表格；(6)符合甲方規范程度：是否很好地符合甲方要求的規范、標準；(7)內容一致性：是否存在前后矛盾；是否存在需求說明中提到的功能在 概要設計、詳細設計中沒有涉及的情況；(8)文字明確性：不使用“可能”、“也許”、“待定”等語義含糊不清 的

6、語句；(9)易讀性：能夠在一篇文檔中說明清楚的內容，盡量不要拆分成若干文 檔，不要循環引用，文檔目錄一目了然，結構清晰。3. 2源代碼審核源代碼審核的主要要求是確保開發商將全部源程序交付甲方，并確保交付 的代碼沒有版權問題(由開發商提供無版權爭議承諾書)對源代碼審核的具體要 求如下：3. 2. 1版權明晰(1)提交的代碼中注釋版權的地方均應去掉版權聲明，或聲明版權為審計 署所有。(2)得到甲方允許，可以使用的控件，由開發商提供無版權爭議承諾書。 使用其他的具有源代碼的控件，均需要當作提交代碼的一部分，直接置于編譯環 境的工程文件中，在編譯發布時無需額外設置。3. 2. 2代碼完整(1)開發商必

7、須把所有實現用戶需求的代碼交付甲方。(2)除非已經得到甲方的允許，使用的控件也必須有源代碼，并得到授權 使用證明；由開發商提供無版權爭議承諾書。(3)包含開發工具的程序文件；要求能夠在甲方計算機中正常編譯、 運行; 除非得到甲方允許，在甲方計算機中編譯的時候無需額外安裝開發工具的插件或 控件。3. 2. 3可讀性強注釋是軟件可讀性的具體體現。 程序注釋量不少于程序編碼量的 30%程序 注釋不能用抽象的語言(如“處理”、“循環”等)，要精確表達出程序的處理 說明。為避免每行程序都使用注釋，可以在一段程序的前面加一段注釋， 有明確 的處理邏輯。4. 3配置文件審核對于B/S程序，部署維護是軟件生存

8、周期中最長的一個過程，配置文件的 審核顯得尤為重要。對配置文件的審核要求與源代碼的審核要求完全一致。5. 4測試用例編寫及測試程序、腳本審核這個過程是在文檔審核和配置腳本審核后，為了檢驗通過源代碼編譯后的 程序是否滿足設計需求。檢驗方式主要是 API測試、集成測試、驗收測試；這一 階段應該完成設計及其有關測試所包括的特性，還需要完成測試所需的測試用例 和測試規程，并規定特性的通過準則。(1)測試用例說明：列出用于輸入的具體值以及預期的輸出結果，并規定 在使用具體測試用例時，對測試規程的各種限制。要求將測試用例與測試設計分 開，可以使它們用于多個設計并能在其它情形下重復使用。(2)測試規程說明：

9、規定對于運行系統和執行指定的測試用例來實現有關 測試設計所要求的所有步驟。測試方案(1)針對性測試方案：從滿意度調查表中篩選出可能不符合需求設計的功 能模塊，編寫針對具體模塊設計的測試方案。這種方案的實現耗時短，根據實際 使用情況調查軟件的具體實現，適合在軟件得到較大面積試用后采取的驗收測 試。(2)抽樣測試方案：在設計文檔中隨機選取，根據抽樣的樣本大小不同， 最后得到的結論可能會出現差異。 這種方案的實現耗時可長可短，適合軟件未得 到大面積適用前驗收時采用。3. 5平臺API測試常見的白盒測試是單元測試。單元測試是測試中最小單位的測試。簡而言 之，就是拿一個函數出來，加上驅動模塊，讓它能夠運

10、行起來，然后設計一些用 例測試其內部的控制點（如：條件判斷點、循環點、選擇分支點等）。驅動模塊 是模擬調用被測函數的函數。根據設計文檔選取關鍵函數和所有開放的 API,設計測試用例。4. 6集成測試/壓力測試常見的黑盒測試包括：集成測試，系統測試。集成測試是在單元測試的基 礎上，將所有模塊按照設計要求（如根據結構圖）組裝成為子系統或系統，進行 集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也 能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來， 影響功能的實現。通過一個應用系統的各個部件的聯合測試， 以決定他們能否在 一起共同工作，在協同工作時是否能夠達到功能要求。5. 7驗收測試目的是檢驗待驗收軟件是否對平臺和其它軟件保持良好的兼容性。四、驗收結論（成績評定標準）驗收結束時，根據以上文檔，填寫驗收結論，對軟件的質量做出評價1 .優秀