Manual——Test （翻譯1）

時間 2019-11-15

標籤 manual test 翻譯简体版

原文原文鏈接

LTE Manual ——Logging（翻譯）

（本文爲我的學習筆記，若有不當的地方，歡迎指正！）

1.17.3 Testing framework（測試框架）

ns-3 包含一個仿真核心引擎、一系列模塊、例子程序和測試。隨着時間的推移，一些新的貢獻者貢獻出模型、測試和例子。 Python 測試程序 test.py 做爲測試執行管理者；test.py 運行測試代碼和例子來尋找 regressions，輸出結果有不少種形式，管理代碼覆蓋分析工具。此外，咱們對 buildslaves 進行分層，buildslaves 是自動化建立的 robots，經過在不一樣的系統中和使用不一樣的配置選項運行測試框架，buildslaves 能執行健壯性測試。

（1）Buildslaves

ns-3 測試的最高級別是 buildslaves (build robots)。若是你不熟悉該系統，能夠參考 https://ns-buildmaster.ee.washington.edu:8010/——jenkins 是一個開源的自動化系統，容許 ns-3 平常重建和測試。經過在不少不一樣系統上運行 buildbots（一種自動化構建工具），咱們能夠確保 ns-3 在它支持的全部系統上正確地構建和執行。

用戶（和開發者）一般不會與 buildslave 系統打交道，除了讀取它的關於測試結果的消息。若是在一個自動化構建和測試的工做中檢測到 FAIL， buildbot 會發送郵件給 ns-commitsmailing 列表。該郵件看起來相似於：

In the full details URL shown in the email, one can find links to the detailed test output。（在郵件顯示的詳細 URL 信息中，用戶能夠找到詳細測試輸出的連接。）

若是沒有錯誤的話，buildslave 系統會默默執行它的工做，而且系統天天會進行構建和測試循環來驗證一切是否 ok。

（2）Test.py

buildbots 使用 Python 程序， test.py——負責運行全部的測試，並收集結果報告爲可讀的形式。該程序也能夠供用戶和開發人員使用。

test.py 在容許用戶指定運行的測試數目和種類方面很是靈活，同時生成輸出的數量和類型。

在運行 test.py 前，確保已經編譯了 ns3 的例子和測試：

$ ./waf configure --enable-examples --enable-tests
$ ./waf build

默認狀況下， test.py 將運行全部可用的測試，並以一種很是簡明的形式報告狀態。運行命令：

$ ./test.py

上述代碼會致使一系列的 PASS、 FAIL、 CRASH 或 SKIP 指示，緊隨其後的是測試種類和顯示名稱。

Waf: Entering directory '/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
Waf: Leaving directory '/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
'build' finished successfully (0.939s)
FAIL: TestSuite propagation-loss-model
PASS: TestSuite object-name-service
PASS: TestSuite pcap-file-object
PASS: TestSuite ns3-tcp-cwnd
...
PASS: TestSuite ns3-tcp-interoperability
PASS: Example csma-broadcast
PASS: Example csma-multicast

這種方式由用戶和開發者使用，用戶感興趣的是肯定其分佈是否正常工做，開發者感興趣的是肯定它們作出的改變是否形成了 regression。

有不少種可用的選項來控制 test.py 的行爲。若是你運行 test.py --help ，你會看到以下結果：

Usage: test.py [options]

