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

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

表一 list&非標類團隊中15名開發同學的bug統計

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

 

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

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

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

二、關于自測精神

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

三、如何提升自測水平？

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

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

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

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

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

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

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

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

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

天貓 軟件自動化測試開發