測試方案和測試報告精選(九篇)
前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的測試方案和測試報告主題范文，僅供參考，歡迎閱讀并收藏。
第1篇：測試方案和測試報告范文
關鍵詞 繼電保護；測試技術；應用
中圖分類號：tm774 文獻標識碼：a 文章編號：1671—7597（2013）051-054-01
在很長的一段時間里，我國的電力系統大都是采用移相器、調壓器、滑桿電阻等來調整三相電壓和三相電流的幅度和相位大小，以達到對各種繼電保護裝置進行調試的目的。在這個調試的過程中，同時還需要極其精密的電壓表、電流表、相位表、頻率計以及毫秒表等儀器設備完成對于試驗所需物理參量的讀取，整個過程的操作較為復雜，并且對于所測量物理量的精度要求較高。采用這種傳統的測試方法，一方面設備的搬運工作極其艱巨、設備占用空間大，并且在測試過程中需要人工反復記錄實驗數據。這種傳統的方法不但調試的技術落后、測試過程復雜、測試誤差較大，而且還會在測試過程中消耗大量的人力物力。伴隨著目前新型繼電保護裝置的應用，基于計算機的自動測試技術已經成為繼電保護設備測試不可或缺的一部分。
1 繼電保護測試技術的發展
繼電保護測試技術主要經歷了組合型試驗裝置、集成電路型試驗裝置以及數字控制型試驗裝置。其中組合型的試驗裝置是將各個物理參數通過不同的裝置分別進行測量，然后將測量結果進行組合，得出繼電保護的測量結果，是一種傳統的試驗裝置；集成電路型試驗裝置是在組合試驗裝置的基礎上，采用集成電路芯片對測試裝置進行控制，并且采用數碼顯示的方式，提高了測試數據讀取的準確性和簡便性；數字控制型試驗裝置主要是利用單片機的計算存儲功能，并且具有一定的用戶交互界面，是繼電保護測試技術的重要發展。
基于計算機的繼電保護測試裝置由人機對話設定輸入電流、電壓參數值，并且通過程序控制信號源實現對電子線路、數模轉換、功率放大等功能，并且向繼電保護裝置輸出具有一定功率值的三相電流、電壓源，同時能夠接受來自繼電保護裝置的反饋信息，并且根據預先設置做出一系列的響應，對結果進行詳細的記錄，同時能夠將測試的結果以文字或者圖標的形式進行打印，真正的實現自動化測試的目標。
2 繼電保護自動測試系統的功能及應用
2.1 繼電保護自動測試系統的功能
目前的繼電保護自動測試系統可以實現的功能主要有以下幾個方面。
1）根據實際的繼電保護測試需要進行測試，并且能夠保證測試數據信息的準確性。這也是繼電保護自動測試系統最基本的功能，是實現其他功能的基礎。
2）實現在檢點保護測試中的良好人機交互界面。在實際的繼電保護測試過程中，操作人員可以根據測試系統交互界面的提示進行操作，并且可以按照系統給出的提示信息判斷測試的過程是否合理以及測試的結果是否在誤差范圍內，可以有效的降低測試的難度和復雜度。
3）實現整個測試過程的自動化處理。在整個繼電保護測試過程中，自動化測試系統可以在無人值守的情況下完成測試的全部流程，并且最終到處需要的測試數據。整個測試過程，只需要操作人員對門限定制進行設定和確認，減少了人員的工作強度，也從根本上提高了繼電保護測試的精確度。同時降低了對操作人員的要求，降低了測試的成本。
4）自動化生成所需要的檢測數據和檢測報告。繼電保護自動檢測系統能夠根據預先設定的需求，自動的在檢測過程完成后到處測試的數據，并且可以生成完整的測試報告，真正的實現了整個測試過程的自動化，節約了操作人員用于編寫測試報告以及整理的時間。
2.2 繼電保護自動測試系統的應用
繼電保護自動測試系統的具體應用主要包括后臺軟件的啟動、測試模板的導入、測試過程以及繼電保護裝置的啟動。其實現過程如圖1所示。
3 繼電保護測試技術應用的意義及其要求
3.1 繼電保護測試技術應用的意義
繼電保護自動測試技術的應用能夠大幅度改善了繼電保護測試，是對目前的繼電保護測試思路的重大突破和創新，它的應用能夠有效的提高繼電保護測試的精確的，提高繼電保護測試的自動化水平，較少測試過程中人員的直接參與，可以從根本上減小繼電保護測試的誤差。同時，繼電保護的自動化測試技術能夠實現對于測試
結果的自動化處理，并且可以根據操作人員的要求生成完整的測試報告，這能夠大幅度的提高繼電保護測試的工作效率，降低整個測試過程中的成本消耗。從繼電保護測試過程到測試報告的自動生產都實現了高度的自動化，也是目前繼電保護測試技術發展的趨勢。
3.2 繼電保護測試技術的要求
在繼電保護測試過程中，為了更好的保證測試結果的準確性，進一步提高繼電保護測試系統的工作效率，需要在測試過程中注意以下幾個方面的問題。
1）在確定測上方案前需要對測試方案進行多次可行性分析。由于整個測試過程都是在自動化模式下完成的，因此，測試方案一旦確定就無法進行更改，錯誤的測試方案會導致嚴重的后果。需要在測試方案的確定前組織相關的人員進行多次方案的可行性論證，確保方案的可行性。
2）加強員工模板導入技術的培訓。在整個繼電保護自動化測試系統中，唯一需要操作人員的步驟就是方案模板的導入工作，這也是最為關鍵的一步。因此，要做到操作人員對于模板導入工作的培訓，并且需要在正式上崗操作前進行嚴格的考核，切實保證測試數據的準確性。
4 結束語
繼電保護自動測試技術的應用是對繼電保護測試的重要技術革新，能夠有效的提高繼電保護測試的精度。同時，繼電保護自動測試技術能夠降低對于操作人員的素質要求，能夠降低企業的成本。因此，在繼電保護測試中要加大自動化程度的開發力度，更進一步提高測試的精度。
參考文獻
第2篇：測試方案和測試報告范文
關鍵詞：軟件測試；性能測試；LoadRunner
中圖分類號：TP306 文獻標識碼：A 文章編號：1672-3198(2009)12-0296-02
1 軟件性能測試
根據測試的目的和內容的不同，性能測試主要包括以下方面：
(1)負載測試：確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。
(2)強度測試：確定在系統資源特別低的條件下軟件系統運行情況。
(3)容量測試：在用戶可接受的響應范圍內，確定系統可處理同時在線的最大用戶數。
(4)壓力測試：通過確定一個系統的瓶頸或者最大使用極限的測試。
(5)疲勞強度測試：以系統穩定運行情況下能夠支持的最大并發用戶數或者日常運行用戶數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作強度性能的過程。
(6)大數據量測試：大數據量測試側重點在于數據的量上，包括獨立的數據量測試和綜合數據量測試。獨立的數據量測試針對某些系統存儲，傳輸、統計、查詢等業務進行大數據量測試，而綜合數據量測試一般和壓力性能測試、負載性能測試、疲勞性能測試相結合。
2 軟件性能測試流程
2.1 測試方案設計
在軟件性能測試的初始階段，首先應對業務模型和系統架構進行調研，收集測試需求。然后生戚性能測試計劃。業務調研和系統調研，需要性能測試團隊提前了解被測試項目的業務功能和系統架構。其間。開發部門應協助提供被測系統相關的文檔和說明，如系統總體介紹、系統規格書、用戶使用手冊、網絡拓撲結構圖和系統配置說明、關鍵服務器及應用部署與配置等文檔。通過和業務部門協商明確本次測試針對哪些業務行為，制定此次測試的目標，細化測試的關注點和性能指標要求。通過以上內容制定詳細的測試方案，并制定詳細測試計劃和各階段目標。
2.2 測試環境的搭建
測試環境的搭建分為軟硬測試系統的環境搭建和測試相關的數據準備工作。環境搭建包括被測試系統的硬件環境建立和軟件應用系統建立及基礎數據環境建立。保障被測試系統的業務可用性和功能的正確性，包括測試系統(如被測試項目的操作系統、中間件、數據庫、壓力測試控制臺、壓力測試發起工具等)的環境搭建、軟件的安裝；測試環境的網絡環境建立(如開放防火墻和網關等)；最后進行測試環境可用性驗證。測試數據準備包括測試應用系統基礎數據準備，即需要按性能測試規模要求，準備足夠的、一定規模的基礎數據，通常采用全量恢復生產數據的方式以達到和生產環境數據一致性的要求。
2.3 測試場景開發
測試場景開發指測試程序(腳本)的開發。測試程序(腳本)的開發是對被測系統的用戶業務行為進行模擬、錄制、編程、參數化、腳本定制和調式等一系列工作，以使測試程序(腳本)可以真實模擬實際生產中的業務交易行為，并通過對程序中參數的配置實現對并發數、思考時間等屬性的準確控制。
2.4 測試執行
測試執行是在測試方案的制定、測試環境準備、測試場景開發工作正確完成的基礎上進行的。
2.5 測試報告和分析
性能測試報告和結果分析是在測試執行完成以后，對性能數據進行采集結果收集工作和針對性能測試過程中暴露的問題進行分析的階段。性能測試報告是對性能測試過程中的監控結果以及報表進行匯總，按照一定的模板整理出的一份結論性文檔。開發團隊和性能測試團隊應依據對性能測試實施過程中監控和記錄的數據和表格，分析系統中存在的性能問題和程序缺陷。并有針對性的在報告中闡述問題、分析原因、提出解決或優化方案。
2.6 回歸測試
回歸測試是開發部門在性能測試報告的基礎上針對軟件的性能或者效率缺陷進行優化或者修復，為了驗證優化的效果而進行的再測試。
3 軟件性能測試工具LoadRunner
作為軟件質量控制中的重要一環，性能測試已經越來越受到軟件開發商和用戶的重視，成為軟件測試的重中之重。性能測試通常在系統測試階段執行，常常與強度測試結合起來，一般需要使用測試工具。一個優秀的軟件測試工具，不僅可以輔助測試工作，滿足科學測試的基本要求；而且可以自動化測試過程，節約大量的時間、成本、人員和資源，提高軟件產品的質量。目前市場上主要使用的測試工具有微軟公司的WAS(Web Application Stress Tool)、Compuware公司的QALoad、RadView公司的WebRunner、HP(Mercury)公司的LoadRunner。下面以LoadRunner為例。介紹軟件測試工具的工作流程。
LoadRunner是一種預測系統行為和性能的負載測試工具。通過模擬上千萬用戶實施并發負載及實時性能檢測來確認和查找問題，能夠對整個企業架構進行測試。通過使用LoadRunner，企業能夠最大限度的縮短測試時間，優化性能和加速應用系統的周期。LoadRunner能支持廣泛的協議和技術，功能比較強大，可以為特殊環境提供特殊的解決方案。LoadRunner由下面三部分組成：Virtual UserGenerator用來錄制腳本、編輯腳本Controller用來布置測試場景、執行測試場景；Analysis用來對測試結果進行分析。
用LoadRunner進行負載測試的流程通常由五個階段組成：計劃、腳本創建、場景定義、場景執行、監視執行和結果分析。
(1)計劃負載測試：定義性能測試要求，例如并發用戶的數量、典型業務流程和所響應時間；根據軟件項目相關需求，定義相關測試的細節，撰寫性能測試報告。
(2)創建Vuser腳本：將最終用戶活動捕獲到自動腳本中LoadRunner的腳本是C語言代碼，LoadRunner有自己的一整套函數接口，可以供外部調用。腳本可分INIT、ACTION、END三部分，其中：INIT部分可以理解為初始部分。ACTION可以理解為事務部分，也是測試的主體，END是退出結束。
當錄制完一個基本的用戶腳本后，在正式使用前我們還需要完善測試腳本，增強腳本的靈活性。一般情況下，我們通過以下幾種方法來完善測試腳本。插人事務、插入結合點、插入注解、參數化輸入。
(3)定義場景：使用LoadRunner Controller設置測試環境；錄制好腳本之后，就可以把腳本加入到場景里面去了，這里首先介紹一下LR的場景類型，LR有2種大的場景類
型。
①Manual Scenario：該項要完全手動的設置場景，這項下面還可以設置為每一個腳本分配要運行的虛擬用戶的百分比，可在Controller的Scenario菜單下設置。
②Goal―Oriented Scenario,如果你的測試計劃是要達到某個性能指標，比如：每秒多少點擊。每秒多少transae，tions，能到達多少VU，某個Transaction在某個范圍VU(5D。一1000)內的反應時間等等，那么就可以使用面向目標的場景。
(4)設置場景：
Design：設計測試場景的靜態部分，設置模擬用戶生成器、模擬用戶數量、模擬用戶組等。
Run：設計測試的動態部分，主要指添加性能計數器，在腳本運行的過程中可以通過這些計數器反饋的數據。
建立了測試場景后，我們可以對Edit_Schedule進行設置，設置測試開始執行的時問，對于手動設計的測試還可以設定它的持續時間，以及何時起用或禁止調用模擬用戶。
(5)運行場景：通過LoadRunner Controller驅動、管理和監控負載測試。
設置完畢后，點擊“開始方案”運行場景。在運行過程中，可以監視各個服務器的運行情況(DataBase Server、WebServer等)。監視場景通過添加性能計數器來實現，下列數據需要特別關注：
①Memory：Available Mbytes物理內存的可用數(單位Mbytes)至少要有10％的物理內存值。
⑦Processor：Processor Time CPU使用率。這是查看處理器飽和狀況的最佳計數器。顯示所有CPU的線程處理時間。如果一個或多個處理器的該數值持續超過90％，則表示此測試的負載對于目前的硬件過于沉重。為多處理器服務器添加該計數器的O到x個實例。
③Processor Queue Length：是指處理列隊中的線程數，小于2。處理器瓶頸時會導致該值持續大于2。
④Context Switches/sec；如果切換次數到5000*CPU個數和i0000*CPU個數中，說明它忙于切換線程。
⑤Network Interface：Bytes Total/sec為發送和接收字節的速率，包括幀字符在內。判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較。
第3篇：測試方案和測試報告范文
關鍵詞：RFID；自動測試；數據庫；物聯網
中圖分類號：TN92 文獻標識碼：A 文章編號：2095-1302（2016）11-00-02
0 引 言
隨著物聯網產業的發展日益壯大，無線射頻識別（Radio Frequency Identification，RFID）技術已經在人們的日常生活中得到廣泛應用，其測試與檢測技術也在不斷發展與完善。為了滿足逐步增長的批量檢測需求，提高測試人員的工作效率，保障測試結果的準確性和可重復性，RFID自動測試系統也成為研究熱點之一。
RFID自動測試系統的主要功能是提供RFID射頻指標的自動測試，通過計算機軟件實現對測試設備和被測設備的高效控制，模塊化軟件設計使得測試流程集成化，可最大程度的降低測試人員的工作量與操作復雜度[1]。
1 系統介紹
RFID自動測試系統的主體是測試軟件。該測試軟件具有自動控制測試設備、數據采集、數據分析處理和生成報告的功能。測試軟件可以與測試設備、被測設備的控制軟件通信，自動讀取儀器型號、軟件版本、選件版本、儀器基本設置等信息，還可調用或驅動測試設備、被測設備的控制軟件，測試人員可以方便的在測試軟件上直接對測試設備與被測設備的控制軟件進行設置并發送命令。測試軟件中預置了常規RFID測試模板，用戶可以根據測試需要編輯測試模板，調用、組合預設的測試項目，靈活定制測試計劃。在測試過程中，測試人員可以同步在測試軟件的界面上看到測試結果并保存。數據庫中記錄了所有測試信息，可以方便的查詢瀏覽。測試結束后，系統自動生成測試報告供測試人員瀏覽與打印。
RFID自動測試系統的基本情況如下：
（1）硬件：計算機、泰克實時頻譜分析儀RSA3408A、GPIB卡、射頻電纜、衰減器及其他測試配件。
（2）軟件：RFID自動測試系統軟件、泰克實時頻譜分析儀控制軟件RSAVu、Agilent IO libraries套件、讀寫器控制程序。
（3）測試項目：輸出頻率、輸出信號頻譜模板、載波頻率容限、占用帶寬、發射功率、鄰道功率泄漏比、雜散發射、最大駐留時間、讀寫器數據編碼、射頻包絡、前同步碼和幀同步。
2 系統結構
計算機通過GPIB總線、網線與RSA3408A頻譜儀相連。其中，頻譜儀與頻譜儀控制軟件通過網線通信，頻譜儀與自動測試系統通過GPIB總線通信。讀寫器通過控制線路與計算機相連，控制線路可以是網線、串口通信線等。讀寫器天線的輸出端口通過射頻線纜、衰減器與頻譜儀的射頻輸入端相連。
RFID自動測試系統硬件連接圖如圖1所示[2]。
3 軟件設計
RFID自動測試系統采用通用的small talk模型，分為表示層、控制層、數據層。
（1）表示層為顯示邏輯部分，實現與測試人員的交互功能；
（2）控制層為事務處理邏輯部分，進行控制命令發送和數據接收、處理；
（3）數據層為數據存儲邏輯部分，主要功能是數據的存儲和讀取[3]。
RFID測試系統的軟件包含以下部分：
（1）測試軟件。在開發過程中，表示層和控制層作為系統的應用軟件聯合開發，能夠控制關聯的其他程序如頻譜儀控制軟件、讀寫器控制程序等，還可實現與用戶的交互功能。
（2）數據庫。數據庫即邏輯模型中的數據層。用以存儲測試模板、測試項目、測試參數等基本信息和測試數據。
（3）必需組件。鏈接軟件與數據庫的動態鏈接庫、與儀器控制軟件之間交互的測試驅動程序等。
模塊設計以及調用流程如圖2所示。
根據系統要求，測試系統的前端軟件，即界面部分的開發工具采用.NET Framework與C#，后臺數據庫采用小型數據庫Access。程序驅動采用C#封裝儀器廠商提供的遠程控制命令，并采用Agilent公司的IO library進行GPIB控制。這樣可以避免程序接口與測試主程序不兼容的問題。RFID自動測試系統的流程圖如圖3所示。
4 數據庫設計
數據庫是整個系統的核心部分之一，負責存儲預置的測試模板，其中包含默認的測試項目、測試參數、性能指標等信息，在測試過程中存儲測試數據和經過數據處理的測試結果，支持測試人員對各類信息的查詢、瀏覽與調用。
數據庫的建模通常由實體關系圖（E-R圖）入手。E-R圖是指以實體、聯系、屬性3個基本概念概括數據的基本結構，從而描述靜態數據結構的模式。
在RFID自動測試系統中，軟件定義的主要數據如下：
（1）測試項目表
內容：存放所有測試項目，每個項目都有對應編號。
說明：分為兩張表，一張存放主測試項目，一張存放子測試項目，兩者之間通過編號可以相互查詢與對應。
主鍵：項目序號。
（2）性能指標表
內容：用上下限的方式存放測試數據的最大允許誤差或性能指標。
說明：每個測試子項目的最大限值與最小限值分兩列保存。對于同一個測試子項目，不同制造商的指標可能各不相同，即使同一制造商生產的儀器因型號不同，裝載了不同選件，其性能指標也可能不同，需要編號分別存儲。
主鍵：無。
（3）被測儀器信息表
內容：記錄設備制造廠商、型號規格、出廠編號、控制軟件版本、選件版本等信息。
說明：該表的數據內容一部分可以通過儀器控制程序直接讀取，一部分需要測試人員在測試界面直接輸入。儀器的制造商、型號、選件版本等和儀器的性能指標表相關聯。
主鍵：出廠編號。
（4）測試參數信息表
內容：記錄各測試項目在測試時設置的參數名稱與限制要求。
說明：與測試項目表相關聯，每個大項建立一張表格，大項包括許多子項目，子項目的名稱放入參數信息表中。測試項目的參數表格中放置測試的設置信息，例如雜散測試中存放起始和終止頻率范圍，鄰道功率泄漏比中存放主信道和相鄰信道的頻譜寬度。當程序運行到所選的測試項目界面時，被選中的測試項目的參數信息會顯示出來并賦值給相應的變量。
主鍵：無。
（5）測試報告記錄表
內容：記錄生成的測試報告信息，包括報告編號、測試環境、測試設備等。
說明：生成報告時需要測試人員填寫報告的基本信息。
主鍵：報告編號，每生成一份，自動加1。
（6）測試結果XML表
內容：XML表中記錄設備的制造商信息、測試日期、測試結果。測試結果包括合格判定，即測試通過/未通過。
說明：每臺設備的測試數據生成一個XML格式表格，保存在XML結果文件夾中。XML表由兩層書簽構成，第一層書簽記錄測試基本信息，第二層書簽記錄測試項目的結果數據。標簽的屬性值記錄測試項目是否通過。
主鍵：XML文件無主鍵。
5 結 語
本RFID自動測試系統可以自動完成對大部分射頻指標的測試工作，提高測試人員的工作效率，降低測試復雜度，保證測試結果的準確性與可重復性。此外，模塊化的軟件設計還具有擴展性強，可移植性高等優點，根據檢測任務的需要，還可以擴展連接更多的測試設備，進一步擴展測試項目。
參考文獻
[1]劉巖.RFID通信測試技術及應用[M].北京：人民郵電出版社，2010.
第4篇：測試方案和測試報告范文
關鍵詞：軟件測試；項目實訓；實踐教學；人才培養
作者簡介：吳夢麟（1982-），男，江蘇南京人，南京工業大學電子信息與工程學院，講師。
中圖分類號：G642.44 文獻標識碼：A 文章編號：1007-0079（2013）14-0126-02
近年來，隨著中國內需市場的增長和國內外外包企業的合作加深，我國的軟件外包行業得到了迅速發展。軟件測試作為軟件外包的主營業務之一，是加快軟件企業與國際接軌，實現產品國際化的重要手段。隨著軟件開發流程的系統化和規范化，我國軟件企業對軟件測試的需求逐步增大，因此高校計算機專業中的軟件測試人才具有良好的就業前景。
由于軟件測試工作的特殊性，需要從業者不僅掌握一定的軟件技術，同時也要對軟件測試的方法和流程具備相當的經驗。通過高校教育培養出來的計算機專業應屆畢業生，雖然能夠掌握基本的軟件開發技術和軟件測試理論，但是缺乏實際的測試經驗和相應的行業背景知識，離企業的需求尚有一定的差距。目前高校計算機專業中軟件測試教學仍以理論為主，實踐動手能力和項目背景經驗的培養相對不足，這些矛盾導致學生就業時很難適應企業的用人要求，企業也必須對招入的應屆畢業生進行培訓，花費相當的人力和物力。
項目實訓是解決高校和企業之間供需矛盾的有效手段。在日常教學計劃中引入項目實訓，以實際測試任務為驅動，按照企業規范進行流程管理，讓學生掌握測試過程中各階段的技能，理論聯系實踐地接受企業化的鍛煉。通過實訓課程，使學生不但能夠學習到實際測試經驗，而且能夠增強團隊意識，進一步縮小畢業生與職業測試工程師之間的差距。
一、軟件測試項目實施
1.測試項目簡介
本文所述的軟件測試實訓項目是基于校企共建模式，由南京工業大學（以下簡稱“我校”）軟件外包實驗室提供軟件測試的場所和專用的硬件設備，從合作的軟件公司引入相應的測試平臺、管理流程和測試報告文檔的測試項目。
本項目的內容是針對前期開發的教師管理系統進行測試。該系統是教學部門的業務管理支撐系統，測試主要圍繞教師信息的查詢和更新操作的管理。通過對這些功能模塊的測試，增強系統的易用性、穩定性、可配置性，消除信息孤島，進一步提高數據信息的應用水平。
在測試環境搭建過程中，服務器的軟硬件配置要與該系統的實際運行環境保持一致。對于測試計劃、測試方案和測試用例等文檔的修改、更新操作，則采用svn版本管理工具來進行控制。學生可以通過svn服務器平臺，按照進度提交每日的測試用例文檔，并填寫日志記錄測試進度和每天的測試工作。
2.實訓計劃和人員管理
軟件測試實訓安排在我校外包實驗室中進行，采用與企業相同的管理模式集中訓練，由相關教師和企業工程師來指導測試流程。測試團隊的成員來自于我校電子與信息工程學院計算機專業的大三、大四學生，以及對軟件測試感興趣的相近專業的學生。這些學生具備基本的軟件編程能力，并且對測試的基本理論有一定的了解。根據學生自身水平和對項目的熟悉程度，可以將其劃分為不同角色，其中包括開發人員和測試人員。開發人員由原來參與系統開發的部分學生擔任。測試人員可以分成不同的小組測試不同的模塊，每個小組設置一個測試組長，負責測試項目管理，其余組員則負責執行測試用例，各小組都有一名教師作為指導教師，控制模塊的測試進度。整個測試實訓項目安排在假期進行，用時半個月，每天工作8小時。每天早晨由測試組長安排當天的測試任務，并對前一天的測試結果進行總結。在每個時間節點，由指導教師和小組成員對相關測試文檔進行評審。
3.測試項目進程
本項目的實際流程圖如圖1所示，在項目初始階段，擔任開發人員角色的學生敘述產品需求和業務流程，為編寫測試計劃做準備。該測試項目主要分為5個階段：測試計劃制定、測試方案編寫、測試用例設計、多輪系統測試和測試系統報告提交。每個階段都力求達到規范化、細致化的測試目標，同時每個階段都要經過教師和各個組員之間的評審，如果評審通過，可以開始下一階段的工作；如果不通過，則需要完善后繼續評審直到通過。
（1）測試計劃制定。在了解了教師管理系統的需求以后，結合學生的基本情況、系統模塊數量和測試的周期來制定測試計劃。測試計劃要涵蓋測試的范圍和環境、測試人員的管理和測試進度安排。考慮到參與實訓項目的學生缺乏相關經驗，因此測試計劃要重點突出每個測試小組所對應的系統模塊，以及測試流程中每個階段所對應的完成日期。該測試計劃由各組組長和指導教師制定，最后需各小組評審后通過。
（2）測試方案編寫。測試方案是按照系統需求說明書詳細的分析測試的模塊，指導后續的測試用例的編寫工作，重點在于對模塊具體功能的理解和測試對象的分析。在這一階段，首先由擔任開發人員角色的學生來介紹系統模塊的基本功能，并以文檔的形式向對應測試組成員提交；然后由指導教師以具體測試點為例，介紹詳細的測試用例寫法；最后，由各組組長將測試任務分配給組員，各組員在理解的基礎上開始測試用例的設計。測試方案完成以后由各組組長匯總，并在組內進行評審。
（3）測試用例設計。測試用例的編寫是針對各功能模塊測試而設計的一組測試輸入、執行條件以及預期結果，也是本實訓項目的重點內容。在對模塊的特性和功能了解的基礎上，設計系統的測試點，設計時應考慮角色權限、驗證點和測試描述。在設計驗證點的過程中，鼓勵學生展開討論，力求做到無疏漏；同時在測試描述時，可以將等價類劃分、邊界值、錯誤推測等常用方法與書本理論相結合，通過具體的實例加深學生對所學知識的理解。最終的測試用例以Excel表格形式列出，其中包括編號、重要級別、操作步驟、預期輸出和實際測試結果等條目。
（4）多輪系統測試。按照測試用例的具體內容，可以進行多輪的系統測試。根據測試結果，扮演開發人員角色的學生對缺陷進行修改。通過這一過程，不但使學生認識到開發過程中存在的問題，而且積累了開發經驗，為今后規范化的編程打下了基礎。
（5）測試報告提交。通過半個月的實訓，學生經歷了規范化的測試流程，測試報告的編寫是對測試內容的概括和總結。報告的內容主要有以下三個方面：通過對測試結果的分析，得到對軟件質量的評價；總結本次的測試過程，為制定以后的測試計劃提供參考；評估本次測試計劃和測試執行是否符合規范。通過本次實訓，學生普遍體會到從理論知識到實踐的過程，明確了規范化的軟件測試方法，同時對軟件編寫中隱含的錯誤和缺陷也有了一定的認識，為今后的軟件開發打下一定的基礎。
二、軟件測試實訓存在的問題和解決辦法
本次軟件測試實訓基本達到了預期的效果，學生不但學到了規范化的測試流程，提高了職業軟件素養，而且通過互動和交流，發現了教學中存在的一些需要解決的問題。首先，本次軟件測試實訓是針對上一次實訓開發的系統，離企業的實際系統測試尚有一些差距；其次，參與的學生缺乏實際經驗，對軟件測試認識不足，導致測試方案和測試用例編寫不夠規范、完善；另外，相應的管理需要加強，在實訓過程中存在遲到、早退以及缺席的現象，從而影響了測試進度。
針對以上問題，在今后的實訓過程中，測試項目要盡量切合企業的實際需求，同時在測試方案和測試用例的評審中，要加強教師和學生的溝通，強調測試流程的規范性，可以多鼓勵高水平的學生帶低水平的學生。另外，可以采取企業現行管理方式對實訓進行管理，如引入考勤制度、評審制度等。
三、結語
軟件測試是我國軟件產業高速發展中需求缺口較大的一個行業，培養具有相關經驗和符合企業需求的軟件測試人才是目前高校計算機專業需要解決的核心問題之一。本文通過研究軟件測試實訓項目，探索了軟件測試專業人才的培訓方式以及在此過程中遇到的問題，對研究校企聯合的人才培養模式具有重要意義。
參考文獻：
[1]徐瑾.中國軟件外包業研究綜述與展望[J].經濟學動態，2010，（11）：75-78.
第5篇：測試方案和測試報告范文
1.
開發框架
開發的系統中所應用的技術都是基于JavaEE，技術成熟穩定又能保持先進性。采用B/S架構使系統能集中部署分布使用，有利于系統升級維護；采用MVC的開發模式并參考SOA體系架構進行功能設計，使得能快速擴展業務功能而不會影響現有系統功能的正常使用，可根據實際業務量進行部分功能擴容，在滿足系統運行要求的同時實現成本最小化。系統采用分布式部署，系統功能隔離運行，保障系統整體運行的穩定性。
圖1.開發框架與體系結構圖
1.1.
web端技術棧
（1）前端采用elementUI/jquery/bootstrap/vue實現，前端和Controller交換數據基于json格式。
1.2
業務端技術棧
（1）
業務端基于springboot、springMVC、JPA、SpringData技術棧構建，對于復雜的系統則采用springCloud構建。
（2）
四層分隔：controller（Facade）/service/dao/entity,其中fa?ade主要用于生成json，實現和前端的數據交換。
（2）命名：按照功能模塊劃分各層包名，各層一致。
2.
系統安全保障
2.1
訪問安全性
權限管理是系統安全的重要方式，必須是合法的用戶才可以訪問系統（用戶認證），且必須具有該資源的訪問權限才可以訪問該資源（授權）。
我們系統設計權限模型，標準權限數據模型包括
：用戶、角色、權限（包括資源和權限）、用戶角色關系、角色權限關系。權限分配：通過UI界面方便給用戶分配權限，對上邊權限模型進行增、刪、改、查操作。
基于角色的權限控制策略根據角色判斷是否有操作權限，因為角色的變化
性較高，如果角色修改需要修改控制代碼。
而基于資源的權限控制：根據資源權限判斷是否有操作權限，因為資源較為固定，如果角色修改或角色中權限修改不需要修改控制代碼，使用此方法系統可維護性很強。建議使用。
2.2
數據安全性
可以從三個層面入手：操作系統；應用系統；數據庫；比較常用的是應用系統和數據庫層面的安全保障措施。
在操作系統層面通過防火墻的設置。如設置成端口8080只有自己的電腦能訪問。應用系統層面通過登陸攔截，攔問請求的方式。密碼不能是明文，必須加密；加密算法必須是不可逆的，不需要知道客戶的密碼。密碼的加密算法{
MD5--不安全，可被破解。需要把MD5的32位字符串再次加密(次數只有你自己知道)，不容易破解；加密多次之后，登錄時忘記密碼，只能重置密碼，它不會告訴你原密碼，因為管理員也不知道。
3.
項目計劃的編制和管理
本公司項目基于敏捷過程的方式組織，項目計劃基于需求和團隊反復討論的過程。在開發系統時都經過了解需求，開需求分析會議，確定開發任務，推進開發進度，測試，試點，交付等開發步驟，其中具體內容有：
1，了解需求：跟客戶溝通，充分了解對方的需求，然后對需求進行過濾，最后整體成需求文檔
2，需求分析會議：也就是項目啟動會議之后要做的事情，對拿來的需求進行討論，怎么做滿足需求。主要對需求進行全面的梳理，讓開發，產品，項目都熟悉整個需求。
3，確定開發任務：根據敏捷開發法則，需求變成一個一個功能點之后就是安排開發任務了。根據團隊現有的資源合理分配任務，和時間節點
4，
推進開發進度：在開發的實際過程中，注意節奏的把控，注重功能點完成的時間點。
5，
每一個功能點完成之后都會有測試工程師進行單元測試。
6，試點單位進行試用，然后解決問題。
7，交付
4.
項目進度保障體系
4.1制度保障
實行項目經理負責制，建立強有力的開發指揮機構和開發保障體系，投入能保證開發進度如期實現的足夠的開發隊伍，實行專業化開發。建立從項目經理到各開發人員的開發任務，全面、及時掌握并迅速、準確地處理開發過程中遇到的各種問題。對開發過程中遇到的需求變更進行協調管理，對重大關鍵問題超前研究，制定措施，及時調整開發的公共類保證開發過程的連續性和高效性。強化開發過程的時間點把控問題，對開發任務實行動態管理。保證在時間點內完成開發任務。實行內部經濟承包責任制。使責任和效益掛鉤，個人利益和完成工作量掛鉤，做到多勞多得，調動開發團隊、個人的積極性。編制科學合理的總體開發進度計劃，運用專業管理軟件，對開發計劃進行動態控制；并在總計劃的基礎上分解明確的月及旬計劃，項目經理抓住主要技術難點，嚴格按計劃安排組織開發，重點抓好關鍵技術的開發。定期檢查開發計劃的執行情況，及時對開發進度計劃進行調整；在開發過程中，根據開發進展和各種因素的變化情況，不斷優化開發的方案，保證各開發有條不紊的執行。
4.2開發進度開發工期保證措施
任務分發將利用一流的開發策劃、高效的組織、科學的領導和動態的控制，用一流的運作與協調、一流的技術框架與技術、一流的團隊素質等來實現一流的管理，從而通過過程控制實現最終產品的精品，滿足客戶對工期、質量等各方面的要求。
完善的開發計劃保證體系是保證項目工期的綱要，掌握開發管理主動權，全面而宏觀的控制整個開發的過程，是保證開發進度的關鍵。通過完善的開發計劃保證體系，采用先進的開發計劃計算、設計軟件，制定出科學合理的開發進度計劃。
1．
編制三級網絡計劃
在開發過程中中我單位將分級編制網絡計劃來控制整個項目的開發。
（1）一級網路計劃
根據項目總工期控制項目各階段里程碑目標。
（2）二級網路計劃
根據各階段分項業務的工期目標控制分解成分部目標。
（3）三級網路計劃
主要技術使用控制周計劃和日計劃。通過對關鍵技術開發編制標準業務，建立計劃統計數據庫，利用項目管理信息系統對工期進行全方位管理。
2.制定派生計劃
根據總控工期、階段工期和分項業務工作量制定出技術保障、商務合同、物資采購、設備定貨、人力資源等派生計劃，是進度管理的重要組成部分，按照最遲完成或最遲準備的插入時間原則，制定各類派生保障計劃，作到各項工作有備而來，有章可循。
工期保證體系框圖
技術保證體系
綜合保證體系
組織保證體系
技術總監
開發組織設計
技術總監
開發人員
測試人員
試驗室
項目經理
制
度
保
證
獎懲制度
崗位責任制
經濟責任制
開發團隊
單元測試
技術培訓
測試用例
開發進度計劃保證
月度計劃
季度計劃
年度計劃
技術工作責任制
技術標準
設計文件
招標文件
技術規范
技術工作標準化
開發團隊
實現工期目標
4.3施工進度三階段控制措施
（一）開發進度“事前控制”
1.積極做好業務需求，業務流程等準備工作，為自己盡早投入開發創造好條件，把準備工作做細做充分，確保按時無障礙開發。
2.編制詳細的開發進度計劃，包括需求文檔，業務分工計劃，業務流程等。
3.關鍵技術或特殊技術編制相應的開發進度計劃，制定相應的節點，編制節點控制計劃。
4.編制開發節點實施細則，明確搭接和流水的節拍。
（二）開發進度“事中控制”
1.嚴格審核開發人員的進度計劃、季度計劃、月計劃，并監督各人員按照已制定的開發進度計劃進行開發。
2.在本項目開發期間，按開發進度需要，配備充足的開發人員，確保時間點的正常運行。
3.在開發期間，每周結束前，組織召開一次碰頭會，協商解決當周開發過程中和第二周開發中將會發生的問題，應解決的問題決不拖延。
4.狠抓開發進度與質量，加強技術培訓。只有在確保技術過關、質量的前提下才能求速度、講進度、抓工期。
5.根據開發的實際情況，及時修改和調整開發進度，并定期向客戶通報系統開發進展情況。
（三）施工進度“事后控制”
1.根據開發進度計劃，及時組織測試人員通過事先編寫的測試用例進行分項測試與系統測試。
2.定期整理有關開發進度的資料，匯總編目，建立相應的檔案。
5.
項目質量保障體系
5.1過程中的保證
依據項目的軟件特點、合作方的項目實施要求，采取需求分析，系統設計，軟件項目計劃，軟件需求分析，軟件模型設計，軟件詳細設計，單元測試設計，編寫單元測試，系統培訓，系統測試等一些列的措施在過程中保證項目的質量。
5.2技術方面的保證
公司研發人員均為國內高校分子計算機專業或招聘的高級技術人才，專業基礎和工作經驗扎實豐富，整個團隊具有高級工程師、博士的人才搭配，具備強大的持續研發能力。
5.3軟件質量管理責任分配
角色
職責
配置管理員
制定、創建和維護配置庫，提供文檔規范，并傳達到各個部門。
QA（質量保證）
參與項目各個階段的評審，進行過程評審和產品審計，檢查文檔和代碼的規范執行情況
QC（質量控制）
軟件測試是質量控制的主要手段，測試人員進行軟件的測試設計和執行工作
5.4工作產品和活動
活動
責任人
工作產品
是否可裁剪
項目立項
項目經理
項目計劃
否
配置管理員
配置管理計劃
是
QA
質量保證計劃
是
測試人員
系統測試計劃
否
需求管理活動
項目經理
需求調研報告
是
需求規格說明書
否
用戶、項目經理
用戶確認書
是
QA
評審報告
是
設計過程、決策分析活動
設計組
概要設計說明書
否
界面設計圖
是
詳細設計說明書
是
項目經理
決策分析評議表
是
QA
評審報告
是
開發編碼、集成過程活動
項目經理
版本記錄
否
QA
評審報告
是
開發人員
程序代碼
否
系統測試活動
測試人員
測試用例、測試報告
否
QA
評審報告
是
項目結項、交付與維護活動
項目經理
培訓教材
是
用戶手冊
是
安裝手冊
是
項目總結報告
否
項目經理、客戶
用戶驗收報告
是
QA
評審報告
是
項目跟蹤與監控活動
項目經理
項目問題跟蹤日志
是
QA
不符合項問題跟蹤記錄表
否
項目跟蹤與監控活動檢查單
是
風險管理活動
項目經理
風險管理列表
是
QA
風險管理活動檢查單
是
配置管理活動
配置管理員
配置狀態報告
是
變更請求審批表
是
變更跟蹤記錄表
是
QA
配置管理活動檢查單
是
評審活動
項目成員
評審報告
否
QA
評審活動檢查單
是
5.5評審
評審是以一種正式的形式進行，如有正式的、事先定義好的有關職責的各種角色，并遵循組織規定的流程。
對于任何工作產品的審計，都會組建與之對應的專門評審組，包括作者、主持人、記錄員以及陪審員若干。評審組的成員可以包括PPQA、項目組成員，但不能有作者的直接領導或者管理者。
評審小組先召開一個預備，作者會針對工作產品向大家做個總體的介紹，例如講解一下本工作產品的目標是什么，以及其相關的實現
細節、開發標準等。應該允許甚至鼓勵評審組成員動手查看工作產品，或者查看開發過程中所用到的檢查單。
評審小組的主持人負責確定什么時間開始真正的評審會議，在預備會和正式評審會議之間，評審小組成員對工作產品進行徹底檢查，并依據相關標準和準則評審工作產品。
在預定時間，評審小組成員以會議形式聚在一起，依次對產品進行檢查，主持人負責對整個會議的進展進行控制，記錄員記錄下這個過程。
在工作產品中發現的每一個缺陷都會被認真記錄下來，并被適當分類。
會議結束后，負責人需要分析相關缺陷，找出產生此缺陷的原因并加以修正。
主持人應確保所有的缺陷都會得到解決和修正。如果過程需要加以變更的話，應將相關問題移交相關的質量保證人員。
階段
評審內容
評審時機
參加人員
是否可裁剪
計劃階段
項目計劃
項目啟動會議
項目所有成員
否
配置管理計劃
項目所有成員
是
質量保證計劃
項目所有成員
是
系統測試計劃
項目所有成員
否
需求階段
需求調研報告
項目評審會議1
需求分析師、項目經理、系統架構師、設計組成員、QA
是
需求規格說明書
需求分析師、項目經理、系統架構師、設計組成員、QA
否
設計階段
概要設計說明書
項目評審會議2
需求分析師、項目經理、系統架構師、設計組成員、QA
否
UI設計圖
UI美工、需求分析師、項目經理、系統架構師、設計組成員、QA
是
詳細設計說明書
需求分析師、項目經理、系統架構師、設計組成員、QA
是
決策分析評議表
需求分析師、項目經理、系統架構師、設計組成員、QA
是
編碼階段
代碼檢查（1）
項目評審會議3
開發組成員、項目經理、需求分析師、系統架構師、QA
否
代碼檢查（2）
開發組成員、項目經理、需求分析師、系統架構師、QA
否
測試階段
系統測試用例
項目評審會議4
測試人員、項目經理、開發組成員、需求分析師、系統架構師、QA
否
系統測試報告（1）
測試人員、項目經理、開發組成員、需求分析師、系統架構師、QA
否
系統測試報告（2）
測試人員、項目經理、開發組成員、需求分析師、系統架構師、QA
否
階段
用戶手冊
項目總結會議
項目所有成員
是
項目總結報告
項目所有成員
否
5.6質量保證（QA）
QA工作審計產品
文檔
責任人
項目計劃
項目經理
需求規格說明書
項目經理
概要設計說明書
項目經理
源代碼
開發組
系統測試用例
測試組
系統測試報告
測試組
用戶手冊
項目經理
項目總結報告
項目經理
入最佳實踐庫的產品
項目經理
QA工作中需要審計的活動
活動
評審時機
項目立項
計劃階段
需求管理活動
需求階段
設計過程活動
設計階段
決策分析活動
設計階段
開發編碼活動
編碼階段
集成過程活動
編碼階段
系統測試活動
測試階段
項目結項
階段
交付與維護
階段
項目跟蹤與監控活動
每月一次
風險管理活動
每月一次
配置管理活動
每月一次
評審活動
每月一次
QA審計中的不符合項目問題
對QA審計過程中發現的不符合項問題要寫入《不符合項跟蹤記錄表》，以郵件的方式發給問題的相關人員，做好和項目成員、項目經理、部門經理之間的溝通，問題的上報流程：項目組成員溝通解決——項目經理——部門經理——總經理。QA要對不符合項問題進行跟蹤與監控，直到問題解決，QA驗證并關閉不符合項。
6.
系統測試驗收方案
系統測試驗收主要包含以下四方面的工作內容，分別是驗收測試、系統試運行、系統文檔驗收以及項目終驗。
6.1.
驗收測試
驗收測試即對信息系統進行全面的測試，依照雙方合同約定的系統環境，以確保系統的功能和技術設計滿足建設方的功能需求和非功能需求，并能正常運行。驗收測試階段應包括編寫驗收測試用例，建立驗收測試環境，全面執行驗收測試，出具驗收測試報告以及驗收測試報告的簽署。
6.2系統試運行
信息系統通過驗收測試環節以后，可以開通系統試運行。系統試運行期間主要包括數據遷移、日常維護以及缺陷跟蹤和修復等方面的工作內容。為了檢驗系統的試運行情況，甲方可將部分數據或配置信息加載到信息系統上進行正常操作。在試運行期間，甲乙雙方可以進一步確定具體的工作內容并完成相應的交接工作。對于在試運行期間系統發生的問題，根據其性質判斷是否是系統缺陷，如果是系統缺陷，應該及時更正系統的功能；如果不是系統自身缺陷，而是額外的信息系統新需求，此時可以遵循項目變更流程進行變更，也可以將其暫時擱置，作為后續升級項目工作內容的一部分。
6.3系統文檔驗收
系統經過驗收測試后，系統的文檔逐步、全面地移交給客戶。客戶按照合同或者項目工作說明書的規定，對所交付的文檔加以檢查和評價；對不清晰的地方可以提出修改要求，在最終交付系統前，系統的所有文檔都需要驗收合格并經雙方簽字認可。
6.4項目終驗
在系統經過試運行以后的約定時間，雙方啟動項目的最終驗收工作。?最終驗收的工作包括雙方對驗收測試文件的認可和接受、雙方對系統試運行期間的工作狀況的認可和接受、雙方對系統文檔的認可和接受、雙方對結束項目工作的認可和接受。?項目最終驗收合格后，由雙方的項目組撰寫驗收報告。
7.
技術服務與支撐
我公司在合同有效期內提供免費維護期和長期的技術服務，向用戶用戶相關技術人員免費提供原理和技術上的指導和咨詢，使用戶能正確熟練地使用本協議的軟件開發及測試成果。
根據用戶使用系統的相關部門人員現狀，一旦系統安裝調試完畢投入正常運行后，卓安公司在交付本系統的一段時間內，專門指派若干名專業工程師為用戶使用部門進行指導培訓和維護，直到用戶安排的技術人員能完全接管本系統的操作管理為止。
7.1.
現場支持
系統在售后期間，提供7×24小時的技術支持服務。如系統出現故障，將保證30分鐘遠程響應；影響生產的故障4小時抵達現場，并派出專業工程師在8小時內排出故障；不影響生產的故障8小時內抵達現場，并派出專業工程師在2個工作日內排除故障。如在2個工作日內無法解決，將在2日內向用戶方提出詳細解決方案及日程安排，交給用戶方確認。
7.2.
技術支持
長期電話技術咨詢和技術服務和遠程在線服務。用戶可以隨時撥打技術支持熱線電話或通過遠程協助進行有關技術咨詢，專業技術人員會耐心解答用戶的問題。免費提供需求預測、系統規劃等支持。當用戶需要對系統擴容、調整時，將免費協助用戶準備預算、規范書、工程有關事項。
7.3.
常規維護
系統在售后期間，會安排工程師定期對系統進行運行檢查。如有功能需求分析范圍內的問題，及時進行修改；維護期后發現的在需求規格說明書范圍內問題，同樣及時進行修改。對用戶提出的方便操作和易用等可用性方面的要求，盡可能滿足用戶要求，并保證在接到要求后兩周內解決。用戶提出性能要求，如屬于軟件編制因素導致性能較差，技術人員主動調整軟件，以提高性能，保證在一個月內解決。
7.4.
變更管理
對系統的應用平臺和開發、運行環境以及應用系統的變更和升級的詳細資料第一時間提交用戶。
8.
培訓計劃
8.1.1.
培訓工作概述
用戶軟件系統項目建設完工后，為了使各個使用本系統的部門能熟練的操作系統，利用系統提供的功能來處理日常工作，本公司將對使用系統的相關部門員工進行一次全面的培訓。
培訓過程按系統使用部門劃分，分別培訓各部門使用的系統功能點及業務流程。另外為了用戶管理需要，將重點培訓2名系統管理員，培訓系統管理相關功能。
8.1.2.
培訓規范
由于培訓過程涉及到時間、場地、人員等諸多不確定因素，本方案所提及項只作為參考大綱。實際培訓安排因由主管部門統一規劃，并下文到各系統使用部門。
培訓的效果與參與人員的重視程度有很大的關系，客戶各部門對參與人員要做好工作，引起重視。主管部門可以考慮是否需要在培訓結束并且參與培訓人員試用一段時間后，組織一次系統使用測驗。
通過系統使用培訓，達到以下目標：
?
使相關使用部門了解系統運作，熟悉系統功能。
?
使系統有效的推廣到相關使用部門，讓員工積極參與使用系統。
第6篇：測試方案和測試報告范文
關鍵詞：低位熱源 、地源熱泵 、地埋管 、熱響應試驗
一、工程概況
煙臺榮昌制藥廠新廠區位于煙臺市經濟技術開發區生物醫藥工業園內，總規劃用地為27.75公頃（合416畝），分為二期完成，總建筑面積為20萬平方米，其中一期建筑面積7.8萬平方米，由九個單體建筑組成，主要建設目的為醫藥產品生產、相關的技術研發、孵化和中試等，項目由榮昌制藥、榮昌生物和同濟大學三方合作完成。
該工程的規劃目標是以用地內的良好生態條件為基礎，通過整合周邊市政和自然風景資源，借助國家和當地政府的扶植，圍繞園區建設任務中最核心的功能，將企業建設成低碳生產、綠色辦公、示范帶動的高科技制藥企業。
二、空調冷、熱負荷的確定
九個建筑單體空調負荷由設計院提供（詳見下附表一），若將所有單體空調負荷疊加則設計空調總冷負荷為8988kW，空調總熱負荷為6103kW，考慮到每個建筑物功能的不同，使用的時間也不一樣， 對不同的建筑按不同的使用系數計入到總負荷中，如下表中的使用系數取值從100%-0%，計算的空調總冷負荷為7423kW，總熱負荷為5191kW。 一期工程共設置一個空調機房，由機房分三路進出水分別供二個車間及生活區（辦公樓、餐廳、招待所、職工宿舍），二個車間為分別為單獨回路，生活區為單獨回路，為了便于管理及核算運行費用，每個回路單獨設一套計量裝置。
二、初投資費用、運行費用及對環境景程的分析對比：
為了選擇最適合本項目的冷、熱源系統，以下對地源熱泵系統（方案一）與城市熱網+冷水機組系統（方案二）這兩種方案主要從經濟性、節能性以及環境影響方面對比分析。
1、兩方案的初投資費用分析：
1.1：地源熱泵系統初投資費用： 地源熱泵系統（不含室內末端系統）總投資費用為1830萬元，其中主機340萬元，機房內附屬設備及安裝費用、室外管網安裝費用320萬元，室外埋管費用1170萬元。
1.2：城市熱網加冷水機組系統的初投資費用：煙臺市城市熱網的收費標準為120元/平方米，7.8萬平方米的建筑總投資費用為936萬元；冷水系統中主機的的初投資費用為270萬元（主機低于地源熱泵主機），機房內附屬設備及安裝費用、室外管網安裝費用330萬元（較地源熱泵系統增加冷卻水系統的費用），總投資費用為1556萬元。
2、兩方案的運行費用分析
空調系統運行費用：根據美國ARI標準和中國行業標準JB/T4329-97，平均滿負荷率一般為60%。
運行費用=裝機容量×平均滿負荷率×運行天數×每天運行時間×電價
2.1：地源熱泵系統運行費用：
夏季運行費用：（305+45+45）×4×0.6×100×16×0.75=113.76萬元。
冬季運行費用：=（382+45+45）×3×0.6×135×16×0.75=137.62萬元。
冬、夏兩季運行總費用為251.39萬元，折合為32.23元/平方米。
2.2：城市熱網加冷水機組系統的運行費用：
冬季運行費用分析：煙臺市城市熱網收費標準為26元/O計算，冬季運行費用為202.80萬元。
夏季運行費用分析：相同的空調冷負荷，由于冷水機組的冷凝溫度高于地埋管系統的冷凝溫度，其耗功高約20%，水泵的功率相同，冷水機組系統的運行費用為（305×1.2+45+45）×4×0.6×100×16×0.75=131.33萬元。
冬、夏兩季運行總費用為334.13萬元，折合為42.84元/平方米。
備注：運行費用的計算條件如下：
①夏季空調運行100天，冬季空調運行135天；
②按空調每天平均運行16小時計算；
③平均滿負荷率一般為60%；
④電價按0.75元/度，空調總面積7.8萬平方米；
⑤冬季開3臺機組供暖. 夏季開4臺機組制冷。
3、兩方案對比分析結果如下：將兩種方案的初投資費用、運行費用、環境影響分析對比如下 ：
通過對兩種方案的初投資費用、運行費用及環境影響的分析比較得出，方案一雖然初投資費用比方案二高274萬元，但每年可節約運行82.74萬元，靜態投資回收年限僅為3.31年，且每年可節約標煤458噸，減少二氧化碳排放量1245噸/年，減少二氧化硫排放量40.6噸/年。
三、空調熱源的配置方案
1、冷、熱源的配置方案
根據設計的冷、熱負荷，設計選用四臺LSBLGR-2280MD 型滿液式半封閉螺桿地源熱泵機組為整個廠區實現夏季供冷、冬季供暖，其中一臺LSBLGR-2280MD機組使用冷卻塔散熱。地源熱泵機組在夏季冷水進出水溫度12℃/7℃，冷卻水（地埋管循環水）進出水溫度25℃/30℃，冬季空調熱水進出水溫度40℃/45℃，冷水（地埋管循環水）進出水溫度6℃/3℃的標準工況條件下，其性能參數如下：
由以上參數可知，夏季四臺機組總的制冷量為7027KW，冬季三臺地源熱泵機組總的制熱量為5073KW （另外一臺機組可以做為備用機組）， 完全可以滿足設計要求。
2、機組的運行方案：本方案空調機組選擇了四臺雙壓縮機頭地溫中央空調機組，每臺壓縮機都可以互為備用，實際使用中可以根據建筑物的實際負荷更好的調節機組的使用率，進行不同檔位的加載，從而降低運行費用；并且每個壓縮機頭都可單獨運行，能夠相互作為備用，對系統的安全起到保護作用。
夏季機組處于制冷狀態，其中三臺機組向土壤釋放熱量，一臺機組向大氣釋放熱量，為室內末端提供空調冷水，滿足空調供冷要求。
冬季四臺機組互為備用，最大負荷時開三臺機組 ，為室內末端提供空調熱水，滿足空調供暖要求。
3、機房主要設備總配電負荷及機房面積
本方案機房機房內所選設備的最大用電負荷按夏季四臺機組全開，約1606KW（包含主機、循環水泵，不含備用泵），配電功率不小于1800kW ，電源采用380V，50HZ三相四線制.
設計機房占地總面積：12 m×26m=312平米 。
五、地源換熱器計算：
該工程在方案實施前已經對擬打孔部位進行了勘探，根據勘探單位提供的《地質勘探及巖土熱響應試驗測試報告》，該工程共鉆鑿換熱試驗孔4個，分布在打孔區域的四個不同位置，每孔的深度為102-105米，以1#為例，地質層標高由上及下分別為粘土層-7.0米（厚7米），砂層-8.5米（厚1.5米），強風化砂巖-17.0（厚8.5米），青白色巖石屬石灰巖-90（厚73米），灰紅色巖石屬石灰巖-105（15米）。
測試報告顯示：當地土壤平均溫度為14.9℃，4個測試孔的土壤綜合導熱系數分別為2.882W/（m.K），3.224/（m.K），2.953W/（m.K），3.295W/（m.K），在設計工況下夏季的換熱量如下表：
以上數據是根據在測試條件的特定工況下計算出的參考值，期換熱量是在單孔不受周邊孔群影響情況下的計算值，該項目本身打孔區域比較集中，且孔數較多，系統正常運行時單孔換熱量受周圍其它孔群影響較大，保守取值按70W/m。
綜合土壤熱物性報告，設計地源換熱器采用垂直埋管形式，井中敷設兩路（雙U型）管徑為φ32的PE管道，井深120米（受打孔位置的限制），井間距為4.5*4.5米。冬季工況每口井的換熱量為4.5×1.2=5.4kW，夏季工況每口井的換熱量為 7×1.2=8.4kW 。
夏季空調制冷需要打孔數N=1792×3（1+1/5.88）/8.4=748
冬季空調制熱需要打孔數N=5191（1-1/4.42）/5.4=744口
本方案按冬季數量增加8%，即按800口井考慮，夏季多余的熱量由冷卻塔釋放 。
六、結論
地源熱泵系統是隨著全球性的能源危機和環境問題的出現而逐漸興起的一門熱泵技術， 雖然與對比方案相比，投資費用高15%，但每年可節約運行費用25%（靜態回收期僅為3.31年），且減少了對周圍環境的污染及排放量，是理想的環保、節能空調系統。
參考文獻：
【1】GB 50366-2006地源熱泵系統工程技術規范
第7篇：測試方案和測試報告范文
【關鍵詞】軟件工程 畢業設計（論文） 實踐教學
一、引言
畢業設計（論文）（以下簡稱畢業設計）是計算機及相關專業教學計劃中的一個重要環節，是培養學生對所學基本理論及基本操作技能綜合運用的訓練過程，是提高學生分析和解決問題能力的重要實踐環節，是實現理論與實踐相結合的重要途徑，是對教育教學質量的全面檢查。目前，計算機及相關專業的畢業設計質量正在逐年下降：學生急于找工作或考研，畢業設計得不到應有的重視；需求分析不到位，設計成果不符合實際需求；軟件開發流程混亂；缺乏文檔寫作訓練，等等。
針對上述問題，筆者認為，除了應當從管理角度嚴格進行過程監控外，還應當使學生通過《軟件工程》課程的學習，提高畢業設計的質量。
二、軟件生命周期與畢業設計過程的對應關系
軟件產品從形成概念開始，經過開發、使用和維護，直到最后退役的全過程稱為軟件的生命周期。軟件生命周期可以劃分成若干個時期與階段，它與畢業設計各個環節的對應關系如圖1所示。
三、軟件生存周期各階段應完成的任務
1.可行性研究與計劃階段、需求分析階段
可行性研究與計劃階段主要完成問題的定義、可行性論證以及初步計劃的制定；需求分析階段主要完成需求調查，進行功能、性能與環境約束分析；編制軟件需求規格說明、制定軟件系統的確認測試準則和用戶手冊概要。這兩個階段對應于畢業設計的課題論證、選題、調研、查資料，通過對設計題目的深刻理解，完成開題報告的撰寫工作。
2.概要設計階段和詳細設計階段
概要設計階段主要完成軟件系統總體結構的建立、定義功能模塊的接口、設計全局數據庫和數據結構、規定設計約束、編制概要設計文檔等工作；詳細設計階段主要完成模塊詳細設計及編制模塊的詳細規格說明工作。包括模塊的詳細功能、算法、數據結構和模塊間的接口信息等設計，擬定模塊測試方案；把模塊詳細設計的結果匯總，形成模塊詳細規格說明書。這兩個階段對應于畢業設計的系統設計階段。
3.實現階段與組裝測試階段
實現階段主要完成編碼及單元測試工作。根據模塊詳細規格說明書，將詳細設計轉化為程序代碼、對模塊程序進行測試，驗證模塊功能及接口與詳細設計文檔的一致性，并形成單元測試報告；組裝測試階段主要完成模塊程序組裝與測試及組裝測試報告的編寫。
4.確認測試階段
該階段主要完成軟件系統測試、確認測試文檔編制及軟件評審工作。根據軟件需求規格說明定義的全部功能和性能要求及軟件確認測試準則對軟件系統進行總測試；向用戶提供以確認測試報告為主的有關文檔，包括系統操作手冊、源程序清單和項目開發總結報告等；由專家、用戶、軟件開發人員組成的軟件評審小組對軟件確認報告、測試結果和軟件進行評審，并將得到確認的軟件產品交付用戶使用。這個階段主要對應于畢業設計（論文）中的論文評審、結題驗收及畢業設計的答辨準備階段。
5.軟件運行與維護階段
主要進入軟件的使用階段，并完成軟件的維護工作。它主要對應于畢業設計中的答辯階段。
四、畢業設計應注意的幾個問題
1.摘要
摘要是對文章主要內容的摘錄，要求精、短、完整。以幾十字至三百字左右為宜。摘要應具有獨立性和自明性，從摘要中即應獲得必要的信息；摘要中只能使用第三人稱；要客觀如實地反應原文的內容，要著重反映論文的最新內容和作者特別強調的觀點；要求結構嚴謹、語義確切、表述簡明，一般不分段落、不進行自我評價。
2.關鍵詞
關鍵詞主要用于論文檢索，它是從論文的題名、摘要和正文中選出的，是對表述論文的中心內容有實質意義的詞匯，關鍵詞一般以3～5個為宜。
3.結論
結論寫作的內容應主要考慮本文研究結果是什么？研究結果說明了什么？對前人有關的看法作了哪些修正、補充、發展、證實或否定？本文研究的不足之處或遺留未予解決的問題以及對解決這些問題的可能的關鍵點和方向等。結論應該準確、完整、明確、精練。
4.需求分析
在畢業設計中，學生往往不能對所做題目進行充分的調研，需求不明確，隨意想象的成分較多。特別是在數據表的建立上，大部分同學隨意設置字段的類型，而字段長度基本上采用默認置。而在實際項目開發中，數據項的設置應主要注意以用戶的需求和滿足系統要求為準，而不應設計冗余的字段；數據的類型要依據實際需求，當某些字段可以是選擇某幾種類型之一，應考慮哪一種更有利于本系統或哪種更易于用戶操作和維護。
5.詳細設計
許多同學把詳細設計階段的任務理解為代碼實現，因此，在概要設計之后就著手進行代碼的編寫而忽略了算法的表達及測試用例的編寫環節，由此造成的結果是隨意編程，大量的時間浪費在程序的修改和調試上。
6.軟件測試
測試做得不夠全面，大部分同學只選擇了有效的測試用例，而沒有進行無效的測試用例的設計，因此所做的軟件BUG較多。
7.團隊合作
在畢業設計中，應有意識地鍛煉學生們的團隊協作精神，因此，在布置畢業設計題目時，應盡量選擇規模大一點的題目，然后由4～5名同學共同協作，每人完成一個子題目。這樣，可以使學生們分析問題和解決問題的能力、溝通和表達能力得到充分鍛煉，為今后的工作奠定基礎。
參考文獻：
[1]全國文獻工作標準化技術委員會.科學技術報告、學位論文和學術論文的編寫格式 [S].北京：中國標準出版社，1988.
第8篇：測試方案和測試報告范文
十幾年的裝飾工程經驗告訴我們，做好一個裝飾工程非常的不容易，換句話說，在一年保修期內不能有任何工程的上的紕漏，尤其是大型裝飾工程，似乎在裝飾行業來說是很少見的。但我公司能長期在全國大型的裝飾工程中多次奪標，多次獲樣板工程，并能同業主保持長期的業務合作，可以說，一方面是全體員工的努力，但更重要的是公司總結出較完善的一套裝飾工程管理經驗。
為了促進業內人士之間的技術交流，我們將總結的部分經驗提供出來，以供同業同仁互相提高。
對一個裝飾工程來講，管理人員的素質是第一重要的，項目經理，材料員、施工員、財務缺一不可，在裝飾工程的管理中同樣有著重要的作用。他們的素質決定了裝飾工程施工的每一個細節，調整一些質量控制點的力度，同樣也就決定了工程本身的優劣。
對一項裝飾工程來講，重點是要作好“質量、進度、投資”的控制和“合同信息”的管理，具體而言，作好施工工程的準備工作，并將其列成表，歸好類，在施工過程中不斷跟蹤記錄、檢驗、及時調整、最終達到我們的預期值。以下，我們以簡單的術語更詳細的概括一下。
一、裝飾工程的進度（網絡計劃）
1、 進度表（根據實際發生情況，報告周進度計劃）；
2、 材料明細表，各種材料進場表，自檢和業主驗收時間表；
3、 各工種人員進場安排表；
4、 隱藏工程驗收時間表
5、 各單項工程階段檢驗及驗收時間表
以上工作雖密不可分，但通常業內人士只用第一種表代替。我們認為很難發現問題，更不能細人，而將這幾個環節提出來，充分考慮和安排，就會發現其中有沖突的地方，使我們能預前解決矛盾，并將工程的管理落到實處。同時，以上工作對加強同業主和其監理人員的交流好處。
二、裝飾工程的質量
1、 各專業原始圖紙及現場勘察資料；
2、 施工圖深度（節點圖，特殊工藝說明圖，各單位工種之間配合工作如預留檢修口方案等。）
3、 施工組織設計，施工場地平面使用說明；
4、 主要工序施工方案及用材一覽表，尤其是防水、防潮、防四害、防腐方案；
5、 施工主要技術班組和管理人員安排一覽表
6、 各主要工種負責人名單及其身份證復印件、主要技術特長和管理水準；
7、 隱蔽工程及檢驗明細一覽表
8、 分包工程及各分包單位資質一覽表（應附說明資料）
前兩項工作雖然同施工隊伍的關系不是很重要的，但往往問題就會出現在這里。許多工程項目常有這種情況，施工隊伍進場了，發現設計單位確定的洗手間位置，沒有給排水管道，或者建筑提供的電源與設計不符，需重新設置配電房等，造成成本不必要的加大。因此，施工前的實地勘察和審查施工圖非常重要。另外，由于目前設計人員素質不等，對施工工藝和材料的應用很熟練的設計師并不是很多，尤其是一些特殊做法，更需要我們優秀的施工人員同設計師多溝通，而不要一意孤行的去改變材料或改變做法，從而偏離了設計的初衷。
裝飾工程質量是最重要的質量控制點是隱蔽工程，雖然不被人重視，但往往問題就出現在這里。如給排水工程管道的水壓試驗雖然很簡單的，但卻為整個工程最重要的環節。沒有經過驗收，規定壓力數值的試驗，管道系統是否漏水無法保障，一旦隱蔽暗裝、作好防水、再貼完瓷片及竣工之后發現漏水，再找原因是非常困難的，經濟上的損失非常大，更嚴重的是我們可能失去了一個合作伙伴。因此，隱蔽工程的自檢是施工中最關鍵之處。
三、裝飾工程的投資
1、 設計階段控制：裝飾效果論證、功能論證、圖紙深度審核。
2、 施工階段控制。
（1） 材料、設備的產地、品牌、等級及材料樣板的封存一覽表；
（2） 主材進場自檢和業主的確認；
（3）工序的合理安排和人員的合理調用；
（4）備料的準確和材料的合理利用。
裝飾施工合同簽訂之后，應該說工程項目的成本、利潤基本有了90％的底數，以上環節施工階段決定了工程的成本。我特別反對“偷工減料”，實際上對有經驗的施工人員來講這一定是“得不償失”。設計階段的要點似乎同施工企業關系不大，但施工前，業主的確認和理解設計意圖非常重要。也許我們經常聽說，施工到一半或基本完工后，業主認為設計效果不好，造成返工重梆，這種投資上的浪費有時非常大，對此部分的工程追加，雖然與施工企業關系不大，但十有八九業主是不會結算給施工企業的。因此，施工前同業主之間的溝通是必不可少。
四、對裝飾工程信息的管理
1、裝飾材料消防審批表；
2、基層隱蔽驗收記錄；
3、吊頂隱蔽驗收記錄；
4、防火涂層隱蔽驗收記錄；
5、主要材料產品出廠合格證及復驗報告；
6、進口材料的設備商檢證、產地證；
7、分部工程質量評定匯總表；
8、施工日記和周、月工作總結；
9、竣工圖。
裝飾工程的信息管理，具體的說，就是要作好施工日記，總結和以上各種施工的自檢和驗收記錄、整理工作。通過以上工作，既可以隨時對進度、質量、投資的原計劃進行對比，隨時調整施工組織計劃，又可以預前解決可能出現的特殊問題，更能在出現施工紕漏時，找出問題的原因并及時得到解決。同時，通過文字上的信息交流，也可以加強同業主之間的了解和信任，為后續的合作打下基礎。
五、配套專業的質量
1、給排水工程
（1）閥門解體檢查記錄；
（2）管道焊接記錄；
（3）管道焊縫探測報告；
（4）計量表校驗報告；
（5）管道試壓檢驗報告；
2、強電和弱電工程
（1）防雷引線安裝隱蔽驗收記錄；
（2）線路穿管敷設隱蔽驗收記錄；
（3）接地極接地帶埋設隱蔽驗收記錄；
（4）配電柜箱安裝就位記錄；
（5）應急發電設備安裝就位記錄；
（6）用電設備安裝就位記錄；
（7）導線及設備絕緣電阻測試記錄；
（8）接地接零點阻測試記錄；
（9）計量儀檢定報告；
（10）整定記錄及整定通知單；
3、消防工程
（1）消防材料設備報批表；
（2）閥門解體檢查記錄；
（3）鋼管焊接記錄；
（4）設備絕緣電阻測試記錄；
（5）接地接零電阻測試記錄；
（6）噴淋頭、煙感器性能抽樣實驗報告；
（7）煙感器反應實驗報告；
（8）管道試壓檢驗報告。
4、空調安裝
（1）消防材料設備報批表；
（2）風、水管道安裝防腐保溫隱蔽驗收記錄；
（3）閥門解體檢查記錄；
（4）給水管焊接記錄；
（5）設備絕緣電阻測試記錄；
（6）接地接零電阻測試記錄；
（7）管道試壓檢驗報告；
（8）冷凍水系統水溫測試報告；
（9）風口風壓測試報告；
（10）風潔凈度測試報告；
第9篇：測試方案和測試報告范文
關鍵詞:modbus;一致性測試;自動化;用例生成器
中圖分類號:tp393.09文獻標識碼:a
文章編號:1004-373x(2010)01-171-03
automation of modbus conformance testing
zhao jian
(northwest airtraffic management bureau,xi′an,710082,china)
abstract:the existing modbus protocol conformance testing method has following problem: there is not automatictesting method for it,and this brings negative impact on the effectiveness of test.in order to solve this problem,the architecture of automation method for modbus protocol conformance testing,the architecture includes test case generation and test result analyzer.the automatic conformance testing system based on the architecture is realized.in practice,the system found a number of hidden modbus conformance errors,this proves that the availability and effectiveness of the method.
keywords:modbus;conformance testing;automation;test case generation
0 引 言
modbus協議已經成為一種事實的工業標準,但modbus設備間的一致性、互操作性較差,是制約modbus發展的瓶頸。為了解決modbus協議的一致性和互操作性問題,國內外的研究機構展開了深入的研究并取得了一些成果。
在modbus-ida國際組織的支持下,進行modbus一致性測試的實驗室陸續建立。目前,在國外得到modbus-ida國際組織授權的modbus一致性測試實驗室僅有兩處:一處是位于美國密歇根大學的modbus tcp一致性測試實驗室;另一處為設在該課題所在機械工業儀器儀表綜合技術經濟研究所的modbus serial line/tcp一致性測試實驗室,它是獨立于產品制造商的第三方測試機構[1,2]。國外其他研究機構對modbus測試系統的研究處于發展階段,modbus測試系統被應用到火電廠、電力監控系統、控制系統安全認證中,但都未形成一致性和互操作測試標準和自動化方法[3-6]。
在國內對進行modbus一致性和互操作性測試研究的機構主要有:北京交通大學的研究人員開展了modbus串行鏈路協議一致性測試系統的研發工作[7,8];開普電器檢測研究院在modbus協議一致性測試方面有多年的經驗,已加入modbus-ida協會[9]。
總得來說,國外在modbus協議的一致性和互操作性測試的研究已經取得了一定的成果,并形成了一些測試系統,但國內用戶分享成果的代價較大,并且無法進行modbus設備的互操作性測試,并且尚未形成測試自動化方法;國內的研究已經起步并取得了一些初步研究成果,但在國內尚未形成測試標準和測試自動化方法。
為了克服目前研究中所存在的問題,本文主要研究modbus協議的一致性測試的自動化方法,測試的自動化方法主要包括測試用例的自動生成和測試結果的自動分析兩方面,限于篇幅對測試結果的自動分析方法不予展開論述,主要論述測試用例的自動生成方法。
1 一致性測試的基本原理
協議測試理論經過幾十年的發展,在許多方面都取得了很大的進展,其中最成熟的是協議一致性測試的理論,主要代表是iso制定的國際標準iso/iec-9646:協議一致性測試的方法和框架。圖1是一致性測試的基本示意圖。iut(implementation under test)是根據規范的具體實現,是一個內部不可見的實體;規范(speciflcation)以某種形式化語言或者自然語言描述,但不管怎樣的描述形式,其根本都是一個擴展自動機模型;測試儀(tester)根據規范為iut產生一組測試序列 (test sequence),然后觀察iut的外部行為是否符合規范的描述[7,8]。
圖1 一致性測試原理示意圖
目前的實際工程測試中,測試序列主要是由少數專家憑借經驗制定的。因為原始的規范通常都是自然語言描述的,不同的實現者在使用形式化語言建模的過程中,就可能產生了一個一致性問題:原始規范和形式化規范之間可能在語義上產生偏差。根據這樣衍生的形式化描述產生的測試序列不能作為判斷是否通過一致性測試的依據。
對于一致性測試的過程,大約需要分五個步驟來完成[8],圖2是一致性測試的過程。
圖2 一致性測試的過程
第一步,分析測試需求。也就是說,分析相應的標準或規范,從中找出一組測試標準,建立用于實現的一致性描述pics(protocol implement conformance statement)。每個pics應該盡可能的簡單并且僅僅集中在一個原子功能上,測試標準之間要做到不相抵觸。
第二步,在pics上增加一些用于測試實現的協議實現額外信息pixit(protocol implementation extra information statement),pics和pixit就組成用于測試實現的一致性信息citi(conformanee information for testing the implementation)。
第三步,基于citi,生成一組抽象的測試用例atc(abstract test case)的集合——抽象測試套件ats(abstract test suite)。
第四步,對各atc中的參數選擇合適的輸入值以及相應的“預測結果”,得到可執行的測試用例etc(executable test case)的集合——可執行的測試套件ets(executable test suite)。當然,生成的可執行測試套件是與所處的測試平臺是密切相關的。
第五步,對被測單元uut(unit under test)執行etc的時候,被測單元的測試過程將會產生一個“通過”或“失敗”的報告。報告“失敗”即未能通過測試則意味著與規范不一致。
2 一致性自動化測試方法
目前測試過程中的“生成ets”、“測試uut”等工作步驟中實現了簡單的測試系統,能夠對一些工作實現自動化,如根據手工輸入的modbus協議的從站號、功能號、地址等參數生成測試用例,能夠自動執行測試用例并生成簡要測試報告。但這些測試過程存在以下問題:測試用例的生成需要大量的人為干預;另外,測試結果只是簡要的測試報告,沒有更進一步的分析報告,以幫助用戶更容易地確定問題所在。
如圖2虛線框部分所示,“生成ets”、“測試uut”等工作步驟可以實現測試自動化。自動化后的體系結構如圖3所示。其中可視化用例設計器、測試用例生成器完成測試用例的自動生成工作;測試結果分析器完成測試結果的自動分析工作。限于篇幅對測試結果的自動分析方法不予展開論述,主要論述測試用例的自動生成方法。
圖3 一致性測試過程的自動化示意圖
通常在一致性測試過程中,測試用例的設計和生成是軟件測試的關鍵任務和難點,據統計,約有40%一致性測試開銷用于設計和生成測試用例上。長期以來,測試用例的設計和生成主要依靠手工完成,這意味著要求測試人員具有相當的經驗和較高的專業水平。因此,實際工程中的測試用例生成往往帶有很大的盲目性,主要依靠直覺經驗產生測試用例,這導致測試用例數量多,測試效果差,測試成本居高不下。另外,如何生成最能發現被測系統(或程序)存在問題的測試用例,如何能用最少的測試用例實現足夠大的覆蓋率,也是測試人員一直追求的目標。這些問題的解決方案就是測試用例的自動生成[10]。
2.1 測試用例的自動生成方法的體系結構
圖3中的測試用例自動生成器是測試用例自動生成工作的核心。其體系結構如圖4所示。
其中用例設計描述是描述用例特性的文本,根據所選擇的算法不同而描述方式也不同:如采用“基于形式規格說明的方法”則用z,vdm,obj,larch [11]等語言來描述,如采用“組合覆蓋方法”則用xml腳本來描述。
圖4 測試用例自動生成器的體系結構
算法適配器為各種算法提供接口,它向上為描述解析器提供算法支持服務,向下解釋各種算法,使得體系結構能夠兼容多種算法而增強體系結構的擴展性和適用范圍。
描述解析器基于算法適配器來分析用例設計描述,將描述統一轉換成用例生成器可識別的內部描述形式,然后傳遞給用例生成器。
用例生成器獲得來自描述解析器的內部描述,并根據描述自動生成可執行測試用例。可執行的測試用例支持多種形式存儲,如內存存儲、文件存儲、數據庫存儲等,具體的存儲格式隨用例執行器的需求而變。
2.2 測試用例的自動生成方法的實現
為了驗證體系結構的合理性和有效性,基于microsoft vc 6.0 sp6、modbus activex控件、“分類樹方法”、cte xl(classification tree editor extended logics)實現了modbus協議一致性測試的自動化系統。
其中cte xl是我們系統中的可視化用例設計器,它是一個語法控制的、可視化、圖形化的編輯器。幫助我們更加有效地使用分類樹方法進行測試用例的設計。
分類樹方法是黑盒測試中的一種部分測試方法,由grochtmann 和grinun 提出,后又由chen 和poon 改進[11],它是一種有效的功能測試方法。分類樹方法的基本思想是: 首先逐層劃分測試對象的輸入域,然后將劃分的獨立的類結合為無冗余的測試用例,這些測試用例覆蓋了整個輸入數據域。
算法適配器、描述解析器、用例生成器、分類樹方法均使用microsoft vc 6.0 sp6實現。
modbus activex控件用來執行用例并生成測試報告。該控件具有多線程、多任務、多優先級等特性,支持modbus serial line/tcp通信協議,支持rtu和ascii兩種通信模式,具有良好的性能。
系統實際使用時,首先用cte xl構建用例設計,也就是生成z語言描述的規格說明,然后描述解析器解析該規格說明并生成測試用例模板(系統內部格式),交由用例生成器生成可執行的測試用例,最后由modbus activex控件用來執行用例并生成測試報告。人工參與的部分只是在第一步,即用cte xl構建用例設計,其余部分均自動完成,大大降低測試人員的工作量,提高了測試工作的效率和客觀性。
該實現已經被應用到“山東石油化工廠裝車管理系統”中用來測試管理系統和油氣批量控制儀之間modbus通信,也被應用到“長慶單井計量信息系統”中用來測試信息系統和plc之間的modbus通信,限于篇幅測試過程不贅述,經過測試發現了一些隱藏的modbus一致性問題并且便于使用,提高了一致性測試有效性和客觀性,同時增強了產品的可靠性和可用性,也證明了本文所論述的一致性測試自動化方法的有效性和實用性。
3 結 語
在分析了現有modbus協議一致性測試中存在的問題后,本文提出了一致性測試的自動化方法,基于這個方法設計并實現了一致性測試系統,在實際應用中該系統發現一些隱藏的modbus一致性問題,提高了modbus一致性測試的有效性和客觀性,證明了該方法的有效性和實用性。目前該方法的實現基于分類樹方法,下一步將研究其他測試用例自動生成方法,使其進一步完善。
編輯整理
參考文獻
