本發(fā)明涉及軟件測試領(lǐng)域，具體涉及一種面向平臺(tái)插件的測試方法。

背景技術(shù)：

針對傳統(tǒng)的軟件開發(fā)模式，軟件測試一般采用具有代表意義的V測試模型。V模型僅僅把測試過程看作是軟件開發(fā)過程中一系列串行活動(dòng)的最后一個(gè)階段，忽略了軟件測試不僅包括程序，還應(yīng)對相應(yīng)的需求和設(shè)計(jì)進(jìn)行測試，導(dǎo)致需求分析階段隱藏的問題到后期的驗(yàn)收階段才可能被發(fā)現(xiàn)，并且該模型不能對測試流程的完整性進(jìn)行體現(xiàn)。

按照傳統(tǒng)的開發(fā)模式，測試階段分為：單元、軟件和系統(tǒng)測試。平臺(tái)插件的開發(fā)模式中，系統(tǒng)化分為一個(gè)個(gè)獨(dú)立功能的插件，多個(gè)插件聯(lián)合完成獨(dú)立業(yè)務(wù)功能，沒有軟件配置項(xiàng)的明確劃分，傳統(tǒng)測試階段的劃分已經(jīng)不完全適用。

插件簇是插件的依賴，協(xié)作關(guān)系形成的邏輯關(guān)系，插件簇的形成類似于插件集成，傳統(tǒng)的集成測試方式有一次性集成和增殖式方式。插件簇沒有層次的控制概念，因此傳統(tǒng)的集成測試方式不適用于插件簇測試。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的主要目的在于提供一種面向平臺(tái)插件技術(shù)的測試方法，并進(jìn)行項(xiàng)目應(yīng)用，驗(yàn)證提出的測試方法的可行性，為后續(xù)基于平臺(tái)插件開發(fā)方式的系統(tǒng)測試提供方法基礎(chǔ)。

為了實(shí)現(xiàn)上述目的，本發(fā)明提出了一種面向平臺(tái)插件技術(shù)的測試方法，包括測試模型選取，測試策略確定，測試設(shè)計(jì)和測試實(shí)施，具體包括以下步驟：

測試模型選?。悍治龈鳒y試模型的特點(diǎn)，并結(jié)合平臺(tái)插件的開發(fā)方式，采用H測試模型進(jìn)行指導(dǎo)測試；

測試策略確定：依據(jù)被測系統(tǒng)的平臺(tái)插件的體系架構(gòu)，將被測系統(tǒng)的測試內(nèi)容進(jìn)行分層；所述分層的層數(shù)最多三層，該三層具體為：插件層、插件簇層和系統(tǒng)業(yè)務(wù)場景層，插件層為最底層，系統(tǒng)業(yè)務(wù)場景層為最高層；

測試設(shè)計(jì)：對插件層、插件簇層和系統(tǒng)業(yè)務(wù)場景層逐層進(jìn)行測試設(shè)計(jì)，具體為：

對插件層中的底層基礎(chǔ)插件和核心插件采用傳統(tǒng)測試法設(shè)計(jì)測試用例，依據(jù)測試用例分別對底層基礎(chǔ)插件和核心插件進(jìn)行灰盒測試；

根據(jù)插件的協(xié)作、依賴關(guān)系，從完成獨(dú)立功能的角度，將插件按照邏輯劃分為插件簇；對插件簇采用基于UML的插件化的集成測試用例設(shè)計(jì)思想進(jìn)行測試設(shè)計(jì)生成測試用例，依據(jù)測試用例對插件簇層進(jìn)行黑盒測試；

根據(jù)插件簇之間的銜接以及協(xié)作關(guān)系，梳理出所有系統(tǒng)業(yè)務(wù)場景形成系統(tǒng)業(yè)務(wù)場景層，采用場景法設(shè)計(jì)測試用例，依據(jù)測試用例對系統(tǒng)業(yè)務(wù)場景層進(jìn)行黑盒測試；

測試實(shí)施：根據(jù)H測試模型對測試設(shè)計(jì)的測試用例逐層進(jìn)行測試實(shí)施。

其中，插件簇由一個(gè)或者多個(gè)插件組成，一個(gè)插件隸屬于一個(gè)或者多個(gè)插件簇；系統(tǒng)業(yè)務(wù)場景層包含一個(gè)或者多個(gè)插件簇，所有插件簇組成被測系統(tǒng)。

