現(xiàn)在很多的項目團隊都只是依靠手工的驗收測試來驗收軟件是否滿足它的功能需求和非功能需求。他們也知道這樣會大大的影響項目的交付質(zhì)量和進度，但他們依舊會這么做，因為他們可能已經(jīng)嘗試過去寫測試，嘗試著搭建自動化測試的相關(guān)服務，但最終并沒能從中獲取到很大的好處而且浪費了大量的精力，所以他們寧愿去手動去測試，遇到 bug 了手動去排除并修復。

當然了，這并不是說寫測試不好，相反的，寫測試是非常重要的，但更重要的是我們必須要認識到相關(guān)的測試策略并正確的選用它，從而為自動的項目實現(xiàn)一套合適自身的部署流程線。測試策略的設計目的主要是識別和評估項目風險的優(yōu)先級，以決定采用哪些行動來緩解風險的一個過程。這也就意味著，寫一次測試并不是一勞永逸的，對于一些自動化測試，我們應還需要不斷的去維護測試以保證客戶需要的功能被正確的實現(xiàn)，在開發(fā)功能之前我們就應該將測試寫好，一開始就將質(zhì)量內(nèi)嵌到自動化測試中，這樣我們才能從中獲取最大的好處。

一 測試的分類

為了確保交付高質(zhì)量的應用軟件， Brian Marick 對測試進行了相應的建模，他根據(jù)兩個維度對測試進行了分類：

• 業(yè)務導向還是技術(shù)導向
• 支持開發(fā)過程還是為了對項目進行評價

分類

** 1、業(yè)務導向且支持開發(fā)過程的測試**

對應的分類

這一象限的測試也叫功能測試或驗收測試，目的是為了驗收當前開發(fā)的功能需求是否被正確的完成，驗收測試也可以測試系統(tǒng)特性的各方面，比如功能、容量、易用性和可變性等。一般我們應該在開發(fā)一個功能前就把驗收測試寫好，并采取自動化的形式去驗收，提前寫驗收測試也可以很好的明確功能需求，通過這些測試我們可以知道我們要做哪些功能。

系統(tǒng)的驗收測試應該運行在類生產(chǎn)環(huán)境，自動化測試的一些特性：

• 加快反饋的速度
• 減少了測試人員的工作負荷
• 讓測試人員可以集中精力去做探索性測試和一些必須手動測試的活動。
• 驗收測試也是一組回歸測試
• 寫出可讀的測試套件，這樣就可以從測試中生成需求說明文檔。這樣也就可以保證了文檔不會過時。

2、技術(shù)導向且支持開發(fā)過程的測試

對應的分類

這些自動化測試應該單獨由開發(fā)人員來創(chuàng)建和維護，這一象限的測試可以分為：

• 單元測試：一般需要依賴測試替身來模擬數(shù)據(jù)。因為不需要使用數(shù)據(jù)庫、文件系統(tǒng)...，所以速度會很快，這也意味著會得到更快的反饋，單元測試也是回歸測試套件的主要部分。
• 組件測試：用測試更大的功能集合，需要使用數(shù)據(jù)庫、文件系統(tǒng) ...，所以速度會相對較慢，組件測試也被稱為“集成測試”。
• 部署測試：為了檢查部署過程是否正常，也就是程序是否被正確的安裝、配置。

3、業(yè)務導向且評價項目的測試

對應的分類

• 演示：頻繁的向客戶演示新功能，以此快速的獲取反饋信息
• 探索性測試：執(zhí)行測試時，測試人員因該積極的去發(fā)現(xiàn)隱藏的缺陷，并創(chuàng)建新的自動化測試集合去覆蓋
• 易用性測試：驗證用戶是否能很容易的使用軟件完成工作（用戶體驗）
• beta 測試：驗證用戶是否對隱藏的新功能感興趣，從而判斷該功能的價值

4、技術(shù)導向且評價項目的測試

對應的分類

