1）Bug大都出現在程序員的編碼過程中。測試人員工作之一就是找出Bug，面對那些難以被人發現的Bug，測試人員通常會采取哪些手段？以您的經驗，對廣大測試人員有什么好的建議？對于開發人員，您有什么建議讓他們減少Bug的產生？

　　之所以難以發現，大多是測試案例不夠完整，檢查測試案例是否全面覆蓋了需求，等價類劃得是不是夠細有助于發現更多的問題。

　　如果已經發現的問題大多是猜測法發現的，那么慘了，這是一個天馬行空的測試，所有的BUG都將是難以發現的BUG，碰運氣吧。如果你真的是在這個不幸的團隊，別傷心，你有很多同伴都是這樣不幸，繼續用你學過的理論和可能不太多的編程經驗，挖邊界值，找亞邊界，偷聽開發人員聊天，看他們哪塊兒是趕工的，哪塊兒編得特艱難的，BUG往往在這里的，上升到理論就是20-80原則。

　　發現難以發現的BUG曾經是評價測試人員的一個重要指標，這要求測試人員細心，有耐心，分析能力強，知識面廣，逆向思維能力強，有創造力。要想練耐心細心，可以玩拼圖，練習在人民日報上找錯別字。練思維方式可以玩密室逃生，玩找不同。可以看出，測試人員還是滿講天份的，女生往往細心耐心有余創造力不足，男生偏向于跳躍思維，但往往坐不住。

　　隨著安全開發的概念的出現，軟件的不可控性下降了，大家可以等著看微軟Windows 7的補丁頻率是不是還像2000/XP那么頻繁。這個年代對測試人員的要求變成了開發能力強，要求結構化思維能力，簡單的說，人治變法治了。

　　開發人員的隨意性是很大的，據說中國的開發人員和印度的開發人員的差別就在于中國的開發人員喜歡小創新而印度的開發人員一般比較乖。對于控制BUG，人治不如法治，人治是指教育開發人員開發時要多做校驗，嚴格按需求開發，不要玩小創造等等，法制是指有嚴格的開發規范并有技術手段去保障開發人員遵守這樣的規范。別把開發人員累死也是減少BUG的重要方法，測試人員成長為項目經理時一定記著這一點。

　　（2）Bug除了出現在程序員編碼階段外，在測試過程中，會不會因為測試人員的操作失誤，亦或是其他原因，導致軟件出現Bug呢？

　　只要軟件還在生命周期里，都可能導致BUG的產生。在測試階段，測試人員沒發現的BUG，就留在軟件里了，測試人員理解錯誤，本來是毛毛蟲的BUG，他給理解成甲殼蟲的BUG，而開發人員也居然就給改成甲殼蟲了，也就引入了新的BUG。如果測試管理到位，測試人員發現的BUG不是直接交給開發人員，而是有個對需求了解比較好的管理者審一下，確定是否真的是BUG，再交給開發人員，可以有效地避免大部分測試導致的BUG。

　　編碼階段的BUG其實只是BUG出現的一個小方面，最多的BUG，或說最嚴重的BUG，往往是在需求階段，越早生成的BUG越難改，后果越嚴重。

　　（3）對于測試人員來講，除了借助于一些測試工具外，還應具備什么樣的個人能力？是否需要具備自己動手處理Bug能力？再則您認為軟件開發人員是否需要具備自我測試的能力？

　　會用測試工具在應聘時超級管用，但要想當一個合格的測試人員，工具外的功夫還需要很多修煉。測試人員的技術能力很重要，作為開發測試，問題報告是給開發人員看的，需要用開發人員能看得懂的語言，因此懂開發，用開發人員的語言去描述問題就非常重要了，而如果是第三方測試，那么問題單不僅開發人員要看懂，業務人員，也就是用戶也必需能看懂，這又要求測試人員要有被測軟件所應用的領域的知識。

　　表達能力也很重要，就是要把你發現的問題說明白，讓別人看得懂。好的程序員用注釋讓別人看得懂，好的測試人員不用注釋就得讓別人看得懂。特別是不容易重現的問題，需要描述很多問題出現的背景條件，絕對是一個挑戰。

　　就像你無法描述開發人員應當需要什么能力一樣，測試人員也各不相同，不管是技術強的，管理強的，溝通強的，腦子活的，細心的，耐心的，都會有發揮優勢的地方。

