建立在不可能出現的條件下的 bug 還算 bug 嗎？

假如淘寶的首頁沒有任何數據的時候，會出現一個bug，這算bug么

---

算，但是優先順序低

---

bug是誰提的？

測試人員不會提這種bug，他們自己折騰不出來。

用戶也不會提，他們不可能遇到。

單元測試可能遇到，遇到了就是bug。

---

加一個條件判斷，比證明一個條件不可能，通常更容易……

更不要說所謂不可能經常是你沒想到這個可能性而已~_~

假如你寫DAO，資料庫告訴你有0條商品，然後你crash了，這是bug。你得考慮是真沒數據還是被許可權問題、where條件啥的給過濾掉了

假如你寫前台，後台告訴你有0條數據，然後你腳本錯誤了，這是bug。也許當前用戶被ban了，就是不讓他看呢。也許愚人節玩笑，每個用戶當天第一次打開界面不讓他看到商品呢

假如你設計數據結構，定義 Person { byte Age; } ，然後crash了，這是bug。因為……

---

不應該算，這種情況都不能發生你管他幹嘛，如果這樣的話，軟體中的 Bug 豈不是無窮無盡了？

---

建立在不可能出現的條件下的 bug 還算 bug 嗎？

這個問題，容我想想。

以你的例子來說，「 淘寶的首頁沒有任何數據 」，這樣的情景，完全可以製造出來，在 「可能」 的條件下出現的程序錯誤，都算bug 。

至於你說的 「 建立在不可能出現的條件下的 bug 」，這樣的，不算是bug，為啥呢？因為條件 都 「 不可能 出現」，這種情況永遠都不會發生，也就不算bug 。

---

bug是運行錯誤不是代碼錯誤，不可能在不可能條件之後。

---

定義「不可能出現」。

淘寶首頁不一定要有商品，比如由於某些原因，淘寶的所有店鋪必須關停的時候。

這裡又要提到面向文檔和邏輯編程了——你的假設必須來自於文檔和邏輯。所謂文檔，包括軟體內部 API 的文檔、平台 API 的文檔、語言的文檔等等一系列。文檔相當於公理，在此假設下你可以推出一系列真命題，你可以安全地使用這些真命題（例如某一段代碼執行的時候一定具有某個不變式），除非你發現一個真命題的否定也是真命題——這個時候文檔是矛盾的。

假設淘寶使用一個 endpoint 提供首頁上應該展示的商品，那麼 endpoint 的文檔中，如果寫了 返回的數據集一定不是空，則可以安全地假設淘寶首頁上應該展示的商品總是存在的，否則，不能如此假設，尤其，如果文檔里寫了 返回的數據集可能是空。

當然，從目前來看，即使返回的數據集可能是空，這個事情發生的可能還是很小的，如果這個 bug 不嚴重，那麼是低優先順序。

————————

建立在不可能發生條件下的命題，永遠是真命題。舉例：如果 0 == 1，則 Windows 10 將會在安裝完畢、第一次配置之後把你的硬碟格式化。

這是對的，顯然不是 bug。

---

沒學過邏輯嗎，零推出任何值都是真的。

---

當然不算，只是現在的編譯器太不智能。無法做太難的邏輯分析

---

如果這個「不可能條件」發生了，那，

要麼是其他模塊的鍋，為什麼會產生這種不可能結果？

要麼是最初定這個模塊的需求的人的鍋，這明明不是不可能結果，你為什麼沒考慮到？

無論如何都不是最終負責實現這個模塊的人的鍋

---

從現實中來講，不可能條件下出現了BUG，那就代表實際很可能代碼邏輯有問題，進而可以推斷可能其他地方也有BUG。

---

算，如果有另一個bug會清空首頁那它就觸發了呀

---

結論上來說是「算bug」。因為題主的不可能存在是現實中不可能存在而不是邏輯上的不可能存在。若是邏輯上的不可能存在的條件也不會出現任何可能存在的結果了。

另外作為測試人員來說，這種現實中不存在的條件可能並不會納入測試範圍，所以不會發現而已

---

算，你的「建立在不可能出現的條件下」是你認為的，可能不是絕對不會出現。

另外有操守有時間的程序員一般就算這樣的問題也會去debug，除非debug的代價太大了。

---

物質終將毀滅，淘寶首頁肯定也有一天沒任何數據，你要證明你的代碼會早於淘寶死去。但這好難啊，還是去改bug吧。

---

被發現的，都算

---

這是薛定諤的bug。

---

需要定義什麼叫「不可能條件」

如果1大於2才會發生的bug叫bug嗎？

---

測試提出bug以後會有優先順序。弱步驟複雜但必先，肯定會提出，至於改與不改需要看項目周期靈活解決，還有要考慮遺留bug率問題。

---

你是說尼奧？

---

推薦閱讀：