Options:
  -h, --help            show this help message and exit
  -b BUILDPATH, --buildpath=BUILDPATH
                        specify the path where ns-3 was built (defaults to the
                        build directory for the current variant)
  -c KIND, --constrain=KIND
                        constrain the test-runner by kind of test
  -e EXAMPLE, --example=EXAMPLE
                        specify a single example to run (no relative path is
                        needed)
  -d, --duration        print the duration of each test suite and example
  -e EXAMPLE, --example=EXAMPLE
                        specify a single example to run (no relative path is
                        needed)
  -u, --update-data     If examples use reference data files, get them to re-
                        generate them
  -f FULLNESS, --fullness=FULLNESS
                        choose the duration of tests to run: QUICK, EXTENSIVE,
                        or TAKES_FOREVER, where EXTENSIVE includes QUICK and
                        TAKES_FOREVER includes QUICK and EXTENSIVE (only QUICK
                        tests are run by default)
  -g, --grind           run the test suites and examples using valgrind
  -k, --kinds           print the kinds of tests available
  -l, --list            print the list of known tests
  -m, --multiple        report multiple failures from test suites and test
                        cases
  -n, --nowaf           do not run waf before starting testing
  -p PYEXAMPLE, --pyexample=PYEXAMPLE
                        specify a single python example to run (with relative
                        path)
  -r, --retain          retain all temporary files (which are normally
                        deleted)
  -s TEST-SUITE, --suite=TEST-SUITE
                        specify a single test suite to run
  -t TEXT-FILE, --text=TEXT-FILE
                        write detailed test results into TEXT-FILE.txt
  -v, --verbose         print progress and informational messages
  -w HTML-FILE, --web=HTML-FILE, --html=HTML-FILE
                        write detailed test results into HTML-FILE.html
  -x XML-FILE, --xml=XML-FILE
                        write detailed test results into XML-FILE.xml

若是指定可選的輸出方式，能夠生成詳細的測試和狀態描述。可選的樣式有 text 和 HTML 。buildbots 選擇 HTML 方式生成 HTML 測試報告用於 nightly builds ：html

$ ./test.py --html=nightly.html

這種狀況下，測試完成時會建立一個名爲‘’nightly.html’’ 的 HTML 文件，對細節感興趣的用戶能夠選擇如下一種可讀的格式：

$ ./test.py --text=results.txt

在上述例子中，test suite 檢測到 ns-3 無線設備傳播損耗模型 FAIL。默認不會提供進一步的信息。

爲了進一步探尋 FAIL， test.py 容許指定單個 test suite 。運行下列命令。

$ ./test.py --suite=propagation-loss-model

或者等價於python

$ ./test.py -s propagation-loss-model

結果是單個 test suite 正在運行。linux

FAIL: TestSuite propagation-loss-model

爲了找到有關失敗的詳細信息，咱們必須指按期望輸出的類型。例如，大多數人可能對文本文件感興趣：

$ ./test.py --suite=propagation-loss-model --text=results.txt

這會致使運行單個test suite ，而且測試狀態會寫入到文件「results.txt」。

你會發現一些相似下面的輸出：

FAIL: Test Suite ''propagation-loss-model'' (real 0.02 user 0.01 system 0.00)
PASS: Test Case "Check ... Friis ... model ..." (real 0.01 user 0.00 system 0.00)
FAIL: Test Case "Check ... Log Distance ... model" (real 0.01 user 0.01 system 0.00)
  Details:
    Message:   Got unexpected SNR value
    Condition: [long description of what actually failed]
    Actual:    176.395
    Limit:     176.407 +- 0.0005
    File:      ../src/test/ns3wifi/propagation-loss-models-test-suite.cc
    Line:      360

注意 Test Suite 由兩個 Test Cases 組成。第一個 test case 檢查 Friis 傳播損耗模型並經過。第二個 test case 檢查 Log Distance propagation model 失敗。這種狀況下，發現 SNR 爲 176.395 ，測試指望的值爲 176.407，到小數點後三位。實現測試失敗的文件和觸發失敗的代碼會被列舉出來。

若是你須要，你能夠參照上述使用 --html 寫一個HTML文件。

一般狀況下，用戶在下載完 ns-3 後，會至少運行一次全部的測試來確保仿真環境正確編譯，而且會根據 test suites 產生正確的結果。開發者一般會在修改以前和以後確保沒有由於改動而帶來 regression 。這種狀況下，開發者可能不想運行全部的測試，而只想運行一部分。例如，開發者在修改 repository 的同時可能只想週期性運行 unit tests 。這種狀況下， test.py 能夠告知約束測試（運行一個特定的類的測試）類型。下面命令的做用是隻有 unit tests 運行：

$ ./test.py --constrain=unit

類似地，下列命令會致使只有 example smoke tests 運行：web

$ ./test.py --constrain=unit

