1、學習好資料1. 系統測試與驗收方案1.1. 測試方案1.1.1. 單元測試1.1.1.1. 單元測試說明在計算機編程中，單元測試（又稱為模塊測試）是針對程序模塊 （軟件設計 的最小單位 ）來進行正確性檢驗的測試工作。 程序單元是應用的最小可測試部件。 在過程化編程中，一個單元就是單個程序、函數、過程等；對于面向對象編程， 最小單元就是方法， 包括基類（超類）、抽象類、 或者派生類（子類）中的方法。單元測試的目標是隔離程序部件并證明這些單個部件是正確的。 一個單元測 試提供了代碼片斷需要滿足的嚴密的書面規約。 因此，單元測試帶來了一些益處。 單元測試在軟件開發過程的早期就能發現問題。1.1.1.

2、2. 單元測試方法與內容單元測試主要采用白盒測試技術， 用控制流覆蓋和數據流覆蓋等測試方法設 計測試用例；主要測試內容包括單元功能測試、 單元性能測試和異常處理測試等。1.1.1.3. 單元測試流程圖 15-1 單元測試流程圖從配置庫獲取源碼文件，設計測試用例， 執行測試用例，并利用相關測試工具對單元代碼進行測試，將測試結論填寫到單元測試報告和軟件Bug 清單中 更多精品文檔學習好資料把軟件 Bug 清單和測試用例執行結果提交測試負責人， 并進入納入質量管理。 對源碼文件進行的測試， 視程序存在缺陷的情況， 可能要重復進行， 直至問題解 決。單元測試的執行者， 一般情況下可由程序的編碼者進行，

3、 特殊情況可由獨立 于編碼者的測試人員進行。1.1.1.4. 單元測試用例編程組組長組織、指導開發人員根據系統設計說明書，編寫所負責代碼 設計模塊的單元測試用例，設計單元測試腳本。1.1.2. 代碼評審代碼評審也稱代碼復查， 是指通過閱讀代碼來檢查源代碼與編碼標準的符合 性以及代碼質量的活動。評審的內容：1) 編碼規范問題：命名不規范、 magic number、 System.out 等；2) 代碼結構問題：重復代碼、巨大的方法和類、分層不當、緊耦合等；3) 工具、框架使用不當： Spring、Hibernate、AJAX等；4) 實現問題：錯誤驗證、異常處理、事務劃分、線程、性能、安全、實

4、現過于 復雜、代碼可讀性不佳、擴展性不好等；5) 測試問題：測試覆蓋度不夠、可測試性不好等。評審的優點：1) 提高代碼質量：在項目的早期發現缺陷，將損失降至最低2) 評審的過程也是重新梳理思路的過程，雙方都加深了對系統的理解3) 促進團隊溝通、促進知識共享、共同提高更多精品文檔學習好資料1.1.3. 集成測試1.1.3.1. 集成測試目的集成測試， 也叫組裝測試或聯合測試。 集成測試是在單元測試的基礎上， 根 據系統概要設計 及系統集成與開發詳細設計 ，對系統的各單元進行組裝。 把分離的系統單元組裝為完整的可執行的計算機軟件。 集成測試的目的是檢查軟 件單元部件是否能夠集成為一個整體， 完成一

5、定的功能， 并找出單元測試中沒有 發現的錯誤， 包括數據定義有沒有重合與沖突， 接口會不會產生錯誤， 組合以后 的模塊功能會不會互相影響，組合的系統是不是達到預期的效果等。1.1.3.2. 集成測試采用的方法和內容集成測試采用白盒測試和黑盒測試相結合的測試技術和漸增式的測試策略， 用數據流等測試方法設計測試用例。 主要測試內容包括單元之間的接口測試、 全 局數據結構測試等。1.1.3.3. 集成測試流程集成測試包括集成測試設計、 集成測試準備、 集成測試實施和測試記錄、 集 成測試問題跟蹤和結束測試等階段。集成測試設計由測試組組長根據項目計劃和開發計劃編制 集成測試計劃 ， 設計測試用例。測試

6、計劃和測試用例應當通過項目經理的審查。集成測試準備需要系統測試組組長建立獨立的測試環境。 測試環境包括測試 硬件環境、網絡、數據庫、應用服務器等以及測試對象 （程序 ）的安裝和初始化工 作。集成測試實施和測試記錄是由系統測試組組長組織人員按照測試計劃和測 試用例要求進行測試，并且記錄測試過程和測試結果。集成測試問題跟蹤是在測試過程中發現的問題由系統測試組組長根據測試 更多精品文檔學習好資料記錄提交測試問題報告，并由系統設計人員和開發人員解決每一個問題的過程。測試結束指測試問題報告中的問題解決后， 進行回歸測試。 當測試問題降低 到一定程度并通過測試通過準則時， 系統測試組組長提交測試總結報告結

