如何debug.... 上面有蠻多文章看來是蠻認真的RD會做的事情，但是忽略了一些在真實世界會碰到 的狀況，而且會因為這樣撞的滿頭包。 首先，要定義什麼叫做bug，通常是由其他人經由某種文件格式，回報這個軟題的 行為跟預期不同。 例如說某個人哀號：C1設定下去之後螢幕變成黑色的，但是應該要是紅色！ 第一步驟是，確認這個回報的問提是否是合乎軟體規格的，很可能是這個人誤會了 軟體的規格，或者是拿了錯誤的規格版本。例如v3.2.7之後天殺的PM改了C1的行為... 如果確定這個回報的資料是正確的，第二部就是複製這個錯誤。 ．．．．． 這又是天殺的難關，大部分好重現或者容易碰到的問題早就在初期解掉了，會交給你 這個菜鳥通常是不好重現。例如說使用者會說他連續操作這個app 30分鐘，出現了一 次這個bug.... 所以此時你的工作是去複製這個問題，通常在回報文件裡面有一大堆不相干的步驟， 或者是步驟少的可憐。總之要靠經驗去複製這個問題，而且讓這個問題越簡單越好。 通常啦，我說通常。反覆操作才會出現的問題跟 Memory Leak有關，有機率發生的問題 通常是跟其他元件交互作用而產生的，例如 race condition。 但是也碰過很多環境相關的問題，例如說使用者註冊的區碼是JP的話會出發問題，用 台哥大的網路因為dns解析錯誤導致拿不到某個xml而定義爛掉，某個該死的使用者 在名稱當中放了一個該死精美的全形空白。。。。。。。。 總之有了簡單而容易重現的步驟之後，才能夠進入到下一個階段。通常在研究重製步驟 會讓你深刻知道，怎樣會發生問題而怎樣不會發生問題。藉此可以大幅縮小嫌疑犯的 範圍。經由反覆 a/b testing，加上前面文章提到的 debugging技巧，很快能夠抓到兇手 。 嗯，我碰過天殺的kernel panic 是因為 file system curruption，原因是 bootloader 載入到 memory 就是爛的，原因是因為 Flash 的 CLK 路徑太長導致訊號衰減，而造成 讀取錯誤。........天殺的。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.48.120 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1569955177.A.3C6.html