爲了快速看到合法的約束列表，你能夠要求它們列舉出來。下使用列代碼：redis

$ ./test.py --kinds

會致使如下列表列舉出來：

Waf: Entering directory '/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
Waf: Leaving directory '/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
'build' finished successfully (0.939s)Waf: Entering directory '/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
bvt:         Build Verification Tests (to see if build completed successfully)
core:        Run all TestSuite-based tests (exclude examples)
example:     Examples (to see if example programs run successfully)
performance: Performance Tests (check to see if the system is as fast as expected)
system:      System Tests (spans modules to check integration of modules)
unit:        Unit Tests (within modules to check basic functionality)

任何這些類型的測試均可以使用 --constraint 選項提供約束。

爲了快速看到全部可用的 test suites ，你能夠請求它們列舉出來。下面代碼

$ ./test.py --list

會致使 test suite 列表顯示出來，類似地，

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
'build' finished successfully (0.939s)

Test Type    Test Name
---------    ---------
performance  many-uniform-random-variables-one-get-value-call
performance  one-uniform-random-variable-many-get-value-calls
performance  type-id-perf
system       buildings-pathloss-test
system       buildings-shadowing-test
system       devices-mesh-dot11s-regression
system       devices-mesh-flame-regression
system       epc-gtpu
...
unit         wimax-phy-layer
unit         wimax-service-flow
unit         wimax-ss-mac-layer
unit         wimax-tlv
example      adhoc-aloha-ideal-phy
example      adhoc-aloha-ideal-phy-matrix-propagation-loss-model
example      adhoc-aloha-ideal-phy-with-microwave-oven
example      aodv
...

任何這些列舉的 suites 均可以使用 --suite 選項來選擇性運行，如前所述，Examples 的處理方式不一樣。

與 test suites 類似，可使用 --example 選項單獨運行 C++ example 。注意，並不須要包含example 的相對路徑， C++ examples 的可執行文件編譯並無擴展。此外， example 必須註冊爲測試框架的 example ；只建立一個example 並經過 test.py 來運行是不夠的；它必須被添加到相對 examples-to-run.py 文件，下面將解釋。在命令行敲入

$ ./test.py --example=udp-echo

會致使單個 example 運行。

PASS: Example examples/udp/udp-echo

你能夠指定路徑，其中 ns-3 經過使用 --buildpath 選項編譯。

$ ./test.py --buildpath=/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build/debug --example=wifi-simple-adhoc

你可使用 --pyexample 選項來運行一個 Python example 程序。注意必須添加 example的相對路徑， Python examples 確實須要擴展。鍵入

$ ./test.py --pyexample=examples/tutorial/first.py

會致使單個 example 運行，shell

PASS: Example examples/tutorial/first.py

由於 Python examples 沒有編譯，你並不須要指定 ns-3 編譯運行它們的路徑。

一般狀況下，當example 程序執行時，它們會寫入大量的 trace 文件數據。它們一般會保存到分配的根路徑（例如， /home/user/ns-3-dev）。當 test.py 運行一個example 時，它一般是徹底不關心 trace 文件。它只想要肯定 example 是否能夠編譯且運行沒有錯誤。既然如此， trace 文件會被寫進一個 /tmp/unchecked-traces 路徑。若是你運行上述 example，你應該可以找到相關的 udp-echo.tr 和 udp-echo-n-1.pcap 文件。

可用的 examples 列表由分配的 ‘’examples’’ 路徑的內容定義。若是你使用 --example 選項選擇一個 example 執行， test.py 將不會作任未嘗試來判斷 example 是否已經配置，它只是嘗試運行它並上報嘗試的結果。

當 test.py 運行時，默認狀況下，它會首先確認系統是否已經徹底編譯。這能夠經過選擇 --nowaf 選項來打破。

$ ./test.py --list --nowaf

將會致使顯示當前已經編譯的 test suites ，相似於：app

propagation-loss-model
ns3-tcp-cwnd
ns3-tcp-interoperability
pcap-file
object-name-service
random-variable-stream-generators

注意沒有 Waf 編譯消息。