7、束測試。1.1.4. 功能測試功能測試包括兩大部分， 一是包括基本業務功能、 業務測試、 接口測試和可 用性測試等方面的功能測試，二是包括：安全性測試、故障恢復測試、數據庫測 試、配置測試、安裝測試的產品化測試。 驗收測試主要從系統的實用性、 穩定性、 可維護性、靈活性、可操作性、和安全性方面進行測試。（1）測試目標組織并執行測試，以降低軟件產品中存在的缺陷， 保證產品的質量和可用性， 測試工作的目標就是降低 BUG率，從各個方面提高軟件產品的質量和可用性。（2）測試流程在確定具體的測試范圍及內容后， 進行測試分類， 并根據分類的結果確定需 要設計的測試用例。在整個測試過程中， 我們將用缺陷管

8、理工具 BugBase對測試大綱、測試用例、 測試問題等進行管理，并可對問題進行統計。（3）測試完成標準實現功能完全符合功能列表。所有的功能頁面均可達。 TD上的問題得到妥善處理，不含有 A,B,C類問題。 定義的測試項目完成。產品化測試的約束達成。（5）缺陷管理追蹤工具在上節描述中提到的 TD，可以應用于測試的全過程，也可以用于管理各類更多精品文檔學習好資料評審的缺陷等。TD 還提供一些模板，例如測試計劃、測試總結、測試大綱、測試問題卡， 因此可以通過 BugBase實現從測試計劃到總結的各測試活動管理。我們以需求說明書、 軟件需求規格說明為輸入編寫測試大綱， 對應測試大綱 中的內容和測試需

9、求編寫測試用例， 測試人員可以根據測試大綱和用例執行測試， 發現問題后，記錄在 TD 中，測試負責人通過查看缺陷問題列表將問題分配給對 應的開發人員，開發人員通過查看問題列表修改問題， TD 還提供了各種統計功 能，例如根據問題的發現日期、問題等級、問題的分布、問題引入階段等進行統 計，這些統計結果可用來進行分析和總結1.1.5. 性能測試性能測試總體流程與業務系統測試的流程基本相同。 驗收測試主要從系統的 實用性、穩定性、可維護性、靈活性、可操作性、和安全性方面進行測試。性能 測試的內容源于用戶對平臺系統的性能要求。1.1.5.1. 測試目標性能測試的目標是在整個系統或一個系統的特定組件上定

10、義、 建立和執行性 能測試。驗證系統是否滿足標書的性能要求，如不能滿足，要進行相應的優化。1.1.5.2. 測試流程首先對性能測試進行策劃，確定性能測試的類別和測試方法。然后開發性能測試的用例， 確定測試環境并準備就緒后執行性能測試， 確定 測試中的系統或組件的性能， 并使用其結果決定性能是否可以被業務所接受。 如 果在測試中度量的性能特性證明是不能被接受的，我們可以通過對業務的改進、 數據庫、應用服務器等進行調優，以提高性能質量，在進行系統調優前，我們同 樣要進行調優的設計與分析。 性能測試與應用和技術架構緊密相關并且兩者互相 影響。更多精品文檔學習好資料1.1.5.3. 性能測試指標a)

11、響應時間響應速度在用戶心理所能承受的范圍內。 無論是客戶端還是管理端， 當用戶 登陸，進行任何操作的時候， 系統應該及時進行反映， 系統應能檢測出各種非正 常情況，并及時提示用戶。b) 可擴展性在設計上必須具有適應變化的能力， 當系統新增業務功能或現有業務改變時， 應保證業務在整體框架不變的基礎上，業務變化造成的影響局部化。c) 易用性所有的業務功能界面風格和操作流程一致， 業務表單做到所見即所得， 錄入 能夠完全通過鍵盤完成。d) 可靠性系統應保證 7*24 小時內不宕機，保證在正常情況下和極端情況下業務邏輯 的正確性。e) 可用性必須避免由于單點故障或系統升級而影響整個系統的正常運行。f)

12、 可維護性系統能夠簡單方便的修改和升級，包含可度性、可修改性、可測試性等。g) 可管理性和服務支持能力每個層次、每個構件都提供標準的管理接口。 實現統一的、一致的日志功能。 每個構件都提供應用架構總體設計規定的必要的標準外部接口。更多精品文檔學習好資料1.1.6. 用戶測試1.1.6.1. 測試流程用戶測試流程如下：1）明確測試內容，其中包括功能、性能、可用性、安全性、兼容性、與其他系 統集成2）確定測試范圍：確定業務情況類型是是非常重要的。每一種業務情況類型都 對應一個實際商業業務。 業務情況類型可以被表達成多種狀況 （例如，簡單情況、 或需要進行復雜處理的例外情況）。3）測試小組成員確定：

