Project

General

Profile

Titan TTCN3 Testsuites » History » Version 42

pespin, 11/15/2019 03:50 PM

1 1 laforge
h1. Osmocom Titan TTCN3 Testsuites
2 36 fixeria
3
{{>toc}}
4 1 laforge
5 14 osmith
In 2017, Osmocom started to create extensive tests suites for the Cellular Network Infrastructure elements.  Those suites are written in the [[TTCN-3]] programming language and use the compiler and executor of the [[Eclipse_TITAN]] project. There are special cases, but in general, the idea is to test one component (e.g. @osmo-mgw@) independently.
6 2 laforge
7 40 Hoernchen
h2. Development
8
9
See [[Titan_TTCN3_Notes]]
10
11 2 laforge
h2. Source Code / Patches
12
13
The source code of our test suites lives in the @osmo-ttcn3-hacks@ repository
14
* cgit web interface: http://git.osmocom.org/osmo-ttcn3-hacks/
15
* clone: @git clone git://git.osmocom.org/osmo-ttcn3-hacks@
16
* patch review: https://gerrit.osmocom.org/#/q/project:osmo-ttcn3-hacks
17
18
We're following the [[Gerrit]] process for patch review.
19
20 32 laforge
h2. Proprietary APER<->BER transcoding library for Iu tests
21
22
As TITAN can only generate and parse ASN.1 BER encoding, but the Iu-CS, Iu-PS and Iuh interfaces are using APER encoding, sysmocom is providing a proprietary transcoding library called libfftranscode.  Debian9 amd64 packages are available from https://ftp.osmocom.org/binaries/libfftranscode/
23
24
We don't like to depend on proprietary software, but given that there is no FOSS ASN.1 compiler that can parse all ASN.1 constructs of the RANAP/RUA/HNBAP specs *and* parse + generate both BER and APER, this is the lesser evil.  Note that the dependency to this proprietary library is only required for the TTCN3 test suite and not a runtime dependency of any of the Osmocom programs itself.
25
26 2 laforge
h2. Test Suites
27
28
|_.Implementation under Test|_.Testsuite|_.Jenkins|
29 41 daniel
|[[OsmoBSCNAT:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/bsc-nat|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bscnat-test/|
30 2 laforge
|[[OsmoBSC:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/bsc|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/|
31
|[[OsmoBTS:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/bts|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/|
32
|[[OpenGGSN:OsmoGGSN]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/ggsn_tests|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test/|
33
|[[OsmoHLR:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/hlr|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hlr-test/|
34
|[[OsmoMGW:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/mgw|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-mgw-test/|
35
|[[OsmoMSC:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/msc|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/|
36 41 daniel
|[[OsmoPCU:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/pcu|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pcu-test/, https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pcu-test-sns/|
37 2 laforge
|[[OsmoSGSN:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/sgsn|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sgsn-test/|
38
|[[osmo-sip-connector:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/sip|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/|
39 42 pespin
|[[osmoSTP:]]|http://git.osmocom.org/osmo-ttcn3-hacks/tree/stp|https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-stp-test/|
40 2 laforge
41
h2. Running a testsuite
42
43
You have multiple options on how to execute a test suite.
44
45
h3. Running test suite in the dockerized environment
46 1 laforge
47 4 osmith
This is the much easier way to run the test suite.  No manual configuration of Osmocom programs or the test suite are required.  Both the Osmocom program (Implementation Under Test) as well as the test suite are packaged as docker containers, which are then executed next to each other using a docker network with the "right" addresses between IUT and testsuite.
48 2 laforge
49
Also, using this setup you will be guaranteed to run in the exact same environment as the automatically-executed tests on jenkins.osmocom.org, i.e. your results should be exactly identical, without any differences introduced by your runtime environment, whether specific library versions or intentional or inadvertent configuration differences.
50
51 10 osmith
h4. Installing docker
52 1 laforge
53 10 osmith
Make sure you have "*docker-ce*":https://docs.docker.com/install/#supported-platforms installed (not to be confused with the possibly outdated version that may be shipped in your distribution's repositories). Check that the version string contains <code>-ce</code> as follows:
54
55
<pre>
56
$ docker -v
57
Docker version 18.06.1-ce, build e68fc7a
58
</pre>
59
60
61 11 osmith
Next, add yourself to the <code>docker</code> group, log off and on again, and verify that you can use docker with your user:
62 10 osmith
63
<pre>
64
$ docker info
65
</pre>
66
67
h4. Cloning docker-playground
68
69 12 osmith
Osmocom related containers are stored in the "@docker-playground@":https://git.osmocom.org/docker-playground/ git repository.
70 5 osmith
71
<pre>
72
$ git clone git://git.osmocom.org/docker-playground
73
$ cd docker-playground
74 1 laforge
</pre>
75 6 osmith
76 1 laforge
h4. Running a testsuite
77
78 38 osmith
All testsuite directories start with @ttcn3@ or @nplab@. Run the following to build/update all required containers and start a specific testsuite:
79 24 osmith
80 1 laforge
<pre>
81 24 osmith
$ cd ttcn3-mgw-test
82
$ ./jenkins.sh
83 1 laforge
</pre>
84
85 24 osmith
Environment variables:
86
* @IMAGE_SUFFIX@: the version of the Osmocom stack to run the testsuite against. Default is `master`, set this to `latest` to test the last stable releases.
87 29 osmith
* @OSMO_TTCN3_BRANCH@: "osmo-ttcn3-hacks.git":https://git.osmocom.org/osmo-ttcn3-hacks/ branch, which will be used when building a `ttcn3-*` docker image. Defaults to `master`.
88 33 osmith
* @OSMO_BSC_BRANCH@, @OSMO_MSC_BRANCH@, ...: branch of the appropriate Osmocom project. Defaults to `master`.
89 24 osmith
* @NO_DOCKER_IMAGE_BUILD@: when set to @1@, it won't try to update the containers (see "README.md":https://git.osmocom.org/docker-playground/tree/README.md)
90 33 osmith
91 24 osmith
92 6 osmith
The @jenkins.sh@ script will make sure to
93 24 osmith
* create the needed docker network(s)
94 6 osmith
* run all the required containers (IUT, helpers, testsuite)
95
* shut them down after test suite execution
96
* collect the log files after execution, @/tmp/logs@ will contain them
97
98 2 laforge
h4. Running only a sub-set of the test cases
99
100 20 osmith
See running the testsuite outside of Docker for reference (below).
101
102 28 osmith
h3. Running it natively on your machine
103 2 laforge
104
This is the most complicated bit to set-up, as you will have to run the respective Osmocom Program (Implementation Under Test) in the right configuration with all the IP addresses, port numbers, config file, etc. exactly like it's expected by the test suite.
105 1 laforge
106 14 osmith
You will need a deeper understanding about how the test suite works, and what its requirement are. Oftentimes looking at how it's done in the Docker scripts is helpful.
107
108
h4. Preparation
109
110 34 Hoernchen
As stated [[Titan_TTCN3_Testsuites##Proprietary-APERBER-transcoding-library-for-Iu-tests|above]] certain parts of the testsuite require libfftranscode! If the build fails this might be the issue.
111 35 laforge
112
While you can try to use any version of Eclipse TITAN, for the best possible experience it's a good idea to use the same version as Osmocom uses in the dockerized environment.  As can be seen in the "Dockerfile":http://git.osmocom.org/docker-playground/tree/debian-stretch-titan/Dockerfile, this (currently) points to the eclipse-titan package from the [[Latest_Builds]] on Debian 9.0":.
113
114 14 osmith
<pre>
115
$ apt install eclipse-titan
116
$ git clone git://osmocom.org/osmo-ttcn3-hacks
117
$ cd osmo-ttc3-hacks/deps
118
$ make
119
</pre>
120
121
h4. Compile a testsuite
122
123
Let's compile the @mgw@ testsuite for example:
124
125
<pre>
126
$ cd mgw
127
$ ./gen_links.sh
128 26 msuraev
$ ./regen_makefile.sh
129 14 osmith
</pre>
130 1 laforge
131 23 osmith
The next command will transform the TTCN3 test data into C++ code. Do not use @-j@ here, that won't work (and it is pretty fast anyway).
132 14 osmith
<pre>
133
$ make compile
134
</pre>
135
136 27 msuraev
Note: if you observe errors during @make compile@, try running it from top-level as @make mgw@ which should trigger dependency update.
137
138 14 osmith
Finally compile the testsuite:
139
<pre>
140
$ make -j5
141
</pre>
142 27 msuraev
143 14 osmith
h4. Run a testsuite
144
145 37 osmith
Start the component that is about to get tested with the config that the testsuite expects. Again, with @mgw@ as example. A suitable config file should be in the same directory of osmo-ttcn3-hacks.git (otherwise one can use "the one from Jenkins":https://git.osmocom.org/docker-playground/tree/ttcn3-mgw-test/osmo-mgw.cfg and replace all IPs with @127.0.0.1@).
146 14 osmith
<pre>
147 21 osmith
$ osmo-mgw -c osmo-mgw.cfg
148 14 osmith
</pre>
149
150
Then run the testsuite:
151
<pre>
152
$ cd osmo-ttcn3-hacks/mgw
153
$ ../start-testsuite.sh ./MGCP_test MGCP_Test.cfg
154
</pre>
155
156
Afterwards you can merge and format the logs as follows:
157
<pre>
158
$ ttcn3_logmerge MGCP_test*.log > ./merged.log
159 1 laforge
$ ttcn3_logformat ./merged.log > ./result.log
160 30 msuraev
</pre>
161
or
162
<pre>
163 31 msuraev
$ ../log_merge.sh MGCP_test
164 1 laforge
</pre>
165 37 osmith
166
Depending on the component that you want to test, you may need to run multiple Osmocom programs. For OsmoMSC, you would run osmo-msc and osmo-stp for example. See the containers that "jenkins.sh":https://git.osmocom.org/docker-playground/tree/ttcn3-msc-test/jenkins.sh is running for reference.
167 2 laforge
168
h4. Running only a sub-set of the test cases
169
170 38 osmith
Running whole testsuites may take a long time. If you only want to run one specific test, or a subset of tests, open up the @_*Test.cfg@ file in the directory of the testsuite and edit the @[EXECUTE]@ section. For example, in "@MGCP_Test.cfg@":https://git.osmocom.org/osmo-ttcn3-hacks/tree/mgw/MGCP_Test.cfg from the @mgw@ directory it looks like the following: 
171 16 osmith
172
<pre>
173 1 laforge
...
174 17 osmith
[EXECUTE]
175
MGCP_Test.control
176
#MGCP_Test.TC_selftest
177
#MGCP_Test.TC_crcx
178
#MGCP_Test.TC_crcx_noprefix
179
...
180
</pre>
181 1 laforge
182 17 osmith
The only line that is *not* commented out is @MGCP_Test.control@. This @*.control@ line will cause all tests to be executed. So comment this line out, and then activate one of the lines of which you would like to execute the tests (see the example below). Then execute the testsuite as usually, and it will skip all commented out tests.
183
184
<pre>
185
...
186
[EXECUTE]
187
#MGCP_Test.control
188
#MGCP_Test.TC_selftest
189
MGCP_Test.TC_crcx
190
MGCP_Test.TC_crcx_noprefix
191
...
192 16 osmith
</pre>
193 2 laforge
194 15 osmith
h2. Reading the logs
195
196
* @xfail@ means, that a test is known to fail, @FAIL@ are unexpected test failures
197
* search for @setverdict(@ to find the results of single tests. @-> fail@ should be the location where a test is failing.
198
199 2 laforge
h2. Further information
200
201 22 osmith
* April 2018 talk by Harald on "State of the Osmocom TTCN-3 Test Suites":https://media.ccc.de/v/UGHHW3
202 39 osmith
* "Patch for colormake to colorize the ttcn3 compiler output":https://github.com/osmith42/Colormake/tree/osmith/ttcn3
Add picture from clipboard (Maximum size: 48.8 MB)