郭 勇， 蘇小紅， 邱 景

（哈爾濱工業(yè)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院， 哈爾濱150001）

0 引 言

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

1 相關(guān)工作

自動(dòng)測(cè)試框架通常由假設(shè)、概念以及為自動(dòng)化測(cè)試提供支持的實(shí)踐集合組成［3］。 自動(dòng)測(cè)試框架的種類(lèi)較多，如：基于數(shù)據(jù)驅(qū)動(dòng)的軟件自動(dòng)化測(cè)試框架［4］、基于關(guān)鍵字的自動(dòng)化測(cè)試框架［5］、基于用例的自動(dòng)化測(cè)試框架驅(qū)動(dòng)［6－7］的等等。 然而，由于軟件開(kāi)發(fā)的方法和采用技術(shù)的多樣性，任何一個(gè)自動(dòng)化測(cè)試框架都不能用于所有類(lèi)型的軟件測(cè)試。 因此，對(duì)于無(wú)法使用通用框架進(jìn)行測(cè)試的系統(tǒng)，則需要定制開(kāi)發(fā)一套適合被測(cè)系統(tǒng)的的測(cè)試工具。

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

本文提出了一種建筑全性能仿真平臺(tái)內(nèi)核功能正確性聯(lián)合在線測(cè)試方法，該方法可以直接對(duì)源代碼進(jìn)行測(cè)試，代碼從管理平臺(tái)（比如：Github）同步到測(cè)試端，并自動(dòng)編譯生成相應(yīng)模塊；測(cè)試人員可自行創(chuàng)建測(cè)試用例、自動(dòng)保存測(cè)試用例、隨時(shí)修改測(cè)試用例、指定測(cè)試通過(guò)標(biāo)準(zhǔn)；該工具提供相應(yīng)的管理功能，測(cè)試人員及審核人員可通過(guò)軟件進(jìn)行通信。 審核人員對(duì)測(cè)試結(jié)果審核評(píng)估，并及時(shí)反饋給測(cè)試人員。

2 系統(tǒng)需求

建筑全性能仿真平臺(tái)內(nèi)核聯(lián)合測(cè)試平臺(tái)是一個(gè)分布式測(cè)試平臺(tái)，平臺(tái)主要包括：用戶管理、代碼管理、測(cè)試項(xiàng)目管理、測(cè)試用例管理、代碼編譯及語(yǔ)法檢測(cè)、模塊組裝、被測(cè)程序自動(dòng)執(zhí)行、結(jié)果判定及結(jié)果審核等功能。

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

代碼管理：用戶可以通過(guò)該功能自動(dòng)從代碼開(kāi)發(fā)管理平臺(tái)同步代碼到測(cè)試平臺(tái)，并可隨時(shí)更新被測(cè)代碼。

測(cè)試項(xiàng)目管理：用戶以項(xiàng)目為單位創(chuàng)建測(cè)試項(xiàng)目，每個(gè)項(xiàng)目中可以創(chuàng)建一個(gè)或多個(gè)測(cè)試用例。

測(cè)試用例管理：主要是對(duì)測(cè)試用例參數(shù)進(jìn)行設(shè)置、測(cè)試標(biāo)準(zhǔn)文件進(jìn)行上傳更新、重命名。

代碼編譯及語(yǔ)法檢測(cè)：用于對(duì)被測(cè)代碼進(jìn)行編譯進(jìn)行語(yǔ)法檢查，生成統(tǒng)一標(biāo)準(zhǔn)的測(cè)試模塊。 完成測(cè)試前的模塊與內(nèi)核組裝，建立通信聯(lián)系。

被測(cè)程序自動(dòng)執(zhí)行：主要是自動(dòng)執(zhí)行被測(cè)程序，收集計(jì)算結(jié)果，自動(dòng)實(shí)現(xiàn)計(jì)算結(jié)果的比對(duì)，并存入數(shù)據(jù)庫(kù)中。

結(jié)果判定及審核：主要用于檢查不符合計(jì)算精度的項(xiàng)，反饋給開(kāi)發(fā)人員做為模塊改進(jìn)的依據(jù)。 若計(jì)算結(jié)果符合要求，則審核通過(guò)，鎖定該版本。

根據(jù)主述需求，系統(tǒng)結(jié)構(gòu)如圖1 所示。

圖1 系統(tǒng)功能結(jié)構(gòu)Fig.1 Functional structure of the system

3 系統(tǒng)設(shè)計(jì)及實(shí)現(xiàn)

