Manual——Test（翻译1）
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)。如果你不熟悉该系统，可以参考 ——jenkins 是⼀个开源的⾃动化系统，允许 ns-3 ⽇常重建和测试。通过在很多不同系统上运⾏ buildbots（⼀种⾃动化构建⼯具），我们可以确保 ns-3 在它⽀持的所有系统上正确地构建和执⾏。
⽤户（和开发者）通常不会与 buildslave 系统打交道，除了读取它的关于测试结果的消息。如果在⼀个⾃动化构建和测试的⼯作中检测到 FAIL， buildbot 会发送邮件给ns-commits mailing 列表。该邮件看起来类似于：
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
-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 l
如果指定可选的输出⽅式，可以⽣成详细的测试和状态描述。可选的样式有 text 和 HTML 。buildbots 选择 HTML ⽅式⽣成 HTML 测试报告⽤于 nightly builds ：$ ./test.py --html=nightly.html
这种情况下，测试完成时会创建⼀个名为‘’nightly.html’’ 的 HTML ⽂件，对细节感兴趣的⽤户可以选择以下⼀种可读的格式：
$ ./test.py --
在上述例⼦中，test suite 检测到 ns-3 ⽆线设备传播损耗模型 FAIL。默认不会提供进⼀步的信息。
为了进⼀步探寻 FAIL， test.py 允许指定单个 test suite 。运⾏下列命令。
$ ./test.py --suite=propagation-loss-model
或者等价于
$ ./test.py -s propagation-loss-model
结果是单个 test suite 正在运⾏。
FAIL: TestSuite propagation-loss-model
为了到有关失败的详细信息，我们必须指定期望输出的类型。例如，⼤多数⼈可能对⽂本⽂件感兴趣：
$ ./test.py --suite=propagation-loss-model --
这会导致运⾏单个test suite ，并且测试状态会写⼊到⽂件 “”。
你会发现⼀些类似下⾯的输出：
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/
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 运⾏：
$ ./test.py --constrain=unit
为了快速看到合法的约束列表，你可以要求它们列举出来。下使⽤列代码：
$ ./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 运⾏，
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-n-1.pcap ⽂件。
可⽤的 examples 列表由分配的 ‘’examples’’ 路径的内容定义。如果你使⽤ --example 选项选择⼀个 example 执⾏， test.py 将不会做任何尝试来判断 example 是否已经配置，它只是尝试运⾏它并上报尝试的结果。
当 test.py 运⾏时，默认情况下，它会⾸先确认系统是否已经完全编译。这可以通过选择 --nowaf 选项来打破。
$ ./test.py --list --nowaf
将会导致显⽰当前已经编译的 test suites ，类似于：
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/ 是这种测试的⼀个例⼦。⽂件 src/network/ 是另⼀个使⽤已知且好的 pcap ⽂件作为测试向量⽂件的例⼦，该⽂件存储在本地 src/network 路径下。
（3c）System Tests（系统测试）
系统测试的定义为在系统中涉及不⽌⼀个模块的测试。在我们当前的回归框架中，有很多这种测试在运⾏，但它们通常是超载的例⼦。我们提供了⼀个新的地⽅放置这种测试，路径为 src/test。⽂件 src/test/ 是这种测试的⼀个例⼦。它使⽤ 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"
extensive翻译你会看到类似下⾯的输出：
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论