其中，步驟3所述的插件簇采用基于UML的插件化的集成測試用例設(shè)計(jì)思想進(jìn)行測試設(shè)計(jì)生成測試用例，具體為：插件簇采用基于UML的插件化的集成測試用例設(shè)計(jì)思想，并根據(jù)測試準(zhǔn)則生成操作序列長度各異的插件簇的初始測試用例，當(dāng)插件簇中包含多個(gè)插件，且插件都進(jìn)行了測試設(shè)計(jì)時(shí)，根據(jù)插件的測試用例的驗(yàn)證角度從初始測試用例中選取沒有包含和交叉關(guān)系的測試用例生成插件簇的測試用例。

其中，從初始測試用例中選擇操作序列長度最大的操作序列對應(yīng)的測試用例，再考慮測試用例的包含和交叉關(guān)系。

其中，所述步驟4具體包括以下步驟：

(401)當(dāng)單獨(dú)的底層基礎(chǔ)插件或核心插件具備測試條件時(shí)，進(jìn)行插件的測試實(shí)施；

(402)當(dāng)插件簇內(nèi)對應(yīng)的底層基礎(chǔ)插件和核心插件已經(jīng)測試通過后，對單獨(dú)的插件簇進(jìn)行測試實(shí)施；

(403)當(dāng)所有的插件簇已經(jīng)測試通過后，對系統(tǒng)業(yè)務(wù)場景層進(jìn)行測試實(shí)施。

其中，所述步驟(401)具體為：當(dāng)單獨(dú)的底層基礎(chǔ)插件或核心插件具備測試條件時(shí)，依據(jù)插件的使用手冊和內(nèi)部實(shí)現(xiàn)編寫測試驅(qū)動(dòng)程序，通過測試驅(qū)動(dòng)程序調(diào)用被測插件，依據(jù)測試用例對被測插件進(jìn)行測試實(shí)施。

本發(fā)明相比背景技術(shù)的有益效果：

(1)H測試模型可以盡早和并行測試，有效避免錯(cuò)誤的影響范圍擴(kuò)大，解決了開發(fā)與測試，以及測試過程內(nèi)部的協(xié)同問題，縮短了項(xiàng)目研發(fā)周期；

(2)根據(jù)被測系統(tǒng)開發(fā)模式的特性，實(shí)施分層測試方法，權(quán)衡了插件的復(fù)雜性和測試充分性準(zhǔn)則問題，對底層基礎(chǔ)插件和核心插件的測試達(dá)到較高的覆蓋率，增強(qiáng)了平臺(tái)框架的健壯性和穩(wěn)定性；

(3)探索并提出的一套相對通用的基于UML的插件化的新的集成測試用例設(shè)計(jì)思想，解決了插件開發(fā)帶來的測試問題，為后續(xù)基于平臺(tái)插件開發(fā)方式的系統(tǒng)的集成測試提供方法基礎(chǔ)，通過對該測試方法的應(yīng)用和測試實(shí)施，驗(yàn)證了本發(fā)明提出的測試方法的有效性，同時(shí)有效保證了系統(tǒng)的穩(wěn)定性和安全性。

(4)測試用例的復(fù)用在后續(xù)項(xiàng)目升級改造之時(shí)或者其他類似項(xiàng)目新研時(shí)，大部分插件功能不用再重復(fù)開發(fā)，只需要進(jìn)行專用插件定制與插件集成。相應(yīng)的，在對底層基礎(chǔ)插件和核心插件以及插件簇測試后，對基于被測系統(tǒng)新搭建的系統(tǒng)，可以復(fù)用相應(yīng)的插件或插件簇測試用例，或進(jìn)行測試用例組合，對新系統(tǒng)進(jìn)行插件組裝測試和系統(tǒng)測試，測試重點(diǎn)為基于典型或特定應(yīng)用的系統(tǒng)測試。

附圖說明

圖1是本發(fā)明的任務(wù)管控平臺(tái)體系架構(gòu)成圖；

圖2是本發(fā)明的方案修正服務(wù)契約插件的類關(guān)系圖；

圖3是本發(fā)明方案修正服務(wù)插件的修正接收方案方法的活動(dòng)圖；

圖4是本發(fā)明的多平臺(tái)任務(wù)統(tǒng)籌分析功能集成圖；

圖5是本發(fā)明的多平臺(tái)任務(wù)統(tǒng)籌分析功能用例圖；

圖6是本發(fā)明的多平臺(tái)任務(wù)分析籌劃插件組處理過程序列圖；

圖7是本發(fā)明的航天任務(wù)處理流程序列圖；

