在這篇文章中，我們將圍繞測試組如何在組織中組織敏捷測試這個話題來展開討論。

　　傳統的軟件測試有非常明確的測試階段劃分和測試過程定義，按照時間順序開展每個階段的測試，以及按照時間順序組織每個階段的測試構成了傳統測試的主要組織方式。按照傳統的軟件測試階段劃分，軟件測試可以在時間序上被分為單元、集成、系統與用戶驗收測試，分別對應軟件的編碼、設計與需求階段。這種按照時間順序的測試階段劃分對傳統軟件開發而言非常適用：測試的每個階段用于對開發相應階段的產出進行校驗和確認，階段之間通過固定的輸入（通常以文檔體現）和輸出（例如測試報告）進行銜接。而傳統的軟件測試過程則一般被定義成測試需求、測試計劃、測試設計、測試執行與測試評估總結這五個時間序的步驟，用以指導每個階段中的測試。

　　在傳統的軟件開發模式中，這種明確的測試階段劃分和測試過程定義工作得非常好，但在敏捷的環境中，這種模式受到了很大的挑戰。挑戰首先在于測試階段的劃分上，敏捷測試鼓勵為產品建立各層面的驗證體系，從某種程度上來說，也可以將其對應到單元測試（代碼級別的測試）、集成測試（接口與服務測試）、系統測試（UI級別的測試、系統性能測試等）以及用戶驗收測試（接受測試）上，但在敏捷環境下，各測試階段間嚴格的時間順序不復存在，敏捷開發鼓勵并行，因此在一個敏捷項目中，單元、集成和系統等測試在時間順序上通常是同時發生的。

　　其次，挑戰來自于敏捷中所采納的方法：TDD、BDD和ATDD等技術的應用使得敏捷環境中的測試成為了超越驗證和確認開發階段產出的存在，測試一方面是驗證和確認，另一方面是設計。在這種情況下，一定要將測試劃分為時間序上的測試階段是非常不合理的。因此，在敏捷測試中，我傾向于拋棄單元測試、集成測試與系統測試的概念，而代之以代碼測試、服務/接口測試、系統測試 —— 后者突出的是測試的對象，而非階段。總而言之，在敏捷測試范圍內，我們不需要過多的關心什么類型的測試應該在什么時候發生，而是始終秉承設置盡可能多的不同層次的測試的理念，在整個開發過程中為產品設置盡可能多的測試。

　　相較于傳統軟件測試的測試過程而言，敏捷中的測試并不特別注重過程，但這并非意味著敏捷測試不需要過程的控制。實際上，如果考察敏捷開發的一個迭代，在一個迭代中發生的測試與傳統軟件測試在過程管理上還是有諸多類似之處的。通常一個迭代中的測試目標相對固定：針對迭代定義的新功能的驗證、針對原有功能的驗證、以及保證開發過程中的持續的開發質量。與傳統的軟件測試相比，在驗證方面，敏捷測試的一個迭代的測試目標與其基本一致；另一方面，由于測試執行活動仍然需要依賴計劃、用例等，對傳統軟件測試的過程稍加修改就可以將其應用在每個迭代的測試活動中。我建議在一個迭代中，針對驗證目標的測試仍然按照測試需求、測試計劃、測試設計與執行、以及測試評估總結的過程方式來管理，但是由于敏捷測試本身的特性（迭代周期短，因而每個迭代中新增內容的驗證不多；大量依賴自動化測試；依賴溝通而非文檔等），在具體的操作上有一些區別。以下是本人建議的在一個迭代中針對驗證與確認工作的測試流程：

收集和整理本迭代中的所有需求（主要體現為新增功能和原有功能的修改），建議以在線文檔（例如google的google docs）的方式管理每個迭代中的需求變化。通常需要對來自產品的需求進行一定程度的細化，細化到本產品的測試工程師能夠清楚理解需要驗證的點即可。測試需求通常需要與產品負責人和開發組確認（非正式評審）。

一頁紙（One Page）的測試計劃是一個很好的實踐。測試計劃中只需要包含本次迭代的目標，以及簡單的時間和資源計劃即可。

