第一篇：系統測試與驗收方案

1.系統測試與驗收方案

1.1.測試方案

1.1.1.單元測試

1.1.1.1.單元測試說明

在計算機編程中，單元測試（又稱為模塊測試）是針對程序模塊(軟件設計的最小單位)來進行正確性檢驗的測試工作。程序單元是應用的最小可測試部件。在過程化編程中，一個單元就是單個程序、函數、過程等；對于面向對象編程，最小單元就是方法，包括基類（超類）、抽象類、或者派生類（子類）中的方法。

單元測試的目標是隔離程序部件并證明這些單個部件是正確的。一個單元測試提供了代碼片斷需要滿足的嚴密的書面規約。因此，單元測試帶來了一些益處。單元測試在軟件開發過程的早期就能發現問題。

1.1.1.2.單元測試方法與內容

單元測試主要采用白盒測試技術，用控制流覆蓋和數據流覆蓋等測試方法設計測試用例；主要測試內容包括單元功能測試、單元性能測試和異常處理測試等。

1.1.1.3.單元測試流程

圖15-1 單元測試流程圖

從配置庫獲取源碼文件，設計測試用例，執行測試用例，并利用相關測試工具對單元代碼進行測試，將測試結論填寫到單元測試報告和軟件Bug清單中。把軟件Bug清單和測試用例執行結果提交測試負責人，并進入納入質量管理。對源碼文件進行的測試，視程序存在缺陷的情況，可能要重復進行，直至問題解決。

單元測試的執行者，一般情況下可由程序的編碼者進行，特殊情況可由獨立于編碼者的測試人員進行。

1.1.1.4.單元測試用例

編程組組長組織、指導開發人員根據《系統設計說明書》，編寫所負責代碼設計模塊的《單元測試用例》，設計單元測試腳本。

1.1.2.代碼評審

代碼評審也稱代碼復查，是指通過閱讀代碼來檢查源代碼與編碼標準的符合性以及代碼質量的活動。

評審的內容：

1)編碼規范問題：命名不規范、magic number、System.out等； 2)代碼結構問題：重復代碼、巨大的方法和類、分層不當、緊耦合等； 3)工具、框架使用不當：Spring、Hibernate、AJAX等；

4)實現問題：錯誤驗證、異常處理、事務劃分、線程、性能、安全、實現過于復雜、代碼可讀性不佳、擴展性不好等； 5)測試問題：測試覆蓋度不夠、可測試性不好等。

評審的優點：

1)提高代碼質量：在項目的早期發現缺陷，將損失降至最低

2)評審的過程也是重新梳理思路的過程，雙方都加深了對系統的理解

3)促進團隊溝通、促進知識共享、共同提高 1.1.3.集成測試

1.1.3.1.集成測試目的

集成測試，也叫組裝測試或聯合測試。集成測試是在單元測試的基礎上，根據《系統概要設計》及《系統集成與開發詳細設計》，對系統的各單元進行組裝。把分離的系統單元組裝為完整的可執行的計算機軟件。集成測試的目的是檢查軟件單元部件是否能夠集成為一個整體，完成一定的功能，并找出單元測試中沒有發現的錯誤，包括數據定義有沒有重合與沖突，接口會不會產生錯誤，組合以后的模塊功能會不會互相影響，組合的系統是不是達到預期的效果等。

1.1.3.2.集成測試采用的方法和內容

集成測試采用白盒測試和黑盒測試相結合的測試技術和漸增式的測試策略，用數據流等測試方法設計測試用例。主要測試內容包括單元之間的接口測試、全局數據結構測試等。

1.1.3.3.集成測試流程

集成測試包括集成測試設計、集成測試準備、集成測試實施和測試記錄、集成測試問題跟蹤和結束測試等階段。

集成測試設計由測試組組長根據項目計劃和開發計劃編制《集成測試計劃》，設計《測試用例》。

測試計劃和測試用例應當通過項目經理的審查。

集成測試準備需要系統測試組組長建立獨立的測試環境。測試環境包括測試硬件環境、網絡、數據庫、應用服務器等以及測試對象(程序)的安裝和初始化工作。

集成測試實施和測試記錄是由系統測試組組長組織人員按照測試計劃和測試用例要求進行測試，并且記錄測試過程和測試結果。

集成測試問題跟蹤是在測試過程中發現的問題由系統測試組組長根據測試記錄提交測試問題報告，并由系統設計人員和開發人員解決每一個問題的過程。

測試結束指測試問題報告中的問題解決后，進行回歸測試。當測試問題降低到一定程度并通過測試通過準則時，系統測試組組長提交測試總結報告結束測試。

1.1.4.功能測試

功能測試包括兩大部分，一是包括基本業務功能、業務測試、接口測試和可用性測試等方面的功能測試，二是包括：安全性測試、故障恢復測試、數據庫測試、配置測試、安裝測試的產品化測試。驗收測試主要從系統的實用性、穩定性、可維護性、靈活性、可操作性、和安全性方面進行測試。

（1）測試目標

組織并執行測試，以降低軟件產品中存在的缺陷，保證產品的質量和可用性，測試工作的目標就是降低BUG率，從各個方面提高軟件產品的質量和可用性。

（2）測試流程

在確定具體的測試范圍及內容后，進行測試分類，并根據分類的結果確定需要設計的測試用例。

在整個測試過程中，我們將用缺陷管理工具BugBase對測試大綱、測試用例、測試問題等進行管理，并可對問題進行統計。

（3）測試完成標準

? 實現功能完全符合功能列表。? 所有的功能頁面均可達。

? TD上的問題得到妥善處理，不含有A,B,C類問題。? 定義的測試項目完成。? 產品化測試的約束達成。

（5）缺陷管理追蹤工具

在上節描述中提到的TD，可以應用于測試的全過程，也可以用于管理各類評審的缺陷等。TD還提供一些模板，例如測試計劃、測試總結、測試大綱、測試問題卡，因此可以通過BugBase實現從測試計劃到總結的各測試活動管理。

我們以需求說明書、軟件需求規格說明為輸入編寫測試大綱，對應測試大綱中的內容和測試需求編寫測試用例，測試人員可以根據測試大綱和用例執行測試，發現問題后，記錄在TD中，測試負責人通過查看缺陷問題列表將問題分配給對應的開發人員，開發人員通過查看問題列表修改問題，TD還提供了各種統計功能，例如根據問題的發現日期、問題等級、問題的分布、問題引入階段等進行統計，這些統計結果可用來進行分析和總結

1.1.5.性能測試

性能測試總體流程與業務系統測試的流程基本相同。驗收測試主要從系統的實用性、穩定性、可維護性、靈活性、可操作性、和安全性方面進行測試。性能測試的內容源于用戶對平臺系統的性能要求。

1.1.5.1.測試目標

性能測試的目標是在整個系統或一個系統的特定組件上定義、建立和執行性能測試。驗證系統是否滿足標書的性能要求，如不能滿足，要進行相應的優化。

1.1.5.2.測試流程

首先對性能測試進行策劃，確定性能測試的類別和測試方法。

