背景

任何產品在研發階段總有那么一些讓人掉坑的缺陷，然而這些缺陷又是怎么去定義的呢？其實各種書籍和網上都有很好說法和定義，在這里就不再細詳說。寫這文章只是個人對bug理解和看法而已

例：測試web一個頁面時，加載完成的時間達到了5s以上，如果是你在操作，你會怎么去定義這個問題？有以下場景：

1、提出的bug，如何證明它不是bug

測試：這是個bug，頁面加載的時間都有5s以上了，測試了多次都是這樣的，很慢啊

開發：5s的加載時間很正常啊，你可以查查我代碼

需求：5s加載時間至少不會影響使用，客戶沒要求要求頁面響應要多快

項目經理：整體功能為主，這個不響影流程的暫不考慮

領導：能滿足客戶的要求即可

客戶：基本上能達到我們要求的功能和要求

路人甲：不好好測試，浪費時間來研究5s（無語）

路人乙：叫你來測試的，不是叫你來找茬的

路人丙：所有人都沒問題，就你說這個有意義嗎（鄙視的眼神）

……

你所認為的bug，被各種理由無奈的抹殺掉

2、提出的bug，如何證明它是bug

測試：這是個bug，頁面響應和加載時的io過高，經多次測試結果，HTTP 請求的連接、發送請求、等待回應的總時間達5000ms以上了，這樣影響了整體的性能和體驗

開發：有這么高了，我查查代碼

需求：5000ms加載時間太長了，客戶體驗肯定不行

項目經理：那么長的時長，代碼優化一下，控制在200ms～1000ms

領導：用戶體驗很重要，必須把時間縮短下來

客戶：這么長的加載時間，那樣不是很差嗎？我的客戶都不想用了

路人甲：打開頁面要花這么長時間，看來做的不怎么樣

路人乙：這個時間都能測出來，看來是拿著手機在計算時間（這么慢）

路人丙：這是誰開發的（那鄙視的眼神）

……

總結

同樣一個bug，看以什么樣的方式去證明它是什么。提出的問題，不能僅僅是以個人的想法去說服其他人，而是提出有價值且帶專業性的問題，能引起其他人來幫助自己一起去評估這問題，甚至于還幫助去解決問題，這就是共鳴效應。有時候不能以主觀的認知和經驗去判別一件事情的對錯，因為那樣對事件的本身是不公平的。

要善于從不同角度去分析事件的本身的價值和影響程度，是否能真正滿足整體的需求，還有是否是以負責任的態度在做事同樣很重要，對人對事負責任，反過來同樣會回報于己身。

框架理論和框架效應，這兩個理論很好的說明了。同樣是指同一件事情，有兩種邏輯思維和意義上相似的說法導致了不同的結果。

End

如果你對測試方面有更好的技術、想法和看法，我們可以一起聊聊。如何改善自己，提升做事效率，個人責任感……

歡迎來撩，但別撩我 ?^ _ ^ ? ? ? --by 王子