test.py 也支持在 valgrind 條件下運行 test suites 和 examples 。Valgrind 是一種靈活的調試和分析 Linux 可執行文件的程序。默認狀況下， valgrind 運行一種叫 memcheck 的工具，它執行一系列的 memory- checking 功能，包括檢測訪問 uninitialised 內存，分配內存（double frees, access after free, etc.）的濫用和檢測內存泄漏等。這能夠經過使用 --grind 選項來選擇。

$ ./test.py --grind

當它運行時，test.py 和它間接運行的程序，會生成大量的臨時文件。一般狀況下，這些文件的內容並不有趣，然而，在某些狀況下也頗有用（用於調試目的），能夠查看這些文件。test.py 會提供一個 --retain 選項，用於在運行結束後保存這些臨時文件。文件保存在一個路徑名爲 testpy-output 下的子目錄，根據當前世界統一時間（Coordinated Universal Time ，也稱格林威治時間）命名。

$ ./test.py --retain

最後， test.py 會提供一個 --verbose 選項，會打印大量的過程信息。除非存在錯誤，不然並不指望它會很是有用。這種狀況下，你能夠經過運行 test suites 和 examples 來得到上報的標準輸出和標準錯誤。按照下列方式選擇 verbose：

$ ./test.py --verbose

全部這些選項均可以混合搭配。例如，在 valgrind 條件下運行全部的 ns-3 核心 test suites ，按照 verbose 方式，與此同時生成一個 HTML 輸出文件，能夠按照以下方式執行：

$ ./test.py --verbose --grind --constrain=core --html=results.html

（3）TestTaxonomy

正如前面所述，測試被分組爲廣義的分類來容許用戶選擇性地運行測試，處理不一樣種類的測試。

Build Verification Tests
Unit Tests
System Tests
Examples
Performance Tests

而且，每種測試又進一步根據指望運行的時間劃分。測試分類爲：

QUICK
EXTENSIVE
TAKES_FOREVER

注意指定的 EXTENSIVE fullness 也會按照 QUICK 類別來運行測試。指定 TAKES_FOREVER 將按照 EXTENSIVE 和 QUICK 類別來運行例子。默認狀況下，只運行 QUICK 測試。

做爲經驗法則，運行測試必須確保 ns-3 一致性爲 QUICK （例如，花幾秒時間）。 EXTENSIVE 是能夠跳過可是很好作的測試；一般測試須要幾分鐘。TAKES_FOREVER 花的測試時間較長，順序爲幾分鐘。分類的主要目標是可以在合理的時間內運行 buildbots i，而且當須要時可以執行更多的 extensive 測試。

（3a） BuildVerificationTests（BVT）

這些爲相對簡單的測試，以分佈式的方式創建，用於確保 build 起至關大的做用。咱們當前的測試單元在它們測試的代碼的源文件中，而且構建在 ns-3 模塊中；所以適合 BVTs 的描述。BVTs 位於相同的源碼（構建在 ns-3代碼中）中。咱們當前的測試例子就屬於這種測試。

（3b）Unit Tests（單元測試）

Unit tests 是更加複雜的測試—— go into detail to make sure that a piece of code works as advertised in isolation。這種測試編譯進一個ns-3 模塊真的是沒有什麼理由。例如，事實證實，用於對象名服務的 unit tests 的大小與對象名服務代碼自己相同。 Unit tests 負責檢查尚未編譯進 ns-3 代碼的單一功能，可是路徑和測試代碼的路徑相同。這些測試能夠檢查一個模塊中多個實現文件的整合。文件 src/core/test/names-test-suite.cc 是這種測試的一個例子。文件 src/network/test/pcap-file-test-suite.cc 是另外一個使用已知且好的 pcap 文件做爲測試向量文件的例子，該文件存儲在本地 src/network 路徑下。

（3c）System Tests（系統測試）

