本文**：
在制定驗證計畫的具體過程中，我們會將技術部分和專案部分都考慮進來。從技術角度而言，我們需要考慮的有驗證的功能點、驗證的層次、測試用例、驗證方法和覆蓋率要求，從專案部分來看，我們也需要考慮使用的工具、人力安排、進度安排和風險評估。接下來，我們逐個分析技術部分和專案部分。
技術部分
驗證的功能
需要驗證的功能點主來自於功能描述文件，設計和驗證人員在閱讀文件的過程中，會將設計的功能、引數、效能從自然語言拆分轉化為乙個個可以單獨驗證的功能點，並且需要用定性定量的語言限定描述這些功能。
我們可以將功能點按照優先順序分為：
驗證的層次
結合驗證的功能點，需要清楚該功能點是否可以在較低的層次完成驗證。從驗證效率和激勵自由度來看，我們應該盡量在較低的層次驗證更多的功能點。在較高的層次，例如晶元級，應該側重於系統整合測試。
驗證方法
需要考慮採取何種驗證方法，動態**、形式驗證還是硬體加速？採取什麼樣的透明度，黑盒、白盒還是灰盒？採用直接測試還是隨機約束激勵？在之前的驗證方法篇中，我們對比了不同方法適用的場景。
測試用例
有了帶驗證的目標功能，選擇合適的層次和方法，在完成了驗證平台搭建以後，我們就需要考慮如何利用現有的驗證平台給出適當的激勵，檢查測試結果。
覆蓋率要求
覆蓋率是衡量激勵生成種類和設計功能點驗證的量化指標，無論通過何種驗證方法，我們都需要採用覆蓋率來確保給出了足夠多的想要的激勵型別，以及設計邊界和內部窮歷了可能的狀態。除了給出合法的激勵之外，也需要考慮給出一些錯誤的激勵，來測試設計的穩定性和糾錯能力。
專案部分
工具選擇
對於專案而言，需要通過驗證計畫中選擇的方法，來考慮選擇相應的工具，它們包括：
選擇了不同的驗證方法和工具，接下來就需要考慮安排有合適技能的驗證人員完成工作。
人力安排
在確定下來驗證方法以後，驗證經理就可以考慮投入的人力了。由於不同驗證方法存在顯著差別，除過考慮個人的實際經驗以外，也需要考慮他們是否熟悉該模組，知識和技術背景越貼合，越傾向於選擇這樣的驗證人員。一般在同乙個專案完整週期內，我們會考慮讓固定的人員跟蹤同乙個設計模組，從搭建環境開始，經歷模組級、子系統級和晶元系統級驗證過程，這樣對於專案的風險較低，人員的成長也更快。
進度安排
在安排人力的過程中，我們同時也將進度考慮了進來。一般而言，進度是從上向下傳達的，驗證經理事先會有乙個大致的時間表，通過簡單的計算：
來安排合適的人力投入到驗證中去。而往往陷入的境地是，人力不夠充分，或者時間不夠寬裕，面對這樣的困難，時間是沒有彈性的，更多地需要在人力角度上考慮如何恰當地安排人力，做好動態的人力分配，實現高效的資源配置。那麼對於驗證經理而言，進度是否是不可修改的，必須嚴格遵循呢？這樣的問題可能難以給出乙個是或者否的答案，但是如果可以在計畫中將設計的交付時間、驗證的驗收時間、不同模組的整合時間等等重要資訊拆分開來，做到更細緻的量化和評估，那麼專案執行中的風險就可以在早期發現，同時朝著按時交付的目標共同邁進。
風險評估
在專案執行中，無論是設計人員、驗證人員還是專案經理
，都會面臨諸多不確定的因素：
驗證的計畫篇之一 計畫的概述
本文 在選擇驗證方法和構建驗證環境之前，我們首先需要清楚驗證計畫是什麼。在展開設計之前，設計人員和驗證人員都會閱讀功能描述文件，以理解設計的各項功能為前提，來考慮如何驗證它。如果功能描述本身不清晰，則需要同系統人員溝通來修改功能描述文件 如果設計和驗證雙方人員對於某一項功能理解有不同的地方，也需要最...
專案管理計畫的內容
專案管理計畫要記錄計畫的假設以及方案選擇，要便於各干係人間的溝通，同時還要確定關鍵的管理審查的內容，範圍和時間，並為進度評測和專案控制 提供乙個基準。計畫應該具有一定的動態性和靈活性，隨著環境和專案本身的 變更而進行適當的調整。計畫應該能夠有利於專案經理管理專案團隊和評估專案 的進展狀況。整合專案資...
測試計畫的範圍 系統測試計畫主要包含的內容及作用
一 內容 測試計畫用來描述所要完成的測試，包括測試背景 測試目的 風險分析 所需資源 任務安排和進度 測試開始 掛起及結束的標準等。引言 目的 背景 範圍 定義 參考資料 測試內容 測試功能清單 測試規則 進入準則，暫停 退出準則 測試方法 測試手段 測試要點 測試工具 測試環境 硬體環境 軟體環境...