圖8是本發(fā)明的觀測任務(wù)可行性分析插件內(nèi)的序列圖；

圖9是本發(fā)明的TaskFeasbilityAnalyze類關(guān)系；

圖10是本發(fā)明的AeraDeal處理流程；

圖11是本發(fā)明的基于場景的測試框架。

具體實(shí)施方式

為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚明白，以下結(jié)合具體實(shí)施例，并參照附圖，對本發(fā)明作進(jìn)一步的詳細(xì)說明。

本發(fā)明提出了一種面向平臺(tái)插件技術(shù)的測試方法，該方法對基于OSGI規(guī)范的插件集成框架，采用C#語言開發(fā)實(shí)現(xiàn)的任務(wù)管控平臺(tái)進(jìn)行應(yīng)用和實(shí)踐，任務(wù)管控平臺(tái)的體系架構(gòu)如圖1所示?；诓捎玫臏y試模型，測試策略和測試設(shè)計(jì)方法，分別進(jìn)行基礎(chǔ)插件和核心插件的接口，功能測試，插件簇的集成測試和系統(tǒng)測試。

一種面向平臺(tái)插件技術(shù)的測試方法，包括以下步驟：

步驟1：測試模型選?。悍治龈鳒y試模型的特點(diǎn)，并結(jié)合平臺(tái)插件的開發(fā)方式，采用H測試模型進(jìn)行指導(dǎo)測試；

采用H測試模型，將每個(gè)層次的測試活動(dòng)完全獨(dú)立出來，只要測試條件成熟，測試準(zhǔn)備活動(dòng)完成，測試執(zhí)行活動(dòng)就可以進(jìn)行。有效解決了盡早測試、獨(dú)立測試、并行測試和迭代測試的問題。

采用該模型，對不同的被測件可以分層次進(jìn)行，將測試和開發(fā)緊密結(jié)合，同步進(jìn)行，并有效縮短測試時(shí)間。

步驟2：測試策略確定：依據(jù)被測系統(tǒng)的平臺(tái)插件的體系架構(gòu)，將被測系統(tǒng)的測試內(nèi)容進(jìn)行分層；所述分層的層數(shù)最多三層，該三層具體為：插件層、插件簇層和系統(tǒng)業(yè)務(wù)場景層，插件層為最底層，系統(tǒng)業(yè)務(wù)場景層為最高層；

插件開發(fā)具有分布開發(fā)、動(dòng)態(tài)插拔特點(diǎn)，插件的完整性，獨(dú)立性高于傳統(tǒng)單元的特性，結(jié)合傳統(tǒng)的測試步驟劃分，確定了插件的測試層；插件的靈活配置特點(diǎn)，可按照不同的功能需求自由組合形成插件簇，沒有軟件配置項(xiàng)的明確劃分，確定了插件簇的測試層；與傳統(tǒng)的系統(tǒng)測試對應(yīng)的提出了系統(tǒng)業(yè)務(wù)場景層的測試。

采用平臺(tái)插件開發(fā)模式開發(fā)的系統(tǒng)，當(dāng)插件數(shù)量多時(shí)，逐個(gè)插件開展插件測試的工作量大。權(quán)衡插件的復(fù)雜性和測試充分性準(zhǔn)則問題，采用分層測試的測試策略，具體為：

a)對底層基礎(chǔ)插件和核心插件，進(jìn)行基于規(guī)約和基于代碼實(shí)現(xiàn)的插件測試，采用灰盒測試策略，重點(diǎn)考慮插件接口覆蓋、功能覆蓋和路徑覆蓋測試，確保插件接口的一致性，插件使用者調(diào)用插件服務(wù)實(shí)現(xiàn)功能的正確性，從而驗(yàn)證底層和核心插件的穩(wěn)定性。

b)插件簇的測試成為該開發(fā)方式的插件系統(tǒng)的測試重點(diǎn)，在該層次測試過程中，重點(diǎn)關(guān)注插件間交互的覆蓋率、事件覆蓋率、消息覆蓋率等，從而驗(yàn)證插件相互協(xié)調(diào)完成系統(tǒng)業(yè)務(wù)能力的正確性。

c)系統(tǒng)業(yè)務(wù)場景層重點(diǎn)考慮插件簇之間的正確銜接、數(shù)據(jù)流向、以及協(xié)作完成典型應(yīng)用模式下的系統(tǒng)能力。

