背景：長期以來業務線測試有這種困擾：**業務線傳統的專案流程把開發、測試兩個階段分得比較明顯，導致開發趕時間寫**，提測階段測出一些低階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的開發工程師寫得不太好且消耗時間略多
2、c2b標準版（5.15-7.13，開發測試比4：0）。暴露乙個問題因為第乙個專案比較成功，所以第二個專案繼續沿用上一次的自測模式，專案流程基本不變。
效果：問題：
此次需求點很多，時間又緊，人員配置全部都是開發的情況下，沒有乙個人能夠關注到整體業務，對所有的業務邏輯能比較清晰。導致
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天
階段3：開發自測，優化流程，釋放測試資源合買版雙12活動（11.23-12.6，開發測試比4：1）
階段2進行得比較順利，於是接下來的專案繼續在此模式基礎上優化
優化點：
1）測試全程介入技術方案評審和**review
從技術方案開始介入，review sql、業務層**、vm層**
2）更加關注系統效能方面的東西
測試同學能有時間學習效能測試，並為系統進行了效能調優，為雙12做好準備
問題：前端**尚無能力review。
二、模式小結
有些人疑惑，開發自測後，測試幹什麼？
這就回到了開頭提到的困擾。開發自測模式，能把開發和測試從低階bug中解放出來，開發可以提高**質量，測試可以關注更深層次的系統質量（比如效能和**優化等），整個團隊能提公升效率，進入良性迴圈。
那麼寫了那麼多，經歷了半年多的探索，目前我們專案組到達了什麼程度呢？從專案模式、效果和測試同學的角色3方面來描述一下。
1、產出了乙個被現實考驗過的專案模式（當然還在繼續優化中）
開發同學要寫詳細、標準的uc，方便後續測試和維護；測試同學根據uc簡單得寫一些tc，方便開發自測
2）dao層單測
新增sql必須要寫單測用例，修改sql必須要回歸單測用例
3）業務層單測
已經有比較完善的單測環境，開發可以根據個人喜好，在manager層或ao層進行單測，無硬性要求
4）**review貫穿整個流程
分為兩類**review，目前我們專案組兩類並存
i.測試同學主導的每日review
專案裡每天測試同學都會review開發提交的**，這不僅僅是發現bug，目前我們的**review已經能到優化**或設計方案的階段。例如：
ii.傳統的專案組review
在專案後期集中式得進行一兩次review，有效果但量較大
5）功能自測&驗收
功能自測開發根據uc和tc進行；驗收是pd介入，頁面有新需求可以及時改動
6）整體測試
主要由我來執行，進行主流程測試和隨機測試，但不會覆蓋所有點，其他功能點的質量開發同學自己保證
2、效果1）工期縮短。這是最明顯的，目前這幾個專案的daily、預發測試時間加起來都沒超過1周的
2）質量提高。
i.開發同學的**質量提高了。以前測試同學都基本是保姆式的，現在測試介入得少了，遺**ug會增加嗎？剛開始開發會略感不適應，但長期來看對整個團隊肯定是有益的
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）完善回歸
方便開發自測，最好開發能根據改動點進行定製的指令碼回歸
做到了這些，就做成了乙個完整的開發自測生態圈。明年繼續努力！
***********************************=分割線******************************==
Android APP開發自測點
功能完成後，自測時的檢查點 1.思考某些情況下，某個變數是否會造成空指標問題 2.把手機橫屏，檢查布局是否有bug 3.在不同解析度的機型上，檢查布局是否有bug 4.切換到英文等外文本型下，檢查外文是否能完整顯示 5.從低版本公升級上來，會不會有問題，比如可能會出現資料庫不相容的問題 6.按下ho...
開發自測的原則
我是一名開發 在咱們開發的時間中,其實coding的時間所佔比例大概為30 大部分時間都在自測和改bug 但是許多新人覺得coding才是最重要的,而且把大部分精力花在coding上,其他的 自測,改bug,重構 不太重視 自測和改bug,歸根結底就是解決問題.解決問題的第一步,就是了解問題的現象,...
開發自測？開發與測試的戰爭
做測試的都會遇到過 開發提交的版本質量太差！開發人員提交測試後發現大部分主要功能都不通，後續告知修復完成，測試人員又去驗證，結果還是大部分功能不通，這樣的效率實在讓人無法忍受。開發自測自然在測試人員心 現！質量的提公升不只是測試團隊的事情，這句話貌似都在說，跟在喊口號一樣，並不能帶來實際的效果。開發...