1. 程式人生 > >處理bug的一些經驗總結

處理bug的一些經驗總結

如何積累解決bug的經驗?


遇到bug並解決了,詳細把bug表現描述出來,並把解決經過寫出來,做成筆記,就算以後不翻看,這樣至少會加深你對類似bug的印象,下回就會知道類似的問題如何解決;


程式執行緩慢,首先應該檢查資料結構是否合理,然後檢查遍歷這個資料結構的遍歷語句是否寫複雜了,能不能把遍歷降低;


遇到bug可以與周圍的同事或朋友進行探討,別人的思路可能會給你幫助,也可能別人曾經遇到過類似的問題。


第一條最重要,善於記錄問題和解決問題方案。


個人的一些bug解決經驗以及測試方面的分析:


輸入的內容,是否有最短或最長資料限制;


可能會產生多個數據的,儘量試試非常多的資料進行測試;


寫遍歷的時候,特別是多重遍歷,考慮是否會產生無限的遍歷計算(非常大的計算量);


做資料庫刪除的時候,考慮資料刪除條件是否完全正確,修改和查詢同樣如是;


存入資料的時候,驗證資料格式,以及考慮換行或特殊字元會造成前端json解析錯誤,此處不僅僅是指html層面的程式碼或JavaScript的程式碼造成注入漏洞;


更改了程式之後,儘量考慮周到有哪些地方會受到影響,最好是在寫註釋的時候註明有哪些地方會產生呼叫資料操作的時候一定要驗明許可權,驗證當前使用者是否有許可權做修改,包括當前資料是否屬於當前使用者等;


對一個數據操作之前,不要憑著想法,覺得是對的,一定要用程式驗明是否存在,並對驗明的結果進行使用者提示或者是報錯處理;此處分為使用者存資料到資料庫之前驗證,另一個就是取資料並進行操作的時候進行驗證,特別是沒有規定使用者必填,但是在顯示或者操作時候卻需要用到的資料,一定要驗明;


浮點數的計算丟失精度的問題,這個做稍微複雜的專案會遇到,此處把參加計算的資料都進行浮點型格式化並把得到的結果按需求四捨五入或其他方式取值,這種做法一般不會造成精度丟失;


兩個數參與除法運算,必須檢查除數是否會存在為0的情況,這種業務邏輯一般可能涉及到計算使用者好評率,計算使用者平均評星的情況,雖然這個除數不能為0是小學的知識點,但是開發過程中可能會漏掉監測,造成程式運算錯誤。

相關推薦

處理bug一些經驗總結

如何積累解決bug的經驗? 遇到bug並解決了,詳細把bug表現描述出來,並把解決經過寫出來,做成筆記,就算以後不翻看,這樣至少會加深你對類似bug的印象,下回就會知道類似的問題如何解決; 程式執行緩慢,首先應該檢查資料結構是否合理,然後檢查遍歷這個資料結構的遍歷語句是否寫

關於海量數據處理分析的經驗總結

建立 我們 網絡日誌 性能 結構 領域 要花 腳本 實施 對海量的數據進行處理是一項艱巨而復雜的任務。原因有以下幾個方面: 一、數據量過大,數據中什麽情況都可能存在。如果說有10條數據,那麽大不了每條去逐一檢查,人為處理,如果有上百條數據,也可以考

項目開發中遇到的Bug解決經驗總結

頭文件 net div pan line blog PE 導致 AR 今天在項目開發中遇到了兩個很難解決的bug,我把我的思路記錄下來,以供之後遇到bug時,提供一些思路:   編譯通過,但總結"core dumped"   這個是寫一個數據包捕捉函數的時候,程序編譯通

開發流程及團隊規範化的一些經驗總結

