aboutsummaryrefslogtreecommitdiffstats
path: root/docs/userguide/testcase_description_v2_template.rst
blob: 91c2a7e33d991baa37a97fdd342afbc63cb7f734 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
.. This work is licensed under a Creative Commons Attribution 4.0 International
.. License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) OPNFV, Ericsson AB and others.

*************************************
Yardstick Test Case Description TCXXX
*************************************

+-----------------------------------------------------------------------------+
|test case slogan e.g. Network Latency                                        |
|                                                                             |
+--------------+--------------------------------------------------------------+
|test case id  | e.g. OPNFV_YARDSTICK_TC001_NW Latency                        |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|metric        | what will be measured, e.g. latency                          |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|test purpose  | describe what is the purpose of the test case                |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|configuration | what .yaml file to use, state SLA if applicable, state       |
|              | test duration, list and describe the scenario options used in|
|              | this TC and also list the options using default values.      |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|test tool     | e.g. ping                                                    |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|references    | e.g. RFCxxx, ETSI-NFVyyy                                     |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|applicability | describe variations of the test case which can be            |
|              | performend, e.g. run the test for different packet sizes     |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|pre-test      | describe configuration in the tool(s) used to perform        |
|conditions    | the measurements (e.g. fio, pktgen), POD-specific            |
|              | configuration required to enable running the test            |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|test sequence | description and expected result                              |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|step 1        | use this to describe tests that require sveveral steps e.g   |
|              | collect logs.                                                |
|              |                                                              |
|              | Result: what happens in this step e.g. logs collected        |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|step 2        | remove interface                                             |
|              |                                                              |
|              | Result: interface down.                                      |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|step N        | what is done in step N                                       |
|              |                                                              |
|              | Result: what happens                                         |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|test verdict  | expected behavior, or SLA, pass/fail criteria                |
|              |                                                              |
+--------------+--------------------------------------------------------------+
rd test requirements. | | | | | | (Pktgen is not always part of a Linux distribution, hence it | | | needs to be installed. It is part of the Yardstick Docker | | | image. | | | As an example see the /yardstick/tools/ directory for how | | | to generate a Linux image with pktgen included.) | | | | +--------------+--------------------------------------------------------------+ |test | This test case uses Pktgen to generate packet flow between | |description | two hosts for simulating network workloads on the SUT. | | | | +--------------+--------------------------------------------------------------+ |traffic | An IP table is setup on server to monitor for received | |profile | packets. | | | | +--------------+--------------------------------------------------------------+ |configuration | file: opnfv_yardstick_tc001.yaml | | | | | | Packet size is set to 60 bytes. | | | Number of ports: 10, 50, 100, 500 and 1000, where each | | | runs for 20 seconds. The whole sequence is run twice | | | The client and server are distributed on different hardware. | | | | | | For SLA max_ppm is set to 1000. The amount of configured | | | ports map to between 110 up to 1001000 flows, respectively. | | | | +--------------+--------------------------------------------------------------+ |applicability | Test can be configured with different: | | | | | | * packet sizes; | | | * amount of flows; | | | * test duration. | | | | | | Default values exist. | | | | | | SLA (optional): max_ppm: The number of packets per million | | | packets sent that are acceptable to loose, not received. | | | | +--------------+--------------------------------------------------------------+ |usability | This test case is used for generating high network | | | throughput to simulate certain workloads on the SUT. Hence | | | it should work with other test cases. | | | | +--------------+--------------------------------------------------------------+ |references | pktgen_ | | | | | | ETSI-NFV-TST001 | | | | +--------------+--------------------------------------------------------------+ |pre-test | The test case image needs to be installed into Glance | |conditions | with pktgen included in it. | | | | | | No POD specific requirements have been identified. | | | | +--------------+--------------------------------------------------------------+ |test sequence | description and expected result | | | | +--------------+--------------------------------------------------------------+ |step 1 | Two host VMs are booted, as server and client. | | | | +--------------+--------------------------------------------------------------+ |step 2 | Yardstick is connected with the server VM by using ssh. | | | 'pktgen_benchmark' bash script is copyied from Jump Host to | | | the server VM via the ssh tunnel. | | | | +--------------+--------------------------------------------------------------+ |step 3 | An IP table is setup on server to monitor for received | | | packets. | | | | +--------------+--------------------------------------------------------------+ |step 4 | pktgen is invoked to generate packet flow between two server | | | and client for simulating network workloads on the SUT. | | | Results are processed and checked against the SLA. Logs are | | | produced and stored. | | | | | | Result: Logs are stored. | | | | +--------------+--------------------------------------------------------------+ |step 5 | Two host VMs are deleted. | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | | | | +--------------+--------------------------------------------------------------+