docs/report/introduction/csit_design.rst

   1 CSIT Design\r
   2 ===========\r
   3 \r
   4 FD.io CSIT system design needs to meet continuously expanding requirements of\r
   5 FD.io projects including VPP, related sub-systems (e.g. plugin applications,\r
   6 DPDK drivers) and FD.io applications (e.g. DPDK applications), as well as\r
   7 growing number of compute platforms running those applications. With CSIT\r
   8 project scope and charter including both FD.io continuous testing AND\r
   9 performance trending/comparisons, those evolving requirements further amplify\r
  10 the need for CSIT framework modularity, flexibility and usability.\r
  11 \r
  12 Design Hierarchy\r
  13 ----------------\r
  14 \r
  15 CSIT follows a hierarchical system design with SUTs and DUTs at the bottom\r
  16 level, and presentation level at the top level, with a number of functional\r
  17 layers in-between. The current CSIT design including CSIT framework is depicted\r
  18 in the diagram below.\r
  19 \r
  20 .. figure:: csit_design.png\r
  21    :alt: FD.io CSIT system design\r
  22    :align: center\r
  23 \r
  24    *Figure 1. FD.io CSIT system design*\r
  25 \r
  26 A brief bottom-up description is provided here:\r
  27 \r
  28 #. SUTs, DUTs, TGs:\r
  29 \r
  30    - SUTs - Systems Under Test\r
  31    - DUTs - Devices Under Test\r
  32    - TGs - Traffic Generators\r
  33 \r
  34 #. Level-1 libraries - Robot and Python:\r
  35 \r
  36    - Lowest level CSIT libraries abstracting underlying test environment, SUT,\r
  37      DUT and TG specifics\r
  38    - Used commonly across multiple L2 KWs\r
  39    - Performance and functional tests:\r
  40 \r
  41      - L1 KWs (KeyWords) are implemented as RF libraries and Python\r
  42        libraries\r
  43 \r
  44    - Performance TG L1 KWs:\r
  45 \r
  46      - All L1 KWs are implemented as Python libraries\r
  47 \r
  48        - Support for TRex only today\r
  49        - Need to add IXIA\r
  50 \r
  51    - Performance data plane traffic profiles:\r
  52 \r
  53      - TG-specific stream profiles provide full control of:\r
  54 \r
  55        - Packet definition – layers, MACs, IPs, ports, combinations thereof\r
  56          e.g. IPs and UDP ports\r
  57        - Stream definitions - different streams can run together, delayed,\r
  58          one after each other\r
  59        - Stream profiles are independent of CSIT framework and can be used\r
  60          in any T-rex setup, can be sent anywhere to repeat tests with\r
  61          exactly the same setup\r
  62        - Easily extensible – one can create a new stream profile that meets\r
  63          tests requirements\r
  64        - Same stream profile can be used for different tests with the same\r
  65          traffic needs\r
  66 \r
  67    - Sunctional data plane traffic scripts:\r
  68 \r
  69      - Scapy specific traffic scripts\r
  70 \r
  71 #. Level-2 libraries - Robot resource files:\r
  72 \r
  73    - Higher level CSIT libraries abstracting required functions for executing\r
  74      tests\r
  75    - L2 KWs are classified into the following functional categories:\r
  76 \r
  77      - Configuration, test, verification, state report\r
  78      - Suite setup, suite teardown\r
  79      - Test setup, test teardown\r
  80 \r
  81 #. Tests - Robot:\r
  82 \r
  83    - Test suites with test cases;\r
  84    - Functional tests using VIRL environment:\r
  85 \r
  86      - VPP\r
  87      - HoneyComb\r
  88 \r
  89    - Performance tests using physical testbed environment:\r
  90 \r
  91      - VPP\r
  92      - Testpmd\r
  93 \r
  94    - Tools:\r
  95 \r
  96      - Documentation generator\r
  97      - Report generator\r
  98      - Testbed environment setup ansible playbooks\r
  99      - Operational debugging scripts\r
 100 \r
 101 Test Lifecycle Abstraction\r
 102 --------------------------\r
 103 \r
 104 A well coded test must follow a disciplined abstraction of the test lifecycles\r
 105 that includes setup, configuration, test and verification. In addition to\r
 106 improve test execution efficiency, the commmon aspects of test setup and\r
 107 configuration shared across multiple test cases should be done only once.\r
 108 Translating these high-level guidelines into the Robot Framework one arrives to\r
 109 definition of a well coded RF tests for FD.io CSIT.\r
 110 Anatomy of Good Tests for CSIT:\r
 111 \r
 112 #. Suite Setup - Suite startup Configuration common to all Test Cases in suite:\r
 113    uses Configuration KWs, Verification KWs, StateReport KWs\r
 114 #. Test Setup - Test startup Configuration common to multiple Test Cases: uses\r
 115    Configuration KWs, StateReport KWs\r
 116 #. Test Case - uses L2 KWs with RF Gherkin style:\r
 117 \r
 118    - prefixed with {Given} - Verification of Test setup, reading state: uses\r
 119      Configuration KWs, Verification KWs, StateReport KWs\r
 120    - prefixed with {When} - Test execution: Configuration KWs, Test KWs\r
 121    - prefixed with {Then} - Verification of Test execution, reading state: uses\r
 122      Verification KWs, StateReport KWs\r
 123 \r
 124 #. Test Teardown - post Test teardown with Configuration cleanup and\r
 125    Verification common to multiple Test Cases - uses: Configuration KWs,\r
 126    Verification KWs, StateReport KWs\r
 127 #. Suite Teardown - Suite post-test Configuration cleanup: uses Configuration\r
 128    KWs, Verification KWs, StateReport KWs\r
 129 \r
 130 RF Keywords Functional Classification\r
 131 -------------------------------------\r
 132 \r
 133 CSIT RF KWs are classified into the functional categories matching the test\r
 134 lifecycle events described earlier. All CSIT RF L2 and L1 KWs have been grouped\r
 135 into the following functional categories:\r
 136 \r
 137 #. Configuration\r
 138 #. Test\r
 139 #. Verification\r
 140 #. StateReport\r
 141 #. SuiteSetup\r
 142 #. TestSetup\r
 143 #. SuiteTeardown\r
 144 #. TestTeardown\r
 145 \r
 146 RF Keywords Naming Guidelines\r
 147 -----------------------------\r
 148 \r
 149 Readability counts: "..code is read much more often than it is written." Hence\r
 150 following a good and consistent grammar practice is important when writing RF\r
 151 KeyWords and Tests.\r
 152 All CSIT test cases are coded using Gherkin style and include only L2 KWs\r
 153 references. L2 KWs are coded using simple style and include L2 KWs, L1 KWs, and\r
 154 L1 python references. To improve readability, the proposal is to use the same\r
 155 grammar for both RF KW styles, and to formalize the grammar of English sentences\r
 156 used for naming the RF KWs.\r
 157 RF KWs names are short sentences expressing functional description of the\r
 158 command. They must follow English sentence grammar in one of the following\r
 159 forms:\r
 160 \r
 161 #. **Imperative** - verb-object(s): *"Do something"*, verb in base form.\r
 162 #. **Declarative** - subject–verb–object(s): *"Subject does something"*, verb in\r
 163    a third-person singular present tense form.\r
 164 #. **Affirmative** - modal_verb-verb-object(s): *"Subject should be something"*,\r
 165    *"Object should exist"*, verb in base form.\r
 166 #. **Negative** - modal_verb-Not-verb-object(s): *"Subject should not be\r
 167    something"*, *"Object should not exist"*, verb in base form.\r
 168 \r
 169 Passive form MUST NOT be used. However a usage of past participle as an\r
 170 adjective is okay. See usage examples.\r
 171 Following sections list applicability of the above grammar forms to different\r
 172 RF KW categories. Usage examples are provided, both good and bad.\r
 173 \r
 174 Coding guidelines\r
 175 -----------------\r
 176 \r
 177 Coding guidelines can be found on `Design optimizations wiki page\r
 178 <https://wiki.fd.io/view/CSIT/Design_Optimizations>`_.\r