關於bug的案例分析

1.  原由

前兩天我公佈了一個京東微信端截取到的三張圖。並簡單闡述了這三張圖中的bug發現過程:

有朋友的評價是圖中這種，可實際上。他應該是沒有看出來這個bug表明的內容有多少。今天心血來潮決定具體寫一下。展示一下老程序猿的酸腐氣質！

 

 

2.  過程詳述

京東微信端可以簽到獲取金幣，天天一次一個金幣，結果沒有不論什麼提醒，簽到積累30金幣的時候就不能簽到了，我一直不知道怎麼回事。

這一天決定兌換一下這種100-10的券。因爲提示是早上9點開始，此前9點多點擊。都沒有搶到，我僅僅是認爲奇怪。

今天我仍然在9點多進行了點擊兌換，系統提演示樣例如如下圖所看到的：

系統告訴我兌換優惠券需要花費10金幣，我點擊立刻兌換。

 

結果系統顯示說，手速太慢。券已經被搶光了哦！

明天記得早點來搶哦！

 

可是我明明記得搶光了應該是灰色的。而這時候是紅色的。

注意。不是上面已領取得券。而是金幣30下方的券。

10點多。意外過來看了一眼，點了一下，居然兌換成功了，我連點了兩次，結果扣了我20金幣，系統告知僅僅能搶一張，我沒有太注意，也忘記截圖了。

下午最終看到系統表示券已經被搶完了。截了張圖例如如下。

 

這裏纔是搶光的結果。這時候，我看了一眼100-10的券。確實僅僅有一張。晚上又看了一次，發現變成兩張了，具體這裏就先不分析這個問題了。因爲要分析，我需要積累超過20金幣之後才幹進行這項測試。

如下咱們來分析一下爲何會發生上面的狀況，或者說。什麼狀況下會發生上面的狀況。

3.  分析

如下逐項進行相關bug的分析描寫敘述。

3.1          實際兌換時間與界面提示兌換時間不一樣

實際可以兌換的時間是10點，而界面提示是9點。

從這個現象可以看到例如如下問題：

1，         京東的測試團隊是分離的

業務邏輯測試團隊和界面測試團隊應該不是同一我的或者同一組人。

這在互聯網軟件測試中是有問題的。固然也可能就是同一我的，這我的太過於粗心了。只是，從常理來看通常不至於犯這種錯誤。

2。         代碼層面上界面推送和邏輯推斷沒有同步

這個問題很是嚴重，常規來講應該有兩種實現方式:

一種是懂一些技術的業務人員進行後臺設定和前臺頁面改動，固然，最大的多是一開始就考慮是9點。結果一個需求變動認爲是10點，而開發者忘記對頁面進行改動。測試因爲是兩批人在作。也沒有完畢同步。

或者說，京東研發測試團隊的需求跟蹤作得不到位，需求變動發生後沒有對所有涉及到該需求的點進行全面檢視。

 

還有一種是經過後臺邏輯代碼進行業務實現的設定和界面設定。

這種方式應該是最好的方式。也最easy避免這類問題。但，很是明顯京東沒有這樣作，多是人力不足。也多是倉促上線。可是上線已經半年的系統仍是這樣。就有點奇怪了。

Btw：我僅僅能說京東的開發團隊問題實在不是通常得多，你們可能會說，我靠打擊京東來宣傳本身，抱歉。假設這樣說，我四年前給幾個大學作的演講中對騰訊的批評不少其它，當中涉及到騰訊遊戲內部的很是多管理問題和開發問題的推演分析結果，這些結果都是獲得了騰訊遊戲集團級專家人員的認可。

3.2          提示信息與邏輯不符

明顯應該是灰色的時候才應該提示：手速太慢，券已經被搶光了哦！明天記得早點來搶哦！

卻在早上9點尚未開始搶的時候作出了這種提示。

這裏能看出來，京東研發中的任意性，提示是默認設定的，而不是與邏輯關聯的。

或者說，提示僅僅是前端的推送和後臺業務全然無關。

這種設定會使得推送的結果因爲前端程序猿的偷懶或者疏忽等問題而形成沒必要要的麻煩。甚至可能應該是每一個頁面單獨寫提示。而不是系統進行的統一提示告警處理模塊完畢的。

對於成熟的系統。所有的異常和提示信息應該是同一模塊統一完畢的。要依據不一樣的邏輯展示不一樣的提示結果，不至於讓用戶認爲很是奇怪。

固然，這裏很是有多是爲了下降先後臺的交互而刻意作的提示結果，也就是我前面提到的。前端程序猿疏忽或者偷懶就進行了默認設定。結果測試人員ye沒有測出來或者不負責任就直接經過上線執行了。

3.3          提示信息欠缺

金幣最多30枚。超過就不能領用。一個簡單的提示都沒有作，更可以看到京東系統的薄弱和問題所在。

 

這種系統邏輯錯誤放在十多年前咱們研發的電信行業業務系統中都是不可容忍的，京東的實際業務處理水平確實是至關得有問題。

3.4          前臺提示與後臺邏輯衝突後前臺的錯誤提示

仍是3.2問題的一個延續。

 

9點多點擊，提示：兌換優惠券需花費10金幣。說明這個業務邏輯沒有走後臺推斷。

而被拒絕後，前臺沒有獲取業務邏輯推斷的提醒代碼或者說沒有代碼。僅僅是給了一個拒絕信息，因而僅僅能提示用戶：手速太慢。券已經被搶光了哦！明天記得早點來搶哦！

 

這說明後臺邏輯的推送要麼沒有異常處理，要麼就是先後臺分離開發後，前臺對後臺的異常處理作了簡單化地響應處理。

這在業務邏輯上是不可能被容忍的。而這種錯誤居然都檢查不出來，京東的測試團隊的能力不是通常得弱小。