如果這些笨辦法對你實在沒有吸引力, 可以看一下比較有技術含量的批量方法:http://wiki.winehq.org/UnitTestSuites

很多項目都有自己的單元測試, 如果你在Wine上面運行這些單元測試, 就變成一組非常有價值的Wine測試用例. (如果你恰好是某個Windows軟件的作者, 希望借助Wine將軟件移植到Linux/Mac, 其實只要在Wine下運行一下單元測試, 就能發現和解決絕大部分問題了.)

上面的例子不是特例, 其實很多項目都有前人總結開發出來的批量報bug方法或工具:

• 怎么批量發現Chromium/Firefox瀏覽器的bug? 有一個叫做Selenium的開源項目, 它是一個瀏覽器自動化測試工具, 支持IE, Firefox, Chromium以及一些手機瀏覽器:http://seleniumhq.org/

• 怎么批量發現linux桌面環境的bug? 有一個叫做linux desktop testing project的開源項目, 用來做桌面環境和圖形界面軟件的自動測試工具, 支持linux, windows 和 mac:http://ldtp.freedesktop.org/wiki

• 怎么批量發現LibreOffice/OpenOffice的bug? 我不知道有什么聰明的辦法, 但笨辦法倒是很簡單: 每個LibreOffice/OpenOffice跟MS office格式不兼容的地方都是一個bug. 面對格式兼容問題, 有的人只會抱怨, 有的人默默地拿走了5000美金... 從Libreoffice的wiki上可以看到, 已經有好幾個GSoC學生做的是改進格式兼容的工作.

其實, 凡是跟兼容靠邊的項目, 都很容易"制造"大量不兼容的bug :P mono, Wine, ReactOS, Haiku OS, LibreOffice/OpenOffice, mingw/mxe, gnash/lightspark, 這些都是跟兼容有關的項目, 只要google一下 XXX open source alternative, 可以發現兼容類開源項目還有很多, 這類項目非常需要志愿者去找bug報bug. 兼容性相關的問題常常是很有挑戰的技術難題, 開發調試不容易, 還時不時需要逆向工程, 遺憾的是這類項目卻被罵得最多, 真是吃力不討好. 如果我們都能做到多報bug, 少抱怨, 這個世界會變得更好.

批量報bug的方法通常跟自動測試/單元測試工具有關, open source testing項目為我們收集總結了大量的自動測試/單元測試工具:http://www.opensourcetesting.org/functional.php

如果給一般的項目報bug對你來說太沒技術含量怎么辦? 不用擔心, 總有夠硬的骨頭可以啃.

• 怎么批量發現gcc的bug? 這個我真不知道, 不過當我搜尋這個問題的答案的時候, 我發現Delta這個工具真是帥呆了:http://gcc.gnu.org/wiki/Aguidetotestcasereduction Delta是一個利用二分原理對代碼進行裁剪的工具, 對于診斷編譯器的bug有很大幫助. 如果報bug可以騙錢, 我會先學習Delta工具, 然后上GCC的bugzilla搜索前人報過的有效的bug, 親自重現幾十個bug.重現bug 其實跟 報bug一樣, 也是一種"掃地", 同樣能學到很多東西. 俗話說熟讀唐詩三百首,不會作詩也會吟, 如果你讀過的bug report夠多, 重現過的bug夠多, 那你也一定會找bug報bug. 像gcc這樣基礎而重要的項目, 對于新手來說確實不容易找到bug, 但也不是沒有機會. gcc在x86平臺上可能非常完善, 但在一些冷門的平臺上則未必有那么***, 這也是找bug的一種思路.

• 怎么批量發現內核的bug? 有一個開源項目叫做linux testing project, 是一個專門針對Linux內核開發的測試套件:http://ltp.sourceforge.net/ 同樣, 如果報內核的bug太難, 也可以先從重現別人的bug report開始入手, 照樣可以學到很多東西. 給內核找bug同樣不容易, 但也不是沒有機會, 一些冷門的平臺, 例如openrisc, 人手不一定夠, 肯定有很多bug等你捉 ;-)

很多人說Linux kernel穩定, 其實linux kernel哪里穩定? 測內核的最傷不起了, 新出的內核動不動就panic, 穩定的內核都是經過多輪測試的. 其實只要有足夠多的工業級測試, linux桌面也可以跟內核一樣穩定. 開源社區極缺大量志愿QA, 如果你愿意捉蟲, 到處歡迎你, 甚至巴不得手把手教你 (就怕人手不夠沒手教你...) 當你報了200個bug的時候, 會發現原來開源項目bug那么多, 人手那么少...

