SOA，測試人員的噩夢？

  對于IT人員來說，SOA已經不僅僅是一種技術，它代表了一種新的，更加宏觀的設計和實施IT系統的方法論。那麼對于整個IT系統的實施過程來說，每一個步驟都按照SOA的角度來考慮，來實施就成為了SOA項目實施過程中的重點和難點。   接口開發的發展促成了SOA的發展，SOA的諸多優勢之中接口規範的标準化是比較突出的一個。從EAI發展到SOA 的ESB，從各種不同的接口标準一統的Web Service，我們看到接口開發的演進過程，标準化、規範化的過程。 在SOA這種新的架構和設計思想下，接口合約（Interface contract）成為限制服務提供方和服務消費方的手段。對于開發人員來講合約會轉換為WSDL或者IDL這樣的定義檔案。有了這樣的定義檔案，提供方和消費方的開發人員就可以并行的開發。在這種新的開發方式，大量的服務可以有效的複用，開發的效率和開發的服務都可以有效的擴充；在這種方式下，可以把某些任務配置設定另外的公司和合作夥伴。從這種方式來講，SOA也友善了軟體的外包和離岸開發。 然而，中國有句老話叫“興一利必生一弊”，這種開發模式下對于測試人員來講會有新的挑戰。   首先，通過接口合約配置設定給不同開發商的服務，這些開發商内部如何有有效的機制來保證開發接口的品質和對于服務規範（SLA）的滿足程度。 第二，在服務組裝階段（一個典型的例子就是BPM的流程的開發就會有這樣的階段），如何有效的保證測試的順利進行。   第一個階段，服務開發階段的功能測試（接口測試）。 有EAI系統或者接口系統開發經驗的人都有知道接口的測試是一個比較繁瑣和效率低下的過程。SOA規範了接口算是改進了一大步，但是它也沒有解決接口測試的根本問題。對于開發和管理者來說，在內建測試之前，保證每個服務的功能測試都是很痛苦的，需要大量的工作。但是對于基于SOA的設計和實作來說，這麼做會屏蔽組裝（Assembly）階段更大的，更具破壞性的風險。 我們知道接口合約在現實項目中往往是word文檔或者excel格式的文檔。對于很多技術實作的細節并沒有描述，比較理想的情況下是有比較準确和細化的接口定義檔案WSDL。在有了WSDL檔案的基礎上，我們可以制作一些服務的simulator或者用戶端的simulator來模拟服務的調用和執行，但是如何有效的覆寫到所有的業務邏輯，就需要測試人員和業務需求人員科學嚴謹的工作了。 接口開發有個金科玉律，不要把問題留內建測試。問題越早發現越好。 第二個階段，服務的內建測試階段（System Integration Test或Assembling Test） 在 IBM對于SOA的實施過程的方法論描述中，有一個叫做Assemble的階段。這個階段就對于Service Testing有着詳細的描述。但是在我看來，這些描述反應的問題就是對于真實的商業環境來講對于SLA的了解是這個階段測試的重點。 這個階段還會涉及到各個廠商的協同測試，因為對于跨多個公司開發服務的內建測試來講，如何協調這些不同的組織，或者說利用什麼樣的工具和手段提供內建測試的效率，也是現階段各個廠商和大的內建公司在相關的SOA文檔和規範中沒有涉及的。是以對于測試人員來說，細節的工作不好做，也缺乏整體的方法論指導的情況下，如何不能說測試人員會進入一個SOA測試的黑洞呢？

 我正在參與一個基于SOA的內建項目，希望能在實踐過程中找到這個問題的答案，也希望有機會與大家一起分享我的經驗。