然后開發性能測試的用例，確定測試環境并準備就緒后執行性能測試，確定測試中的系統或組件的性能，并使用其結果決定性能是否可以被業務所接受。如果在測試中度量的性能特性證明是不能被接受的，我們可以通過對業務的改進、數據庫、應用服務器等進行調優，以提高性能質量，在進行系統調優前，我們同樣要進行調優的設計與分析。性能測試與應用和技術架構緊密相關并且兩者互相影響。

1.1.5.3.性能測試指標

a)響應時間 響應速度在用戶心理所能承受的范圍內。無論是客戶端還是管理端，當用戶登陸，進行任何操作的時候，系統應該及時進行反映，系統應能檢測出各種非正常情況，并及時提示用戶。

b)可擴展性

在設計上必須具有適應變化的能力，當系統新增業務功能或現有業務改變時，應保證業務在整體框架不變的基礎上，業務變化造成的影響局部化。

c)易用性

所有的業務功能界面風格和操作流程一致，業務表單做到所見即所得，錄入能夠完全通過鍵盤完成。

d)可靠性

系統應保證7*24小時內不宕機，保證在正常情況下和極端情況下業務邏輯的正確性。

e)可用性

必須避免由于單點故障或系統升級而影響整個系統的正常運行。

f)可維護性

系統能夠簡單方便的修改和升級，包含可度性、可修改性、可測試性等。

g)可管理性和服務支持能力

每個層次、每個構件都提供標準的管理接口。實現統一的、一致的日志功能。每個構件都提供應用架構總體設計規定的必要的標準外部接口。

1.1.6.用戶測試

1.1.6.1.測試流程

用戶測試流程如下：

1)明確測試內容，其中包括功能、性能、可用性、安全性、兼容性、與其他系統集成

2)確定測試范圍：確定業務情況類型是是非常重要的。每一種業務情況類型都對應一個實際商業業務。業務情況類型可以被表達成多種狀況（例如，簡單情況、或需要進行復雜處理的例外情況）。

3)測試小組成員確定：由管理人員、業務人員、技術人員等組成，我方提供驗收測試過程中的技術支持。4)明確問題分類標準

5)系統的功能通過功能測試進行驗證。在功能測試過程中發現的問題根據其嚴重程度進行分類。下表列出了功能測試問題的分類。

1.1.6.2.用戶測試設計

設計測試用例：確定每個功能的測試用例，明確系統輸入信息和期望的輸出結果。針對需求規格說明書的每一條測試內容，確定測試用例。每個測試用例包括測試條件（包括生成測試條件需要的測試數據類型）和期望的結果。每個測試用例都應該是唯一確定的（例如，賦一個數值）。

設計測試大綱：依據測試范圍生成測試大綱。對每一種業務情況類型，生成盡可能多的測試用例來完善測試大綱。為了保證測試大綱包含所有的測試用例，將測試用例的條件映射為測試大綱是非常必要的。測試大綱中測試用例的順序安排是非常重要的，它應考慮多種方面的因素，主要考慮的因素是按照系統產生的數據，在測試大綱中安排測試用例的順序，使得一個測試的結果作為另一個測試前提。

測試環境準備：為了預防出現問題，如數據損壞或對系統資源的爭用，需要建立一個獨立的測試環境。在進行測試之前，根據測試計劃中確定的時機建立一個獨立的測試環境。

1.1.6.3.用戶測試結果

1)測試結束后，測試小組根據測試數據，制定并向驗收工作領導小組提交《用戶測試報告》。

2)測試報告結果說明軟件滿足下列要求： 3)在認可的外部設計文檔中表述的功能要求 4)在認可的系統描述文檔中表述的非功能要求 5)此外，測試報告中還包括對系統提出的改進意見。

1.1.7.測試產出

1)《測試計劃》 2)《系統測試方案》 3)《測試用例》 4)《系統測試案例》 5)《系統測試報告》 6)《試運行測試報告》

1.2.驗收方案

1.2.1.驗收流程

在驗收階段，平臺系統將按照用戶和我公司都認可的《系統需求分析》，組織驗收小組，進行功能和性能的驗收測試。從系統的實用性、穩定性、可維護性、靈活性、可操作性、和安全性及系統文檔、代碼、規范及注釋說明等方面組織全面驗收。驗收測試安排分為系統初驗和系統終驗。

1.2.2.系統初驗

經過系統內部試運行，我公司對內部試運行期間發現的問題改正后，提出系統初驗書面申請。驗收標準將按照“需求說明書”和雙方認可的有關系統設計文檔所提的要求進行。用戶在收到我公司驗收申請后，盡快組織系統初驗。初驗前我公司提供全部的工程文檔和安裝測試報告，并提供初驗測試文檔，在用戶認可后進行初驗測試，初驗通過后，系統進入正式試運行期。我公司應解決試運行期間所反映出的問題，若系統達不到合同規定要求，試運行期將繼續順延，直到系統完善，但試運行期最長不得超過一個月。

1.2.3.系統試運行

初驗合格后，經用戶同意，系統進入試運行階段，試運行周期不超過三個月。在試運行期間，我公司按用戶要求提供培訓和技術支持，保證用戶能夠正確理解和使用系統；我公司對試運行中出現的任何問題及用戶提出的修改意見將及時做出響應，并提交解決方案，在用戶確認后實施。試運行期間如出現重大故障，則試運行期從故障排除之日起重新計算。

1.2.4.系統終驗

試運行期結束后，如系統無功能缺陷，能夠正常運行，在具備終驗條件下進行系統終驗，由我公司提出終驗書面申請，用戶在收到我公司驗收申請后，盡快組織系統終驗。成立項目全面驗收小組，由用戶、我公司以及外部專家等組成，對項目進行全面驗收。系統終驗前，我公司提交終驗測試標準和終驗測試計劃，內容包括：測試對象及應達到的測試指標、測試方法和測試條件、測試資料和數據，并以圖表說明每一測試對象或過程的功能輸入輸出測試進度。

系統終驗標準：

1)系統實用性：項目驗收最關鍵的指標，檢查系統是否符合當前業務的需要，特別是業務流的整體性和數據流的一致性，并前瞻性提供未來業務接口。

2)系統穩定性：硬件環境的穩定性、軟件運行異常處理和正常運行情況。3)系統可維護性：含網絡系統管理與維護、服務器系統平臺管理與維護、操作系統管理與維護、應用系統軟件管理與維護、數據庫管理與維護以及數據庫備份、應用系統備份，災難事件處理與解決實施方案等。

4)系統文檔：驗收文檔是否齊全、規范、準確、詳細，主要的文檔包括：需求分析報告，框架設計報告，數據庫物理及邏輯設計報告，詳細設計報告，編碼規范及技術選型報告，測試報告，系統部署和發布報告，集成方案，軟件用戶使用手冊，系統維護方案和操作文檔等。

5)代碼規范及注釋說明：程序代碼編寫是否規范；注釋說明或代碼文檔是否詳細全面；接口定義是否符合局信息系統規劃一致性的要求。

6)系統靈活性：系統是否方便客戶進行維護；系統是否在先進性的基礎上具備未來升級和可擴充性；是否利于系統平臺遷移和部署等。

7)系統可操作性：界面是否友好性；是否實現傻瓜化操作和智能化數據檢索功能。

8)系統安全性：是否有完善的安全機制保證系統的安全性，如軟件方面的安全防范（加密措施、相關認證、數據庫安全防范），硬件方面（防火墻、物理隔離和邏輯隔離）的安全設置。

