2014-10-06 31 views
1

我目前開始,我們都希望能開發使用可重複使用的組件和服務的新系統,新的項目。測試可重用的組件/跨多個系統服務

我們目前有30多個系統都有共同的元素,但目前我們單獨開發每個系統,所以感覺我們經常複製代碼,當然我們有30多個單獨的代碼庫來維護和支持。

我們希望做的是建立使用共享組件,使新的集合,重用代碼和重複使用的自動化測試快速發展,降低了代碼庫,需要保持一個通用的平臺。

我們的想法至今都認爲我們會有例如用戶管理和安全系統訪問,這些模塊可以由自己的通用Web模塊,API和語境的特定模塊通用代碼庫。這將創建一個通用的代碼包。

然後,我們可以部署這些不同的組件/包來構建一個新的系統,以便一次又一次地保存相同模塊的編碼,因此如果新系統需要管理用戶,您可以獲得用戶管理包並將其激活做你需要的。但是,因爲我們有30多個系統,我們會爲每個集合多次部署組件。此外,我們也欣賞一些系統需要獨特的功能,因此可能會爲通用模塊添加擴展以滿足系統特定的需求,或者選擇不使用其中一個通用模塊並創建一個新模塊,但使用其餘的的通用組件。

例如,如果我們有4個通用的組件,使系統的A,B,C和D.這些可能被部署到創建下列系統設置窗口:

系統1 - A,B,C和d(快樂的所有通用組件)

系統2 - AA,B,C和d(擴展組分A爲包括特定的功能)

系統3 - A,E,C和F(不能重複使用組分B和d,以便產生特定的,但仍然重用組分A和C)

這是我扔了幾個問題,因爲我需要能夠測試這個平臺,各系統,以確保它的工作原理,這是我第一次遇到有來測試設置如下。

我已經做了周圍Mircroservices以及如何一些閱讀測試他們,但這些往往採用,我們正在尋找具有不同配置的多個系統微服務解決這個問題的只有1系統。

到目前爲止,我的想法讓我相信,對於不同集合將使用的通用組件,我可以在基本代碼級別創建自動化測試,然後這些測試將確認泛型功能,因此它不會對於每個組件重新測試這些功能都是必要的,除了部署之後可能還有人工檢測。然後在每個系統級別添加額外的自動化測試以檢查可能創建的特定功能。

理想情況下,我想要設置某種測試平臺,以便在對用戶管理等核心組件進行更改時,可以在覈心級別觸發所有自動測試然後對將共享該組件的所有系統進行所有特定的系統測試,以確保任何更改不會影響核心功能或對特定系統產生影響。然後需要快速手動檢查。每次共享組件發生更改時,我都希望嘗試刪除大量的手動測試開銷,以檢查30多個系統。

我們以敏捷的方式工作,對於我們當前的項目,我們建立了一個強大的持續集成過程,所以當開發人員檢查一些代碼時(Visual Studio),這會觸發CI構建(TeamCity/Octopus)所有的單元測試,只要所有這些測試都通過了,這就觸發了一個集成構建,它將運行我的QA自動化測試,這些測試是在API級別運行的測試以及使用SpecFlow和PhantomJS或Selenium Webdriver的Web測試的混合體。我們希望保持這種框架以保持快速反饋循環。

這一切在理論上聽起來不錯,但在那裏我掙扎試圖把東西付諸實踐,並營造良好的測試策略,以覆蓋這種系統的建立。

所以真的就是我希望的是,有一個人在那裏誰也遇到過類似的東西,有最好的辦法的想法來解決這個並已經證明,他們的工作。

我渴望得到更好的理解我怎麼能建立一個測試平臺/鑽機援助考慮到每個系統可能會有所不同的所有系統的不斷整合,但有共同的代碼。

,你認爲可能會幫助任何想法或鏈接到博客/白皮書等,將不勝感激!

回答

1

你的做法是相當不錯,因爲不久我將不得不面對像你一樣的問題 - 我可以給你我的想法而已。我敢肯定,到

創造一個良好的測試策略,以覆蓋這種系統的建立

不能在一個崗位受到擠壓項。因此,大圖像看起來像這樣(對我來說) - 你處於Enterprise application integration進程的中間,要測試的基本依據是Data migration。也許你需要使用共享組件

考慮Service-oriented architecture

通用平臺的概念,因爲它會幫助您提供應用的功能給其他應用程序服務。這裏間接的好處是SOA會涉及大大簡化的測試。服務是自治的,無狀態的,具有完全記錄的接口,並且與執行的交叉關注點分開。有很多這樣的資源E2E testingefficiently testing SOA

+0

謝謝,有些有用的鏈接給了我一些想法。我仍然不確定如何設置測試平臺來將它們連接在一起,但這無疑幫助我更進一步。 :) – Noodle 2014-10-09 07:56:15