這是乙個典型的bug跟蹤過程，設計者篤信只有完整的檢查才會保證修改乙個bug的時候不會產生另外乙個bug。但是現實好像總是跟他作對，bug返回率一直居高不下。於是設計者修訂了流程，增加了幾個步驟。他希望問題能夠通過複查被發現出來。但是增加了流程以後bug返回率反而提高了。
「這是人的問題！」流程設計者認為。
這不是人的問題，這是流程的問題。我說。
另外乙個團隊，並沒有採用這樣的模型，bug返回率卻很低，而且修改的時間明顯的要短於前乙個團隊。他們採用的是這個流程：
這個流程和前乙個流程的最大區別在於測試是自動進行的，而且由開發團隊自己進行管理。這是開發團隊的內部流程，由測試團隊提出的bug，將會被首先整理成一組測試用例來進行復現，自動測試中的**可以自由修改，所以，問題定位要快的多，並且修改了**以後，可以馬上對測試用例進行回歸測試。很快就可以知道是否修改完畢。並且，對於有影響的模組，由於已經有了大量的測試用例，可以全部回歸，從而避免了因為影響性分析不充分而造成的bug返回，所以大大的降低了bug的返回率。
我們為一家大型電信公司做諮詢的時候，他們採用了比圖1更加複雜的流程，還有上傳修改**和確認的過程，但是效果沒有得到改善，而且所耗時間更長。在採用了我們幫助其完善的新流程以後，bug修改時間和效果上都得到了大大的改善。
轉
注：bug返回率是指，開發團隊將修改後的**提交給測試團隊以後，測試團隊驗證bug修改狀況，對於沒有修改正確的bug返回到開發團隊的情況稱作返回。返回個數佔修改個數的比例稱作bug返回率。
跟蹤分析Linux核心的啟動過程
在linux作業系統中，系統的啟動都是從start kernel 這個函式開始的。start kernel 是核心的彙編與 語言的交接點，在該函式以前，核心的 都是用彙編寫的，完成一些最基本的初始化與環境設定工作，比如核心 載入記憶體並解壓縮 現在的核心一般都經過壓縮 cpu 的最基本初始化，為c ...
跟蹤分析Linux核心的啟動過程
說明 在實驗樓裡做該實驗時，發現實驗樓環境老卡死，折騰幾個小時都如此，根本沒有辦法完成作業。因此此處只能提供一張截圖。後面的內容都是根據老師的課程整理出來的。開啟shell 使用gdb跟蹤除錯核心 gdb file linux 3.18.6 vmlinux 說明 在gdb介面中targe remot...
跟蹤分析Linux核心的啟動過程
1.除錯gdb 1 執行qemu 2 執行gdb並鏈結remote 3 設定斷點break start kernel，break rest init 2.分析start kernel 在斷點處停止 分析start kernel asmlinkage visible void init start k...