【乙個要素是條件】
bug描述裡一般會列出這些條件：作業系統的版本號，環境變數配置了什麼值（這些變數也許會是乙個長長的列表），發生bug之前做了什麼操作（這些操作也許會是乙個長長的列表）。
我們需要從這個描述中找出導致bug的「條件要素」，才能更好的理解bug發生的原因，從而可以找到解決方案。這裡提到的「條件要素」是指，如果不執行某個測試步驟，就不會發生這個bug，那麼這個步驟就是「條件要素」。
對於能夠100%重現bug（或叫必現），我們既可以用下邊的方法去找「條件要素」，又可以直接用設定斷點的方式去發現**錯誤，不過設定哪個斷點也有很多可討論的地方，這些複雜的討論需要在開發者「做bug重現」時再去解決。在這兩種方法的具體選擇上，要看哪個方法更快、自己更熟悉等因素。
對於重現概率較低的bug，作為乙個開發者，如何在這些海量資訊面前，迅速找出那個決定性的條件？這絕對是個能力，而且有時很像智商測試題。這是程式設計師必備的技能，具體的方法有很多，其中乙個方法是「對比」。
現代版的俗話說：「沒有對比就沒有傷害」。
當開發者或測試者修改了某乙個測試步驟，例如改變了乙個環境變數的值、減少了乙個測試步驟、改變了兩個測試步驟的順序，等等，有時就會發現bug沒有了，那就證明是這次的測試步驟改變導致bug消失的，條件要素也就找到了。
這裡有兩個變化需要注意：
一、無論是必現的bug還是不必現的bug，修改乙個步驟後bug消失了，一般情況下就能判斷出是這次修改步驟導致的，但僅限於一般情況，還有其他情況導致bug發生，例如多執行緒，這些複雜的討論需要在開發者「做bug重現」時再去解決，這個階段只是為了讓專案經理、開發者、測試者看懂bug就足夠做決策用了。
二、一次只能改變乙個測試步驟，否則我們就無法準確知道是哪個改變導致的。
到此為止，方法是有了，但是方法還不夠有力。一旦測試步驟非常多，那麼需要對比的測試用例就多，有時會達到100條以上，這樣的效率就太低了，而且操作起來讓人心煩，根本找不到工作中的快樂。
好在我們還有更好的方法：谷歌搜尋的「手氣不錯」！也就是說，在把所有情況羅列出來以前，先用自己的直覺試驗乙個最有可能的用例，往往就能找到那個關鍵的條件要素。不過直覺需要知識和經驗的積累，更需要對經驗的「反芻」。
【另乙個要素是「錯誤是什麼」】
有人會說，「錯誤是什麼」不是明擺著的嗎？看完下邊這個例子，他就能體會到「明擺著」只是一種奢望：
有乙個bug的標題是：使用者開啟某個介面時，得到的人員列表不符合預期。
bug的細節描述是：當使用者開啟應用程式的乙個介面時，得到了乙個如下這個不符合預期的人員列表：
002 b先生
003 c小姐
001 a先生
而期望值是：
001 a先生
002 b先生
003 c小姐
理解錯誤的壞結果
如果這個列表比較長，那麼靠人眼去對比期望值和實際結果，需要多花一點時間。不要小看多花的這一點時間，一方面，人的大腦看到瑣碎的東西一定會比較累。
另一方面，如果是產品經理或專案經理在看這個列表，他不可能去看每乙個bug的細節，因為他需要站在乙個更高的視角去看待整個專案。所以他看到這種模糊不清的問題，要麼多花一些時間去仔細理解這個bug，要麼是認為自己理解清楚了，從而讓這個bug在整個開發鏈條中的多個人之間流轉一圈，最後bug仍然沒有解決，這樣一來，多花的時間就有些可觀了。
導致理解錯誤的淺層原因
下面就是乙個導致bug無效流轉的「坑」。
開發者看到這個結果對比的直覺是：一定是第一列的顯示順序錯了。之後，開發者就去改**，改完之後，測試者又發現了另外乙個bug：
當使用者開啟應用程式的乙個介面時，得到了乙個如下列表：
001 a先生
002 b先生
003 c小姐
004 a小姐
而期望值是：
001 a先生
004 a小姐
002 b先生
003 c小姐
實際上只是因為在這個列表中又加入一條資料而已，卻觸發了開發者改上乙個bug時的理解錯誤，導致修改bug的成本翻倍。
經過分析，終於得出結論：應該按照第二列排序，而不是第一列！
這還只是乙個最簡單的例子，大部分人還是能一眼就能看出來，但是，實際的工作中遠比這個情況複雜，想不「中招」就需要去蕪取精的能力了。
正確的做法是：
開發者看到這個問題，如果邏輯清晰的話，應該能想到有很多種情況導致這種錯誤，上文提到的只是其中的兩種情況，他想到之後要去找測試者確認，有時甚至要找到需求文件編寫者和產品經理。
導致理解錯誤的深層原因
表面上看起來這是個溝通問題，其實不是，這是因為：測試者確切地知道需求是什麼，只是他認為沒必要寫出來，而開發者也認為自己理解對了，也就沒必要再問，導致了bug的無效流轉。當大家都認為沒有分歧時，自然就不需要溝通，所以邏輯能力的欠缺才是深層原因！
解決邏輯能力欠缺的有效方法有兩個：長期來看，應該去學習、思考。短期來看，用最準確的語言去描述，例如上文的bug描述應改為：使用者開啟某個介面時，得到的人員列表應該按照第二列排序。
導致理解錯誤的知識原因
行文至此，如果讀者認為這就是「第二個要素：錯誤是什麼」的全部了，「也不過如此嘛」，那有時還會掉到下邊這個更深的「坑」裡：
對於使用分布式資料庫的系統，程式中傳給資料庫的sql中，如果沒有包含order by，那得到資料的順序是不會得到保證的！因為分布式資料庫為了提高效能，是用併發的方式從多個資料庫節點獲得資料，既然是併發，那就無法確定哪個節點的資料先傳到。
如果開發者沒有這個知識，或即便有這個知識而忘記了在這裡運用它，就會掉到上邊這個「深坑」裡。結果就是：讓乙個bug衍生出另外乙個bug，再衍生出第三個bug，讓這些「臭蟲」在開發者、測試者、專案經理、產品經理，甚至客戶那裡轉啊轉，創造出的gdp是很多了，但都是無價值甚至是負價值的gdp。
精彩的內容要和朋友分享哦
程式設計師都遇到過哪些誤解？
程式設計師 為計算機編寫 的人，按照現代企業研發部的崗位，分為 開發工程師，運維工程師，架構師，資料工程師，演算法工程師等 誤解 即事實是另外一種情況，而因為環境的複雜性或者訊息在傳播過程中失真，受眾認為事實是另外一種情況。為計算機編寫 的這一群體，都碰到過哪些訊息失真的情況呢？我是一名10年開發經...
90後的程式設計師何必迷茫
雖然，現在it產業發展迅猛 但是作為21世紀的主導 有何理由而迷茫去墮落逃避 即使it屆的牛人比比皆是，但是技術 總在更新總在普及，我們接受新技術的能力並不比他們差。還有這個時代的主導者是我們這一代，我們有何理由而止步不走 雖然我們的個性張揚揮灑，但是我們做事認真而富有激情，因為我們有一顆格物致知的...
程式設計師都知道的資料變數
承載資訊的符號 a 字串常量 hello b 整數常量 12,23 c 小數常量 12.345 d 字元常量 a a 0 e 布林常量 true,falsef 空常量 null 後面講 a 二進位制 由0，1組成。以0b開頭。b 八進位制 由0，1，7組成。以0開頭。c 十進位制 由0，1，9組成。...