「集成測試」，「持續集成服務器」和「每晚構建」之間有什麼關係？

Question

我已經失學幾年了，最近纔開始回去重讀一些我的課本（我想保持新鮮）。我實際上發現我的軟件工程教科書迷人並計劃閱讀整個事情 - 如果有趣的話，因爲當我在學校時，我發現它非常無聊。

因此，有半章致力於集成測試。而且，就像學術界的大多數事情一樣，這些理論在閱讀的任何地方都具有很小的實用性。但是，它讓我思考。

我們使用CruiseControl進行持續集成測試，但看到我們是一個大型開發團隊，而且我沒有處理部署/構建/發佈，所以我從來沒有親自動手過。當我打破每晚的構建時，我會不時收到一封電子郵件。還有兩個科技導向向我解釋。

解決我的問題：我的舊教科書將集成測試稱爲相互配對和測試組件，而不是針對一個特定類的單元測試。這可以通過「自上而下」或「自下而上」的方式完成，其中自上而下意味着將整個事物作爲系統進行測試，然後遞歸地將系統分解爲更小的子系統並對其進行測試;自下而上意味着相反（從小開始，變大）。

我的問題：

如何以下threee概念之間的相互關係：

• 集成測試的這一理論解釋;和
• 所謂的「持續集成服務器」，如Hudson，Jenkins或CruiseControl;和
• 有一個「每晚構建」，其中的代碼已簽出一個單片機和自動編譯

難道只是巧合的是，前兩個在他們的詞「整合」的概念？是否像運行持續集成服務器（在晚上）一樣執行「夜間構建」，還是他們是兩個單獨的概念？

如果持續集成測試&夜間建築絕對沒有做學術的集成測試，那麼如何集成測試實際上體現在現實世界？他們的框架是否像JUnit一樣，但只專注於集成測試？

我知道這些是很多問題，但他們真的只是簡單地理解這些是什麼以及它們是如何使用的。在線搜索每個這些都會拉回相當模糊，抽象的答案。

Answer 1

太龐大，只能在幾行中解釋。

持續集成基本上是自動檢出，構建，測試，編碼質量檢查，部署等的循環。 它的測試部分將包括單元測試（單元代碼），集成測試（對數據庫或外部資源的依賴），以及工具和框架如junit，rspec。

這些可以安排在夜間生成並定期建立。

像cruisecontrol，哈德森這樣的連續集成工具可以幫助您配置此過程。 它更像是一個執行不同任務的schedular，通過除通知和工件管理等來定義依賴關係。

所有這些都非常相互依賴。

更多信息@http://martinfowler.com/articles/continuousIntegration.html

Answer 2

「集成測試」 以多種方式被使用;在「集成測試」和「持續集成」中使用「集成」一詞是由於過去更常見的「集成測試」的含義。

• 「集成測試」通常是指一次測試所有人的代碼或一次測試至少幾個代碼的測試。它是「單元測試」的補充，它一次測試一個代碼的單個模塊。在大多數項目中，單元和集成測試運行在同一個測試套件中。在大型項目中，特別是在過去軟件行業不擅長自動化測試的情況下，集成測試可能會在不同團隊的工作中組裝的系統上單獨完成。 「持續整合」中的「整合」來自後一種用法。

• 「持續集成」是每次運行項目的構建的源代碼更改的做法。 「構建」包括編譯（如果您的語言需要編譯），生成部署的工件以及運行自動化測試（包括單元和集成測試）。持續集成服務器通過觀察源代碼，開始構建和報告結果來支持這一過程。

• 「夜間構建」是一夜之間運行項目構建的實踐。它在大多數情況下通過持續集成被替換，因爲最好知道你的構建儘快被破壞。