13、由管理人員、業務人員、技術人員等組成，我方提供驗 收測試過程中的技術支持。4）明確問題分類標準5）系統的功能通過功能測試進行驗證。 在功能測試過程中發現的問題根據其嚴 重程度進行分類。下表列出了功能測試問題的分類。1.1.6.2. 用戶測試設計設計測試用例： 確定每個功能的測試用例， 明確系統輸入信息和期望的輸出 結果。針對需求規格說明書的每一條測試內容， 確定測試用例。 每個測試用例包 括測試條件（包括生成測試條件需要的測試數據類型） 和期望的結果。 每個測試 用例都應該是唯一確定的（例如，賦一個數值）。設計測試大綱： 依據測試范圍生成測試大綱。 對每一種業務情況類型， 生成 盡可能多的測試

14、用例來完善測試大綱。為了保證測試大綱包含所有的測試用例， 將測試用例的條件映射為測試大綱是非常必要的。 測試大綱中測試用例的順序安 排是非常重要的， 它應考慮多種方面的因素， 主要考慮的因素是按照系統產生的 數據，在測試大綱中安排測試用例的順序， 使得一個測試的結果作為另一個測試 前提。更多精品文檔學習好資料測試環境準備： 為了預防出現問題， 如數據損壞或對系統資源的爭用， 需要 建立一個獨立的測試環境。 在進行測試之前， 根據測試計劃中確定的時機建立一 個獨立的測試環境。1.1.6.3. 用戶測試結果1) 測試結束后，測試小組根據測試數據，制定并向驗收工作領導小組提交用 戶測試報告。2) 測

15、試報告結果說明軟件滿足下列要求：3) 在認可的外部設計文檔中表述的功能要求4) 在認可的系統描述文檔中表述的非功能要求5) 此外，測試報告中還包括對系統提出的改進意見。1.1.7. 測試產出1) 測試計劃2) 系統測試方案3) 測試用例4) 系統測試案例5) 系統測試報告6) 試運行測試報告1.2. 驗收方案1.2.1. 驗收流程在驗收階段，平臺系統將按照用戶和我公司都認可的系統需求分析，組 織驗收小組，進行功能和性能的驗收測試。 從系統的實用性、 穩定性、可維護性、 靈活性、可操作性、和安全性及系統文檔、代碼、規范及注釋說明等方面組織全 更多精品文檔學習好資料 面驗收。驗收測試安排分為系統初

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

17、運行周期不超過三個月。 在試運行期間， 我公司按用戶要求提供培訓和技術支持， 保證用戶能夠正確理解 和使用系統；我公司對試運行中出現的任何問題及用戶提出的修改意見將及時做 出響應，并提交解決方案，在用戶確認后實施。試運行期間如出現重大故障，則 試運行期從故障排除之日起重新計算。1.2.4. 系統終驗試運行期結束后， 如系統無功能缺陷， 能夠正常運行， 在具備終驗條件下進 行系統終驗， 由我公司提出終驗書面申請， 用戶在收到我公司驗收申請后， 盡快 組織系統終驗。成立項目全面驗收小組，由用戶、我公司以及外部專家等組成， 對項目進行全面驗收。系統終驗前，我公司提交終驗測試標準和終驗測試計劃， 內容

18、包括： 測試對象及應達到的測試指標、 測試方法和測試條件、 測試資料和數 據，并以圖表說明每一測試對象或過程的功能輸入輸出測試進度。系統終驗標準：1) 系統實用性：項目驗收最關鍵的指標，檢查系統是否符合當前業務的需 更多精品文檔學習好資料 要，特別是業務流的整體性和數據流的一致性，并前瞻性提供未來業務接口。2) 系統穩定性：硬件環境的穩定性、軟件運行異常處理和正常運行情況。3) 系統可維護性：含網絡系統管理與維護、服務器系統平臺管理與維護、 操作系統管理與維護、 應用系統軟件管理與維護、 數據庫管理與維護以及數據庫 備份、應用系統備份，災難事件處理與解決實施方案等。4) 系統文檔：驗收文檔是否

19、齊全、規范、準確、詳細，主要的文檔包括： 需求分析報告，框架設計報告，數據庫物理及邏輯設計報告，詳細設計報告，編 碼規范及技術選型報告，測試報告，系統部署和發布報告，集成方案，軟件用戶 使用手冊，系統維護方案和操作文檔等。5) 代碼規范及注釋說明：程序代碼編寫是否規范；注釋說明或代碼文檔是 否詳細全面；接口定義是否符合局信息系統規劃一致性的要求。6) 系統靈活性：系統是否方便客戶進行維護；系統是否在先進性的基礎上 具備未來升級和可擴充性；是否利于系統平臺遷移和部署等。7) 系統可操作性：界面是否友好性；是否實現傻瓜化操作和智能化數據檢 索功能。8) 系統安全性：是否有完善的安全機制保證系統的安全性，如軟件方面的 安全防范(加密措施、相關認證、數據庫安全防范)，硬件方面(防火墻、物理 隔離和邏輯隔離)的安全設置。9) 其他驗收標準：其他