軟件設(shè)計(jì)結(jié)構(gòu)有許多種，但分層結(jié)構(gòu)是最為流行的軟件設(shè)計(jì)方式。 分層結(jié)構(gòu)有效的降低了單個(gè)問(wèn)題的規(guī)模和整個(gè)系統(tǒng)設(shè)計(jì)的復(fù)雜度。 系統(tǒng)采用分層結(jié)構(gòu)，具有良好的可擴(kuò)展性、易于維護(hù)，上層使用下層的各種服務(wù)，每一層都對(duì)自己的上層隱藏其下層的細(xì)節(jié)，這樣可更好的保證系統(tǒng)設(shè)計(jì)上的高內(nèi)聚、松耦合。 因此，本平臺(tái)在設(shè)計(jì)上采用分層結(jié)構(gòu)。

3.1 總體設(shè)計(jì)

系統(tǒng)采用分層結(jié)構(gòu)，共分為五層：UI（User Interface）層、業(yè)務(wù)層、持久層、服務(wù)層和數(shù)據(jù)層。 系統(tǒng)架構(gòu)如圖2 所示。

UI 層是系統(tǒng)和用戶之間進(jìn)行交互的接口，實(shí)現(xiàn)信息的內(nèi)部形式與用戶接受形式之間的轉(zhuǎn)換。 本系統(tǒng)以Web 方式顯示相應(yīng)的操作界面，為用戶提供相應(yīng)的操作，具體功能由業(yè)務(wù)層提供。

業(yè)務(wù)層是系統(tǒng)架構(gòu)中體現(xiàn)核心價(jià)值的部分。 業(yè)務(wù)規(guī)則的制定、流程的實(shí)現(xiàn)等，與業(yè)務(wù)需求有關(guān)的處理都在該層實(shí)現(xiàn)。 業(yè)務(wù)邏輯層在體系架構(gòu)中的位置很關(guān)鍵，它處于持久層、服務(wù)層中間，起到了數(shù)據(jù)交換中承上啟下的作用。

圖2 建筑全性能仿真平臺(tái)內(nèi)核聯(lián)合測(cè)試平臺(tái)架構(gòu)Fig.2 Architecture of federated testing platform for building full performance simulation

持久層主要負(fù)責(zé)對(duì)用例數(shù)據(jù)、日志數(shù)據(jù)、帳戶數(shù)據(jù)、結(jié)果數(shù)據(jù)的訪問(wèn)操作。

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

數(shù)據(jù)層主要包括用來(lái)存貯信息的數(shù)據(jù)庫(kù)。

3.2 核心流程設(shè)計(jì)

平臺(tái)在設(shè)計(jì)上支持多用戶同時(shí)在線使用，需要同時(shí)處理多個(gè)用戶的并發(fā)請(qǐng)求。 為此，系統(tǒng)采用了多任務(wù)面向服務(wù)的多進(jìn)程處理方法。 進(jìn)程分為服務(wù)端進(jìn)程隊(duì)列和客戶端進(jìn)程。 為了保證在線用戶的服務(wù)質(zhì)量，系統(tǒng)采用了限制進(jìn)程數(shù)量的方法。 為了提高處理效率系統(tǒng)起動(dòng)時(shí)需創(chuàng)建一個(gè)進(jìn)程隊(duì)列，用于多任務(wù)處理，每個(gè)任務(wù)由一個(gè)進(jìn)程處理。 初始進(jìn)程隊(duì)列中的進(jìn)程數(shù)是計(jì)算機(jī)內(nèi)核的整數(shù)倍。 當(dāng)檢測(cè)到用戶請(qǐng)求時(shí)，從進(jìn)程隊(duì)列中取出一個(gè)進(jìn)程，處理客戶的請(qǐng)求，完成客戶請(qǐng)求后，將進(jìn)程重新放入隊(duì)列中。客戶－服務(wù)器進(jìn)程的流程如圖3 所示。

當(dāng)創(chuàng)建測(cè)試進(jìn)程后，測(cè)試進(jìn)程首先獲取測(cè)試用例路徑，然后讀取測(cè)試程序，創(chuàng)建相應(yīng)測(cè)試目錄，啟動(dòng)測(cè)試。 程序流程如圖4 所示。

3.3 代碼同步設(shè)計(jì)

由于模塊開(kāi)發(fā)者分布在全國(guó)各地，通常是將代碼放在托管平臺(tái)進(jìn)行管理，模塊開(kāi)發(fā)完成后，需要進(jìn)行聯(lián)合測(cè)試，這樣就需要將代碼放在聯(lián)合測(cè)試平臺(tái)。手動(dòng)將代碼拷貝到測(cè)試平臺(tái)非常麻煩且不方便，而一般的工具又無(wú)法直接用到聯(lián)合測(cè)試平臺(tái)。 為解決代碼自動(dòng)同步的問(wèn)題。 本文將這一環(huán)節(jié)設(shè)計(jì)為，由聯(lián)合測(cè)試平臺(tái)自動(dòng)完成同步操作。

