建立SOA測試團隊需考慮的幾大問題

我們就SOA測試問題從三個不同的角度分別請教了三個人：培訓師、廠商、從業者。Randy Rice是一位軟件測試和軟件質量領域的主要作家、發言人兼顧問。Randy的公司為SOA測試提供培訓服務。Frank Cohen 是一位作家也是一家開源軟件測試公司Push2Test的創始人。Jim Giddings是一個SOA測試從業者，前任SOA路線捍衛者。過去幾年中，他曾經從事許多SOA行動。

　　SOA為測試帶來的最大改變是什么？

　　Randy 說“無障礙服務”或“服務的無頭特性”為測試員制造了新的挑戰。測試人員將必須在沒有用戶界面幫助的情況下測試許多服務，還須要進行嚴格的測試來驗證這些服務。Randy說測試服務讓他想起了需要軟件測試工具和測試框架的測試驅動器面臨的挑戰。

　　Frank談到了服務是如何的“隨時可獲取”，這與“你受控其中”的多層架構是不同的。有了SOA，你就能在Mashups的世界中用服務召集其它的服務，測試人員在實行部署之前了解這些服務將如何使用。Frank列出的挑戰中還包括了測量和性能。

　　Jim說你應該事先預料到頻繁的測試周期就像敏捷項目一樣，我們應該采取測試驅動開發的方法。Jim表示測試治理對于SOA來說已經是至關重要了。就像他的同行一樣，Jim也討論了服務的無頭特性和性能測試的挑戰。

　　你看到對于測試人員理解SOA所需的技術技巧提出的挑戰了嗎？

　　Randy 強調了強大的技術知識的重要性。他說測試人員來自企業不同部分（業務、開發等等），他們并不一定具有SOA所需的合適的技能。他也強調更大程度的面向業務需求的重要性，并將之稱為“測試遺忘的區域”。只專注于技術的測試員會忽略業務流程方面的因素。非業務頭腦測試員往往沒有適當水平的與業務人員聯系。

　　Frank 指出測試員已經開始進行編碼，而編碼人員也開始從事測試工作了。測試驅動開發引起了這樣的角色和責任的轉變。如果你的測試員不能夠編碼，那么這將成為一種挑戰。Frank 提出的另外一點就是對于非SOA的通用記錄和回錄方法以及框架的需求。測試員必需要學習如何用框架工作，這或許就需要腳本和編碼。測試人員還必須要理解支持狀態（statefullness）的概念。

　　Jim 提到許多測試員認為SOA等同于Web服務，而且對于架構范疇的理解也并不完整。并非所有的測試員都具備足夠的技術水平來“深入到架構中去”。SOA需要的不僅僅是黑匣子測試。Jim說SOA需要黑、白、灰匣子相結合的測試，因為在架構的每一層有太多的內容。

　　測試SOA的關鍵工具是甚么（如果有的話）？

　　Randy 談到允許測試配置的工具，還提到了SoapUI和ITKO的Lisa 產品，這兩個測試工具的設計目的是為給予測試員服務結構獲得途徑。他說現有的工具是能夠擴展的，但卻達不到有效測試SOA的水平。

　　Frank 表示SOA測試工具應該讓你重新目的化。例如：工具應該允許測試人員使用開發人員的測試配置并通過功能測試將之擴展。Frank的公司建立了 Testmaker Pro,一個開源工具為測試人員在無需學習像Groovy或Jython一樣的新語言情況下提供重新目的化的框架。

　　Jim 強調性能測試工具的重要性，還推薦一個像ITKO的Lisa一樣的工具來跟蹤代理服務和動態探測呼叫服務的路徑。在一些SOA實施當中，架構師傾向于在自己的服務前利用許多代理服務。

原文轉自：http://www.kjueaiud.com