本文**：
在我們平常的驗證過程中，有這樣的一種問題存在:乙個測試激勵根本沒有測試到我們期望的測試點，但是在**的過程中也沒有出現嚴重的錯誤，從頭到尾**正常的結束，那麼我們一般會認為它**通過了，在我們收集覆蓋率之前我們一般不會發現它其實根本什麼都沒有做，只是假裝**通過，今天我們介紹一種克服這種問題的辦法，利用sv的斷言api介面鏈結上uvm的測試平台來動態監測我們測試激勵的實際**情況，如果沒有打到測試點，就結束**，讓這個測試激勵不通過，這樣不僅可以減少**時間的浪費，還可以減少不必要的覆蓋點的增加
一般我們都是利用sv斷言來檢測設計**的執行質量，但在這篇文章中我們來介紹怎麼利用sv斷言檢測測試**的質量，我們會通過乙個例子來介紹怎麼去寫監測測試激勵的**並且把它和我們的uvm測試平台鏈結起來，我們利用斷言來檢測測試**質量的目的是為了檢驗測試激勵**過程中有沒有測試到我們期望的那些點，這和我們的斷言覆蓋率分析報告很像，只不過我們針對的是單個的測試激勵，當然利用sv斷言來進行測試激勵的檢測技術不僅可以讓我們挑出那些無作為的測試激勵，還可以根據sv斷言的反饋情況來調整我們測試激勵的輸入，以達到比較高的覆蓋率
下面我們具體看看它怎麼實現，在這個例子中，我們假設要測試的設計模組是乙個仲裁模組，它有三個輸入，三個輸出如下圖:
為了幫助驗證這個模組，可能驗證工程師已經已經有針對性的寫了以下斷言，如下圖:
這些斷言的用處在於如果仲裁模組發生了不合法的行為，它就會讓我們的測試激勵**失敗，但它卻並不能指出測試激勵是否正確的測試了仲裁模組，也就是說我們對於仲裁模組的使用合理不合理，如果你的測試激勵的測試點是同時拉高三個req訊號，那麼上面的斷言並不能告訴你，你的測試激勵在**過程中到底有沒有測試到這一點，為了驗證有沒有測試到你還需要加上下面的斷言:
然後根據斷言覆蓋率報告，你可以確定同時拉高三個req訊號的情況有沒有被測試到，但通常對於覆蓋率報告的分析都是針對整個regression的，所以你只能確定這種情況沒有沒測試到，卻不知道是那個測試激勵覆蓋到的，這樣我們就有必要針對我們的測試激勵進行斷言確認，但鑑於不同的測試激勵需要的斷言確認情況不一樣，所以我們需要對斷言加一些可以自由配置的選項，就像下圖一樣，自由決定斷言的開關:
斷言的應用場景和應用方式確定了，下來我們該**具體的實現細節了，我們將主要利用sv斷言api的兩個特性來實現斷言的監視器:一、可以通過和設計模組互動找到特定的斷言，二、可以把一些子執行緒和一些斷言繫結，整個斷言在我們測試激勵**過程中的應用如下圖所示:
在測試激勵**開始之前，sv測試平台會根據命令列引數去解析驗證人員需要新增的斷言，並把它和合適的c dpi執行緒繫結，具體實現**如下圖:
在每個測試激勵**結束時，sv測試平台會呼叫end-of-test執行緒來檢查有沒有其他的錯誤，**如下圖:
另外，我們的斷言監視器系統除了可以應用在這些直接測試激勵上，對於隨機測試激勵也可以發揮它的作用，來提供反饋讓我們的隨機測試更好的完成測試任務，下面是乙個應用例子:
隨著積體電路的設計複雜度越來越高，驗證的時間週期會變得越來越緊，可以動態的去檢測每乙個測試激勵的實際**情況對於我們的驗證程序有著很大的影響，它可以讓我們最大程度的利用**資源，減少不必要的時間浪費，以很快的速度接近覆蓋率收斂的目標.
TestNG在介面測試中的應用
testng在介面測試中的應用 一 介面測試 介面測試是測試系統元件間介面的一種測試，介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。如今的系統架構紛繁複雜，系統間的介面龐雜繁多，傳統的功能測試已...
Windows PDH庫在效能測試中的應用
相信大家都已經使用過了windows自帶的效能測試工具perfmon。perfmon能夠實時的抓取當前環境的硬體資訊,並直觀的展示出來。但是當你想在程式設計中利用這些資料，perfmon就不是那麼方便了。那麼windows是否提供了合適的api來完成這些功能呢？答案是肯定的，這就是performan...
Python在HTTP介面測試中的應用
http介面例子 http ip port inte ce.php?uname aaa 介面功能 根據uname引數值來返回對應的使用者名稱的基本資訊 1.用python封裝被測試 介面,對於http接 們通常會採用 get和post 2種呼叫方式去訪問,所以必須把這2種方式都封裝進去 coding...