qileilove

　　長期以來業務線測試有這種困擾：淘寶業務線傳統的項目流程把開發、測試兩個階段分得比較明顯，導致開發趕時間寫代碼，提測階段測出一些低級bug；重新返工不僅測試時間延長，也導致開發、測試同學都累。

　 　在天彤的支持下，本人今年3月份來到C2B市場團隊輪崗開發，實踐了開發自測的項目模式。這是一個新產品團隊，新模式比較容易落地。迄今經歷了5個項目 （C2B公益概念版、C2B標準版、C2B公益版2期、C2B合買版和合買版雙12活動），摸索了近1年，有過困難和困惑，總體看來實踐效果還是挺不錯 的，分享一下。

　　分享分為實踐案例、模式小結和展望3部分

　　一、實踐案例

　　以時間為維度，實踐中經歷了以下3個階段。每個階段都是在前一階段模式的基礎上根據實際情況優化的

　　階段1：人人都是開發，沒有專職測試

　　有兩個項目

　　1、C2B團購概念版（3.20-4.15，開發測試比3：0），第1次實踐成功

　　這是第一次輕量級嘗試，加上我有3個開發，功能全部自測，最后我主導驗收了一下功能。項目流程如下

　　說明：

　　1）由于前端資源緊缺問題，所以后期才開始前端編碼

　　2）TC也要開發自己寫。給開發培訓了一下從UC到TC的轉化方法

　　3）整體驗收包括代碼review、PD驗收和我再覆蓋一下主流程

　　效果：

　　1）單測和接口測試覆蓋很好地保證了質量

　　在單測和接口測試階段都發現了bug，避免遺留到功能測試階段；后端編碼的穩定性，能讓開發在后期專注在前端功能的開發和聯調上，不用擔憂底層的質量

　　2）功能測試時間大大縮短

　　因為資源問題前端介入較晚，全部聯調好后離計劃發布日還剩2天，這兩天的功能測試時間里我們找出了大部分問題并解決了，完成了驗收和發布。項目總共花了19個工作日，開發時間稍微延長，測試時間大大縮短，總的項目時間是縮短的。

　　3）項目質量穩定

　　發布后，后端遺留一個因線上、daily環境不一致導致的bug；前臺遺留1個bug。在時間很有限的情況下，總體質量不錯

　　問題：

　　UC、TC有一定的重復工作量，初次編寫TC的開發工程師寫得不太好且消耗時間略多

　　因為第一個項目比較成功，所以第二個項目繼續沿用上一次的自測模式，項目流程基本不變。

　　效果：

　　關鍵詞還是前端資源緊張，全部聯調好后只剩下1天的daily測試時間。因為前期各自自測做得比較充分，所以依舊是后端穩定，前端小問題比較多。花了1天修復完大部分前端問題后，按時發布。

　　問題：

　　此次需求點很多，時間又緊，人員配置全部都是開發的情況下，沒有一個人能夠關注到整體業務，對所有的業務邏輯能比較清晰。導致

　　1）系統方面：后面新需求過來評估時，要花費更多的時間，潛在bug發生的可能性增加

　　2）業務方面：用戶體驗，對PD新需求的控制力什么的，照顧不太到

　　3）流程方面：UC略不規范，導致轉化成TC不太方便，也不方便別人看，不方便驗收和測試

　　階段2：開發自測，測試關注整體業務

　　1、公益版2期（7.13-8.3，開發測試比4：1）

　　2、合買版（10.19-11.3，開發測試比4：1）

　　這兩個項目又新增了開發資源，吸取了前兩次的經驗教訓后，繼續優化一下項目模式。

　　優化點：

　　1）項目里我不再擔任開發人員，全職做測試；因為前面兩個項目自測效果不錯，所以依舊堅持開發自測的思路

　　2）強化UC，弱化TC。開發不再編寫TC，但要詳細寫好UC。由我負責寫一些主流程TC和容易出錯環節的TC

　　弱化TC的原因：

　　i.和UC有重復工作量

　　ii.黑盒功能用例寫得再多也不能保證全部覆蓋

　　iii.TC也是給開發自測參考用的。開發自測習慣是根據代碼邏輯做功能測試，流程性的一般根據自己的UC進行自測，然后再覆蓋一下TC上容易遺漏的點，基本能滿足自測期望達到的目標

　　3）增強代碼review

　　測試從前期就介入代碼review中，避免項目后面大家一起review的工作量太大。項目代碼略穩定后，我每天花在代碼review上的時間至少占工作量的三分之一

　　4）完善回歸系統

　　效果：

　　1）測試能對整體業務點都很了解，并且能在前期就review出一些bug

