背景
任何產(chǎn)品在研發(fā)階段總有那么一些讓人掉坑的缺陷，然而這些缺陷又是怎么去定義的呢嗡载？其實各種書籍和網(wǎng)上都有很好說法和定義仍稀，在這里就不再細(xì)詳說。寫這文章只是個人對bug理解和看法而已
例：測試web一個頁面時技潘，加載完成的時間達(dá)到了5s以上享幽，如果是你在操作，你會怎么去定義這個問題值桩？有以下場景：
1、提出的bug奔坟，如何證明它不是bug
測試：這是個bug，頁面加載的時間都有5s以上了婉支，測試了多次都是這樣的澜建，很慢啊
開發(fā)：5s的加載時間很正常啊，你可以查查我代碼
需求：5s加載時間至少不會影響使用户誓，客戶沒要求要求頁面響應(yīng)要多快
項目經(jīng)理：整體功能為主幕侠，這個不響影流程的暫不考慮
領(lǐng)導(dǎo)：能滿足客戶的要求即可
客戶：基本上能達(dá)到我們要求的功能和要求
路人甲：不好好測試碍彭，浪費(fèi)時間來研究5s（無語）
路人乙：叫你來測試的，不是叫你來找茬的
路人丙：所有人都沒問題庇忌，就你說這個有意義嗎（鄙視的眼神）
……
你所認(rèn)為的bug，被各種理由無奈的抹殺掉
2疏橄、提出的bug，如何證明它是bug
測試：這是個bug捎迫，頁面響應(yīng)和加載時的io過高，經(jīng)多次測試結(jié)果贝次，HTTP 請求的連接彰导、發(fā)送請求、等待回應(yīng)的總時間達(dá)5000ms以上了位谋，這樣影響了整體的性能和體驗
開發(fā)：有這么高了，我查查代碼
需求：5000ms加載時間太長了盖腿，客戶體驗肯定不行
項目經(jīng)理：那么長的時長损同，代碼優(yōu)化一下，控制在200ms～1000ms
領(lǐng)導(dǎo)：用戶體驗很重要膏燃，必須把時間縮短下來
客戶：這么長的加載時間，那樣不是很差嗎等龙？我的客戶都不想用了
路人甲：打開頁面要花這么長時間伶贰，看來做的不怎么樣
路人乙：這個時間都能測出來，看來是拿著手機(jī)在計算時間（這么慢）
路人丙：這是誰開發(fā)的（那鄙視的眼神）
……
總結(jié)
同樣一個bug泥畅，看以什么樣的方式去證明它是什么琅翻。提出的問題，不能僅僅是以個人的想法去說服其他人方椎，而是提出有價值且?guī)I(yè)性的問題，能引起其他人來幫助自己一起去評估這問題琳疏，甚至于還幫助去解決問題，這就是共鳴效應(yīng)空盼。有時候不能以主觀的認(rèn)知和經(jīng)驗去判別一件事情的對錯，因為那樣對事件的本身是不公平的按咒。
要善于從不同角度去分析事件的本身的價值和影響程度但骨，是否能真正滿足整體的需求，還有是否是以負(fù)責(zé)任的態(tài)度在做事同樣很重要奔缠，對人對事負(fù)責(zé)任，反過來同樣會回報于己身两波。
框架理論和框架效應(yīng)闷哆，這兩個理論很好的說明了。同樣是指同一件事情抱怔，有兩種邏輯思維和意義上相似的說法導(dǎo)致了不同的結(jié)果屈留。
End
如果你對測試方面有更好的技術(shù)、想法和看法灌危，我們可以一起聊聊。如何改善自己沫勿，提升做事效率浅蚪，個人責(zé)任感……
歡迎來撩，但別撩我 ?^ _ ^ ? ? ? --by 王子