9)其他驗收標準：其他的與本系統相關的驗收標準。系統終驗流程安排

1)我公司按照項目驗收計劃完成驗收準備工作 2)用戶代表運行驗收測試用例集，記錄運行結果

3)如果發現沒有通過的驗收測試用例，則我公司立即解決問題 4)用戶主持項目驗收會

5)我公司向用戶報告項目實施結果 6)用戶代表向用戶報告試運行結果

7)用戶評議項目實施和試運行結果，起草和審定項目驗收報告。

1.2.5.系統終驗相關文檔

我公司在軟件開發和系統集成中將嚴格按照國家軟件工程有關要求提供的文檔來提供，驗收的技術文檔至少包含以下內容： 1)系統需求分析 2)系統概要設計 3)系統詳細設計 4)數據庫詳細設計 5)應用系統集成實施方案 6)系統測試大綱 7)系統測試報告 8)系統驗收報告 9)系統用戶使用手冊 10)系統安裝維護管理手冊

1.2.6.終驗報告

驗收小組將在終驗結束后提交一份由專家簽名的驗收報告。驗收報告附平臺系統和整體系統測試結果報告，同時給出以下明確結論之一：

（1）通過驗收；

（2）基本通過驗收，要求在五個工作日內完善后再次進行驗收；（3）未通過驗收，要求在十五個工作日內改正后再次進行驗收； 如再次驗收后仍然不能全部通過，用戶有權終止合同，并要求我公司承擔違約責任。

驗收結束時,我公司將平臺系統相關產品說明書、系統安裝手冊、技術文檔、資料及安裝、測試、驗收報告等文檔匯集成冊交付用戶。

第二篇：驗收測試方案

驗收測試方案

1.1 驗收目的

驗收是項目從實施到售后維護的一個過渡階段，驗收通過之后實施的項目正式實施完成，項目進入系統售后維護階段。驗收是項目建設過程的一個里程碑，說明項目建設完成了實施這一過程，進入了下一個階段。確保項完成后達到有關要求和標準，正常運行平穩，必須進行項目驗收。

1.2 驗收對象

咭星塢平臺，andorid版本、ios版本、OTT版本 1.3 驗收前提條件

1）從測試結果用例覆蓋和系統穩定性方面來看，整個系統的運行已經進入正軌，需求 響應也已基本完成，并穩定運行后組織驗收； 2）要相關使用科室主要負責人簽字； 3）照合同要求全部建成，并滿足使用要求； 4）文檔和驗收資料完備，符合合同的內容； 5）數據處理符合信息安全的要求；

6）系統、數據庫、中間件、應用軟件和開發工具符合知識產權相關政策法規的要求； 1.4 驗收方法

項目驗收是它是對項目建設高度負責的體現，也是項目建設成功的重要保證。采用的驗收方法是：運行項目系統軟件，檢驗其應用軟件的實際能力是否與規定的一致；運行應用軟件，實際操作，處理業務，檢查是否與合同規定的一致，達到了預期的目的。1.5 驗收步驟 1）編寫驗收計劃

2）根據咭星塢平臺的需求分析的基礎上編寫驗收計劃，提交負責人審定。

3）成立項目驗收小組實施測試驗收工作時，成立項目驗收小組，具體負責驗收事宜。4）項目驗收的實施嚴格按照驗收方案對項目應用軟件、系統文檔資料等進行全面的測試和驗收。

5）提交驗收報告項目驗收完畢，對項目系統設計、軟件運行情況等做出全面的評價，得出結論性意見，對不合格的項目不予驗收，對遺留問題提出具體的解決意見。

6）召開項目驗收評審會召開項目驗收評審會，全面細致地審核項目驗收小組所提交的驗收報告，給出最終的驗收意見，形成驗收評審報告并存檔 1.6 驗收流程

（一）初驗

經過系統內部試運行，我公司對內部試運行期間發現的問題改正后，提出系統初驗書面申請。驗收標準將按照“需求說明書”和雙方認可的有關系統設計文檔所提的要求進行，初驗通過后，咭星塢項目正式進入試運行，我公司應解決試運行期間所反映出的問題，若系統達不到合同規定要求，試運行期將繼續順延，直到系統完善，但試運行期最長不得超過三個月

（二）終驗 終驗流程

1）申請：初驗合格后，承建方根據合同、任務書，檢查、總結項目組織實施和完成情況后向建設方提出驗收申請。

2）經過審核，材料齊全則由建設方組織驗收。驗收工作由建設方和供應商項目組人員一起組成驗收小組進行驗收，驗收后提交驗收報告。

3）驗收簽字經過驗收、評審形成的驗收報告和評審報告，建設方簽字，通過驗收。終驗內容：

1）項目驗收最關鍵的指標，系統實用性，業務流的整體性和數據的一致性

2）系統穩定性：硬件環境的穩定性、軟件運行異常處理和正常運行情況。

3）系統可維護性：含網絡系統管理與維護、服務器系統平臺管理與維護、操作系統管理與維護、應用系統軟件管理與維護、數據庫管理與維護以及數據庫備份、應用系統備份，災難事件處理與解決實施方案等。

4）系統文檔：驗收文檔是否齊全、規范、準確、詳細，主要的文檔包括：需求分析報告，框架設計報告，數據庫物理及邏輯設計報告，詳細設計報告，編碼規范，測試報告，系統部署和發布報告，集成方案，軟件用戶使用手冊，系統維護方案和操作文檔等。

5）代碼規范及注釋說明：程序代碼編寫是否規范；注釋說明或代碼文檔是否詳細全面；接口定義是否符合系統規劃一致性的要求

6）系統靈活性：系統是否方便客戶進行維護；系統是否在先進性的基礎上具備未來升級和可擴充性；是否利于系統平臺遷移和部署等。

7）系統可操作性：界面是否友好性；是否實現傻瓜化操作和智能化數據檢索功能。8）系統安全性：是否有完善的安全機制保證系統的安全性，如軟件方面的安全防范（加密措施、相關認證、數據庫安全防范），硬件方面（防火墻、物理隔離和邏輯隔離）的安全設置。1.7 驗收依據

驗收依據為供應商提供的功能設計（項目過程中依據需求調研結果而提交的各子系統《軟件功能描述與操作說明書》，即功能清單。具體依據如下：

A、本項目采購合同的所有文件，尤其是項目需求部分；

B、工程施工過程中的經雙方簽字的變更需求，包括《二次開發方案》《軟件功能描述與操作說明書》《合同或合同變更情況》； C、確認的《系統運行情況報告》；

D、確認的《合同執行情況報告》，確認收到的終驗提交文檔資料情況； 1.8 驗收需提交的文檔

提供整個產品交付過程中產生的全部文檔，產品驗收標準技術說明書使用說明書安裝、維修及操作手冊合同中要求的其他文件資料，系統驗收后供貨方需提供系統源碼，并簽訂保密協議。

開發技術文檔：《需求分析說明書》、《詳細設計》、《二次開發方案》、《數據結構》、《框架結構圖》、《應用系統測試方案》、《系統功能說明》，以及其它要求的技術文檔。工程技術文檔：《測試記錄》、《測試報告》、《數據準備報告》《用戶操作手冊》《系統維護手冊》《系統操作說明書》《培訓計劃》、《培訓記錄》、《故障情況記錄表》《階段驗收方案》 1.9 驗收結論

