Test Execution Notes
This page has notes about aspects of the execution control for different systems that perform test execution.
Here are some of the elements of a the test execution API:
- test API - what functions can the test call?
- file operations
- service operations (start, stop)
- log access
- results output functions
- host/target abstraction - is the test executed from host or directly on target
- DUT preparation/control: - this might be in a separate standard
- kernel installation / provisioning
- console access
- log access
- test activation - how is the test activated or started?
- e.g. installed and activated as part of boot
- e.g. a command is executed as a program?
- e.g. is the test built into the kernel and activated via some trigger mechanism (e.g. via /proc or /sys or an ioctl)?
- test retrieval, build, deployment
- test execution:
- test name, or standard for test invocation name
- ex: 'make test' - a standard make target name?
- runtest.sh? - a standard shell script name?
- <testname>.sh - a standard shell script name, based on test meta-data?
- test phases?
- test selection / skiplists - how are test selected for inclusion or exclusion in a test run
- test variables - how does the test control execution
- make variables
- environment variables
- command line arguments
Does this include test scheduling? (no), but it does include test selection.
Does this include test building (no) - see Test Building notes
- 1 Notes by test system
- 1.1 Fuego
- 1.2 LKFT/Linaro
- 1.3 LAVA
- 1.4 CKI
- 1.5 Yocto Project ptest
- 1.6 kselftest
- 1.7 LTP
- 2 Standards
- 3 board-local test APIs
Notes by test system
- test source location: each test is in it's own directory under fuego-core/tests/<test-name>
- on the target, test materials are placed in $BOARD_TESTIDR/fuego.$TESTDIR
- BOARD_TESTDIR is usually something like: /home/fuego
- TESTDIR is the name of the test: eg. Functional.hello_world
- so the final path is something like: /home/fuego/fuego.Functional.hello_world
test script names
- each test has a script called 'fuego_test.sh'
- this script is run on the host
- often there is a test on the target, which is executed by the test on the host
- there is no convention for the name of the target-side script
- it is referenced inside the host-side 'fuego_test.sh'
Provided by board library: fuego_board_function_lib.sh
Is a library of shell functions.
host-side functions: See http://fuegotest.org/wiki/Test_Script_APIs
Provided in environment variables, prefixed by test name:
- ex: FUNCTIONAL_HELLO_ARGS
Required minimum Linux command set
Tools builtin or on the PATH
- cat, df, find, free, grep, head, logger, logread, mkdir, mount, ps, rm ,rmdir, sync, tail, tee, touch, true, umount, uname, uptime, xargs, [
Required command arguments:
- mkdir -p, rm -rf, grep -f,
Tools at specific paths:
- /sbin/reboot, /bin/true, /sbin/route
- /var/log/messages, /var/log/syslog
- /proc/interrupts, /proc/drop_caches, /proc/oom_score_adj
In test-definitions Linaro tests try to follow LAVA conventions. So there is no specific script naming convention however we try to use <testname>.sh. Sometimes there are more than one script to execute the test. There is additional YAML test description that can be consumed by LAVA to execute tests. This way tests can be executed in LAVA, standalone using script and using test-runner.py from test-definitions. There is nothing that prevents us from renaming all scripts to say 'runtest.sh'. It's just not very high on the priority list.
location of tests
- test source is located in directories under https://github.com/CKI-project/tests-beaker
CKI uses the test invocation mechanism that Beaker uses. This means having a Makefile with a "make run" target (which can call build if needed) that executes the test.
The test file is called runtest.sh, by convention, but it can be any name, as it is referenced by the test's Makefile.
Yocto Project ptest
ptest execution consists of multiple phases:
- compile the tests (as part of a yocto project build
- do a "make install" of the tests to a specific directory
There may be separate make targets for these first two steps or a combined one. It depends on the software and its build system. Sometimes there is no option but to have recipe code move the files around itself.
YP has a test that splits 'make check' into "make buildtest" and "make runtest". The libxml run-ptest script above shows how we'd use runtest on target.
location of tests
- the test source code is contained within the source for each package
- for test binaries, for each piece of software there is a directory with the test materials at:
There is always a single file called 'run-ptest', that is placed into /usr/lib/<name>/ptest
Here are some examples:
A nice simple make invocation: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-core/libxml/libxml2/run-ptest
A not so simple execution of test scripts: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-core/util-linux/util-linux/run-ptest
The YP ptest system has a standalone software project called ptest-runner2:
It looks for and executes the individual run-ptest scripts and processes the output. It finds them as a simple search of /usr/lib/*/ptest/run-ptest.
- test selection via TARGETS make variable
- test skiplist support via SKIP_TARGETS make variable
- patch submitted 9/24/2019 - need to check mainline status - see https://email@example.com/
location of tests
- source of tests is in: <kernel_repository>/tools/testing/selftests/<area>
- test binaries are placed in: $INSTALL_PATH/kselftest
- they are organized by test area, which corresponds to the directory in which they reside in the kernel source repsoitory
test executable names
There is no standard, but the names appear to be obtainable with 'make -s -C tools/testing/selftests/<area> emit_tests'
A script is generated which runs all the test, sourcing 'kselftest/runner.sh' and calling all the test names with the function 'run_many', generating TAP output based on the return code for each test.
- test selection via 'scenario' or 'runtest' files (located in <topdir>/runtest)
- test skiplist support via runltp -S option
- ex: runltp ... -S skiplist.txt ...
- test command line argument control is via the runtest file
- Makefile targets for software testing:
- make test
- make check
If a program uses Makefile to build and install the software under test, then it should provide the following Makefile targets, to support testing of the software.
See https://www.gnu.org/software/make/manual/make.html#Goals (section "9.2 Arguments to Specify the Goals")