系統測試的定義爲在系統中涉及不止一個模塊的測試。在咱們當前的迴歸框架中，有不少這種測試在運行，但它們一般是超載的例子。咱們提供了一個新的地方放置這種測試，路徑爲 src/test。文件 src/test/ns3tcp/ns3-interop-test-suite.cc 是這種測試的一個例子。它使用 NSC TCP 來測試 ns-3 TCP 實現。這種測試須要的測試向量一般會有，而且它們存儲在測試所在的路徑下。例如， ns3tcp-interop-response-vectors.pcap 是一個由不少 TCP 頭部組成的文件，TCP 頭部用做測試下對 NSC TCP（用做一個「known good 」實現）產生的刺激的預期 ns-3 TCP 響應。

（3d）Examples框架

examples 由框架測試來確保它們編譯了並將運行。沒有檢查，且當前的 pcap 文件只是寫入到 /tmp 被丟棄。若是 examples 運行（沒有crash ），它們會經過該 smoke test 。

（3e）Performance Tests

Performance tests 是訓練系統特定部分和肯定測試是否在合理時間內完成的測試。

（4）Running Tests（運行測試）

測試一般使用高級 test.py 程序來運行。爲了得到一系列可用的命令行選項，運行 test.py --help。

測試程序 test.py 將同時運行 tests 和那些添加到列表中檢查的 examples 。測試和例子的差異以下。Tests 一般會檢查特定的仿真輸出或事件是否符合指望的行爲。相反，examples 的輸出不用檢查，而且 test 程序只檢查 example 程序的退出狀態來確保它是否運行出錯。

簡單地說，爲了運行全部的 tests，首先必須在配置階段配置測試和（可選的）examples（若是要須要檢查 examples ）。

$ ./waf --configure --enable-examples --enable-tests

而後，編譯 ns-3 ，在編譯完成後，運行 test.py 。 test.py -h 會顯示一系列修改 test.py 的行爲的配置選項。

對於 C++ tests 和 examples ，程序 test.py 產生一種較低級的 C++ 程序來實際運行測試，稱爲 test-runner 。正以下面討論的，該 test-runner 是調試測試的有用方法。

（5）Debugging Tests

測試程序的測試最好是運行在低級的 test-runner 程序中。 test-runner 是一座從通常代碼過渡到 ns-3 代碼的橋樑。它是由 C++ 編寫，在 ns-3 代碼中使用自動測試過程發現和容許執行全部版本的測試。

test.py 不適合調試的主要緣由是，當運行 test.py 時，不容許使用 NS_LOG 環境變量開啓日誌功能。該限制並不適用於 test-runner 可執行文件。所以，若是你想看到你的測試有日誌輸出，你必須直接使用 test-runner 。

爲了執行 test-runner，你能夠像執行其餘 ns-3 可執行文件同樣執行它——使用 waf 。獲取可用選項的列表，鍵入：

$ ./waf --run "test-runner --help"

你會看到相似下面的輸出：dom

Usage: /home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build/utils/ns3-dev-test-runner-debug [OPTIONS]

Options:
--help                 : print these options
--print-test-name-list : print the list of names of tests available
--list                 : an alias for --print-test-name-list
--print-test-types     : print the type of tests along with their names
--print-test-type-list : print the list of types of tests available
--print-temp-dir       : print name of temporary directory before running
                         the tests
--test-type=TYPE       : process only tests of type TYPE
--test-name=NAME       : process only test whose name matches NAME
--suite=NAME           : an alias (here for compatibility reasons only)
                         for --test-name=NAME
