※ 引述《EricTCartman (阿ㄆㄧㄚˇ)》之銘言：
: ※ 引述《jas1123kimo (傑森)》之銘言：
: : 2. 要怎麼Debug及測試
: : 因為小弟我之前都在學校，寫的程式不會這麼龐大?
: : Debug就是設定很多的Pritf看運作的參數
: : 或者丟各種測資，而且要每個Function都要跑到
: : 但每次這樣回答完
: : 面試官都露出應該還有其他的方法的臉看著我。
: : 請問還可以怎樣測試或Debug呢
: 1. 測試
: 單元測試 集成測試 重點應該是要能自動化
: 測資從正常數值開始抓 接著抓極端值
: 對於可邏輯產生的數值 也會自動化產生測資
: 會考慮輸入記憶體配置失敗 或外部資源無效時的案例
: 如果是performance-critical的區段 還會加上時間測量
: 測試時會將bug的情況作為test case追加
: 講完要反問一下面試官 你們覆蓋率幾%
: 2. Debug
: 首要工作是是要確立重現的流程
: 並且將重現bug的流程做到最精簡
: 原因：過於繁複的重現步驟表示涉及的程式碼越多 則越難找到bug的出處
: 對於我不熟悉的專案，我會從操作步驟的UI層開始追蹤
: 且如果是資料的錯誤，我會利用watcher監看資料實體是在哪個時機點被改變
: 如果是偶發的錯誤，我會利用conditional breakpoint增進debug的效率
: 莫名的資源無效或記憶體錯誤 我會檢查有無多執行續或重複釋放、destruction
: 等可能的行為
: 如果是第三方library或dll的bug，我會先閱讀文件確認使用方式無誤，如還是
: 無法發現問題則會到官方的bug tracker查詢有無類似情況。若以上均無解且與
: 該公司無合作關係或狀況急迫，我會以組合語言的形式下斷點並觀察memory變化
: 試圖出可能的原因，並從input或使用方式解決此問題
: 解釋完自己如何進行debug
: 如果之前面試官說公司測試覆蓋率不高或根本答非所問打太極的話
: 記得要反問面試官 貴公司修正bug後
: 如何確保不會產生其他bug 以及如何落實code reivew
先分清楚是production or UAT
若是production
先去windows 事件檢視簿調閱log
Or
/var/log/messages
調閱，從log中分析問題。通常9成可以馬上抓到問題。剩下一成是特殊案例。
若是UAT直接docker image 抓下來測試發生錯誤流程。若沒有docker先瞭解有沒有文件定
義業務流程，或者unit test，若覆蓋率太低或者文件不齊全則要trace code 一層一層追
。
確認好所有商務邏輯才能debug