本文**：
在上一節我們提到如何快速有效地進行驗證收斂，即利用遞迴測試表來產生更多複雜場景和提高驗證的覆蓋率。在驗證收斂的過程中，每乙個人，無論你是驗證人員、設計人員還是系統人員，都不可避免地會遇到乙個問題，那就是檢測出了漏洞，應該怎麼辦？
由以上的例子我們可以總結出，發現了問題以後，進行跟蹤的基本依據是：
所以，我們可以將問題追蹤的型別分為以下幾類：
在對矽前問題進行分類以後，我們接下來需要將它們記錄到乙個合適的資料庫中，該資料庫不但需要記錄問題、還需要有分類、派發、查詢、追溯、報告的作用。晶元設計專案除了在執行過程中，會參考軟體專案的構建、分塊、依賴路徑、決策的方法，也在問題追蹤上借鑑了軟體開發的方式。軟體開發更早地使用標準化的問題追蹤工具來進行執行專案，伴隨著晶元開發的進度逐漸加快，一些商業或者免費的問題跟蹤工具也進入了晶元開發的視野。例如以下這些問題追蹤工具：
這些問題追蹤工具一般也都會具備如下的功能：
分類：歸屬於哪乙個專案、哪乙個環節（系統、設計、驗證還是其它）、哪乙個模組、問題嚴重性（致命、重要、中級、完善）。
派發：在跟蹤系統中，問題一旦提交，即它的生命週期開始，接下來由管理層指定問題回顧和修復的人員，再轉而由下一位問題持有者完成他所需要做的環節，並且繼續指定問題的下一位持有者，這部分我們會在後面的問題跟蹤流程中詳細介紹。
查詢：當遇到漏洞之後，除了可以同漏洞相關人員溝通之外，在確定提交問題之前，我們還需要利用問題追蹤工具資料庫提供的查詢功能快速判斷，該問題以前是否發生過、有無解決方法；另外一方面，我們也可以很方便地利用問題獨一無二的id編碼在工具搜尋欄中快速調出該問題的背景和進度。
追溯：問題從被提出到被派發、解決、驗證和最終的關閉，在乙個專案中可能走完它的生命週期，而不排除它可能會在下乙個專案中「復活」，可能造成問題復活的因素有許多譬如問題重新發現、原來解決方案不再滿足、新專案繼承上乙個專案時一些問題修復沒有被整合進來仍然需要再次修復等等。所以，問題追溯的好處就可以看到同乙個「頑固」的問題是如何在不同的專案之間（尤其是多個並行專案中）產生的。
問題追蹤流程
在了解了問題追蹤工具一般具備功能之後，我們還需要了解在日常工作中，如果發現了乙個問題，我們應該如何使用工具來提交、跟蹤、修改、驗證這個問題的狀態，還有狀態之間的跳轉通常是在什麼情況下發生的。上面這幅問題追蹤狀態流程圖是針對矽前晶元開發流程的，實際上的問題跟蹤週期要比這個狀態更長，還包括了矽後測試週期。在這裡，我們先集中在矽前晶元開發階段，來依次解釋各個狀態的表徵以及狀態之間的跳轉條件。
新的問題：當在專案執行中，發現了乙個新的問題，而且這個問題的影響滿足之前問題提交的基本依據時，我們就需要在問題追蹤工具中提交這個問題，填寫相應的內容，這對應著步驟1。接下來，提交者會將問題派發給需要解決問題的所有者。如果所有者發現該問題不屬於他的模組，那麼他應該再次將該問題派發給真正的問題所有者，即步驟2。問題所有者會進行研究，確定是否屬於系統結構、設計或者驗證問題，然後他可能會進行
開始：當問題開始進入修復過程時，問題所有者在經過研究之後，做出了修正，則他會將問題修改了解決狀態，即步驟8。在這一狀態中，問題所有者仍然有可能會將狀態修改為重複或者延後的狀態，即步驟9和步驟10。
解決：當問題修復以後，問題所有者會將該問題再派發給驗證人員，例如設計人員會派發給驗證人員要求測試漏洞修復是否完成，系統人員派發給設計人員要求檢查功能描述是否與設計相符且漏洞得到修復等，這一過程即是上圖的步驟11。
驗證：當問題得到修復和驗證之後，問題會再次派發給當初的問題提交者或者管理人員，由他們將狀態修改為關閉狀態，即步驟12。
關閉：在問題關閉之後，問題的提交者如果在回顧問題、或者再次遇到此問題發現沒有得到完全解決時，他可以重啟問題，即步驟13。
重啟：問題得到重啟後，問題所有者又需要再次進入問題，檢查新的問題場景，經過研究後
上述的各個狀態以及狀態之間的跳轉，符合一般晶元開發中的問題追蹤流程，從該流程的細節我們可以發現，問題追蹤管理的特點是：
至此，我們將問題追蹤需求、分類、工具和流程介紹完畢。有了團隊間協作的工作，那接下來我們將進入「人」的環節，來看一看如何在長、中、短期建設驗證團隊，使團隊成為最寶貴的公司財富。
滲透測試之漏洞驗證篇
msf 是乙個滲透測試利用框架，在這個框架中整合了很多漏洞檢測和利用的指令碼工具，可以讓我們直接利用，省去了在網路中查詢指令碼的時間。msf 資料庫為 postgresql，在使用時要保證其是開啟的 確定使用的指令碼工具，可以通過search來搜尋 使用對應的指令碼，use 搜尋序號 或use 指令...
驗證的管理篇之六 驗證師的培養
本文 我們在之前的 晶元驗證全視篇 中針對驗證師的 自我修養 提出了包括技術和專案在內的要素分析，從 一名驗證師的自我修養 一文可以發現驗證師需要得到各方面的鍛鍊。在這些因素背後，通過日常的觀察，我們可以發現優秀驗證師之間的共同能力。這些能力不完全是與生俱來，如果你願意下功夫，也可以在下面總結出的出...
驗證的管理篇之七 驗證的專業化
本文 人們對乙個行業所產生的偏見多半是由於沒有親身體驗過，而在晶元領域驗證所接收到的偏見也絲毫不少於其它行業所面臨的窘境。在每次新開學與我的學生們交流的時候，他們對於驗證的理解仍然停留在當初學習vhdl或者verilog所學到的通過乙個簡易包裝的測試盒子，固定的激勵源和細緻的時序激勵調整來測試設計。...