本文**：
在選擇驗證方法和構建驗證環境之前，我們首先需要清楚驗證計畫是什麼。在展開設計之前，設計人員和驗證人員都會閱讀功能描述文件，以理解設計的各項功能為前提，來考慮如何驗證它。如果功能描述本身不清晰，則需要同系統人員溝通來修改功能描述文件；如果設計和驗證雙方人員對於某一項功能理解有不同的地方，也需要最後同系統人員的解釋保持統一。
那麼一旦完成了驗證計畫書，還需要對其進行修改嗎？答案是需要。因為在實際專案執行過程中，功能描述文件和設計會不斷更新，直到晶元到流片前都有可能在一直進行，那麼驗證人員就需要做好相應的驗證計畫更新。所以，驗證計畫的生命在設計被構建之前就誕生了，伴隨著設計的週期，直到流片。
伴隨著驗證計畫的建立，計畫流程可以分為若干個步驟，它們包括：
建立驗證計畫
選擇驗證方法
人力資源調配
構建驗證平台和環境元件
開發測試用例
建立乙份驗證計畫是首要的任務，通過收集下列材料可以更好地組織出有價值的計畫：
通常上面的這些資料可以從硬體功能描述和系統文件中找到，同時，也可以從矽後測試、韌體開發人員那裡得到設計的實際使用配置情況。
通過合理的驗證計畫，可以為晶元開發帶來很多好處：
從更寬泛的意義上來看，乙份驗證計畫幾乎可以囊括所以跟驗證相關的東西，這其中不單單包括要驗證的設計功能，還包括驗證方法、人力安排、進度評估等等。由於驗證計畫的生命期很長，在實際環境中，有很多因素會不斷影響計畫的更新，這些可能的因素包括：
驗證的計畫篇之二 計畫的內容
本文 在制定驗證計畫的具體過程中，我們會將技術部分和專案部分都考慮進來。從技術角度而言，我們需要考慮的有驗證的功能點 驗證的層次 測試用例 驗證方法和覆蓋率要求，從專案部分來看，我們也需要考慮使用的工具 人力安排 進度安排和風險評估。接下來，我們逐個分析技術部分和專案部分。技術部分 驗證的功能 需要...
我的讀書計畫 C 篇
use a book as a bee does flowers 哈哈，這是我的部落格的副標題，嗯，是bugzilla上的一句話。其實感覺自己還是比較懶，自律性不夠好，平時浪費了不少時間。為了能夠對得起這句話，俺決定給自己制定乙個近期的讀書計畫，首先讀一些以前沒讀過的書，拓展知識面。首先從c 開始吧...
我的測試文件之一 測試計畫的編寫
測試生涯兩年了，經歷過幾個專案，負責測試過n個公升級包測試發布，經歷過兩個人測試一款公司主要產品的測試，負責過小產品的測試.小公司的好處之一就是接觸多，工作廣，磨練人啊。整理下思路吧，算是乙個思想的沉澱，也給我的兩年測試生涯的乙個總結。先寫寫測試計畫吧 1.簡介 1.1 編寫目的 1.2 編寫背景 ...