--assert-on-failure    : when a test fails, crash immediately (useful
                         when running under a debugger
--stop-on-failure      : when a test fails, stop immediately
--fullness=FULLNESS    : choose the duration of tests to run: QUICK,
                         EXTENSIVE, or TAKES_FOREVER, where EXTENSIVE
                         includes QUICK and TAKES_FOREVER includes
                         QUICK and EXTENSIVE (only QUICK tests are
                         run by default)
--verbose              : print details of test execution
--xml                  : format test run output as xml
--tempdir=DIR          : set temp dir for tests to store output files
--datadir=DIR          : set data dir for tests to read reference files
--out=FILE             : send test result to FILE instead of standard output
--append=FILE          : append test result to FILE instead of standard output

若是你有看過 test.py ，你會發現不少你熟悉的可用東西。這應該是在預料之中，由於 test- runner 是 test.py 和 ns-3 之間的一個接口。你可能注意到這裏沒有 example-related 命令。這是由於 examples 真的不是 ns-3 測試。 test.py 運行它們彷彿它們呈現了一個統一的測試環境，但實際上它們真的徹底不一樣，且在這裏找不到。

出如今這裏的第一個新選項但 test.py 中沒有的是 --assert-on-failure 選項。當在調試器中，好比 gdb ，運行調試一個 test case 時，該選項是有用的。當選定該選項時，若是檢測到一個錯誤，該選項會告訴潛在的 test case 引發了內存段異常。它有好的反作用，當檢測到一個錯誤時，它會形成程序執行中止（break into the debugger）。若是你使用 gdb ，你可使用該選項相似於

$ ./waf shell
$ cd build/utils
$ gdb ns3-dev-test-runner-debug
$ run --suite=global-value --assert-on-failure

若是在 global-value test suite 中發現一個錯誤，會產生一個segfault（段錯誤），而且在檢測到錯誤時，（source level）調試器會中止在 NS_TEST_ASSERT_MSG 。

爲了直接使用 waf 從 test-runner 運行測試，你須要指定 test suite運行。所以，你可使用 shell 而後執行：

$ ./waf --run "test-runner --suite=pcap-file"

當你按照下列方式運行時，ns-3 logging 是可用的，例如：（這一命令很是實用！）

$ NS_LOG="Packet" ./waf -- run "test-runner -- suite=pcap-file"

例如，對「lte-test-rr-ff-mac-scheduler.cc」添加日誌功能，能夠獲取相關的吞吐量信息，使用相似上述的命令：tcp

$ NS_LOG="LenaTestRrFfMacScheduler" ./waf --run "test-runner --suite=lte-rr-ff-mac-scheduler" >& log5.out

能夠在 log5.out 中查看有用的日誌信息，部分截圖以下：

（5a）Test output（測試輸出）

不少 test suites 在運行測試的過程當中須要寫臨時文件（例如 pcap 文件）。而後測試須要一個臨時目錄來寫。Python 測試工具（test.py）會自動提供一個臨時文件，可是若是單獨運行，必須提供該臨時文件。若是持續性提供一個--tempdir ，這可能有點使人厭煩，所以若是你本身不提供一個，test runner 將爲你提供一個。它首先尋找名爲 TMP 和 TEMP 和的環境變量，而後使用它們。若是 TMP 和 TEMP 都沒有定義，它會選擇 /tmp 。代碼而後添加到一個標識符上，表示所在的目錄（ns-3），而後緊隨時間（hh.mm.ss）後面的是一個大的隨機數。test runner 會建立一個目錄，其名稱會用做臨時路徑。臨時文件而後進入到一個路徑，路徑命名相似於：

/tmp/ns-3.10.25.37.61537845

若是你須要回頭看看放置在該路徑的文件時，時間是一個提示，這樣你能夠相對容易重建使用過的路徑。

另外一類輸出是測試輸出，相似生成 pcap traces ，用於比較參考輸出。在 test suites 全都運行完成後，測試程序一般會刪掉這些。爲了禁止刪除測試輸出，可使用「retain」選項來運行 test.py ：

$ ./test.py -r

而後測試輸出能夠在路徑 testpy-output/ 下找到。

（5b）Reporting of test failures（上報測試失敗）

當你使用 test-runner 運行 test suite 時，它會運行測試並上報 PASS 或 FAIL。爲了更安靜地運行程序，你須要指定一個輸出文件——測試會使用 --out 選項寫進它們的狀態。嘗試輸入下列代碼：

$ ./waf --run "test-runner --suite=pcap-file --out=myfile.txt"

（5c）Debugging test suite failures

爲了調試測試 crashes，例如

CRASH: TestSuite ns3-wifi-interference

你能夠經過以下的 gdb 接入潛在的 test-runner 程序，而後傳遞「–basedir='pwd'」參數運行（須要的話你也能夠傳遞其餘的參數，可是最低要求爲屬性同樣）：

$ ./waf --command-template="gdb %s" --run "test-runner"
Waf: Entering directory `/home/tomh/hg/sep09/ns-3-allinone/ns-3-dev-678/build'Waf: Leaving directory `/home/tomh/hg/sep09/ns-3-allinone/ns-3-dev-678/build''build' finished successfully (0.380s)
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
L cense GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) r --suite=
Starting program: <..>/build/utils/ns3-dev-test-runner-debug --suite=ns3-wifi-interference
[Thread debugging using libthread_db enabled]
assert failed. file=../src/core/model/type-id.cc, line=138, cond="uid <= m_information.size () && uid != 0"
...

