建筑全性能仿真平臺內核聯合測試平臺的設計與實現

郭 勇， 蘇小紅， 邱 景

（哈爾濱工業大學 計算機科學與技術學院， 哈爾濱150001）

0 引 言

軟件質量的好壞，決定了軟件與需求相一致的程度，以及軟件產品是否可用和生命周期的長短。需求調研不充分或開發人員的疏忽，將導致不合理的設計和軟件缺陷，使軟件存在潛在的危險。 在一定條件下缺陷代碼被執行，會導致軟件運行失效，從而給軟件使用者帶來損失。 頻繁的軟件故障會使軟件不可用，且會帶來極大危害。 為了避免在開發時引入軟件故障，軟件測試應貫穿整個軟件開發過程。通常，軟件測試主要包括單元測試、集成測試和系統測試。 單元是一個比較籠統的概念［1］，一個單元可以是一個方法、一個模塊、一個類或是一個組件。 單元測試主要是在初期，確定各個基本部分是否符合要求。 單元通過測試，并不能保證單元與單元之間是否能協調工作。 在通過單元測試的基礎上，還要進行集成測試，以此確定相關聯單元組裝在一起是否能夠正常工作。 為了更好的實現松耦合，可采用基于構件技術的軟件開發，每個構件也可看作一個單元，它把構成系統的各個部分從系統邏輯中清晰地分離出來。 每個單元均采用統一的標準進行開發，然后組裝在一起，構成整個系統。 目前，許多軟件都采用了基于構件的軟件開發方法［2］。 對于每個構件，用戶并不需要了解內部細解，這樣可以加速軟件開發，但也給測試帶來了困難。 因此，要保證構件組成系統的正常工作，就要對基于構件開發的系統及時進行全面的回歸測試。 由于手工操作無法實現快速準確的回歸測試，因此通常采用自動測試方法。

1 相關工作

自動測試框架通常由假設、概念以及為自動化測試提供支持的實踐集合組成［3］。 自動測試框架的種類較多，如：基于數據驅動的軟件自動化測試框架［4］、基于關鍵字的自動化測試框架［5］、基于用例的自動化測試框架驅動［6－7］的等等。 然而，由于軟件開發的方法和采用技術的多樣性，任何一個自動化測試框架都不能用于所有類型的軟件測試。 因此，對于無法使用通用框架進行測試的系統，則需要定制開發一套適合被測系統的的測試工具。

建筑全性能仿真平臺是為解決我國綠色建筑工作中，建筑熱濕環境及機電系統性能仿真，模擬這一關鍵基礎問題而開發的。 項目目標是解決建筑環境控制多因素共同耦合的復雜問題，它是基于DeST［8］軟件外部擴展功能接口開發的，內核中采用了基于功能模型接口（FMI）、功能模型單元（FMU）及聯合仿真（ Co－Simulation） 技術，由模型建立、模擬計算、節能評估等模塊構成［9］。 實現了建筑負荷與獨立人行為功能模型單元的聯合仿真，并判斷出建筑節能設計方法的適用性。 在建筑全性能仿真平臺內核上，可以擴展多個功能模塊。 比如人行為、遮光采陽、系統及冷熱源模擬等。 由于采用了FMI 標準，每個功能模塊可以單獨開發，獨立功能模塊開發完成后完成組裝，再進行集成測試。 由于整個平臺內核由多個單位聯合開發，給內核的聯合測試帶來不便。 另外，每個模塊的測試數據量都非常龐大，生成的結果數據可能會有幾十萬條，根本無法通過人工方式對結果數據進行誤差分析［10］。

本文提出了一種建筑全性能仿真平臺內核功能正確性聯合在線測試方法，該方法可以直接對源代碼進行測試，代碼從管理平臺（比如：Github）同步到測試端，并自動編譯生成相應模塊；測試人員可自行創建測試用例、自動保存測試用例、隨時修改測試用例、指定測試通過標準；該工具提供相應的管理功能，測試人員及審核人員可通過軟件進行通信。 審核人員對測試結果審核評估，并及時反饋給測試人員。

2 系統需求

建筑全性能仿真平臺內核聯合測試平臺是一個分布式測試平臺，平臺主要包括：用戶管理、代碼管理、測試項目管理、測試用例管理、代碼編譯及語法檢測、模塊組裝、被測程序自動執行、結果判定及結果審核等功能。

用戶管理：主要包括用戶的新建、管理范圍設置、刪除用戶、修改用戶、查詢用戶及權限分配。

代碼管理：用戶可以通過該功能自動從代碼開發管理平臺同步代碼到測試平臺，并可隨時更新被測代碼。