驗收結果分為：驗收合格、需要復議和驗收不合格三種。

1、項目凡具有下列情況之一的，按驗收不合格處理：

（一）未按項目考核指標或合同要求達到所預定的主要技術指標的；

（二）所提供的驗收材料不齊全或不真實的；

（三）實施過程中出現重大問題，尚未解決和作出說明，或項目實施過程及結果等存在糾紛尚未解決的；

（四）沒有對系統或設備進行試運行，或者試運行不合格；

（五）項目經費使用情況審計發現問題的；

（六）違反法律、法規的其他行為。

1.10 項目交接

項目驗收合格后，應辦理項目交接手續，轉入售后維護階段。

第三篇：系統驗收方案

第一章 項目驗收方案

1.1 驗收目的

驗收是項目從實施到售后維護的一個過渡階段，驗收通過之后實施的項目正式實施完成，項目進入系統售后維護階段。驗收是項目建設過程的一個里程碑，說明項目建設完成了實施這一過程，進入了下一個階段。

為使信息化項目建設按照《軟件功能描述與操作說明書》要求進行，確保項目完成后達到有關要求和標準，正常運行平穩，必須進行項目驗收。

1.2 驗收對象

XXXX有限公司。

1.3 驗收前提條件

（一）從多方的反饋和系統穩定性方面來看，整個系統的運行已經進入正軌，需求的響應也已基本完成，并穩定運行五個月后組織驗收；

（二）每個模塊需要相關使用科室主要負責人簽字；

（三）所有模塊按照合同要求全部建成，并滿足使用要求；

（四）各個分期工程全部初驗合格；

（五）已通過軟件系統測試評審；

（六）各種技術文檔和驗收資料完備，符合合同的內容；

（七）系統建設和數據處理符合信息安全的要求；

（八）外購的操作系統、數據庫、中間件、應用軟件和開發工具符合知識產權相關政策法規的要求；

（九）經過建設方同意；

（十）合同或合同附件規定的其他驗收條件。1.4 驗收方法

項目驗收，是項目開發建設中有組織的主動性行為，它是對項目建設高度負責的體現，也是項目建設成功的重要保證。切實做好項目建設中的驗收工作至關重要，應當采取有效措施，實實在在做好。為保證項目驗收質量，建議采用的驗收方法是：

運行項目系統軟件，檢驗其應用軟件的實際能力是否與合同規定的一致；運行應用軟件，實際操作，處理業務，檢查是否與合同規定的一致，達到了預期的目的。

1.5 驗收步驟

（一）編寫驗收計劃

（二）由XX公司在對項目進行深入的需求分析的基礎上編寫驗收計劃，提交建設方審定。

（三）成立項目驗收小組

實施測試驗收工作時，成立項目驗收小組，具體負責驗收事宜。

（四）項目驗收的實施

嚴格按照驗收方案對項目應用軟件、系統文檔資料等進行全面的測試和驗收。

（五）提交驗收報告

項目驗收完畢，對項目系統設計、軟件運行情況等做出全面的評價，得出結論性意見，對不合格的項目不予驗收，對遺留問題提出具體的解決意見。

（六）召開項目驗收評審會

召開項目驗收評審會，全面細致地審核項目驗收小組所提交的驗收報告，給出最終的驗收意見，形成驗收評審報告并存檔。1.6 驗收程序

（一）初驗

1、申請：項目后經測試和試運行合格，供應商根據合同、招標書、計劃任務書，檢查、總結項目完成情況后向建設方提出初驗申請。

2、方式：建設方組織人員進行初驗。

3、供應商提供材料：初驗申請書、完工報告、項目總結，以及要求的驗收評審資料。

（二）終驗

1、申請：初驗合格后，承建方根據合同、招標書、任務書，檢查、總結項目組織實施和完成情況后向建設方提出驗收申請。

2、經過審核，材料齊全則由建設方組織驗收。

驗收工作由專家、建設方和供應商項目組人員一起組成驗收小組進行驗收，驗收后提交驗收報告。

3、驗收簽字

經過驗收、評審形成的驗收報告和評審報告，建設方簽字，通過驗收。

1.7 驗收依據

驗收依據為供應商提供的功能設計（項目過程中依據需求調研結果而提交的各子系統《軟件功能描述與操作說明書》，即功能清單，本投標文件提交的各技術方案以及《技術偏離表》也是階段驗收的依據之一）。

具體依據如下：

A、本項目招、投標書的所有文件，尤其是項目需求部分；

B、工程施工過程中的經雙方簽字的變更需求，包括《二次開發方案》《軟件功能描述與操作說明書》《合同或合同變更情況》；

C、確認的《系統運行情況報告》；

D、確認的《合同執行情況報告》，確認收到的終驗提交文檔資料情況；

1.8 驗收需提交的文檔

提供以下目錄的原廠商資料一套：

? 按CMMI和ISO9000系列標準要求，提供整個產品交付過程中產生的全部文檔

? 產品驗收標準 ? 技術說明書 ? 使用說明書

? 安裝、維修及操作手冊及公開維修密碼 ? 合同中要求的其他文件資料

? 系統驗收后中標方需提供系統源碼，并簽訂保密協議。開發技術文檔：

《數據字典、數據結構與流程》并提供電子瀏覽、查找工具、直接集成在“系統管理子系統”中；

《需求分析說明書》、《詳細設計》、《二次開發方案》、《數據結構》、《框架結構圖》、《應用系統測試方案》、《系統功能說明》，以及其它招標要求的技術文檔。工程技術文檔：

《測試記錄》、《測試報告》、《數據準備報告》 《用戶操作手冊》 《系統維護手冊》 《接口說明書》 《系統操作說明書》 《試運行方案》 《系統維護情況表》

《培訓計劃》、《培訓記錄》、《例會記錄》、《故障情況記錄表》 《階段驗收方案》??

其他文檔：按采購文件要求須提供的其它文檔。

源代碼：提供的軟件產品應包括各種相關的軟件系統、各階段開發文檔、運行穩定可靠的本系統安裝程序、注釋清晰明了的能編譯生成目前（實施并客戶化后的）正在運行的全套應用程序的源代碼等。階段驗收報告的組成：

階段驗收報告

1.9 驗收結論

驗收結果分為：驗收合格、需要復議和驗收不合格三種。符合信息化項目建設標準、系統運行安全可靠、任務按期保質完成、經費使用合理的，視為驗收合格；由于提供材料不詳難以判斷，或目標任務完成不足80%而又難以確定其原因等導致驗收結論爭議較大的，視為需要復議。

1、項目凡具有下列情況之一的，按驗收不合格處理：

（一）未按項目考核指標或合同要求達到所預定的主要技術指標的；

（二）所提供的驗收材料不齊全或不真實的；

（三）項目的內容、目標或技術路線等已進行了較大調整，但未曾得到相關單位認可的；

（四）實施過程中出現重大問題，尚未解決和作出說明，或項目實施過程及結果等存在糾紛尚未解決的；

（五）沒有對系統或設備進行試運行，或者試運行不合格；

（六）項目經費使用情況審計發現問題的；