敏捷測試中的測試設計與執行通常是交織在一起的，對于新功能，測試工程師通常通過對新功能的使用和嘗試來了解之，然后為其設計測試用例并用腳本（手工測試用例或自動化腳本）的方式將其固定下來；而對于原有功能的測試主要依靠自動化測試來進行。在測試設計階段，測試工程師需要維護驗收測試，以保證其準確地反映了每個迭代的目標。推薦使用在線表格或是輕量的用例管理軟件對用例進行管理，在自動化程度比較高的情況下，甚至可以直接依賴測試需求列表和自動化測試腳本，而無需創建手工用例集合。

測試評估總結意味著對每個迭代中進行的測試進行評估與總結。與傳統的測試相同，敏捷測試中評估的主要目的同樣是獲得被測產品質量與測試質量的度量，但在具體方法上與傳統軟件測試有一定的差別。

• 測試需求
• 測試計劃
• 測試設計與執行
• 測試評估總結

　　在系統測試層面上，在傳統的軟件測試中，我們通常定義從測試需求到測試用例的跟蹤矩陣，基于這個矩陣計算測試覆蓋率，據此獲得測試質量度量，但在敏捷測試中，一方面，敏捷測試并不鼓勵建立完整的從測試需求到測試用例的跟蹤矩陣，因此很難的到一個精確的測試覆蓋度量；另一方面，敏捷測試大量使用探索性測試的方法，由于探索性測試在覆蓋方面的隨意性，也很難準確度量得到覆蓋率。

　　因此，我傾向于通過保證驗收測試的完備性和在更低層次衡量測試覆蓋率作為測試質量評估的標準。由于一個迭代的周期很短，因此一個迭代中能夠被添加和修改的功能較少，在這種情況下，維護完備的驗收測試應該不是非常困難；而在更底層的測試中，通過接口或是代碼覆蓋率來衡量已建立的測試的完備性是更合理的方式。

　　對于被測產品的質量評估則完全依靠為產品建立的各種不同層次的測試。與傳統軟件測試相比，敏捷測試有兩個主要的不同：首先，敏捷測試中的質量評估遍布整個開發過程，代碼評審、持續集成、開發測試、接口測試等各種測試遍布在整個開發過程中，通過這些評審和測試，能夠在各個維度上建立針對產品的質量評估；其次，敏捷測試通常非常看重產品的可測試性，因此，在整個質量評估體系中，對產品可測試性的評估是一個不能被忽略的因素。對產品可測試性的評估通過代碼評審、代碼測試覆蓋率（通常具有好的可測試性的代碼更容易達到更高的測試覆蓋率）或是使用其他相關工具進行評估。

　　敏捷中的測試總結工作則主要是收集整理各次迭代中可復用的測試資源，從探索性測試中總結發現缺陷的模式，以及從缺陷分析中獲得預防缺陷的信息。

　　當然，除了在每個迭代中針對迭代的目標建立和執行測試外，敏捷測試還意味著對產品質量和生產率的不斷促進和提升。我個人傾向于使用任務列表來描述敏捷測試中的相關任務：

• 建立和維護持續集成，建立基于持續集成的質量控制和發布規則
• 持續改進產品的自動化測試框架，提高自動化測試的穩定性，降低自動化測試成本，不斷提高測試覆蓋率
• 發現值得關注的測試切入點
• 持續推動可測試性的提高
• 通過缺陷成因分析獲得避免缺陷的信息，設立規則和實踐避免缺陷引入
• 提高探索性測試應用能力，通過探索性測試發現更多的缺陷
• 創建更高效的工具，盡量將測試推動到上游

　　圍繞提高生產率和提高質量這兩個目標，敏捷測試是一個持續的自改進過程，這就意味著敏捷測試中的測試工程師必須采用與傳統測試中不同的方式，持不同的測試理念和對待測試的態度。敏捷測試并非是一個面向過程的活動，一言以蔽之，在敏捷測試中，我們需要盡一切可能去考慮、去推動生產率的提高和質量的提升，將目光從單純的關注發現缺陷本身移出來，去發現更多、更遠、更有價值的需要去推動的事情。

　　關于作者

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