@import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); 《轉載》開發(fā)自測一：掩月在房產項目中的試點 luoqing 發(fā)表于：2012-01-19 瀏覽：3238次 評論：0次 所屬分類： 系列活動 專題：開發(fā)自測 羅青：開發(fā)自測對開發(fā)團隊有什么優(yōu)點？ 掩月：在項目前期提升質量，在項目后期縮短周期，減少開發(fā)測試之間的溝通成本(bug, 需求，code， TC)，減少bug修復成本，減少回歸次數(shù)（回歸多， bug多，會打散開發(fā)的時間，碎隙時間難以利用） 羅青：開發(fā)自測對測試團隊有什么優(yōu)點？ 掩月：讓有限的測試同學能做更多的項目和日常，能做更重要的事情 羅青：開發(fā)自測效率如何? 掩月：有時候并行3個項目， 1個測試，7個開發(fā)，1個前端，20多個運營，一個項目100個TC，平均開發(fā)測試比為8:1，平均發(fā)布周期2周 羅青：開發(fā)自測質量如何? 掩月：房產這個產品從6月份開始，沒有任何線上故障，預發(fā)時發(fā)現(xiàn)的也是建議性bug 羅青：開發(fā)自測的形式有哪些? 掩月：小日常（活動類為主）開發(fā)自測直接上線，項目中部分模塊開發(fā)自測直接上線，其余模塊開發(fā)自測+測試驗收，目前開發(fā)自測直接上線的占比40% 羅青：開發(fā)自測在團隊中是怎么合作的? 掩月：從建立代碼分支就開始白盒掃描自測（包括安全），當天bug當天修復，中間開發(fā)根據UC, TC進行自測，daily, 預發(fā)，20多個運營一起進行驗收自測。 羅青：房產的開發(fā)自測有做過哪些類型的項目？ 掩月：兩種類型；數(shù)據準備型的最難開展開發(fā)自測，都需要測試準備好數(shù)據，才能進行測試；操作繁瑣型的容易開展開發(fā)自測，但是異常場景的校驗還是需要測試介入 羅青：2012年房產團隊的開發(fā)自測可以提高的點在哪里？ 掩月： 1. 需要建立自動的回歸體系-目前做的都是新的獨立功能，不涉及回歸，后續(xù)功能多了以后就會有大量的回歸工作，不可能依靠測試或者開發(fā)的手工回歸 2. 需要提升開發(fā)同學的測試思維，擴展開發(fā)自測的范圍從主流程到P3, P4—目前局限于活動頁面，開發(fā)同學的測試思維較狹窄，后續(xù)擴展范圍后，不可能僅僅做主流程的開發(fā)自測 3. 需要更適合的流程和工具支撐整個開發(fā)自測體系 羅青：開發(fā)自測對開發(fā)團隊有要求嗎? 掩月：房產團隊的開發(fā)有一半是新來的，很愿意接受新的思維，在測試給予建議和培訓后，質量意識提升很快，特別是有一個新女開發(fā)，0bug很強 歲晚：目前的自測對于開發(fā)團隊成員的成熟度依賴性比較高，就是說開發(fā)人員如果對于質量有比較強的意識，對于自己的code能用比較專業(yè)的角度去看（比如，站在測試的角度，愿意發(fā)現(xiàn)bug提高質量），那么這個團隊做開發(fā)自測就比較順暢，自測的質量也會比較好。如何在開發(fā)經驗少，質量意識薄弱的開發(fā)新人團隊進行開發(fā)自測？ 羅青： 我會持續(xù)的把各個團隊的開發(fā)自測情況進行分析，總結，建議和推進，這是第一份戰(zhàn)報 有任何團隊想開展開發(fā)自測的，已經開發(fā)自測的歡迎找我

和list&非標類團隊的開發(fā)同學合作了將近1年了，自己在這個階段看到了一些自測效果提升的情況，分享出來。下表是xlist&非標類團隊中15名開發(fā)同學2012年上半年和下半年的bug reopen率和低級bug率的統(tǒng)計。可以看到2項指標均有不同程度的下降。經過這半年的實踐，小談一下我接口的開發(fā)團隊的自測情況。