　　2）從時間上可以看出，項目時間都在一個月內。這里測試時間壓縮了很多，兩個項目提測到發布都只花了4天

　　合買版雙12活動（11.23-12.6，開發測試比4：1）

　　階段2進行得比較順利，于是接下來的項目繼續在此模式基礎上優化

　　優化點：

　　1）測試全程介入技術方案評審和代碼review

　　從技術方案開始介入，review sql、業務層代碼、vm層代碼

　　2）更加關注系統性能方面的東西

　　測試同學能有時間學習性能測試，并為系統進行了性能調優，為雙12做好準備

　　問題：

　　前端代碼尚無能力review。

　　二、模式小結

　　有些人疑惑，開發自測后，測試干什么？

　　這就回到了開頭提到的困擾。開發自測模式，能把開發和測試從低級bug中解放出來，開發可以提高代碼質量，測試可以關注更深層次的系統質量（比如性能和代碼優化等），整個團隊能提升效率，進入良性循環。

　　那么寫了那么多，經歷了半年多的探索，目前我們項目組到達了什么程度呢？從項目模式、效果和測試同學的角色3方面來描述一下。

　　1、產出了一個被現實考驗過的項目模式（當然還在繼續優化中）

　　1）UC

　　開發同學要寫詳細、標準的UC，方便后續測試和維護；測試同學根據UC簡單得寫一些TC，方便開發自測

　　2）DAO層單測

　　新增sql必須要寫單測用例，修改sql必須要回歸單測用例

　　3）業務層單測

　　已經有比較完善的單測環境，開發可以根據個人喜好，在manager層或ao層進行單測，無硬性要求

　　4）代碼review貫穿整個流程

　　分為兩類代碼review，目前我們項目組兩類并存

　　i.測試同學主導的每日review

　　項目里每天測試同學都會review開發提交的代碼，這不僅僅是發現bug，目前我們的代碼review已經能到優化代碼或設計方案的階段。例如：http://kelude.taobao.net/issues/206462?page=1

　　ii.傳統的項目組review

　　在項目后期集中式得進行一兩次review，有效果但量較大

　　5）功能自測&驗收

　　功能自測開發根據UC和TC進行；驗收是PD介入，頁面有新需求可以及時改動

　　6）整體測試

　　主要由我來執行，進行主流程測試和隨機測試，但不會覆蓋所有點，其他功能點的質量開發同學自己保證

　　1）工期縮短。這是最明顯的，目前這幾個項目的daily、預發測試時間加起來都沒超過1周的

　　2）質量提高。

　　i.開發同學的代碼質量提高了。以前測試同學都基本是保姆式的，現在測試介入得少了，遺漏bug會增加嗎？剛開始開發會略感不適應，但長期來看對整個團隊肯定是有益的

　　ii.整個開發流程中，很多bug發現在前期，后期底層基本很穩定了

　　3）釋放測試資源

　　目前我們團隊的開發測試比是4:1，最高時是5:1。在開發大部分時間工作量飽和的情況下，測試資源基本能滿足項目組需要

　　4）周期快，能夠滿足一周多次發布的需求

　　交易線標準的日常流程：上一周提需求，周五UC評審，下周二提測，周三預發，周四發布。1周發布1次

　　目前我們日常主要靠 開發自測+代碼review+腳本回歸 保證質量，測試同學不用花太多精力進行功能測試。因此團隊效率很高，甚至能達到一天一次的發布頻率（當然發布多了不是好事）

　　3、測試同學的任務

　　從初級bug的痛苦中釋放出來后，測試關注什么？

　　1）業務方面

　　了解整體業務和邏輯，review覆蓋整個研發流程，包括技術方案、sql、業務代碼、vm，做一個熟悉整個系統的角色

　　2）持續回歸

　　這一直是測試同學的強項，維護一個成形的產品需要建立一套完善的回歸體系

　　3）其他方面

　　系統性能？算法測試？單測回歸？無線？隨便，因為有時間有精力了，都可以去做

　　三、展望。我們才剛開始

　　明年測試策略需要怎樣完善？產品在不斷迭代，市場在不斷增長，測試壓力得到釋放后，有更多的事等著我們去做。目前想到的有以下3點

　　1）測試數據

　　方便開發同學自測

　　2）前端代碼review

　　這一直是痛點，前端沒有成形的review機制。明年學習一下前端知識，希望在review上有所突破

　　3）完善回歸

　　方便開發自測，最好開發能根據改動點進行定制的腳本回歸

　　做到了這些，就做成了一個完整的開發自測生態圈。明年繼續努力！