本節書摘來自華章社群《uvm實戰》一書中的第2章，第2.5節建造測試用例，作者 張 強，更多章節内容可以通路雲栖社群“華章社群”公衆号檢視
2.5 建造測試用例
2.5.1 加入base_test
uvm使用的是一種樹形結構，在本書的例子中，最初這棵樹的樹根是my_driver，後來由于要放置其他component，樹根變成了my_env。但是在一個實際應用的uvm驗證平台中，my_env并不是樹根，通常來說，樹根是一個基于uvm_test派生的類。本節先講述base_test，真正的測試用例都是基于base_test派生的一個類。
代碼清單 2-74
base_test派生自uvm_test，使用uvm_component_utils宏來注冊到factory中。在build_phase中執行個體化my_env，并設定sequencer的default_sequence。需要注意的是，這裡設定了default_sequence，其他地方就不需要再設定了。
除了執行個體化env外，base_test中做的事情在不同的公司各不相同。上面的代碼中出現了report_phase，在report_phase中根據uvm_error的數量來列印不同的資訊。一些日志分析工具可以根據列印的資訊來判斷dut是否通過了某個測試用例的檢查。report_phase也是uvm内建的一個phase，它在main_phase結束之後執行。
除了上述操作外，還通常在base_test中做如下事情：第一，設定整個驗證平台的逾時退出時間；第二，通過config_db設定驗證平台中某些參數的值。這些根據不同的驗證平台及不同的公司而不同，沒有統一的答案。
在把my_env放入base_test中之後，uvm樹的層次結構變為如圖2-11所示的形式。
top_tb中run_test的參數從my_env變成了base_test，并且config_db中設定virtual interface的路徑參數要做如下改變：
代碼清單 2-75
2.5.2 uvm中測試用例的啟動
要測試一個dut是否按照預期工作，需要對其施加不同的激勵，這些激勵被稱為測試向量或pattern。一種激勵作為一個測試用例，不同的激勵就是不同的測試用例。測試用例的數量是衡量驗證人員工作成果的最直接目标。
伴随着驗證的進行，測試用例的數量一直在增加，在增加的過程中，很重要的一點是保證後加的測試用例不影響已經建好的測試用例。在前面所有的例子中，通過設定default_sequence的形式啟動my_sequence。假如現在有另外一個my_sequence2，如何在不影響my_sequence的前提下将其啟動呢？最理想的辦法是在指令行中指定參數來啟動不同的測試用例。
無論是在my_env中設定default_sequence，還是在base_test中或者top_tb中設定，都必須修改相關的設定代碼才能啟動my_sequence2，這與預期相去甚遠。為了解決這個問題，先來看兩個不同的測試用例。my_case0的定義如下：
代碼清單 2-76
當my_case0運作的時候需要修改代碼，重新編譯後才能運作；當my_case1運作時也需如此，這相當不友善。事實上，uvm提供對不加參數的run_test的支援：
代碼清單 2-80
整個啟動及執行的流程如圖2-12所示。
