一些有價值bug產生的思考

一、異步處理時防止重複點擊的邏輯校驗

場景 打款請求時，進入異步處理的隊列，生成一個任務號，存在如數據庫，且狀態爲未完成。此時，若是併發操做，如重複點擊或者重複調用接口，則發出的兩條請求可能被分配到不一樣服務器處理，此時數據庫產生兩條數據，同一任務id對應不一樣進程id，屬於異常場景。程序邏輯判斷數據>2，不處理，則異步任務終止。

其中，重複點擊致使產生兩條數據的緣由僅爲猜想，實際排查過程當中發現，前端已經作了防重複點擊，多是後端的前置邏輯致使對同一批數據作兩次請求

總結    不只在同步業務處理時須要注意併發問題，異步任務時也須要根據實現邏輯關注中間狀態

解決  一、數據庫加聯合惟一索引，第二條數據寫不進去，直接將數據庫報錯拋出

         二、忽略兩天數據的場景，當作正常業務處理，兩條都進行更新

         三、 排查產生兩條數據的緣由，源頭上杜絕

最終方案選擇了2   當時我選擇的是1和3,1做爲當即解決的方案，在不動業務邏輯的場景下，解決問題，風險較小。3做爲後續的溯源頗有必要。可是最後沒爭過開發

二、臨時小需求對系統功能的影響，須要思考後再作迴歸

eg.列表新增字段的需求，須要新增一個時間標籤。當作一個簡單的迴歸時正常。可是這個列表中有三個寫入的業務類型，其中一個寫入類型與其餘寫入的函數不一樣。此時，因爲未對第三個業務類型進行迴歸，致使漏測。這也是爲何測試須要參與設計評審的緣由。

分析：正常的業務場景和實現方式來講，基於複用原則，和通用的代碼實現方式，這種寫入應該都是在同一個函數完成。可是防不勝防啊。需求急測試不能急，任何小的修改均可能對你以前的測試結果造成覆蓋

三、客戶端測試時，須要注意系統與原生兼容和交互，如獲取權限，打開文件等

四、先後端交互問題，前端頁面展現錯誤、請求參數錯誤、交互錯誤這種類型的bug咱就不提了。主要說一種，請求的同步和異步，也就是時間對請求結果的影響，和前端在處理請求結果時，是否會基於時間的考慮來展現返回結果。

先來個簡單的例子，在某修改功能中，要求前端請求後進行查詢，以便在列表展現上獲取剛纔的修改提交。此時，先發出修改請求，再發出查詢請求，若是修改請求仍在處理，尚未成功，便返回查詢結果，而後返回修改結果，修改爲功。此時就形成了展現內容與實際結果不一致。因此查詢接口應該等待修改接口返回結果後再發出

先後端交互中也存在同步異步問題。同步就是上面的例子。下面是先後端交互的兩種異步場景。

a、輪詢（polling） 間隔必定時間不斷向後端發送請求，如導出功能，第一次請求導出時，後端給到一個任務id，而後前端拿着這個id每隔1秒請求一次。肯定就是消耗大，有延遲。延遲問題能夠經過長輪詢方式解決，具體自行擴展

b、websocket是跟http同樣性質的傳輸協議。詳細區別本身找找，這裏就談一個，http是單向的，websocket是雙向的協議。因此很明瞭，websocket 協議中，服務器端會主動向瀏覽器端發送結果，進而能夠下降延遲。缺點就是資源消耗大。因此在生命週期結束時，應該關閉鏈接