但是你如何測試這些Web服務，知道它們就是在做你想要它們做的事情呢?要知道原來的應用可能根本沒有預想到自己會被做成一些構件的。程序代碼可能是意大利面式的。想象一下某個相當簡單的東西，比如管理用戶數據庫。假設，我們的Order Processing應用就這么干，因此我們需要把用戶更新功能(即添加、修改和刪除用戶)作為web服務暴露出來。我們了解此應用，因此我們知道其程序邏輯做了我們想要它做的事情。但它還做了別的什么事情嗎?這就是潛在的問題。
Web服務的單元測試
我們要如何做呢?我們可以讀源代碼。這是個好主意，去查看時候在我們添加、修改或刪除用戶時調用了我們不想調用的邏輯。但我們需要做的比這更多。我們除了把新的web服務與Order Processing應用一起測試之外沒有別的辦法。我們可以在測試所有可能的新的Customer Update web服務接受和發出的SOAP消息組合時，對Order Processing應用使用現有的回歸測試。當我們完成這項測試后，所有我們所做的事就是web服務的單元測試。因此，當我們暴露任何要用的web服務時，我們都需要做這樣的測試。實際上，這樣的測試手段應該成為IT管理的一部分。
假設現在的情況是我們用一些web服務和一些新的邏輯構建起組合的應用。我們希望每個web服務都已經被單元測試過了。于是測試過程應該按如下循環進行:創建測試計劃，創建測試床以及進行測試(測試設計，編寫特定測試用例，編寫特定腳本，執行測試，測試報告)。我們使用的已經被單元測試過的web服務不應該讓我們過于自信。就算在單獨測試時它們沒有出錯，也很有可能在一起工作時出錯。我們的測試方法應用能讓我們打散端到端的交易，探測失敗出現的地點。這意味著要能夠捕捉并分析從一個構件傳到另一個構件的所有SOAP消息。
集成測試
集成測試和傳統的系統測試非常不同。首先，我們做單元測試，然后做集成測試。額外的事情是當我們做集成測試時，我們必須對用到web服務的應用做回歸測試。
另兩種測試(壓力/性能測試和交付測試)也需要這個額外過程。我們需要測試相互關聯的東西，這樣它才能在真實的環境中運行起來。
可能我們已經提出了問題。但事情可能變的很復雜。對于可行但低效的垂直應用，測試還相對簡單。你只需對應用構件做單元測試。然后對整體做集成測試。然后，如果你對性能有什么要求，你可以再做壓力測試。最后，你再做交付測試。創建測試床不是什么問題，你只需建立運行時環境并構建一套測試數據，或者從真實系統中提取一些數據。
SOA的問題在于它是端到端的。垂直應用和簡單建立測試床將不復存在。隨著SOA項目的深入，你將需要有更多的各種各樣的測試床。事實上，你很可能需要能創建和拆除測試環境并從真實系統中提取數據的工具。沒有它們，創建足夠的測試床將非常困難。
壓力測試/性能測試也會成為測試床的一個挑戰。新的組合應用的運行決定了你會需要對很可能跨越很多不同服務器的整套端到端軟件進行壓力測試。
當前可以被管理的SOA測試情況非常少，如果有的話，組織就可以馬上構建復雜的端到端組合應用。他們的項目會涉及到集成相鄰的垂直應用或為核心系統增加瀏覽器接口，或者增加一些BPM。而當業務更復雜一些，他們就會發先SOA測試有多么復雜了。
文章來源于領測軟件測試網 http://www.k11sc111.com/