非功能測試是指除了功能之外的系統(tǒng)及其它方面的質(zhì)量，比如：容量、可用性、 安全性等。對非功能性的測試也是非常重要的，因為這因素可能會導致很大的潛在風險。 當然非功能性測試所需要的環(huán)境也更加苛刻，它需要專業(yè)的人員搭建一些特殊的環(huán)境來能實現(xiàn)，而且花費的時間也較長，所以非功能性測試的頻率會比較低，而且應該在開發(fā)的后期去進行測試。

二 測試替身

在自動化測試時測試替身扮演著一個非常重要的角色，比如在單元測試中通過模擬對象來代替系統(tǒng)的一部分，這樣就可以大大的提高測試的速度。
測試替身的分類：

• 啞對象(dump object)：指那些被傳遞但不被真正使用的對象，這些對象一般只是用于填充參數(shù)列表，只是起到一個占位的作用，沒有具體的含義。(如測試A類的run方法，需要在創(chuàng)建A類的實例時需要傳入B類實例，但run方法并沒有用到B類實)
• 假對象(fake object)：假對象相對于啞對象來說，要對耦合的組件有一些簡單的實現(xiàn)，實現(xiàn)我們在測試中要用到的方法，指定期望的行為（如返回期望的值）。假對象適用于替換產(chǎn)品代碼中使用的全局對象，或者創(chuàng)建的類
• 樁(stub)：測試樁與假對象有點類似，也要實現(xiàn)與產(chǎn)品代碼耦合的組件，指定期望的行為。這里最大的不同是測試樁需要注入到產(chǎn)品代碼中，從而在測試產(chǎn)品代碼時替換組件，執(zhí)行樁的行為。使用測試樁不需要進行備份和還原。
• spy：與測試樁類似，但是可以記錄樁使用的記錄，并進行驗證。
• 模擬對象(mock)：設定期望的行為，然后驗證期望的行為是否發(fā)生，從而達到測試產(chǎn)品代碼行為的目的。適用于驗證一些void的行為。

三 現(xiàn)實中的情況和對應策略

1、新項目

當我們著手開始一個項目的時候，這也是最容易開始做持續(xù)集成的時候，那么毫無疑問最重要的事情應該是先自動化驗收測試。我們需要

• 選擇技術(shù)平臺和測試工具
• 建立一個簡單的自動化構(gòu)建
• 制定遵守 INVEST 原則（獨立的、可協(xié)商的、有價值的、可估計的、小的、可測試的）的用戶故事及其考慮其驗收條件

步驟：

• 客戶、分析師和測試人員定義驗收條件
• 測試人員和開發(fā)人員一起基于驗收條件實現(xiàn)驗收測試的自動化
• 開發(fā)人員編碼來滿足驗收條件
• 只要有自動化測試失敗，開發(fā)人員都應該將它定義為最高優(yōu)先級并修復它。

2、正在進行中的項目

對一個正在進行中的項目去做自動化測試相比項目一開始就寫測試面臨著更大的壓力。最好的自動化測試的方式就是選擇應用程序中那些最常見最重要的用例開始寫測試，讓這些測試盡可能覆蓋更多的選項，一般覆蓋的范圍都會寬于用戶故事級別的驗收測試。

3、遺留的系統(tǒng)

去測試那些你修改的代碼就可。前提是你已經(jīng)搭建好自動化構(gòu)建流程。

幾個概念

• 可用性測試：讓用戶通過使用產(chǎn)品來評估產(chǎn)品的技術(shù)。
• 探索性測試：在進行測試的時候同時探索開發(fā)更多類型的測試從而改善測試流程。
• happy path：一個正確的執(zhí)行路徑
• alternate path ：多個可以相互替代的 path ，入口和過程可以不一樣，但是最終產(chǎn)生的用戶價值是一樣的
• sad path ：選擇一條執(zhí)行路徑產(chǎn)生的錯誤處理