測試實施實踐
持續集成
什麼是持續集成
持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通過每個成員每天至少集成一次，也就意味着每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發佈，自動化測試）來驗證，從而儘早地發現集成錯誤。
爲什麼要持續集成
因爲對於多人合作的大型軟件來說，越早發現問題，解決問題的成本越低。隨着軟件項目複雜度的增加（即使增加一個人），就會對集成和確保軟件組件能夠在一起工作提出了更多的要求-要早集成，常集成。早集成，頻繁的集成幫助項目在早期發現項目風險和質量問題。
持續集成的優勢
減少風險
一天中進行多次的集成，並做了相應的測試，這樣有利於檢查缺陷，瞭解軟件的健康狀況，減少假定。
減少重複過程
減少重複的過程可以節省時間、費用和工作量。說起來簡單，做起來難。這些浪費時間的重複勞動可能在我們的項目活動的任何一個環節發生，包括代碼編譯、數據庫集成、測試、審查、部署及反饋。通過自動化的持續集成可以將這些重複的動作都變成自動化的，無需太多人工干預，讓人們的時間更多的投入到動腦筋的、更高價值的事情上。
任何時間、任何地點生成可部署的軟件
持續集成可以讓您在任何時間發佈可以部署的軟件。從外界來看，這是持續集成最明顯的好處，我們可以對改進軟件品質和減少風險說起來滔滔不絕，但對於客戶來說，可以部署的軟件產品是最實際的資產。利用持續集成，您可以經常對源代碼進行一些小改動，並將這些改動和其他的代碼進行集成。如果出現問題，項目成員馬上就會被通知到，問題會第一時間被修復。不採用持續集成的情況下，這些問題有可能到交付前的集成測試的時候才發現，有可能會導致延遲發佈產品，而在急於修復這些缺陷的時候又有可能引入新的缺陷，最終可能導致項目失敗。
增強項目的可見性
持續集成讓我們能夠注意到趨勢並進行有效的決策。如果沒有真實或最新的數據提供支持，項目就會遇到麻煩，每個人都會提出他最好的猜測。通常，項目成員通過手工收集這些信息，增加了負擔，也很耗時。持續集成可以帶來兩點積極效果：
(1)有效決策：持續集成系統爲項目構建狀態和品質指標提供了及時的信息，有些持續集成系統可以報告功能完成度和缺陷率。
(2)注意到趨勢：由於經常集成，我們可以看到一些趨勢，如構建成功或失敗、總體品質以及其它的項目信息。
建立團隊對開發產品的信心
持續集成可以建立開發團隊對開發產品的信心，因爲他們清楚的知道每一次構建的結果，他們知道他們對軟件的改動造成了哪些影響，結果怎麼樣。
原則
- 所有的開發人員需要在本地機器上做本地構建，然後再提交的版本控制庫中，從而確保他們的變更不會導致持續集成失敗。
- 開發人員每天至少向版本控制庫中提交一次代碼。
- 開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器。
- 需要有專門的集成服務器來執行集成構建,每天要執行多次構建。
- 每次構建都要100%通過。
- 每次構建都可以生成可發佈的產品。
- 修復失敗的構建是優先級最高的事情。
TDD
TDD （測試驅動開發(Test-Driven Development)）TDD是測試驅動開發（Test-Driven Development）的英文簡稱，是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什麼產品代碼。TDD雖是敏捷方法的核心實踐，但不只適用於XP（Extreme Programming），同樣可以適用於其他開發方法和過程。
ATDD
驗收測試驅動開發（Acceptance Test Driven Development）
BDD
BDD：行爲驅動開發（Behavior Driven Development）
行爲驅動開發是一種敏捷軟件開發的技術，它鼓勵軟件項目中的開發者、QA和非技術人員或商業參與者之間的協作。主要是從用戶的需求出發，強調系統行爲。BDD最初是由Dan North在2003年命名，它包括驗收測試和客戶測試驅動等的極限編程的實踐，作爲對測試驅動開發的迴應。
使用BDD和ATDD可以解決需求和開發脫節的問題，首先他們都是從用戶的需求出發，保證程序實現效果與用戶需求一致。
這個過程可以使用基於BDD的自動化測試工具Cucumber。
結對編程
其實結對編程做起來很簡單也很有趣，找個水平差的不太遠的程序員和自己配成一對。只用一臺計算機，大家選一個人坐在鍵盤前面負責輸入，另一個人坐在後面口述。兩個人要不斷的交流，頻率不應低於一分鐘一次。整個的設計思想由後面只動口不動手的人主導，而由操鍵盤的人做實現。由於人的思維速度是快於輸入代碼的速度的。那麼觀看的人可以有空閒的時間做額外的思考，觀察代碼寫的有沒有問題，結構有沒有問題。
如果程序員的經驗積累足夠，是很容易看出存在潛在問題的代碼的，即表面上實現了功能，但實際上是一種糟糕的做法。這在XP(eXtreme Programming 極限編程)中被稱爲代碼壞味道，在 Martin Fowler的《重構》一書中有詳細的介紹。兩個有經驗的程序員同時在一起工作，看起來好像浪費了一個人的時間：但實際上的效果確實完成了更高質量的代碼。程序編的不那麼容易出BUG，而且代碼也寫得更爲優雅和緊湊.
DevOps
DevOps（英文Development和Operations的組合）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它的出現是由於軟件行業日益清晰地認識到：爲了按時交付軟件產品和服務，開發和運營工作必須緊密合作。
傳統的軟件組織將開發、IT運營和質量保障設爲各自分離的部門。在這種環境下如何採用新的開發方法（例如敏捷軟件開發），這是一個重要的課題：按照從前的工作方式，開發和部署不需要IT支持或者QA深入的、跨部門的支持，而卻需要極其緊密的多部門協作。然而DevOps考慮的還不止是軟件部署。它是一套針對這幾個部門間溝通與協作問題的流程和方法。
需要頻繁交付的企業可能更需要對DevOps有一個大致的瞭解。Flickr發展了自己的DevOps能力，使之能夠支撐業務部門“每天部署10次”的要求──如果一個組織要生產面向多種用戶、具備多樣功能的應用程序，其部署週期必然會很短。這種能力也被稱爲持續部署，並且經常與精益創業方法聯繫起來。 從2009年起，相關的工作組、專業組織和博客快速涌現。
DevOps的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但如今已屢見不鮮的──“熱補丁”）起到意義深遠的影響。在缺乏DevOps能力的組織中，開發與運營之間存在着信息“鴻溝”──例如運營人員要求更好的可靠性和安全性，開發人員則希望基礎設施響應更快，而業務用戶的需求則是更快地將更多的特性發布給最終用戶使用。這種信息鴻溝就是最常出問題的地方。