表一 list&非標類團隊中15名開發(fā)同學的bug統(tǒng)計

時間	總bug數(shù)	月均reopen率	月均低級bug率	備注
2012-02-01至2012-06-30	204	20.56%	10.53%	1.共計算5個月； 2.月均低級bug只有6月份有數(shù)據，因此這里算的是6月份 3.這個階段大家都沒有記錄低級bug，我估計是大家還沒有意識到低級bug的標記
2012-07-01至2012-11-30	212	0.83%	5.33%	共計算5個月

 

一、自測水平和代碼水平有關系么？

我認為，自測水平和代碼水平是弱關聯(lián)的。雖然編碼能力強，有助于自測的效率，但是并非編碼能力決定自測水平。

我覺得自測的覺悟和人本身的責任心是息息相關的，有些開發(fā)同學從始至終自測精神都非常好。例如，我一個對口產品線的開發(fā)同學：盈軒，我最早測試她的產品，她才開始coding，那個時候她讓我印象最深刻的就是，寫出來的業(yè)務邏輯，幾乎無bug。后來隨著她編碼能力越來越棒，自測也一直堅持做的非常好。

二、關于自測精神

我覺得自測精神是一個好開發(fā)應該具備的基本素質之一。假如我們比較代碼，在某個項目、某個日常里面碰到不那么靠譜的開發(fā)怎么辦？我覺得，他不重視，他的老大一定要重視。例如，我們對口開發(fā)組的主管索尼，非常重視開發(fā)自測的情況，每次質量團隊的bug統(tǒng)計數(shù)據出爐之后，索尼都會強調下自測的重要性。我想這樣是我們開發(fā)組自測風氣略有提升的原因之一。萬一主管也不重視呢？我也沒辦法了。

三、如何提升自測水平？

這一點，我本身是沒有經歷的。我只能分享給大家，我觀察到的。給大家分享幾個案例。女士優(yōu)先，先來說說女生吧。

盈軒，一個開發(fā)經驗不到2年的美女，但是代碼質量非常好。每次產品完成開發(fā)之后，盈軒幾乎自己會完整的測試一遍業(yè)務邏輯，還會關注下不同瀏覽器下的頁面表征。

臨意，如果你接口開發(fā)是臨意，那我只能說，你走運了，因為你確實可以少操心好多。我也曾問過臨意關于自測的看法，聊過單元測試之類的，他提到，單元測試還是功能自測都不重要，關鍵是開發(fā)要清楚業(yè)務邏輯，要分析記錄好自測點，然后再開始自測，不能一頓亂點。

少符，非常了解業(yè)務的開發(fā)，他自測的優(yōu)勢在于非常了解所負責的產品邏輯，并且設計測試主流程和分支流去自測。

本相，通過完整而詳細的UC指導自己的開發(fā)思路，完成開發(fā)只會會在本地自測業(yè)務邏輯。

通過他們的共性，可以總結出開發(fā)自測的要點：(1)理清楚業(yè)務邏輯，最好配以UC或思維導圖；(2)編碼完成后代碼部署到本地進行一遍完整的功能執(zhí)行，驗證數(shù)據輸入和輸出；(3)主管要重視；

四、哪些日常可以完全讓開發(fā)自測，測試不參與？

評估點：(1)日常的重要性。(2)開發(fā)對此業(yè)務的了解程度。如果開發(fā)新接手該業(yè)務，那么不管這個開發(fā)的代碼質量有多好，建議都不要完全自測；如果通過日常合作了解該開發(fā)清楚業(yè)務主流程，那么可考慮開發(fā)自測即可。(3)開發(fā)過往的代碼質量。

有時候日常感覺開發(fā)自測不完全放心的時候，可以考慮和開發(fā)一起評估UC，然后讓其自測。如果UC依然不放心，可以自己寫完TC，請開發(fā)同學執(zhí)行TC，全部通過才算自測通過。

天貓 軟件自動化測試開發(fā)