（七）違反法律、法規的其他行為。

2、驗收結論確認和處理

由建設方根據驗收意見和相關資料得出結論，并進行確認。

3、項目驗收結論的處理

（一）驗收結論為驗收合格的，則后可進行項目交接；如有需補充問題，則在補充問題響應完成后進行項目交接。

（二）驗收結論為需要復議的，則供應商需在一周內補充有關材料或者進行相關說明。

（三）驗收結論為驗收不合格的，則供應商必須限期整改，整改后試運行合格的，重新申請驗收。

1.10 項目交接

項目驗收合格后，應辦理項目交接手續，轉入售后維護階段。

第四篇：檢驗、測試、調試與驗收方案

檢驗、測試、調試與驗收方案

【隱蔽工程檢驗、測試、驗收方案】

1）凡隱蔽工程都必須組織隱蔽驗收。—般分部（項）隱蔽工程由施工員組織驗收，邀請現場監理工程師參加；重要的請現場監理工程師、建設單位及設計單位派員參加。

2）隱蔽工程檢查記錄是工程檔案重要內容之一，隱蔽工程經三方共同驗收后，及時填寫隱蔽工程檢查記錄。隱蔽檢查記錄由施工員或工程技術負責人填寫，監理工程師和建設單位代表共同會簽。

3）不同項目的隱蔽工程，應分別填寫檢查記錄表應復寫一式五份，建設單位、監理單位各一份，自存三份歸檔。

4）隱蔽工程項目及檢查內容

A 管線、接線盒預埋：導管、位臵、規格、標高、彎度、防腐等，電纜耐壓絕緣試驗、地線、地板的接地電阻。

B 埋地管道工程：位臵、標高、坡度、焊接、防銹、防腐及預埋件等。5）隱蔽工程檢查記錄表的填寫內容

A 單位工程名稱、隱蔽工程名稱、部位、標高、尺寸和工程量。B 材料產地、品種、規格、質量等。C 合格證及試驗報告編號。

6）填寫隱蔽工程檢查記錄，文字要簡練、扼要，能說明問題，必要時應附三面圖（平、立、剖面圖）。

【系統工程檢驗、測試、調試、驗收方案】

1、檢驗、測試和調試前的準備

（1）仔細確認每一臺設備是否安裝、連接正確，認真向施工人員詢問施工遺留的可能影響使用的有關問題。

（2）再次認真地閱讀所有的設備說明書，仔細查閱設計圖紙的標注和連接方式。

（3）一定要確認供電線路和供電電壓沒有任何問題。（4）調試前應該保證現場沒有無關人員。

（5）準備相應的儀器和工具，并保證工作狀態優良。

2、檢驗、測試和調試的項目、方法、程序以及要求

音響系統的調試是工程調試的關鍵，音響系統涉及的設備最多，調試的部位也最多，遇到的問題也可能最多，所以應首先集中精力完成。調試的原則，必須認真閱讀產品說明，逐步細致地進行微調，在不破壞基本的聲場條件的前下，有選擇地使用音頻處理設備，以達到設計要求。需要準備的儀器和工具：相位儀，噪聲發生器，頻譜儀（含聲級計），萬用表。主要關鍵設備調試的步驟：

（1）單獨開機，從音源開始逐步檢查信號的傳輸情況。因為，當信號在各個設備中傳輸良好，功放和音箱才會得到一個正常以經過正確處理的信號，才可能有一個好的擴聲音量。此時，周邊處理設備臵于旁路狀態，音箱和功放與系統斷開。檢查時順著信號的去向，逐步檢查它的電平設臵、增益、相位及暢通情況，保證各個設備都能得到前級設備提供的最佳信號，也能為下級提供最佳信號。在檢查信號的同時，逐一觀察設備的工作是否正常，是否穩定，這項工作意義就在于，單臺設備的在此時出現故障或不穩定，處理起來比較方便，也不會危及其他設備的安全，因此，這項檢查不要帶入下一步進行。（2）上述無誤后，就將音箱和功放逐一接入系統，在較小的音量下，利用相位儀首先逐一檢查所有立場箱的相位是否一致，為下面的調試作好設備，將噪聲發生器的均衡器接入系統，準備好頻譜儀，以適中音量開始對均衡器接入系統，準備好頻譜儀，以適中的音量開始對均衡器進行調試，頻譜儀的測試點要按照有關標準選取，對均衡器的調試原則是：使頻譜儀在于20HZ-20KHZ的音頻范圍內，顯示的廳堂頻響曲線在各測試點處基本平直。注意：對各個點進行測試時要使音量保持一致，然后記錄好調試后的均衡各頻點電位器的位臵；同樣以較小的音量和較大的音量保持一致，然后記錄好調試后均衡器各頻點電位器的位臵；同樣以較小的音量和較大的音量分別再進行一次調試，再將均衡器的調試結果記錄下來，最后將幾種調試結果的數據進行分析，尋找到一個各種音量下均衡量各頻點的折中位臵，然后再進行測試，并將廳堂頻響曲線描繪下來，最終的均衡器各頻點位臵也要進行記錄。在均衡器的調試中，調音臺的頻率補償臵于0處，其它的周邊設備要處于旁路狀態。另外需要說明的是：在通常的音響工程中，考慮到廳堂的裝飾材料對高頻信號的吸收較弱，所以，可以適當將10KHZ以上的信號略做衰減。

（3）以上步驟完成后，進行電子分頻器的調試。分頻器的調試分高、中、低頻單獨進行。其中分頻器在系統中的用途不同，調試的方法也有區別。僅用于低音音箱的分頻器，只要在上述的均衡器調試完成后，讓低音音箱單獨工作，將分頻器的低音分頻點取在150~300HZ之間，適當調整低音信號的增益，感覺低音音量適可便是，然后與全頻系統一道試聽，再進行低音與全頻音量平穩；用在全頻系統中的分頻器，準確依照音箱廠家提供的參數分別設定高、中、低頻的分頻點，然后反復地進行各頻段信號增益的調整，直到各頻段的聽感比較平衡后，再參照下一步頻譜儀在各測試點測試的聲壓情況做進一步的微調。待均衡器和電子分頻器基本調試完畢后，就應該開始進行廳堂聲壓級的測定，測試點還是原來選取的幾點，噪聲源應該用粉紅色噪聲儀，測試時除了全頻段外，在高、中、低三個頻段分別選取幾個頻點測試，測試目標就是：在保證信號最佳動態前提下，以調整使得系統的擴聲聲壓在各點都要達到設計的聲壓級，同時參考高、中、低頻段各點的情況，再分別對均衡器和電子分頻器略作調整，如果各測試點聲壓級結果偏差較大，即聲場的質量，那就應該提出可行的整改措施。如裝飾方面沒有明顯的缺陷，或有一點明顯不足，但無法進行整改時，就應該從音箱的擺位，指向及安裝的形式方面進行分析，分析內容包括：音箱與建筑四面的距離，音箱之間的安裝位臵要求，音箱的指向和頻率特性及各音箱之間的相位等。

