對於it人員來說，soa已經不僅僅是一種技術，它代表了一種新的，更加巨集觀的設計和實施it系統的方**。那麼對於整個it系統的實施過程來說，每乙個步驟都按照soa的角度來考慮，來實施就成為了soa專案實施過程中的重點和難點。
介面開發的發展促成了soa的發展，soa的諸多優勢之中介面規範的標準化是比較突出的乙個。從eai發展到soa 的esb，從各種不同的介面標準一統的web service，我們看到介面開發的演進過程，標準化、規範化的過程。
在soa這種新的架構和設計思想下，介面合約（inte***ce 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的整合專案，希望能在實踐過程中找到這個問題的答案，也希望有機會與大家一起分享我的經驗。
敏捷 系統測試的噩夢？ zz
很早就聽說過敏捷軟體開發的概念，覺得是個新生事物，挺好玩，現在it的炒作已經太多了，後來發現敏捷的思想越來越深入人心，大大小小的公司開始使用敏捷的模式進行軟體開發。終於，敏捷來到了我的身邊。在傳統的軟體開發模式中，系統測試屬於軟體開發過程的較後階段，基本是在所有開發 全部完成，開發人員拿出所有精力修...
開發人員的噩夢 刪除重覆記錄
想必每一位開發人員都有過類似的經歷，在對資料庫進行查詢或統計的時候不時地會碰到由於表中存在重複的記錄而導致查詢和統計結果不準確。解決該問題的辦法就是將這些重複的記錄刪除，只保留其中的一條。在sql server中除了對擁有十幾條記錄的表進行人工刪除外，實現刪除重覆記錄一般都是寫一段 用光標的方法一行...
噩夢的解析
昨晚，應該說是今天凌晨，作了乙個自己得重病，將不久於人世的夢，夢中情節在驚醒後仍歷歷在目，查了一下解夢，感覺說得很符合 從周公解夢來看，夢病在身，主人發財。基本上從周公解夢來看是意味著身體健康.但是從心理來分析,你目前面臨一些選擇或者壓力,你潛意識很想得到乙個解脫,並且也反映了對目前的社會感到了無助...