測試項目管理：用戶以項目為單位創建測試項目，每個項目中可以創建一個或多個測試用例。

測試用例管理：主要是對測試用例參數進行設置、測試標準文件進行上傳更新、重命名。

代碼編譯及語法檢測：用于對被測代碼進行編譯進行語法檢查，生成統一標準的測試模塊。 完成測試前的模塊與內核組裝，建立通信聯系。

被測程序自動執行：主要是自動執行被測程序，收集計算結果，自動實現計算結果的比對，并存入數據庫中。

結果判定及審核：主要用于檢查不符合計算精度的項，反饋給開發人員做為模塊改進的依據。 若計算結果符合要求，則審核通過，鎖定該版本。

根據主述需求，系統結構如圖1 所示。

圖1 系統功能結構Fig.1 Functional structure of the system

3 系統設計及實現

軟件設計結構有許多種，但分層結構是最為流行的軟件設計方式。 分層結構有效的降低了單個問題的規模和整個系統設計的復雜度。 系統采用分層結構，具有良好的可擴展性、易于維護，上層使用下層的各種服務，每一層都對自己的上層隱藏其下層的細節，這樣可更好的保證系統設計上的高內聚、松耦合。 因此，本平臺在設計上采用分層結構。

3.1 總體設計

系統采用分層結構，共分為五層：UI（User Interface）層、業務層、持久層、服務層和數據層。 系統架構如圖2 所示。

UI 層是系統和用戶之間進行交互的接口，實現信息的內部形式與用戶接受形式之間的轉換。 本系統以Web 方式顯示相應的操作界面，為用戶提供相應的操作，具體功能由業務層提供。

業務層是系統架構中體現核心價值的部分。 業務規則的制定、流程的實現等，與業務需求有關的處理都在該層實現。 業務邏輯層在體系架構中的位置很關鍵，它處于持久層、服務層中間，起到了數據交換中承上啟下的作用。

圖2 建筑全性能仿真平臺內核聯合測試平臺架構Fig.2 Architecture of federated testing platform for building full performance simulation

持久層主要負責對用例數據、日志數據、帳戶數據、結果數據的訪問操作。

為了方便分布式處理，服務層將一部分功能以服務的形式提供給業務層。 其中包括：編譯服務、文件上傳服務、文件解壓縮服務和測試服務等。

數據層主要包括用來存貯信息的數據庫。

3.2 核心流程設計

平臺在設計上支持多用戶同時在線使用，需要同時處理多個用戶的并發請求。 為此，系統采用了多任務面向服務的多進程處理方法。 進程分為服務端進程隊列和客戶端進程。 為了保證在線用戶的服務質量，系統采用了限制進程數量的方法。 為了提高處理效率系統起動時需創建一個進程隊列，用于多任務處理，每個任務由一個進程處理。 初始進程隊列中的進程數是計算機內核的整數倍。 當檢測到用戶請求時，從進程隊列中取出一個進程，處理客戶的請求，完成客戶請求后，將進程重新放入隊列中。客戶－服務器進程的流程如圖3 所示。

當創建測試進程后，測試進程首先獲取測試用例路徑，然后讀取測試程序，創建相應測試目錄，啟動測試。 程序流程如圖4 所示。

3.3 代碼同步設計

由于模塊開發者分布在全國各地，通常是將代碼放在托管平臺進行管理，模塊開發完成后，需要進行聯合測試，這樣就需要將代碼放在聯合測試平臺。手動將代碼拷貝到測試平臺非常麻煩且不方便，而一般的工具又無法直接用到聯合測試平臺。 為解決代碼自動同步的問題。 本文將這一環節設計為，由聯合測試平臺自動完成同步操作。

圖3 客戶－服務器進程Fig.3 Client－server process

圖4 測試進程流程Fig.4 Test process flow

在測試人員創建測試項目時，通過參數設置的方式，將代碼管理平臺的信息保存在測試項目配置信息中（即：在參數設置中，可指定被測代碼所在的服務器）。 在代碼管理或執行測試前，測試人員在進行代碼同步時，系統會根據設置的代碼服務器地址，從服務器端將代碼同步到被測平臺。 為了代碼安全，被測代碼被保存在聯合測試平臺服務器端，測試人員不能接觸到后端代碼，這樣確保了代碼的安全。 代碼管理平臺與測試平臺的通信關系如圖5 所示。

圖5 代碼管理平臺與測試平臺的關系Fig.5 The relationship between code management platform and test platform

3.4 主要功能模塊的設計及實現

3.4.1 系統管理模塊的設計

