軟體驗收報告範文（精選5篇）
甲方： 有限公司
乙方： 有限公司
甲方收到乙方開發的)，下文簡稱“軟體”。截止於 年 月 日初步測試已經通過，暫時無發現重大軟體漏洞問題，軟體細節後期有待驗證。
乙方應在甲方實際使用軟體過程中，對軟體已有功能做售後服務。如後期有軟體漏洞問題，乙方應積極配合甲方做免費修復。
甲方驗收人員： 日期：
甲方驗收人員： 日期：
甲方：
乙方：
就“ ，經過甲乙雙方的通力配合和共同努力，完成了合同中約定的全部任務，現在整個系統運行正常，按照合同約定，進行項目驗收工作。
驗收工作分為設備清點、安裝調試、初驗、上線試運行和終驗幾個階段，驗收方式主要以清單、測試和實地操作為主。具體內容如下： 第一部分：設備清點
主要檢查運到甲方的設備是否與合同相符
甲乙雙方按照合同要求對運抵現場的設備進行了清點，此項工作已於 年 月 日完成，結論如下：
1.1 核對到貨清單，實物與運送單據是否一致。
□通過 □未通過 備註：
1.2 檢查和清點運抵現場的各種設備是否與合同相符。
□通過 □未通過 備註：
1.3 檢查運抵現場的文檔是否齊全
□通過 □未通過 備註：
第二部分：安裝調試
通過系統硬體測試證明各部分硬體物理破壞且已正確安裝。
按照合同要求，乙方對已經到貨的設備進行了安裝，甲乙雙方進行了加電測試，主要觀察設備加電後的表現和運行自檢程序的結果，此項工作已於 年 月 日完成，結論如下：
2.1 加電是否成功
□通過 □未通過 備註：
2.2 設備狀態是否正常
□通過 □未通過 備註：
2.3 系統顯示的版本和序列號等信息是否符合合同要求
□通過 □未通過 備註：
2.4 自檢有無報警
□通過 □未通過 備註：
第三部分：初驗、上線試運行
通過系統運行，證明系統可以正常工作
乙方進行設備安裝調試後，甲乙雙方在作業系統、資料庫等運行環境下進行系統測試，此項工作已於 年 月 日完成，結論如下：
3.1 系統啟動是否正常
□通過 □未通過 □未涉及 備註：
3.2 系統管理功能是否正常
□通過 □未通過 □未涉及 備註：
3.3 相關軟體License是否已經生效使用
□通過 □未通過 □未涉及 備註：
3.4系統運行是否正常
□通過 □未通過 □未涉及 備註：
第四部分 終驗
系統和設備在質保期內能正常運轉，出現故障，能及時解決。
乙方在質保期內對系統和設備進行了終驗驗收，此項工作已於 年 月 日完成，結論如下：
□通過 □未通過 □未涉及 備註：
完成上述工作以後，甲乙雙方認為整個項目驗收正式通過，整個系統交付完畢，設備運行正常，可以投入使用。
甲方： 乙方：
代表 代表
日期 日期
用戶名稱： huaxia
密級：huaxia123
文檔編號：
編 寫：
審 核：
批 准
項目名稱：
編寫日期：
審核日期：
批准日期：
項目名稱
【驗收報告應由客戶方起草，雙方有關人員簽字，此時驗收報告的格式主要由客戶方選定;當然，也可接受用戶方委託，由項目經理起草驗收報告，經用戶方簽字蓋章認可。】
第一章 項目概述
1.1 項目背景
目前，電視台除了自製節目以外，外購節目制度存在非常明顯的潛規則、暗箱操作、圈子交易等現象，一個公平、公正、公開、透明的節目採購方式呼之欲出。
各省級衛視也有自己的採購方式。如江蘇廣播電視總台電視節目採購工作按照民主集中制的原則開展，實行四級審片制，即採購人員初審、審片組審片、分管主任複審、主任審看。另外還有送頻道或者召開觀眾審片會議複審。對審片評價較好的劇目進行外地播出效果評估，最後形成劇目的總體評價，對有爭議的劇目報總台分管領導仲裁。所有外購節目採購在部門民主集中形成意見後報總台領導批准購買。廣州電視台除新聞節目外，所有頻道、節目將全面實行制播分離，所屬九個頻道向台內外製作機構開放，建立起多主體、多渠道採購節目，擇優播出機制。
面對激烈的市場競爭和不規範的市場原則，省級衛視為了搶占市場先機，降低採購成本，採取聯合採購的模式。如2+4模式：東方衛視和北京衛視購買了《馬文的戰爭》的首輪播出權後，二輪播權由山東、天津、吉林和深圳4家衛視採購。還有《我的團長我的團》、《潛伏》、《婚變》等電視劇被適用於4+4模式。另外，目前的電視劇爭奪戰中還出現了“劇本期貨”交易現象——在劇本出來之後，只要有足夠的賣點和看點，電視台就會採取前期介入，迅速獲得優勢資源。
另一方面，由於電視劇買賣的圈子很小，電視台和製作機構之間的買賣屬於圈子交易。每年60億元的購片經費中，大部分都集中在幾十個電視台採購負責人手中。很多情況下，電視台的節目採購很大程度上受到採購者的個人因素影響，如與節目製作機構的人際關係，個人的喜好或者審美習慣等等。這樣就無法保證把經費用在刀刃上，既浪費了資源，又沒有買到好的節目。
各家電視台都出台了各種採購形式，但電視台的節目採購形式都沒有在業界形成
項目名稱
公信度和絕對優勢，因為沒有一個切實有效的部門(崗位)來統籌規範電視節目的引進工作，這就非常有必要增設採購編輯來改變這一現狀。
1.2 參考資料
編寫本驗收報告時主要參考了如下的資料和文獻：
1.
2.
3.
4.
5.
6. 《華夏影視交易平台系統合同書(主合同)》 《華夏影視交易平台系統軟體開發合同書》 《華夏影視交易平台系統需求分析說明書》 《華夏影視交易平台系統總體設計說明書》 《華夏影視交易平台系統詳細設計說明書》 《應達到的技術指標和參數(驗收標準)》
第二章 驗收定義
2.1 驗收方式
組織彙報、功能代碼審查
2.2 驗收依據
《華夏影視交易平台系統合同書(主合同)》
《華夏影視交易平台系統軟體開發合同書》
《附件五 華夏影視交易平台系統工作說明書》
2.3 驗收環境
華夏影視交易平台X綜合業務系統實際運行的生產環境為驗收環境。
硬體平台
伺服器：AS/400-840系列;RS/6000-H85
客戶機：IBM_PC、實達、國光、長城系列終端及終端外圍設備。
軟體平台
項目名稱
伺服器：OS/400 Ver5.1 AIX 4.3.3作業系統，DB2 資料庫 Ver 7.2.0;
客戶機：SCO UNIX作業系統3.24及5.01, INFORMIX ONLINE 資料庫 Ver 7.3
2.4 驗收標準
2.4.1 系統功能標準
如果各模塊驗收測試結果如下表所述則視為驗收合格，否則將進行修改，以進行再次驗收評審。
2.4.2 性能標準
1.優秀
1)材料完整
2)軟體可正常運行
3)實現項目軟體需求說明書要求的各項功能需求
4)軟體介面友好，易於交互
5)軟體功能新穎，有較強創新
2.合格
1)本標準第3條要求的材料完整
2)可正常運行實現功能達到軟體需求說明書要求的三分之二以上 3.不合格
1)標準第3條要求的材料不完整 2)軟體不能運行
3) 軟體需求說明書要求的主要功能 。
2.5 驗收規則
驗收規則一：【避免在法度中應用魔鬼數字，必須用有意義的常量來標識。】
驗收規則二：【明白辦法的功能，一個辦法僅完成一個功能。】
驗收規則三：【辦法參數不克不及跨越5個】
驗收規則四：【辦法調用儘量不要返回null，取而代之以拋出異常，或是返回特例對象(SPECIAL CASE object，SPECIAL CASE PATTERN);對於以湊集或數組類型作為返回值的辦法，取而代之以空湊集或0長度數組。】
驗收規則五：【在進行資料庫操縱或IO操縱時，必須確保資料在應用完畢後獲得開釋，並且必須確保開釋操縱在finally中進行。】
驗收規則六：【異常捕獲不要直接catch (Exception ex) ，應當把異常細分處理懲罰。】
驗收規則七：【對於if „ else if „(後續可能有多個else if …)這種類型的前提斷定，最後必須包含一個else分支，避免呈現分支漏掉造成錯誤;每個switch-case語句都必須包管有default，避免呈現分支漏掉，造成錯誤。】
驗收規則八：【覆寫對象的equals辦法時必須同時覆寫hashCode辦法。】
驗收規則九：【禁止輪迴中創建新線程，儘量應用線程池。】
驗收規則十：【在進行正確策畫時(例如:貨幣策畫)避免應用float和double，浮點數策畫都是不正確的，必須應用BigDecimal或將浮點數運算轉換為整型運算。】
2.6 驗收人員
2.7 驗收時間
第三章 遺留問題
暫無。
第四章 交付物清單
4.1 文檔提交清單
4.2 源碼提交清單
第五章 驗收結論
第一版驗收通過
第六章 雙方簽字
客戶方(蓋章)： 代表：
公司(蓋章) 代表： 日期：
日期：
第三方((蓋章)[如果有]： 代表： 日期：
附件:
驗收測試記錄、測試報告等記錄。
目前，國內軟體的驗收沒有可參照的強制性標準，就軟體測試和評價來說，參照的標準是GB/T 17544 和GB/T 16260，它們都是推薦性標準，且都是定性而非定量的標準，這樣，對於軟體的驗收來說，存在很大的分歧和不確定性。為此，我們在參考了大量的實踐案例和文獻的基礎上，結合本校實際制定本驗收辦法，用於規範本校軟體系統驗收。
軟體系統的驗收可通過本校組織驗收或通過第三方驗收兩種辦法。 1、驗收原則
驗收參與部門：資產管理處、紀檢監察、用戶使用單位、專家小組或第三方驗收人員;開發單位。
在軟體開發合同的簽訂階段就提出軟體驗收項目和驗收通過標準的意見;在軟體的需求評審階段，仔細審閱軟體的需求規格說明書，指出不利於測試和可能存在歧義的描述;在開發方開發完軟體並經過開發方內部仔細的測試後，對完成的軟體進行評審或第三方的驗收測試，提供完整的錯誤報告提交給用戶方，由用戶方根據之前簽訂的開發合同中相應的驗收標準判斷是否進行驗收。
2、驗收項目和驗收標準 2.1 驗收項目 a) 功能項測試
對軟體需求規格說明書中的所有功能項進行測試; b) 業務流程測試
對軟體項目的典型業務流程進行測試; c) 容錯測試
容錯測試的檢查內容包括:
1) 軟體對用戶常見的誤操作是否能進行提示;
2) 軟體對用戶的的操作錯誤和軟體錯誤，是否有準確、清晰的提示; 3) 軟體對重要數據的刪除是否有警告和確認提示;
4) 軟體是否能判斷數據的有效性，屏蔽用戶的錯誤輸入，識別非法值，並有相應的錯誤提示。
d) 安全性測試安全性測試的檢查內容包括:
1) 軟體中的密鑰是否以密文方式存儲;
2) 軟體是否有留痕功能, 即是否保存有用戶的操作日誌; 3) 軟體中各種用戶的權限分配是否合理; e) 性能測試
對軟體需求規格說明書中明確的軟體性能進行測試。測試的準則是要滿足規格說明書中的各項性能指標。
f ) 易用性測試 易用性測試的內容包括:
1) 軟體的用戶介面是否友好，是否出現中英文混雜的介面; 2) 軟體中的提示信息是否清楚、易理解，是否存在原始的英文提示; 3) 軟體中各個模塊的介面風格是否一致;
4) 軟體中的查詢結果的輸出方式是否比較直觀、合理。 g) 適應性測試
參照用戶的軟、硬體使用環境和需求規格說明書中的規定，列出開發的軟體需要滿足的軟、硬體環境。對每個環境進行測試。
h) 文檔測試
用戶文檔包括: 安裝手冊、操作手冊和維護手冊。對用戶文檔測試的內容包括: 1) 操作、維護文檔是否齊全、是否包含產品使用所需的信息和所有的功能模塊; 2) 用戶文檔描述的信息是否正確, 是否沒有歧義和錯誤的表達;
3) 戶文檔是否容易理解, 是否通過使用適當的術語、圖形表示、詳細的解釋來表達;
4) 用戶文檔對主要功能和關鍵操作是否提供應用實例; 5) 用戶文檔是否有詳細的目錄表和索引表; i)
用戶有特別要求的測試
2.2 驗收標準
2.2.1 軟體錯誤的嚴重性等級
1：不能執行正常功能或重要功能, 或者危及人身安全; 2：嚴重地影響系統要求或基本功能的實現, 且沒有辦法解決; 3：嚴重地影響系統要求或基本功能的實現, 但存在合理的解決辦法; 4：使操作者不方便或遇到麻煩, 但不影響執行正常功能或重要功能; 5 ：其它錯誤;
2.2.2錯誤與嚴重性等級對應表 a) 1 級錯誤的描述
這一級別的錯誤一般包括以下內容: 沒有實現或錯誤地實現重要的功能;業務流程存在重大隱患;軟體在操作過程中由於軟體自身的原因自動退出系統或出現死機的情況;軟體在操作過程中由於軟體自身的原因對系統或數據造成破壞;在現有的軟、硬建設環境下不能實現應有的功能;特殊軟體在操作過程中可能危及系統和人身安全等。
b) 2 級錯誤的描述
這一級別的錯誤一般包括: 沒有實現基本功能，並且不存在替代辦法;沒有實現重要功能中的部分功能，並且不存在替代辦法;業務流程銜接錯誤;密鑰以明文方式存儲;沒有留痕功能;用戶的權限分配不合理;在現有的環境下，不能實現部分功能且沒有替代方案;沒有滿足系統的性能要求。
c) 3 級錯誤的描述
這一級的錯誤是與第2 級別的錯誤相對應的，而第3 級錯誤則存在替代方法;對誤操作或錯誤操作沒有提示，導致非法數據進入資料庫。
d) 4 級錯誤的描述
這一級別的錯誤通常為易用性方面的錯誤。比如介面不友好、前後風格不一;中英文混雜;查詢結果輸出不直觀等。
e) 5 級錯誤的描述
通常為文檔方面的錯誤，如安裝手冊、操作手冊、維護手冊中的描述錯誤。 其次，對發現的每一個錯誤都要確定相應的嚴重性等級，如表2 中的說明。
全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，用戶方認為軟體不可驗收，要求開發方在規定的時間內全面整改軟體, 提交給軟體評測中心再次進行完整的驗收測試。
2.2.2 驗收標準
1) 測試用例不通過數的比例< 1.5 %; 2) 不存在錯誤等級為1 的錯誤; 3) 不存在錯誤等級為2 的錯誤; 4) 錯誤等級為3 的錯誤數量≤ 5; 5) 所有提交的錯誤都已得到更正; 2.3 驗收標準的詳細說明
驗收項目的劃分參照GB/T 16260 標準。在該標準中，將軟體的質量特性分為6 大特性、21 個子特性，而對於具體的軟體，並非都要進行這21 個特性的測試和評價。本文選取的是最通用的子特性部分，針對各種不同的軟體，可以對驗收項目進行剪裁或擴充。
需要制定的驗收標準，即每一級別的錯誤量的可接受範圍。一般來說，不允許存在1 級和2級錯誤，而3 級錯誤的數量則可按本標準確定或由用戶方和開發方根據軟體的規模和複雜程度進行商定，並在軟體開發合同中明確地列出。
在軟體驗收測試中， 測試的依據包括軟體的投標文件、開發合同、需求規格說明書, 同時還包括特定軟體的相關行業標準(這些行業標準應在開發合同中明示出來)。
在進行第三方的驗收測試後，軟體評測中心將發現的所有錯誤進行總結和歸納， 並提交完整的錯誤報告，在錯誤報告中包括每一級別的錯誤數量和錯誤清單(所有的錯誤都需經過用戶方和開發方的確認)。
用戶方根據錯誤報告中每一級別的錯誤數量和錯誤清單與軟體開發合同中的驗收標準進行對照，如錯誤的級別和數量在合同中沒有約定，可按本辦法的規定進行。用戶方認為軟體可以驗收，但要求開發方對錯誤報告中的所有錯誤進行整改，並提交給軟體評測中心進行回歸測試，確認錯誤報告中的所有錯誤全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，用戶方認為軟體不可驗收，要求開發方在
規定的時間內全面整改軟體，提交給軟體評測中心再次進行完整的驗收測試。
3、驗收資料
(1)工程立項批准文件 (2)項目驗收申請報告; (3)工程招標書 (4)工程投標書 (5)工程施工中標通知書 (6)工程施工合同(含預算表) (7)軟體需求說明書; (8)概要設計說明書;
(9)數據及資料庫設計要求說明書; (10)詳細設計說明書; (11)操作手冊; (12)用戶手冊
(13)項目用戶評價過程意見; (14)軟體接口規範; (15)原代碼或安裝盤; (16)專家組要求的其他材料 4、其他
在有條件的情況下，還應該進行安裝測試、壓力測試和數據恢複測試。若進行子系統驗收或部分驗收，可參照以上方法和資料，雙方共同協商確定。
參考文獻：
GB/T 17544 ;GB/T 16260;《軟體驗收標準探討》
{項目名稱}
驗收報告
{日期}
目 錄
§1 項目基本情況.................................................... §2 項目進度審核.................................................... 2.1 項目實施進度情況 2.2 項目變更情況 2.3 項目投資結算情況
§3 項目驗收計劃.................................................... 3.1 項目驗收原則 3.2 項目驗收方式 3.3 項目驗收內容
§4 項目驗收情況匯總................................................ 4.1 項目驗收情況匯總表 4.2 項目驗收附件明細 4.3 專家組驗收意見
§5 項目驗收結論.................................................... 5.1 開發單位結論 5.2 建設單位結論
§6 附件............................................................ 6.1 附件一：軟體平台驗收單 6.2 附件二：功能模塊驗收單 6.3 附件三：項目文檔驗收單 6.4 附件四：硬體設備驗收單
§1 項目基本情況
§2 項目進度審核2.1 項目實施進度情況
2.2 項目變更情況2.2.1 項目合同變更情況
{記錄合同變更情況}
2.2.2 項目需求變更情況
{記錄需求變更情況}
2.3 項目投資結算情況
§3 項目驗收計劃3.1 項目驗收原則
1、審查提供驗收的各類文檔的正確性、完整性和統一性，審查文檔是否齊全、合理; 2、審查項目功能是否達到了合同規定的要求; 3、審查項目有關服務指標是否達到了合同的要求; 4、審查項目投資以及實施進度的情況;
5、對項目的技術水平做出評價，並得出項目的驗收結論。
3.2 項目驗收方式
{記錄項目驗收的組織方式和參與驗收工作的人員情況}
3.3 項目驗收內容
1、硬體設備驗收; 2、軟體平台驗收; 3、應用系統驗收; 4、項目文檔驗收;
5、項目服務響應(如售後服務、問題相應等方面)驗收。
§4 項目驗收情況匯總
4.1 項目驗收情況匯總表
4.2 項目驗收附件明細
1、軟體平台驗收單(見附件一)。 2、功能模塊驗收單(見附件二)。
3、項目文檔驗收單(見附件三)。 4、硬體設備驗收單(見附件四)。
4.3 專家組驗收意見
§5 項目驗收結論5.1 開發單位結論
5.2 建設單位結論
§6 附件6.1 附件一：軟體平台驗收單
驗收人： 驗收時間：
6.2 附件二：功能模塊驗收單
驗收人： 驗收時間：
6.3 附件三：項目文檔驗收單
驗收人： 驗收時間：
6.4
附件四：硬體設備驗收單
目前，國內軟體的驗收沒有可參照的強制性標準，就軟體測試和評價來說，參照的標準是GB/T 17544 和GB/T 16260，它們都是推薦性標準，且都是定性而非定量的標準，這樣，對於軟體的驗收來說，存在很大的分歧和不確定性。為此，我們在參考了大量的實踐案例和文獻的基礎上，結合本校實際制定本驗收辦法，用於規範本校軟體系統驗收。
軟體系統的驗收可通過本校組織驗收或通過第三方驗收兩種辦法。 1、驗收原則
驗收參與部門：資產管理處、紀檢監察、用戶使用單位、專家小組或第三方驗收人員;開發單位。
在軟體開發合同的簽訂階段就提出軟體驗收項目和驗收通過標準的意見;在軟體的需求評審階段，仔細審閱軟體的需求規格說明書，指出不利於測試和可能存在歧義的描述;在開發方開發完軟體並經過開發方內部仔細的測試後，對完成的軟體進行評審或第三方的驗收測試，提供完整的錯誤報告提交給用戶方，由用戶方根據之前簽訂的開發合同中相應的驗收標準判斷是否進行驗收。
2、驗收項目和驗收標準 2.1 驗收項目 a) 功能項測試
對軟體需求規格說明書中的所有功能項進行測試; b) 業務流程測試
對軟體項目的典型業務流程進行測試; c) 容錯測試
容錯測試的檢查內容包括:
1) 軟體對用戶常見的誤操作是否能進行提示;
2) 軟體對用戶的的操作錯誤和軟體錯誤，是否有準確、清晰的提示; 3) 軟體對重要數據的刪除是否有警告和確認提示;
4) 軟體是否能判斷數據的有效性，屏蔽用戶的錯誤輸入，識別非法值，並有相應的錯誤提示。
d) 安全性測試安全性測試的檢查內容包括:
1) 軟體中的密鑰是否以密文方式存儲;
2) 軟體是否有留痕功能, 即是否保存有用戶的操作日誌; 3) 軟體中各種用戶的權限分配是否合理; e) 性能測試
對軟體需求規格說明書中明確的軟體性能進行測試。測試的準則是要滿足規格說明書中的各項性能指標。
f ) 易用性測試 易用性測試的內容包括:
1) 軟體的用戶介面是否友好，是否出現中英文混雜的介面; 2) 軟體中的提示信息是否清楚、易理解，是否存在原始的英文提示; 3) 軟體中各個模塊的介面風格是否一致;
4) 軟體中的查詢結果的輸出方式是否比較直觀、合理。 g) 適應性測試
參照用戶的軟、硬體使用環境和需求規格說明書中的規定，列出開發的軟體需要滿足的軟、硬體環境。對每個環境進行測試。
h) 文檔測試
用戶文檔包括: 安裝手冊、操作手冊和維護手冊。對用戶文檔測試的內容包括: 1) 操作、維護文檔是否齊全、是否包含產品使用所需的信息和所有的功能模塊; 2) 用戶文檔描述的信息是否正確, 是否沒有歧義和錯誤的表達;
3) 戶文檔是否容易理解, 是否通過使用適當的術語、圖形表示、詳細的解釋來表達;
4) 用戶文檔對主要功能和關鍵操作是否提供應用實例; 5) 用戶文檔是否有詳細的目錄表和索引表; i)
用戶有特別要求的測試
2.2 驗收標準
2.2.1 軟體錯誤的嚴重性等級
1：不能執行正常功能或重要功能, 或者危及人身安全; 2：嚴重地影響系統要求或基本功能的實現, 且沒有辦法解決; 3：嚴重地影響系統要求或基本功能的實現, 但存在合理的解決辦法; 4：使操作者不方便或遇到麻煩, 但不影響執行正常功能或重要功能; 5 ：其它錯誤;
2.2.2錯誤與嚴重性等級對應表 a) 1 級錯誤的描述
這一級別的錯誤一般包括以下內容: 沒有實現或錯誤地實現重要的功能;業務流程存在重大隱患;軟體在操作過程中由於軟體自身的原因自動退出系統或出現死機的情況;軟體在操作過程中由於軟體自身的原因對系統或數據造成破壞;在現有的軟、硬建設環境下不能實現應有的功能;特殊軟體在操作過程中可能危及系統和人身安全等。
b) 2 級錯誤的描述
這一級別的錯誤一般包括: 沒有實現基本功能，並且不存在替代辦法;沒有實現重要功能中的部分功能，並且不存在替代辦法;業務流程銜接錯誤;密鑰以明文方式存儲;沒有留痕功能;用戶的權限分配不合理;在現有的環境下，不能實現部分功能且沒有替代方案;沒有滿足系統的性能要求。
c) 3 級錯誤的描述
這一級的錯誤是與第2 級別的錯誤相對應的，而第3 級錯誤則存在替代方法;對誤操作或錯誤操作沒有提示，導致非法數據進入資料庫。
d) 4 級錯誤的描述
這一級別的錯誤通常為易用性方面的錯誤。比如介面不友好、前後風格不一;中英文混雜;查詢結果輸出不直觀等。
e) 5 級錯誤的描述
通常為文檔方面的錯誤，如安裝手冊、操作手冊、維護手冊中的描述錯誤。 其次，對發現的每一個錯誤都要確定相應的嚴重性等級，如表2 中的說明。
全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，用戶方認為軟體不可驗收，要求開發方在規定的時間內全面整改軟體, 提交給軟體評測中心再次進行完整的驗收測試。
2.2.2 驗收標準
1) 測試用例不通過數的比例< 1.5 %; 2) 不存在錯誤等級為1 的錯誤; 3) 不存在錯誤等級為2 的錯誤; 4) 錯誤等級為3 的錯誤數量≤ 5; 5) 所有提交的錯誤都已得到更正; 2.3 驗收標準的詳細說明
驗收項目的劃分參照GB/T 16260 標準。在該標準中，將軟體的質量特性分為6 大特性、21 個子特性，而對於具體的軟體，並非都要進行這21 個特性的測試和評價。本文選取的是最通用的子特性部分，針對各種不同的軟體，可以對驗收項目進行剪裁或擴充。
需要制定的驗收標準，即每一級別的錯誤量的可接受範圍。一般來說，不允許存在1 級和2級錯誤，而3 級錯誤的數量則可按本標準確定或由用戶方和開發方根據軟體的規模和複雜程度進行商定，並在軟體開發合同中明確地列出。
在軟體驗收測試中， 測試的依據包括軟體的投標文件、開發合同、需求規格說明書, 同時還包括特定軟體的相關行業標準(這些行業標準應在開發合同中明示出來)。
在進行第三方的驗收測試後，軟體評測中心將發現的所有錯誤進行總結和歸納， 並提交完整的錯誤報告，在錯誤報告中包括每一級別的錯誤數量和錯誤清單(所有的錯誤都需經過用戶方和開發方的確認)。
用戶方根據錯誤報告中每一級別的錯誤數量和錯誤清單與軟體開發合同中的驗收標準進行對照，如錯誤的級別和數量在合同中沒有約定，可按本辦法的規定進行。用戶方認為軟體可以驗收，但要求開發方對錯誤報告中的所有錯誤進行整改，並提交給軟體評測中心進行回歸測試，確認錯誤報告中的所有錯誤全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，用戶方認為軟體不可驗收，要求開發方在
規定的時間內全面整改軟體，提交給軟體評測中心再次進行完整的驗收測試。
3、驗收資料
(1)工程立項批准文件 (2)項目驗收申請報告; (3)工程招標書 (4)工程投標書 (5)工程施工中標通知書 (6)工程施工合同(含預算表) (7)軟體需求說明書; (8)概要設計說明書;
(9)數據及資料庫設計要求說明書; (10)詳細設計說明書; (11)操作手冊; (12)用戶手冊
(13)項目用戶評價過程意見; (14)軟體接口規範; (15)原代碼或安裝盤; (16)專家組要求的其他材料 4、其他
在有條件的情況下，還應該進行安裝測試、壓力測試和數據恢複測試。若進行子系統驗收或部分驗收，可參照以上方法和資料，雙方共同協商確定。
參考文獻：
GB/T 17544 ;GB/T 16260;《軟體驗收標準探討》
{項目名稱}
驗收報告
{日期}
目 錄
§1 項目基本情況.................................................... §2 項目進度審核.................................................... 2.1 項目實施進度情況 2.2 項目變更情況 2.3 項目投資結算情況
§3 項目驗收計劃.................................................... 3.1 項目驗收原則 3.2 項目驗收方式 3.3 項目驗收內容
§4 項目驗收情況匯總................................................ 4.1 項目驗收情況匯總表 4.2 項目驗收附件明細 4.3 專家組驗收意見
§5 項目驗收結論.................................................... 5.1 開發單位結論 5.2 建設單位結論
§6 附件............................................................ 6.1 附件一：軟體平台驗收單 6.2 附件二：功能模塊驗收單 6.3 附件三：項目文檔驗收單 6.4 附件四：硬體設備驗收單
§1 項目基本情況
§2 項目進度審核2.1 項目實施進度情況
2.2 項目變更情況2.2.1 項目合同變更情況
{記錄合同變更情況}
2.2.2 項目需求變更情況
{記錄需求變更情況}
2.3 項目投資結算情況
§3 項目驗收計劃3.1 項目驗收原則
1、審查提供驗收的各類文檔的正確性、完整性和統一性，審查文檔是否齊全、合理; 2、審查項目功能是否達到了合同規定的要求; 3、審查項目有關服務指標是否達到了合同的要求; 4、審查項目投資以及實施進度的情況;
5、對項目的技術水平做出評價，並得出項目的驗收結論。
3.2 項目驗收方式
{記錄項目驗收的組織方式和參與驗收工作的人員情況}
3.3 項目驗收內容
1、硬體設備驗收; 2、軟體平台驗收; 3、應用系統驗收; 4、項目文檔驗收;
5、項目服務響應(如售後服務、問題相應等方面)驗收。
§4 項目驗收情況匯總
4.1 項目驗收情況匯總表
4.2 項目驗收附件明細
1、軟體平台驗收單(見附件一)。 2、功能模塊驗收單(見附件二)。
3、項目文檔驗收單(見附件三)。 4、硬體設備驗收單(見附件四)。
4.3 專家組驗收意見
§5 項目驗收結論5.1 開發單位結論
5.2 建設單位結論
§6 附件6.1 附件一：軟體平台驗收單
驗收人： 驗收時間：
6.2 附件二：功能模塊驗收單
驗收人： 驗收時間：
6.3 附件三：項目文檔驗收單
驗收人： 驗收時間：
6.4
附件四：硬體設備驗收單
驗收人： 驗收時間：
軟體驗收報告範文 篇1
甲方： 有限公司
乙方： 有限公司
甲方收到乙方開發的)，下文簡稱“軟體”。截止於 年 月 日初步測試已經通過，暫時無發現重大軟體漏洞問題，軟體細節後期有待驗證。
乙方應在甲方實際使用軟體過程中，對軟體已有功能做售後服務。如後期有軟體漏洞問題，乙方應積極配合甲方做免費修復。
甲方驗收人員： 日期：
甲方驗收人員： 日期：
軟體驗收報告範文 篇2
甲方：
乙方：
就“ ，經過甲乙雙方的通力配合和共同努力，完成了合同中約定的全部任務，現在整個系統運行正常，按照合同約定，進行項目驗收工作。
驗收工作分為設備清點、安裝調試、初驗、上線試運行和終驗幾個階段，驗收方式主要以清單、測試和實地操作為主。具體內容如下： 第一部分：設備清點
主要檢查運到甲方的設備是否與合同相符
甲乙雙方按照合同要求對運抵現場的設備進行了清點，此項工作已於 年 月 日完成，結論如下：
1.1 核對到貨清單，實物與運送單據是否一致。
□通過 □未通過 備註：
1.2 檢查和清點運抵現場的各種設備是否與合同相符。
□通過 □未通過 備註：
1.3 檢查運抵現場的文檔是否齊全
□通過 □未通過 備註：
第二部分：安裝調試
通過系統硬體測試證明各部分硬體物理破壞且已正確安裝。
按照合同要求，乙方對已經到貨的設備進行了安裝，甲乙雙方進行了加電測試，主要觀察設備加電後的表現和運行自檢程序的結果，此項工作已於 年 月 日完成，結論如下：
2.1 加電是否成功
□通過 □未通過 備註：
2.2 設備狀態是否正常
□通過 □未通過 備註：
2.3 系統顯示的版本和序列號等信息是否符合合同要求
□通過 □未通過 備註：
2.4 自檢有無報警
□通過 □未通過 備註：
第三部分：初驗、上線試運行
通過系統運行，證明系統可以正常工作
乙方進行設備安裝調試後，甲乙雙方在作業系統、資料庫等運行環境下進行系統測試，此項工作已於 年 月 日完成，結論如下：
3.1 系統啟動是否正常
□通過 □未通過 □未涉及 備註：
3.2 系統管理功能是否正常
□通過 □未通過 □未涉及 備註：
3.3 相關軟體License是否已經生效使用
□通過 □未通過 □未涉及 備註：
3.4系統運行是否正常
□通過 □未通過 □未涉及 備註：
第四部分 終驗
系統和設備在質保期內能正常運轉，出現故障，能及時解決。
乙方在質保期內對系統和設備進行了終驗驗收，此項工作已於 年 月 日完成，結論如下：
□通過 □未通過 □未涉及 備註：
完成上述工作以後，甲乙雙方認為整個項目驗收正式通過，整個系統交付完畢，設備運行正常，可以投入使用。
甲方： 乙方：
代表 代表
日期 日期
軟體驗收報告範文 篇3
用戶名稱： huaxia
密級：huaxia123
文檔編號：
編 寫：
審 核：
批 准
項目名稱：
編寫日期：
審核日期：
批准日期：
項目名稱
【驗收報告應由客戶方起草，雙方有關人員簽字，此時驗收報告的格式主要由客戶方選定;當然，也可接受用戶方委託，由項目經理起草驗收報告，經用戶方簽字蓋章認可。】
第一章 項目概述
1.1 項目背景
目前，電視台除了自製節目以外，外購節目制度存在非常明顯的潛規則、暗箱操作、圈子交易等現象，一個公平、公正、公開、透明的節目採購方式呼之欲出。
各省級衛視也有自己的採購方式。如江蘇廣播電視總台電視節目採購工作按照民主集中制的原則開展，實行四級審片制，即採購人員初審、審片組審片、分管主任複審、主任審看。另外還有送頻道或者召開觀眾審片會議複審。對審片評價較好的劇目進行外地播出效果評估，最後形成劇目的總體評價，對有爭議的劇目報總台分管領導仲裁。所有外購節目採購在部門民主集中形成意見後報總台領導批准購買。廣州電視台除新聞節目外，所有頻道、節目將全面實行制播分離，所屬九個頻道向台內外製作機構開放，建立起多主體、多渠道採購節目，擇優播出機制。
面對激烈的市場競爭和不規範的市場原則，省級衛視為了搶占市場先機，降低採購成本，採取聯合採購的模式。如2+4模式：東方衛視和北京衛視購買了《馬文的戰爭》的首輪播出權後，二輪播權由山東、天津、吉林和深圳4家衛視採購。還有《我的團長我的團》、《潛伏》、《婚變》等電視劇被適用於4+4模式。另外，目前的電視劇爭奪戰中還出現了“劇本期貨”交易現象——在劇本出來之後，只要有足夠的賣點和看點，電視台就會採取前期介入，迅速獲得優勢資源。
另一方面，由於電視劇買賣的圈子很小，電視台和製作機構之間的買賣屬於圈子交易。每年60億元的購片經費中，大部分都集中在幾十個電視台採購負責人手中。很多情況下，電視台的節目採購很大程度上受到採購者的個人因素影響，如與節目製作機構的人際關係，個人的喜好或者審美習慣等等。這樣就無法保證把經費用在刀刃上，既浪費了資源，又沒有買到好的節目。
各家電視台都出台了各種採購形式，但電視台的節目採購形式都沒有在業界形成
項目名稱
公信度和絕對優勢，因為沒有一個切實有效的部門(崗位)來統籌規範電視節目的引進工作，這就非常有必要增設採購編輯來改變這一現狀。
1.2 參考資料
編寫本驗收報告時主要參考了如下的資料和文獻：
1.
2.
3.
4.
5.
6. 《華夏影視交易平台系統合同書(主合同)》 《華夏影視交易平台系統軟體開發合同書》 《華夏影視交易平台系統需求分析說明書》 《華夏影視交易平台系統總體設計說明書》 《華夏影視交易平台系統詳細設計說明書》 《應達到的技術指標和參數(驗收標準)》
第二章 驗收定義
2.1 驗收方式
組織彙報、功能代碼審查
2.2 驗收依據
《華夏影視交易平台系統合同書(主合同)》
《華夏影視交易平台系統軟體開發合同書》
《附件五 華夏影視交易平台系統工作說明書》
2.3 驗收環境
華夏影視交易平台X綜合業務系統實際運行的生產環境為驗收環境。
硬體平台
伺服器：AS/400-840系列;RS/6000-H85
客戶機：IBM_PC、實達、國光、長城系列終端及終端外圍設備。
軟體平台
項目名稱
伺服器：OS/400 Ver5.1 AIX 4.3.3作業系統，DB2 資料庫 Ver 7.2.0;
客戶機：SCO UNIX作業系統3.24及5.01, INFORMIX ONLINE 資料庫 Ver 7.3
2.4 驗收標準
2.4.1 系統功能標準
如果各模塊驗收測試結果如下表所述則視為驗收合格，否則將進行修改，以進行再次驗收評審。
2.4.2 性能標準
1.優秀
1)材料完整
2)軟體可正常運行
3)實現項目軟體需求說明書要求的各項功能需求
4)軟體介面友好，易於交互
5)軟體功能新穎，有較強創新
2.合格
1)本標準第3條要求的材料完整
2)可正常運行實現功能達到軟體需求說明書要求的三分之二以上 3.不合格
1)標準第3條要求的材料不完整 2)軟體不能運行
3) 軟體需求說明書要求的主要功能 。
2.5 驗收規則
驗收規則一：【避免在法度中應用魔鬼數字，必須用有意義的常量來標識。】
驗收規則二：【明白辦法的功能，一個辦法僅完成一個功能。】
驗收規則三：【辦法參數不克不及跨越5個】
驗收規則四：【辦法調用儘量不要返回null，取而代之以拋出異常，或是返回特例對象(SPECIAL CASE object，SPECIAL CASE PATTERN);對於以湊集或數組類型作為返回值的辦法，取而代之以空湊集或0長度數組。】
驗收規則五：【在進行資料庫操縱或IO操縱時，必須確保資料在應用完畢後獲得開釋，並且必須確保開釋操縱在finally中進行。】
驗收規則六：【異常捕獲不要直接catch (Exception ex) ，應當把異常細分處理懲罰。】
驗收規則七：【對於if „ else if „(後續可能有多個else if …)這種類型的前提斷定，最後必須包含一個else分支，避免呈現分支漏掉造成錯誤;每個switch-case語句都必須包管有default，避免呈現分支漏掉，造成錯誤。】
驗收規則八：【覆寫對象的equals辦法時必須同時覆寫hashCode辦法。】
驗收規則九：【禁止輪迴中創建新線程，儘量應用線程池。】
驗收規則十：【在進行正確策畫時(例如:貨幣策畫)避免應用float和double，浮點數策畫都是不正確的，必須應用BigDecimal或將浮點數運算轉換為整型運算。】
2.6 驗收人員
2.7 驗收時間
第三章 遺留問題
暫無。
第四章 交付物清單
4.1 文檔提交清單
4.2 源碼提交清單
第五章 驗收結論
第一版驗收通過
第六章 雙方簽字
客戶方(蓋章)： 代表：
公司(蓋章) 代表： 日期：
日期：
第三方((蓋章)[如果有]： 代表： 日期：
附件:
驗收測試記錄、測試報告等記錄。
軟體驗收報告範文 篇4
目前，國內軟體的驗收沒有可參照的強制性標準，就軟體測試和評價來說，參照的標準是GB/T 17544 和GB/T 16260，它們都是推薦性標準，且都是定性而非定量的標準，這樣，對於軟體的驗收來說，存在很大的分歧和不確定性。為此，我們在參考了大量的實踐案例和文獻的基礎上，結合本校實際制定本驗收辦法，用於規範本校軟體系統驗收。
軟體系統的驗收可通過本校組織驗收或通過第三方驗收兩種辦法。 1、驗收原則
驗收參與部門：資產管理處、紀檢監察、用戶使用單位、專家小組或第三方驗收人員;開發單位。
在軟體開發合同的簽訂階段就提出軟體驗收項目和驗收通過標準的意見;在軟體的需求評審階段，仔細審閱軟體的需求規格說明書，指出不利於測試和可能存在歧義的描述;在開發方開發完軟體並經過開發方內部仔細的測試後，對完成的軟體進行評審或第三方的驗收測試，提供完整的錯誤報告提交給用戶方，由用戶方根據之前簽訂的開發合同中相應的驗收標準判斷是否進行驗收。
2、驗收項目和驗收標準 2.1 驗收項目 a) 功能項測試
對軟體需求規格說明書中的所有功能項進行測試; b) 業務流程測試
對軟體項目的典型業務流程進行測試; c) 容錯測試
容錯測試的檢查內容包括:
1) 軟體對用戶常見的誤操作是否能進行提示;
2) 軟體對用戶的的操作錯誤和軟體錯誤，是否有準確、清晰的提示; 3) 軟體對重要數據的刪除是否有警告和確認提示;
4) 軟體是否能判斷數據的有效性，屏蔽用戶的錯誤輸入，識別非法值，並有相應的錯誤提示。
d) 安全性測試安全性測試的檢查內容包括:
1) 軟體中的密鑰是否以密文方式存儲;
2) 軟體是否有留痕功能, 即是否保存有用戶的操作日誌; 3) 軟體中各種用戶的權限分配是否合理; e) 性能測試
對軟體需求規格說明書中明確的軟體性能進行測試。測試的準則是要滿足規格說明書中的各項性能指標。
f ) 易用性測試 易用性測試的內容包括:
1) 軟體的用戶介面是否友好，是否出現中英文混雜的介面; 2) 軟體中的提示信息是否清楚、易理解，是否存在原始的英文提示; 3) 軟體中各個模塊的介面風格是否一致;
4) 軟體中的查詢結果的輸出方式是否比較直觀、合理。 g) 適應性測試
參照用戶的軟、硬體使用環境和需求規格說明書中的規定，列出開發的軟體需要滿足的軟、硬體環境。對每個環境進行測試。
h) 文檔測試
用戶文檔包括: 安裝手冊、操作手冊和維護手冊。對用戶文檔測試的內容包括: 1) 操作、維護文檔是否齊全、是否包含產品使用所需的信息和所有的功能模塊; 2) 用戶文檔描述的信息是否正確, 是否沒有歧義和錯誤的表達;
3) 戶文檔是否容易理解, 是否通過使用適當的術語、圖形表示、詳細的解釋來表達;
4) 用戶文檔對主要功能和關鍵操作是否提供應用實例; 5) 用戶文檔是否有詳細的目錄表和索引表; i)
用戶有特別要求的測試
2.2 驗收標準
2.2.1 軟體錯誤的嚴重性等級
1：不能執行正常功能或重要功能, 或者危及人身安全; 2：嚴重地影響系統要求或基本功能的實現, 且沒有辦法解決; 3：嚴重地影響系統要求或基本功能的實現, 但存在合理的解決辦法; 4：使操作者不方便或遇到麻煩, 但不影響執行正常功能或重要功能; 5 ：其它錯誤;
2.2.2錯誤與嚴重性等級對應表 a) 1 級錯誤的描述
這一級別的錯誤一般包括以下內容: 沒有實現或錯誤地實現重要的功能;業務流程存在重大隱患;軟體在操作過程中由於軟體自身的原因自動退出系統或出現死機的情況;軟體在操作過程中由於軟體自身的原因對系統或數據造成破壞;在現有的軟、硬建設環境下不能實現應有的功能;特殊軟體在操作過程中可能危及系統和人身安全等。
b) 2 級錯誤的描述
這一級別的錯誤一般包括: 沒有實現基本功能，並且不存在替代辦法;沒有實現重要功能中的部分功能，並且不存在替代辦法;業務流程銜接錯誤;密鑰以明文方式存儲;沒有留痕功能;用戶的權限分配不合理;在現有的環境下，不能實現部分功能且沒有替代方案;沒有滿足系統的性能要求。
c) 3 級錯誤的描述
這一級的錯誤是與第2 級別的錯誤相對應的，而第3 級錯誤則存在替代方法;對誤操作或錯誤操作沒有提示，導致非法數據進入資料庫。
d) 4 級錯誤的描述
這一級別的錯誤通常為易用性方面的錯誤。比如介面不友好、前後風格不一;中英文混雜;查詢結果輸出不直觀等。
e) 5 級錯誤的描述
通常為文檔方面的錯誤，如安裝手冊、操作手冊、維護手冊中的描述錯誤。 其次，對發現的每一個錯誤都要確定相應的嚴重性等級，如表2 中的說明。
全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，用戶方認為軟體不可驗收，要求開發方在規定的時間內全面整改軟體, 提交給軟體評測中心再次進行完整的驗收測試。
2.2.2 驗收標準
1) 測試用例不通過數的比例< 1.5 %; 2) 不存在錯誤等級為1 的錯誤; 3) 不存在錯誤等級為2 的錯誤; 4) 錯誤等級為3 的錯誤數量≤ 5; 5) 所有提交的錯誤都已得到更正; 2.3 驗收標準的詳細說明
驗收項目的劃分參照GB/T 16260 標準。在該標準中，將軟體的質量特性分為6 大特性、21 個子特性，而對於具體的軟體，並非都要進行這21 個特性的測試和評價。本文選取的是最通用的子特性部分，針對各種不同的軟體，可以對驗收項目進行剪裁或擴充。
需要制定的驗收標準，即每一級別的錯誤量的可接受範圍。一般來說，不允許存在1 級和2級錯誤，而3 級錯誤的數量則可按本標準確定或由用戶方和開發方根據軟體的規模和複雜程度進行商定，並在軟體開發合同中明確地列出。
在軟體驗收測試中， 測試的依據包括軟體的投標文件、開發合同、需求規格說明書, 同時還包括特定軟體的相關行業標準(這些行業標準應在開發合同中明示出來)。
在進行第三方的驗收測試後，軟體評測中心將發現的所有錯誤進行總結和歸納， 並提交完整的錯誤報告，在錯誤報告中包括每一級別的錯誤數量和錯誤清單(所有的錯誤都需經過用戶方和開發方的確認)。
用戶方根據錯誤報告中每一級別的錯誤數量和錯誤清單與軟體開發合同中的驗收標準進行對照，如錯誤的級別和數量在合同中沒有約定，可按本辦法的規定進行。用戶方認為軟體可以驗收，但要求開發方對錯誤報告中的所有錯誤進行整改，並提交給軟體評測中心進行回歸測試，確認錯誤報告中的所有錯誤全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，用戶方認為軟體不可驗收，要求開發方在
規定的時間內全面整改軟體，提交給軟體評測中心再次進行完整的驗收測試。
3、驗收資料
(1)工程立項批准文件 (2)項目驗收申請報告; (3)工程招標書 (4)工程投標書 (5)工程施工中標通知書 (6)工程施工合同(含預算表) (7)軟體需求說明書; (8)概要設計說明書;
(9)數據及資料庫設計要求說明書; (10)詳細設計說明書; (11)操作手冊; (12)用戶手冊
(13)項目用戶評價過程意見; (14)軟體接口規範; (15)原代碼或安裝盤; (16)專家組要求的其他材料 4、其他
在有條件的情況下，還應該進行安裝測試、壓力測試和數據恢複測試。若進行子系統驗收或部分驗收，可參照以上方法和資料，雙方共同協商確定。
參考文獻：
GB/T 17544 ;GB/T 16260;《軟體驗收標準探討》
{項目名稱}
驗收報告
{日期}
目 錄
§1 項目基本情況.................................................... §2 項目進度審核.................................................... 2.1 項目實施進度情況 2.2 項目變更情況 2.3 項目投資結算情況
§3 項目驗收計劃.................................................... 3.1 項目驗收原則 3.2 項目驗收方式 3.3 項目驗收內容
§4 項目驗收情況匯總................................................ 4.1 項目驗收情況匯總表 4.2 項目驗收附件明細 4.3 專家組驗收意見
§5 項目驗收結論.................................................... 5.1 開發單位結論 5.2 建設單位結論
§6 附件............................................................ 6.1 附件一：軟體平台驗收單 6.2 附件二：功能模塊驗收單 6.3 附件三：項目文檔驗收單 6.4 附件四：硬體設備驗收單
§1 項目基本情況
§2 項目進度審核2.1 項目實施進度情況
2.2 項目變更情況2.2.1 項目合同變更情況
{記錄合同變更情況}
2.2.2 項目需求變更情況
{記錄需求變更情況}
2.3 項目投資結算情況
§3 項目驗收計劃3.1 項目驗收原則
1、審查提供驗收的各類文檔的正確性、完整性和統一性，審查文檔是否齊全、合理; 2、審查項目功能是否達到了合同規定的要求; 3、審查項目有關服務指標是否達到了合同的要求; 4、審查項目投資以及實施進度的情況;
5、對項目的技術水平做出評價，並得出項目的驗收結論。
3.2 項目驗收方式
{記錄項目驗收的組織方式和參與驗收工作的人員情況}
3.3 項目驗收內容
1、硬體設備驗收; 2、軟體平台驗收; 3、應用系統驗收; 4、項目文檔驗收;
5、項目服務響應(如售後服務、問題相應等方面)驗收。
§4 項目驗收情況匯總
4.1 項目驗收情況匯總表
4.2 項目驗收附件明細
1、軟體平台驗收單(見附件一)。 2、功能模塊驗收單(見附件二)。
3、項目文檔驗收單(見附件三)。 4、硬體設備驗收單(見附件四)。
4.3 專家組驗收意見
§5 項目驗收結論5.1 開發單位結論
5.2 建設單位結論
§6 附件6.1 附件一：軟體平台驗收單
驗收人： 驗收時間：
6.2 附件二：功能模塊驗收單
驗收人： 驗收時間：
6.3 附件三：項目文檔驗收單
驗收人： 驗收時間：
6.4
附件四：硬體設備驗收單
軟體驗收報告範文 篇5
目前，國內軟體的驗收沒有可參照的強制性標準，就軟體測試和評價來說，參照的標準是GB/T 17544 和GB/T 16260，它們都是推薦性標準，且都是定性而非定量的標準，這樣，對於軟體的驗收來說，存在很大的分歧和不確定性。為此，我們在參考了大量的實踐案例和文獻的基礎上，結合本校實際制定本驗收辦法，用於規範本校軟體系統驗收。
軟體系統的驗收可通過本校組織驗收或通過第三方驗收兩種辦法。 1、驗收原則
驗收參與部門：資產管理處、紀檢監察、用戶使用單位、專家小組或第三方驗收人員;開發單位。
在軟體開發合同的簽訂階段就提出軟體驗收項目和驗收通過標準的意見;在軟體的需求評審階段，仔細審閱軟體的需求規格說明書，指出不利於測試和可能存在歧義的描述;在開發方開發完軟體並經過開發方內部仔細的測試後，對完成的軟體進行評審或第三方的驗收測試，提供完整的錯誤報告提交給用戶方，由用戶方根據之前簽訂的開發合同中相應的驗收標準判斷是否進行驗收。
2、驗收項目和驗收標準 2.1 驗收項目 a) 功能項測試
對軟體需求規格說明書中的所有功能項進行測試; b) 業務流程測試
對軟體項目的典型業務流程進行測試; c) 容錯測試
容錯測試的檢查內容包括:
1) 軟體對用戶常見的誤操作是否能進行提示;
2) 軟體對用戶的的操作錯誤和軟體錯誤，是否有準確、清晰的提示; 3) 軟體對重要數據的刪除是否有警告和確認提示;
4) 軟體是否能判斷數據的有效性，屏蔽用戶的錯誤輸入，識別非法值，並有相應的錯誤提示。
d) 安全性測試安全性測試的檢查內容包括:
1) 軟體中的密鑰是否以密文方式存儲;
2) 軟體是否有留痕功能, 即是否保存有用戶的操作日誌; 3) 軟體中各種用戶的權限分配是否合理; e) 性能測試
對軟體需求規格說明書中明確的軟體性能進行測試。測試的準則是要滿足規格說明書中的各項性能指標。
f ) 易用性測試 易用性測試的內容包括:
1) 軟體的用戶介面是否友好，是否出現中英文混雜的介面; 2) 軟體中的提示信息是否清楚、易理解，是否存在原始的英文提示; 3) 軟體中各個模塊的介面風格是否一致;
4) 軟體中的查詢結果的輸出方式是否比較直觀、合理。 g) 適應性測試
參照用戶的軟、硬體使用環境和需求規格說明書中的規定，列出開發的軟體需要滿足的軟、硬體環境。對每個環境進行測試。
h) 文檔測試
用戶文檔包括: 安裝手冊、操作手冊和維護手冊。對用戶文檔測試的內容包括: 1) 操作、維護文檔是否齊全、是否包含產品使用所需的信息和所有的功能模塊; 2) 用戶文檔描述的信息是否正確, 是否沒有歧義和錯誤的表達;
3) 戶文檔是否容易理解, 是否通過使用適當的術語、圖形表示、詳細的解釋來表達;
4) 用戶文檔對主要功能和關鍵操作是否提供應用實例; 5) 用戶文檔是否有詳細的目錄表和索引表; i)
用戶有特別要求的測試
2.2 驗收標準
2.2.1 軟體錯誤的嚴重性等級
1：不能執行正常功能或重要功能, 或者危及人身安全; 2：嚴重地影響系統要求或基本功能的實現, 且沒有辦法解決; 3：嚴重地影響系統要求或基本功能的實現, 但存在合理的解決辦法; 4：使操作者不方便或遇到麻煩, 但不影響執行正常功能或重要功能; 5 ：其它錯誤;
2.2.2錯誤與嚴重性等級對應表 a) 1 級錯誤的描述
這一級別的錯誤一般包括以下內容: 沒有實現或錯誤地實現重要的功能;業務流程存在重大隱患;軟體在操作過程中由於軟體自身的原因自動退出系統或出現死機的情況;軟體在操作過程中由於軟體自身的原因對系統或數據造成破壞;在現有的軟、硬建設環境下不能實現應有的功能;特殊軟體在操作過程中可能危及系統和人身安全等。
b) 2 級錯誤的描述
這一級別的錯誤一般包括: 沒有實現基本功能，並且不存在替代辦法;沒有實現重要功能中的部分功能，並且不存在替代辦法;業務流程銜接錯誤;密鑰以明文方式存儲;沒有留痕功能;用戶的權限分配不合理;在現有的環境下，不能實現部分功能且沒有替代方案;沒有滿足系統的性能要求。
c) 3 級錯誤的描述
這一級的錯誤是與第2 級別的錯誤相對應的，而第3 級錯誤則存在替代方法;對誤操作或錯誤操作沒有提示，導致非法數據進入資料庫。
d) 4 級錯誤的描述
這一級別的錯誤通常為易用性方面的錯誤。比如介面不友好、前後風格不一;中英文混雜;查詢結果輸出不直觀等。
e) 5 級錯誤的描述
通常為文檔方面的錯誤，如安裝手冊、操作手冊、維護手冊中的描述錯誤。 其次，對發現的每一個錯誤都要確定相應的嚴重性等級，如表2 中的說明。
全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，用戶方認為軟體不可驗收，要求開發方在規定的時間內全面整改軟體, 提交給軟體評測中心再次進行完整的驗收測試。
2.2.2 驗收標準
1) 測試用例不通過數的比例< 1.5 %; 2) 不存在錯誤等級為1 的錯誤; 3) 不存在錯誤等級為2 的錯誤; 4) 錯誤等級為3 的錯誤數量≤ 5; 5) 所有提交的錯誤都已得到更正; 2.3 驗收標準的詳細說明
驗收項目的劃分參照GB/T 16260 標準。在該標準中，將軟體的質量特性分為6 大特性、21 個子特性，而對於具體的軟體，並非都要進行這21 個特性的測試和評價。本文選取的是最通用的子特性部分，針對各種不同的軟體，可以對驗收項目進行剪裁或擴充。
需要制定的驗收標準，即每一級別的錯誤量的可接受範圍。一般來說，不允許存在1 級和2級錯誤，而3 級錯誤的數量則可按本標準確定或由用戶方和開發方根據軟體的規模和複雜程度進行商定，並在軟體開發合同中明確地列出。
在軟體驗收測試中， 測試的依據包括軟體的投標文件、開發合同、需求規格說明書, 同時還包括特定軟體的相關行業標準(這些行業標準應在開發合同中明示出來)。
在進行第三方的驗收測試後，軟體評測中心將發現的所有錯誤進行總結和歸納， 並提交完整的錯誤報告，在錯誤報告中包括每一級別的錯誤數量和錯誤清單(所有的錯誤都需經過用戶方和開發方的確認)。
用戶方根據錯誤報告中每一級別的錯誤數量和錯誤清單與軟體開發合同中的驗收標準進行對照，如錯誤的級別和數量在合同中沒有約定，可按本辦法的規定進行。用戶方認為軟體可以驗收，但要求開發方對錯誤報告中的所有錯誤進行整改，並提交給軟體評測中心進行回歸測試，確認錯誤報告中的所有錯誤全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，用戶方認為軟體不可驗收，要求開發方在
規定的時間內全面整改軟體，提交給軟體評測中心再次進行完整的驗收測試。
3、驗收資料
(1)工程立項批准文件 (2)項目驗收申請報告; (3)工程招標書 (4)工程投標書 (5)工程施工中標通知書 (6)工程施工合同(含預算表) (7)軟體需求說明書; (8)概要設計說明書;
(9)數據及資料庫設計要求說明書; (10)詳細設計說明書; (11)操作手冊; (12)用戶手冊
(13)項目用戶評價過程意見; (14)軟體接口規範; (15)原代碼或安裝盤; (16)專家組要求的其他材料 4、其他
在有條件的情況下，還應該進行安裝測試、壓力測試和數據恢複測試。若進行子系統驗收或部分驗收，可參照以上方法和資料，雙方共同協商確定。
參考文獻：
GB/T 17544 ;GB/T 16260;《軟體驗收標準探討》
{項目名稱}
驗收報告
{日期}
目 錄
§1 項目基本情況.................................................... §2 項目進度審核.................................................... 2.1 項目實施進度情況 2.2 項目變更情況 2.3 項目投資結算情況
§3 項目驗收計劃.................................................... 3.1 項目驗收原則 3.2 項目驗收方式 3.3 項目驗收內容
§4 項目驗收情況匯總................................................ 4.1 項目驗收情況匯總表 4.2 項目驗收附件明細 4.3 專家組驗收意見
§5 項目驗收結論.................................................... 5.1 開發單位結論 5.2 建設單位結論
§6 附件............................................................ 6.1 附件一：軟體平台驗收單 6.2 附件二：功能模塊驗收單 6.3 附件三：項目文檔驗收單 6.4 附件四：硬體設備驗收單
§1 項目基本情況
§2 項目進度審核2.1 項目實施進度情況
2.2 項目變更情況2.2.1 項目合同變更情況
{記錄合同變更情況}
2.2.2 項目需求變更情況
{記錄需求變更情況}
2.3 項目投資結算情況
§3 項目驗收計劃3.1 項目驗收原則
1、審查提供驗收的各類文檔的正確性、完整性和統一性，審查文檔是否齊全、合理; 2、審查項目功能是否達到了合同規定的要求; 3、審查項目有關服務指標是否達到了合同的要求; 4、審查項目投資以及實施進度的情況;
5、對項目的技術水平做出評價，並得出項目的驗收結論。
3.2 項目驗收方式
{記錄項目驗收的組織方式和參與驗收工作的人員情況}
3.3 項目驗收內容
1、硬體設備驗收; 2、軟體平台驗收; 3、應用系統驗收; 4、項目文檔驗收;
5、項目服務響應(如售後服務、問題相應等方面)驗收。
§4 項目驗收情況匯總
4.1 項目驗收情況匯總表
4.2 項目驗收附件明細
1、軟體平台驗收單(見附件一)。 2、功能模塊驗收單(見附件二)。
3、項目文檔驗收單(見附件三)。 4、硬體設備驗收單(見附件四)。
4.3 專家組驗收意見
§5 項目驗收結論5.1 開發單位結論
5.2 建設單位結論
§6 附件6.1 附件一：軟體平台驗收單
驗收人： 驗收時間：
6.2 附件二：功能模塊驗收單
驗收人： 驗收時間：
6.3 附件三：項目文檔驗收單
驗收人： 驗收時間：
6.4
附件四：硬體設備驗收單
驗收人： 驗收時間：
收藏