15
3. The operational model of the framework
複雜的商業程序引入了工作流程管理系統的概念後，使得這些商業系統在開 發過程中將遵循著一個固定的軟體規格，我們的工作就是基於這些相同的軟體規 格上開發出一套泛用的測試架構，使之可以滿足所有上述工作流程管理系統的特 性以及測試需求，並套用先進的軟體技術如 AOP[17]、IOC[16]等，讓我們的測試 架構得以迅速的移植到不同的 WfMS。
根據 Workflow reference model[7]所述，參與者和 WfMS 中間會有一個使 用者介面(User interface)，負責呈現給使用者各種介面(Figure 1.4)，使用者 根據系統呈現的畫面再給予不同的回應。根據這項特徵，我們的測試平台可以重 新實作一份使用者介面，讓它直接與我們的 Test agent 溝通，Test agent 則是 根據 TS-WfMS 所填寫的內容而決定該如何與 WfMS 互動。TS-WfMS 裡面還必須要讓 使用者填寫實體資源的資料，再執行時我們會將他模擬成一個 Resource pool，
他隨著 TS-WfMS 內的 Flow 敘述而動態模擬真實資源運作。執行過程中我們也要 對於 WfMS 內的 Workflow process 作 Monitor 紀錄各種事件的存取，最後我們將 這份存取記錄放到一個容器內，然後再根據 Agent 接收到的資料做驗證，測試由 系統發展者給定的資料使否滿足系統發展者所預期的結果，以下我們將會依序介 紹 Figure 3.1 內各個元件運作模式：
1. TS-WfMS：系統發展者必須具體指定其系統之規格、資源及限制，然後 整個測試系統根據所定義之資訊運作。TS-WfMS 最少包含以下的資訊：
i. 參與者之 Input/Output 資訊：每個參與者在執行 Activity 可 能的 Input 及 Output 都必須詳細訂定，若有許多不同的可能，
系統必須 Enumerate 所有可能情形加以測試。
ii. Resource 相關資訊：Resource 的啟始數目、運作機制、限制、
錯誤機率還有和 Workflow exception 及 Workflow failure 的 相關性，都必須加以定義。
iii. System constraints ： 系 統 發 展 者 必 須 將 系 統 執 行 的 Constraints 定義，若實際執行違反所定義之 Constraints，
16
就是系統的運作不符合系統發展者的預期，也就是系統有 bugs，
在此我們必須要強調，所有 System constraints 都可能會在 前述三種不同的 Test strategies 執行時所偵測到。
2. Agent：為了達成自動化測試的目標，不能由測試員扮演參與者來和系 統溝通。當 Activity 的執行必須和參與者溝通時，Agent 程式會扮演參 與者來和系統溝通，因此必須根據每系統的不同而實作不能的溝通介面，
諸如 Web Service, HTTP, POP3, SSH, 或是普通的 SOCKET connection。
Agent 必 須 參 考 由 系 統 發 展 者 定 義 的 TS-WfMS 中 的 「 參 與 者 之 Input/Output 資訊」來運作。
3. Execution collector：為了確認 Workflow processes 的執行是否有違 反所定義之 Constraints，系統必須將執行的情形儲存，儲存的方式透 過 AOP[17]來實現，可能的資料收集點如 Figure 3.1 中紅色的長方形所 示，可能位於一個 Workflow definition 被 WfMS 實體化時、結束時、
每個 Activity 開始執行、結束，每個 Activity 執行過程中也可能為資 料收集點。
4. Resource manager：各種實體資源如汽車、行政人員數等，這類的實體 資源並不會真正存在於工作流程管理系統裡，因此必須要有一個完善的 方式來模擬其運作。
5. Validation tool：在 TS-WfMS 中定義的各式 Constraints 都由此檢驗。
有 些 Constraints 是 進 行 Run-time check ， 另 一 些 是 Workflow processes 執行結束後由 Validation tool 檢驗儲存的 Execution log 來決定是否有違反。
17 User interface
Agent Agent
TS-WfMS
Validation tool
Execution - collector
Resource pool
Workflow management system
Resource Manager
Figure 3.1 The operation model of our Testing framework
在開始簡介各個元件的原理及運作方式前，我們先為大家介紹一個實用的 Workflow 範例，此範例會在以下的文章中不斷被引用：
Start of Workflow
End of Workflow
Activity Connection Edge
Condition
Participant Branch A1
A3
A2
A5
A6 Login
success
A4
Register
Send another document Send
document
Receive Message Login fail
Show history
A1: Login activity A2: Register activity A3: Function dispatch activity A4: Send an E-document activity A5: Look the history list activity A6: Receive message activity
Figure 3.2 Electronic-document system – office workflow
18
Figure 3.2 所描述的 Workflow 旨在數位化學校行政系統內的某一個處室環 節，A1 代表此系統自有的帳號登入與驗證，如果驗證成功即往 A3 前進，若失敗 則不斷的重覆執行A1，A1 頁面上可以選擇是否註冊註冊帳號，此選擇是前往 A2 的唯一路徑；A2 的功能是填寫相關註冊資訊；A3 則是一個功能選擇頁面，提供 參與者可以前往 A4，A5，A6 的方式；A4 是撰寫一份電子公文，餐語者可以連 續撰寫很多封公文，撰寫完後需要由另一個 Workflow 來進行送文列印，該 Workflow 將在下述；A5 是觀看目前的參與者的電子公文紀錄，A6 是觀看確認收 到的公文訊息，無論 A4 還是 A5 還是 A6，他們之中任一個 Activity 執行完後此 Workflow 即算執行結束，在此 Workflow 中，他們都需要一位人員的參與，這個 人員可能身兼寫文件以及送文件的工作，因此他會與下面所述的另一個Workflow 使用相同的人員資源。
A4
A1
A3
A2
A1: Login activity A2: Register activity
A3: Print E-document to Paper activity
A4: After send message, make the message to transfer activity Start of
Workflow
End of Workflow Activity Connection
Edge
Condition
Participant Branch Login fail
Register Looking
for document
Transfer document
Figure 3.3 Electronic-document system – worker workflow
Figure 3.3 描述了一個電子公文系統的後端列印送件的流程，目的是在 Figure 3.2 裡的A4 寫完公文後，這個流程即可立即幫他進行送件，而送完件後，
此流程需要對所送件的公文進行標記，讓已送件的公文被註記。Figure 3.3 的 A1 是此流程的登入系統，他的帳號系統資料庫與 Figure 3.2 的帳號系統相同；
A2 是註冊系統，讓新進的人員可以註冊近此公文系統；A3 是列印以及檢視所有
19
以撰寫好且尚未傳送的電子公文，在執行此 Activity 時，他需要印表機以及人員 以及交通車這三項實體資源，因為在此 Activity 內必須涵蓋列印，送件，以及交 通問題；A4 是送件人員對於已送件之公文進行註記的 Activity。
上述兩個範例的完整語法我們將在 經過簡略的介紹範例後，以下子章節分 別探討各個元件的實作方法與運作流程，並在解說的過程中交錯使用以上範例解 釋。
3.1 TS-WfMS
TS-WfMS 在測試過程中扮演著重要的角色，所有測試條件以及資源模擬和 Workflow constraints 條件限制都必須涵蓋在內(Figure 3.4)，以下我們分別 探討他們的實作原理及命名含意。
20
Application section
Resources definition section
Flows definition section
Workflow constraints section Header section
H1 <?xml version="1.0" encoding="UTF-8"?>
H2 <TestScript>
H3 <Applications>
A1 <Application
1>
r1 <!– resources_definition section -->
r2 [R
1]
r3 [R
2]
.
r4 [R
3]
r5 <!– End resources_definition section -->
f1 <!– flows_definition section -->
f2 [F
1]
f3 [F
2]
.
f4 [F
3]
f5 <!– End flows_definition section -->
w1 <!– workflowConstraint_definition section -->
w2 [W
1]
w3 [W
2]
.
w4 [W
3]
w5 <!– End workflowConstraint_definition section -->
</Application
1>
A2 <Application
2> … </Application
2>
A3 <Application
3> … </Application
3>
.
</Applications>
</TestScript>
Figure 3.4 Archetecture of TS-WfMS
在開始簡介 TS-WfMS 文法前，我們先透過 Figure 3.4 來解釋，一份 TS-WfMS 是由五大部分組成：檔頭區段、應用程式區段、資源定義區段、流程定義區段、
工作流程限制定義區段。
1. The header section：TS-WfMS 本身也是 XML 文件，因此必須遵照 XML 的 規格來表示檔頭資訊(H1)，一份 TS-WfMS 的開始節點是 TestScript，而 它包含一個名為 Applications 的子節點(H2~H3)，其涵意是測試 WfMS 上 不同的 Applications。
21
2. The application section：Application 代表在 WfMS 上肢一個即將受測 的 Application，在此我們必須強調 Application 的定義，他可能是由多 個 不 同 的 Workflow definitions 所 組 成 ， 為 了 分 別 不 同 的 受 測 Application，我們賦予此節點一個 id 屬性，用來標名受測系統的不同。
3. Resources definition section：根據我們所描述 WfMS 上的實體資源模 擬問題，我們定義了這個區段，用來描述實體資源的細節，其詳細與法 會在後續子章節描述。
4. Flows definition section：為了支援繁複的 WfMS 與參予者間的互動，
我們藉由定義此區段來達成此項需求，此區段內的定義同時也是 WfMS 內 進行 Concurrent testing 時的依據，在不斷的 Monitor 和 Replay 間藉 由比較輸出的資訊來驗證資訊是否正確。
5. Workflowconstraint definition section ： 系 統 開 發 者 通 常 會 在 Application 內自定義一些條件限制，這個定義區段即是用來協助系統開 發者在交雜測試這些 applicaion 時一併檢查這些條件限制。
經過簡介 TS-WfMS 架構後，我們使用 Table 3.1 更進一步的將完整個撰寫方 式表達出，為了完成一個完整的自動測試環境，每一個 Application 應該要有一 些必備的部分必須撰寫，他們分別是 Resources, Flows, WorkflowConstraints 此三大區段，以下子章節分別探討 TS-WfMS 的組織架構以及實作範例。
Table 3.1 TS-WfMS basic structure
<?xml version=”1.0” encoding=”UTF-8"?>
<TestScript>
<Applications>
<Application id="">
<Resources>
…
</Resources>
<Flows>
…
</Flows>
<workflowconstraints>
22
…
</workflowconstraints>
</Application>
</Applications>
</TestScript>
3.1.1 Resources
Resources 標籤是描述測試 WfMS 內實體資源的語法，此標籤主要目的是要解 決前述測試 WfMS 中內實體資源的問題，它含有一個子節點 Resource，每個 Resource 子節點代表 WfMS 上的一種實體資源，我們可以透過撰寫這個節點的資 訊來告訴測試平台應該如何模擬實體資源。Resources 節點內的基本語法如 Figure 3.5 所示，語法是使用 Extended Backus–Naur form (EBNF)表示[14]，
其中有底線的單字為 Nonterminal symbols，無底線的單字為 Terminal symbols。
23
Resources_Definition Æ <resourses>Resource</resourses>
Resource Æ
<resource>
<type>String</type>
<name>String</name>
<number>INT</number>
[BelongMap]
<states>
State_INFO
</states>
[SpontaneousAction]
<initialState>StateName</initialState>
</resource>{ Resource }
BelongMap Æ <belong num=“INT”>FlowName</belong>{BelongMap}
State_INFO Æ <state Workable=“Decision">StateName</state>{State_INFO}
SpontaneousAction Æ <Spontaneous type=“SCRIPT">
Script
</Spontaneous> |
<Spontaneous type=“SOURCE">
Source
</Spontaneous>|
<Spontaneous type=“IOC">
IOC
</Spontaneous>
Script Æ <![CDATA[ FROM StateName TO StateName [ WHERE Limit ] ]]>{Script}
Source Æ <SourceCode path=“String" package=“String“ classpath=“String“ bindir=“String">String</SourceCode>
{ Source }
IOC Æ <SourceCode path=“String" package=“String“ classpath=“String“ bindir=“String">String</SourceCode>
<ConfigurationFile path=“String">String</ConfigurationFile> { IOC } Limit Æ StateName Operation INT { AND Limit }
Limit Æ WAITING INT { AND Limit } Operation Æ >|>=|<|<=
StateName Æ String FlowName Æ String StateName Æ String
Decision Æ YES|NO|TRUE|FALSE INT Æ [0-9]+
Figure 3.5 Resources definition section syntax
經過簡介語法結構，我們利用實際的語言範例來解釋，如 Table 3.2 所述。
Table 3.2 Resources node’s basic structure
<Resources>
<Resource>
…
</Resource>
24 <Resource>
…
</Resource>
</Resources>
Resource：這個標籤主要用途是用來模擬流程運作中可能會對實體資源的 運作過程，系統發展者可以藉由描述該項資源的數量、型別、歸屬權，以及運作 過程中的可能操作行為，來達到對於該項資源在測試環境中所有可能的狀況分析，
Resource 下所有可能的基本語法如 Table 3.3 所示
Table 3.3 Resource node’s basic structure
<resourse>
<type>car</type>
<name>bus-1</name>
<number>3</number>
<belong num="2">電子送件系統</belong>
<states>
<state Workable="no">GoAway</state>
<state Workable="yes">WAITING</state>
<state Workable="no">ONTIME</state>
<state Workable="no">Late</state>
<state Workable="yes">No Oil</state>
</states>
<Spontaneous type="Script">
<![CDATA[ FROM NO-OIL TO IDLE WHERE WAITING 1 ]]>
</Spontaneous>
<initialState>GOAWAY</initialState>
</resourse>
以下簡介 Resource 標籤內所有可能的子標籤以及屬性：
Type： 系統發展者必須填入此項資源的類型，比如說汽車，或是機車，
或是送件人員，此項標籤可填入的內容是系統發展者對於 WfMS 所使用 到的資源類型進行分類，妥善的分類資源對於 Resource manager 往後 執行模擬測試時會有相當大的助益。
Name： 此項資源的代表名稱。
25
Number：只能填入數字，代表該項資源的總數。
Belong：此項主要是說明這項資源在該 Application 內的歸屬狀況，從 Figure 3.2 以及 Figure 3.3 中可發現，兩個流程都需要人員的協助，
但是實際狀況可能兩邊是不同的辦公室，所以兩個 Workflow 最後需要 人員協助送件或是寫公文的人員也都不同，此時我們可以藉由此項功能，
明確的將此項資源的歸屬權宣告在此。可填入的值為 Workflow 名稱。
此標籤有一個名稱為 Num 的屬性。
Num : 此屬性描述某個 Flow 能夠擁有幾個此類型的資源，只 能填入數字。
States： 此標籤內含 State 子標籤，用來描述某項實體資源所有可能 的狀態，Resource manager 藉由讀取此標籤來辨識該項資源所有可使用 的狀態。
State:此標籤是讓系統發展者描述某項實體的某種狀態，內含一個 名為 Workable 的屬性名稱。
Workable: 描述此 State 在 Resource manager 裡是否屬於可 執行的狀態，可能的值為 Yes, No, True, False。
從上面的例子中，可能的資源狀態如下：
Figure 3.6 human resource and it’s state
Resource /State No Oil
GoAway WAITING ONTIME Late
Bus-1 ˇ ˇ ˇ ˇ ˇ
Nissun ˇ ˇ
Figure 3.7 car resource and it’s state
Resource/State BUSY IDLE REST TIRED VACATION
Human 1 ˇ ˇ ˇ ˇ ˇ
Human 2 ˇ ˇ ˇ ˇ ˇ
26
Figure 3.6 以及 Figure 3.7 是上述例子中可能的資源以 及他的狀態，從此可以看到，相同類型的資源可能因為名稱不 同會有不同的狀態產生，如一般交通車可能會有遲到或者是等 待時間到發車的狀態，可是自用的小客車只有沒有油和準時這 兩項狀態而已。
Spontaneous：此標籤描述此項資源在 Resource manager 中的一些自 我行動的行為，亦稱為資源的預設行為，舉例如電子公文系統內的行政 人員以及交通車，行政人員可能一天只送一次公文，但是可能遇上臨時 狀況而不送文，因此我們可以藉由定義這樣的行為發生機率來模擬實際 運作狀況。Spontaneous 這個標籤擁有一個名為 type 的屬性。
Type: 可能填入的值為 IOC, Source, Script 三種，此三值的差異 在於決定測試平台在模擬實體資源時資源自己的預設行為實作類 型，依照填入的值不同，Spontaneous 的內容填寫方式也不同，詳 述如下：
Source：若選擇填入 Source 代表系統開發者選擇使用實作測 試環境所使用的程式語言來描述該資源的自我預設行為，此時 Spontaneous 標籤的內容必須如填寫一個子標籤如 Table 3.4 所示，子標簽名稱為 SourceCode，解釋如下：
Table 3.4 Spontaneous type = source and it’s detail structure
<Spontaneous type="Source">
<SourceCode path="" package="" classpath=""
bindir="">spontaneous.java</SourceCode>
</Spontaneous>
Resource/State BUSY IDLE REST TIRED VACATION
Human 1 ˇ ˇ ˇ ˇ ˇ
Human 2 ˇ ˇ ˇ ˇ ˇ
27
SourceCode：此標籤可填入的值為該程式檔案的檔案名 稱，他有四種屬性，分別為 path, package, classpath, bindir。
Path：描述此檔案在檔案系統內的路徑，可填入的值 為系統路徑。
Package：描述此檔案的 namespace 標籤名稱，可填 入 的 值 為 實 作 測 試 環 境 的 程 式 語 言 所 提 供 的 namespace 寫法。
Classpath：描述此檔案中所參照到的其他函式庫的 路徑，填入的值為描述參照使用的函式庫之檔案系統 路徑。
Bindir：描述此檔案未來將在哪個路徑被執行，可填 入的值為檔案系統路徑。
IOC：若選擇填入 IOC 表示系統開發者除了指定使用實作 測試環境所使用的程式語言來描述該資源的自我預設行 為外，還額外利用 IOC 來管理這個物件，因此 Spontaneous 標籤的內容除了需要撰寫與指定類型為 Source 的子標籤 外，還必須在撰寫另一個子標籤如 Table 3.5 所示
Table 3.5 Spontaneous type = IOC and it’s detail structure
<Spontaneous type="Source">
<SourceCode path="" package="" classpath=""
bindir="">name.java</SourceCode>
<ConfigurationFile
path="">ioc.xml</ConfigurationFile>
</Spontaneous>
ConfigurationFile：此標籤描述 IOC Container 的設 定檔案名稱，可填入的值為 IOC Container 的設定檔 案名稱，此標籤內有一個名為 path 的屬性。
28
Path：可填入的內容為該檔案在檔案系統的路 徑。
Script：若選擇填入 Script，則 Spontaneous 標籤的內容 必須填入<![CDATA[ Spontaneous ]]>，這個 script 則是 另外定義的動態語言，專門用來描述資源在 Resource manager 裡面的行為，我們在 Figure 3.5 中已有描述，在 此再延伸探討含意。
Table 3.6 Spontaneous Script syntax
Spontaneous Æ FROM StateName TO StateName [ WHERE Limit { AND Limit }
Limit Æ StateName Operation INT { AND Limit } Limit Æ WAITING INT { AND Limit }
Table 3.6 是使用 EBNF 來描述這個 Script 語法，具 體作用是可以提供系統開發者在撰寫 Resources 時可以指 定所描述之實體資源由某種狀態轉換至另一個狀態時可 能會轉變為另一種狀態的機率，或是需要等待時間多久。
InitialState： 每個實體資源在 Resource Manager 中都會有預設的狀態，
在這可以讓系統發展者決定所有資源的預設狀態，可以填入的內容為系 統發展者在 state 標籤內描述過的狀態名稱。
3.1.2 Flows
Flows 標籤主要描述的細節為一個 Application 內所有受測之 flow 的輸入 輸出以及和 Resource Manager 互動的細節，這些細節是為了滿足前述測試 WfMS 所會遇到的繁複的 I/O 問題，Flows 節點內的文法如 Figure 3.8 所述。
29
Flows definition Æ <flows>Flow_Info</flows>
Flow_Info Æ <flow name=“String">
Activity
</flow> { Flow_Info } Activity Æ <Activity name=“String">
Page
</Activity> { Activity } Page Æ <Page seq=“INT">
[Presentation_Info]
[ParticipantInput]
[ParticipantAction]
</Page> { Page }
Presentation_Info Æ <Presentation>
Rule { Rule }
</Presentation>
Rule Æ <rule type="regex" target=“Component">REGEX</rule> |
<rule type=“plaintext" target=“Component">Context</rule>
ParticipantInput Æ <ParticipantInput>
Input { Input }
</ParticipantInput>
Input Æ <data variable=“VariableName“>Value</data>
ParticipantAction Æ <ParticipantAction type="Script">ActionTime_Script</ParticipantAction> |
<ParticipantAction type="Source">ActionTime_Source</ParticipantAction> |
<ParticipantAction type=“IOC">ActionTime_IOC</ParticipantAction>
ActionTime_Script Æ (<before>Script</before>|<around>Script</around>|<after>Script</after>) { ActionTime_Script } ActionTime_Source Æ (<before>Source</before>|<around>Source</around>|<after>Source</after>) { ActionTime_Source } ActionTime_IOC Æ (<before>IOC</before>|<around>IOC</around>|<after>IOC</after>) { ActionTime_IOC }
Script Æ <![CDATA[ FUNCTION ]]>{Script}
Source Æ <SourceCode path=“String" package=“String“ classpath=“String“ bindir=“String">String</SourceCode> { Source } IOC Æ <SourceCode path=“String" package=“String“ classpath=“String“ bindir=“String">String</SourceCode>
<ConfigurationFile path=“String">String</ConfigurationFile> { IOC } INT Æ [0-9]+
Component Æ String REGEX Æ String VariableName Æ String Value Æ String
Figure 3.8 Flows definition section syntax
Figure 3.8 中的 FUNCTION 標籤我們尚未去定義他的內容，因為他的表示方 式比較特殊，因此我們在此提出來以文字描述他的語法，特徵如下：
1. 語法採用 Java 的語法來表達，但是每個 FUNCTION 標籤內可表示的 java 語法只能是一個 Java method 內允許的語法。
2. 我們額外定義幾個在此 FUNCTION 內可以存取的資料結構。
I. WfMSOutput：
Table 3.7 WfMSOutput object method
public static String get(String ComponentName);
WfMSOutput 物件可以存取的 method 如 Table 3.7 所示，系統開發
30
者直接使用 WfMSOutput.get(Component)這樣的敘述句來存取由 WfMS 所傳給測試系統的資訊，其中 Component 所該填入的值是 WfMS 內 GUI Component 的名稱。
II. ResourcePoolManager：
Table 3.8 ResourcePoolManager object method
public static boolean action(String resourceType, String ResourceName, int number, String originalState, String newState);
ResourcePoolManager 物件可以存取的 method 如 Table 3.8 所表示，
系 統 發 展 者 僅 需 在 他 的 Script 中 以 ResourcePoolManager.action(resourceType, ResourceName, number, originalState, newState)即可對該項資源做操作，若操 作成功則會回傳 True，反之回傳 False。
Flows 的大架構如 Table 3.9 所描述，他有一個名為 Flow 的子節點，以下我 們開始簡介各個節點：
Table 3.9 Flows node’s basic structure
<flows>
<flow name="">
…
</flow>
<flow name="">
…
</flow>
…
</flows>
Flow：此標籤內容主要描述一個 Application 裡面要測試的 Flow，Flow 為 一個 Workflow 的基本描述單位，其下有一個 Name 屬性，內容是描述此 Flow 在 WfMS 內的名稱，Agent 利用此名稱在 Runtime 時去抓取此 Flow 資訊，此標籤有 一個名為 Activity 的子節點，每一個 Activity 描述該 Activity 運作時該有的
31
Input, Output, 和操縱實體資源的行為，其中 Activity 又涵蓋了數量不等的 Page，Page 的含意是將一個 Activity 依照他所呈現的不同梯次的輸入以及輸出 分開，因此 Flow 標籤的架構大致如 Table 3.10 所示：
Table 3.10 Flow node’s basic structure
<flow name="flowNameA">
<Activity name="act1">
<Page seq="1">
…
</Page>
<Page seq="2">
…
</Page>
…
</Activity>
<Activity name="act2">
<Page seq="1">
…
</Page>
<Page seq="2">
…
</Page>
…
</ Activity >
…
</flow>
Activity：此標籤代表受測 Flow 內的 Activity 內容，他有一個名為 Name 的 屬性，解釋如下：
Name：此屬性內容是填寫該 Activity 在 Flow 內的真實名稱，以利 Agent 在動態時依照 WfMS 傳來的名稱再去 TS-WfMS 抓取資料。
Page：Activity 的子節點，含意是相同一個 Activity 或許會呈現多次輸出 以及輸入，因此我們利用 Page 這個子節點來描述一次 Activity 的呈現所需 要的輸入，以及輸出規則，還有 Resource manager 的操作，Page 節點有一 名為 Seq 的屬性，且 Page 內含三個主要的節點分別為 Presentation, ParticipantInput, ParticipantAction，他們的含義以及語法如下：
32
Table 3.11 Page node’s basic structure
<Page seq="1">
<Presentation>
…
</Presentation>
<ParticipantInput>
…
</ParticipantInput>
<ParticipantAction type="">
…
</ParticipantAction>
</Page>
Seq：屬性的含意是表示此呈現頁面位於 Activity 運作裡的第幾次 呈現，能填入的值僅有數字。
以下簡介每個 Page 該有的原件介紹：
Presentation： 此標籤含意是將現在執行之 Page 的概況描述進來，
他有一個名為 Rule 的子節點，架構如 Table 3.12 所示，簡介如下：
Table 3.12 Presentation node’s structure
<Presentation>
<rule type="regex" target="url">(rid=)\\d+</rule>
</Presentation>
Rule:此標籤主要是描述驗證此 Page 的輸出是否為正確的，他 含有兩個屬性，分別是 type, target，此標籤的值則是寫下根 據 type 所描述的驗證方式而填寫的內容，此兩屬性簡介如下：
Type：描述驗證方式，可能填入的值有 Regex, Plaintext，
前者代表使用正則表示式來驗證，後者代表使用全文驗 證。
Target：描述驗證的對象，系統發展者可以藉由填入需要 驗證的元件來配合驗證。
ParticipantInput： 這是要求系統發展者將 Page 內可能的輸入列
33
舉出來讓我們可以自動測試，開發者必須把變數名稱跟變數值明確 指定，以供我們來做自動測試，他有一個名為 data 的子節點，此 節點的架構如 Table 3.13 所示，data 節點的解釋如下：
Table 3.13 ParticipantInput node’s basic structure
<ParticipantInput>
<data variable="name">value</data>
</ParticipantInput>
Data：描述輸入的資訊，可填入的值為傳入資訊的數值，此節 點有一個名為 Variable 的屬性，其可填入的值為傳入資訊的 變數名稱。
ParticipantAction： 此標籤目的是與 Resource Manager 配合，
在前面的 Resource 部份我們有介紹了一個 Spontaneous，其涵意是 資源本身的可能行為，稱之自發性行為，現在這個標籤的涵意則是 提供 Activity 運作過程中可以對實體資源加以控制的方法，我們 稱之為強制性(Compulsory)的行為，Agent 命令 Resource manager 運作，此標籤的基本語法如 Table 3.14 所描述，有一名稱為 Type 的屬性以及三個子節點，分別為 Before, Around, After 其解釋如 下：
Table 3.14 ParticipantAction node’s basic structure
<ParticipantAction type="Script">
<before>
</before>
<around>
</around>
<after>
</after>
</ParticipantAction>
Type：可能填入的值為 IOC, Source, Script 三種，此三值的差 異在於決定測試平台在模擬實體資源時資源自己的預設行為實作
34
類型，依照填入的值不同，ParticipantAction 的內容填寫方式也 不同，其描寫方式與前述 Resource 節點下的 Spontaneous 節點撰 寫方式雷同，不同的地方在根據不同 Type 所填入的內容都必須是 Before, Around, After 此三節點的子節點，其表達方式如 Table 3.16 所示。
Table 3.15 ParticipantAction content syntax with type = script
<before>
<![CDATA[ FUNCTION ]]>
</before>
<around>
…
</around>
<after>
…
</after>
Before：此標籤表示在此頁面一開始執行時 Agent 必須喚醒 Resource manager 來運作。此標籤可有可無，若有撰寫代表 Agent 必須在此標籤所指定的執行時間呼叫 Resource manager 運作其內 指定的內容，執行方式則是利用 ParticipantAction 標籤的 type 屬性指定。
Around：此標籤表示在 Agent 傳送資料至 WfMS 前須先喚醒 Resource manager 來運作。此標籤可有可無，若有撰寫代表 Agent 必須在此標籤所指定的執行時間呼叫 Resource manager 運作其內 指定的內容，執行方式則是利用 ParticipantAction 標籤的 type 屬性指定。
After：此標籤代表 Agent 在傳送訊息給 WfMS 後必須喚醒 Resource manager 來運作。此標籤可有可無，若有撰寫代表 Agent 必須在此 標籤所指定的執行時間呼叫 Resource manager 運作其內指定的內 容，執行方式則是利用 ParticipantAction 標籤的 type 屬性指定。
Table 3.16 是一個 Flows 可能的撰寫方式範例：
35
Table 3.16 example of flow tag in TS-WfMS
<flows>
<flow name="flowNameA">
<Activity name="act1">
<Page seq="1">
<Presentation>
<rule type="regex" target="url">(rid=)\\d+</rule>
<rule type="regex"
target="from">example...</rule>
<rule type="regex"
target="textfield">example...</rule>
</Presentation>
<ParticipantInput>
<data variable="name">userName1</data>
<data variable="passwd">userPass1</data>
</ParticipantInput>
</Page>
</Activity>
<Activity name="act2">
…
</ Activity >
</flow>
</flows>
3.1.3 WorkflowConstraint
此標籤主要是讓系統發展者指定整個 WfMS 執行時所必須遵守的條件限制，這些 限制有很多種類，我們只是將其可能的語法標示出來當作範本，其語法結構如 Figure 3.9 所示，他有一個名為 Constraint 的子標籤，解釋如下：
36
WorkflowConstraint_definition Æ <WorkflowConstraint>Constraint</WorkflowConstraint>
Constraint Æ FlowInstanceNumber | InterFlowInstanceNumber | ResourceLimitation | ExecutionOrder | singleActivityExecutionCount | Loop | Exception | ActivityExecutionTimeDuration | ActivityExecutionDeadlineTime FlowInstanceNumber Æ <FlowInstanceNumber max=“INT">FlowName</FlowInstanceNumber> { FlowInstanceNumber } InterFlowInstanceNumber Æ <InterFlowInstanceNumber max="INT">FlowNames}</InterFlowInstanceNumber>
{ InterFlowInstanceNumber }
ResourceLimitation Æ <ResourceLimitation actionON=“ActivityExecutionTime" type=“ResourceType" name=“ResourceName"
lower=“INT" upper=“INT" activity="ActivityName“>FlowName</ResourceLimitation> { ResourceLimitation }
ExecutionOrder Æ <ExecutionOrder current=“ActivityName” next=“ActivityName” >FlowName</ExecutionOrder> { ExecutionOrder } singleActivityExecutionCount Æ <SingleActivityExecutionCount maximun=“INT” minimun=“INT”
activity=“ActivityName”>FlowName</SingleActivityExecutionCount> { singleActivityExecutionCount }
Loop Æ <Loop maximun=“INT” minimun=“INT” start=“ActivityName” end=“ActivityName”>FlowName</Loop> { Loop } ActivityExecutionTimeDuration Æ <ActivityExecutionTimeDuration activity=“ActivityName” duration=“INT”>FlowName</
ActivityExecutionTimeDuration>
ActivityExecutionDeadlineTime Æ <ActivityExecutionDeadlineTime activity=“ActivityName” deadlineTime=“INT”>FlowName</
ActivityExecutionDeadlineTime >
FlowNames Æ FlowName { , FlowNames) ActivityExecutionTime Æ startACT | endACT INT Æ [0-9]+
ResourceType Æ String FlowName Æ String ActivityName Æ String
Figure 3.9 WorkflowConstraint syntax
在 WorkflowConstraint 此節點下有眾多不同的條件限制，以下簡述他的功 用：
flowInstanceNumber：此標籤內容的限制是描述一個 Workflow 的最大實體 化數目，具體的例子可以由 Figure 3.2 來描述之，當一個處室的行政人員有限 下，系統開發者可能自行撰寫相對應的限制在他的系統中，此時透過此標籤的描 述，測試平台可以協助監控系統內真正運行所有由該 Workflow definition 所實 體化的 Workflow processes 數目，此標籤有一個 max 的屬性，內容只能填寫數 字，而此標籤的內容是填寫 Flow 的名稱，用來指定這個條件用在哪個 Flow 上，
Table 3.17 是一個撰寫的範例。
Table 3.17 Structure of constaint with type = flowInstanceNumber
<FlowInstanceNumber max="3">flowNameA</FlowInstanceNumber>
interflowInstanceNumber：此標籤內容的限制是描述多個不同的 Workflow definitions 的最大實體化數目，具體的例子可以由 Figure 3.2 以及 Figure 3.3 此兩流程來描述，如果此兩個流程使用相同的行政人員，此時系統開發者可能自 己 撰 寫 方 法 來 限 定 兩 個 流 程 同 時 實 體 化 的 最 大 數 目 ， 若 要 測 試 這 樣 的
37
Application，我們可以藉由定義此項標籤內容來協助監控真正系統上實體化的 數目。此標籤有一個 max 的屬性，內容只能填寫數字，而此標籤的內容是填寫 flow 的名稱，用來指定這個條件用在哪個 flow 上，Table 3.18 是一個撰寫的範例。
Table 3.18 Structure of constaint with type = interflowInstanceNumber
<FlowInstanceNumber max="3">flowNameA, flowNameB
</FlowInstanceNumber>
executionOrder：此標籤內含三個屬性，分別為 Before, After, Current，
表是三個不同的 Activity 間的順序，而此標籤的內容僅能填入描述限制的 flow 名稱。此標籤功用是限制 Workflow 內 Activities 間的執行順序，當開發者想測 試自己撰寫的流程有沒有問題時，他可以藉由詳細的撰寫這項標籤來測試自己寫 的流程定義是否有誤，我們使用 Figure 3.2 來描述此標籤作用，A1 這個 Activity 是負責登入的動作，所以無論如何他都必須要在 A2 前執行，假若開發者在寫他 的流程定義檔時將 A2 寫在 A1 前執行，如此一來我們可以利用此屬性的功能來設 定我們的 Constraint，架構如 Table 3.19 所述。以下簡介此標籤的屬性作用：
Table 3.19 Structure of constaint with type = executionOrder
<ExecutionOrder before="beforActivity" after="afterActivity"
current="currentActivity">flowName</ExecutionOrder>
Before：相對於 Current 之前一個 Activity，可填入名稱為 Activity 名稱。
Current：現在執行到的 Activity 名稱，可填入之值為 Activity 名。
After：相對於 Current 所描述的 Activity 之後的下一個 Activity，可 填入的值為 Activity 名稱。
singleActivityExecutionCount ： 此 標 籤 含 意 是 測 試 指 定 之 Workflow definition 內個別 Activities 的總共被執行個數，我們使用 Figure 3.2、Figure 3.3 來舉例，Figure 3.2 的流程裡 A4 這個 Activity 是負責撰寫電子公文，若此
38
系統有限定一天最多能送件的公文數目，則系統開發者可以藉由使用此標籤來撰 寫這樣的條件，如此測試平台即可協助監控，具體的範例如 Table 3.20 所示。
此標籤的值只能填入流程名稱，且他有三項屬性，分別在以下描述之：
maximun：最大的執行次數限制，只能填入數字。
minimun：最小的執行次數限制，只能填入數字。
activity：受限制的 Activity 名稱。
Table 3.20 Structure of constaint with type = singleActivityExecutionCount
<SingleActivityExecutionCount maximun="INT" minimun="INT"
activity="ActivityName">FlowName</SingleActivityExecutionCount>
Loop：此標籤含有四個屬性，分別為 Maximum, Minimum, Start, End，此 標籤內容是填寫受限制的 flow 名稱，他的屬性含意解釋如下：
Maximum：受限制之迴圈最大的次數，只可填入數字。
Minimum：受限制之迴圈最大的次數，只可填入數字。
Start：描述開始的 Activity 是哪一個，內容只能填入 Activity 名稱。
End：描述結束的 Activity 是哪一個，內容只能填入 Activity 名稱。
此標籤用來測試同一個 Workflow 裡面 Activity 間循環執行次數，使用 Figure 3.2 為範例，A1 的行為是登入，如果登入錯誤他會一直回到自己，此時 我們可以用此標籤描述限制登入次數最多幾次，然後與實際程式下去測試，除了 單一的 Activity 的循環外，也可以測試不同 Activity 間的循環，比如 A1 和 A2，
系統開發者可能會要限定同一個 Session 內最大只能註冊一個帳號，此時我們就 由此標籤可以讓測試系統來協助系統開發者做監控，其架構如 Table 3.21 所示。
Table 3.21 Structure of constraint with type = Loop
<Loop maximum="5" minimun="0" start="anotherActivity"
end="someActivity">flowName</Loop>
ResourceLimitation：此標籤用來描述 Activity 開始與結束時之資源限制，
標籤內容必須填入受限制之 Flow 名稱，其屬性簡介如下：
39
ActionOn：描述此資源限制的檢查時間，此屬性只能填入 EndACT, StartACT 兩種資訊。
Type：此屬性用來描述系統發展者所欲限定之資源類型，且此值必須和 Resource 節點內的 Type 屬性值一致，否則 Resource manager 會回報找 不到該項資源。
Name：此屬性用來描述系統發展者所欲限定之資源名稱，此值必須和 Resource 節點內的 Name 子節點的值一致，否則會找不到資源。
Lower：此屬性描述此項資源最少的數量，內容只能填入數值。
Upper：此屬性描述此項資源最大的數量，內容只能填入數值。
Activity：此屬性描述被限制的 Activity 名稱，內容必須填入 Activity 名稱。
此標籤旨在描述 Activity 啟動時，可能會有最少需求的實體資源需要 存在且可利用，藉由此屬性可以用來明確檢驗，具體的範例可使用 Figure 3.3 內的 A3 來解釋，A3 的啟動需要一個行政人員以及交通車的參與，系統開發 者可能自己有撰寫監控的相關程式，此時藉由測試平台所提供的此項標籤，
系統開發者將得以測試他所設定的條件限制是否執行正確。其架構如 Table 3.22 所示。
Table 3.22 Structure of constraint with type = resourceLimitation
<ResourceLimitation actionON="startACT" type="car" name="audi"
lower="0" upper="5"
activity="ActivityNameA">flowNameA</ResourceLimitation>
<ResourceLimitation actionON="endACT" type="car" name="B.M.W"
lower="2" upper="5"
activity="ActivityNameB">flowNameA</ResourceLimitation>
ActivityExecutionTimeDuration：此標籤用來描述一個 Activity 開始與結 束時之間的執行時限制，標籤內容必須填入受限制之 flow 名稱，其屬性簡介如 下：
Activity：描述受限之 Activity 名稱。
Duration：描述執行時間，只能填入數字。
40
此標籤使用的具體範例可由 Figure 3.3 內的 A4 來描述，A4 是 A3 執行完後 便會啟動的 Activity，他的終止條件是行政人員送件結束後必須回來登記，系統 開發者可能自行撰寫了這個 Activity 最大運行時間以便偵測此 Activity 的正確 性，此時他可以藉由撰寫此標籤的語法來利用測試平台測試他的條件限定的正確 性。撰寫範例如 Table 3.23 所示。
Table 3.23 Structure of constraint with type = ActivityExecutionTimeDuration
<ActivityExecutionTimeDuration activity="A4" duration="30">電子送件系
</ActivityExecutionTimeDuration>
ActivityExecutionDeadlineTime：此標籤用來描述一個 Activity 執行結束 時間的執行時限制，標籤內容必須填入受限制之 Flow 名稱，其屬性簡介如下：
Activity：描述受限之 activity 名稱。
deadlineTime：描述某一個執行日期。
我們使用 Figure 3.2 的 A4 以及 Figure 3.3 的 A3 作為範例，一個行政人員 可能都是在固定時間統整所有公文再寄出，此時系統開發者可能會在 Figure 3.2 的 A4 內撰寫最晚執行結束的時間點，比如是下午的兩點半前，超過該時間後所 撰寫的公文將會在隔天才被 Figure 3.3 的 A3 寄送，系統開發者可以藉由撰寫測 試平台所提供的語法來協助測試他的條件限制是否有誤\，撰寫範例如 Table 3.24 所示。
Table 3.24 Structure of constraint with type = ActivityExecutionDeadlineTime
<ActivityExecutionDeadlineTime activity="ActivityNameA"
duration="INT">FlowName</ActivityExecutionDeadlineTime>
簡介完所有條件限制語法後，我們使用實際範例更進一步的將整區段寫法表 達出來，以下是 WorkflowConstraint 可能的描述方式：
Table 3.25 example of WorkflowConstraint tag in TS-WfMS
41
<WorkflowConstraint>
<FlowInstanceNumber max="3">flowNameA</FlowInstanceNumber>
<ExecutionOrder before="beforActivity" after="afterActivity"
current="currentActivity">flowName</ExecutionOrder>
<Loop maximun="5" minimun="0" start="anotherActivity"
end="someActivity">flowName</Loop>
<ResourceLimitation actionON="startACT" type="car" name="audi"
lower="0" upper="5"
activity="ActivityNameA">flowNameA</ResourceLimitation>
<ResourceLimitation actionON="endACT" type="car" name="B.M.W"
lower="2" upper="5"
activity="ActivityNameB">flowNameA</ResourceLimitation>
< ActivityExecutionDeadlineTime activity="ActivityNameA"
duration="INT">FlowName</ ActivityExecutionDeadlineTime>
<ActivityExecutionTimeDuration activity="ActivityNameA"
duration="INT">FlowName</ActivityExecutionTimeDuration>
<SingleActivityExecutionCount maximun="INT" minimun="INT"
activity="ActivityName">FlowName</SingleActivityExecutionCount>
</WorkflowConstraint>
上面所描述的所有條件限制會在 Figure 1.8 所描述的三種不同測試策略中 進行，藉由在不同的執行環境下，我們的測試平台得以更精確的告知使用者錯誤 發生的地點。
3.2 Agent
Agent 是負責自動測試程式與 WfMS 溝通的橋梁，當 WfMS 開始測試後，他必 須根據目前運行的流程名稱，以及 Activity 名稱，動態的從 TS-WfMS 中讀取該 次輸入與輸出的相關資訊。Agent 除了擔負與 WfMS 溝通的責任外，同時還必須與 Resource Manager 的進行互動(Table 3.26 中的 ParticipantAction 標籤)，最 後將從 WfMS 收集到的輸出送回 Execution Collector 進行最後步驟的驗證。
42 WfMS
Agent 1 . Send data to User(Include waiting user response)
5 . Send response to WfMS
TS-WfMS
2 . According to TS-WfMS Content
Validation tool
Resource Manager
4 . Communication with Resource Manager
3 . Validation data
Figure 3.10 Agent process flow
Figure 3.10 清楚的描述 Agent 的運作流程，一開始，WfMS 系統進入傳送資 料給 WfMS 參與者的狀態，此時 WfMS 可能正在等待使用者的回應或是他只是單純 呈現資料給使用者，接下來 Agent 開始根據 Test Scirpt 描述此 flow 中的現正 執行之 Activity 的資訊，陸續執行驗證資料以及與 Resource Manager 溝通的動 作，最後若 WfMS 需要回傳資料，則 Agent 再將資料回傳給 WfMS。
引用上面的範例(Figure 3.2,Figure 3.3)，Table 3.26 的設定代表電子公 文系統中 Figure 3.2 的 A1, 也就是 Login activity。當 WfMS 系統運行到此 Activity 時，Agent 將會根據 Page 的順序來抓取相對應的 Page 內資料傳送給 WfMS，
以此為例，Agent 首先會收到從 WfMS 傳來的訊息，此時 Agent 將會利用操作者在
<Presentation> 標 籤 內 所 描 述 的 驗 證 規 則 將 WfMS 的 輸 出 送 到 Execution-Collector 加以驗證，驗證方式是採用正則表示式來驗證輸出訊息，
此 時 ， login 的 Activity 要 求 使 用 者 輸 入 登 入 的 相 關 資 訊 ， Agent 利 用
<ParticipantInput>內描述的 Name-Value Pair 來傳送相關訊息回覆給 WfMS，
在本例子中 Agent 負責將使用者帳號以及密碼傳回去 WfMS，接著 WfMS 會在往下
43
個 步 驟 前 進 ， 可 能 是 更 換 Activity ， 也 可 能 是 前 往 下 個 Page 。
<ParticipantAction>告知 Agent 該在 Activity 內的哪個 Page 執行與 Resource Manager 的互動，標籤內含三個子標籤，分別是 Before, Around, After，他們 分別代表該在 Page 的開始前、傳送資料中、傳送資料結束後，三個運作點下去 呼叫運作，運作方式則依照指定的方式來操作，本例中採用 Source 方式來對 Resource Manager 操作。
Table 3.26 example of activity’s configuration of TS-WfMS
<flow name="電子送件系統">
<Activity name="A1">
<Page seq="1">
<Presentation>
<rule type="regex" target="url">(rid=)\\d+</rule>
<rule type="regex" target="from">fromTageName</rule>
</Presentation>
<ParticipantInput>
<data variable="name">userName1</data>
<data variable="passwd">userPass1</data>
</ParticipantInput>
<ParticipantAction type="Source">
<Before>
<SourceCode path="D:\ActionCode"
package="tw.edu.ntnu.csie.iclab.ResourceManager.Test"
classpath="D:\workspace3.2\ReachabilityTesting\src;D:\workspace3.2\Re achabilityTesting\lib\spring\lib\jakarta-commons\commons-logging.jar"
bindir="D:\workspace3.2\ReachabilityTesting\bin">before.java
</SourceCode>
</Before>
<Around>
<SourceCode path="D:\ActionCode"
package="tw.edu.ntnu.csie.iclab.ResourceManager.Test"
classpath="D:\workspace3.2\ReachabilityTesting\src;D:\workspace3.2\Re achabilityTesting\lib\spring\lib\jakarta-commons\commons-logging.jar"
bindir="D:\workspace3.2\ReachabilityTesting\bin">before.java
</SourceCode>
</Around>
<After>
44
<SourceCode path="D:\ActionCode"
package="tw.edu.ntnu.csie.iclab.ResourceManager.Test"
classpath="D:\workspace3.2\ReachabilityTesting\src;D:\workspace3.2\Re achabilityTesting\lib\spring\lib\jakarta-commons\commons-logging.jar"
bindir="D:\workspace3.2\ReachabilityTesting\bin">before.java
</SourceCode>
</After>
</ParticipantAction>
</Page>
…
</Activity>
…
</flow>
Agent 的實作可以由內部支援測試，與外部支援測試，內部測試方法是透過 改寫 WfMS 的一些 I/O 原件，而外部測試方法則是讓 Agent 透過模擬真實的 WfMS 與外界溝通的方式來測試(如 SMTP, HTTP, SSH 等)。而控制他們何時與 WfMS 做 溝 通 的 方 法 則 是 經 由 我 們 定 義 的 通 用 機 制 來 達 成 ， 這 機 制 我 們 留 到 Execution-Collector 的子章節介紹。
完善的 WfMS 設計如 JOO-WfMS[4]，提供了一個完備的存取介面機制，有了這 樣的設計，Agent 的開發成本將會相對的簡潔與便利，透過複寫指定的介面，並 適當的對調整 WfMS 的控制細節，即可完成 Agent 的開發。
無論是內部還是外部測試，若沒搭配完善的軟體測試方式，則都只能測出 WfMS 內 Even-order non-relative 的錯誤原因，更複雜的軟體錯誤則無法得知其 原因為何。為了能針對 WfMS 內各種的軟體錯誤都能夠具體測試出錯誤原因，我 們必須搭配如 Reachability Testing[15] 這類的軟體測試方法，才能讓測試系 統更加完備。
3.3 Execution Collector
Execution collector 目的是收集 WfMS 系統內的 Runtime information，這 些資訊可能是 Reachability Testing[15]所需要的 Event access log，或是 TestScript 中 WorkflowConstraints 標籤內所要測試的資訊。但是 WfMS 本身可
45
能不提供存取這些資訊的方法，或是 WfMS 內部根本沒有這種資訊的需求。為了 要存取這些資源，可能需要透過 Code injection 來達成，但如此一來勢必將會 對所要測試的 WfMS 有大幅度的修改，增加了測試平台在不同的 WfMS 裡移植安裝 的困難度，幸好有 AOP(Aspect-Orient Programming)[17]這類的技術，使得收集 資訊的問題幾乎可以不修改 WfMS 本身的程式碼，只需藉由額外的 AOP 程式設定 來獲取這些資訊，藉以讓移植測試平台到不同的 WfMS 所要耗費的成本大為降低。
為此我們定義了一個架構於 AOP 上的通用機制(Figure 3.11)，不同的 WfMS 若要使用我們的系統，則他僅需重新定義我們指定的 Pointcut，接著再稍加修正 取得系統資訊之資料結構方式，就可以完整的將我們的測試架構移植到不同的 WfMS 上。
這 份 通 用 機 制 的 定 義 包 含 了 Agent 何 時 該 與 WfMS 溝 通 ， Execution-Collector 何時該接收資訊，Validation Tool 何時該驗證資訊的正 確與否，利用 AOP 這項技術，使得繁複的 code injection 變成單純的重新定義 介面以及資料結構存取的修改而已，大大增加了 testing framework 的可移植性，
這份通用機制可以適用於不同 WfMS 實作的主要原因是他們都有相同的軟體規格 [7]，因此不同的 WfMS 內必定有相似的介面，而測試平台剛好仰賴這些介面內的 Method 進行測試，舉體如 Flow start、Flow end、Activity start、Activity end、Activity wait user response、Activity GUI page creat，只需要有這 些基本介面，測試平台便足以建構起來進行系統測試。
46 Execution -Collector
Workflow management system
WfMS Pointcut Definition
Package tw.edu.ntnu.csie.iclab.Runtime;
importjava.util.Map;
importcomm.RequestId;
importwfms.core.Process;
public aspectWfMSPointcutDefinitionextends AbstractPointcutDefinition {
public pointcutmainPrograme():
execution( * webapp.StartJettyServer.main(String[]));
public pointcutactivityWaitUserResponce():
execution( Map<String, String>
comm.ui.component.Form.submit()) ||
execution( Map<String, String>
comm.ui.component.Page.submit());
public pointcutactivityExecutionCodeExecute(RequestId reqId, Map<String, String> param):
execution(publicvoid
wfms.core.ActivityExecutionCode+.call(RequestId, Map<String, String>)) &&
args(reqId, param);
publicpointcut flowInstanced():
execution( Process
wfms.core.ProcessDefinition.createProcess());
}
According
Figure 3.11 A general mechanism of weaving test framework to WfMS
Figure 3.10 裡紅色的小長方形是根據 WfMS Pointcut Definition 定義所產 生，而這些執行時間點要運作的內容可能是 Execution-Collector、Agent、
Resource Manager、Validation Tool 等，我們所提出的測試平台上所有原件都 是透過此份定義所描述的時間點來與系統合作。
3.4 Resource manager
回顧本章節的範例，一個協助學校行政系統公文數位化的工作流程管理系統 可能將其行政人員以及交通車的資訊放入資料庫中，但實體測試環境下，除非開 發員有針對資源的概況在相對應的 Activity 中做輸出的行為，我們才有機會藉 由驗證 Activity 輸出條件規則來判定執行的對錯，否則將沒有直接的方式來驗 證這類的原件。Resource Manager 的功用就是協助開發者免於憂心實體物件在 資料庫的值是否與開發者預想的邏輯運作方式相反，以及協助開發者模擬實際資 源使用狀況，進而達到協助預期 workflow 對於實體資源使用的最大負載。
47
Resource Pool
Resource Instance Resource Manager
Figure 3.12 Resource Manager
為了提供測試時更大彈性的功能，Resource Manager 是由以下元件組成 (Figure 3.12)：
1. Resource Manager：資源管理系統，本身需要控管所有由 TS-WfMS 中所 描述的實體資源，並且接收 Agent 傳來的要求，進而根據 TS-WfMS 上所 撰寫的 Rule 運行。
2. Resource Pool：對於 TS-WfMS 上所描述的各種不同實體資源，都要有他 們專屬的 Resource Pool，一個 pool 控制一種資源類別，如電子公文系 統內的交通車可能有很多種不同品牌的汽車，但是他們都是歸屬於同一 Resource Pool 所控管、模擬。
3. Resource Instance：每一個 Resource Pool 針對他們的所屬資源，全 部都必須產生一個專有的物件來模擬該實體資源真實的情況。
Resource Manager 的控制內容必須要夠彈性，以及要能兼具足夠多的功能，
才能簡易的讓開發者使用，因此 Resource manager 有三種可行的選擇可供使用 如下：
1. Script：這個實作方法是經由開發者在 TS-WfMS 中明確的表示 type =
“Script”，並寫入由我們所訂立的 Script Syntax，讓系統發展者藉
48
由撰寫簡易的 Script 來與測試系統溝通。
2. Source：除了 Script 外，也可以進一步的根據不同的程式語言，提供一 個共通介面讓他們實作，接著動態編譯程式碼，最後再呼叫使用，這個 做法可以讓開發者使用他們擅長的程式語言，撰寫相對應的模擬操作行 為，讓測試過程更加依照開發者的需求而改變。此類的方法需在 TS-WfMS 中相對應的地方使用 type = “Source”來指定。Table 3.27, Table 3.28 分別是 Spontaneous 和 Compulsory 的 Source 類型實作。
Table 3.27 SpontaneousAction Interface (implements in JAVA)
package tw.edu.ntnu.csie.iclab.ResourceManager;
import java.util.List;
import
tw.edu.ntnu.csie.iclab.ResourceManager.ResourcePool.ResourceIn stance;
public interface SpontaneousAction {
public Message action(String orig, String target, String workingAct, String workingFlow, List<ResourceInstance> resList);
}
Table 3.28 CompulsoryAction Interface (implements in JAVA)
package tw.edu.ntnu.csie.iclab.ResourceManager;
import java.util.List;
public interface CompulsoryAction {
public Message action(List<ResourcePoolInterface> poolList, String currentFlowName, String currentActName);
}
JAVA 因為有 JVM 中介動態的找尋 class 來執行，因此我們只需要保證先 動態編譯完後再使用此 class 即可，若是使用其他語言來實作則有些不 同點，如 C++可能需要透過將這個 class 編譯成 Dynamic Linking
49
Library 才能達到這樣的目的。
3. IOC：我們可以利用 IOC 的觀念將系統發展者的自定義行為藉由程式語言 的實作進一步的將其視為是一個 bean，而在執行期間動態將其呼叫使用。
此類的方法需在 TS-WfMS 中相對應的地方使用 type = “IOC”來指定。
IOC 的實作有部分需要使用 SOURCE 的方法，因為 IOC 本身不負責編譯 Source 檔案。
Agent
TS-WfMS
WfMS
1. WfMS send data to agent
3 .Agent invoke Resource Manager According to TS-WfMS
Compulsory Action 2 .Read data form TS-WfMS
Spontaneous Action
4. According to Resource tag
Figure 3.13 Resource Manager operation flow
簡介完 Resource Manager 的組成後，接下來簡介 Resource Manager 的運作 流程(Figure 3.13)，首先由 WfMS 系統發出資訊，Agent 接收到此資訊後由 TS-WfMS 內讀取現正執行的 Activity 的資訊，接下來依照系統發展者的描述對 Resource Manager 執行 Compulsory Action(強制性動作)，而在運作過程中 Resource Manager 會依照 TS-WfMS 裡的 Resource 標籤內敘述的 Spontaneous 行為運作，最 後即完成 Resource Manager 的運作流程。
我們用前述的範例，在 Figure 3.2 裡面的 A4 這個 Activity 的設定檔為例 如 Table 3.29 所示，<ParticipantAction>標籤下面有三個子標籤，他們分別也
50
有填入設定的資訊，而在這個 Activity 中，他的工作是對於顧客選定的汽車在 資料庫中的狀態做更改，因此我們可以在 before.java 寫下檢驗該車是否可以租 借 ， around.java 寫 下 改 變 該 台 車 在 Resource Manager 中 的 狀 態 登 記 ， After.java 中寫下驗證是否資料庫中的狀態真的已經改變，他們的程式碼大略如 下中的 Table 3.30, Table 3.31, Table 3.32 所示，藉由 Table 3.28 的介面，
開發者可以動態獲得 Resource Manager 中的所有資訊，並可在其內任意的執行 他所想要的運作，如等待資源改變狀態，或是一直存取資源，或是對於實體的資 料庫資源做確認等，開發者能夠完善的執行有關資源的所有測試或是模擬，不需 要更改 WfMS 中任何的程式碼，有效的偵測任何問題點的產生原因。
Table 3.29 Figure 3.2 中 A3 在 TS-WfMS 裡有關於 Resource manger 的範 例
<flow name="RentCar">
<Activity name="deal">
<Page seq="1">
<Presentation>
…
</Presentation>
<ParticipantInput>
…
</ParticipantInput>
<ParticipantAction type="Source">
<Before>
<SourceCode path="D:\ActionCode"
package="tw.edu.ntnu.csie.iclab.ResourceManager.Test"
classpath="D:\workspace3.2\ReachabilityTesting\src;D:\workspace3.
2\ReachabilityTesting\lib\spring\lib\jakarta-commons\commons-logg ing.jar"
bindir="D:\workspace3.2\ReachabilityTesting\bin">before.java
</SourceCode>
</Before>
<Around>
<SourceCode path="D:\ActionCode"
package="tw.edu.ntnu.csie.iclab.ResourceManager.Test"
classpath="D:\workspace3.2\ReachabilityTesting\src;D:\workspace3.
2\ReachabilityTesting\lib\spring\lib\jakarta-commons\commons-logg
ing.jar"
51
bindir="D:\workspace3.2\ReachabilityTesting\bin">around.java
</SourceCode>
</Around>
<After>
<SourceCode path="D:\ActionCode"
package="tw.edu.ntnu.csie.iclab.ResourceManager.Test"
classpath="D:\workspace3.2\ReachabilityTesting\src;D:\workspace3.
2\ReachabilityTesting\lib\spring\lib\jakarta-commons\commons-logg ing.jar"
bindir="D:\workspace3.2\ReachabilityTesting\bin">after.java
</SourceCode>
</After>
</ParticipantAction>
</Page>
…
</Activity>
…
</flow>
Table 3.30 Table 3.29 裡 before 標籤的內容實作範例
package tw.edu.ntnu.csie.iclab.ResourceManager.Test;
import java.util.List;
import tw.edu.ntnu.csie.iclab.ResourceManager.CompulsoryAction;
import tw.edu.ntnu.csie.iclab.ResourceManager.Message;
import tw.edu.ntnu.csie.iclab.ResourceManager.ResourcePoolInterface;
public class before implements CompulsoryAction{
public Message action(List<ResourcePoolInterface> poolList, String currentFlowName, String currentActName) {
// write code of connecting to database and check the car state in database // return message according to the state of this resource in database
return new Message(false, "RENT FALSE");
} }
Table 3.31 Table 3.29 裡 around 標籤的內容實作範例
52
package tw.edu.ntnu.csie.iclab.ResourceManager.Test;
import java.util.List;
import tw.edu.ntnu.csie.iclab.ResourceManager.CompulsoryAction;
import tw.edu.ntnu.csie.iclab.ResourceManager.Message;
import tw.edu.ntnu.csie.iclab.ResourceManager.ResourcePoolInterface;
public class around implements CompulsoryAction{
public Message action(List<ResourcePoolInterface> poolList, String currentFlowName, String currentActName) {
for( ResourcePoolInterface respi : poolList ){
if( respi.getResourceName().equalsIgnoreCase("B.M.W") ){
return respi.stateChange("IDLE", "BUSY", 2, currentActName, currentFlowName);
} }
return new Message(false, "RENT FALSE");
} }
Table 3.32 Table 3.29 裡 after 標籤的內容實作範例