步驟3：測試設(shè)計(jì)：對插件層、插件簇層和系統(tǒng)業(yè)務(wù)場景層逐層進(jìn)行測試設(shè)計(jì)，具體為：

對插件層中的底層基礎(chǔ)插件和核心插件采用傳統(tǒng)測試法設(shè)計(jì)測試用例，依據(jù)測試用例分別對底層基礎(chǔ)插件和核心插件進(jìn)行灰盒測試；

根據(jù)插件的協(xié)作、依賴關(guān)系，從完成獨(dú)立功能的角度，將插件按照邏輯劃分為插件簇；對插件簇采用基于UML的插件化的集成測試用例設(shè)計(jì)思想進(jìn)行測試設(shè)計(jì)生成測試用例，依據(jù)測試用例對插件簇層進(jìn)行黑盒測試；

根據(jù)插件簇之間的銜接以及協(xié)作關(guān)系，梳理出所有系統(tǒng)業(yè)務(wù)場景形成系統(tǒng)業(yè)務(wù)場景層，采用場景法設(shè)計(jì)測試用例，依據(jù)測試用例對系統(tǒng)業(yè)務(wù)場景層進(jìn)行黑盒測試；

(1)插件測試

a)基礎(chǔ)插件

對于基礎(chǔ)功能的插件進(jìn)行接口測試，采用黑盒測試方法，從插件使用方角度，通過接口契約的調(diào)用參數(shù)，調(diào)用形式等輸入數(shù)據(jù)得到結(jié)果，并進(jìn)行與接口規(guī)范的比較得到測試報(bào)告。

在設(shè)計(jì)接口測試輸入?yún)?shù)時(shí),除了使用傳統(tǒng)的等價(jià)類劃分、邊界值分析等方法外，還要考慮到接口的前置條件和后置條件等約束。同時(shí)根據(jù)插件的功能特定，選取相應(yīng)的動(dòng)態(tài)測試方案。若插件主要用于數(shù)據(jù)交換，則應(yīng)偏重于數(shù)據(jù)的測試，可采用數(shù)據(jù)流的動(dòng)態(tài)測試方案，該方法應(yīng)用到ESB總線服務(wù)的插件測試中。

以工作流作業(yè)調(diào)度插件為例，描述插件接口測試用例設(shè)計(jì)。

步驟3-1-1：從插件的需求規(guī)格說明和使用說明書中，分析插件的接口定義。

工作流引擎服務(wù)，是獨(dú)立部署的webserver，配合第三方工作流產(chǎn)品，負(fù)責(zé)業(yè)務(wù)的調(diào)度。工作流調(diào)度插件是和工作流引擎服務(wù)唯一交互的中間層，它封裝了統(tǒng)一的工作流引擎服務(wù)的交互接口，供插件使用方調(diào)度工作流，接口定義如下：

步驟3-1-2：以正確性和充分性的原則，選取插件的接口數(shù)據(jù)進(jìn)行測試。

包括：合法的輸入數(shù)據(jù)，即所有有效的和期望的數(shù)據(jù)；非法的輸入數(shù)據(jù)，即無效的和不期望的數(shù)據(jù)；能夠表達(dá)上下文相關(guān)的輸入數(shù)據(jù)；各種約束，對輸入數(shù)據(jù)或測試的各種約束。

設(shè)計(jì)的該插件接口測試用例：已定義的工作流信息，不存在的工作流信息。

b)核心功能插件

對于核心功能(服務(wù)類)插件，既測試接口，同時(shí)又考慮服務(wù)的設(shè)計(jì)實(shí)現(xiàn)原理。從插件狀態(tài)與實(shí)現(xiàn)角度出發(fā)，依據(jù)插件設(shè)計(jì)說明中的交互圖，采用灰盒測試方法，制定測試用例，再實(shí)施測試。以方案修改服務(wù)插件為例進(jìn)行測試過程描述。

步驟3-2-1：從插件的設(shè)計(jì)說明中，分析方案修改契約插件的接口定義。

方案修正服務(wù)契約插件(UpdateRecvContact)包含IUpdateRecv類，該類定義了服務(wù)需要實(shí)現(xiàn)的方法。類關(guān)系圖如圖2所示。

輸入?yún)?shù)：

config：待修正的方案配置信息

error：修正過程中返回的錯(cuò)誤信息。

返回值：true表示成功，false表示失敗。

步驟3-2-2：從插件的設(shè)計(jì)說明中，方案修正服務(wù)插件定義了對方案修正的實(shí)現(xiàn)方法，bool Update(ref SchemeConfig config,ref string error)。修正接收方案服務(wù)插件的實(shí)現(xiàn)類所用的邏輯如圖3所示。