　　如果說一定要找一個最關鍵的能力，那就是責任心了。這是針對不太規范的測試而言，對于理想狀態的測試，如果測試案例都定好了，測試人員按部就班執行就好。但一般來說，測試方案都是粗線條的，那么做一個案例還是做兩上，猜測還是不猜測，都是測試人員主觀需要確定的，這時，有責任心的測試的價值就體現出現了。

　　我不建議測試人員自己動手處理BUG，開發人員和測試人員形成的相互制約在一定程度上保證了軟件的質量。測試人員如果自己處理BUG，引入新的BUG的概率會大增，而且發現這樣的BUG要比發現開發人員制造的BUG難得多。

　　同樣的道理，開發人員測試也會造成相互制約機制的破壞，因此，有條件的軟件公司最好不要讓軟件開發人員測試自己的軟件。但這也有一點例外，就是開發人員用白盒測試工具自己檢查自己代碼的質量，這樣的測試還是建議開發人員自己做的。

　　（4）我們經常看到一款軟件在正式發布后，仍存在很多Bug。在產品發布后，是否還需要人員去進行測試Bug？對一款產品的測試工作，Bug率達到一個怎樣的狀態才算作合格產品？

　　即使軟件再也不打算升級了，只有還在使用，測試就還有意義。測試可以為下次升級做準備，即使不再升級，測試也能給使用者以信心，對于存在的問題，給出解決或預防的辦法。更主要的是，用戶一定會發現問題，開發人員要么根據測試人員的復測情況進行修改，要么就只能教育用戶怎么避免問題了，比如：“那個地方千萬別輸入負數，否則系統會崩掉了”，多丟臉呀。

　　而如果一個軟件行將就木了，不僅不會再改，甚至不會再用了，那就別測了。

　　Bug率多高跟軟件給誰用有關，飛機火箭的BUG率要求肯定要比辦公軟件苛刻得多。套用一句據說是某快餐店銷售人員的話：“給冰激淋的量應該是客戶不投訴的最少量。”那么BUG率就應該是客戶還愿意選用你的軟件的最高BUG率就好了。對于一般軟件來說，這完全是個市場行為，客戶能接受，項目經理一定不會再投入測試人員了。而如果你的對手重重，或你有一個很有追求的上司，那么BUG率就會要求得比較嚴格。而對于飛機火箭來說，由于硬件投入大，政治影響大，事關人事等原因，BUG率的要求會非常苛刻，測試投入也應該大得多。

　　（5）您認為測試人員有沒有必要與開發人員在同一個項目組工作，能將Bug扼殺在萌芽狀態嗎？如果采用這樣的工作方法，責任應該如何界定，避免互相推諉？

　　將BUG扼殺在搖籃里是我們的終極追求。上面的問題談到開發人員可以利用白盒工具檢查自己的代碼，這樣就可以在代碼還沒有離開開發人員的手里的時候就殺掉它。在一個大型開發項目中，測試可能有很多的角色，如開發測試，為開發人員貼身服務，獨立于測試，跟開發人員背對背，跟蹤每一個研發版本，在發版前還有一個測試組，這個測試組發現的問題就要打開發和測試組的板子了。軟件發版后，再有一個測試組，專門針對用戶的反饋進行測試，將認為必要的改動記入下一個版本的需求中。

　　不管測試和開發是在一個項目組中還是完全獨立，出現推諉的原因一般是因為測試和開發上面共同的領導工作缺位，沒有一個老大說了算。測試人員發現開發人員的問題天經地義，似乎開發人員沒有反駁的余地，但測試人員也會有“水平有限，錯漏之處，敬請諒解”的地方，這要是讓開發人員揪住，當然會出現界定責任的問題。這就需要有一個站得更高的人，充分了解軟件的需求和設計，由他來充當裁判，一方面保證開發人員按要求修改問題，一方面把測試人員提得不合理的問題駁回，主持公道，解決爭端

　　專家簡介

　　朱璇，女，年齡絕密，計算機系統結構專業，中國軟件評測中心信息安全測試部副經理，十年軟件和信息系統測試工作經驗，目前主要從事信息安全測試，安全風險評估、安全技術研究和測試管理工作。