Contents |
Conductor is the executer in the ots-worker. You can use conductor to test device flashing and for semi-automatic test executions.
To test flashing and basic test execution:
conductor --imageurl=http://192.168.1.1/image.tar.gz
The conductor flasher the image to the device and executes all available test packages.
To list all supported options:
conductor --help
Note: Before starting to execute tests with ots_trigger, verify that your ots-worker is configured correctly. That can be done with conductor, see the topic above.
OTS trigger is tool for triggering a testrun to OTS server.
Before you can trigger a testrun, you need to have all following:
And one of the following options:
Okey, now we are ready to get dirty.
If we have test package(s) installed into the device and we want to execute all of them:
ots_trigger --server=192.168.1.1/xmlrpc --build_id=nightly_testing --image=http://url.to.image/image.tar.gz --sw_product=meego_n900 \ --email=my.name@company.com
Let me explain the parameters.
That was simple. Next you want to execute only one package, no problem, just define test package name to OTS trigger:
ots_trigger --server=192.168.1.1/xmlrpc --build_id=nightly_testing --image=http://url.to.image/image.tar.gz --sw_product=meego_n900 \ --email=my.name@company.com --testpackages=my-test-package1-tests
In to the testpackages option, you can define multiple packages like this:
--testpackages=my-test-package1-tests,my-test-package2-tests
If you want to add more people to receive email after the execution is done, just add more email addresses to --email option:
ots_trigger --server=192.168.1.1/xmlrpc --build_id=nightly_testing --image=http://url.to.image/image.tar.gz --sw_product=meego_n900 \ --email=my.name@company.com,second.name@company.com
If you have test package installed to your ots-worker machine, that can be executed with --hostpackages:
ots_trigger --server=192.168.1.1/xmlrpc --build_id=nightly_testing --image=http://url.to.image/image.tar.gz --sw_product=meego_n900 \ --email=my.name@company.com --hostpackages=my-test-package1-tests
For optimizing the execution time, see distribution models section below.
To list all supported options:
ots_trigger --help
Test plan based execution means that the user can create a test plan and give it directly to ots_trigger without making any test package. This brings benefits when executing different test against the same test image or release.
The user can create the test plan with Testplanner.
And then give the test plan to ots_trigger with --deviceplan or --hostplan. Difference between these options are that 'deviceplan' is executed in the device and 'hostplan' in the ots-worker.
ots_trigger --server=192.168.1.1/xmlrpc --build_id=nightly_testing --image=http://url.to.image/image.tar.gz --sw_product=meego_n900 \ --email=my.name@company.com --deviceplan=/path/to/my/test_plan.xml
These are models how the OTS is distributing test executions to ots-workers. There are 2 build-in models and other ones are distribution model plug-ins.
Distribution model can be specified to ots_trigger with --distribution option.
This is the default model, if nothing else has been specified.
Default model executes all test packages in a single task, so only one ots-worker will handle the test execution. Only exception to this model is test plan based executions, they are always executed as an own task and therefor distributed to multiple workers.
---distribution=perpackage
Perpackage is the second build-in distribution model.
This models creates always an own task for each test package and test plan, so multiple ots-worker can handle the testrun at the same time.
---distribution=optimized
Optimized is a distribution plug-in and it is part of history plug-in.
History plug-in collects test package execution times to a database. When the user triggers a testrun, he/she can specify how long the execution should take and how many device can be used. The optimized model then tries to optimize the execution time to fit the user's requirements.
See how to use the optimized plug-in from the plug-in subpage.
Chroot functionality makes possible to use chroot environment with specific software to run the tests. This way a test case which needs specific software can be started at any OTS worker and a worker will stay clean of additional software. Chroot based testing is primarily targeted at executing tests with the Testability Driver framework.
Basically you can use any i386 chroot environment you like, but MeeGo Netbook edition is good starting point. First create an image with all packages you need for testing and then unpack and compress it to a tar.gz package:
mic-chroot --unpack-only –save-to=<chroot_directory> <image> cd <chroot_directory> tar -Pczf ../rootstrap.tar.gz .
Now you have a rootstrap ready in rootstrap.tar.gz file.
To trigger a chroot test you need to give two arguments for OTS trigger:
Example like this:
ots_trigger --server=192.168.1.1/xmlrpc --build_id=nightly_testing --image=http://url.to.image/image.tar.gz --sw_product=meego_n900 \ --chrootpackages=mwts-filesystem --rootstrap=http://url.to.rootstrap/rootstrap.tar.gz --email=my.name@company.com