依據(jù)邏輯判定條件，分別從調(diào)用預(yù)報(bào)失敗，循環(huán)開始，循環(huán)結(jié)束等多條件分支，設(shè)計(jì)測試用例。

設(shè)計(jì)的該插件接口測試用例有：方案正確的配置信息，不滿足SchemenConfig格式的方案信息，輸入?yún)?shù)不完整的調(diào)用信息。

設(shè)計(jì)的該插件功能測試用例有：調(diào)用測站預(yù)報(bào)失敗用例，只有一個(gè)可匹配的接收時(shí)段修正用例，方案中的多個(gè)接收時(shí)段修正用例，方案中的一個(gè)接收時(shí)段修改接收仰角用例。

步驟3-2-3：在測試環(huán)境中增加模擬數(shù)據(jù)，在數(shù)據(jù)庫中錄入測試用的不同接收方案數(shù)據(jù)。

(2)插件簇測試

由于插件簇是多個(gè)有協(xié)作關(guān)系的插件的集合，因此插件簇測試時(shí)，用例的設(shè)計(jì)變得更加復(fù)雜。需要考慮的：一是各個(gè)插件的順序如何安排；二是如何測試新增加的插件。為了確定上下文相關(guān)關(guān)系，我們采用基于協(xié)作圖和順序圖的方法對測試因素進(jìn)行描述，分析包含類的實(shí)例的UML協(xié)作圖和順序圖，梳理各插件之間的交互關(guān)系，進(jìn)行插件簇劃分和插件簇的測試。

具體實(shí)施過程是，首先從插件需求規(guī)格說明中分析插件組的功能用例圖和功能集成圖；從插件設(shè)計(jì)說明中，找出插件不同級別的過程序列圖。根據(jù)插件間的依賴關(guān)系，構(gòu)造不同的插件簇。對于每個(gè)插件簇采用傳統(tǒng)黑盒測試方法，從盡可能發(fā)現(xiàn)被測插件簇的功能或接口缺陷的角度，設(shè)計(jì)測試用例，最后實(shí)施測試。

以多平臺(tái)任務(wù)分析籌劃插件組為例，具體描述插件簇逐步劃分和插件簇測試的過程。

步驟3-3-1：理解，分析插件組功能

多平臺(tái)任務(wù)分析籌劃插件組的功能為：根據(jù)情報(bào)偵察、軍事測繪等類型任務(wù)要求，統(tǒng)籌考慮各類觀測資源能力，根據(jù)任務(wù)的觀測要求、目標(biāo)特性等進(jìn)行可行性分析與統(tǒng)籌考慮后，將任務(wù)分配給不同的觀測平臺(tái)；

對于航天任務(wù)，結(jié)合衛(wèi)星的觀測能力對區(qū)域任務(wù)進(jìn)行分解，把一個(gè)大區(qū)域需求分解成衛(wèi)星一次觀測可以完成的多個(gè)小任務(wù)；

將衛(wèi)星觀測任務(wù)經(jīng)可行性分析與分解處理后，生成可供任務(wù)規(guī)劃插件組可使用的觀測元任務(wù)。

其中多平臺(tái)任務(wù)統(tǒng)籌分析功能集成圖如圖4所示，多平臺(tái)任務(wù)統(tǒng)籌分析功能用例圖如圖5所示，多平臺(tái)任務(wù)分析籌劃插件組處理過程序列圖如圖6所示。

其中數(shù)據(jù)持久化插件，日志管理插件，地圖顯示插件均為基礎(chǔ)平臺(tái)的插件，在基礎(chǔ)平臺(tái)的插件接口和功能測試已經(jīng)驗(yàn)證。

步驟3-3-2：分析，梳理插件組的過程序列關(guān)系

航天任務(wù)處理流程序列圖如圖7所示，觀測任務(wù)可行性分析插件內(nèi)的序列圖如圖8所示。

步驟3-3-3：依據(jù)插件簇的劃分原則，劃分插件簇，形成的測試簇有：觀測任務(wù)可行性分析簇，航天任務(wù)處理簇，航空任務(wù)處理簇，多任務(wù)統(tǒng)籌分析簇。

步驟3-3-4：逐步分析插件簇內(nèi)的插件類關(guān)系圖，類內(nèi)操作的處理流程圖，再結(jié)合插件簇內(nèi)的UML序列圖的動(dòng)態(tài)行為導(dǎo)出該簇的測試方法序列。

