correct permanent redirects in documentation
[functest.git] / docs / testing / user / userguide / test_details.rst
1 .. SPDX-License-Identifier: CC-BY-4.0
2
3 The different test cases are described in the remaining sections of this
4 document.
5
6 VIM (Virtualized Infrastructure Manager)
7 ----------------------------------------
8
9 Healthcheck tests
10 ^^^^^^^^^^^^^^^^^
11 Since Danube, healthcheck tests have been refactored and rely on SNAPS, an
12 OPNFV middleware project.
13
14 SNAPS stands for "SDN/NFV Application development Platform and Stack".
15 SNAPS is an object-oriented OpenStack library packaged with tests that exercise
16 OpenStack.
17 More information on SNAPS can be found in  `[13]`_
18
19 Three tests are declared as healthcheck tests and can be used for gating by the
20 installer, they cover functionally the tests previously done by healthcheck
21 test case.
22
23 The tests are:
24
25
26  * *connection_check*
27
28 Connection_check consists in test cases (test duration < 5s) checking the
29 connectivity with Glance, Keystone, Neutron, Nova and the external network.
30
31 Self-obviously, successful completion of the 'healthcheck' testcase is a
32 necessary pre-requisite for the execution of all other test Tiers.
33
34
35 vPing_ssh
36 ^^^^^^^^^
37
38 Given the script **ping.sh**::
39
40     #!/bin/sh
41     ping -c 1 $1 2>&1 >/dev/null
42     RES=$?
43     if [ "Z$RES" = "Z0" ] ; then
44         echo 'vPing OK'
45     else
46         echo 'vPing KO'
47     fi
48
49
50 The goal of this test is to establish an SSH connection using a floating IP
51 on the Public/External network and verify that 2 instances can talk over a
52 Private Tenant network::
53
54  vPing_ssh test case
55  +-------------+                    +-------------+
56  |             |                    |             |
57  |             | Boot VM1 with IP1  |             |
58  |             +------------------->|             |
59  |   Tester    |                    |   System    |
60  |             | Boot VM2           |    Under    |
61  |             +------------------->|     Test    |
62  |             |                    |             |
63  |             | Create floating IP |             |
64  |             +------------------->|             |
65  |             |                    |             |
66  |             | Assign floating IP |             |
67  |             | to VM2             |             |
68  |             +------------------->|             |
69  |             |                    |             |
70  |             | Establish SSH      |             |
71  |             | connection to VM2  |             |
72  |             | through floating IP|             |
73  |             +------------------->|             |
74  |             |                    |             |
75  |             | SCP ping.sh to VM2 |             |
76  |             +------------------->|             |
77  |             |                    |             |
78  |             | VM2 executes       |             |
79  |             | ping.sh to VM1     |             |
80  |             +------------------->|             |
81  |             |                    |             |
82  |             |    If ping:        |             |
83  |             |      exit OK       |             |
84  |             |    else (timeout): |             |
85  |             |      exit Failed   |             |
86  |             |                    |             |
87  +-------------+                    +-------------+
88
89 This test can be considered as an "Hello World" example.
90 It is the first basic use case which **must** work on any deployment.
91
92 vPing_userdata
93 ^^^^^^^^^^^^^^
94
95 This test case is similar to vPing_ssh but without the use of Floating IPs
96 and the Public/External network to transfer the ping script.
97 Instead, it uses Nova metadata service to pass it to the instance at booting
98 time.
99 As vPing_ssh, it checks that 2 instances can talk to
100 each other on a Private Tenant network::
101
102  vPing_userdata test case
103  +-------------+                     +-------------+
104  |             |                     |             |
105  |             | Boot VM1 with IP1   |             |
106  |             +-------------------->|             |
107  |             |                     |             |
108  |             | Boot VM2 with       |             |
109  |             | ping.sh as userdata |             |
110  |             | with IP1 as $1.     |             |
111  |             +-------------------->|             |
112  |   Tester    |                     |   System    |
113  |             | VM2 executes ping.sh|    Under    |
114  |             | (ping IP1)          |     Test    |
115  |             +-------------------->|             |
116  |             |                     |             |
117  |             | Monitor nova        |             |
118  |             |  console-log VM 2   |             |
119  |             |    If ping:         |             |
120  |             |      exit OK        |             |
121  |             |    else (timeout)   |             |
122  |             |      exit Failed    |             |
123  |             |                     |             |
124  +-------------+                     +-------------+
125
126 When the second VM boots it will execute the script passed as userdata
127 automatically. The ping will be detected by periodically capturing the output
128 in the console-log of the second VM.
129
130
131 Tempest
132 ^^^^^^^
133
134 Tempest `[2]`_ is the reference OpenStack Integration test suite.
135 It is a set of integration tests to be run against a live OpenStack cluster.
136 Tempest has suites of tests for:
137
138   * OpenStack API validation
139   * Scenarios
140   * Other specific tests useful in validating an OpenStack deployment
141
142 Functest uses Rally `[3]`_ to run the Tempest suite.
143 Rally generates automatically the Tempest configuration file **tempest.conf**.
144 Before running the actual test cases,
145 Functest creates the needed resources (user, tenant) and
146 updates the appropriate parameters into the configuration file.
147
148 When the Tempest suite is executed, each test duration is measured and the full
149 console output is stored to a *log* file for further analysis.
150
151 The Tempest testcases are distributed across three
152 Tiers:
153
154   * Smoke Tier - Test Case 'tempest_smoke'
155   * Components Tier - Test case 'tempest_full'
156   * Neutron Trunk Port - Test case 'neutron_trunk'
157   * OpenStack interop testcases - Test case 'refstack_defcore'
158   * Testing and verifying RBAC policy enforcement - Test case 'patrole'
159
160 NOTE: Test case 'tempest_smoke' executes a defined set of tempest smoke
161 tests. Test case 'tempest_full' executes all defined Tempest tests.
162
163 NOTE: The 'neutron_trunk' test set allows to connect a VM to multiple VLAN
164 separated networks using a single NIC. The feature neutron trunk ports have
165 been supported by Apex, Fuel and Compass, so the tempest testcases have been
166 integrated normally.
167
168 NOTE: Rally is also used to run Openstack Interop testcases `[9]`_, which focus
169 on testing interoperability between OpenStack clouds.
170
171 NOTE: Patrole is a tempest plugin for testing and verifying RBAC policy
172 enforcement. It runs Tempest-based API tests using specified RBAC roles, thus
173 allowing deployments to verify that only intended roles have access to those
174 APIs. Patrole currently offers testing for the following OpenStack services:
175 Nova, Neutron, Glance, Cinder and Keystone. Currently in functest, only neutron
176 and glance are tested.
177
178 The goal of the Tempest test suite is to check the basic functionalities of the
179 different OpenStack components on an OPNFV fresh installation, using the
180 corresponding REST API interfaces.
181
182
183 Rally bench test suites
184 ^^^^^^^^^^^^^^^^^^^^^^^
185
186 Rally `[3]`_ is a benchmarking tool that answers the question:
187
188 *How does OpenStack work at scale?*
189
190 The goal of this test suite is to benchmark all the different OpenStack modules
191 and get significant figures that could help to define Telco Cloud KPIs.
192
193 The OPNFV Rally scenarios are based on the collection of the actual Rally
194 scenarios:
195
196  * authenticate
197  * cinder
198  * glance
199  * heat
200  * keystone
201  * neutron
202  * nova
203  * quotas
204
205 A basic SLA (stop test on errors) has been implemented.
206
207 The Rally testcases are distributed across two Tiers:
208
209   * Smoke Tier - Test Case 'rally_sanity'
210   * Components Tier - Test case 'rally_full'
211
212 NOTE: Test case 'rally_sanity' executes a limited number of Rally smoke test
213 cases. Test case 'rally_full' executes the full defined set of Rally tests.
214
215
216 SDN Controllers
217 ---------------
218
219 OpenDaylight
220 ^^^^^^^^^^^^
221
222 The OpenDaylight (ODL) test suite consists of a set of basic tests inherited
223 from the ODL project using the Robot `[11]`_ framework.
224 The suite verifies creation and deletion of networks, subnets and ports with
225 OpenDaylight and Neutron.
226
227 The list of tests can be described as follows:
228
229  * Basic Restconf test cases
230
231    * Connect to Restconf URL
232    * Check the HTTP code status
233
234  * Neutron Reachability test cases
235
236    * Get the complete list of neutron resources (networks, subnets, ports)
237
238  * Neutron Network test cases
239
240    * Check OpenStack networks
241    * Check OpenDaylight networks
242    * Create a new network via OpenStack and check the HTTP status code returned
243      by Neutron
244    * Check that the network has also been successfully created in OpenDaylight
245
246  * Neutron Subnet test cases
247
248    * Check OpenStack subnets
249    * Check OpenDaylight subnets
250    * Create a new subnet via OpenStack and check the HTTP status code returned
251      by Neutron
252    * Check that the subnet has also been successfully created in OpenDaylight
253
254  * Neutron Port test cases
255
256    * Check OpenStack Neutron for known ports
257    * Check OpenDaylight ports
258    * Create a new port via OpenStack and check the HTTP status code returned by
259      Neutron
260    * Check that the new port has also been successfully created in OpenDaylight
261
262  * Delete operations
263
264    * Delete the port previously created via OpenStack
265    * Check that the port has been also successfully deleted in OpenDaylight
266    * Delete previously subnet created via OpenStack
267    * Check that the subnet has also been successfully deleted in OpenDaylight
268    * Delete the network created via OpenStack
269    * Check that the network has also been successfully deleted in OpenDaylight
270
271 Note: the checks in OpenDaylight are based on the returned HTTP status
272 code returned by OpenDaylight.
273
274
275 Features
276 --------
277
278 Functest has been supporting several feature projects since Brahmaputra:
279
280
281 +-----------------+---------+----------+--------+-----------+-----------+
282 | Test            | Brahma  | Colorado | Danube | Euphrates |  Fraser   |
283 +=================+=========+==========+========+===========+===========+
284 | barometer       |         |          |    X   |     X     |     X     |
285 +-----------------+---------+----------+--------+-----------+-----------+
286 | bgpvpn          |         |    X     |    X   |     X     |     X     |
287 +-----------------+---------+----------+--------+-----------+-----------+
288 | copper          |         |    X     |        |           |           |
289 +-----------------+---------+----------+--------+-----------+-----------+
290 | doctor          |    X    |    X     |    X   |     X     |     X     |
291 +-----------------+---------+----------+--------+-----------+-----------+
292 | domino          |         |    X     |    X   |     X     |           |
293 +-----------------+---------+----------+--------+-----------+-----------+
294 | fds             |         |          |    X   |     X     |     X     |
295 +-----------------+---------+----------+--------+-----------+-----------+
296 | moon            |         |    X     |        |           |           |
297 +-----------------+---------+----------+--------+-----------+-----------+
298 | multisite       |         |    X     |    X   |           |           |
299 +-----------------+---------+----------+--------+-----------+-----------+
300 | netready        |         |          |    X   |           |           |
301 +-----------------+---------+----------+--------+-----------+-----------+
302 | odl_sfc         |         |    X     |    X   |     X     |     X     |
303 +-----------------+---------+----------+--------+-----------+-----------+
304 | opera           |         |          |    X   |           |           |
305 +-----------------+---------+----------+--------+-----------+-----------+
306 | orchestra       |         |          |    X   |     X     |     X     |
307 +-----------------+---------+----------+--------+-----------+-----------+
308 | parser          |         |          |    X   |     X     |     X     |
309 +-----------------+---------+----------+--------+-----------+-----------+
310 | promise         |    X    |    X     |    X   |     X     |     X     |
311 +-----------------+---------+----------+--------+-----------+-----------+
312 | security_scan   |         |    X     |    X   |           |           |
313 +-----------------+---------+----------+--------+-----------+-----------+
314 | clover          |         |          |        |           |     X     |
315 +-----------------+---------+----------+--------+-----------+-----------+
316 | stor4nfv        |         |          |        |           |     X     |
317 +-----------------+---------+----------+--------+-----------+-----------+
318
319 Please refer to the dedicated feature user guides for details.
320
321
322 VNF
323 ---
324
325
326 cloudify_ims
327 ^^^^^^^^^^^^
328 The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an
329 architectural framework for delivering IP multimedia services.
330
331 vIMS has been integrated in Functest to demonstrate the capability to deploy a
332 relatively complex NFV scenario on the OPNFV platform. The deployment of a
333 complete functional VNF allows the test of most of the essential functions
334 needed for a NFV platform.
335
336 The goal of this test suite consists of:
337
338  * deploy a VNF orchestrator (Cloudify)
339  * deploy a Clearwater vIMS (IP Multimedia Subsystem) VNF from this
340    orchestrator based on a TOSCA blueprint defined in `[5]`_
341  * run suite of signaling tests on top of this VNF
342
343 The Clearwater architecture is described as follows:
344
345 .. figure:: ../../../images/clearwater-architecture-v2.png
346    :align: center
347    :alt: vIMS architecture
348
349 heat_ims
350 ^^^^^^^^
351 The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an
352 architectural framework for delivering IP multimedia services.
353
354 vIMS has been integrated in Functest to demonstrate the capability to deploy a
355 relatively complex NFV scenario on the OPNFV platform. The deployment of a
356 complete functional VNF allows the test of most of the essential functions
357 needed for a NFV platform.
358
359 The goal of this test suite consists of:
360
361 * deploy a Clearwater vIMS (IP Multimedia Subsystem) VNF using
362   OpenStack Heat orchestrator based on a HOT template defined in `[17]`_
363 * run suite of signaling tests on top of this VNF
364
365 The Clearwater architecture is described as follows:
366
367 .. figure:: ../../../images/clearwater-architecture-v2.png
368   :align: center
369   :alt: vIMS architecture
370
371 vyos-vrouter
372 ^^^^^^^^^^^^
373 This test case deals with the deployment and the test of vyos vrouter with
374 Cloudify orchestrator. The test case can do testing for interchangeability of
375 BGP Protocol using vyos.
376
377 The Workflow is as follows:
378  * Deploy
379     Deploy VNF Testing topology by Cloudify using blueprint.
380  * Configuration
381     Setting configuration to Target VNF and reference VNF using ssh
382  * Run
383     Execution of test command for test item written YAML format  file.
384     Check VNF status and behavior.
385  * Reporting
386     Output of report based on result using JSON format.
387
388 The vyos-vrouter architecture is described in `[14]`_
389
390 juju_epc
391 ^^^^^^^^
392 The Evolved Packet Core (EPC) is the main component of the System Architecture
393 Evolution (SAE) which forms the core of the 3GPP LTE specification.
394
395 vEPC has been integrated in Functest to demonstrate the capability to deploy a
396 complex mobility-specific NFV scenario on the OPNFV platform. The OAI EPC
397 supports most of the essential functions defined by the 3GPP Technical Specs;
398 hence the successful execution of functional tests on the OAI EPC provides a
399 good endorsement of the underlying NFV platform.
400
401 This integration also includes ABot, a Test Orchestration system that enables
402 test scenarios to be defined in high-level DSL. ABot is also deployed as a
403 VM on the OPNFV platform; and this provides an example of the automation
404 driver and the Test VNF being both deployed as separate VNFs on the underlying
405 OPNFV platform.
406
407 The Workflow is as follows:
408  * Deploy Orchestrator
409     Deploy Juju controller using Bootstrap command.
410  * Deploy VNF
411     Deploy ABot orchestrator and OAI EPC as Juju charms.
412     Configuration of ABot and OAI EPC components is handled through
413     built-in Juju relations.
414  * Test VNF
415     Execution of ABot feature files triggered by Juju actions.
416     This executes a suite of LTE signalling tests on the OAI EPC.
417  * Reporting
418     ABot test results are parsed accordingly and pushed to Functest Db.
419
420 Details of the ABot test orchestration tool may be found in `[15]`_
421
422 Kubernetes (K8s)
423 ----------------
424
425 Kubernetes testing relies on sets of tests, which are part of the  Kubernetes
426 source tree, such as the Kubernetes End-to-End (e2e) tests `[16]`_.
427
428 The kubernetes testcases are distributed across various Tiers:
429
430  * Healthcheck Tier
431
432    * k8s_smoke Test Case: Creates a Guestbook application that contains redis
433      server, 2 instances of redis slave, frontend application, frontend service
434      and redis master service and redis slave service. Using frontend service,
435      the test will write an entry into the guestbook application which will
436      store the entry into the backend redis database. Application flow MUST
437      work as expected and the data written MUST be available to read.
438
439  * Smoke Tier
440
441    * k8s_conformance Test Case: Runs a series of k8s e2e tests expected to
442      pass on any Kubernetes cluster. It is a subset of tests necessary to
443      demonstrate conformance grows with each release. Conformance is thus
444      considered versioned, with backwards compatibility guarantees and are
445      designed to be run with no cloud provider configured.
446
447
448 .. _`[2]`: https://docs.openstack.org/tempest/latest/
449 .. _`[3]`: https://rally.readthedocs.io/en/latest/index.html
450 .. _`[5]`: https://github.com/Orange-OpenSource/opnfv-cloudify-clearwater/blob/master/openstack-blueprint.yaml
451 .. _`[8]`: https://github.com/openstack/refstack-client
452 .. _`[9]`: https://github.com/openstack/interop
453 .. _`[10]`: https://github.com/openstack/interop/blob/master/2016.08/procedure.rst
454 .. _`[11]`: http://robotframework.org/
455 .. _`[13]`: https://wiki.opnfv.org/display/PROJ/SNAPS-OO
456 .. _`[14]`: https://github.com/oolorg/opnfv-functest-vrouter
457 .. _`[15]`: https://www.rebaca.com/what-we-do/abot-5g-network-simulator/
458 .. _`[16]`: https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md
459 .. _`[17]`: https://github.com/Metaswitch/clearwater-heat/blob/release-129/clearwater.yaml