（4）話筒的調試。對于話筒的調試按照分類進行，人聲用有線話筒如沒有可聞的線路噪音，音質正常就即可，在其有效活動范圍的聲反饋可以利用頻譜儀進行頻率監測，并作好相應頻率和位臵的記錄；樂器用有線話筒必須和樂隊一道配合調試，并作好樂器使用話筒的型號和拾音距離的記錄；無線話筒必須和樂隊一道配合，并做好各樂器使用話筒的型號和拾音距離的記錄；無線話筒的調試應注意：天線位臵合理，話筒使用出現死點的位臵（作好記錄），接受機的信號電平增益要適可，降噪微調的最佳位臵反復尋找等。

（5）效果器的調試。原則是保證其輸入信號增益能使效果器得到較好動態的聲音信號，并且要留有一定的余量，效果混合信號輸出根據需求來設臵。至于效果器的具體選擇和參數設定，應該作一些粗略的試驗。然后根據節目的要求來選定，需要注意的是：效果器的混響時間和延時量在調節上不要超過一定范圍。以免影響語言的清晰度和信號的連續性，在話筒和效果器的調試中，還應該包括返聽系統的調試，原則就是：讓返聽系統的頻響特性與主擴聲系統一致，其聲壓級演員（包括樂隊）能清楚地聽到各自的聲音為準，不能太大，不能帶來額外的聲反饋等。

（6）壓限器的調試。在系統的以上設備基本調定后再進行，在調試時首先要設定壓縮起始電平，設定值應當適量，具體位臵視各種壓限器的調節范圍和信號而定，其次要設定壓縮啟動和恢復時間，通常啟動時間不宜過長，以免保護動作不及時，而恢復時間不宜太短，以免造成聲音效果受到破壞；再就是要設定壓縮比，一般工程中設在4：1左右，壓縮器中的噪聲門的調節要注意：如果系統沒有較大的噪聲門關閉；如果有一定的噪聲，可以將噪聲門的門檻電平設定較低處，以免造成擴聲信號斷斷續續的現象，如果系統的噪聲較大，應該以施工技術方面分析，不能單獨靠噪聲門來解決，其它設臵可以根據不同要求而定。

（7）系統總體調試及試運行

? 當各分系統的調試已經完成，并且確認各個設備狀態良好，沒有明顯的調試不當時，開始整個系統的全面調試。

? 檢查各系統協同運作中它們相互聯系的工作部分是否協調。

? 檢查它們在同步工作時是否會產生相互影響和干擾，例如：檢查其它系統的切換是否會帶給音響系統的噪音，檢查燈光系統是否會對音響系統產生干擾等等。檢查中央控制系統與受控分系統的信號切換等。

系統驗收前，我們要編制好竣工交驗大綱，在工程指揮部的組織下，邀請設計單位，各子系統施工單位及有關部門參加并要求施工單位做好交驗準備，提供下列資料：

設計文件和相關的技術標準、各子系統的驗收規范標準、系統的評估辦法、施工圖紙、竣工圖紙及施工中各類設計變更單、施工洽商單、各種施工記錄，包括管線敷設記錄、設備安裝調試記錄、試運行記錄等、各類設備資料，包括公司資質證明、用戶操作手冊、保修單等、各種管理資料，公司資質證明、開工報告、竣工報告等。然后按竣工交驗程序，分別對系統功能、施工、竣工資料等項目進行檢查和驗收。統初驗后，經試運行一段時間一切正常，即可組織驗收。

【檢驗、測試、調試、驗收的標準】

? GB/T 50314--2000《智能建筑設計標準》 ? GB 2887-89《計算站場地技術要求》 ? GB 9361-88《計算站場地安全要求》 ? GB50054-95《低壓配電設計規范》 ? EIA/TIA607《民用建筑通信接地標準》 ? EIA/TIA607《民用建筑通信接地標準》

? GB/T50311-2000《建筑與建筑群綜合布線系統工程設計規范》 ? ISO/IEC 11801《國際綜合布線六類信道標準》 ? GB50371-2006《廳堂擴聲系統設計規范》 ? JGJ16-2008《民用建筑電氣設計規范》 ? GB/T50314-2000《智能建筑設計標準》

? GB/T50311-2000《建筑與建筑群綜合布線工程設計規范》 ? GB/T50312-2000《建筑與建筑群綜合布線系統工程驗收規范》 ? GB50259-96《電氣裝臵安裝工程電氣照明裝臵施工及驗收規范》 ? GB50169-92《電氣安裝工程接地裝臵施工質量驗收規范》

? GBJ 232 《電氣裝臵安裝工程施工及驗收規范》 ? GB 50303 《建筑電氣安裝工程施工質量驗收規范》 ? GB/T14549/93《電能質量、公用電網諧波》 ? GB/T126661/6/90《電纜的耐燃性考核標準》 ? GB50217/94《電纜設計規范》 ? GB50258/96《電纜敷設規范》

? GYJ 25-86 《廳堂擴聲系統聲學特性指標》 ? GB 4959-95 《廳堂擴聲特性測量方法》 ? GBJ 76-84 《廳堂混響時間測量方法》

? GB/T 14197-93 《聲系統設備互連的優選配接值》 ? GB 50198 《民用閉路監視電視系統工程技術規范》 ? GBJ 79 《工業企業通訊接地設計規范》 ? GB50016－2006《建筑設計防火規范》 ? GA/T75-94《安全防范工程程序與要求》 ? GA/T74-2000《安全防范系統通用圖形符號》 ? GB50198-94 《民用閉路電視監視系統工程技術規范》 ? GBJ/16-83《建筑電氣設計技術規程》

? GB4208-84，1994年版《外殼防護等級的分類》

? GJB1653-1993《電子和電氣設備、附件及備件包裝規范》

【工程檢測驗收項目、程序及需要招標人參加的項目、時間】

本系統工程檢測驗收項目可分為：系統管線隱蔽工程安裝驗收、設備及設備安裝驗收、系統安裝驗收、系統性能測試驗收、等內容。

? 系統管線隱蔽工程安裝驗收（時間：隱蔽工程完工后）

工程所需管線等敷料進場進行材料報驗合格后，與土建、裝修方同步進行交叉施工，每道工序安裝完成，提請監理部門進行隱蔽工程驗收，驗收完畢并符合要求，出具檢驗報告，保障隱蔽工程的安全可靠。

? 設備及設備安裝驗收（時間：設備安裝結束后）

設備運輸到施工現場，按照合同清單所列貨物名稱、型號，填寫相應報驗表（格式按當地工程監理要求），安排工程各相關部門一起進行貨物的檢驗，所列物品與合同清單核對無誤，相關部門簽字后，進行設備安裝。設備安裝到位后，提請監理方進行安裝驗收（按當地有關工程質量規范標準）。驗收完畢并符合要求，出具檢驗報告。

? 系統安裝驗收（時間：系統安裝完工后）

設備、隱蔽工程安裝完畢并符合要求后，進行系統安裝，安裝完畢后，加電試運行前依照最終系統圖紙，報請相關部門進行系統安裝驗收，驗收完畢并符合要求，出具檢驗報告。

? 系統性能測試驗收（時間：系統初步調試結束后）

前提：以上步驟都完成，并且檢驗合格后，加電進行系統調試，按照國家相應規范、規定和合同所列出的標準，經初步的系統統調、調整、自測完畢后，提請有關部門或第三方相關單位進行系統性能主、客觀測試，并做出相應系統測試測量數據，做為驗收依據。

