將業務需求轉換到軟件中這一過程能夠通過ALM工具自動完成。包括跟蹤編程過程、儲存源代碼、執行測試案例(目的是確保功能)，并記錄產品的缺陷和改進。自動化測試歷來只是被插入到ALM的“測試執行”階段。這可以提供有關代碼覆蓋或替換成功或失敗編譯的統計數據。但是，功能更加強大的測試可以使ALM工具管理的生命周期的每一階段增值。
例如，開發人員可以根據ALM庫中存儲的源代碼檢查測試，因為簡單化的“基本路徑”測試能夠展示已經交付組建的既定功能。接著，質量保證團隊會知曉有這些新資產，并運行和重復這些試驗證明一個更大的可能進行的活動集。但是另外一個團隊在集成和部署的過程中，可以使用開發和質量保證的所有的測試，將多個測試捆綁在一起，以確保用最小的成本得到整體回歸和功能覆蓋。最后，隨著業務團隊和支持團隊的介入，他們可以運行、修改和檢查對于平臺的測試，以發現問題或確定ALM生命周期的下一階段。按照這種方式實現共享，測試就變成了SOA協作資產，并增加了每個迭代周期的靈活性和速度，同時更好地確保了端到端業務流程的成功。
這種做法可以被任何測試工具所采用，無論你使用的是JUnit還是自動化程度更高的、無編碼的測試工具。使用無編碼測試環境的優勢在于能夠自動化執行測試，無需編碼技能，它能夠讓非開發人員參與到上述周期中來。
在上面這個例子中，每次組件級的迭代被引入時，每個人都應該參與測試的制定和執行，這些測試被集成到一個更廣泛的工作流程和業務流程中。一個敏捷機構允許多個團隊的開發人員和非開發人員在開發結束前的很長時間就相互協作，共同致力于測試應用組件。這可以確保在每個迭代周期進行連續測試，以及更加可靠的方案修正和發布過程。
例如，一家保險公司可能會有將郵政編碼與某種類型的汽車保險匹配的需求。開發人員創建一個組件，并利用一個能夠顯示一些郵編和保險類型匹配的簡單的測試案例對它進行檢查。質量保證團隊可以利用一個包含完整的郵編/保險類型匹配的數據集重復這一測試，并且隨后進行的系統開發都要進行這種測試。如果開發人員稍后更新了組件而所需的測試沒有通過，那么這一情況就會報告給ALM系統，同時還配有問題根源分析。最后根據ALM系統的問題解決規則，有關團隊互相溝通之后進行問題矯正。
四、IT運營和監測
本節是如何構建敏捷性SOA的第四部分，在這一節里，我們將主要研究一下IT運營、監測和性能。
一旦企業應用被部署完畢并投入使用，確保它的持續可用性、性能和準確性對于企業來說是至關重要的。在許多企業中，IT運營團隊可能是整個測試和開發團隊的一部分，或者被單獨“抽取出來”作為一個獨立的團隊，職責就是提供一定程度的公正性，確保應用環境所需的服務水平得到滿足。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
