SOA TESTING

在 Testing services and service-centric systems: challenges and opportunities[22]這篇

paper 當中，作者 Canfora, G. , Di Penta, M 提出，在做 SOA testing 之時會遭遇許 多困難，第一個問題就是，services 之間很多 interactions 而且這些 interaction 還是 dynamic 的情形，所以在測試之時相當的麻煩。所以她們提出的想法是使用 mutation strategy 來做 service functional testing，作法為先由 request 端送出 request 到 target service，等到 target service 將 response 送回來之時，再來分析 response 是否有 fault。接下來他們會做整合性的測試，作法是利用幾組不同的 input 將其 輸入之後，看看系統是否能正確的運行，他們也提到因為 service 之間的 interaction 可能會因為不同的 message 有不同的 condition，所以他們也提出軟體測試的觀點，

就是要做 regression testing，就是當 path 出現分歧的時候，必須要在那個分歧的 地方再加以測試，不過他們自己也說這可能不是太容易。不過，現在我們的系統 就是在朝這個方向來做努力，採用 monitor 跟 replay 的方式，配合上 reachability testing，就是在運用這種方式做 testing。在 Challenges in Evaluating SOA Test

30

Processes[23]這篇 paper 當中，作者 Ayaz Farooq, Konstantina Georgieva, Reiner R.

Dumke 提出使用 Evalution process 的方式來做 SOA 的 testing，一開始的時候他也 提到要做 SOA 的 testing 有相當程度的困難。因為以往的 testing 技巧，不能完全 work 在 SOA 的架構當中，因為他們的 interface 跟以往的架構不太相同，加上 service 的封裝，使得要做 testing 不是很容易。於是他們使用 evalution process 這 個 framework 來做 SOA 的 testing。這個 evalution process 有四個步驟，第一個步 驟是 establish evalution requirements，這個步驟主要是在做一些 initial 的動作，根 據 business 的需求，來定義一些 requirement，讓等下 evalution 時可以有一個方向 來針對這些 requirement 來做評估。第二個步驟是 specify evalution，這個會仔細 定義等下 evalution 一些 quality 的 attribute 以及 quality 的 matrix。第三個步驟是 Design evalution，這個步驟主要是考量到 resource 使用狀況的問題，可以定義 when, how, what 的一些狀況，讓整個 resource 的使用狀況也可以評估進去。最後一個步 驟就是 execute evalution，最後就是將所有上面定義的東西一起納入考量，去評估 受測程式的 quality，主要是使用 qualiity indexing scheme。當評估完成之後，會回 報一份 report，除了評估的結果之外，還會再給予一些改進的建議以及一些比較 危險的地方會標示出來。這個 work 也是有不少的挑戰，像是如何制定 SOA 的 test

process。以及如何設定 evalution 的目標，最後就是 qualiity indexing scheme 這個 方法要用的 SOA Test Matrices。這些都是這個方法會遭遇到的問題，雖然作者都 有些方法可以來幫忙解決，但是他們還是有很多限制在，而我們的系統可以有比

31

較 formal 的方式來解決各式各樣的 case。在 SOA: Testing and Self-Checking[24]

這篇 paper 當中，作者 Gerardo Canfora and Massimiliano Di Penta 提到，傳統的 testing 技術應用在 service-oriented architecture(SOA)的平台上，並不適用。因為 SOA 的架構當中每個 service 都可能與其他的 service 同一時間超過一個以上的 interaction，要怎麼可能做到 run-time 的 monitor，是一個相當大的挑戰。所以他 們提出的做法是採用 role testing and monitoring。role testing 是採用 XML 的資料 格式存放一些要輸入的 input 資料，製造 test case。而 role monitoring 他會 weaving 成一個 crosscutting concerns 在 system code (例如:BPEL 的 process 之中)上面，當 系統出現問題的時候會做一個 recovery 的動作。當兩個系統整合在一起的時候，

可以驗證 service QoS、service interoperability、service evolution。目前我覺得這個

framework 的想法還算不錯，不過因為有些地方都有相當難度的運作。所以很多 地方還要做一些限制。但是對於 SOA 這個新的架構方式，我覺得已經算是提供 了一個不錯的方式來做處理，比較大的缺點就是沒辦法確定在 concurrent application 執行的情況下，每一個 interleaf 都有執行到，不然的話我覺得考量算 是蠻完整的。