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

背景技術(shù)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

附圖說(shuō)明

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

圖2是本發(fā)明的方案修正服務(wù)契約插件的類(lèi)關(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ù)分析籌劃插件組處理過(guò)程序列圖；

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

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

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

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

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

具體實(shí)施方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1)插件測(cè)試

a)基礎(chǔ)插件

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

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

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

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

工作流引擎服務(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)行測(cè)試。

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

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

b)核心功能插件

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

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

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

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

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

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

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

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

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

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

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

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

(2)插件簇測(cè)試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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