專利名稱：基于工作流的通用軟件測試過程模型的建立方法
技術領域：
本發明涉及計算機技術領域，具體涉及一種基于工作流的通用軟件測試過程模型的建立方法。
背景技術：
軟件測試，是指在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復查。軟件測試過程是指軟件測試的不同開發階段，通常包括單元測試、集成測試、系統測試和驗收測試。其中，對每一個測試階段均定義了相關測試人員的進出準則、規范活動及輸出的工作產品。完善的軟件測試過程可以有效的提高軟件測試的質量。現有軟件測試過程模型通常是基于業務邏輯而建立的，當業務發生變動時，原軟件測試過程模型不再適用，因此，現有軟件測試過程模型具有通用性差的缺點。

發明內容
針對現有技術存在的缺陷，本發明提供一種基于工作流的通用軟件測試過程模型的建立方法，將工作流方法引入軟件測試過程，并且基于原子活動邏輯來建立通用軟件測試過程模型，從而提高了通用軟件測試過程模型的通用性。本發明所采用的技術方案如下本發明提供一種基于工作流的通用軟件測試過程模型的建立方法，包括以下步驟SI :將軟件測試過程中的各個業務活動細化，得到原子活動；S2 :定義所述原子活動的要素，得到所述通用軟件測試過程模型的組成結構圖；S3:根據所述組成結構圖通過軟件測試過程描述語言定義元素，并設置與所述元素對應的屬性；通過所述元素和所述屬性得到所述原子活動的原子活動邏輯；S4 :利用XML語言對所述原子活動邏輯進行形式化描述，得到與所述軟件測試過程對應的軟件測試過程模型。優選的，所述原子活動為包括以下信息的活動與所述原子活動對應的輸入數據、 與所述原子活動對應的輸出數據、與所述原子活動對應的操作方法、與所述原子活動對應的參與者信息、與所述原子活動對應的功能和與所述原子活動對應的目的；各個所述原子活動間通過預設邏輯相關聯。優選的，S2中，所述要素包括與所述原子活動對應的軟件測試過程定義、測試參與者的活動、所述原子活動的變遷條件、測試相關數據信息、角色信息、測試參與者信息和應用程序；其中，所述軟件測試過程定義為定義所述軟件測試過程的基本信息，所述基本信息包括所述軟件測試過程的過程簡介信息、所述軟件測試過程的開始時間、所述軟件測試過程的創建者信息；
所述測試參與者的活動為所述測試參與者需要執行的具體任務；所述原子活動的變遷條件為所述原子活動向其他原子活動發生變遷的條件，如果滿足所述變遷條件，則進行變遷，否則不進行變遷；所述測試相關數據信息包括所述原子活動的變遷方向、與所述原子活動對應的控制數據；所述控制數據為全局數據；所述角色信息為所述測試參與者的具體角色；所述測試參與者信息包括所述測試參與者的姓名信息；所述應用程序為被所述原子活動調用的應用程序，所述應用程序為全局變量。優選的,所述組成結構圖為所述原子活動的UML圖。優選的，S3中，所述元素包括源節點、目標節點、轉移條件、活動節點、測試數據、 應用程序、測試參與者；其中，所述活動節點用于標記所述原子活動；所述源節點用于標記與當前連接線的出發點對應的活動節點；所述目標節點用于標記與所述當前連接線的結束點對應的活動節點；所述轉移條件用于標記所述原子活動間的變遷條件，如果滿足所述變遷條件，則由當前原子活動跳轉到下一個原子活動；如果不滿足所述變遷條件，則所述當前原子活動不進行跳轉；所述測試數據用于表示所述軟件測試過程中的所述控制數據，所述測試數據為全
局變量；所述應用程序用于表示被調用的應用程序，所述應用程序為全局變量；所述測試參與者用于標記所述軟件測試過程中各個所述原子活動的參與者，所述測試參與者為全局變量。優選的,所述活動節點包括以下內容手動節點用于標記需要所述測試參與者手動執行的原子活動；自動節點用于標記通過調用所述應用程序完成的原子活動；選擇節點用于標記所述軟件測試過程中多個任務流的匯集情況；并行節點用于標記需要并行執行的多個所述原子活動；子過程節點用于標記子過程活動；開始節點用于標記所述通用軟件測試過程模型的唯一入口點；結束節點用于標記所述通用軟件測試過程模型的唯一出口點。優選的，S4中，所述利用XML語言對所述原子活動邏輯進行形式化描述，具體為分別定義以下內容定義各個標記的公共屬性；定義應用程序；定義變量；定義傳輸線；附加定義活動節點；定義標志節點；定義任務節點；過程定義標記；過程定義XML文件根元素標記。本發明的有益效果如下本發明提供的基于工作流的通用軟件測試過程模型的建立方法，該方法引入工作流方法中相關技術的概念及關系，并參考工作流元模型，設計出通用軟件測試過程模型。該模型克服了一般現有的軟件測試過程模型由于基于業務邏輯而建立所造成的不能夠通用的缺點，當業務發生變動時，該模型依然適用，因此，具有通用性強的優點。


