各位看官，可能看到標題的你一定認為這是一篇涉嫌“炒作”的文章，亦或是為了吸引眼球而起的標題，恭喜你猜對了一半，確實是為了吸引大家的關(guān)注而起的這個標題，不過不是為了“炒作”而只是為了讓更多人關(guān)注bug，重視bug，從而挖掘bug的潛在價值--技術(shù)團隊的財富。

Bug一詞估計也只有相關(guān)從業(yè)人員才會比較了解，我想了解它的人沒有一個不討厭它的。這一點從給它起的名字就可以看出來，“bug”翻譯成中文就是“蟲子”，大家對蟲子第一影響就是厭惡，所以沒人喜歡它是人之常情，今天我們卻要走相反的路線，好好的“夸一夸”令大家都不爽的“蟲子”。

研發(fā)人員的“錯題集”--bug追蹤記錄

說道錯題集估計大家都不陌生，但凡熱愛學習（關(guān)注成績）的同學可能都有自己的“武林秘籍”--考試或者練習測驗中做錯的題目。通過對這本武林秘籍中的題目進行針對性的練習，來減少重復踩坑帶來的分數(shù)損失。對于研發(fā)同學在研發(fā)階段產(chǎn)生的bug和線上出現(xiàn)的事故，我們也可以做個類比，把它們稱為研發(fā)同學的“錯題集”。對于研發(fā)同學如何對待這本“錯題集”，不僅僅關(guān)乎軟件代碼質(zhì)量的提高，更關(guān)乎個人技能的持續(xù)成長。如何讓一個人不重復犯同一類錯誤，如何讓一個團隊不重復踩相同的“技術(shù)坑 ”，如何把團隊付出昂貴代價積累下的經(jīng)驗傳承下來，一直都是技術(shù)管理者頭疼的問題。那“研發(fā)團隊錯題集”不失是一種可行的方案，通過實際的bug案例，產(chǎn)生的原因、造成的影響、如何避免類似問題的產(chǎn)生，可以讓新來的同學迅速繼承以前趟過的坑。我認為對技術(shù)團隊來說，技術(shù)積累大致可以分為兩類，“成功案例”和“失敗教訓”，我認為失敗教訓對其他團隊的參考意義更大，因為相對于成功來說，失敗有更大的普適性。綜上，認真對待自己犯過的“錯誤”，把它當做持續(xù)提高自己的“訓練集”，既能完成軟件代碼質(zhì)量的不斷提高，又能讓研發(fā)團隊整體戰(zhàn)斗力持續(xù)提升，你說它是不是一筆“財富”。

測試人員的“遺漏用例集”--非用例執(zhí)行bug記錄和在線bug記錄

如果你認為bug只是針對研發(fā)同學的，那就大錯特錯了。對于測試同學bug也是一種“財富”，這不僅僅體現(xiàn)在“工作量”上，更體現(xiàn)在后續(xù)根據(jù)bug不斷改進用例設計方法的實戰(zhàn)經(jīng)驗上。相信測試同學大部分會有這樣的經(jīng)歷。

經(jīng)歷A：

一期需求中辛辛苦苦準備了很多用例，開發(fā)提測后按照用例執(zhí)行一遍發(fā)現(xiàn)沒有發(fā)現(xiàn)幾個bug，于是基于職業(yè)敏感，開始又一輪的探索性測試，又發(fā)現(xiàn)很多bug，甚至比通過用例發(fā)現(xiàn)的bug還要多，于是提出“設計測試用例無用論”。（私下認為，應該是設計用例的方法有問題，需要改進設計用例的方法，并推廣之，讓更少的同學經(jīng)歷A事件）

經(jīng)歷B：

辛辛苦苦熬到需求上線，發(fā)布不久出現(xiàn)線上故障，緊急回滾或者緊急線上修復，所有事情都忙完后，開始準備線上故障報告，包括故障原因，開始時間，修復時間，解決方法，后續(xù)避免措施，懷著忐忑的心情結(jié)束一天的工作。

其實經(jīng)歷A、B本質(zhì)上講都是由于用例設計不充分導致的，在互聯(lián)網(wǎng)敏捷發(fā)布、持續(xù)交付的大環(huán)境下，如何更好更快的設計更加全面的測試用例是測試同學需要不斷追求的，而bug集恰恰是最好的“場景數(shù)據(jù)”，從這個角度講我想大家也都認為bug是一種財富。

bug不僅是軟件研發(fā)中發(fā)生的錯誤，同時也是幫助大家技能持續(xù)成長的一種財富，如何把這種潛在資產(chǎn)的價值發(fā)揮出來，是研發(fā)團隊需求不斷探索和實踐的。