Latest revision as of 13:21, 16 December 2011

OTS Usage

Test execution

Using conductor

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

Using OTS trigger

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.

How to install OTS trigger.

Before you can trigger a testrun, you need to have all following:

• OTS server up-and-running [1]
• OTS worker with hardware configured [2]
• Image with eat-device package (enabled test automation environment to hardware) [3]

And one of the following options:

• Test package installed to the device
• Test package installed to the ots-worker or
• Test plan Test plan based executions

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.

• server: Defines the address of the OTS server. If you are not using logger plug-in, the address is then 192.168.1.1:8080.
• build_id: Free string to define the image build id.
• image: Url path where the image is located. Yes, it must be on the http server.
• sw_product: The default SW test execution options, you have defined the sw_product in /etc/ots/server.conf.
• email: Who has requested the testrun and to whom to send notifications.

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 executions

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.

You can find simple examples of testplans in System test data

Test plan can be also created 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

Distribution models

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.

Default

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.

Perpackage

---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.

Optimized

---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.

Running tests in chroot environment

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.

How to create rootstrap?

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.

Triggering a chroot test

To trigger a chroot test you need to give two arguments for OTS trigger:

• --chrootpackages=<test_packages>
  • Test packages to be executed on chroot environment
• --rootstrap=<rootstrap_file>
  • The rootstrap URL

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