其中觀測任務(wù)可行性分析插件組中的區(qū)域可行性分解的類關(guān)系圖如圖9所示，其中AreaTargetDeal的一個(gè)操作的處理流程如圖10所示。

根據(jù)確定的測試方法，觀測任務(wù)處理簇生成的測試用例為：區(qū)域任務(wù)不能被型號衛(wèi)星訪問、區(qū)域任務(wù)新的訪問條帶已經(jīng)被覆蓋、區(qū)域任務(wù)訪問條帶與需求未覆蓋區(qū)域有交叉、點(diǎn)目標(biāo)被訪問和點(diǎn)目標(biāo)沒有被訪問等。

航天任務(wù)處理簇分析生成測試用例時(shí)，從該簇的操作序列中選取長度最大的操作序列生成初始測試用例，再去除簇中有包含關(guān)系觀測任務(wù)可行性分析簇的功能，綜合考慮不同型號衛(wèi)星的觀測方式上設(shè)計(jì)最終的測試用例。生成的測試用例為：不同型號衛(wèi)星的航天任務(wù)觀測，同一型號衛(wèi)星不同觀測方式的目標(biāo)觀測，不同型號衛(wèi)星側(cè)擺情況下的任務(wù)觀測等。

其他插件簇的測試設(shè)計(jì)不再一一贅述。

(3)系統(tǒng)測試

步驟3-4-1：以需求分析中的設(shè)計(jì)模型為基礎(chǔ)，在插件簇的交互序列中添加約束，通過序列聯(lián)合和序列的精化生成初始場景集，然后從初始場景集中，按照系統(tǒng)的使用方式，選取真實(shí)場景來描述系統(tǒng)的總體行為，再從被測系統(tǒng)的完整性，適用性、健壯性、易用性等角度設(shè)計(jì)生成系統(tǒng)業(yè)務(wù)場景層測試用例?；趫鼍暗臏y試框架如圖11所示。

步驟3-4-2：設(shè)計(jì)測試用例。對不同系統(tǒng)業(yè)務(wù)場景層從有利于檢驗(yàn)的角度設(shè)計(jì)測試用例，重點(diǎn)關(guān)注被測系統(tǒng)功能的正確性，流程變化的適應(yīng)性，以及系統(tǒng)對外接口的一致性。

被測系統(tǒng)主要分為常規(guī)業(yè)務(wù)場景和應(yīng)急業(yè)務(wù)場景。常規(guī)業(yè)務(wù)場景主要功能是面向多用戶提交的觀測需求，調(diào)度多顆衛(wèi)星和地面資源進(jìn)行任務(wù)安排。在實(shí)際使用中多用戶可以同時(shí)啟動(dòng)多個(gè)常規(guī)業(yè)務(wù)，或根據(jù)不同的工作需求定制不同的常規(guī)業(yè)務(wù)流程節(jié)點(diǎn)?；趯?shí)際的使用場景，從插件簇的序列中進(jìn)行篩選，精化生成測試用例。

步驟3-4-3：在實(shí)施系統(tǒng)測試的時(shí)候，根據(jù)需要可以修正并完善用例。

步驟4：測試實(shí)施：根據(jù)H測試模型對測試設(shè)計(jì)的測試用例逐層進(jìn)行測試實(shí)施。

單獨(dú)的底層基礎(chǔ)插件或核心插件的測試實(shí)施，驗(yàn)證插件對外交互接口是否與插件規(guī)范說明一致，插件實(shí)現(xiàn)的功能是否正確。

插件簇的測試實(shí)施，判斷插件簇功能的正確性，以及驗(yàn)證框架對插件數(shù)量逐漸增加的動(dòng)態(tài)加載，即插即用能力，以及平臺(tái)框架的穩(wěn)定性。

對系統(tǒng)業(yè)務(wù)場景層進(jìn)行測試實(shí)施，驗(yàn)證被測系統(tǒng)在系統(tǒng)業(yè)務(wù)場景層實(shí)現(xiàn)系統(tǒng)行為的正確性和合理性，被測系統(tǒng)的完整性，適用性、健壯性、易用性等。

以上所述的具體實(shí)施例，對本發(fā)明的目的、技術(shù)方案和有益效果進(jìn)行了進(jìn)一步詳細(xì)說明，應(yīng)理解的是，以上所述僅為本發(fā)明的具體實(shí)施例而已，并不用于限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所做的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。