在批量找bug這件事上, 需要一定的創意和想象力. 比如Selenium原本的作用是測試瀏覽器, 內置了大量的browser test case, 而ReactOS是一個開源的仿Windows操作系統, 如果把這兩者組合起來, 在ReactOS上運行Windows版的Selenium+Firefox/Chrome, 那就變成一組現成的ReactOS test case了, 這時候還怕找不到ReactOS的bug嗎?

只要肯動腦, 一定能發明出前人沒想到過的批量找bug的方法. 還是那句話, 只要想一想5000美金, 辦法一定有的 :P 讀到這里, 也許你會發現, 報bug不是問題, 找bug也不是問題, 問題是木有項目!

很多人想參與開源項目, 卻不知參加什么項目好. 其實這個問題功利的答案很簡單: 如果是沖著GSoC的5000美金去報bug的, 那就去GSoC的官方網站查一下最近5年有哪些項目跟google合作過:http://code.google.com/intl/zh-CN/soc/ 看完之后可以猜出哪些項目明年參與合作的機會比較大, 然后就可以從中找感興趣的項目去研究. 如果過去對開源項目了解不多, 那么不妨花一兩個星期的時間廣泛瀏覽然后再篩選一些進一步鉆研.

不那么功利的答案: 只要是感興趣的任何項目都可以. 如果毫無頭緒, 不妨到ohloh.net上隨便瀏覽, 比如看看按活躍貢獻人數排名的top 1000:https://www.ohloh.net/p?page=100&sort=active_committers 如果找到一個感興趣的項目, 還可以在 ohloh.net 上搜索這個項目的related project, 一不小心就會牽出一批有趣的項目. 如果有多個候選項目要篩選出一個進行重點研究, 可以在 ohloh.net 上看一下這些項目的統計數據, 比如: - 近期代碼提交數量 - 最近一個月的new contributor的人數 - 高kudo rank的開發者的人數.

一個開源項目經常有新代碼提交, 說明這個項目很活躍, 加入活躍的項目才有活干, 給活躍項目報bug才有人處理; 一個項目經常有新貢獻者加入, 說明這個項目很吸引人并且對新人的門檻不是特別高; 一個項目有很多高kudo rank的開發者, 那么加入這個項目可以跟很多大牛學習.

如果找到這樣的項目, 但它以前沒有參與過GSoC, 也可以慫恿項目開發者明年向Google申請作為GSoC的合作項目, 當然, 申請不一定會成功, 因為每年只有大約200個項目有機會跟Google合作. 另外,Google每年都說不保證明年會繼續舉辦GSoC, 所以, 騙錢要趁早...

很多事情是知易行難, 報bug也一樣, 哪怕項目找到了, 批量報bug的方法也找到了, 堅持報200個bug也是一件不容易的事情.

怎樣才能找到足夠的動力持續去報bug呢? 其實也不難.

報bug被修復帶來的成就感, 本身就能激勵人繼續努力. 問題是, 不是每一個bug都能被及時修復. 很多新手經常問, 一個bug要多久才能修復? 網上流傳個段子, 正好回答了這個問題:

===
>> 師爺, 寫代碼最重要的是什么?
>淡定.
>> 師爺, 調試程序最重要的是什么?
>運氣.
===

這個段子很經典, 影響bug修復的因素太多了, 有的bug一天就能修復, 有的陳年老bug很多年都沒解決. 一個bug要多久才能被修復, 這個問題本身無法回答, 但是換個說法就能帶來希望: 報100個bug一年后會有多少個被修復? 根據我的粗略統計, 給Wine項目報100個bug, 一年后大約會有50個被修復. 換句話說, "bug半衰期" 差不多是1年. 其他開源項目, 只要是活躍開發中, "bug半衰期"應該都不會太長. 所以, 保持報bug的動力的方法之一就是多報bug, 這樣必定有一部分bug先被修復, 這些成果就會激勵自己繼續前進.