二、檢驗、測試、調試、驗收的程序：

1、參與檢驗、測試、調試、驗收人員：

公司質量檢驗人員；設計部門經理；工程部門經理；業主或業主委派的人員；施工單位負責人、或業主聘請的第三方專業測試者。

2、檢驗測試使用文件：

《設備技術規格書》；《檢驗測試記錄表》；《系統設計原理圖》；《系統性能指標》；所引用的標準。

3、檢驗測試內容

幅頻特性；聲場不均勻度；最大聲壓級；傳聲增益；系統總噪聲級：混響時間；主觀聽音：語言清晰、音質良好、無聲缺陷。

4、測量測試儀器（軟件、硬件）

進行統測量測試時，我方參考并提供以下儀器儀表： ? 交流電壓表：上海無線電儀器廠生產 AS-2294A。? 寬帶粉紅噪聲信號發生器：NEUTRIK/Minirator MR1。? 聲場測量傳聲器：KLARK TEKNIK 6501。? 聲級計：FWE 33-2050。

? 傳聲增益測量用擴聲傳聲器：EV ND767a。

? 實時頻譜分析儀：KLARK TEKNIK DN6000、Ivie PC-40 ? 相位測試儀：UNIKA PT-1 ? 專業聲卡：M-AUDIO PRE ? 實時分析測試系統：SIA SmaartLive。? 所需的其它必要儀器、軟件。

5、測試條件

對觀眾廳的聲場，在系統控制器調整后。測量其幅頻特性，聲場不均勻度，最大聲壓級，傳聲增益。其中：測量幅頻特性，聲場不均勻度，最大聲壓級，采用電輸入法。傳聲增益的測量采用聲輸入法。

均衡器已進行系統最佳補償調整；測點聲壓級至少高于總噪聲15dB；系統調整至正常工作狀態，將寬帶粉紅噪聲信號經調音臺送至功率放大器輸入端，各揚聲器最大輸出按生產廠方提供參數設定。

各項測試應在空場和滿場條件下進行，滿場或模擬滿場難以滿足時，可只作空場測試。

第五篇：ERP系統驗收測試流程、方法原則及內容

www.tmdps.cn 全面的ERP資源下載

ERP系統驗收測試流程、方法原則及內容

引言

軟件測試是為了發現錯誤而執行程序的過程。它不僅是軟件開發階段的有機組成部分，而且在整個軟件工程(即軟件定義、設計和開發過程)中占據相當 大的比重。軟件測試是軟件質量保證的關鍵環節，直接影響著軟件的質量評估。軟件測試不僅要講究策略，更要講究時效性。驗收測試作為軟件測試過程的最后一個 環節，對軟件質量、軟件的可交付性和軟件項目的實施周期起到“一錘定音”的作用。

1、ERP驗收測試的現狀

驗收測試是一種有效性測試或合格性測試。它是以用戶為主，軟件開發人員、實施人員和質量保證人員共同參與的測試。ERP(企業資源規劃)作為提 高企業管理創新能力的有力工具，其定義、設計、開發、實施和應用的過程遵循一定的規律。這些規律表現在軟件過程控制、質量保證和軟件測試等方面。驗收測試 關系到ERP能否成功驗收，能否平滑步入維護期，能否快速實現效益。ERP驗收測試的全面性、效率性、科學性、規范性、徹底性在廣大制造業企業和ERP軟 件供應商中還是一個嶄新的話題。

當前很多人對ERP驗收測試工作存在一些誤解：

(1)由于ERP軟件的復雜性、規模性，人們可能更多地關注它多變的需求定義、個性化解決方案、定制化開發過程，卻輕視了項目的驗收工作。這些“只重視開題和過程，不重視結題和維護”的做法，最直接的后果就是，形成了一個個延期工程或“爛尾”項目。

(2)ERP實施工作做好了，用戶企業可以把系統跑起來了，文檔移交了，客戶簽字了，還有什么必要做驗收測試。這種誤解源于對驗收測試的目的、流程、方法和意義缺乏認識。

(3)驗收測試是用戶企業的事，與軟件服務提供商無關。事實上，只有兩者密切配合，才能提高測試效率。

(4)將驗收測試理解成給用戶做演示。驗收測試要講究策略，不是走走過場，而是有計劃有步驟的執行活動，要進行科學的用例設計。

(5)驗收測試就是驗證軟件的正確性。驗收測試和其他的測試一樣，既要驗證軟件的正確性，又要發現軟件錯誤。只不過，驗收測試是以確認軟件功能是否滿足需求為主。

www.tmdps.cn 全面的ERP資源下載

2、ERP驗收測試的流程及方法原則

軟件包括程序、數據和文檔。ERP驗收測試的對象應當含蓋這三個方面。驗收測試的主體要以用戶企業為主，ERP軟件服務供應商積極配合;或以第三方測試為主，用戶和軟件供應商共同配合。

ERP驗收測試的基本流程如下圖所示，軟件實施人員要適時配合和敦促用戶做好驗收測試的各項準備工作，按計劃按步驟執行驗收測試，形成規范的測 試文檔，客觀地分析和評估測試結果，并跟蹤不合格現象，對軟件問題要分級分類管理，必要時要進行回歸測試，確保所有問題能得到關閉，最終成功通過驗收。

在測試方法上，由于驗收階段的特殊性，一般以黑盒測試和配置復審為主，以自動化測試和特殊性能測試為輔，用戶、軟件開發實施人員和質量保證人員共同參與。

ERP驗收測試要注意以下幾個原則問題：

(1)驗收測試始終要以雙方確認的ERP需求規格說明和技術合同為準，確認各項需求是否得到滿足，各項合同條款是否得到貫徹執行。

(2)驗收測試和單元測試、集成測試不同，它是以驗證軟件的正確性為主，而不是以發現軟件錯誤為主。

(3)對驗收測試中發現的軟件錯誤要分級分類處理，直到通過驗收為止。

(4)驗收測試中的用例設計要具有全面性、多維性、效率性，能以最少的時間在最大程度上確認軟件的功能和性能是否滿足要求。

3、ERP驗收測試的內容及用例設計

ERP驗收測試的目的是確認系統是否滿足產品需求規格說明和技術合同的相關規定。通過實施預定的測試計劃和測試執行活動確認軟件的功能需求、性 能需求和文檔需求。ERP是較復雜的大規模性軟件，其驗收測試應當涵蓋確認測試和系統測試兩個方面的內容。具體包括以下測試內容：安裝測試、功能測試、界 面測試、性能測試、文檔測試、負載壓力測試、恢復測試、安全性測試、兼容性測試等。下面結合ERP驗收測試的具體內容，談談用例設計的注意事項。

(1)安裝測試

安裝測試的目的在于驗證軟件能否在不同的配置情況下完成安裝，并確認能否正常運行。ERP安裝測試的用例設計要注意以下幾點：

第一，根據ERP的可移植性，選擇不同操作系統。

第二，選擇不同層次的硬件配置和軟件配置，一般選用最低、中等和最高三種配置進行測試，驗證系統對軟硬件環境的依懶性。

www.tmdps.cn 全面的ERP資源下載