圖3 客戶－服務(wù)器進(jìn)程Fig.3 Client－server process

圖4 測(cè)試進(jìn)程流程Fig.4 Test process flow

在測(cè)試人員創(chuàng)建測(cè)試項(xiàng)目時(shí)，通過(guò)參數(shù)設(shè)置的方式，將代碼管理平臺(tái)的信息保存在測(cè)試項(xiàng)目配置信息中（即：在參數(shù)設(shè)置中，可指定被測(cè)代碼所在的服務(wù)器）。 在代碼管理或執(zhí)行測(cè)試前，測(cè)試人員在進(jìn)行代碼同步時(shí)，系統(tǒng)會(huì)根據(jù)設(shè)置的代碼服務(wù)器地址，從服務(wù)器端將代碼同步到被測(cè)平臺(tái)。 為了代碼安全，被測(cè)代碼被保存在聯(lián)合測(cè)試平臺(tái)服務(wù)器端，測(cè)試人員不能接觸到后端代碼，這樣確保了代碼的安全。 代碼管理平臺(tái)與測(cè)試平臺(tái)的通信關(guān)系如圖5 所示。

圖5 代碼管理平臺(tái)與測(cè)試平臺(tái)的關(guān)系Fig.5 The relationship between code management platform and test platform

3.4 主要功能模塊的設(shè)計(jì)及實(shí)現(xiàn)

3.4.1 系統(tǒng)管理模塊的設(shè)計(jì)

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

圖6 權(quán)限管理Fig.6 Privilege Management

系統(tǒng)通過(guò)角色和具體權(quán)限設(shè)定給每個(gè)用戶分配權(quán)限。 其中，超級(jí)用戶初始設(shè)置時(shí)使用，其它用戶要通過(guò)具有管理用戶權(quán)限的人員創(chuàng)建，不支持自己注冊(cè)。 用戶名、密碼輸入正確進(jìn)入系統(tǒng)后的界面會(huì)根據(jù)登錄用戶擁有的權(quán)限，顯示相應(yīng)的信息和可操作的功能項(xiàng)。

3.4.2 項(xiàng)目管理模塊的設(shè)計(jì)

項(xiàng)目管理主要是創(chuàng)建項(xiàng)目和進(jìn)入項(xiàng)目執(zhí)行代碼同步、測(cè)試用例輸入、編譯程序、評(píng)測(cè)、設(shè)置項(xiàng)目信息等針對(duì)該項(xiàng)目的其它功能。 創(chuàng)建項(xiàng)目時(shí)需要輸入項(xiàng)目名稱、簡(jiǎn)介、GITURL、GIT 上的被測(cè)程序分支名。使用聯(lián)合測(cè)試平臺(tái)時(shí)，要求將被測(cè)試的程序保存在GIT 服務(wù)器上。 需要指定被測(cè)程序在GIT 上的地址及GIT 分支，同時(shí)還要提供服務(wù)器公鑰并將該公鑰加到GIT 服務(wù)器。

3.4.3 代碼管理模塊的設(shè)計(jì)

代碼管理實(shí)現(xiàn)了從GIT 服務(wù)器下載或更新被測(cè)程序到本測(cè)試平臺(tái)。 這里采用的多進(jìn)程方式，在進(jìn)行同步時(shí)創(chuàng)建一個(gè)子進(jìn)程，單獨(dú)處理代碼同步操作。若已執(zhí)行從服務(wù)器同步代碼的操作，界面中會(huì)顯示同步的文件及目錄，供操作人員選擇相應(yīng)操作。 文件列表采用分頁(yè)方式顯示，頁(yè)面最下面一行有向前、向后翻頁(yè)的按鈕。 界面設(shè)計(jì)如圖7 所示。

圖7 代碼管理界面設(shè)計(jì)Fig.7 Code management interface design

3.4.4 測(cè)試用例管理模塊的設(shè)計(jì)

操作人員可創(chuàng)建測(cè)試用例、輸入測(cè)試命令、刪除測(cè)試用例，也可執(zhí)行評(píng)測(cè)。 可以列出已經(jīng)創(chuàng)建好的測(cè)試用例，包括“編號(hào)、命令、允許誤差、創(chuàng)建時(shí)間、創(chuàng)建人”。 其中，“允許誤差”是指當(dāng)預(yù)期結(jié)果與實(shí)際結(jié)果偏差小于等于該值是，則認(rèn)為通過(guò)了測(cè)試。“創(chuàng)建”或“修改”測(cè)試用例時(shí)，可以輸入此值。

