<strike id="6ym2a"></strike>
<fieldset id="6ym2a"></fieldset>
blog已經轉移至github,大家請訪問 http://qaseven.github.io/
配置管理
配置管理在軟件開發項目中極其重要，它記錄了軟件開發流程的演進過程。它能夠實現軟件增量式開發，并隨時可以追溯或查看任意時間的軟件版本。持續集成一書中對配置管理是這樣定義的：
配置管理是指一個過程，通過該過程，所有與項目相關的產物，以及它們之間的關系都被唯一的定義、修改、存儲和檢索。
那么我們怎么做配置管理？
（一）版本控制
（1）首先我們需要一個版本控制系統，Subversion、Mercurial或者Git，對于一個分布式的團隊最好優先選擇Mercurial或者Git。
（2）把軟件開發有關的所有內容進行版本控制。包括源代碼、數據庫腳本、構建腳本、部署腳本、文檔、第三方依賴、MindMap等等。保證新加入的成員能夠很容易地從零開始工作，保證在新的測試或者生產中能輕松部署應用。
（3）頻繁提交代碼到主干。為了驗證修改的正確性，快速的得到反饋，以及能夠輕松地回滾到某個無錯誤的版本，提倡頻繁提交。
（4）提交注釋清晰明了。構建失敗時，為了能夠通過版本控制器查詢是誰破壞了構建，以及他做了哪些修改，提交代碼的時候必須使用意義明顯的提交注釋。建議第一段是簡短的總結，第二段是描述更多的修改細節。
（二）依賴管理
第三方庫文件是最常見的依賴，我們可以在本地建一個外部依賴庫的副本來統一管理所有依賴，如果你使用Maven，你就可以這樣做。
（三）環境配置
軟件最終的運行環境可能不止一個，而且每個軟件都會依賴的硬件、軟件、基礎設施或者外部系統才能工作。我們必須把環境配置自動且可靠化，可以借助Puppet或者CfEngine之類的工具軟件。
持續集成
敏捷宣言首要原則就是盡快的交付可工作的軟件到客戶手中，為了實現這一原則，控制成本并及早的驗證修改的正確性和快速得到反饋，提倡使用持續集成方法。
準備工作：
（1）版本控制
（2）自動化構建
（3）持續集成系統（Jenkins，Go，TeamCity等等）
（4）七步代碼提交法則。如下圖：
為了實現持續集成需要做一下準備： （1）頻繁提交 （2）創建全面的自動化測試套件（單元測試、功能測試等） （3）保持較短的構建和測試過程 （4）可視化構建狀態（可使用紅綠熔巖燈） 必不可少的實踐 （1）構建失敗后不要提交代碼 （2）提交前在本地運行所有的提交測試（單元測試、功能測試等） （3）等提交測試通過后再繼續工作 （4）下班之前，構建必須處于成功狀態 （5）若測試運行慢，就讓構建失敗 （6）若有編譯錯誤或者代碼風格問題，就讓構建失敗 持續集成改變了以往的軟件開發模式，使應用程序任何時候都處于可運行狀態，創建了一個快速的反饋環，使你能夠盡早的發現問題，而發現問題越早，修復成本越低。 測試策略 測試策略的設計主要是識別和評估項目風險的優先級，以及決定采用哪些行為來緩解風險的一個過程。 測試有很多種，Brian Marick提出了如下圖 所示的測試象限。 好的測試策略會帶來很多的積極作用。測試會建立我們的信心，使我們相信軟件可按預期正常運行。相關鏈接：軟件開發為何采用持續集成
為了實現持續集成需要做一下準備：
（1）頻繁提交
（2）創建全面的自動化測試套件（單元測試、功能測試等）
（3）保持較短的構建和測試過程
（4）可視化構建狀態（可使用紅綠熔巖燈）
必不可少的實踐
（1）構建失敗后不要提交代碼
（2）提交前在本地運行所有的提交測試（單元測試、功能測試等）
（3）等提交測試通過后再繼續工作
（4）下班之前，構建必須處于成功狀態
（5）若測試運行慢，就讓構建失敗
（6）若有編譯錯誤或者代碼風格問題，就讓構建失敗
持續集成改變了以往的軟件開發模式，使應用程序任何時候都處于可運行狀態，創建了一個快速的反饋環，使你能夠盡早的發現問題，而發現問題越早，修復成本越低。
測試策略
測試策略的設計主要是識別和評估項目風險的優先級，以及決定采用哪些行為來緩解風險的一個過程。
測試有很多種，Brian Marick提出了如下圖 所示的測試象限。
好的測試策略會帶來很多的積極作用。測試會建立我們的信心，使我們相信軟件可按預期正常運行。
相關鏈接：
軟件開發為何采用持續集成
posted on 2012-06-27 09:39 順其自然EVO 閱讀(655) 評論(0) 編輯 收藏 所屬分類: 測試學習專欄
Powered by: BlogJava Copyright © 順其自然EVO