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 文件和参考输出的。