測試多年，崩潰遇到無數，這個崩潰是比較典型的可以拿來紀念一下：
背景：線上出現崩潰bug，開發修復了，測試一下上線
目的：檢視是否修復成功
步驟：復現崩潰，驗證崩潰是否修復
測試思路：
1、安裝線上版本的測試包
2、復現bug，比較坑的是：
沒有明確的崩潰步驟，首先要收集資料；
bug日誌空，找開發要；
公式無；
3、與開發交流：為何出現這個bug？原因是：計算的中間環節，aim 算出結果為0，可實現盈虧/aim=roe
4、根據開發提示修改：im，iom欄位為0，線上測試版本無崩潰；
「holder_vol 和 close_vol 這個也設定為0「 ——根據提示繼續設定為0，無崩潰，我已經崩潰了，然後找開發，要公式：aim = hold_vol / (hold_vol + close_vol)
沒錯：1）這麼 修改沒有問題，說明線上沒有bug？
2）bug不是這裡的，是其他地方的？或者我的修改方式不對？
3）公式不對，或者公式不完整，重新要？
新公式如下：
4）好吧，有坑（開發給了崩潰日誌後，確實必崩，確實是這裡的bug；）咋辦？先復現崩潰，解析公式
崩潰發生是aim=0得到的。那麼aim如何才能為0？
a）im>mm 且im=0，不可能發生im=0，忽略這個情況；
可以試試會不會崩潰，試過發現不會崩潰
b）imc）imd）im分別嘗試過後，發現崩潰產生了，換新修改包後崩潰消失，說明已修復
這個bug不大好復現，因為資料不全，對分析來說還是比較坑對，但是這個bug還是比較好復現的因為bug日誌已經明確的表示出來了，加油吧，面對崩潰，自己不要先崩潰
常見的線上異常崩潰一
一 uitableview reloaddata的崩潰 tableview reloaddata 後當需要立即獲取tableview的cell 高度，或者需要滾動tableview，那麼直接在reloaddata後執行 是會有問題的。如 在專案中用到scrolltorowatindexpath，但程...
iOS線上APP崩潰 Crash 分析
這兩周一直在研究如何追蹤線上的bug，如何快速分析出程式到底崩潰在什麼地方，從底層了解crash是如何產生的 如何傳遞的 以及是如何分析出來的。雖然專案組並沒有對這些要求很嚴格，但是作為乙個高階開發人員這些是我們必須要了解的，要弄明白的。之前專案中用的是bugly，其實接入bugly之後，大部分問題...
記錄線上presto集群崩潰
公司線上presto集群在週末有大量的任務失敗，檢視了下機群的負載，除了coordinator，所有worker的cpu和記憶體基本上都耗盡了，檢視日誌，出現了很多worker節點被下線的情況，檢視jvn程序，出現了很多次full gc，而且時間非常長 首先我們判斷是不是網路問題，因為我們這邊的資料...