csit rls1701 report edits:
[csit.git] / docs / report / honeycomb_functional_tests / overview.rst
@@ -1,8 +1,8 @@
 Overview\r
 ========\r
 \r
 Overview\r
 ========\r
 \r
-Tested Topologies VIRL\r
-----------------------\r
+Tested Virtual Topologies\r
+-------------------------\r
 \r
 CSIT Honeycomb functional tests are executed on virtualized topologies created\r
 using Virtual Internet Routing Lab (VIRL) simulation platform contributed by\r
 \r
 CSIT Honeycomb functional tests are executed on virtualized topologies created\r
 using Virtual Internet Routing Lab (VIRL) simulation platform contributed by\r
@@ -45,8 +45,8 @@ test execution, all nodes are reachable thru the Management network connected
 to every node via dedicated virtual NICs and virtual links (not shown above\r
 for clarity).\r
 \r
 to every node via dedicated virtual NICs and virtual links (not shown above\r
 for clarity).\r
 \r
-Honeycomb Functional Tests Overview\r
------------------------------------\r
+Functional Tests Coverage\r
+-------------------------\r
 \r
 The following Honeycomb functional test areas are included in the CSIT |release|\r
 with results listed in this report:\r
 \r
 The following Honeycomb functional test areas are included in the CSIT |release|\r
 with results listed in this report:\r
@@ -135,3 +135,34 @@ Because of this, test cases follow this general pattern:
 Test cases involving network interfaces utilize the first two interfaces on\r
 the DUT node.\r
 \r
 Test cases involving network interfaces utilize the first two interfaces on\r
 the DUT node.\r
 \r
+Functional Tests Naming\r
+-----------------------\r
+\r
+CSIT |release| introduced a common structured naming convention for all\r
+performance and functional tests. This change was driven by substantially\r
+growing number and type of CSIT test cases. Firstly, the original practice did\r
+not always follow any strict naming convention. Secondly test names did not\r
+always clearly capture tested packet encapsulations, and the actual type or\r
+content of the tests. Thirdly HW configurations in terms of NICs, ports and\r
+their locality were not captured either. These were but few reasons that drove\r
+the decision to change and define a new more complete and stricter test naming\r
+convention, and to apply this to all existing and new test cases.\r
+\r
+The new naming should be intuitive for majority of the tests. The complete\r
+description of CSIT test naming convention is provided on `CSIT test naming\r
+page <https://wiki.fd.io/view/CSIT/csit-test-naming>`_.\r
+\r
+Here few illustrative examples of the new naming usage for functional test\r
+suites:\r
+\r
+#. **Physical port to physical port - a.k.a. NIC-to-NIC, Phy-to-Phy, P2P**\r
+\r
+    - *eth2p-ethip4-ip4base-func.robot* => 2 ports of Ethernet, IPv4 baseline\r
+      routed forwarding, functional tests.\r
+\r
+#. **Physical port to VM (or VM chain) to physical port - a.k.a. NIC2VM2NIC,\r
+   P2V2P, NIC2VMchain2NIC, P2V2V2P**\r
+\r
+    - *eth2p-ethip4vxlan-l2bdbasemaclrn-eth-2vhost-1vm-func.robot* => 2 ports of\r
+      Ethernet, IPv4 VXLAN Ethernet, L2 bridge-domain switching to/from two vhost\r
+      interfaces and one VM, functional tests.\r