實際上, 保持動力的第二個方法仍然是 "多報bug". 當你報的bug足夠多的時候, 可能會發現只要你一段時間不上網, 郵箱里就有很多bug郵件等著你處理, 可能是開發者發布了新補丁等你幫忙測試, 也可能是一組相關聯的bug狀態發生變化需要重測, 這時候bug reporter的作用就很重要. 如果不回復, 開發者的工作就可能被阻塞, 意識到這一點, 就會加倍感受到自己在社區中的價值.

如果我說保持動力的第三個方法仍然是多報bug, 那我一定會被讀者罵死 :) 其實, 在我看來, 保持動力的最***辦法, 就是跟開源項目的其他貢獻者成為朋友. 加入一個國際性的開源項目, 可以認識到地球上不同角落的朋友, 也許有的角落你一輩子都沒有機會到達, 但是那里有個跟你素未謀面卻一樣為同一個開源項目做貢獻的人, 這是多么神奇的事情! 如果你得到某個老外的幫助, 一定要記住她/他的名字, 雖然老外的名字很難記; 如果你得到別人的鼓勵, 也不要忘了鼓勵別人, 大牛和菜鳥一樣都需要鼓勵. 如果你跟世界各地的開源項目貢獻者成為朋友, 就會加倍享受到開源的樂趣, 那個時候, 地球人都無法阻止你報bug了...

既然決心報bug, 就千萬別浪費一邊掃地一邊偷學的好機會, 這正是掃地僧的真諦所在. 開源社區里雖然不需要"偷", 但要觀察到別人忽略的東西, 學到別人沒學到的東西, 也需要 "留心", 所謂的 "偷學" 其實就是分外留心地觀察和學習. 只要有心, 報200個bug可以學到很多東西.

• 如果開發者反復追問bug的細節和日志, 你可以學習積累排錯調試的方法思路.
• 如果開發者關閉了重復的bug, 就應該注意學習搜索方法和積累搜索關鍵詞, 尤其是英文不好的新手.
• 如果一個bug被開發者確診為上游的bug, 你也可以順便了解上游項目.
• 對于大型項目, 要閱讀完所有代碼幾乎是不可能的, 報bug的過程可以熟悉局部代碼并逐漸入門開發:
• 如果開發者針對bug發布了一個補丁, 可以嘗試從這個補丁周圍的代碼入手閱讀和學習, 理解補丁的作用, 暫時忽略無關的代碼.
• 如果你自己報的bug足夠多, 可能會發現某些bug涉及的代碼似曾相識, 這時候不妨嘗試自己動手修改代碼, 也許是從協助診斷開始, 也許是從dirty hack開始, 慢慢地就可能從報bug進階到修bug.

值得強調的是, 如果你的目標是從報bug入門進階為開發, 那么從一開始就應該訂閱開源項目的patch列表和devel列表, 一開始讀不懂不要緊, 長期耳濡目染, 量變可能會引起質變, 這也是一種"掃地".

如果你像我當初一樣對自己的開發能力沒有足夠自信, 這種看似曲折的道路可以大大降低入門開發的門檻, 不知不覺增長信心. 如果你還是沒信心, 想一想5000美金吧 XD

除了這些能直接學到的東西, 報bug還能帶來很多間接的好處.

• 報bug的過程可以跟開發者熟悉甚至成為朋友, 將來他們能夠對你有很多幫助, 有開發方面的問題可以向他們請教.

• 報bug過程可以鍛煉英文!!! 如果你跟我一樣, 大學入學英語分班考試考到了最差的班, 那么趕緊去報bug. 當你報了200個bug的時候, 計算機專業英語肯定不是障礙. 我剛開始用英文給開源項目報bug的時候, 很多單詞不懂, 一邊寫bug report一邊查, 報一個bug花很多時間, 還戰戰兢兢生怕自己表達錯, 現在雖然英文也不太好, 但至少錢是騙到手了 =) 如果你在一個開源項目里混久了, 那么很容易會認識幾個老外朋友, 那時候遇到英語的問題你還可以向老外請教... (用英語請教LOL)

• 報bug的過程會逐漸改變自己的思維方式. 報10個bug跟報200個bug, 學到的東西不一樣, 思考方式也不一樣, 前者可能是從用戶的角度出發去思考問題, 而后者會迫使你從開源項目團隊的角度出發去思考問題, 例如:

• 怎么做才能提高bug被修復的概率?
• 怎么節省開發者的時間和自己的時間?
• 這個項目什么地方最需要改進?
• 怎么降低新手報bug的門檻?
• 等等 當你想這些問題的時候, 其實已經逐漸融入項目團隊了. 當你融入項目團隊了, 可能就會像我一樣沒事總想騙幾個人來幫忙... 所以就有了這篇文章 =)

報bug能學到很多東西, 可惜很多東西記錄不下來, 記下來的也可能會失真. 這也正常, 如果讀一讀別人的分享就能學到這些東西, 那又何必親力親為去掃地? 如果真的報了200個bug, 一定會充分掌握掃地僧騙錢大法, 申請GSoC成功的概率一定會很大. GSoC的學生需要在申請時說明自己想要為項目做什么貢獻, 盡管GSoC的合作項目會提供一些可選的任務, 但更鼓勵學生提出自己的idea. 如果你對項目很了解, 就容易提出自己的idea, 不會跟其他學生撞車. 如果你對項目很了解, 就會對不同任務的難度心里有數, 申請成功后也容易實現目標. 其實大多數被拒絕的學生, 不是idea太難不現實, 就是idea太容易騙錢意圖太明顯. 騙錢可以, 但不要太明顯 ;-)

其實, <<做一名開源社區的掃地僧(上)>>, 到這里就可以結束了. 也許有人會困惑, 這才剛講完掃地, 還沒開始講騙錢, 怎么就結束了? 有這樣的困惑, 正是紙上談兵的后果. 如果真的按照掃地僧打怪升級的道路去做, 會發現對自己幫助***的人, 其實是開源項目中的前輩, 而這篇文章***的作用無非是引誘多幾個人去嘗試, 真正的價值不大, 屬于讀過就可以忘掉的類型.

開源項目的前輩, 有的就是GSoC的潛在導師. 騙錢事宜, 都是導師說了算, 所以最重要的還是趕緊找個項目去跟潛在的導師混熟 ;-)

正經地說, 這篇文章希望探討的問題不僅僅是騙錢, 而是這么一個老大難的問題: 應屆畢業生找工作難! 沒有工作經驗, 所以找不到工作; 找不到工作, 所以沒有工作經驗.

其實對于未來碼農來說, 解決這個問題的辦法很簡單, 只要愿意在開源項目中找一份掃地的活干, 花個大半年的時間報一兩百個bug, 就能積累一定的經驗, 這個時候去找測試崗位的實習 [廣告1], 肯定很受歡迎, 而有了開源項目經歷和靠譜的實習, 肯定不怕找不到工作. 在開源項目中掃地掃久了, 還能逐漸進階入門開發, 如果成功參加過GSoC, 就更不愁找不到工作了.

當然, 參與開源項目實踐, 也不能包治百病. 比如, 參與開源項目不能代替學習計算機基礎和算法基礎, 不能代替閱讀好書. 不過, 多實踐對于明白需要學什么會很有幫助, 實踐遇到瓶頸的時候也會更容易發現自己讀書不夠. 再比如, 參與開源項目也不能代替企業的實習經歷, 實際上兩者都能學到很多東西, 但兩者互不可替代. 不過, 如果有開源項目的實踐經歷, 對于尋找更好的實習機會肯定大有幫助.

希望這篇文章對在讀本科新生或者研究生新生有幫助, 尤其是對開源感興趣卻不知如何入手的同學, 或者對開發感興趣卻經驗不足的同學. 開發能力很強的同學請不要被這篇文章誤導, 你應該向 google-opensource.blogspot.com 中記錄的優秀案例看齊, 爭取成為下一個優秀案例, 掃地的路徑不一定適合你, 我這種騙錢的技倆也不應該是你追求的層次 ;-)

GSoC每年報名申請的時間是4月份, 現在開始掃地距離GSoC2013還有半年的時間, 其實很充裕. 對于接近畢業面臨就業壓力的學生, 現在開始掃地合不合適我就不知道了 :P

我有一個小小的愿望, 希望以后國內的大學生爭先恐后給開源項目報bug, 通過報bug入門參與開源項目, 緊接著成功申請GSoC, 并且在騙完錢之后仍然繼續給開源項目做貢獻 ;-) 希望將來本科生參與開源項目就像現在的本科生參加數學建模競賽, ACM競賽, XXX軟件開發比賽一樣多. 想一想哪個比賽有5000美金, 就知道誰吸引力大了 XD

