近期，為了對外縮短發布周期，對內建立更加快速的反饋機制，我們團隊全面嘗試了從“先開發后測試”到“邊開發邊測試”的轉變。在此過程中，我感到測試用例設計和評審、測試執行兩個活動需要做出一定的調整。
1、測試用例設計和評審：從時間驅動轉變為用戶故事驅動
當開發和測試順序執行時，我們的功能測試計劃會指定測試用例設計和評審時間。當開發和測試并行時，我們不再以時間的維度來計劃測試用例的設計和評審，而是以用戶故事的維度。我稱這一轉變為“從時間驅動的測試用例設計和評審轉為用戶故事驅動”。“用戶故事驅動的測試用例設計和評審”有兩個要點：（1）以用戶故事的優先級來確定測試用例設計的優先級；（2）配合開發節奏，以一個或多個用戶故事為批次，多次分批進行測試用例評審。為了讓團隊對測試用例設計的進度有一個直觀的了解，我們為每個用戶故事創建了一個設計測試用例的任務。
2、測試執行
（1）從廣度優先轉變為深度優先
以前的測試我們會安排多個輪次，每個輪次的測試重點和方法都有所變化。而現在再也沒有測試輪次的概念了，因為除了回歸測試期間，基本都是每日構建，有什么測什么。那么這樣的變化要求測試人員怎樣調整測試執行呢？我認為是要把“回鍋肉”模式變為“煮飯”模式。“回鍋肉”模式是先把五花肉煮個八成熟（類似我們先把某個用戶故事測試完成），然后再和大蒜等配料一起回到鍋里炒，并最終裝盤（類似我們通過回歸測試最后確保所有功能在一起工作正常，然后發布）。“煮飯”模式是“一灶火把飯煮熟”，因為夾生飯再煮又浪費時間又不好吃。這類似我們的測試要圍繞該用戶故事盡量一次測試充分，而不要象以前因為知道后續還有多輪測試而有意識地推遲某些當前就可以做的測試。從某種程度上說，是要把廣度優先測試轉移到深度優先測試。
當然，深度優先的一個缺陷在于可能會忽視用戶故事間的關系。因為用戶故事的INVEST（Independent，Negotiable，Verifiable，Estimable，Small，Testable）特性，故事間是比較獨立的。但是由用戶故事構成的系統卻不能忽視故事間的內在關聯。所以，我建議在測試單個用戶故事之后，在回歸測試之前，盡量穿插一定的用戶場景測試（scenario testing），把在某些用戶場景上自然集成起來的多個故事一起測試，從而盡早暴露故事間的一些缺陷，彌補深度優先測試的不足。當然，最后的回歸測試也是對深度優先測試的一個補充。
（2）測試執行需要借力于持續集成
持續集成不是傳統測試范疇的內容，但為了及時保衛勝利果實，對已經進行過測試之處的正確性和穩定性提供必要的及時的檢查和信心保障，持續集成不可或缺。邊開發邊測試的過程中，我們通過集成了自動化測試的每日構建，及時發現了由于版本不斷被修改而造成的意料之外的問題。開發人員也因為能將引起這些問題的原因及時鎖定在近期剛剛修改過的內容上而加快了修復一些棘手問題的速度。當開發和測試人員馬不停蹄地向前沖的時候，持續集成為我們鞏固了后方。
除了上述兩個較大的方面，我也隱約感到其它一些方面，如測試進度報告、測試人員心態的困擾等，也有一些變化，還有更多細節需要調整。所以，我們仍然需要擁抱變化，應需而變，持續調整和改進我們的測試實踐。
版權聲明：本文出自 zdlzx 的51Testing軟件測試博客：http://www.51testing.com/?56882
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。