一、開發前: 開發模式採用流行的敏捷流程極限程式設計模式(XP)。 計劃任務:根據市場客戶需求了及現有的開發能力制定版本迭代週期和開發需求,如兩到三週一次版本釋出,再後期推動中不斷修正。 1. 需求:由專案經理或產品經理編寫需要說明書(PRD),讓測試和開發明確開發需求(使用

Elasticsearch & Logstash -- 一些經驗總結

本文作為一些實踐經驗的總結,未必是最佳實踐,歡迎大家交流。 ES叢集環境: 節點配置:  8核CPU, 48GB記憶體, 4*2TB磁碟JBOD 節點數量:9 作業系統:CentOS 6.4 Final JDK 1.7.0_45 ES版本:1.2.1 1.  通過管線

關於mongodb建立索引的一些經驗總結

想來接觸mongodb已經快一年了,對於它的索引知識也積攢了不少經驗,趁著這個月黑風高的夜晚,就把mongodb的索引總結一番吧。 一,索引介紹     mongodb具有兩類索引,分別為單鍵索引和複合索引。     1.單鍵索引是最簡單的一種索引,建立單鍵索引的開

專案的一些經驗總結

1、系統設計        在專案開始前的階段著重理解式樣書和需求,把握住專案整體框架(業務邏輯,程式流程)等大方向。然後根據式樣書的詳細程度確定是否需要詳細設計,詳細設計的製作可由高階程式設計師或專案經理參與設計,也可由程式設計師自身設計並整理形成文件,一方面促使對系統的理解和業務邏輯的正確把握,另一方面便

13 年的 Bug 除錯經驗總結

編碼 下面這些都是我經歷過的會導致難點bug的問題: 1、事件順序。在處理事件時,提出下列問題會很有成效:事件可以以不同的順序到達嗎?如果我們沒有接收到此事件會怎麼樣?如果此事件接連發生兩次會怎麼樣?哪怕通常不會發生,但系統(或互動系統)其他部分的bug可能會導致事件發生呢。 2、過早。這是第一點“

web api 中get和post一些經驗總結

        百度提示 常用的web api場景是一個介面多平臺呼叫,例如給安卓呼叫 給ios呼叫 給平板呼叫 主要為移動網際網路提供服務, web api雖然可以脫離iis自寄宿 但目前大多還是託管在IIS上的 會提示跨域呼叫錯誤 解決辦法好幾個 我採用cors(Cr

安卓App耗電量優化的一些經驗總結

1、準備工作 磨刀不誤砍柴工。開始優化工作之前,一定要確定“測試場景”和“測試用例” (1)應用後臺 ——滅屏 ——亮屏 (2)應用後臺 分析埋點資料 -> 找出高頻頁面 -> 頁面分類歸納 -> 總結出一系列場景 【備註】 <1>

關於程式設計的一些經驗總結

 編寫程式是一項系統而繁瑣的工作,它不僅需要程式設計人員具有一定的功底,更需要有良好的程式設計習慣和風格。良好的程式設計習慣和風格不僅可以使程式程式碼更易於讀懂和修改,更重要的是,它可以使程式的結構更加合理,有助於提高程式的執行效率。下面是我在程式設計中總結的一些經驗,供大家參考。    設計順序    在我

Altium Designer16繪制51單片機的一些經驗總結

改進 正常 排列 崩潰 寫博客 科技 紀念 ima 芯片 制作這塊51單片機的還是蠻艱辛的,應該是我水平太差,現在這塊51單片機已經穩定了,也把這塊板子制作過程中的一些問題及經驗總結記錄下來。這塊板子制作出了很大問題很大原因是因為我對Altium Designer16這個軟

內部業務系統的一些經驗總結

  從業那麼久,之前做的要不就是軟體外包,要不就是C端的產品,對於B端,或者企業內部系統還真沒怎麼接觸。   最近這兩年都是接觸愜意內部業務系統,其實也就那麼一回事而已,產品的設計還是那樣,只是會多了一個業務方、對接人,相比起C端使用者的不明確,需要自己去研究,自己去嘗試,企業內部業務系統,會有更明確的需求

【原】深度學習的一些經驗總結和建議 | To do v.s Not To Do

前言:本文同步釋出於公眾號:Charlotte資料探勘,歡迎關注,獲得最新干貨~     昨天看到幾篇不同的文章寫關於機器學習的to do & not to do,有些觀點贊同,有些不贊同,是現在演算法崗位這麼熱門,已經不像幾年前一樣,可能跑過一些專案、懂點原理就可以了,現在對大家的要求更高,尤其工

(轉)基於MVC4+EasyUI的Web開發框架經驗總結(6)--在頁面中應用下拉列表的處理

ica new web開發 don ext images 如果 bob 獲取 http://www.cnblogs.com/wuhuacong/p/3840321.html 在很多Web界面中,我們都可以看到很多下拉列表的元素,有些是固定的,有些是動態的;有些是字典內容,

Hybrid APP混合開發的一些經驗總結

後臺 機制 獲取 功能 前端 如果 導致 接口 編寫 寫在前面: 由於業務需要,接觸到一個Hybrid APP混合開發的項目。當時是第一次接觸混合開發,有一些經驗和總結,歡迎各位一起交流學習~ 1、混合開發概述 Hybrid App主要以JS+Native兩者

Java 異常處理的誤區和經驗總結

ORC 進一步 相關 ror final 額外 檢測 業務 清理資源 一 異常分檢測異常和非檢測異常,異常的應用情景可以概括為以下: 調用代碼不能繼續執行,需要立即終止。出現這種情況的可能性太多太多,例如服務器連接不上、參數不正確等。這些時候都適用非檢測異常,不需要調用

每一個程序員都應該知道的高並發處理技巧、創業公司如何解決高並發問題、互聯網高並發問題解決思路、caoz大神多年經驗總結分享

海量數據 限定 微博 https 2.3 tst 日誌分析 如何 ive 目錄: 場景及解決方法解讀 認識負載 數據跟蹤 腦圖、caoz大神公眾號分享 參考資料 秉承知其然及其所以然的思路,以撥蟬拔絲的思維,一一解讀各個技巧的使用場景: a.網絡通道+前臺控制 原因

image_pyradid和自己的一些訓練經驗總結

nbsp 一個 技術 物體 感覺 自己的 其他 什麽 img 這是訓練的路錐、警示柱的數據,也就是小物體的.小物體有兩個定義,一個是本身像素少,另一個是物體相對於整張圖片的比例小 這是把圖片縮小到600 proposal_target_layer選取用來訓練的pro

HTTP介面自動化經驗總結(三)Okhttp3 介面測試框架搭建之資料處理

上篇文章寫了怎麼新建POST,GET方法。這篇文章介紹下該如何校驗。 因為我們在方法裡面都返回了String型別結果,String型別校驗起來比較麻煩。多數http介面返回的都是json形式。我們可以寫一個通用方法將String型別轉換為Map物件這樣校驗就比較方便準確了。廢話不多說直接上方法。