bug遺漏，我想這個是很多公司很多人頭痛的一個問題。眾所周知，bug是不可能被完全消滅的，當然也就意味着在發布前不能被全部找出來。於是乎當項目發布后，或多或少都會出現bug遺漏的現象，即使發布初期沒有發現，隨着時間的流逝，一些隱藏的bug也會慢慢浮現出來。那么對於遺漏的bug，我們該怎么去做？
古時雲：亡羊補牢，為時未晚也。對於遺漏的bug，我們應該去透徹的分析它產生的原因，然后吸取教訓，防止再次出現。這樣遺漏bug的數量就會越來越少，趨於0。那么怎樣的分析才是透徹的呢？我發表一下自己的觀點。
根據我的經驗，總結下來有以下幾點，首先從根源上說，需求的問題。需求是一切的根本，我們所做的一切都是在需求的基礎上進行的，那么需求會不會有問題？當然有啦，否則要需求評審干嘛，每次需求評審，或多或少都能發現一些需求的問題，在還沒有開始編碼之前就把需求的bug找出來，這個是最理想的狀態。顯然這個不現實，但是能多發現一個不合理的地方，那就能減少很多風險。因此需求關要把好。當然要求測試人員在需求評審時就要找出需求的bug，這個是要求比較高的，需要對業務的熟悉以及對相似產品的認識。需求關把好了，那么就算踏出了成功的第一步。
其次，要盡早與開發人員進行測試設計評審，統一對需求的認識（開發測試人員都可能存在對需求的認識不正確）。越早進行，越能夠避免出現因為對需求的認識不同而導致出現的問題（最可怕的是因此產生的隱性bug），這樣也能減少后期很多不必要的資源浪費。
接下來，就是用例設計了，這方面體現了一個測試人員的真實地能力。考慮的面要廣，包括:使用不同的測試方案，不同的測試數據的類型（要齊全），正常流與異常流等來覆蓋所有的需求。
然后就開始執行測試，要全面地執行測試用例，並且在測試過程中不斷的添加遺漏的用例。在時間允許下，盡可能的執行。
回歸階段，除了要回歸前面發現的bug，還要重視回歸那些bug相關的模塊，這個教訓是很多的，所以千萬不能忽視。一個小小的小小的參數變動可能引起一個比較遠的功能點的大bug，繼而引發遺漏。所以這個是需要開發人員與測試人員去識別的。開發人員熟知代碼，知道改動的地方會被哪些模塊調用或者會引起哪些變化，因此開發人員需要通知測試人員測試關注點以及加強自測。在開發人員與測試人員無間隔的合作下，這種bug的遺漏會減少很多。
發布前期，應該在保證所有的bug都fixed的前提下，把所有用例都回歸一下，以免遺漏。
最后終於發布了，發布好就可去FB了，^o^。不要在開心的情況下放松神經，所謂行百里，半九十，不能倒在最后的沖刺關頭。細心細心再細心。只要一步步走下來，那么就可以把遺漏的bug數量減到最低。
當然最好做自動化腳本，方便以后的回歸。這就是我想說的，大家有意見可以跟着，共同進步。
軟件測試干了幾年，項目一個接着一個，一路從一個坑跳入另一個坑，有些是開發問題，一些是測試本人問題，大家在測試過程中踩過哪些坑尼？
1.自以為了解業務邏輯，實際浮於表面
這是個深坑，產品迭代跟的久了，功能上閉着眼睛都能說清楚就自以為很了解，實際上連該功能使用的協議，調用的接口都不知道，所以看到問題都是表面的問題。
你只看到了兩個操作的入口不一樣，提示信息不一樣，你就以為是兩個問題，而這兩個問題都是調同一個接口引起的，但你分析不出來。。
這樣導致的問題有：
①修改bug后對影響范圍評估不夠
②提相同的bug，碰上特別注重bug數量的開發，真是揪心。。
我們公司對於bug定期要做bug根因分析，這在一定程度上也是幫助測試更深入的了解產品，因為每次bug單上開發寫的產生原因和解決方案，真是言簡意賅。。
2.思維定死，不會向前多走一步
比如同一個賬號添加之后刪除再添加，同一份文檔導入之后導出再導入，密碼修改成功之后再修改，等等，向前多走一步，就可能有意外收獲。
3.忽略偶現的問題
測試要記住：所有偶現的問題，都只是沒有找到必現的規律！
不要以為偶現的問題，沒有出現，就不提出來，等上線后用戶發現這個問題，你再說曾經遇到過，只是沒有提出來，那測試不背鍋還有誰背？？
提出問題但不解決，測試就可以甩鍋給產品，給開發，完美！（這個真是從踩過的坑里得出血淋淋的教訓）
這里有個好的習慣：遇到問題先截圖！！！先錄視頻！！！再分析原因，再提交給開發，最怕偶現的問題口說無憑，又沒有證據證明，開發說你逗我呢？？？
4.避免隨機測試
避免沒有用例而進行的隨機測試，雖然隨機測試能發現一些問題，但是它的特點是我們測試人員想到什么就測試什么，這樣就會導致有些功能點重復測試，而有的業務流程卻沒有覆蓋到，出現漏測，一旦上線后出現Bug，就不好說了。
5.Bug的復現步驟描述必須要詳細
這個其實算不上坑，只是個人總結。之前提交過一個Bug，Bug描述非常簡單，在后期給開發復現的時候，費了很大的勁兒，如果我們能在Bug描述中，准確描述Bug的復現步驟，就可以明顯縮短開發分析問題、定位問題的時間。
6.不要 “動” 之前的業務邏輯，因為會 “牽一發而動全身”
要 “遵守” 之前的業務邏輯，現有的業務邏輯盡量不要和之前的沖突，為啥呢？
因為啊，一旦按照現在業務邏輯的話，就得把之前的改了，改之前的業務邏輯會非常的復雜，不僅開發需要改代碼，而且我們測試要重新再測，所以，不要動之前的業務邏輯。