什麼是敏捷軟體測試

【編者按】敏捷的理念已經深入人心，開發過程已經漸入佳境，測試的處境卻稍顯尷尬。測試從業者應該何去何從，怎樣才能擁抱敏捷，體現出自己新的價值呢？InfoQ特地邀請了來自Google的敏捷測試專家段念，為讀者答疑解惑，希望所有測試從業者可以從中得到自己的答案。更多關於敏捷測試的內容，請訪問InfoQ中文站敏捷測試相關內容。

在與不少測試從業人員討論到敏捷的時候，被問得最多的大約是兩個問題：“到底什麼是敏捷軟體測試？”，“敏捷軟體開發還需要測試工程師嗎？”。前一個問題是對於敏捷測試本身定義的疑問，第二個問題則是對敏捷開發將測試工程師排除在外的擔心。其實，在探尋這兩個問題答案的過程中，我們可以更清晰的瞭解敏捷軟體開發中測試的工作定義，測試價值觀，以及敏捷開發中開發與測試工程師的配合。鑑於這兩個問題的意義，在本敏捷測試專欄的第一篇文章中，本人嘗試從自己的實踐出發，儘可能清楚的回答這兩個問題。

確實，相對於敏捷開發紅遍大江南北的狀況而言，對敏捷測試的討論則低調得多。敏捷聯盟定義了敏捷的4個價值宣告，以及伴隨的12條支援原則，這12條原則中沒有一條單獨提到測試。這是不是意味著測試在敏捷開發中並不重要呢？實際上，如果仔細研讀敏捷的12個原則，以及各種不同的敏捷實踐，就會發現，測試在敏捷開發中佔有非常重要的地位。無論是原則中的“頻繁交付”，還是對“可工作的軟體”的度量，或是敏捷開發實踐中的“測試驅動開發”，“行為驅動開發”，都離不開測試的支援。在本人看來，敏捷開發中不把測試單獨拿出來描述的原因，恰恰是因為在敏捷開發中，測試不再是一個單獨的、和開發獨立的過程，而是變成了驅動開發、衡量產出的主要的手段，成為了敏捷開發中所有工程師在工作時必須時刻考慮和實踐的一個部分。簡而言之，敏捷軟體測試更多的是一種理念，而非過程。

既然是這樣，為什麼我們還要在這個專欄中專門來討論“敏捷軟體測試”？本人接觸過不少軟體開發和測試工程師，他們所處的組織有的正在努力向敏捷開發轉型，有的已經實踐了一段實踐的敏捷開發，但由於由來已久的工作習慣，他們中的絕大多數並不能自覺的認識到測試在敏捷開發中的關鍵作用，而是有意無意的將測試仍然看作是與開發截然分開的“下一個階段”，導致在實踐敏捷開發的過程中遇到種種問題：要麼是忽略了程式碼質量，導致在頻繁的迭代過程中，每一個迭代的問題層出不窮；或是沿用原有的方法安排對系統的系統測試，導致測試團隊疲於奔命，卻總也趕不上開發所要求的進度。在這種情況下，專門來討論敏捷軟體開發中的測試，也就是敏捷軟體測試的話題，對這些工程師應該會有一些幫助。

那麼，到底什麼是敏捷軟體測試？很難給敏捷測試下一個精確、完善的定義，在本人看來，接納了敏捷的核心價值觀（溝通，簡單，反饋，勇氣，尊重），在敏捷軟體開發過程中開展的測試就可以被稱作是敏捷軟體測試。因此，敏捷軟體測試並不是一個與敏捷軟體開發同一層次的劃分，而是敏捷軟體開發中的一部分，與傳統的測試不同，敏捷軟體測試並不是一個獨立的過程，相反，它與整個敏捷開發中的其他活動交織在一起，處處都能看到它的影子。由於敏捷軟體測試並不傾向於一個單獨的過程定義，本人擬從敏捷軟體測試與傳統測試觀點的比較、敏捷軟體測試中採用的方法、測試工程師在敏捷軟體測試過程中的工作等方面來闡述之。在這篇文章中，我們主要從巨集觀的角度來描述敏捷軟體測試，而在本專欄的後續文章中，我們將對敏捷軟體測試中採用的方法、工程師在敏捷軟體測試中的工作內容等進行進一步的描述。

敏捷軟體測試是建立在敏捷核心價值觀的基礎上，為了更生動的描述其與傳統軟體測試的區別，本人從自己的實踐經驗出發，嘗試給出包含了本人認為包含了敏捷測試關鍵要素的“敏捷測試檢查表”：