圖I為本發明實施例提供的基于工作流的通用軟件測試過程模型的建立方法的流程示意圖；圖2為本發明實施例提供的業務邏輯和原子活動邏輯的雙層結構圖；圖3為本發明實施例提供的一種原子活動要素的UML圖；圖4為本發明實施例提供的軟件測試過程描述語言的元素層次圖；圖5為本發明實施例提供的語言元素描述軟件測試過程步驟圖；圖6為本發明實施例提供的系統測試基本流程圖。
具體實施例方式以下結合附圖對本發明的一個具體的實施方式進行說明。本發明提供一種基于工作流的通用軟件測試過程模型的建立方法，該方法引入工作流方法中相關技術的概念及關系，并參考工作流元模型，設計出通用軟件測試過程模型。 該模型克服了一般現有的軟件測試過程模型由于基于業務邏輯而建立所造成的不能夠通用的缺點，當業務發生變動時，該模型依然適用。本發明提供的基于工作流的通用軟件測試過程模型的建立方法，如圖I所示，包括以下步驟SlOl :將軟件測試過程中的各個業務活動細化，得到原子活動。本步驟中，將軟件測試過程分兩個層面描述，將業務部分進行細化，分解成更細的原子活動，從而形成高層為業務邏輯，底層為原子活動邏輯的模型，而底層的原子活動邏輯是更為本質的描述方法，并且，原子活動不可再分解，從而提高了軟件測試過程的通用性和靈活性。如圖2所示，為業務邏輯和原子活動邏輯的雙層結構圖。將多個原子活動通過相應的規則連接起來，就形成了一個測試過程。因此，當給定測試對象以后，對軟件測試過程以原子活動為單位細分并加以關聯， 從而能夠實現所有的軟件測試過程中的業務活動都可以由相應的原子活動組合而成。所述原子活動為包括以下信息的活動與所述原子活動對應的輸入數據、與所述原子活動對應的輸出數據、與所述原子活動對應的操作方法、與所述原子活動對應的參與者信息、與所述原子活動對應的功能和與所述原子活動對應的目的；各個所述原子活動間通過預設邏輯相關聯。其中，原子活動間的邏輯通過下面步驟介紹，在此不再贅述。S102:定義所述原子活動的要素，得到所述通用軟件測試過程模型的組成結構圖；本發明中，為每一個原子活動均定義對應的要素，其中，要素的種類可根據實際使用需要進行調整，如圖3所示，為當采用7個要素時，得到的一種原子活動要素的 UML (Unified Modeling Language,統一建模語言)圖，所述要素包括與所述原子活動對應的軟件測試過程定義、測試參與者的活動、所述原子活動的變遷條件、測試相關數據信息、 角色信息、測試參與者信息和應用程序；其中，所述軟件測試過程定義為定義所述軟件測試過程的基本信息，所述基本信息包括所述軟件測試過程的過程簡介信息、所述軟件測試過程的開始時間、所述軟件測試過程的創建者信息；
所述測試參與者的活動為所述測試參與者需要執行的具體任務；所述原子活動的變遷條件為所述原子活動向其他原子活動發生變遷的條件，如果滿足所述變遷條件，則進行變遷，否則不進行變遷；所述測試相關數據信息包括所述原子活動的變遷方向、與所述原子活動對應的控制數據；所述控制數據為全局數據；所述角色信息為所述測試參與者的具體角色；所述測試參與者信息包括所述測試參與者的姓名信息；所述應用程序為被所述原子活動調用的應用程序，所述應用程序為全局變量。S103:根據所述組成結構圖通過軟件測試過程描述語言定義元素，并設置與所述元素對應的屬性；通過所述元素和所述屬性得到所述原子活動的原子活動邏輯；本發明中，定義的元素的具體數量根據實際需要進行調整，本實施例中，以提供7 個元素為例進行說明。如圖4所示，為軟件測試過程描述語言的元素層次圖，如圖5所示， 為語言元素描述軟件測試過程步驟圖，所述元素包括源節點、目標節點、轉移條件、活動節點、測試數據、應用程序、測試參與者；其中，所述活動節點用于標記所述原子活動；所述源節點用于標記與當前連接線的出發點對應的活動節點；所述目標節點用于標記與所述當前連接線的結束點對應的活動節點；所述轉移條件用于標記所述原子活動間的變遷條件，如果滿足所述變遷條件，則由當前原子活動跳轉到下一個原子活動；如果不滿足所述變遷條件，則所述當前原子活動不進行跳轉；所述測試數據用于表示所述軟件測試過程中的所述控制數據，所述測試數據為全局變量；如判斷“轉移條件”是否為真時所需要的數據即為控制數據。所述應用程序用于表示被調用的應用程序，所述應用程序為全局變量；所述測試參與者用于標記所述軟件測試過程中各個所述原子活動的參與者，所述測試參與者為全局變量。進一步的,所述活動節點包括以下內容手動節點用于標記需要所述測試參與者手動執行的原子活動；自動節點用于標記通過調用所述應用程序完成的原子活動，而不需要人工參與;選擇節點用于標記所述軟件測試過程中多個任務流的匯集情況；并行節點用于標記需要并行執行的多個所述原子活動；子過程節點用于標記子過程活動，用于比較復雜的軟件測試過程描述；開始節點用于標記所述通用軟件測試過程模型的唯一入口點，它沒有前驅節點， 所有的軟件測試過程模型都是從開始節點執行，然后根據相關條件節點激活后續活動節占.結束節點用于標記所述通用軟件測試過程模型的唯一出口點，它沒有后續節點， 一旦激活了結束節點，則整個軟件測試過程結束。S104 :利用XML(extensible markup language,可擴展標記語言)語言對所述原子活動邏輯進行形式化描述，得到與所述軟件測試過程對應的軟件測試過程模型。
7
所述利用XML語言對所述原子活動邏輯進行形式化描述，具體為分別定義以下內容定義各個標記的公共屬性；定義應用程序；定義變量；定義傳輸線；附加定義活動節點； 定義標志節點；定義任務節點；過程定義標記；過程定義XML文件根元素標記。利用XML語言對底層原子活動邏輯進行形式化描述，提供與平臺無關的模型表示方法。該描述有利于軟件測試過程在跨平臺或多平臺實現。因此，當給定一個測試對象的時候，根據以上步驟即可方便的對該軟件測試對象定義一個測試過程，實現對測試過程的形式化、標準化的描述，再經過具體的一系列工作， 得到有效的測試結果。基于工作流的思想，通過使用本發明提供的軟件測試過程模型，將軟件測試過程分解成八層結構，使用XML語言八層結構進行描述。下面以基于GJBZ-141標準體系的軟件系統測試中的一個階段性過程為例，介紹該通用軟件測試過程模型的應用方式。基于GJBZ-141的軟件系統測試是以完整的、集成的計算機系統為測試對象，目的是在真實系統或仿真系統工作環境下，驗證完整的軟件配置項能否和系統正確連接、并滿足系統或子系統設計文檔和軟件開發任務書規定的要求。系統測試的人員配置如下測試項目負責人管理監督測試項目、提供技術指導、獲取適當的資源、指定基線、 技術協調、負責項目的安全保密和質量管理。測試分析員確定測試計劃、測試內容、測試方法、測試數據生成方法、測試(軟、 硬件)環境、測試工具、評估測試工作的有效性。測試設計員設計測試用例，確定測試用例的優先級，建立測試環境。測試程序員編寫測試輔助軟件。測試員執行測試、記錄測試結果。測試系統管理員對測試環境和資產進行管理和維護。配置管理員設置、管理和維護測試配置管理數據庫。系統測試一般由軟件的需方組織、由獨立于軟件開發的組織實施。如果系統測試由第三方實施，必須是軍方認可的第三方測試組織。系統測試要求強化配置管理，已經通過測試的系統狀態和各項參數應詳細記錄， 歸檔保存，未經測試負責人允許，任何人無權改變。系統測試過程由四個階段組成，分別是測試策劃階段、測試設計與實現階段、測試執行階段、測試總結階段。每個階段都會有相應的驗證工作，如果該階段的測試工作通過驗證，則開始下一階段，否則繼續迭代執行本階段工作。每個測試階段都由很多測試任務構成，篇幅所限，我們只介紹測試設計與實現、測試執行兩個階段的測試任務。在測試設計與實現階段，測試設計人員和測試程序員應該完成以下測試工作任務I)設計測試用例將需測試的軟件特性分解，針對分解后的每種情況設計測試用例，每個測試用例的設計應符合GJBZ-141標準的要求；2)獲取測試數據包括獲取現有的測試數據和生成新的測試數據，并按照要求驗證所有數據；3)確定測試順序可從資源約束、風險以及測試用例失效造成的影響等方面考慮；4)獲取測試資源對于支持測試的軟件，有的需要從現有的工具中選定，有的需要開發；5)編寫測試程序包括開發測試支持工具；6)建立和校準測試環境；7)按照GJBZ-141標準編寫系統測試說明；8)評審和驗證。在明確了軟件測試過程實例的基本內容之后，我們開始用軟件測試過程描述語言來描述這個測試過程實例。首先要對測試過程實例做深入分析。經分析可知，測試過程實例包括一個有4個任務節點的串行的過程，這四個過程分別為測試策劃、測試設計與實現、測試執行、測試總結，每個測試任務節點之間都有相應的轉換條件。如由測試策劃階段轉向測試設計與實現階段的轉換條件為測試策劃通過評審。即如果轉換條件不滿足，那么測試策劃階段繼續迭代進行。實例對各階段的人員配置做了明確的說明測試策劃階段由測分析員參與；測試設計與實現階段由測試設計員和測試程序員參與；測試執行階段由測試員和測試分析員參與，測試總結階段由測試分析員參與。 圖6明確地表示了該測試過程。下面介紹如何利用軟件測試過程描述語言描述該流程第一步定義全局變量。測試過程實例的流程涉及到了四次驗證，每次驗證都需要有一個條件判斷，因此可將四個驗證條件定義為BOOL型的全局變量，具體如下定義BOOL型的全局變量TestSchemeIsOK,若該變量的值為True，表明測試策劃階段驗證通過；若值為False,表明驗證未通過。定義BOOL型的全局變量DesignandlmplementationIsOK,若該變量的值為True, 表明測試設計與實現階段驗證通過；若值為False，表明驗證未通過。定義BOOL型的全局變量TestExecutionIsOK,若該變量的值為True，表明測試執行階段驗證通過；若值為False，表明驗證未通過。定義BOOL型的全局變量TestSumlsOK，若該變量的值為True，表明測試總結階段驗證通過；若值為False,表明驗證未通過。用軟件測試過程描述語言描述這四個全局變量<datas>
〈Data dataType=’BOOL’ default Value=5 False description=’驗證測試策劃， id=’Check01，mergeRule=，0’ name=’ TestSchemelsOK’〉
〈Data dataType=’BOOL’ defaultValue=5False5 description=’驗證設計與實現’ id=’Check02’ mergeRule=’。’ name=’ DesignandlmplementationIsOK5 >
<Data dataType=’BO〇L’ default Value=5 False description=’驗證測試執行’ id=’Check03’ mergeRule=，0’ name=5 TestExecutionIsOK5 >
〈Data dataType=’B0〇L’ default Value=5 False description=’ 驗證測試總結, id=’Check04’ mergeRule=^7 name=’ TestSumlsOK’〉
</datas>第二步分析并定義各節點類型。首先，分析四個任務節點，每一個節點實際上都是子過程節點(其中測試設計與實現、測試執行兩個子過程節點在后文中會詳細描述)，各個子過程節點之間是順序關系， 用WF-STPDL分別定義，我們先給出描述，然后進行解釋，具體如下測試策劃階段的任務節點定義
<SubprocNode ID=7TestStepOr description=，測試策劃階段 ’ name=， TestScheme5 >
〈targets/〉
<sources/>
<extendProperties/>
<subProc processed=’SubO I’ processName=’ TestSchemeSubProcess’ serverName=’？’ versionName=’？，〉
<subProcParams/>
</SubprocNode>測試設計與實現階段的任務節點定義〈SubprocNode ID=，TestStep02’ description=’測試設計與實現階段’ name=’ DesignandImplementation5 >
〈targets/〉
<sources/>
<extendProperties/>
<subProcprocessed=’Sub02’processName=’
DesignandImplementationSubProcess’ ServerName=5 5 versionName=’？’〉 <subProcParams/>
〈/SubprocNode〉測試執行階段的任務節點定義
〈SubprocNode ID=’TestStep03’ description=5 測試執行階段 ’ name=’ TestExecution5 >
〈targets/〉
〈sources/〉
<extendProperties/>
<subProc processed=5 SubOS5 processName=’ TestExecutionSubProcess, serverName=，？’ versionName=’？，〉
<subProcParams/>
〈/SubprocNode〉測試總結階段的任務節點定義〈SubprocNode ID=’TestStep04’ description=’測試總結階段’ name=’ TestSum5
>
〈targets/〉
<sources/>
<extendProperties/>
<subProc processed=’Sub04’ processName=5 TestSumSubProcess， serverName=，？’ versionName=’？，〉
<subProcParams/>
〈/SubprocNode〉因為開始和結束標記節點、傳輸線等數據尚未定義，因而任務節點定義中相應的屬性值暫時未空。下面開始定義開始節點和結束節點開始節點的定義
〈StartNode ID=’Start’ description=’測試開始 ’ name=’TestStart’> 〈sources/〉
<extendProperties/>
</StartNode>結束節點定義
〈EndNode ID=5End5 description=’測試結束’ name=’TestEncf> 〈targets/〉
<extendProperties/>
〈/EndNode〉同理，因傳輸線等數據尚未定義，因而標記節點定義中相應的屬性值暫時為空。下面開始定義傳輸線。本過程測試實例包含5條傳輸線，每條傳輸線包含一個轉換條件，下面分別定義各傳輸線開始節點到測試策劃任務節點的傳輸線定義〈Transition description= ’開始至測試策劃’ id=’tran01， name=,tranOr priority=’I’ source=’Start’ target=’ TestStepOl’>
〈expression condition=,NULL7>
〈/Transition〉測試策劃到測試設計與實現的傳輸線定義
〈Transition description=，測試策劃到測試設計與實現，id=’tran02’ name=’tran02’ priority=’2’ source=7TestStepOT target=5 TestStep02,>
〈expression condition=’ TestSchemelsOKV>
〈/Transition〉測試設計與實現到測試執行的傳輸線定義
〈Transition description=，設計與實現到測試執行， id=’tran03’ name=’tran03’ priority=^5 source=5TestStep025 target=5 TestStep03’>
〈expression condition=’ DesignandImplementationIsOKV>
〈/Transition〉測試執行到測試總結的傳輸線定義
〈Transition description=’ 測試執行到測試總結’ id=’tran04’ name=’tran04’ priority=^5 source=’TestStep03’ target=’ TestStep04,>
〈expression condition=’ TestExecutionIsOK V>
〈/Transition〉測試總結到過程實例結束的傳輸線定義
〈Transition description=’ 測試總結到過程實例結束 5 id=’tran05’ name=’tran05’ priority=555 source=5TestStep045 target=5 End’>
〈expression condition=’ TestSumlsOK’/〉
〈/Transition〉以上是5條傳輸線的定義，這些定義需要用傳輸線集合標簽組織起來，傳輸線集合標簽的定義為〈transitions/〉，它包含 0 個或以上的〈Transition/〉標記。定義完全部傳輸線之后，標記節點和任務節點的屬性即可以補全，且節點之間的聯系也建立起來了。
然后，我們需要定義測試過程實例的根節點和過程定義標記，它們用于描述實例的基本情況，具體如下
< xm1 version="l .0” encoding^^UTF-8,5 >
〈model: ProcessContent>
〈ProcessID=5 SystemTestInstance5buildTime=’12/9/2010’
builder=5QiaomuWang5 modifiedTime=，Null’ name=’ SystemTestInstance ’ ver si onNam e=5 B etaO I，>
〈/Process〉
〈/model :ProcessContent>最后，依據傳輸線、標記節點、任務節點之間的屬性對應關系，將任務節點和標記節點的相關屬性補充完整，就得到了最終的基于WF-STPDL的實例過程描述，代碼如下
< xml Version=tiI .0” encoding=“UTF-8’’？>
〈model: ProcessContent>
〈ProcessID=5 SystemTestInstance5
builder=7 QiaomuWang5 modifiedTime=’Null’ name=
buildTime=，12/9/2010， SystemTestInstance ’VersionName=5BetaO r>
<!--下面是全局變量節點-->
<datas>
〈Data dataType=’BOOL，defaultValue=Talse’ description=’驗證測試策劃’ id=’CheckOI’ mergeRule=’。’ name=’ TestSchemelsOK’〉
〈Data dataType=’BOOL’ default Value=7 F al se7 description=’驗證設計與實現’ id=’Check02’ mergeRule=,。’ name=’ DesignandlmplementationIsOK’ >
〈Data dataType=’BOOL’ defaultValue=Talse5 description=’驗證測試執行’ id=’Check03’ mergeRule=，。’ name=5 Te stExecutionl sOK5 >
〈Data dataType=’BOOL’ default Value=5 F al se, description=’ 驗證測試總結’ id=’Check04’ mergeRule=，。’ name=, TestSumlsOK’〉
</datas>
<!--下面是傳輸線節點-->
〈transitions〉
<!__開始節點到測試策劃任務節點的傳輸線定義->
〈Transition description=’ 開始至測試策劃 ’ id=’tran01 ’ name=^tranOI ’ priority= 5T source=’Start’target=’ TestStepO T >
〈expression condition=,NULL7>
〈/Transition〉
<!--測試策劃到測試設計與實現的傳輸線定義
〈Transition description=，測試策劃到測試設計與實現，id=’tran02’ name=’tran02’ priority=’2’ source=。TestStepOI’ target=’ TestStep02’>
〈expression condition=’ TestSchemelsOK7>
〈/Transition〉
<!--測試設計與實現到測試執行的傳輸線定義
〈Transition description=’ 設計與實現到測試執行 ’ id=’tran03’ name=5tran035 priority=’3’ source=，TestStep02’ target=’ TestStep03’>
〈expression condition=’ DesignandlmplementationIsOK7>〈/Transition〉
<!--測試執行到測試總結的傳輸線定義:
〈Transition description=7 測試執行到測試總結’ id=，tran04’ name=’tran04’ priority=^5 source=’TestStep03’ target=’ TestStep04’>
〈expression condition=’ TestExecutionIsOK 7>
〈/Transition〉
<!--測試總結到過程實例結束的傳輸線定義-->
〈Transition description=’ 測試總結到過程實例結束，id=’tran05’ name=’tran05’ priority=’5’ source=’TestStep04’ target=’ End’>
〈expression condition=5 TestSumlsOK’/〉
〈/Transition〉
<!--下面是標記節點定義 <StartNode ID=’Start’ description=’測試開始 ’ name=’TestStart’>
<sources>
〈source transitionName=,tranOr>
〈/sources〉
</StartNode>
〈EndNode ID=5End5 description=’測試結束’ name=’TestEnd5>
〈targets〉
<target transitioiiName=’tran05 ’>
〈/targets〉
〈/EndNode〉
<!--下面是任務節點定義-->
<!--4個子過程節點-->
〈SubprocNode ID=，TestStepOI，description=，測試策劃階段 ’ name=， TestScheme7 >
〈targets〉
<target transitionName=,traii015>〈/targets〉
<sources>
<source tran siti onNam e=7tran027>
</sources>
<subProc processed=’SubO I’ processName=’ TestSchemeSubProcess’ serverName^’localhost’ versionName=,BataOr>
<subProcParams/>
〈/SubprocNode〉
<SubprocNode ID=’TestStep02’ description=’測試設計與實現階段’ name=’ DesignandImplementation ’ >
〈targets〉
〈target transitionName=,traii02,>
〈/targets〉
<sources>
<source tran si ti onNam e=7 tran 0 37 >
</sources>
<subProcprocessed=’Sub02’processName=’
De signandlmpl ementati on SubPr ocess7serverNamdocalhost’
VersionName=5BataO r>
<subProcParams/>
〈/SubprocNode〉
〈SubprocNode ID=’TestStep03’ description=’ 測試執行階段’ name=’ TestExecution，>
〈targets〉
<target transitionName=’tran03 ’>
〈/targets〉<sources>
〈source transitionName=,tran04 5>
</sources>
<subProc processed=，Sub03’ processName=5 TestExecutionSubProcess5 ServerName=5IocalhoSt5 VersionName=5BateO r>
<subProcParams/>
〈/SubprocNode〉
〈SubprocNode ID=’TestStep04’ description=’ 測試總結階段 ’ name=’ TestSum, >
〈targets〉
〈target transitionName=,tran03 7>
</targets>
<sources>
〈source transitionName=,tran04 5>
</sources>
<subProc processed=’Sub04’ processName=’ TestSumSubProcess， ServerName=5IocalhoSt5 VersionName=5BataO r>
<subProcParams/>
〈/SubprocNode〉
〈/Process〉
</model:ProcessContent>以上是用WF-STPDL描述的一個簡單的軟件系統測試過程實例。以上所述僅是本發明的優選實施方式，應當指出，對于本技術領域的普通技術人員來說，在不脫離本發明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應視本發明的保護范圍。
權利要求
1.一種基于工作流的通用軟件測試過程模型的建立方法，其特征在于，包括以下步驟Si:將軟件測試過程中的各個業務活動細化，得到原子活動；52:定義所述原子活動的要素，得到所述通用軟件測試過程模型的組成結構圖；53:根據所述組成結構圖通過軟件測試過程描述語言定義元素，并設置與所述元素對應的屬性；通過所述元素和所述屬性得到所述原子活動的原子活動邏輯；54:利用XML語言對所述原子活動邏輯進行形式化描述，得到與所述軟件測試過程對應的軟件測試過程模型。
2.根據權利要求I所述的方法，其特征在于，所述原子活動為包括以下信息的活動■ 與所述原子活動對應的輸入數據、與所述原子活動對應的輸出數據、與所述原子活動對應的操作方法、與所述原子活動對應的參與者信息、與所述原子活動對應的功能和與所述原子活動對應的目的；各個所述原子活動間通過預設邏輯相關聯。
3.根據權利要求I所述的方法，其特征在于，S2中，所述要素包括與所述原子活動對應的軟件測試過程定義、測試參與者的活動、所述原子活動的變遷條件、測試相關數據信息、角色信息、測試參與者信息和應用程序；其中，所述軟件測試過程定義為定義所述軟件測試過程的基本信息，所述基本信息包括所述軟件測試過程的過程簡介信息、所述軟件測試過程的開始時間、所述軟件測試過程的創建者信息；所述測試參與者的活動為所述測試參與者需要執行的具體任務；所述原子活動的變遷條件為所述原子活動向其他原子活動發生變遷的條件，如果滿足所述變遷條件，則進行變遷，否則不進行變遷；所述測試相關數據信息包括所述原子活動的變遷方向、與所述原子活動對應的控制數據；所述控制數據為全局數據；所述角色信息為所述測試參與者的具體角色；所述測試參與者信息包括所述測試參與者的姓名信息；所述應用程序為被所述原子活動調用的應用程序，所述應用程序為全局變量。
4.根據權利要求I所述的方法，其特征在于，S2中，所述組成結構圖為所述原子活動的 UML 圖。
5.根據權利要求I所述的方法，其特征在于，S3中，所述元素包括源節點、目標節點、 轉移條件、活動節點、測試數據、應用程序、測試參與者；其中，所述活動節點用于標記所述原子活動；所述源節點用于標記與當前連接線的出發點對應的活動節點；所述目標節點用于標記與所述當前連接線的結束點對應的活動節點；所述轉移條件用于標記所述原子活動間的變遷條件，如果滿足所述變遷條件，則由當前原子活動跳轉到下一個原子活動；如果不滿足所述變遷條件，則所述當前原子活動不進行跳轉；所述測試數據用于表示所述軟件測試過程中的所述控制數據，所述測試數據為全局變所述應用程序用于表示被調用的應用程序，所述應用程序為全局變量;所述測試參與者用于標記所述軟件測試過程中各個所述原子活動的參與者，所述測試參與者為全局變量。
6.根據權利要求5所述的方法，其特征在于，所述活動節點包括以下內容手動節點用于標記需要所述測試參與者手動執行的原子活動；自動節點用于標記通過調用所述應用程序完成的原子活動；選擇節點用于標記所述軟件測試過程中多個任務流的匯集情況；并行節點用于標記需要并行執行的多個所述原子活動；子過程節點用于標記子過程活動；開始節點用于標記所述通用軟件測試過程模型的唯一入口點；結束節點用于標記所述通用軟件測試過程模型的唯一出口點。
7.根據權利要求I所述的方法，其特征在于，S4中，所述利用XML語言對所述原子活動邏輯進行形式化描述，具體為分別定義以下內容定義各個標記的公共屬性；定義應用程序；定義變量；定義傳輸線；附加定義活動節點；定義標志節點；定義任務節點；過程定義標記；過程定義XML文件根元素標記。
全文摘要
本發明提供的基于工作流的通用軟件測試過程模型的建立方法，包括以下步驟S1將軟件測試過程中的各個業務活動細化，得到原子活動；S2定義所述原子活動的要素，得到所述通用軟件測試過程模型的組成結構圖；S3根據所述組成結構圖通過軟件測試過程描述語言定義元素，并設置與所述元素對應的屬性；通過所述元素和所述屬性得到所述原子活動的原子活動邏輯；S4利用XML語言對所述原子活動邏輯進行形式化描述，得到與所述軟件測試過程對應的軟件測試過程模型。本發明克服了一般現有的軟件測試過程模型由于基于業務邏輯而建立所造成的不能夠通用的缺點，當業務發生變動時，該模型依然適用，因此，具有通用性強的優點。
文檔編號G06F11/36GK102591779SQ20121000829
公開日2012年7月18日 申請日期2012年1月12日 優先權日2012年1月12日
發明者劉業, 王喬木, 王軼辰, 蔣崇武 申請人:北京賽若科技有限公司, 王軼昆, 王軼辰, 蔣崇武