我還有一個大一點的愿望, 希望將來我們可以在國內舉辦比GSoC更大規模的夏令營, 鼓勵和支持更多的學生為開源項目做貢獻. 每年1000多名參加GSoC的學生中, 印度學生和美國學生是最多的, 都有200人上下, 而中國學生只有50人左右. 如果有更多中國學生愿意走"掃地僧路線", 我相信人數翻一翻兩翻完全不是問題. 但是如果大家真的爭先恐后都去申請GSoC了, 肯定也沒辦法全部申請成功, 畢竟機會有限. 我希望我們能夠舉辦一個"本土化類GSoC", 提供更多的機會, 當然這需要錢. 其實現在很多學校都喜歡舉辦ACM/數模等的院賽和校內賽, 是否以后也可以多舉辦一些院級或校級的"報bug掃地夏令營"呢?

有人會問, 如果掃地捉bug的人多了, 僧多bug少怎么辦? 我只能說, 我非常期待沒bug可報的那一天 ;-) 其實很多開源項目每年"制造"的bug遠不只200個, 比如Wine項目, 從2011年到2012年就增長了3500個bug. 粗略估計, 凡是ohloh.net上活躍貢獻人數排名前1000的項目, 每年都能制造成百上千個bug:https://www.ohloh.net/p?page=100&sort=active_committers 如果你不信, 你給我錢我找給你看 XD 活躍的開源項目其實是一直在發展中的, 簡直可以說是批量生bug, 所以bug是永遠捉不完的...

從捉bug入門進階開發, 不是新鮮事, 我只是跟隨前人的腳步走, 應該感謝掃地的前人. 劉未鵬寫過一篇文章, 叫做 <<怎樣花兩年時間面試一個人>>, 我的掃地僧計劃有很大程度上受到了這篇文章的啟發, 所以我還應該謝謝劉未鵬 ^_^ <<做一名開源社區的掃地僧>>, 其實就是從學生的角度出發, 對 <<怎樣花兩年時間面試一個人>> 的理論進行實踐. 有(上)自然有(下), <<掃地僧(下)>>也大致預謀好了, 但現在仍不能劇透, 否則一旦失敗就變成搞笑劇了 冏 其實, 最***的結果是, 這篇文章的學生讀者, 將來寫出成百上千各種版本的 <<掃地僧(下)>>.

雖然文章的標題叫做掃地僧, 可是文章的內容其實是"山寨掃地僧", 為了呼應金庸原著中的絕世掃地僧, 在結尾向大家介紹Wine社區的掃地高僧 Anastasius Focht, 十一年來他分析了成百上千個bug, 他的bug report就是Wine的調試教材...http://goo.gl/TxIvZ

***, 感謝我的GSoC導師Aric Stewart, 在Wine的開發中給我很多幫助. Aric Stewart是日本人, 我們都希望中日和平友好. 我相信開源不分種族性別信仰和國界. 感謝 Dan Kegal, Bruno Jesus, Austin English, André Hentschel 等幫助和鼓勵過我的開發者, 盡管他們看不懂中文 :-\ 感謝Google Open Source Team, 8年來為培養開源社區新人做了很多貢獻, 特別要感謝 Carol Smith, GSoC的成功舉辦離不開她.

親愛的讀者, 如果你讀到這里才想起自己已經不是學生, 猛然意識到GSoC騙錢已經與你無關, 那我只能說非常抱歉, 騙你讀了這么久... 如果你想報復社會, 就轉載這篇文章吧...

小調查: CrossOver (Wine的商業版) 將專門為中文用戶提供中文技術支持以及特別優惠. 如果你有時間, 請花3分鐘做一份關于 Wine / CrossOver 的調查, 一共只有6個問題, 非常感謝!http://goo.gl/aEfE4

Qian Hong fracting AT gmail DOT com 2012-10-12

[注1] 要了解技術性的內容, 可以看一下我的 "分享Wine調試經驗" 系列, 比如:https://groups.google.com/forum/?fromgroups=#!topic/gzlug/dGet0BGOikQ [廣告1] 代Kexin姐發個廣告: 紅帽北京長期招內核測試實習生, 歡迎在校學生投簡歷, google一下就可以找到相關信息. 如果感興趣但擔心自己達不到要求, 我建議從掃地開始 ;-) 如果掃地掃夠了準備出山, 也可以發信問我要Kexin的聯系方式.

全文轉載自郵件列表