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

背景技術(shù)：

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

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

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

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

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

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

測試模型選取：分析各測試模型的特點，并結(jié)合平臺插件的開發(fā)方式，采用H測試模型進行指導測試；

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

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

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

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

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

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

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

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

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

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

(401)當單獨的底層基礎(chǔ)插件或核心插件具備測試條件時，進行插件的測試實施；

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

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

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

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

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

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

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

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

附圖說明

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

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

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

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

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

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

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

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

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

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

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

具體實施方式

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

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

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

步驟1：測試模型選取：分析各測試模型的特點，并結(jié)合平臺插件的開發(fā)方式，采用H測試模型進行指導測試；

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

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

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

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

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

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

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

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

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

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

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

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

(1)插件測試

a)基礎(chǔ)插件

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

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

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

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

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

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

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

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

b)核心功能插件

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

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

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

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

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

error：修正過程中返回的錯誤信息。

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

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

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

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

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

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

(2)插件簇測試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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