軟件開發專家知道測試是開發與部署之間過渡的關鍵，部署一直以來都是軟件項目的目標。要想測試面向服務架構(SOA)應用程序，就必須通過擴大單元測試、擴大負載測試的范圍，分別測試編制、集成和基于組件結構的信息流來使三級測試過程適應SOA原則。

應用程序測試通常是三階段流程。第一階段流程，應用程序組件通過開發人員根據所制定的規范來確保它們的功能從而實現“單元測試”。第二階段流程，這些組件被整合起來完成應用程序的開發，然后進行“系統測試”或“集成測試”以確保應用程序和功能關系間的工作流達到預期的要求。最后一階段流程，對應用程序進行“負載測試”或“試點測試”來模擬實際的部署環境。SOA應用程序可以遵循相同的模式，但每個階段都會有特殊規定，以適應特殊性質的基于組件的松耦合程序。

SOA要求程序組件具有“即服務”組件的功能來展示應用程序完整的運行過程。將SOA組件視為服務于單元測試的應用程序是十分重要的，這就意味著結合以上三階段測試，并在每個SOA服務/組件運行這三個階段。

服務接口是SOA組件測試的關鍵。通過描述生產服務的SOAP/WSDL確保單元測試以真正的服務形式對組件進行測試。用戶報告稱，基礎軟件測試經常會忽視服務接口，將其延遲到后期的集成測試，在安裝前這種項目允許的延遲會積淀許多服務規范問題。適當的服務接口測試通常需要通過SOA/SOAP接口使測試生成器運作，從而確保在所有可能的條件中都可以進行測試。

考慮到這一點，我們在驗證過程中添加了基礎負載測試，以確保組件的性能可以滿足總體目標。對一系列SOA組件進行性能測試會更加復雜，這是因為所有可能的路徑都是難以核實的。如果每個組件分別進行負載測試，那么可以在不同情況下，通過為每個路徑繪制工作流和總結延遲來預測應用程序的性能。這便可作為一個指標來比較實際的負載測試結果。

在SOA中，集成測試的目標是三個，而不是一個。SOA應用程序不同于普通的應用程序，因為它們通常在編制軟件時引入一個新的組件，即應用于連接SOA組件的消息/服務總線技術。在許多SOA應用程序中，組件間的信息管理是由一個業務流程執行語言(BPEL)模板所控制，這同樣是一個測試的新元素。只有當這兩個“新”的元素經過測試后，才可以測試普通組件間的集成。事實上，“集成”測試并非組件測試而是優先于單元測試的測試系統，這說明了本文前面概論所說的提升組件驗證標準的重要性。

至少應用程序架構師早期所開發的應用程序原型中，大多數SOA應用程序都有自己的BPEL。如果BPEL基礎主路徑和相關的數據都可以從該流程和單元測試中獲取，那么他們就可以用來驗證信息/服務總線編制軟件的功能。確保BPEL能正確地驅動組件序列，及信息/服務總線軟件與組件之間的接口是正確的，這非常重要的。這樣組件就可以進行正確的訪問，SOAP信息格式也可以重新測試;它們在基礎水平的單元測試過程中也已經被驗證過。當主測試完成時，二級邏輯路徑可以通過相同的BPEL組件序列測試系統進行測試。

SOA應用程序中的負載測試也是通過信息/服務總線和BPEL介入而完成的，這是因為這些元素的性能將影響應用程序的質量體驗(QoE)。為了確保負載下的性能而對SOA應用程序進行測試，則更有可能因為組件與員工支持點的相對性位置，而變得復雜。除非所有的SOA組件都是托管在一個帶有短網絡連接路徑的通用數據中心中，QoE才有可能因為員工的位置而有所變化。

多地點的數據注入是網絡連接程序唯一可靠的測試方式，它對SOA應用程序尤其重要。這種測試模式所面臨的挑戰是要找出相關問題的原因，這是因為網路中多地點所發生事件的具體時機，對于問題的解決是難以重復的。對事件時間準確標記的測試流監控是必不可少的。用戶報告稱，依靠數據記錄器可能會出現問題，因為記錄器會影響應用程序的性能，同時也影響事件處理的時機。

用戶致力于敏捷開發實踐，旨在調試新代碼，對漏洞或者尋找SOA有用性和挑戰性方面的更改做出更快速的反應。由于SOA中的組件都是比較孤立的，所以它能夠迅速地編寫新版本組件，并且在不重復主要部分和負載測試的前提下進行部署。然而，SOA組件間的交互性自然比較高，所以為了部署而對SOA水平集成進行測試可能會耗時。

重新部署SOA測試的最佳策略是，為非常結構化的組件接口和信息流進行設計，避免其出現自由格式的參數和松散的變量。讓組件徹底地驗證其參數，或采用WSDL模式明確表示參數的范圍。如果組件可以“自我集成”，那么重新部署的更廣泛的測試需求降低了，而調試變化和漏洞修復的速度卻提升了。

SOA測試是集成應用測試的一種特殊情況，因為SOA通常部署較多的組件，并且工作流的交換過于結構化。通過利用結構化，可以降低大量組件化產生的風險，對沒有通過測試的組件進行測試。