...
A test engine and a number of test script is used as a foundation for the test environment. The requirements to
The test environment uses docker images both the Non-RT RIC components as well as for the the needed simulators.
Function test is normally started in "docker-mode" meaning that images will be started as container in a private docker network. As an option, the same test case also executed in a minikube environment. Running in minikube is still in an experimental state so docker should be used as a the standard execution environment.
The basic idea of function test is to run the Non-RT RIC components and test the exposed interfaces using simulators. The test engine and the test scripts controls the behaviour of the simulators but also use the exposed interfaces for test and monitoring.
The test scripts are designed in a way so that the same script can be used for testing of the functionality in the master branch as well as previous release(s). The supported branches/releases are indicated by the existence of a environment variable file in the test/common dir with the name of the branch. The environment for master has the name of coming release.
The majority of the test scripts test one or several aspects of the functionality but there is also test scripts for stability tests over longer period of time (currently 3 days max intensity test).
...
The picture below shows the setup used for function tests. Non-RT RIC components in orange, simulators in light blue and the test environment in dark blue. The purple arrow is outside the scope of the test but is used for demo test scripts.
Test scripts/Test cases
...
- Bash shell
- docker (latest)
- docker-compose (latest)
- python3 (latest)
- minikube (latest) - only needed when running in kubernetes mode
The test engine as well as all available test scripts is available in the nonrtric repo. Clone the repo and go to the auto-test directory:
...
Start the appropriate test script with the command below. No further action is required. The tests are fully automated. Once the execution is completed a test report is printed.
Example, run images from the staging repor. To run only release images, add the parameter 'release' after the 'docker' parameter.
| Code Block | ||
|---|---|---|
| ||
$ ./FTC100.sh remote docker --env-file ../common/test_env-oran-master.sh |
For further information and details, see README in the dirs 'auto-test' and 'common'.
Tested image versions
| Component | image (release repo) | tag | profile (release) |
|---|---|---|---|
| Policy Management Service |
10002/o-ran-sc/nonrtric-policy-agent | 2.1. |
| 1 |
| cherry | |
| A1-controller |
10002/o-ran-sc/nonrtric-a1-controller | 2.0.1 |
| cherry | |
| Enrichment Coordinator Service |
| nexus3.o-ran-sc.org: |
| 10002/o-ran-sc/nonrtric-enrichment-coordinator-service | 1.0. |
| 1 |
| cherry | |
| Control Panel |
10002/o-ran-sc/nonrtric-controlpanel | 2. |
| 1.0 |
| cherry | |
| A1-Simulator |
10002/o-ran-sc/a1-simulator | 2.1.0 | cherry |
| R-APP Catalogue | nexus3.o-ran-sc.org:10002/o-ran-sc/nonrtric-r-app-catalogue | 1.0.1 |
| cherry |
"profile" refers to the name of the environment variable profile used when executed a test case. There is always a profile for "master" which is the lastest available version and then a profile for each release.Currently (nov 2020) the master profile targets the Cherry releaseThe profiles has the pattern 'test_env-oran<profile-name>.sh in the test/common dir.