系統管理主要功能是用戶管理和角色管理，這些功能主要是管理人員使用。 用戶管理主要是用戶的新建、管理范圍設置、刪除用戶、修改用戶、查詢用戶及權限分配。 其中權限管理使用了角色及具體權限相結合的方法。 權限分配界面如圖6 所示。

圖6 權限管理Fig.6 Privilege Management

系統通過角色和具體權限設定給每個用戶分配權限。 其中，超級用戶初始設置時使用，其它用戶要通過具有管理用戶權限的人員創建，不支持自己注冊。 用戶名、密碼輸入正確進入系統后的界面會根據登錄用戶擁有的權限，顯示相應的信息和可操作的功能項。

3.4.2 項目管理模塊的設計

項目管理主要是創建項目和進入項目執行代碼同步、測試用例輸入、編譯程序、評測、設置項目信息等針對該項目的其它功能。 創建項目時需要輸入項目名稱、簡介、GITURL、GIT 上的被測程序分支名。使用聯合測試平臺時，要求將被測試的程序保存在GIT 服務器上。 需要指定被測程序在GIT 上的地址及GIT 分支，同時還要提供服務器公鑰并將該公鑰加到GIT 服務器。

3.4.3 代碼管理模塊的設計

代碼管理實現了從GIT 服務器下載或更新被測程序到本測試平臺。 這里采用的多進程方式，在進行同步時創建一個子進程，單獨處理代碼同步操作。若已執行從服務器同步代碼的操作，界面中會顯示同步的文件及目錄，供操作人員選擇相應操作。 文件列表采用分頁方式顯示，頁面最下面一行有向前、向后翻頁的按鈕。 界面設計如圖7 所示。

圖7 代碼管理界面設計Fig.7 Code management interface design

3.4.4 測試用例管理模塊的設計

操作人員可創建測試用例、輸入測試命令、刪除測試用例，也可執行評測。 可以列出已經創建好的測試用例，包括“編號、命令、允許誤差、創建時間、創建人”。 其中，“允許誤差”是指當預期結果與實際結果偏差小于等于該值是，則認為通過了測試。“創建”或“修改”測試用例時，可以輸入此值。

選擇某一測試用例后點擊“評測”，即可進行自動執行該測試用例的評測工作；或者點擊左側選擇框，選中某些測試用例進行評測。 也可以點擊“評測所有測試用例”對列表中的所有用例進行評測。每一條后面的“修改”項，可用來修改該條測試用例的測試命令； “測試用例”項可用來上傳被測文件和預期結果文件。

3.4.5 編譯文件的管理

對從GIT 服務器同步到本系統的代碼需進行編譯，編譯成功會生成執行文件，否則需要通知編程人員修改被測程序，并重新上傳至GIT 服務器。 編譯后的文件管理包括：壓縮文件、將文件復制到某個測試用例中、將文件復制到指定位置、文件重命名、創建文件夾。

3.4.6 代碼聯合測試

測試前要保證各項信息設置正確，評測才能正常進行。 若已有完成的評測任務，界面中應顯示評測任務列表，其中包括該任務的“編號、類型、創建時間、結束時間，狀態、通過、未通過、用例總數”等信息。 “通過”表示該任務通過測試的用例數；“未通過”則表示測試結果未達到誤差要求；“出錯”表示測試時出錯的用例數。 “未通過”的測試任務界面如圖8 所示。

圖8 評測結果未通過時Fig.8 When the evaluation result fails

3.4.7 審核功能模塊的設計及實現

經過上述測試，如果測試結果符合要求則發出審核請求，該項目進入被審核狀態。 審核時該項目被鎖定，許多操作將被限制，直到審核完畢。 審核通過后的項目狀態如圖9 所示。

圖9 審核界面Fig.9 Audit interface

4 結束語

針對由大量獨立模塊組成的建筑全性能仿真平臺內核，為了驗證其功能正確性及其能耗計算是否達到精度要求，提出了建筑全性能仿真平臺內核聯合測試平臺的設計與實現方案。 平臺在設計上采用了面向服務的分層設計結構，驗證方法采用了國際建筑能耗對比標準。 通過程序間對比法和實驗驗證法，對建筑全性能仿真平臺內核功能正確性及計算準確性進行了測試，實現了對全性能仿真平臺計算內核的全面檢驗。 測試平臺從代碼管理平臺直接同步代碼到測試平臺，簡化了測試流程，被測模塊源代碼直接在測試平臺被編譯并組裝運行，避免了不同平臺模塊間的兼容問題。 經過實際使用表明，所設計實現的平臺達到了預期要求，完全滿足實際需要。