第三，觀察ERP安裝程序在軟硬件資源充足的情況下能否正常安裝，安裝過程中是否給予充足的提示，是否存在流氓軟件的一些弊病，安裝完成后能否正常運行，能否徹底刪除。

第四，在資源不充沛的情況下，如磁盤空間不夠、內容不足等，系統能否完成安裝，能否給予各種提示。

(2)功能測試

功能測試是驗收測試中的主要內容。ERP功能測試要包含以下項目：單個模塊的查詢、增加、刪除、修改、保存等操作;數據的輸入與輸出;數據處理 操作，如導入、結轉等;基礎數據定義的精度;計算的準確性，如倉庫的歷史庫存、當前庫存、貨位庫存是否準確;數據共享能力;身份驗證和權限管理;接口參數 和系統控制參數;單據流轉情況;狀態控制，如系統是否對MPS在執行MRP分解、工單下達、車間任務調度等操作前后的狀態做了標識，狀態的改變是否正確;報表的打印輸出;審批流程定義及各種審批、反審批操作;短信發送及管理;崗位及部門業務的操作，如從請購管理、采購計劃到采購訂單管理，再到采購到貨管 理;跨部門的業務操作，如從銷售訂單到主生產計劃，從車間領料到倉庫出庫等等。

ERP功能測試的用例設計要注意以下幾點：

第一，測試項目的輸入域要全面。要有合法數據的輸入，也要有非法數據的輸入。如，在測試基礎數據的定義時，若規定是數字，則既要輸入數字進行測試，也要輸入字母、空格等非數字進行測試。數字包含整數、負數、小數，因而還要輸入這些不同的數字驗證數字的精度。

第二，劃分等價類，提高測試效率。在考慮測試域全面性的基礎上，要劃分等價類，選擇有代表意義的少數用例進行測試，提高測試效率。如，若MRP 記錄有“剛形成”、“已派工”“正執行”、“已完成”四種狀態，系統只允許對剛形成的MRP記錄做局部性修改或刪除操作，那么在測試時，將MRP記錄劃分 為四類，每種狀態對應一類，每類各選一條記錄作為測試用例即可。

第三，要適時利用邊界值進行測試。如“訂單預排”中一般要求預排的數量大于0，那么測試數據可以分別為0，-1，1，10000000(一個非常大的正數)。

第四，重復遞交相同的事務。

第五，不按照常規的順序執行功能操作。

第六，驗證實體關系，實體間的關系有三種：一對一，一對多，多對多。如，一個MPS對應多個MRP，一個MRP對應多個車間任務。

第七，執行正常操作，觀察輸出結果的異常性。如，刪除某條記錄對排序的影響;執行審批后，單據的狀態是否改變。

www.tmdps.cn 全面的ERP資源下載

(3)界面測試

ERP界面要符合現行標準和用戶習慣。軟件企業可以形成自己的特色，但要確保整個軟件風格一致。界面測試要從友好性、易操作性、美觀性、布局合理、分類科學、標題描述準確等方面入手。測試用例的設計要重點掌握以下幾點：

第一，背景和前景的顏色是否協調，顏色反差是否用得恰當。

第二，軟件得圖標、按鈕、對話框等外觀風格是否一致，美觀效果所要求的屏幕分辨率。

第三，窗口元素的布局是否合理，并保持一致。

第四，各種字段標題的信息描述是否準確。

第五，快捷鍵、按鈕、鼠標等操作在軟件中是否一致。

第六，窗口及報表的顯示比例和格式是否能適應用戶的預期需求。

第七，誤操作引起的錯誤提示是否友好。

第八，活動窗口和被選中的記錄是否高亮顯示。

第九，是否有幫助信息，菜單導航能否正常執行。

第十，檢查一些特殊域和特殊控件能否運行。

(4)性能測試

性能測試主要測試軟件的運行速度和對資源的消耗。通過調整ERP所依賴的軟硬件配置、網絡拓補結構、工作站點數、數據量和服務請求數來測試軟件 的移植性、運行速率、穩定性和可靠性。一般借助WinRunner之類的企業級自動化測試工具來輔助測試，通過極限測試來分析評估軟件性能。

(5)文檔測試

文檔是軟件的重要組成部分，也是軟件質量保證和軟件配置管理的重要內容。文檔測試主要通過評審的方式檢查文檔的完整性、準確性、一致性、可追溯 性和可理解性。ERP作為一個大規模軟件，覆蓋了企業的各種業務。它至少要具備需求定義、開發設計、測試評估、項目管理、用戶應用這五類文檔，具體而言，應包含GB8567-88中規定的14種軟件文檔。

在文檔復審時，要特別注意以下幾點：

第一，要明確文檔驗收的標準，軟件企業和用戶企業要達成一致。

www.tmdps.cn 全面的ERP資源下載

第二，確定文檔的重要性和項目文檔需求，比如，在驗收階段，用戶文檔(用戶手冊、操作手冊、維護手冊、聯機幫助文件)顯得特別重要，需要認真評審。

第三，檢驗文檔完整性，主要是文檔的種類和內容的完整性。

第四，檢驗文檔的一致性和可追溯性，主要是：軟件的設計描述是否按照需求定義進行展開的;應用程序是否與設計文檔的描述一致;用戶文檔是否客觀描述應用程序的實際操作;關于同一問題的描述是否存在不同的說法。

第五，檢驗文檔的準確性，主要是文檔的描述是否準確，有無歧義，文字表達是否存在錯誤。

第六，檢驗文檔的可理解性，主要審核文檔是否針對特定的讀者群體，表達是否詳細。如，ERP操作手冊，除了描述每個模塊的操作，應該還提供關聯性崗位業務、部門業務和跨部門業務的操作說明。

(6)其他測試

除了上述的測試外，還有必要對系統的其他特性和需求加以測試。如檢測軟件遇突發性故障后對數據的恢復能力，軟件的安全保密性和對硬件、軟件、數據的兼容性，系統所能承擔的最大數據量和健壯性等。

其他測試一般包含以下幾種：

第一，負載壓力測試。它主要包括并發性能測試、疲勞強度測試、大數據量測試和速度測試。一般采用自動化技術分別在客戶端、服務器端和網絡上進行測試。用例設計時，要以真實的業務為依據，選擇有代表性的、關鍵的業務操作作為測試對象。

第二，恢復測試。通過模擬硬件故障或故意造成軟件出錯，檢測系統對數據的破壞程度和可恢復的程度。

第三，安全性測試。通過非法登陸、漏洞掃描、模擬攻擊等方式檢測系統的認證機制、加密機制、防病毒功能等安全防護策略的健壯性。

第四，兼容性測試。通過硬件兼容性測試、軟件兼容性測試和數據兼容性測試來考察軟件的跨平臺、可移植的特性。

4、結語

ERP用戶和軟件開發實施人員要明確驗收測試的真正意圖。開發人員和實施人員不應該掩蓋軟件錯誤或不關心用戶不熟悉的測試項目。用戶也不能因為 存在一些當前無法實現的需求而擱置驗收工作。相反，兩者應當精誠合作，相互信任，撥云見日。對于那些不可行的需求或不明確的需求，雙方要協商進行需求變 更，并達成一致意見。只有這樣的驗收測試，才能促使ERP工程項目得以快速圓滿驗收。

www.tmdps.cn 全面的ERP資源下載