接口開發的發展促成了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的集成項目，希望能在實踐過程中找到這個問題的答案，也希望有機會與大家一起分享我的經驗。
延伸閱讀
文章來源于領測軟件測試網 http://www.k11sc111.com/