這裏還有另一個例子教你如何使用 valgrind 調試內存問題，例如：

VALGR: TestSuite devices-mesh-dot11s-regression

$ ./waf --command-template="valgrind %s --suite=devices-mesh-dot11s-regression" --run test-runner

（5）Class TestRunner

運行專用測試程序的可執行文件須要使用類 TestRunner 。該類會提供自動的測試註冊和清單，以及執行單個測試的方法。單獨的 test suites 使用 C++ 全局構造函數添加它們自身到由 test runner 管理的 test suites 集合中。 test runner 用於列舉全部可用的測試和選擇要運行的測試。TestRunner是一個很是簡單的類，提供3種靜態方法，用於提供、添加或得到 test suites 到測試集合中。查看 doxygen瞭解更多關於類 ns3::TestRunner 的信息。

（6）Test Suite

全部的 ns-3 測試分爲Test Suites 和 Test Cases。一個 test suite 是 test cases 的集合，徹底使用一種給定的功能。正如前面所述， test suites 分類爲，

Build Verification Tests
Unit Tests
System Tests
Examples
Performance Tests

classification 是從 TestSuite 類中導出的。該類十分簡單，現有的只有一個地方輸出其類型和積累 test cases。從用戶的的角度來講，爲了在系統中建立一個新的 TestSuite ，用戶只需定義一個新的類（繼承類 TestSuite）並執行這兩個任務。

下面代碼將定義一個新的類，能夠經過 test.py 做爲「單元」測試進行運行，顯示名稱爲 my-test-suite-name。

class MySuite : public TestSuite
{
public:
  MyTestSuite ();
};

MyTestSuite::MyTestSuite ()
  : TestSuite ("my-test-suite-name", UNIT)
{
  AddTestCase (new MyTestCase, TestCase::QUICK);
}

static MyTestSuite myTestSuite;

基類負責測試框架中要求的全部登記和報告。

避免將初始化邏輯放入到 test suite 或 test case 的構造函數中。緣由是 test suite 的實例被建立在運行時間（因爲上述靜態變量），無論測試是否運行。相反，TestCase 提供一個虛的 DoSetup方法，能夠在 DoRun 被調用前專門執行 setup 。

（7）Test Case

使用 TestCase 類能夠建立單獨的測試。使用 test case 的通常模型包括「one test case per feature」，和「one test case per method」。也能夠將這些模型混合起來使用。

爲了在系統中建立一個新的 test case，必需要繼承 TestCase 基類，重寫（override）構造函數爲 test case 指定一個名稱，重寫 DoRun 方法以運行測試。可選的，也能夠重寫 DoSetup 方法。

class MyTestCase : public TestCase{
  MyTestCase ();
  virtual void DoSetup (void);
  virtual void DoRun (void);};

MyTestCase::MyTestCase ()
  : TestCase ("Check some bit of functionality"){}

voidMyTestCase::DoRun (void){
  NS_TEST_ASSERT_MSG_EQ (true, true, "Some failure message");}

（8）Utilities（實用工具）

多種實用工具也是測試框架的一部分。Examples 中包含用於存儲測試向量的通常性 pcap 文件；在測試執行期間用於臨時存儲測試向量的通用容器；基於 validation 和 verification 測試結果生成報告的工具。

這裏就不介紹這些實用工具了，可是能夠看看，例如，src/test/ns3tcp/ 中的 TCP 測試是如何使用 pcap 文件和參考輸出的。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。