It is possible to test Open vSwitch using both tooling provided with Open vSwitch and using a variety of third party tooling.
可以使用Open vSwitch提供的工具和各种各样的第三方工具来测试Open vSwitch。
Built-in Tooling
Open vSwitch provides a number of different test suites and other tooling for validating basic functionality of OVS. Before running any of the tests described here, you must bootstrap, configure and build Open vSwitch as described in Open vSwitch on Linux, FreeBSD and NetBSD. You do not need to install Open vSwitch or to build or load the kernel module to run these test suites. You do not need supervisor privilege to run these test suites.
内置工具
Open vSwitch提供了许多不同的测试套件和其他工具，用于验证OVS的基本功能。在运行本文描述的任何测试之前，必须先在Linux、FreeBSD等操作系统上，正确的bootstrap、configure和build Open vSwitch。您不需要安装Open vSwitch，也不需要构建或加载内核模块来运行这些测试套件。运行这些测试套件不需要管理员特权。
Unit Tests
Open vSwitch includes a suite of self-tests. Before you submit patches upstream, we advise that you run the tests and ensure that they pass. If you add new features to Open vSwitch, then adding tests for those features will ensure your features don’t break as developers modify other areas of Open vSwitch.
To run all the unit tests in Open vSwitch, one at a time, run:
make check
This takes under 5 minutes on a modern desktop system.
To run all the unit tests in Open vSwitch in parallel, run:
make check TESTSUITEFLAGS=-j8
You can run up to eight threads. This takes under a minute on a modern 4-core desktop system.
To see a list of all the available tests, run:
make check TESTSUITEFLAGS=--list
To run only a subset of tests, e.g. test 123 and tests 477 through 484, run:
make check TESTSUITEFLAGS='123 477-484'
Tests do not have inter-dependencies, so you may run any subset.
To run tests matching a keyword, e.g. ovsdb, run:
make check TESTSUITEFLAGS='-k ovsdb'
To see a complete list of test options, run:
make check TESTSUITEFLAGS=--help
The results of a testing run are reported in tests/testsuite.log. Report report test failures as bugs and include the testsuite.log in your report.
Note: Sometimes a few tests may fail on some runs but not others. This is usually a bug in the testsuite, not a bug in Open vSwitch itself. If you find that a test fails intermittently, please report it, since the developers may not have noticed. You can make the testsuite automatically rerun tests that fail, by adding RECHECK=yes to the make command line, e.g.:
make check TESTSUITEFLAGS=-j8 RECHECK=yes
单元测试
Open vSwitch包括一套自检代码。在您向远程仓库提交补丁之前，我们建议您运行测试代码并确保它们全部都通过。如果您为Open vSwitch添加新的特性，为这些新特性添加测试代码，将确保当其他开发人员修改Open vSwitch的其他区域时，您添加的新特性不会被破坏。
运行所有的单元测试，一次一个，使用下面这个命令：
make check
在现代桌面系统上，这只需要不到5分钟。
要并行运行Open vSwitch中的所有单元测试，请运行:
make check TESTSUITEFLAGS=-j8
您最多可以运行8个线程。这在现代的4核桌面系统上只需要不到一分钟的时间。
要查看所有可用测试的列表，请运行:
make check TESTSUITEFLAGS=--list
如果只运行一个测试子集，例如测试123和测试477到484，请运行:
make check TESTSUITEFLAGS='123 477-484'
测试没有相互依赖关系，所以您可以运行任何子集。
要运行匹配关键字的测试，例如ovsdb，请运行:
make check TESTSUITEFLAGS='-k ovsdb'
要查看测试选项的完整列表，请运行:
make check TESTSUITEFLAGS=--help
测试运行的结果报告在tests/testsuite.log中。将测试失败作为bug报告，并在报告中包含testsuite.log。
注意:有时一些测试可能在某些运行中失败，但在其他运行中不会。这通常是测试套件中的错误，而不是Open vSwitch本身的错误。如果你发现测试间歇失败，请报告它，因为开发人员可能没有注意到。通过在make命令行中添加RECHECK=yes，可以使测试套件自动重新运行失败的测试，例如:
make check TESTSUITEFLAGS=-j8 RECHECK=yes
Debugging unit tests
To initiate debugging from artifacts generated from make check run, set the OVS_PAUSE_TEST environment variable to 1. For example, to run test case 139 and pause on error:
OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v 139'
When error occurs, above command would display something like this:
Set environment variable to use various ovs utilities
export OVS_RUNDIR=<dir>/ovs/_build-gcc/tests/testsuite.dir/0139
Press ENTER to continue:
And from another window, one can execute ovs-xxx commands like:
export OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/testsuite.dir/0139
$ ovs-ofctl dump-ports br0
.
.
Once done with investigation, press ENTER to perform cleanup operation.
调试单元测试
从由make check运行生成的工件开始初始化调试，将环境变量OVS_PAUSE_TEST设置为1。比如说，运行实例139并在发生错误时候暂停。
OVS_PAUSE_TEST=1 make check TESTSUITEFLAGS='-v 139'
当有错误发生，上述命令会产生下面的内容：
Set environment variable to use various ovs utilities
export OVS_RUNDIR=<dir>/ovs/_build-gcc/tests/testsuite.dir/0139
Press ENTER to continue:
然后从其他窗口，我们可以运行ovs-xxx命令，如：
export OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/testsuite.dir/0139
$ ovs-ofctl dump-ports br0
.
.
当调试结束，使用ENTER键清除操作。
Coverage
If the build was configured with --enable-coverage and the lcov utility is installed, you can run the testsuite and generate a code coverage report by using the check-lcov target:
make check-lcov
All the same options are available via TESTSUITEFLAGS. For example:
make check-lcov TESTSUITEFLAGS='-j8 -k ovsdb'
代码覆盖率
如果构建项目的时候配置了--enable-coverage标签并且已经安装了lcov组件，你可以使用target check-lcov运行所有的测试用例，并生成代码覆盖率报告:
make check-lcov
跟之前一样，所有的操作都可以使用TESTSUITEFLAGS。 例如:
make check-lcov TESTSUITEFLAGS='-j8 -k ovsdb'
Valgrind
If you have valgrind installed, you can run the testsuite under valgrind by using the check-valgrind target:
$ make check-valgrind
When you do this, the “valgrind” results for test <N>are reported in files named tests/testsuite.dir/<N>/valgrind.*.
To test the testsuite of kernel datapath under valgrind, you can use the check-kernel-valgrindtarget and find the “valgrind” results under directory tests/system-kmod-testsuite.dir/.
All the same options are available via TESTSUITEFLAGS.
Hint:You may find that the valgrind results are easier to interpret if you put -q in ~/.valgrindrc, since that reduces the amount of output.
如果你已经安装了valgrind（Valgrind是用于内存调试、内存泄漏检测、性能分析的软件），
您可以使用targetcheck-valgrind在valgrind下运行测试代码：
$ make check-valgrind
当你做完了之后，测试用例<N>的“valgrind”的结果会输出在这个文件中tests/testsuite.dir/<N>/ valgrind.*
为了测试valgrind下的内核数据路径测试套件，你可以使用targetcheck-kernel-valgrind来完成，其结果会输出在tests/system-kmod-testsuite.dir/这个目录中。
同样，所有的操作都可以使用TESTSUITEFLAGS
暗示：如果在~/.valgrindrc中加入-q，您可能会发现valgrind结果更容易说明。因为这减少了产量。
OFTest
OFTest is an OpenFlow protocol testing suite. Open vSwitch includes a Makefile target to run OFTest with Open vSwitch in “dummy mode”. In this mode of testing, no packets travel across physical or virtual networks. Instead, Unix domain sockets stand in as simulated networks. This simulation is imperfect, but it is much easier to set up, does not require extra physical or virtual hardware, and does not require supervisor privileges.
To run OFTest with Open vSwitch, you must obtain a copy of OFTest and install its prerequisites. You need a copy of OFTest that includes commit 406614846c5 (make ovs-dummy platform work again). This commit was merged into the OFTest repository on Feb 1, 2013, so any copy of OFTest more recent than that should work. Testing OVS in dummy mode does not require root privilege, so you may ignore that requirement.
Optionally, add the top-level OFTest directory (containing the oft program) to your $PATH. This slightly simplifies running OFTest later.
To run OFTest in dummy mode, run the following command from your Open vSwitch build directory:
$ make check-oftest OFT=<oft-binary>
where <oft-binary> is the absolute path to the oft program in OFTest. If you added “oft” to your $PATH, you may omit the OFT variable assignment By default, check-oftest passes oft just enough options to enable dummy mode. You can use OFTFLAGS to pass additional options. For example, to run just the basic.Echo test instead of all tests (the default) and enable verbose logging, run:
$ make check-oftest OFT=<oft-binary> OFTFLAGS='--verbose -T basic.Echo'
If you use OFTest that does not include commit 4d1f3eb2c792 (oft: change default port to 6653), merged into the OFTest repository in October 2013, then you need to add an option to use the IETF-assigned controller port:
$ make check-oftest OFT=<oft-binary> OFTFLAGS='--port=6653'
Interpret OFTest results cautiously. Open vSwitch can fail a given test in OFTest for many reasons, including bugs in Open vSwitch, bugs in OFTest, bugs in the “dummy mode” integration, and differing interpretations of the OpenFlow standard and other standards.
Note: Open vSwitch has not been validated against OFTest. Report test failures that you believe to represent bugs in Open vSwitch. Include the precise versions of Open vSwitch and OFTest in your bug report, plus any other information needed to reproduce the problem.
OpenFlow协议测试
OFTest是一个OpenFlow协议测试套件。Open VSwitch包含一个Makefile target来在"dummy mode"模拟模式下运行OFTest。在这种测试模式下，不会有数据包通过物理或虚拟网络进行传输。相反,Unix domain sockets充当模拟网络。这种模拟并不完美，但它更容易设置，而且不需要额外的物理或虚拟硬件，也不需要管理员权限。
要使用Open vSwitch运行OFTest，你必须获取一份OFTest的拷贝，并安装它的依赖。你需要一份OFTest的拷贝，即包含提交406614846c5的代码(使ovs-dummy平台再次工作)。这个提交在2013年2月1日被合并到OFTest存储库中，所以任何比它更近的OFTest副本都应该可以工作。在"dummy mode"下测试OVS不需要root权限，因此可以忽略该需求。
可选择将顶层的OFTest目录(包含oft程序)添加到你的$PATH环境变量中。这将稍微简化以后运行OFTest。
要在"dummy mode"下运行OFTest，请在Open vSwitch构建目录下运行以下命令:
$ make check-oftest OFT=<oft-binary>
其中<oft-binary>是OFTest中oft程序的绝对路径。如果你在$PATH中添加了" oft "，你可以忽略oft变量的赋值。默认情况下，check-oftest会传给oft足够多的选项来启动虚拟模式。你可以使用OFTFLAGS来传递其他选项。例如，basic.Echo只运行基本测试而不是所有测试(默认)+启用详细日志记录，运行:
$ make check-oftest OFT=<oft-binary> OFTFLAGS='--verbose -T basic.Echo'
如果你使用的OFTest不包括4d1f3eb2c792 (oft:更改默认端口为6653)这个commit，2013年10月合并到OFTest远程仓库。你需要添加一个选项来使用IETF指定的控制器端口:
$ make check-oftest OFT=<oft-binary> OFTFLAGS='--port=6653'
谨慎解释测试结果。在OFTest中，Open vSwitch可能会因为许多原因导致给定的测试失败，包括Open vSwitch自身的bug, OFTest中的bug，“dummy mode”集成中的bug，以及OpenFlow标准和其他标准造成的bug。
注意：Open vSwitch未通过OFTest验证。报告您认为代表缺陷的测试用例。在错误报告中写出Open vSwitch和OFTest的精确版本，以及重现问题所需的所有信息。
Ryu
Ryu is an OpenFlow controller written in Python that includes an extensive OpenFlow testsuite. Open vSwitch includes a Makefile target to run Ryu in “dummy mode”. See OFTest above for an explanation of dummy mode.
To run Ryu tests with Open vSwitch, first read and follow the instructions under Testing above. Second, obtain a copy of Ryu, install its prerequisites, and build it. You do not need to install Ryu (some of the tests do not get installed, so it does not help).
To run Ryu tests, run the following command from your Open vSwitch build directory:
$ make check-ryu RYUDIR=<ryu-source-dir>
where <ryu-source-dir> is the absolute path to the root of the Ryu source distribution. The default<ryu-source-dir>is $srcdir/../ryu where$srcdir is your Open vSwitch source directory. If this is correct, omit RYUDIR
Note: Open vSwitch has not been validated against Ryu. Report test failures that you believe to represent bugs in Open vSwitch. Include the precise versions of Open vSwitch and Ryu in your bug report, plus any other information needed to reproduce the problem.
Ryu测试
Ryu是一个用Python编写的OpenFlow控制器，它包含一个扩展的OpenFlow测试套件。Open vSwitch包括一个Makefile target，可以“dummy mode”下运行Ryu。关于“dummy mode”的解释请参见OFTest。
要使用Open vSwitch运行Ryu测试，第一步先阅读并遵循上面的测试说明。第二步你需要获取Ryu的副本，第三步安装它的依赖，然后构建它。您不需要安装Ryu(一些测试没有安装，所以它没有帮助)。
要运行Ryu测试，请从Open vSwitch构建目录运行以下命令:
$ make check-ryu RYUDIR=<ryu-source-dir>
其中<ryu-source-dir>是Ryu源码的绝对路径，默认的<ryu-source-dir>是$srcdir/../ryu其中$srcdir是你的Open vSwitch的源码目录。如果上述配置正确，你可以省略RYUDIR。
注意：Open vSwitch还没有对Ryu进行验证。报告您认为代表缺陷的测试失败Open vSwitch。在错误报告中包括Open vSwitch和Ryu的精确版本，以及再现问题所需的所有信息。
Datapath testing
Open vSwitch includes a suite of tests specifically for datapath functionality, which can be run against the userspace or kernel datapaths. If you are developing datapath features, it is recommended that you use these tests and build upon them to verify your implementation.
The datapath tests make some assumptions about the environment. They must be run under root privileges on a Linux system with support for network namespaces. For ease of use, the OVS source tree includes a vagrant box to invoke these tests. Running the tests inside Vagrant provides kernel isolation, protecting your development host from kernel panics or configuration conflicts in the testsuite. If you wish to run the tests without using the vagrant box, there are further instructions below.
Vagrant
Important:Requires Vagrant (version 1.7.0 or later) and a compatible hypervisor.
Note:You must bootstrap and configure the sources (see doc:/intro/install/general) before you run the steps described here.
A Vagrantfile is provided allowing to compile and provision the source tree as found locally in a virtual machine using the following command:
$ vagrant up
This will bring up a Fedora 23 VM by default. If you wish to use a different box or a vagrant backend not supported by the default box, the Vagrantfilecan be modified to use a different box as base.
The VM can be reprovisioned at any time:
$ vagrant provision
OVS out-of-tree compilation environment can be set up with:
$ ./boot.sh
$ vagrant provision --provision-with configure_ovs,build_ovs
This will set up an out-of-tree build environment inside the VM in /root/build. The source code can be found in /vagrant.
To recompile and reinstall OVS in the VM using RPM:
$ ./boot.sh
$ vagrant provision --provision-with configure_ovs,install_rpm
Two provisioners are included to run system tests with the OVS kernel module or with a userspace datapath. This tests are different from the self-tests mentioned above. To run them:
$ ./boot.sh
$ vagrant provision --provision-with \
configure_ovs,test_ovs_kmod,test_ovs_system_userspace
The results of the testsuite reside in the VM root user’s home directory:
$ vagrant ssh
$ sudo -s
$ cd /root/build
$ ls tests/system*
Native
The datapath testsuite as invoked by Vagrant above may also be run manually on a Linux system with root privileges.Make sure, no other Open vSwitch instance is running on the test suite. These tests may take several minutes to complete, and cannot be run in parallel.
Userspace datapath
To invoke the datapath testsuite with the userspace datapath, run:
$ make check-system-userspace
The results of the testsuite are in tests/system-userspace-testsuite.dir.
All the features documented under Unit Tests are available for the userspace datapath testsuite.
Userspace datapath with DPDK
To test Open vSwitch with DPDK (i.e., the build was configured with --with-dpdk, the DPDK is installed), run the testsuite and generate a report by using the check-dpdk target:
# make check-dpdk
or if you are not a root, but a sudo user:
$ sudo -E make check-dpdk
To see a list of all the available tests, run:
# make check-dpdk TESTSUITEFLAGS=--list
These tests support a DPDK supported NIC. The tests operate on a wider set of environments, for instance, when a virtual port is used. They do require proper DPDK variables (DPDK_DIR and DPDK_BUILD). Moreover you need to have root privileges to load the required modules and to bind the NIC to the DPDK-compatible driver.
All tests are skipped if no hugepages are configured. User must look into the DPDK manual to figure out how to Configure hugepages. The phy test will skip if no compatible physical device is available.
All the features documented under Unit Tests are available for the DPDK datapath testsuite.
Kernel datapath
Make targets are also provided for testing the Linux kernel module. Note that these tests operate by inserting modules into the running Linux kernel, so if the tests are able to trigger a bug in the OVS kernel module or in the upstream kernel then the kernel may panic.
To run the testsuite against the kernel module which is currently installed on your system, run:
$ make check-kernel
To install the kernel module from the current build directory and run the testsuite against that kernel module:
$ make check-kmod
The results of the testsuite are in tests/system-kmod-testsuite.dir
All the features documented under Unit Tests are available for the kernel datapath testsuite.
Note: Many of the kernel tests are dependent on the utilities present in the iproute2 package, especially the ‘ip’ command. If there are many otherwise unexplained errors it may be necessary to update the iproute2 package utilities on the system. It is beyond the scope of this documentation to explain all that is necessary to build and install an updated iproute2 utilities package. The package is available from the Linux kernel organization open source git repositories.
网友评论