選擇某一測(cè)試用例后點(diǎn)擊“評(píng)測(cè)”，即可進(jìn)行自動(dòng)執(zhí)行該測(cè)試用例的評(píng)測(cè)工作；或者點(diǎn)擊左側(cè)選擇框，選中某些測(cè)試用例進(jìn)行評(píng)測(cè)。 也可以點(diǎn)擊“評(píng)測(cè)所有測(cè)試用例”對(duì)列表中的所有用例進(jìn)行評(píng)測(cè)。每一條后面的“修改”項(xiàng)，可用來(lái)修改該條測(cè)試用例的測(cè)試命令； “測(cè)試用例”項(xiàng)可用來(lái)上傳被測(cè)文件和預(yù)期結(jié)果文件。

3.4.5 編譯文件的管理

對(duì)從GIT 服務(wù)器同步到本系統(tǒng)的代碼需進(jìn)行編譯，編譯成功會(huì)生成執(zhí)行文件，否則需要通知編程人員修改被測(cè)程序，并重新上傳至GIT 服務(wù)器。 編譯后的文件管理包括：壓縮文件、將文件復(fù)制到某個(gè)測(cè)試用例中、將文件復(fù)制到指定位置、文件重命名、創(chuàng)建文件夾。

3.4.6 代碼聯(lián)合測(cè)試

測(cè)試前要保證各項(xiàng)信息設(shè)置正確，評(píng)測(cè)才能正常進(jìn)行。 若已有完成的評(píng)測(cè)任務(wù)，界面中應(yīng)顯示評(píng)測(cè)任務(wù)列表，其中包括該任務(wù)的“編號(hào)、類(lèi)型、創(chuàng)建時(shí)間、結(jié)束時(shí)間，狀態(tài)、通過(guò)、未通過(guò)、用例總數(shù)”等信息。 “通過(guò)”表示該任務(wù)通過(guò)測(cè)試的用例數(shù)；“未通過(guò)”則表示測(cè)試結(jié)果未達(dá)到誤差要求；“出錯(cuò)”表示測(cè)試時(shí)出錯(cuò)的用例數(shù)。 “未通過(guò)”的測(cè)試任務(wù)界面如圖8 所示。

圖8 評(píng)測(cè)結(jié)果未通過(guò)時(shí)Fig.8 When the evaluation result fails

3.4.7 審核功能模塊的設(shè)計(jì)及實(shí)現(xiàn)

經(jīng)過(guò)上述測(cè)試，如果測(cè)試結(jié)果符合要求則發(fā)出審核請(qǐng)求，該項(xiàng)目進(jìn)入被審核狀態(tài)。 審核時(shí)該項(xiàng)目被鎖定，許多操作將被限制，直到審核完畢。 審核通過(guò)后的項(xiàng)目狀態(tài)如圖9 所示。

圖9 審核界面Fig.9 Audit interface

4 結(jié)束語(yǔ)

針對(duì)由大量獨(dú)立模塊組成的建筑全性能仿真平臺(tái)內(nèi)核，為了驗(yàn)證其功能正確性及其能耗計(jì)算是否達(dá)到精度要求，提出了建筑全性能仿真平臺(tái)內(nèi)核聯(lián)合測(cè)試平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)方案。 平臺(tái)在設(shè)計(jì)上采用了面向服務(wù)的分層設(shè)計(jì)結(jié)構(gòu)，驗(yàn)證方法采用了國(guó)際建筑能耗對(duì)比標(biāo)準(zhǔn)。 通過(guò)程序間對(duì)比法和實(shí)驗(yàn)驗(yàn)證法，對(duì)建筑全性能仿真平臺(tái)內(nèi)核功能正確性及計(jì)算準(zhǔn)確性進(jìn)行了測(cè)試，實(shí)現(xiàn)了對(duì)全性能仿真平臺(tái)計(jì)算內(nèi)核的全面檢驗(yàn)。 測(cè)試平臺(tái)從代碼管理平臺(tái)直接同步代碼到測(cè)試平臺(tái)，簡(jiǎn)化了測(cè)試流程，被測(cè)模塊源代碼直接在測(cè)試平臺(tái)被編譯并組裝運(yùn)行，避免了不同平臺(tái)模塊間的兼容問(wèn)題。 經(jīng)過(guò)實(shí)際使用表明，所設(shè)計(jì)實(shí)現(xiàn)的平臺(tái)達(dá)到了預(yù)期要求，完全滿足實(shí)際需要。