在芯片驗證中，搭建好testbench後，就必須開始着手創建testcases。testcase按功能可劃分爲三類：冒煙用例、隨機用例、定向用例。按開發時間順序，一般也是冒煙用例→隨機用例→定向用例。
- 冒煙用例(sanity testcase)
在環境搭建好之後，爲了迅速將RTL基本功能測試起來，可以考慮寫幾個簡單的testcases來作爲冒煙用例，比如總線驗證中，可以將基本通路掃描作爲的冒煙用例，在CPU驗證中，可以將幾個簡單指令拿來做冒煙用例。
冒煙用例的特點就是要快速測試基本功能，不要求大而全。而且在每次testbench和RTL有所改動時，可以用冒煙用例先調試起來，加速環境的穩定。冒煙用例像是偵察兵，提前探測敵情。 - 隨機用例(random testcase)
隨機用例一般是用在環境穩定後，開始大規模衝擊壓力和各種可能存在場景而開發的，此時就是要考慮大而全了。在寫隨機用例時，一定要注意：所有可變的特性值一定要在最大範圍內隨機，再加以覆蓋率收集，確保所有值都有覆蓋到。當然可以在某些常用值或組合上加大隨機權重，減少在很大驗證空間裏漫無目的隨機，浪費機時。
隨機用例的特點就是要全面，是覆蓋率的主要貢獻者，它就像是主要作戰部隊，用例大規模消除隱藏的bug。 - 定向用例(direct testcase)
定向用例顧名思義就是有針對性去測試一些場景，這些場景可能是設計要求覆蓋的，也可能是在覆蓋率中一些無法隨機到corner場景。
定向用例的特點就是要易於控制，精準打擊，用於完善覆蓋率和檢測一些邊界情況。
溫馨提示：
大家在寫testcase的時候一定要注意提前規劃好全局testcase風格，達到易擴展和易複用，不要一昧求快，想到啥就寫啥，這樣後期改動起來特別耗時間和精力，而且容易錯。
在易擴展和易複用有以下幾個小點供參考：
- 把一些可能會變化的值定義成宏，方便改變宏的值就達到全局替換，如總線位寬；
- 對一些可能常用的功能塊或配置流程，封裝起來，方便使用，代碼也更簡潔；
- 如果多個人共用一套驗證環境，可以自己從tc_base.sv擴展出子類tc_base_xxx.sv，方便把常用task/function或配置放在這裏，不和別人衝突；不過也可以在tc_base.sv裏採用`include file_name的方式自己維護一份file，不影響他人；
- UVM phase把驗證平臺執行過程分的很細，要提前想好在每個phase裏面需要做的事情，如系統時鐘復位處理、寄存器配置、sequence執行、end of checker檢查、用例執行報告等等；
- 對一些變量可能只有幾種值，且每種值都有特殊含義的，可以考慮用enum類型來定義，簡單易懂。