編寫背景：
最近親自在跟兩個(gè)重要項(xiàng)目，感受很多，明天準(zhǔn)備寫其中一個(gè)項(xiàng)目的項(xiàng)目測試總結(jié)在組內(nèi)分享，有一個(gè)還在背后默默關(guān)注。
在深圳工作1年了，每當(dāng)組內(nèi)的測試人員出現(xiàn)一些很常識的問題和面試過的測試人員回答的一些問題；非常明顯的感覺到南北測試人員工作水平和對測試工作理解的差異，在深圳想找到有共鳴的人好難啊。
今天寫這個(gè)文章，只是把工作中的一些片段和場景與大家分享，希望測試新人在做測試工作中多一些執(zhí)著、多一些思考和多問為什么？
故事1：搜索列表頁的一個(gè)神奇bug
問題現(xiàn)象：一個(gè)已經(jīng)測試通過并上線的商品搜索列表頁，頁面功能很簡單、有搜索的篩選項(xiàng)、商品展示、商品翻頁功能。通常大家在測試翻頁功能時(shí)，基本測試點(diǎn)都是測試上一頁、下一頁、具體頁數(shù)、頁數(shù)輸入框（正常、異常）；有意思的是這個(gè)搜索列表結(jié)果有500多個(gè)商品1百頁，我就一直點(diǎn)擊下一頁、一頁一頁的瀏覽商品，當(dāng)瀏覽到第24頁時(shí)，發(fā)現(xiàn)瀏覽器訪問報(bào)錯(cuò)提示連接不上；訪問其它網(wǎng)站或該網(wǎng)站的其它功能就正常。
問題分析：此處的點(diǎn)擊下一頁的翻頁程序代碼，每翻一頁，URL請求就會多加一串字符
“swIFRPIDUwMH0gcHJpY2VfQ05ZOjUwMDxKaW1pPnByaWNlX0NOWTp7MCBUTyA1MDB9IHByaWNlX0NOWTo1MDA8SmltaT5wcmljZV9DTlk6ez
AgVE8gNTAwfSBwcmljZV9DTlk6NTAwPEppbWk+cHJpY2VfQ05ZOn”；
這串字符出現(xiàn)6次以上后，url訪問長度超過2k瀏覽器請求就會參數(shù)丟失，導(dǎo)致頁面訪問報(bào)錯(cuò)
5個(gè)思考點(diǎn)：
思考1：為什么測試的時(shí)候沒有發(fā)現(xiàn)呢？其中一個(gè)測試人員說，這個(gè)場景很少有人想到。
思考2：測試人員如何能測試出這種問題呢？我在想，聰明的辦法那就是對設(shè)計(jì)實(shí)現(xiàn)熟悉了解，了解開發(fā)是如何實(shí)現(xiàn)的，應(yīng)該可以想出來這個(gè)地方會有問題。另一個(gè)辦法就是增加這樣的測試點(diǎn)，用自動化測試腳本來測試這種大數(shù)據(jù)量的功能極限測試。
思考3：對比其它網(wǎng)站，為什么別的網(wǎng)站沒有這種問題呢？開發(fā)在設(shè)計(jì)上沒有考慮這種情況？
思考4：為什么開發(fā)沒有自測發(fā)現(xiàn)這個(gè)問題？我在想，開發(fā)沒有考慮到URL會有問題
思考5：我們?nèi)绾胃倪M(jìn)和提高呢？我在想，測試除了要補(bǔ)充測試用例；開發(fā)要整理出搜索結(jié)果列表頁的一些設(shè)計(jì)規(guī)范，同時(shí)要參考和同行對比；開發(fā)要對系統(tǒng)的實(shí)現(xiàn)邏輯加強(qiáng)極限測試。
最后我想，還好這個(gè)場景不常見，影響范圍沒有很大的殺傷力。
故事2：兩個(gè)bug還是1個(gè)bug
現(xiàn)象：一個(gè)問題是：商品買滿打XX折，從購物車進(jìn)入到訂單提交頁中，商品總結(jié)算金額顯示不正確；另一個(gè)問題是：商品買滿減XX元，從購物車進(jìn)入到訂單提交頁中，商品總結(jié)算金額顯示不正確。開發(fā)認(rèn)為這是1個(gè)bug，因?yàn)槎际巧唐房偨Y(jié)算金額顯示不正確；我認(rèn)為是2個(gè)bug，因?yàn)槭莾蓚€(gè)不同的測試用例場景得出的問題，不能因?yàn)楝F(xiàn)象一樣就認(rèn)為是一個(gè)bug，同時(shí)懷疑代碼里面的處理邏輯是不一樣的。
分析：為什么這種問題在我過去工作8年的公司和開發(fā)團(tuán)隊(duì)，沒有開發(fā)管理人員認(rèn)為這類bug是1個(gè)，而認(rèn)為是2個(gè)；而這位開發(fā)管理人員認(rèn)為是1個(gè)；我在想：原因是這位開發(fā)管理人員很害怕bug？還是這位開發(fā)管理人員很不喜歡看到很多的bug，因?yàn)榻裉煳覀儨y試兩個(gè)頁面，4小時(shí)報(bào)了35個(gè)bug讓人心情很不爽？答案不知道，只要解決就好。
5個(gè)思考點(diǎn)？
思考1：站在用戶角度，如果是用戶發(fā)現(xiàn)的，我們告訴用戶是1個(gè)問題？用戶能明白嗎？
思考2：站在開發(fā)設(shè)計(jì)角度，需要知道那個(gè)地方的實(shí)現(xiàn)邏輯都是一個(gè)類或方法嗎？即使是一個(gè)類或方法，當(dāng)參數(shù)不一樣時(shí)內(nèi)部處理邏輯一樣嗎？找個(gè)時(shí)間問具體寫代碼的開發(fā)人員問問就知道了？
思考3：下次碰到此類開發(fā)管理人員該如何相處？我在想：只要改了就行，不能和這類人去糾結(jié)1個(gè)還是2個(gè)，因?yàn)榈啦煌荒芾斫猓坏菧y試工作總結(jié)時(shí)要算成2個(gè)。
思考4：為什么不能報(bào)成1個(gè)bug，因?yàn)楫?dāng)把多個(gè)bug放到1個(gè)bug里報(bào)時(shí)，如何有效跟蹤？（比如：開發(fā)修改轉(zhuǎn)測后，測試驗(yàn)證有一部分沒有修改好，這個(gè)bug會來回修復(fù)、打開）；如何有效做bug分析？（測試任務(wù)結(jié)束后，如何分類分析bug的錯(cuò)誤類型及開發(fā)工作改進(jìn)建議數(shù)據(jù)分析）。
思考5：為什么這么明顯的bug開發(fā)沒有自測出來？開發(fā)做自測了嗎？這樣的開發(fā)管理人員管理的開發(fā)團(tuán)隊(duì)，轉(zhuǎn)測出現(xiàn)這樣低級的bug，消耗了多少不必要的測試成本（測試環(huán)境部署+bug報(bào)告跟蹤和驗(yàn)證時(shí)間）和開發(fā)修復(fù)版本成本？降低了多少工作效率？這類bug有多少？
最后我想：我要通過什么方法來改變？
生活還在繼續(xù)、工作也在繼續(xù)，世界之大、無奇不有，每天都有不同的見聞和收獲，活著真好！