專案	檢查點	註釋
團隊	測試工程師是否與開發工程師建立了緊密聯絡？ 測試工程師是否與客戶建立和緊密聯絡？	是否參加每日站立會議？是否與開發工程師可以展開隨時的，面對面的，對等的討論？ 是否保持和客戶的良好溝通？是否和客戶一起維護良好定義的驗收測試？
反饋	專案是否建立了合適的驗收測試？ 是否專案中每個人都能隨時瞭解當前工作與可交付產品的距離？ 是否建立了針對開發質量的度量標準？ 開發工程師是否能夠快速得到對提交程式碼的反饋？	使用Dashboard、燃盡圖等方式展示當前工作與可交付產品之間的距離 建立單元測試覆蓋率等度量指標 使用持續整合或頻繁的構建讓開發工程師快速得到提交程式碼的質量反饋
質量文化	是否建立了開發與測試工程師共享質量目標的原則？ 團隊是否注重開發質量，並在工作中儘可能保證高的開發/程式碼質量？	共享質量目標意味著質量責任由所有工程師共同承擔 不僅關注最終的產出，不斷對程式碼進行重構，保證程式碼質量
開發測試	是否進行了充分的開發測試？ 是否設立了持續整合環境，並以持續整合的結果作為能夠繼續提交程式碼和釋出的條件？ 是否建立了足夠多的自動化測試，以及在設計時關注自動化測試的要求？	開發測試應該建立一定的測試覆蓋率標準，例如，在單元測試這個級別上，建立60%或80%的覆蓋率要求 通過使用TDD、BDD等技術，保證產品和程式碼的可測試性 建立足夠多的自動化測試，保證測試能夠滿足快速迭代的要求

檢查表提到了“團隊”、“反饋”、“質量文化”和“開發測試”四個方面的內容，在本人看來，這四個方面體現的就是敏捷軟體測試與傳統軟體測試的最大的不同。傳統軟體測試關注的是通過儘可能完備的“覆蓋”去發現儘可能多的問題，把測試和開發當成是兩個獨立的過程，測試是對開發階段產生成果的驗證。而敏捷軟體測試則建立了一種不同的質量文化：測試的目的是為了保證產品快速釋出，也就是對生產率本身的提高。基於“驗證”的出發點必然會要求測試與開發的獨立，以及儘可能“客觀”和“完備”的度量產品質量；而基於“生產率”的出發點則要求建立敏捷的團隊，要求測試與開發儘可能緊密，要求建立具有高度可測試性的軟體，以及基於這些的高度自動化測試。

在檢查表列出的所有專案中，“質量文化”是基礎，“團隊”是敏捷軟體測試得以實施的條件，“反饋”和“開發測試”則是敏捷軟體測試的具體方法。當然，你可以可以從敏捷的核心價值觀來階段這些專案：“團隊”關注的是溝通與尊重；“反饋”直接對應於反饋；“質量文化”基於勇氣（承擔質量責任的勇氣）與尊重；而“開發測試”則是反饋與簡單的具體體現。

另一個在本文最初提出來的問題是：“敏捷軟體開發還需要測試工程師嗎？”，對這個問題，業界有不同的觀點。有人認為需要，因為總有一些是需要測試工程師的技能完成的工作；當然，也有人認為不需要，因為敏捷開發中的測試注重開發測試與自動化測試，開發工程師就可以自己搞定與測試相關的工作。在實踐中，那些大規模實踐敏捷開發的公司（例如Google），傾向於在組織中設定數量較少的測試工程師，在專案中分配較少的測試資源，甚至對某些專案，完全不使用測試工程師。

就我的個人實踐經驗，對大部分的專案，尤其是為明確的客戶開發的專案，需要在敏捷開發團隊中設定專職的測試工程師，因為：

1. 測試與開發具有不同的思維方式：測試更注重全面的驗證和檢查一個系統，而開發工程師往往很難在大的範圍內建立這樣的思維方式。因此，無論是從系統的層面驗證產品，或是從應用系統的角度發現值得測試和驗證的點（access point），專職的測試工程師都更有效。
2. 專職的測試工程師能夠更關注於測試基礎，建立測試需要的基礎架構：由於測試工程師具有更好的對測試的理解，通常他們能夠更多的考慮測試的需求而開發適合專案的測試基礎架構（自動化測試框架），而開發工程師可以使用這些框架來建立面向功能或程式碼的測試。

但是，不得不說的是，敏捷開發對開發和測試工程師都提出了更要的要求，尤其是對測試工程師而言，傳統的只能“精確模擬使用者操作”的測試工程師，因為不能為產品帶來生產率的提升，在敏捷開發的團隊中，很難有所作為。在本專欄的後續文章中，我們會進一步討論測試工程師在敏捷軟體開發中的工作和任務。

關於作者

段念：Google中國高階測試經理，畢業於華中科技大學，先後在通訊、嵌入式軟體、網際網路等多個行業的國內外知名公司中從事軟體開發與測試工作。對軟體測試中的技術和管理工作有獨到見解，對軟體測試團隊管理、自動化測試、效能測試與開發測試有較多研究。

---

感謝張凱峰的策劃以及審校。