MeeGo wiki - User contributions [en]

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-08-30T13:32:14Z

Eluttine: /* 0.8.8 - 0.8.9 */

= Upgrading OTS =

== 0.8.8 - 0.8.9 ==
Upgrade to meego-ai-flasher 0.1.8, older versions doesn't work with OTS 0.8.9.

== 0.8.7 - 0.8.8 ==
New conductor configuration parameter 'target_username'. Add it to existing conductor configuration files (/etc/ots/conductor.conf and /etc/ots/conductor_*.conf) or replace old file(s) with new one.

== 0.8.6 - 0.8.7 ==
Locations and names of configuration files have been changed. All configuration files are now located in /etc/ots and the plugin configuration files are in /etc/ots/plugins.

If you wish to keep your old settings you have to replace the new files.
On the server side:
sudo mv /etc/ots_server.ini /etc/ots/server.conf
sudo mv /etc/ots_plugin_qareports.conf /etc/ots/plugins/qareports.conf
And email plugin has it's own configuration file so you should move the [ots.email_plugin] section from the old /etc/ots_server.ini file to /etc/ots/plugins/email.conf.

On the worker side:
sudo mv /etc/ots.ini /etc/ots/worker.conf
sudo mv /etc/conductor.conf /etc/ots/conductor.conf
sudo mv /etc/ots_plugin_conductor_richcore.conf /etc/ots/plugins/conductor_richcore.conf

== 0.8.5 - 0.8.6 ==
Backup all configuration files and database before upgrading.

If you have logger plugin installed update the templates by giving following commands after upgrade:
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/

Upgrade also the latest meego-ai-flasher.

=== Updating the database ===

If you want to keep your old log database, add new (user_defined_id) column to the log_messages table. Run database command line interface for OTS database. By default OTS uses sqlite database at /opt/ots/ots.sqlite.
sudo sqlite3 /opt/ots/ots.sqlite
Add new column to the log_messages table by executing following command:
ALTER TABLE log_messages ADD COLUMN user_defined_id varchar(255) NOT NULL DEFAULT <nowiki>''</nowiki>;

If there's no need to keep the old database you can remove the database file (/opt/ots/ots.sqlite) and generate a new one using [[Quality/QA-tools/OTS/Plugins/Django#Create.2Fupdate_databases|the instructions]].

== 0.8.4 - 0.8.5 ==
* Rich-core conductor plug-in available
** Changes to /etc/conductor.conf
** New configuration file for plug-in: /etc/ots_plugin_conductor_richcore.conf

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-08-30T13:31:38Z

Eluttine: /* Upgrading OTS */

= Upgrading OTS =

== 0.8.8 - 0.8.9 ==
Remember to install meego-ai-flasher 0.1.8. Older versions doesn't work with OTS 0.8.9.

== 0.8.7 - 0.8.8 ==
New conductor configuration parameter 'target_username'. Add it to existing conductor configuration files (/etc/ots/conductor.conf and /etc/ots/conductor_*.conf) or replace old file(s) with new one.

== 0.8.6 - 0.8.7 ==
Locations and names of configuration files have been changed. All configuration files are now located in /etc/ots and the plugin configuration files are in /etc/ots/plugins.

If you wish to keep your old settings you have to replace the new files.
On the server side:
sudo mv /etc/ots_server.ini /etc/ots/server.conf
sudo mv /etc/ots_plugin_qareports.conf /etc/ots/plugins/qareports.conf
And email plugin has it's own configuration file so you should move the [ots.email_plugin] section from the old /etc/ots_server.ini file to /etc/ots/plugins/email.conf.

On the worker side:
sudo mv /etc/ots.ini /etc/ots/worker.conf
sudo mv /etc/conductor.conf /etc/ots/conductor.conf
sudo mv /etc/ots_plugin_conductor_richcore.conf /etc/ots/plugins/conductor_richcore.conf

== 0.8.5 - 0.8.6 ==
Backup all configuration files and database before upgrading.

If you have logger plugin installed update the templates by giving following commands after upgrade:
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/

Upgrade also the latest meego-ai-flasher.

=== Updating the database ===

If you want to keep your old log database, add new (user_defined_id) column to the log_messages table. Run database command line interface for OTS database. By default OTS uses sqlite database at /opt/ots/ots.sqlite.
sudo sqlite3 /opt/ots/ots.sqlite
Add new column to the log_messages table by executing following command:
ALTER TABLE log_messages ADD COLUMN user_defined_id varchar(255) NOT NULL DEFAULT <nowiki>''</nowiki>;

If there's no need to keep the old database you can remove the database file (/opt/ots/ots.sqlite) and generate a new one using [[Quality/QA-tools/OTS/Plugins/Django#Create.2Fupdate_databases|the instructions]].

== 0.8.4 - 0.8.5 ==
* Rich-core conductor plug-in available
** Changes to /etc/conductor.conf
** New configuration file for plug-in: /etc/ots_plugin_conductor_richcore.conf

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS/DeveloperDocs

2011-08-24T12:09:37Z

Eluttine: /* OTS - Open Testing Service */

= OTS - Open Test System =

== Related Documentation ==

* [[Quality/QA-tools/OTS/DevelopmentGuidelines | Development Guidelines]]
* [[Quality/QA-tools/OTS/Packages | Packages]]
* [[Quality/QA-tools/OTS/ErrorCodes | Error Codes]]
* [[Quality/QA-tools/OTS/Glossary]]
* [[Quality/QA-tools/OTS/DeveloperDocs/Transition0.1-0.8|Making transition from 0.1 to 0.8]]

== Synopsis ==

OTS is a Distributed Test System that takes a Data Driven Approach using XML Files to allow parallel testing of Applications on evolving Hardware platforms.

Design has been driven by the need for a language neutral test platform that allows testing under different device architectures in parallel.

== High Level Overview ==

OTS allows a Test Sequence to be fanned out from a hub known as a '''Distributor''' to a remote machine known as a '''Worker'''.
Each '''Worker''' has a '''Device Group''' associated with it, this is defined in the configuration. The Tests are routed to the '''Worker'''
on the basis of the '''Device Group'''.

An XML '''Test Definition File''' describes the Tests that are run. The results are returned to the '''Distributor''' in an XML '''Results File'''.

The '''Distributor''' takes a '''Device Group''' and '''Timeout''' as inputs, as well as the '''Command''' for running '''Tasks'''. Tests are run within a '''Task''' which
is currently run as a process. The '''Command''' will typically take a path to the '''Test Definition File''' as an input.
If the process exceeds the '''Timeout''' the '''Task''' is stopped (the process is killed).

A number of '''Tasks''' can be added to a '''Testrun'''. The '''Testrun''' will normally wait for all '''Tasks''' to finish before completion.

Data (status, error and results) are communicated back from the '''Task''' to the '''Worker'''. The '''Results Object''' is a container for the files outputted: '''Test Definition File''', '''Results File'''
and any other files produced by the test as well as metadata relating to the run.

== Technology ==

OTS is written in [http://www.python.org/ Python 2.6].

[http://www.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protocol AMQP] protocol is used for communication.

=== XmlFileFormats ===

The XML file formats provide the datum for the system.

Download [http://meego.gitorious.org/meego-quality-assurance/test-definition/trees/master them] and add the path to the '''results_xsd''' parameter in your [http://meego.gitorious.org/meego-quality-assurance/ots/blobs/master/ots.server/ots/server/server.conf server.conf] file

=== Third Party Dependencies ===

==== RabbitMQ ====

You need to install [http://www.rabbitmq.com/server.html RabbitMQ], this is AMQP message server.

===== Managing the Queues =====

If you need to delete or empty the queues there are [http://meego.gitorious.org/meego-quality-assurance/ots/trees/master/ots.server/ots/server/distributor/dev_utils utilities] to help with this.

==== Python Packages ====

The following python packages are needed

* [http://pypi.python.org/pypi/setuptools setuptools]

* [http://www.voidspace.org.uk/python/configobj.html configobj]

* [http://pypi.python.org/pypi/multiprocessing multiprocessing]

* [http://code.google.com/p/py-amqplib/ pyamqplib] (version 0.6.1 or newer)

* [http://www.familieleuthe.de/DownloadMiniXsv.html minixsv]

* [http://www.djangoproject.com/download/1.1.2/tarball/ django]

* [http://code.google.com/p/python-nose/ nose]

== Diving In ==

The following steps show how to get a Development Environment up and running

=== 1. Install Dependencies ===

* Install the Third Party Dependencies

* Get the XML File Formats and set the OTS_TESTDEFINITION environment variable

=== 2. Build the Eggs ===

From the root directory

<code>
./setup.sh
source ./paths.sh
</code>

=== 3. Unittests ===

Run the unittests from the root directory

<code>
./nose.sh
</code>

=== 4. Component Tests ===

Component Tests run high level tests on an OTS Component using Mocks of the dependencies.

You can run these with the component_tests shell script in the root directory.

<code>
./component_tests.sh
</code>

=== 5. Hello OTS World ===

The source contains a simple demonstration of the way the key elements work.

==== 1. Open two terminal windows. ====

==== 2. In the first window run the server ====

<code>
cd $SERVER
cd hub/demos
python demo_hub.py
</code>

==== 3. You should see this: ====

<code>
<snip>
20XX-XX-XX XX:XX:XX,XXX - ots.server.distributor.taskrunner - DEBUG - Sending command '['echo', 'hello world']' with key 'foo'
</code>

==== 4. In the second window run the worker ====

<code>
cd $WORKER
python worker.py -c config.ini
</code>

==== 5. Now in the Server terminal the command should run to completion. You should see the following line in the logs: ====

<code>
20XX-XX-XX XX:XX:XX,XXX - ots.worker.command - DEBUG - process.communicate() returned echo hello world
</code>

It will raise a PackageException. This is normal as no Tasks that are run return Packages to the Server

==== 6. And on the logs on the Worker side should contain: ====

<code>
XXXX-XX-XX XX:XX:XX,XXX - ots.worker.command - DEBUG - process.communicate() returned echo hello world
XXXX-XX-XX XX:XX:XX,XXX - ots.worker.task_broker - DEBUG - Task in state: 'finish'
XXXX-XX-XX XX:XX:XX,XXX - ots.worker.task_broker - INFO - Recommence consume on queue: foo
</code>

== Installation ==

It is intended that the '''Distributor''' and each '''Worker''' should be installed to separate machines.

== Configuration ==

=== Distributor ===

The format of the configuration file is as follows.

The `host` is the name of the RabbitMQ server

<code>

[Client]
host = localhost
vhost = /
port = 5672
username = guest
password = guest
queue = FIXME
consumer_tag = worker
services_exchange = services

</code>

=== Worker ===

Edit your config.ini so that the

* `queue`
* `routing_key`
* `services_exchange`

Are set for your '''Device Group'''.

And the `host` is the name of your RabbitMQ server.

<code>
[Worker]
host = localhost
vhost = /
port = 5672
username = guest
password = guest
queue = foo
routing_key = foo
services_exchange = foo
</code>

==== Starting the Worker ====

To start your Worker:

<code>
python worker.py -c config.ini
</code>

== Automated System Tests ==

Automated system tests are available in ots.system_tests. They trigger various testruns with xmlrpc and check return value and log messages.

=== Requirements ===

* Fully functional OTS system with one worker.
* A SW Product "ots-system-tests" configured so that it defaults to the worker.
* A meego image with test-definition-tests and testrunner-lite-regression-tests.
* Django based advanced OTS setup.
* BeautifulSoup python library.

=== Configuration ===

* make the system test image available for the workers. (for example copy it to your apache static content directory /var/www/static/)
* Modify system_tests.conf in ots.system_tests directory to match your system.
* Make sure all the urls in system_tests.conf work.

=== Notes ===

* System tests execute multiple full testruns. Running all tests can easily take more than 1.5 hours with N900 worker.
* Make sure there's no other activities ongoing in the system while running the tests.
* Some error handling tests expect certain devicegroups and sw products _not_ to be available. If these test cases fail you can remove those queues with ots tools.

== License ==

OTS is distributed under an LGPL license.

== Contributions ==

OTS welcomes contributions.

The following areas would benefit greatly from your help:

* Adding to the list of freely available Publisher Plugins
* Examples of OTS in use with different hardware architectures
* Improving the ease of deployment

Please check out the [[Quality/QA-tools/OTS/DevelopmentGuidelines | Guidelines]] and [[Quality/QA-tools/OTS/DevelopmentGuidelines/Review | Review process]].

== Wiki ==

[[Quality/QA-tools/OTS | OTS Wiki Home]]

== Source Code Documentation ==

OTS docstrings are in [http://epydoc.sourceforge.net/manual-epytext.html epytext] format which enables the use of [http://epydoc.sourceforge.net/index.html epydoc] in API documentation generation.

== Mailing List ==

[http://lists.meego.com/listinfo/meego-qa MeeGo QA] mailing list

== IRC Channel ==

The #meego-qa irc channel in freenode

== Bugs ==

The [http://bugs.meego.com/ Meego bugs page]

== Platform Dependencies ==

OTS is tested to run on Linux only.

Tested on Ubuntu (8.04, 10.04, 10.10), Fedora 13, MeeGo and Redhat.

Binary support for Ubuntu, Fedora and MeeGo.

== Architecture ==

* [[Quality/QA-tools/OTS/DeveloperDocs/Components | Components]]

* [[Quality/QA-tools/OTS/DeveloperDocs/Server | Server]]

* [[Quality/QA-tools/OTS/DeveloperDocs/Plugins | Plugins]]

* [[Quality/QA-tools/OTS/DeveloperDocs/DataFlow | DataFlow]]

* [[Quality/QA-tools/OTS/DeveloperDocs/Behaviour | Behaviour]]

== APIs ==

==== Server ====

The top level [http://meego.gitorious.org/meego-quality-assurance/ots/blobs/dev_branch_0.8/ots.server/ots/server/hub/api.py api] for external clients utilises parameters in a dictionary.

The parameters are explicitly defined in [http://meego.gitorious.org/meego-quality-assurance/ots/blobs/dev_branch_0.8/ots.server/ots/server/hub/options.py options.py]. The conversion from the loosely defined dictionary to a clear API is undertaken by the [http://meego.gitorious.org/meego-quality-assurance/ots/blobs/dev_branch_0.8/ots.server/ots/server/hub/options_factory.py options_factory.py]

==== [http://meego.gitorious.org/meego-quality-assurance/ots/blobs/dev_branch_0.8/ots.server/ots/server/distributor/api.py Distributor] ====

==== [http://meego.gitorious.org/meego-quality-assurance/ots/blobs/dev_branch_0.8/ots.results/ots/results/api.py Results] ====

==== [http://meego.gitorious.org/meego-quality-assurance/ots/blobs/dev_branch_0.8/ots.worker/ots/worker/api.py Worker] ====

== Extending OTS ==

You can extend OTS with your own [[Quality/QA-tools/OTS/CreatingAPublisher|Publisher]]
and with [[Quality/QA-tools/OTS/DeveloperDocs/CreatingACustomDistributionModel|custom package distribution models.]]

== Experimental ==

Documentation for experimental branches, spikes, WIPs etc. can be found in [[Quality/QA-tools/OTS/DeveloperDocs/Experimental]].

== Analysis ==

[[Quality/QA-tools/OTS/DeveloperDocs/ErrorSituations| OTS 0.1 Error Situations]]

[[Quality/QA-tools/OTS/DeveloperDocs/TypicalUsage| Typical OTS users and usage scenarios]]

== Project Planning ==

* [[Quality/QA-tools/OTS/Roadmap | Roadmap]]
* [[Quality/QA-tools/OTS/Meetings | Meetings]]
* [[Quality/QA-tools/OTS/ReleaseChecklist | ReleaseChecklist]]

==== Release Practices ====

OTS releases are done when a new release makes sense from OTS point of view. There are no scheduled releases.

The [[Quality/QA tools development#Release_Practices | QA Tools Release Practices]] gives more details.

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-08-16T15:13:58Z

Eluttine: /* 0.8.7 - 0.8.8 */

= Upgrading OTS =

== 0.8.7 - 0.8.8 ==
New conductor configuration parameter 'target_username'. Add it to existing conductor configuration files (/etc/ots/conductor.conf and /etc/ots/conductor_*.conf) or replace old file(s) with new one.

== 0.8.6 - 0.8.7 ==
Locations and names of configuration files have been changed. All configuration files are now located in /etc/ots and the plugin configuration files are in /etc/ots/plugins.

If you wish to keep your old settings you have to replace the new files.
On the server side:
sudo mv /etc/ots_server.ini /etc/ots/server.conf
sudo mv /etc/ots_plugin_qareports.conf /etc/ots/plugins/qareports.conf
And email plugin has it's own configuration file so you should move the [ots.email_plugin] section from the old /etc/ots_server.ini file to /etc/ots/plugins/email.conf.

On the worker side:
sudo mv /etc/ots.ini /etc/ots/worker.conf
sudo mv /etc/conductor.conf /etc/ots/conductor.conf
sudo mv /etc/ots_plugin_conductor_richcore.conf /etc/ots/plugins/conductor_richcore.conf

== 0.8.5 - 0.8.6 ==
Backup all configuration files and database before upgrading.

If you have logger plugin installed update the templates by giving following commands after upgrade:
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/

Upgrade also the latest meego-ai-flasher.

=== Updating the database ===

If you want to keep your old log database, add new (user_defined_id) column to the log_messages table. Run database command line interface for OTS database. By default OTS uses sqlite database at /opt/ots/ots.sqlite.
sudo sqlite3 /opt/ots/ots.sqlite
Add new column to the log_messages table by executing following command:
ALTER TABLE log_messages ADD COLUMN user_defined_id varchar(255) NOT NULL DEFAULT <nowiki>''</nowiki>;

If there's no need to keep the old database you can remove the database file (/opt/ots/ots.sqlite) and generate a new one using [[Quality/QA-tools/OTS/Plugins/Django#Create.2Fupdate_databases|the instructions]].

== 0.8.4 - 0.8.5 ==
* Rich-core conductor plug-in available
** Changes to /etc/conductor.conf
** New configuration file for plug-in: /etc/ots_plugin_conductor_richcore.conf

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-08-16T15:13:40Z

Eluttine: /* Upgrading OTS */

= Upgrading OTS =

== 0.8.7 - 0.8.8 ==
* New conductor configuration parameter 'target_username'. Add it to existing conductor configuration files (/etc/ots/conductor.conf and /etc/ots/conductor_*.conf) or replace old file(s) with new one.

== 0.8.6 - 0.8.7 ==
Locations and names of configuration files have been changed. All configuration files are now located in /etc/ots and the plugin configuration files are in /etc/ots/plugins.

If you wish to keep your old settings you have to replace the new files.
On the server side:
sudo mv /etc/ots_server.ini /etc/ots/server.conf
sudo mv /etc/ots_plugin_qareports.conf /etc/ots/plugins/qareports.conf
And email plugin has it's own configuration file so you should move the [ots.email_plugin] section from the old /etc/ots_server.ini file to /etc/ots/plugins/email.conf.

On the worker side:
sudo mv /etc/ots.ini /etc/ots/worker.conf
sudo mv /etc/conductor.conf /etc/ots/conductor.conf
sudo mv /etc/ots_plugin_conductor_richcore.conf /etc/ots/plugins/conductor_richcore.conf

== 0.8.5 - 0.8.6 ==
Backup all configuration files and database before upgrading.

If you have logger plugin installed update the templates by giving following commands after upgrade:
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/

Upgrade also the latest meego-ai-flasher.

=== Updating the database ===

If you want to keep your old log database, add new (user_defined_id) column to the log_messages table. Run database command line interface for OTS database. By default OTS uses sqlite database at /opt/ots/ots.sqlite.
sudo sqlite3 /opt/ots/ots.sqlite
Add new column to the log_messages table by executing following command:
ALTER TABLE log_messages ADD COLUMN user_defined_id varchar(255) NOT NULL DEFAULT <nowiki>''</nowiki>;

If there's no need to keep the old database you can remove the database file (/opt/ots/ots.sqlite) and generate a new one using [[Quality/QA-tools/OTS/Plugins/Django#Create.2Fupdate_databases|the instructions]].

== 0.8.4 - 0.8.5 ==
* Rich-core conductor plug-in available
** Changes to /etc/conductor.conf
** New configuration file for plug-in: /etc/ots_plugin_conductor_richcore.conf

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS

2011-08-16T15:04:52Z

Eluttine: /* Releases */

= OTS Index =

Welcome to the Open Test System (OTS) Wiki Index.

== Introduction ==

OTS is the '''Open Test System''' for testing software systems on evolving hardware architectures.

It was born out of the test framework incrementally developed for use on [http://maemo.org/ Maemo] project and is in use for 24/7 testing service by [http://www.nokia.com/ Nokia].

More detailed info can be found from [[Quality/QA-tools/OTS/About|about]] page.

== Releases ==

Current release [http://meego.gitorious.org/meego-quality-assurance/ots tag 0.8.8]. See [[Quality/QA-tools/OTS/UserDocumentation/Upgrading|upgrading]] instructions!

Next release [http://bugs.meego.com/show_bug.cgi?id=22496 0.8.9]

See OTS [[Quality/QA-tools/OTS/Roadmap| roadmap.]]

== Documentation ==

* [[Quality/QA-tools/OTS/UserDocumentation | User Documentation]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation | Installation Ubuntu]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation_rpm | Installation RPM]]
** [[Quality/QA-tools/OTS/UserDocumentation/Upgrading | Upgrading]]
* [[Quality/QA-tools/OTS/DeveloperDocs | Developer Documentation]]
* [[Quality/QA-tools/OTS/AdminDocs | System Administration]]
* [[Quality/QA-tools/OTS/Glossary | Glossary]]
* [[Quality/QA-tools/OTS/ExampleSetup | Example OTS Service Setup]]

User:Eluttine

2011-08-09T09:40:46Z

Eluttine:

== Using virtualenv with OTS ==
=== Setting up virtual environment ===

Install virtualenv using package manager
sudo [aptitude/yum] install python-virtualenv

Create virtual environment to your OTS root directory with following command. It creates .env directory which will include bin, include and lib directories. When using '--no-site-packages' parameter virtualenv will not inherit any packages from your global site-packages directory.
virtualenv --no-site-packages ENV

Set environment by sourcing activate file from ENV/bin folder.
source ENV/bin/activate
Now 'which python' command should point to your ENV/bin/python file.

=== Installing packages to virtual environment ===

Now let's install python packages needed by OTS to virtual environment. Run command
pip install --upgrade minixsv amqplib django configobj

Packages will be installed under ENV/lib/python2.6/site-packages directory.

=== Installing OTS ===
Install OTS normal way using 'python setup.py install' command under component directory (no need to do it as root).

Now 'which ots_server' should point to ENV/bin/ots_server file, and you can start is as normal user.

To leave virtual environment give command
deactivate

=== Starting OTS ===
OTS will read configuration files under /etc directory, so configuration files must be copied to there. When starting OTS you need to do it as root, or give write permission for a user write log files and [[Quality/QA-tools/OTS/UserDocumentation/Conductor#Setting_your_USB_permissions_for_Flashing|do the flashing]]. Then you can activate virtualenv in two different terminals and start ots_server and ots_worker.

Quality/QA-tools/OTS/Plugins/Django

2011-08-02T12:59:18Z

Eluttine: /* Apache configuration */

= Django environment setup =

== Introduction ==

Django is used for handling database communication and displaying WebUI.

== Basic installation ==

These instructions are made for Ubuntu, but should work in the same principals with other distributions. 
Installation is made to OTS server.

1. Install django
sudo apt-get install python-django
In Fedora:
sudo yum install Django
2. Download the latest django xml-rpc plugin
https://launchpad.net/django-xmlrpc
3. Install django plug-in
tar xzf django_xmlrpc-0.1.tar.gz
sudo mv django_xmlrpc /usr/local/lib/python2.6/dist-packages/
In Fedora (as root):
mv django_xmlrpc /usr/lib/python2.6/site-packages/
chcon -R -t httpd_user_content_t /usr/lib/python2.6/site-packages/django_xmlrpc
chcon -R -t httpd_user_content_t /opt/ots
setsebool -P httpd_unified 1
setsebool -P httpd_tmp_exec 1

== Enable/disable Django applications ==

From '''0.8.3''' release, this is not necessary anymore. Plug-ins are loaded automatically.

1. Edit Django settings
sudo nano /usr/local/lib/python2.6/dist-packages/ots/django/settings.py
In Fedora:
sudo nano /usr/lib/python2.6/site-packages/ots/django/settings.py
2. Comment/uncomment OTS components in 'INSTALLED_APPS' section
# OTS components:
'ots.plugin.logger',
'ots.plugin.monitor',
'ots.plugin.history'

== Create/update databases ==

1. Create database
sudo python /usr/local/lib/python2.6/dist-packages/ots/django/manage.py syncdb --settings=settings
In Fedora:
sudo python /usr/lib/python2.6/site-packages/ots/django/manage.py syncdb --settings=settings

2. Set permissions to database file
sudo chown www-data:www-data /opt/ots
sudo chown www-data:www-data /opt/ots/ots.sqlite
In Fedora:
sudo chown apache:apache /opt/ots
sudo chown apache:apache /opt/ots/ots.sqlite

== Apache configuration ==

1. Install Apache2 and Apache2 modules
sudo apt-get install libapache2-mod-wsgi apache2-mpm-prefork libapache2-mod-python
Fedora:
yum install httpd mod_wsgi
rm /etc/httpd/conf.d/welcome.conf

2. Apache2 configuration

'''On Ubuntu'''

Edit the 000-default file. See examples for Ubuntu 10.04 and 10.10 below.

sudo nano /etc/apache2/sites-enabled/000-default

000-default on Ubuntu 10.04

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE ots.django.settings
PythonDebug On
</Location>

<Location "/media">
SetHandler None
</Location>

<LocationMatch "/styles">
SetHandler None
</LocationMatch>
</VirtualHost>
</pre>

000-default on Ubuntu 10.10

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

'''Fedora'''
rm /etc/httpd/conf.d/welcome.conf
sudo nano /etc/httpd/conf.d/ots.conf

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

3. Add symbolic links to static files
sudo ln -s -t /var/www /usr/share/ots/django/ots.wsgi
sudo ln -s -t /var/www /usr/share/ots/django/media
sudo ln -s -t /var/www /usr/share/ots/django/styles
sudo ln -s -t /var/www /usr/share/ots/plugin/logger
sudo ln -s -t /var/www /usr/share/ots/plugin/monitor
4. Add WSGI settings '''"WSGIRestrictSignal Off"'''
sudo nano /etc/apache2/apache2.conf
Fedora:
sudo nano /etc/httpd/conf/httpd.conf
5. Restart apache
sudo service apache2 restart
Fedora:
chkconfig --add httpd
chkconfig httpd on
/etc/init.d/httpd start

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-08-02T10:26:47Z

Eluttine: /* OTS server installation */

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version. If you wish to install OTS from source follow instructions howto [[Quality/QA-tools/OTS/UserDocumentation/Installation#Building_packages_from_source|build packages from the source]].

=== Set up Tools:Testing repository ===

By setting up the repository it allows you to install OTS and other MeeGo QA tools via apt-get command. Follow the [[Quality/QA-tools/How_to_set_up_repositories|instructions]].

== OTS server installation ==

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server

* Configure OTS server settings
sudo nano /etc/ots/server.conf

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots/worker.conf

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

== Building packages from source ==

If you which to build your own packages and install OTS from them here are the instructions. But it is recommended to install OTS using the repository.

* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Now you can install the packages
sudo dpkg -i <package>

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-08-02T10:25:55Z

Eluttine: Undo revision 45727 by Eluttine (talk)

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version. If you wish to install OTS from source follow instructions howto [[Quality/QA-tools/OTS/UserDocumentation/Installation#Building_packages_from_source|build packages from the source]].

=== Set up Tools:Testing repository ===

By setting up the repository it allows you to install OTS and other MeeGo QA tools via apt-get command. Follow the [[Quality/QA-tools/How_to_set_up_repositories|instructions]].

== OTS server installation ==

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server
Or if you are using own built packages
sudo dpkg -i ...

* Configure OTS server settings
sudo nano /etc/ots/server.conf

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots/worker.conf

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

== Building packages from source ==

If you which to build your own packages and install OTS from them here are the instructions. But it is recommended to install OTS using the repository.

* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Now you can install the packages
sudo dpkg -i <package>

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-08-02T10:23:12Z

Eluttine: /* Preparation */

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version. If you wish to install OTS from source follow instructions howto [[QA-tools/OTS/UserDocumentation/Installation#Building_packages_from_source|build packages from the source]].

=== Set up Tools:Testing repository ===

By setting up the repository it allows you to install OTS and other MeeGo QA tools via apt-get command. Follow the [[QA-tools/OTS/UserDocumentation/Installation#Building_packages_from_source|instructions]].

== OTS server installation ==

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server
Or if you are using own built packages
sudo dpkg -i ...

* Configure OTS server settings
sudo nano /etc/ots/server.conf

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots/worker.conf

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

== Building packages from source ==

If you which to build your own packages and install OTS from them here are the instructions. But it is recommended to install OTS using the repository.

* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Now you can install the packages
sudo dpkg -i <package>

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-08-02T10:22:13Z

Eluttine: /* Preparation */

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version. If you wish to install OTS from source follow instructions howto [[Quality/QA-tools/OTS/UserDocumentation/Installation#Build_packages_from_source|build packages from the source]].

=== Set up Tools:Testing repository ===

By setting up the repository it allows you to install OTS and other MeeGo QA tools via apt-get command. Follow the [[QA-tools/OTS/UserDocumentation/Installation#Building_packages_from_source|instructions]].

== OTS server installation ==

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server
Or if you are using own built packages
sudo dpkg -i ...

* Configure OTS server settings
sudo nano /etc/ots/server.conf

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots/worker.conf

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

== Building packages from source ==

If you which to build your own packages and install OTS from them here are the instructions. But it is recommended to install OTS using the repository.

* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Now you can install the packages
sudo dpkg -i <package>

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-08-02T10:21:27Z

Eluttine:

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version. If you wish to install OTS from source follow instructions howto [[Quality/QA-tools/OTS/UserDocumentation/Installation#Build_packages_from_source|build packages from the source]].

=== Set up Tools:Testing repository ===

By setting up the repository it allows you to install OTS and other MeeGo QA tools via apt-get command. Follow the [[Quality/QA-tools/How_to_set_up_repositories|instructions]].

== OTS server installation ==

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server
Or if you are using own built packages
sudo dpkg -i ...

* Configure OTS server settings
sudo nano /etc/ots/server.conf

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots/worker.conf

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

== Building packages from source ==

If you which to build your own packages and install OTS from them here are the instructions. But it is recommended to install OTS using the repository.

* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Now you can install the packages
sudo dpkg -i <package>

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-07-12T08:36:45Z

Eluttine: /* 0.8.6 - 0.8.7 */

= Upgrading OTS =

== 0.8.6 - 0.8.7 ==
Locations and names of configuration files have been changed. All configuration files are now located in /etc/ots and the plugin configuration files are in /etc/ots/plugins.

If you wish to keep your old settings you have to replace the new files.
On the server side:
sudo mv /etc/ots_server.ini /etc/ots/server.conf
sudo mv /etc/ots_plugin_qareports.conf /etc/ots/plugins/qareports.conf
And email plugin has it's own configuration file so you should move the [ots.email_plugin] section from the old /etc/ots_server.ini file to /etc/ots/plugins/email.conf.

On the worker side:
sudo mv /etc/ots.ini /etc/ots/worker.conf
sudo mv /etc/conductor.conf /etc/ots/conductor.conf
sudo mv /etc/ots_plugin_conductor_richcore.conf /etc/ots/plugins/conductor_richcore.conf

== 0.8.5 - 0.8.6 ==
Backup all configuration files and database before upgrading.

If you have logger plugin installed update the templates by giving following commands after upgrade:
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/

Upgrade also the latest meego-ai-flasher.

=== Updating the database ===

If you want to keep your old log database, add new (user_defined_id) column to the log_messages table. Run database command line interface for OTS database. By default OTS uses sqlite database at /opt/ots/ots.sqlite.
sudo sqlite3 /opt/ots/ots.sqlite
Add new column to the log_messages table by executing following command:
ALTER TABLE log_messages ADD COLUMN user_defined_id varchar(255) NOT NULL DEFAULT <nowiki>''</nowiki>;

If there's no need to keep the old database you can remove the database file (/opt/ots/ots.sqlite) and generate a new one using [[Quality/QA-tools/OTS/Plugins/Django#Create.2Fupdate_databases|the instructions]].

== 0.8.4 - 0.8.5 ==
* Rich-core conductor plug-in available
** Changes to /etc/conductor.conf
** New configuration file for plug-in: /etc/ots_plugin_conductor_richcore.conf

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS/Plugins/HTTP logger

2011-07-01T07:02:55Z

Eluttine: /* Installation */

= HTTP logger plugin =

Released in OTS 0.8.2.

== Installation ==

Installation is made to OTS server.

1. Install plug-in
sudo apt-get install python-ots-plugin-logger
Fedora:
sudo yum install python-ots-plugin-logger

2. Install [[Quality/QA-tools/OTS/Plugins/Django#Django_environment_setup|Django environment]]

3. Setup [[Quality/QA-tools/OTS/Plugins/Django#Apache_configuration|Apache2 environment]]

4. Enable [[Quality/QA-tools/OTS/Plugins/Django#Enable.2Fdisable_Django_applications|Django application]]
'ots.plugin.logger'
5. [[Quality/QA-tools/OTS/Plugins/Django#Create.2Fupdate_databases|Create/update database]]

6. Restart Apache2
sudo service apache2 restart
Fedora:
sudo /etc/init.d/httpd restart

7. Browse http://localhost/logger/view/

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-07-01T06:39:11Z

Eluttine: /* Preparation */

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version.

=== Set up Tools:Testing repository ===

By setting up the repository it allows you to install OTS and other MeeGo QA tools via apt-get command. Follow the [[Quality/QA-tools/How_to_set_up_repositories|instructions]].

=== Build packages from source (optional) ===

If you which to build your own packages and install OTS from them here are the instructions. But it is recommended to install OTS using the repository.

* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

== OTS server installation ==

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server
Or if you are using own built packages
sudo dpkg -i ...

* Configure OTS server settings
sudo nano /etc/ots_server.ini

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots.ini

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

Quality/QA-tools/OTS/Plugins/Django

2011-06-30T12:09:11Z

Eluttine: /* Apache configuration */

= Django environment setup =

== Introduction ==

Django is used for handling database communication and displaying WebUI.

== Basic installation ==

These instructions are made for Ubuntu, but should work in the same principals with other distributions. 
Installation is made to OTS server.

1. Install django
sudo apt-get install python-django
In Fedora:
sudo yum install Django
2. Download the latest django xml-rpc plugin
https://launchpad.net/django-xmlrpc
3. Install django plug-in
tar xzf django_xmlrpc-0.1.tar.gz
sudo mv django_xmlrpc /usr/local/lib/python2.6/dist-packages/
In Fedora (as root):
mv django_xmlrpc /usr/lib/python2.6/site-packages/
chcon -R -t httpd_user_content_t /usr/lib/python2.6/site-packages/django_xmlrpc
chcon -R -t httpd_user_content_t /opt/ots
setsebool -P httpd_unified 1
setsebool -P httpd_tmp_exec 1

== Enable/disable Django applications ==

From '''0.8.3''' release, this is not necessary anymore. Plug-ins are loaded automatically.

1. Edit Django settings
sudo nano /usr/local/lib/python2.6/dist-packages/ots/django/settings.py
In Fedora:
sudo nano /usr/lib/python2.6/site-packages/ots/django/settings.py
2. Comment/uncomment OTS components in 'INSTALLED_APPS' section
# OTS components:
'ots.plugin.logger',
'ots.plugin.monitor',
'ots.plugin.history'

== Create/update databases ==

1. Create database
sudo python /usr/local/lib/python2.6/dist-packages/ots/django/manage.py syncdb --settings=settings
In Fedora:
sudo python /usr/lib/python2.6/site-packages/ots/django/manage.py syncdb --settings=settings

2. Set permissions to database file
sudo chown www-data:www-data /opt/ots
sudo chown www-data:www-data /opt/ots/ots.sqlite
In Fedora:
sudo chown apache:apache /opt/ots
sudo chown apache:apache /opt/ots/ots.sqlite

== Apache configuration ==

1. Install Apache2 and Apache2 modules
sudo apt-get install libapache2-mod-wsgi apache2-mpm-prefork libapache2-mod-python
Fedora:
yum install httpd mod_wsgi
rm /etc/httpd/conf.d/welcome.conf

2. Apache2 configuration

'''On Ubuntu'''

Edit the 000-default file. See examples for Ubuntu 10.04 and 10.10 below.

sudo nano /etc/apache2/sites-enabled/000-default

000-default on Ubuntu 10.04

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE ots.django.settings
PythonDebug On
</Location>

<Location "/media">
SetHandler None
</Location>

<LocationMatch "/styles">
SetHandler None
</LocationMatch>
</VirtualHost>
</pre>

000-default on Ubuntu 10.10

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

'''Fedora'''
rm /etc/httpd/conf.d/welcome.conf
sudo nano /etc/httpd/conf.d/ots.conf

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

3. Copy www files to /var/www/
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/
4. Add WSGI settings '''"WSGIRestrictSignal Off"'''
sudo nano /etc/apache2/apache2.conf
Fedora:
sudo nano /etc/httpd/conf/httpd.conf
5. Restart apache
sudo service apache2 restart
Fedora:
chkconfig --add httpd
chkconfig httpd on
/etc/init.d/httpd start

Quality/QA-tools/OTS/Plugins/Django

2011-06-30T12:00:39Z

Eluttine: /* Apache configuration */

= Django environment setup =

== Introduction ==

Django is used for handling database communication and displaying WebUI.

== Basic installation ==

These instructions are made for Ubuntu, but should work in the same principals with other distributions. 
Installation is made to OTS server.

1. Install django
sudo apt-get install python-django
In Fedora:
sudo yum install Django
2. Download the latest django xml-rpc plugin
https://launchpad.net/django-xmlrpc
3. Install django plug-in
tar xzf django_xmlrpc-0.1.tar.gz
sudo mv django_xmlrpc /usr/local/lib/python2.6/dist-packages/
In Fedora (as root):
mv django_xmlrpc /usr/lib/python2.6/site-packages/
chcon -R -t httpd_user_content_t /usr/lib/python2.6/site-packages/django_xmlrpc
chcon -R -t httpd_user_content_t /opt/ots
setsebool -P httpd_unified 1
setsebool -P httpd_tmp_exec 1

== Enable/disable Django applications ==

From '''0.8.3''' release, this is not necessary anymore. Plug-ins are loaded automatically.

1. Edit Django settings
sudo nano /usr/local/lib/python2.6/dist-packages/ots/django/settings.py
In Fedora:
sudo nano /usr/lib/python2.6/site-packages/ots/django/settings.py
2. Comment/uncomment OTS components in 'INSTALLED_APPS' section
# OTS components:
'ots.plugin.logger',
'ots.plugin.monitor',
'ots.plugin.history'

== Create/update databases ==

1. Create database
sudo python /usr/local/lib/python2.6/dist-packages/ots/django/manage.py syncdb --settings=settings
In Fedora:
sudo python /usr/lib/python2.6/site-packages/ots/django/manage.py syncdb --settings=settings

2. Set permissions to database file
sudo chown www-data:www-data /opt/ots
sudo chown www-data:www-data /opt/ots/ots.sqlite
In Fedora:
sudo chown apache:apache /opt/ots
sudo chown apache:apache /opt/ots/ots.sqlite

== Apache configuration ==

1. Install Apache2 and Apache2 modules
sudo apt-get install libapache2-mod-wsgi apache2-mpm-prefork libapache2-mod-python
Fedora:
yum install httpd mod_wsgi
rm /etc/httpd/conf.d/welcome.conf

2. Apache2 configuration

'''On Ubuntu'''

Edit the 000-default file. See examples for Ubuntu 10.04 and 10.10 below.

sudo nano /etc/apache2/sites-enabled/000-default

000-default on Ubuntu 10.04

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE ots.plugin.logger.django_ots.settings
PythonDebug On
</Location>

<Location "/media">
SetHandler None
</Location>

<LocationMatch "/styles">
SetHandler None
</LocationMatch>
</VirtualHost>
</pre>

000-default on Ubuntu 10.10

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

'''Fedora'''
rm /etc/httpd/conf.d/welcome.conf
sudo nano /etc/httpd/conf.d/ots.conf

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

3. Copy www files to /var/www/
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/
4. Add WSGI settings '''"WSGIRestrictSignal Off"'''
sudo nano /etc/apache2/apache2.conf
Fedora:
sudo nano /etc/httpd/conf/httpd.conf
5. Restart apache
sudo service apache2 restart
Fedora:
chkconfig --add httpd
chkconfig httpd on
/etc/init.d/httpd start

Quality/QA-tools/OTS/Plugins/Django

2011-06-30T11:59:13Z

Eluttine: /* Apache configuration */

= Django environment setup =

== Introduction ==

Django is used for handling database communication and displaying WebUI.

== Basic installation ==

These instructions are made for Ubuntu, but should work in the same principals with other distributions. 
Installation is made to OTS server.

1. Install django
sudo apt-get install python-django
In Fedora:
sudo yum install Django
2. Download the latest django xml-rpc plugin
https://launchpad.net/django-xmlrpc
3. Install django plug-in
tar xzf django_xmlrpc-0.1.tar.gz
sudo mv django_xmlrpc /usr/local/lib/python2.6/dist-packages/
In Fedora (as root):
mv django_xmlrpc /usr/lib/python2.6/site-packages/
chcon -R -t httpd_user_content_t /usr/lib/python2.6/site-packages/django_xmlrpc
chcon -R -t httpd_user_content_t /opt/ots
setsebool -P httpd_unified 1
setsebool -P httpd_tmp_exec 1

== Enable/disable Django applications ==

From '''0.8.3''' release, this is not necessary anymore. Plug-ins are loaded automatically.

1. Edit Django settings
sudo nano /usr/local/lib/python2.6/dist-packages/ots/django/settings.py
In Fedora:
sudo nano /usr/lib/python2.6/site-packages/ots/django/settings.py
2. Comment/uncomment OTS components in 'INSTALLED_APPS' section
# OTS components:
'ots.plugin.logger',
'ots.plugin.monitor',
'ots.plugin.history'

== Create/update databases ==

1. Create database
sudo python /usr/local/lib/python2.6/dist-packages/ots/django/manage.py syncdb --settings=settings
In Fedora:
sudo python /usr/lib/python2.6/site-packages/ots/django/manage.py syncdb --settings=settings

2. Set permissions to database file
sudo chown www-data:www-data /opt/ots
sudo chown www-data:www-data /opt/ots/ots.sqlite
In Fedora:
sudo chown apache:apache /opt/ots
sudo chown apache:apache /opt/ots/ots.sqlite

== Apache configuration ==

1. Install Apache2 and Apache2 modules
sudo apt-get install libapache2-mod-wsgi apache2-mpm-prefork libapache2-mod-python
Fedora:
yum install httpd mod_wsgi
rm /etc/httpd/conf.d/welcome.conf

2. Apache2 configuration

'''Ubuntu'''

Edit the 000-default file. See examples for Ubuntu 10.04 and 10.10 below.

sudo nano /etc/apache2/sites-enabled/000-default

'''000-default on Ubuntu 10.04'''

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE ots.plugin.logger.django_ots.settings
PythonDebug On
</Location>

<Location "/media">
SetHandler None
</Location>

<LocationMatch "/styles">
SetHandler None
</LocationMatch>
</VirtualHost>
</pre>

'''000-default on Ubuntu 10.10'''

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

'''Fedora'''
rm /etc/httpd/conf.d/welcome.conf
sudo nano /etc/httpd/conf.d/ots.conf

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

3. Copy www files to /var/www/
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/
4. Add WSGI settings '''"WSGIRestrictSignal Off"'''
sudo nano /etc/apache2/apache2.conf
Fedora:
sudo nano /etc/httpd/conf/httpd.conf
5. Restart apache
sudo service apache2 restart
Fedora:
chkconfig --add httpd
chkconfig httpd on
/etc/init.d/httpd start

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-06-30T11:45:05Z

Eluttine: /* How to install N900 automation tools to OTS worker */

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version.

* Add Tools:Testing apt source to /etc/apt/sources.list
sudo nano /etc/apt/sources.list
deb http://download.meego.com/live/Tools:/Testing/xUbuntu_10.10/ /
Notice that if you are using Ubuntu 10.04, change the path.

* Add repository keys
gpg --keyserver subkeys.pgp.net --recv-keys 0BC7BEC479FC1F8A
gpg --export --armor 0BC7BEC479FC1F8A | sudo apt-key add -

* Update the repositories
sudo apt-get update

'''Build packages from source (optional)'''
* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

== OTS server installation ==

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server
Or if you are using own built packages
sudo dpkg -i ...

* Configure OTS server settings
sudo nano /etc/ots_server.ini

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots.ini

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-06-30T11:39:30Z

Eluttine: /* OTS server installation */

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version.

* Add Tools:Testing apt source to /etc/apt/sources.list
sudo nano /etc/apt/sources.list
deb http://download.meego.com/live/Tools:/Testing/xUbuntu_10.10/ /
Notice that if you are using Ubuntu 10.04, change the path.

* Add repository keys
gpg --keyserver subkeys.pgp.net --recv-keys 0BC7BEC479FC1F8A
gpg --export --armor 0BC7BEC479FC1F8A | sudo apt-key add -

* Update the repositories
sudo apt-get update

'''Build packages from source (optional)'''
* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

== OTS server installation ==

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server
Or if you are using own built packages
sudo dpkg -i ...

* Configure OTS server settings
sudo nano /etc/ots_server.ini

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots.ini

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

Quality/QA-tools/OTS/UserDocumentation/Installation

2011-06-30T11:35:01Z

Eluttine: /* OTS server installation */

= OTS 0.8.x installation Ubuntu =

If using 0.1.x version, see [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration from 0.1.x to 0.8.x]] document.

== Used hardware ==

:1 x Server (Ubuntu 10.10)
:1 x Client (Ubuntu 10.10)
::1 x HAT controller
:: 1 x Power cable
:: 1 x Power supply
:: 2 x USB A-B cable
:: 1 x USB A-microB cable
:: 1 x N900

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version.

* Add Tools:Testing apt source to /etc/apt/sources.list
sudo nano /etc/apt/sources.list
deb http://download.meego.com/live/Tools:/Testing/xUbuntu_10.10/ /
Notice that if you are using Ubuntu 10.04, change the path.

* Add repository keys
gpg --keyserver subkeys.pgp.net --recv-keys 0BC7BEC479FC1F8A
gpg --export --armor 0BC7BEC479FC1F8A | sudo apt-key add -

* Update the repositories
sudo apt-get update

'''Build packages from source (optional)'''
* Install git core
sudo apt-get install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* Get building tools
sudo apt-get install dpkg-dev debhelper python-setuptools

* Build packages
cd ots
dpkg-buildpackage -rfakeroot

== OTS server installation ==

* Install dependencies
sudo apt-get install python-django python-amqplib python-configobj rabbitmq-server test-definition

* Install OTS server components
sudo apt-get install python-ots-common python-ots-results python-ots-server
Or if you are using own built packages
sudo dpkg -i ...

* Configure OTS server settings
sudo nano /etc/ots_server.ini

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins
[[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger plug-in]] (recommended)
[[Quality/QA-tools/OTS/Plugins/Email|Email plug-in]] (recommended)

See more plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* If logger plug-in is installed
Change permissions to logging directory
sudo chown www-data:www-data /var/log/ots

Now the OTS server can be used via apache (django_xmlrpc).

* If logger plug-in is not installed
Change user permissions to logging directory
sudo chown <user>:<group> /var/log/ots

* Start rabbitmq-server
/etc/init.d/rabbitmq-server start

* Now you can start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
sudo apt-get install python-amqplib testrunner-lite

* Install OTS worker packages
sudo apt-get install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots.ini

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker
sudo ots_worker

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
sudo apt-get install python-ots-tools

* Trigger a test run
ots_trigger -s localhost/xmlrpc -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

== How to install N900 automation tools to OTS worker ==

* Remove network-manager, because it breaks the USB connection. See more information from autotest-guide.

* Install dependencies
sudo apt-get install meego-ai-flasher eat-host-ubuntu

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2_i386.deb
sudo dpkg -i maemo_flasher-3.5_2.5.2.2_i386.deb

* Start HAT driver
sudo hat_drv &

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>

* Start OTS worker
sudo ots_worker

Quality/QA-tools/OTS

2011-06-13T07:29:15Z

Eluttine: /* Releases */

= OTS Index =

Welcome to the Open Test System (OTS) Wiki Index.

== Introduction ==

OTS is the '''Open Test System''' for testing software systems on evolving hardware architectures.

It was born out of the test framework incrementally developed for use on [http://maemo.org/ Maemo] project and is in use for 24/7 testing service by [http://www.nokia.com/ Nokia].

More detailed info can be found from [[Quality/QA-tools/OTS/About|about]] page.

== Releases ==

Current release [http://meego.gitorious.org/meego-quality-assurance/ots tag 0.8.6]. See [[Quality/QA-tools/OTS/UserDocumentation/Upgrading|upgrading]] instructions!

Next release [https://bugs.meego.com/show_bug.cgi?id=18875 0.8.7]

See OTS [[Quality/QA-tools/OTS/Roadmap| roadmap.]]

== Documentation ==

* [[Quality/QA-tools/OTS/UserDocumentation | User Documentation]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation | Installation Ubuntu]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation_rpm | Installation RPM]]
** [[Quality/QA-tools/OTS/UserDocumentation/Upgrading | Upgrading]]
* [[Quality/QA-tools/OTS/DeveloperDocs | Developer Documentation]]
* [[Quality/QA-tools/OTS/AdminDocs | System Administration]]
* [[Quality/QA-tools/OTS/Glossary | Glossary]]
* [[Quality/QA-tools/OTS/ExampleSetup | Example OTS Service Setup]]

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-06-13T06:48:05Z

Eluttine: /* 0.8.5 - 0.8.6 */

= Upgrading OTS =

== 0.8.5 - 0.8.6 ==
Backup all configuration files and database before upgrading.

If you have logger plugin installed update the templates by giving following commands after upgrade:
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/

Upgrade also the latest meego-ai-flasher.

=== Updating the database ===

If you want to keep your old log database, add new (user_defined_id) column to the log_messages table. Run database command line interface for OTS database. By default OTS uses sqlite database at /opt/ots/ots.sqlite.
sudo sqlite3 /opt/ots/ots.sqlite
Add new column to the log_messages table by executing following command:
ALTER TABLE log_messages ADD COLUMN user_defined_id varchar(255) NOT NULL DEFAULT <nowiki>''</nowiki>;

If there's no need to keep the old database you can remove the database file (/opt/ots/ots.sqlite) and generate a new one using [[Quality/QA-tools/OTS/Plugins/Django#Create.2Fupdate_databases|the instructions]].

== 0.8.4 - 0.8.5 ==
* Rich-core conductor plug-in available
** Changes to /etc/conductor.conf
** New configuration file for plug-in: /etc/ots_plugin_conductor_richcore.conf

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-06-13T06:12:00Z

Eluttine: /* 0.8.5 - 0.8.6 */

= Upgrading OTS =

== 0.8.5 - 0.8.6 ==
Backup all configuration files and database before updating.

If you have logger plugin installed update the templates by giving following commands after upgrade:
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/

Upgrade also the latest meego-ai-flasher.

=== Update the database ===

If you want to keep your old log database, add new (user_defined_id) column to the log_messages table. Run database command line interface for OTS database. By default OTS uses sqlite database at /opt/ots/ots.sqlite.
sudo sqlite3 /opt/ots/ots.sqlite
Add new column to the log_messages table by executing following command:
ALTER TABLE log_messages ADD COLUMN user_defined_id varchar(255) NOT NULL DEFAULT <nowiki>''</nowiki>;

== 0.8.4 - 0.8.5 ==
* Rich-core conductor plug-in available
** Changes to /etc/conductor.conf
** New configuration file for plug-in: /etc/ots_plugin_conductor_richcore.conf

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS/Plugins/Rich-core

2011-05-23T06:14:19Z

Eluttine: Created page with "= Rich-core plug-in = Released in OTS 0.8.5. == Installation == Installation is made to OTS worker. 1. Install plug-in package sudo apt-get install python-ots-plugin-conduct..."

= Rich-core plug-in =

Released in OTS 0.8.5.

== Installation ==

Installation is made to OTS worker.

1. Install plug-in package
sudo apt-get install python-ots-plugin-conductor-richcore
On Fedora
sudo yum install python-ots-plugin-conductor-richcore

2. Make sure that testrunner-lite 1.6.1 or newer is installed

3. Set rich_core_dumps_folder parameter for conductor
sudo nano /etc/conductor.conf

4. Configure rich-core plug-in settings
sudo nano /etc/ots_plugin_conductor_richcore.conf

5. Restart OTS worker

Quality/QA-tools/OTS/DeveloperDocs/Plugins

2011-05-23T05:54:28Z

Eluttine: /* Publisher Plugins */

= Plugins =

== Overview ==

OTS currently consists of two distributed '''Applications''':

* Worker

* Server

These Applications are made up of '''Components'''. The '''Components''' perform a specific task in the system (and are distributable in their own right).

Some of the '''Components''' are essential for the '''Applications''' to operate. The '''Plugins''' are the non-essential (pluggable!) '''Components'''.

== Technology ==

OTS allows for a configurable distribution by using a plug-in mechanism using [http://peak.telecommunity.com/DevCenter/PkgResources Package Resources]

== Supported Plugins ==

Some of the plug-ins are requiring [[Quality/QA-tools/OTS/Plugins/Django|Django environment]]. This is mentioned in the plug-ins instructions.

=== Distribution Model Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/History|History]]|| ots.plugin.history.distribution_model:get_model || Test package distribution model based on last execution time
|}

=== Publisher Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/HTTP_logger|HTTP Logger]]|| ots.plugin.logger.logger_plugin:LoggerPlugin || Plug-in for enabling HTTP based logging and monitoring
|-
|[[Quality/QA-tools/OTS/Plugins/Email|Email]]|| ots.plugin.email.email_plugin:EmailPlugin || Plug-in for enabling email sending
|-
|[[Quality/QA-tools/OTS/Plugins/QAReports|QA-Reports]]|| ots.plugin.qareports.qareports_plugin:QAReportsPlugin || Plug-in for sending results to QA Reports
|-
|[[Quality/QA-tools/OTS/Plugins/History|History]]|| ots.plugin.history.history_plugin:HistoryPlugin || Plug-in for storing execution times to database
|-
|[[Quality/QA-tools/OTS/Plugins/Monitor|Monitor]]|| ots.plugin.monitor.monitor_plugin:MonitorPlugin || Plug-in for collecting statistical information
|}

=== Conductor Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/Rich-core|Rich-core]]|| ots.plugin.conductor.richcore.richcore_plugin:RichCorePlugin || Plug-in for uploading rich-core dumps to post-processing. Rich-core plug-in is part of [[ARM/N900/QA#Crash_analysis_support_for_ARM_core_dumps|crash reporting functionality]].
|}

Quality/QA-tools/OTS/DeveloperDocs/Plugins

2011-05-20T14:35:40Z

Eluttine: /* Technology */

= Plugins =

== Overview ==

OTS currently consists of two distributed '''Applications''':

* Worker

* Server

These Applications are made up of '''Components'''. The '''Components''' perform a specific task in the system (and are distributable in their own right).

Some of the '''Components''' are essential for the '''Applications''' to operate. The '''Plugins''' are the non-essential (pluggable!) '''Components'''.

== Technology ==

OTS allows for a configurable distribution by using a plug-in mechanism using [http://peak.telecommunity.com/DevCenter/PkgResources Package Resources]

== Supported Plugins ==

Some of the plug-ins are requiring [[Quality/QA-tools/OTS/Plugins/Django|Django environment]]. This is mentioned in the plug-ins instructions.

=== Distribution Model Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/History|History]]|| ots.plugin.history.distribution_model:get_model || Test package distribution model based on last execution time
|}

=== Publisher Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/HTTP_logger|HTTP Logger]]|| ots.logger_plugin.logger_plugin || Plug-in for enabling HTTP based logging and monitoring
|-
|[[Quality/QA-tools/OTS/Plugins/Email|Email]]|| ots.logger_plugin.email_plugin || Plug-in for enabling email sending
|-
|[[Quality/QA-tools/OTS/Plugins/QAReports|QA-Reports]]|| ots.logger_plugin.qareports_plugin || Plug-in for sending results to QA-Reports
|-
|[[Quality/QA-tools/OTS/Plugins/History|History]]|| ots.plugin.history.history_plugin:HistoryPlugin || Plug-in for storing execution times to database
|-
|[[Quality/QA-tools/OTS/Plugins/Monitor|Monitor]]|| ots.plugin.monitor.monitor_plugin:MonitorPlugin || Plug-in for collecting statistical information
|}

=== Conductor Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/Rich-core|Rich-core]]|| ots.plugin.conductor.richcore.richcore_plugin:RichCorePlugin || Plug-in for uploading rich-core dumps to post-processing. Rich-core plug-in is part of [[ARM/N900/QA#Crash_analysis_support_for_ARM_core_dumps|crash reporting functionality]].
|}

Quality/QA-tools/OTS/DeveloperDocs/Plugins

2011-05-20T14:34:46Z

Eluttine: /* Conductor Plugins */

= Plugins =

== Overview ==

OTS currently consists of two distributed '''Applications''':

* Worker

* Server

These Applications are made up of '''Components'''. The '''Components''' perform a specific task in the system (and are distributable in their own right).

Some of the '''Components''' are essential for the '''Applications''' to operate. The '''Plugins''' are the non-essential (pluggable!) '''Components'''.

== Technology ==

OTS allows for a configurable distribution by using a PlugIn mechanism using [http://peak.telecommunity.com/DevCenter/PkgResources Package Resources]

== Supported Plugins ==

Some of the plug-ins are requiring [[Quality/QA-tools/OTS/Plugins/Django|Django environment]]. This is mentioned in the plug-ins instructions.

=== Distribution Model Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/History|History]]|| ots.plugin.history.distribution_model:get_model || Test package distribution model based on last execution time
|}

=== Publisher Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/HTTP_logger|HTTP Logger]]|| ots.logger_plugin.logger_plugin || Plug-in for enabling HTTP based logging and monitoring
|-
|[[Quality/QA-tools/OTS/Plugins/Email|Email]]|| ots.logger_plugin.email_plugin || Plug-in for enabling email sending
|-
|[[Quality/QA-tools/OTS/Plugins/QAReports|QA-Reports]]|| ots.logger_plugin.qareports_plugin || Plug-in for sending results to QA-Reports
|-
|[[Quality/QA-tools/OTS/Plugins/History|History]]|| ots.plugin.history.history_plugin:HistoryPlugin || Plug-in for storing execution times to database
|-
|[[Quality/QA-tools/OTS/Plugins/Monitor|Monitor]]|| ots.plugin.monitor.monitor_plugin:MonitorPlugin || Plug-in for collecting statistical information
|}

=== Conductor Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/Rich-core|Rich-core]]|| ots.plugin.conductor.richcore.richcore_plugin:RichCorePlugin || Plug-in for uploading rich-core dumps to post-processing. Rich-core plug-in is part of [[ARM/N900/QA#Crash_analysis_support_for_ARM_core_dumps|crash reporting functionality]].
|}

Quality/QA-tools/OTS/DeveloperDocs/Plugins

2011-05-20T14:31:06Z

Eluttine: /* Plugins */

= Plugins =

== Overview ==

OTS currently consists of two distributed '''Applications''':

* Worker

* Server

These Applications are made up of '''Components'''. The '''Components''' perform a specific task in the system (and are distributable in their own right).

Some of the '''Components''' are essential for the '''Applications''' to operate. The '''Plugins''' are the non-essential (pluggable!) '''Components'''.

== Technology ==

OTS allows for a configurable distribution by using a PlugIn mechanism using [http://peak.telecommunity.com/DevCenter/PkgResources Package Resources]

== Supported Plugins ==

Some of the plug-ins are requiring [[Quality/QA-tools/OTS/Plugins/Django|Django environment]]. This is mentioned in the plug-ins instructions.

=== Distribution Model Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/History|History]]|| ots.plugin.history.distribution_model:get_model || Test package distribution model based on last execution time
|}

=== Publisher Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/HTTP_logger|HTTP Logger]]|| ots.logger_plugin.logger_plugin || Plug-in for enabling HTTP based logging and monitoring
|-
|[[Quality/QA-tools/OTS/Plugins/Email|Email]]|| ots.logger_plugin.email_plugin || Plug-in for enabling email sending
|-
|[[Quality/QA-tools/OTS/Plugins/QAReports|QA-Reports]]|| ots.logger_plugin.qareports_plugin || Plug-in for sending results to QA-Reports
|-
|[[Quality/QA-tools/OTS/Plugins/History|History]]|| ots.plugin.history.history_plugin:HistoryPlugin || Plug-in for storing execution times to database
|-
|[[Quality/QA-tools/OTS/Plugins/Monitor|Monitor]]|| ots.plugin.monitor.monitor_plugin:MonitorPlugin || Plug-in for collecting statistical information
|}

=== Conductor Plugins ===

{|border="1" cellpadding="5"
|-
|'''Name'''||'''Entry point'''||'''Purpose'''
|-
|[[Quality/QA-tools/OTS/Plugins/Rich-core|Rich-core]]|| ots.plugin.conductor.richcore.richcore_plugin:RichCorePlugin || Plug-in for uploading rich-core dumps to post-processing
|}

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-05-20T13:17:43Z

Eluttine: /* 0.8.4 - 0.8.5 */

= Upgrading OTS =

== 0.8.4 - 0.8.5 ==
* Rich-core conductor plug-in available
** Changes to /etc/conductor.conf
** New configuration file for plug-in: /etc/ots_plugin_conductor_richcore.conf

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS/UserDocumentation/Upgrading

2011-05-20T10:57:53Z

Eluttine: /* Upgrading OTS */

= Upgrading OTS =

== 0.8.4 - 0.8.5 ==
* Remember to install python-ots-plugin-conductor-richcore to all workers if you are planning to use it.

== 0.8.3 - 0.8.4 ==
* Backup all configuration files before updating
* Multiple device support added, even if you use '''only one device''' check following:
** Changes to /etc/conductor.conf
** Update meego-ai-flasher (>= 0.1.4) and [http://meego-qa-tools.digia.com/meego-ai/meego-ai-optimized.tar.gz meego-ai] packages!
** Even if you use only one device, remove usb0 configurations from /etc/network/interfaces
** [[Quality/QA-tools/OTS/UserDocumentation/Multiple_device| See this instructions!]]
* Changes to QAReports configuration file /etc/ots_plugins_qareports.conf
** Added proxy and attachment upload settings

== 0.8.2 - 0.8.3 ==
* Changes in ots_plugin_qareports.conf
** Add new parameters
* Only new features
** Test plan based execution
** Chroot support
** See [[Quality/QA-tools/OTS/UserDocumentation/Usage|how to]] use these features

== 0.8.1 - 0.8.2 ==
* New django package added, effects to all plug-ins
** See [[Quality/QA-tools/OTS/Plugins/Django|Django instructions]].
** See [[Quality/QA-tools/OTS/DeveloperDocs/Plugins|plug-ins instructions]].

== 0.8.0 - 0.8.1 ==
* Plug-in namespace changed, effects to Logger and QA-Reports plug-ins
** For logger update web page content, see step 8 from [[Quality/QA-tools/OTS/Plugins/HTTP_logger|Logger documentation]].
** For QA-Reports, configuration file name has changed. Move /etc/ots_qareports_plugin.conf to /etc/ots_plugin_qareports.conf

== 0.1.x - 0.8.0 ==

See [[Quality/QA-tools/OTS/UserDocumentation/Migration_0.1_0.8| migration document]].

Quality/QA-tools/OTS

2011-05-20T10:47:51Z

Eluttine: /* Releases */

= OTS Index =

Welcome to the Open Test System (OTS) Wiki Index.

== Introduction ==

OTS is the '''Open Test System''' for testing software systems on evolving hardware architectures.

It was born out of the test framework incrementally developed for use on [http://maemo.org/ Maemo] project and is in use for 24/7 testing service by [http://www.nokia.com/ Nokia].

More detailed info can be found from [[Quality/QA-tools/OTS/About|about]] page.

== Releases ==

Current release [http://meego.gitorious.org/meego-quality-assurance/ots tag 0.8.5]. See [[Quality/QA-tools/OTS/UserDocumentation/Upgrading|upgrading]] instructions!

Next release [https://bugs.meego.com/show_bug.cgi?id=17933 0.8.6]

See OTS [[Quality/QA-tools/OTS/Roadmap| roadmap.]]

== Documentation ==

* [[Quality/QA-tools/OTS/UserDocumentation | User Documentation]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation | Installation Ubuntu]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation_rpm | Installation RPM]]
** [[Quality/QA-tools/OTS/UserDocumentation/Upgrading | Upgrading]]
* [[Quality/QA-tools/OTS/DeveloperDocs | Developer Documentation]]
* [[Quality/QA-tools/OTS/AdminDocs | System Administration]]
* [[Quality/QA-tools/OTS/Glossary | Glossary]]

Quality/QA-tools/OTS/Plugins/Django

2011-05-13T11:45:55Z

Eluttine: /* Enable/disable Django applications */

= Django environment setup =

== Introduction ==

Django is used for handling database communication and displaying WebUI.

== Basic installation ==

These instructions are made for Ubuntu, but should work in the same principals with other distributions. 
Installation is made to OTS server.

1. Install django
sudo apt-get install python-django
In Fedora:
sudo yum install Django
2. Download the latest django xml-rpc plugin
https://launchpad.net/django-xmlrpc
3. Install django plug-in
tar xzf django_xmlrpc-0.1.tar.gz
sudo mv django_xmlrpc /usr/local/lib/python2.6/dist-packages/
In Fedora (as root):
mv django_xmlrpc /usr/lib/python2.6/site-packages/
chcon -R -t httpd_user_content_t /usr/lib/python2.6/site-packages/django_xmlrpc
chcon -R -t httpd_user_content_t /opt/ots
setsebool -P httpd_unified 1
setsebool -P httpd_tmp_exec 1

== Enable/disable Django applications ==

From '''0.8.3''' release, this is not necessary anymore. Plug-ins are loaded automatically.

1. Edit Django settings
sudo nano /usr/local/lib/python2.6/dist-packages/ots/django/settings.py
In Fedora:
sudo nano /usr/lib/python2.6/site-packages/ots/django/settings.py
2. Comment/uncomment OTS components in 'INSTALLED_APPS' section
# OTS components:
'ots.plugin.logger',
'ots.plugin.monitor',
'ots.plugin.history'

== Create/update databases ==

1. Create database
sudo python /usr/local/lib/python2.6/dist-packages/ots/django/manage.py syncdb --settings=settings
In Fedora:
sudo python /usr/lib/python2.6/site-packages/ots/django/manage.py syncdb --settings=settings

2. Set permissions to database file
sudo chown www-data:www-data /opt/ots
sudo chown www-data:www-data /opt/ots/ots.sqlite
In Fedora:
sudo chown apache:apache /opt/ots
sudo chown apache:apache /opt/ots/ots.sqlite

== Apache configuration ==

1. Install Apache2 and Apache2 modules
sudo apt-get install libapache2-mod-wsgi apache2-mpm-prefork
Fedora:
yum install httpd mod_wsgi
rm /etc/httpd/conf.d/welcome.conf

2. Apache2 configuration

'''Ubuntu 10.04'''

sudo apt-get install libapache2-mod-python

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE ots.plugin.logger.django_ots.settings
PythonDebug On
</Location>

<Location "/media">
SetHandler None
</Location>

<LocationMatch "/styles">
SetHandler None
</LocationMatch>
</VirtualHost>
</pre>

'''Ubuntu 10.10'''
sudo nano /etc/apache2/sites-enabled/000-default

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

'''Fedora'''
rm /etc/httpd/conf.d/welcome.conf
sudo nano /etc/httpd/conf.d/ots.conf

<pre>
<VirtualHost *:80>

AliasMatch /([^/]*\.css) /var/www/styles/$1

Alias /media/ /var/www/media/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /var/www/ots.wsgi

<Directory /usr/local/wsgi/scripts>
Order allow,deny
Allow from all
</Directory>

</VirtualHost>
</pre>

3. Copy www files to /var/www/
sudo cp -r /usr/share/ots/django/* /var/www/
sudo cp -r /usr/share/ots/plugin/* /var/www/
4. Add WSGI settings '''"WSGIRestrictSignal Off"'''
sudo nano /etc/apache2/apache2.conf
Fedora:
sudo nano /etc/httpd/conf/httpd.conf
5. Restart apache
sudo service apache2 restart
Fedora:
chkconfig --add httpd
chkconfig httpd on
/etc/init.d/httpd start

Quality/QA-tools/OTS/UserDocumentation/Installation rpm

2011-05-13T11:39:58Z

Eluttine: /* Preparation */

= OTS 0.8.x installation RPM =

These instructions have been tested with Fedora 13. Execute commands as root.

In MeeGo netbook, at least following packages needs to be installed manually:
python-amqp, python-django, minixsv, rabbitmq-server

== Network Setup ==

Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.

'''Note''' All OTS machines need to be able to access other OTS machines based on their hostname.

How to check that DNS names are correct:

1. Check OTS server's hostname
hostname
2. Ping the OTS server's hostname from the OTS worker
ping <hostname>

If ping fails, add manually OTS server's hostname to OTS workers '''/etc/hosts''' file
<IP> <hostname>

== Preparation ==

There are two ways of getting OTS binary packages: from '''the source code'''
or from the '''MeeGo Tools:Testing repository'''. From the repository you can get
the stable version and from the source code the development version.

* Add Tools:Testing source to /etc/yum.repos.d/
cd /etc/yum.repos.d/
yum install wget nano
wget http://download.meego.com/live/Tools:/Testing/Fedora13/Tools:Testing.repo

* Update the repositories
yum check-update

'''Build packages from source (optional)'''
* Install git core
yum install git-core

* Get sources
git clone git://gitorious.org/meego-quality-assurance/ots.git

* List tags
git tag -l

* Checkout the latest tag
git checkout <tag_name>

* Get building tools
yum rpm-build python-setuptools

* Build packages
mv ots python-ots-0.8.x
tar czf python-ots-0.8.x.tar.gz python-ots-0.8.x
rpmbuild -tb python-ots-0.8.x.tar.gz

== OTS server installation ==

* Install dependencies
yum install Django python-amqplib python-configobj rabbitmq-server test-definition
easy_install minixsv
yum install python-setuptools

* Install OTS server components
yum install python-ots-common python-ots-results python-ots-server
or if you are using own built packages
rpm -i ...

* Add rabbitmq to start on boot
chkconfig --add rabbitmq-server
chkconfig rabbitmq-server on

* Start rabbitmq server
/etc/init.d/rabbitmq-server start

* Configure OTS server settings
sudo nano /etc/ots_server.ini

Recommended to change following:
'example_sw_product', example to 'meego_product'
'devicegroup', example to 'meego_n900'

* Install OTS server plug-ins

See plug-ins from [[Quality/QA-tools/OTS/Plugins|OTS Plug-ins]]

* Start OTS server
ots_server

== OTS worker installation ==

* Install dependencies
yum install python-amqplib testrunner-lite

* Install OTS worker packages
yum install python-ots-common python-ots-worker

* Configure OTS worker settings
sudo nano /etc/ots.ini

Change 'devicegroup', example meego_n900

Change 'host' to server's address

* Start OTS worker (as root)
ots_worker

NOTE: if worker failed to start up with error like "socket.error: [Errno 113] No route to host", check that ots-worker is able to connect to ots-server

== OTS tools ==

Tools are used for triggering test runs from the command line.

* Install OTS tools
yum install python-ots-tools

* Trigger a test run
ots_trigger -s localhost:8080 -b test_build -i http://url_to_image -p example_sw_product -e test@man.com

* Kickstart file for automation can be found from
http://meego.gitorious.org/meego-quality-assurance/enables-automated-testing/blobs/ks/meego-n900-autotest.ks

* You need to build the image with mic-image-creator with parameters:
--save-kernel --package=tar.gz

== How to install N900 automation tools to OTS worker ==

* Install dependencies
yum install meego-ai-flaster eat-host

* Get N900 flasher from the Nokia's tablets-dev portal
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=maemo_flasher-3.5_2.5.2.2.tar.gz
Compile the flasher

* Configure conductor to use rpm and fetch /var/log/messages
sudo nano /etc/conductor.conf

* Test manually that everything is OK, this is executed in the worker
sudo conductor -u <image url>
* Start OTS worker
sudo ots_worker

Quality/QA tools development

2011-05-02T06:33:29Z

Eluttine: /* Documentation */

= QA tools development =

This page provides information on the development activities and practices of QA tools. The focus is on presenting things that are relevant for people interested in developing the tools. The main page for the end users is [[Quality/QA-tools|here]].

Anyone is welcome to contribute and non-member contributions will be treated with same process and review as member contributions. We follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines]. In addition, you may take personal clone from our [http://meego.gitorious.org/meego-quality-assurance/ git repositories] and create merge request. Tool maintainers in our projects will review your contributions and decide on merge.

'''Targets:'''

* Improve MeeGo test reporting tools - target from MeeGo Quality Assurance
* Improve MeeGo test automation (execution and software installation) - target from MeeGo release engineering

"As Core OS release release manager I want to verify trunk:testing packages frequently so that I know the quality of nightly/weekly releases."

== Tools and Maintainers ==

Tool maintainers are selected based on developer experience with particular tool/package or seniority. Tool maintainers have been agreed [[Quality/QA-tools/Meetings|in the QA-tools meeting]] Tuesday September 7th 2010. Changes, if needed, are discussed also there.

In practice only tool maintainers will have commit and review right to particular repository - later several people may have rights to repository based on merit (as proposed by tool maintainer). Others must follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines] to submit patches or personal clone + merge request approach.

The maintainer of the tree shall update the changelog.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Gitorious'''||'''Maintainer''' ||'''Substitute'''
|-
| [[Quality/QA-tools/Test-definition|test-definition]]||[http://meego.gitorious.org/meego-quality-assurance/test-definition Gitorious] || Sampo Saaristo || Timo Härkönen
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||[http://meego.gitorious.org/meego-quality-assurance/testrunner-lite Gitorious] || Sampo Saaristo || Kyösti Ranto
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || [http://meego.gitorious.org/meego-quality-assurance/testrunner Gitorious] || Kyösti Ranto || Timo Härkönen
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] ||[http://meego.gitorious.org/meego-quality-assurance/testplanner Gitorious] || Kyösti Ranto || N/A
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] ||[http://meego.gitorious.org/meego-quality-assurance/enables-automated-testing Gitorious] || Timo Härkönen || Timo Mäkimattila
|-
| [[Quality/QA-tools/OTS|OTS - Open Test System]] ||[http://meego.gitorious.org/meego-quality-assurance/ots Gitorious] || Elias Luttinen || Ville Niutanen
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||[http://gitorious.org/qa-tools/meego-ai Gitorious] || Timo Härkönen || N/A
|-
| [[Quality/TestSuite/MCTS|MeeGo Core Test Suite]] || [http://meego.gitorious.org/meego-quality-assurance/mcts/ Gitorious] ||Matti Salmi || Jeff Zheng
|-
| [[Quality/Netbook Test Suite and Utilities|MeeGo Netbook Test Suite]] || [http://gitorious.org/qa-tools/mnts/ Gitorious] ||Jeff Zheng || N/A
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] || [http://gitorious.org/qa-tools/qtuitest-mbt-adapter Gitorious] || Riku Halonen || N/A
|-
| [http://min.sourceforge.net/ MIN test framework] || [http://meego.gitorious.org/meego-quality-assurance/min Gitorious] || Sampo Saaristo || Timo Mäkimattila
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || [http://gitorious.org/TDriver Gitorious] || Petri Kiiskinen || Tatu Lahtela
|-
| Rich Core dumper || [http://meego.gitorious.org/meego-quality-assurance/rich-core Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter settings || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter-settings-public Gitorious] || Carol Rus || Raimo Gratseff
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] || [http://meego.gitorious.org/meego-quality-assurance/hat-control Gitorious] || Marko Junttila || Riku Halonen
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || [http://meego.gitorious.org/meego-quality-assurance/qa-reports Gitorious] || Sami Hangaslammi || Jarno Keskikangas
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] || [http://meego.gitorious.com/meego-quality-assurance/scripts-and-utils Gitorious] || N/A || N/A
|-
| [[Quality/TestSuite/handset-test-suite/handset-ux-test_Releases | handset_ux_tests]] || [http://meego.gitorious.com/meego-quality-assurance/handset-ux-tests Gitorious] || JessicaJi || N/A
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] || [http://meego.gitorious.org/meego-quality-assurance/meego-testing-hudson-plugin Gitorious] || Alexey Kuznetsov || Timo Härkönen
|-
| Service OS based Flasher || [http://meego.gitorious.org/meego-quality-assurance/meego-ai-serviceos Gitorious] || Jing Wang || N/A
|-
| [[Quality/QA-tools/Qpid C wrapper|Qpid C wrapper library - libcqpid]] || [http://meego.gitorious.org/meego-quality-assurance/libcqpid Gitorious] || Sami Lahtinen || N/A
|}

If you are interested in the user experience work regarding these tools, you can find more information [[Quality/QA-tools/User experience|here]].

=== Overview ===

The figure below tries to summarize the relations and tasks of the tools when used in test automation context.

[[File:testautomationtools.png]]

xfig file:[[File:qatools.fig]]

== Release Practices ==

Here is the workflow for QA tools release practices.

{| border="1" cellspacing="0"
|+
|'''Role'''
|'''Description'''
|-
| Developer || Anyone who wants to participate in qa-tools development
|-
| VCS Maintainer || Component owner who has commit rights in version control system (VCS)
|-
| Package Maintainer || Integrator whose responsibility is the OBS packaging
|-
| Release Management || Third party who is responsible of trunk:testing releases(?)
|}

[[File:Release.png]]

Kivio file: [[File:Release.flw]]

# Developer creates merge request(s) in gitorious.
# VCS Maintainer tests and accepts merge requests.
# VCS Maintainer checks/updates change logs.
# VCS Maintainer tags a version.
# VCS maintainer sends email to [http://lists.meego.com/pipermail/meego-qa/ meego-qa mailing list] based on the following template
Topic: Integration request: package-name version
PACKAGE: package-name
TAG: tag name
URL: link to sources
CHANGES: short description of changes containing bugs.meego.com bug numbers of fixed bugs
# Package maintainer updates the OBS package.
# Package maintainer tests the OBS package.
# If the package belongs to tools:testing and passes testing, Package Maintainer may accept it. If the package belongs to trunk:testing, Package Maintainer creates a promotional request to Release Management. (If the package belongs to both repositories, we let the Release Management set bugs fixed by the package to RELEASED state).
# Host side tools are updated to tools:testing after verifying functionality
# Package maintainer replies to meego-qa list about the actions done with the updated package. e.g. 'Updated in devel:quality and sent promotion request to testing'
# Release Management accepts the package. Or not. (Follow meego-packaging and meego-commits.)

''' YouTube videos '''

YouTube is a good way to communicate new features. You can find existing demo videos on [http://www.youtube.com/user/meegoqatools meegoqatools channel on Youtube].

If you shoot a video to YouTube, promote it on meego-qa mailing list!

You can find some hints how to shoot, edit, and upload a video here: [[YouTube_Hints]]

=== Release checklist ===
To make sure fixes are released without delay, check that the following conditions are met

# Change logs are updated and contain relevant references to MeeGo bugzilla
# Created obs request include fixes bug numbers from MeeGo bugzilla
# Bugzilla items listed in changes are set as resolved
# Spec file matches [[Packaging/Guidelines|MeeGo packaging guidelines]]
# Rpmlint warnings are either fixed or explained by comments in the spec file. e.g. eat packages install files into root's home and the reasoning for it needs to be explained
# Host side tool packages use the same source tar ball to produce debian and rpm packages

== Roadmap ==

The focus is currently on [[ARM/N900/QA|N900 Developer Edition QA]]. Hence the N900 related list below doesn't have a comprehensive information about target builds or priorities.

When you add a new bug, add correct dependencies to the corresponding roadmap meta bug.

The features in the roadmap are followed with META FEA bugs. The features are split to small tool specific FEA:s that block the feature META bug. The META bug is then the last bug to be closed when the feature is finished. You can also follow the tool bug progression from the dependency trees of the META bugs.

Adding a new feature to the roadmap:
# Add a feature bug describing the main purpose of the feature with META and FEA tags.
# Add separate bugs for each tool specific change
# Add correct dependencies between tool specific bugs (e.g. testrunner bug depends on testrunner-lite bug that depends on test-definition bug...)
# Make all of the bugs block the META bug

A list of defined features:

{| border="1" cellspacing="0"
|+
|'''Feature'''
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12980&hide_resolved=0 Measurement support]
|-
| [https://bugs.meego.com/show_bug.cgi?id=12810 Easy install]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=12454&hide_resolved=0 Parallel testing]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12981&hide_resolved=0 Events feature in automatic testing]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12937&hide_resolved=0 MCTS coverage support]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=12833&hide_resolved=0 Test environment validation]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=13092&hide_resolved=0 Test equipment control]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12971&hide_resolved=0 Qt Creator integration]
|-
| [https://bugs.meego.com/show_bug.cgi?id=13190 A tool that combines Testrunner and Testplanner]
|-
| [[Quality/QA-tools/OTS/Roadmap|OTS releases]]
|}

== Design/ Planning ==

* [[Quality/QA-tools/MCTS test automation design|MCTS Test Automation]] (QA Tools support for MCTS)

== Documentation ==

Please make sure that all the relevant documentation regarding the tools is kept up-to-date whenever you update any of the tools. Please consider the end users of the tool as the primary readers of the documentation and make the documentation task-oriented for end user needs. Separate developer documentation can exist as well.

'''Wiki guidelines'''

Every tool should have a wiki page that contains at least 1) Overview of the tool and its benefits 2) Installation instructions 3) Basic use tutorial 4) Contact information.

Make sure that you are familiar with [[Wiki contribution guidelines|MeeGo wiki contribution guidelines]] before creating new content. Currently, there are quite a lot problems relating to e.g. page names, wiki links, deep hierarchies and obsolete pages in our wiki section.

'''Documentation checklist'''

The following table lists the tool-specific documentation that should exist (marked with 'x'). These should be checked frequently and more in depth in the future. Bugs will be filed for the missing or inaccurate documentation (marked as 'NOK' i.e. "Not OK").

{| border="1" cellspacing="0"
|+
|'''Tool''' ||'''Doxygen'''||'''Help''' ||'''Man pages''' || '''Wiki'''
|-
| test-definition || || || || x Checked: asinnela 2011-03-03
|-
| testrunner-lite || x || x Checked: asinnela 2011-03-07 || x Checked: asinnela 2011-03-07, NOK [http://bugs.meego.com/show_bug.cgi?id=14074 Bug 14074] || x Checked: asinnela 2011-03-07, NOK [http://bugs.meego.com/show_bug.cgi?id=14073 Bug 14073]
|-
| Testrunner || x || x Checked: asinnela 2011-03-07 || || x Checked: asinnela 2011-03-07
|-
| Testplanner || x || x Checked: asinnela 2011-03-10 || || x Checked: asinnela 2011-03-07
|-
| eat - enables automated testing || || || || x Checked: asinnela 2011-03-08
|-
| OTS - Open Test System || x || x || x || x Checked: asinnela 2011-03-25
|-
| MIN test framework || x || x || x ||
|-
| Scripts and utils || || || || x Checked: asinnela 2011-03-11
|-
| MeeGo Fast Feedback Testing || x || x || || x Checked: asinnela 2011-03-11
|-
| Qpid C wrapper library - libcqpid || x || || || x Page created, content to be added.
|}

'''Other documentation'''

* [[Quality/QA-tools/Autotest-guide|Autotest-Guide]]
* [[Quality/QA-tools/How_to_set_up_repositories|How to set up the repositories that are needed to install QA tools]]

== Meetings ==

All meetings will be held in <code>#meego-meeting</code> on <code>irc.freenode.net</code>.

* Team meetings
** QA-tools weekly meetings are held on every Tuesday 08:00 UTC in #meego-meeting2 on irc.freenode.net (please note the "2") from May 3rd 2011 onwards.
** [[Quality/QA-tools/Meetings|Meeting agendas and minutes]]

* Architecture meetings
** Architecture meetings will be held on-demand basis.
** [[Quality/QA-tools/Arch-Meetings|Meeting agendas and minutes]]

* Workshops
** Face-2-face meetings within the team.
** [[Quality/QA-tools/Workshops|Meeting agendas and minutes]]

== Collaboration spaces ==

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://lists.meego.com/listinfo/meego-dev meego-dev@meego.com mailing list], please prefix with 'QA-tools' for team related topics.
** Please also poke team members or Ville Ilvonen either by email or on IRC because of high traffic @ meego-dev
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
** [http://timoph.fi/qa-tools-stats/ Old #meego-qa-tools statistics]
** [http://timoph.fi/qa-tools-logs-archive/ Archived #meego-qa-tools logs]
* Gitorious team, http://meego.gitorious.org/meego-quality-assurance/
* [http://www.youtube.com/user/meegoqatools Youtube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]
* MeeGo OBS - devel:quality
* This wiki area
* [[Quality/QA-tools/ServiceOS|ServiceOS]]
* [[Quality/QA-tools/PXEInstall|PXEInstallation]]

== Team members ==

The current team members are (in no particular order):

{| border="1" cellspacing="0"
|+
| '''Name'''
| '''Role'''
| '''Affiliation'''
| '''IRC nickname'''
|-
| Riku Halonen || Team member || Nokia || rikhalon
|-
| Kari Sievi || Team member || Digia || sievi
|-
| Timo Härkönen || Team member || Digia || timoph
|-
| Carol Rus || Team member || Digia || carrus
|-
| Sami Lahtinen || Team member || Digia || slahtinen
|-
| Raimo Gratseff || Team member || Digia || rrraimo
|-
| Kyösti Ranto || Team member || Digia || kyranto
|-
| Joonas Kylänpää || Team member || Digia || Kaadlajk
|-
| Timo Mäkimattila || Team member || Digia || timakima
|-
| Elias Luttinen || Team member || Digia || eluttine
|-
| Ville Niutanen || Team member || Digia || Villen
|-
| Vesa Poikajärvi || Team member || Digia || vesse
|-
| Alexey Kuznetsov || Team member || Digia || alkuznet
|-
| Daniil Chuiko || Team member || Digia || dachuiko
|-
| Jarmo Savinen || Team member || Digia || jasavi
|-
| Sampo Saaristo || Team member || Sofica || sampos
|-
| Ling Yu || Team member || Intel || -
|-
| Jing Wang || Team member || Intel || -
|-
| Tuomo Mäkinen || Team member || Ixonos || -
|-
| Jouni Leppäkases || Team member || Ixonos || jouni
|-
| Jarno Keskikangas || Team member || Leonidas || jakeskik
|-
| Janne Hietamäki || Team member || Leonidas || _janne
|-
| Sami Hangaslammi || Team member || Leonidas || sahangas
|-
|}

 
[[Category:QA]]

Quality/QA-tools/OTS

2011-05-02T06:29:56Z

Eluttine: /* Introduction */

= OTS Index =

Welcome to the Open Test System (OTS) Wiki Index.

== Introduction ==

OTS is the '''Open Test System''' for testing software systems on evolving hardware architectures.

It was born out of the test framework incrementally developed for use on [http://maemo.org/ Maemo] project and is in use for 24/7 testing service by [http://www.nokia.com/ Nokia].

More detailed info can be found from [[Quality/QA-tools/OTS/About|about]] page.

== Releases ==

Current release [http://meego.gitorious.org/meego-quality-assurance/ots tag 0.8.4]. See [[Quality/QA-tools/OTS/UserDocumentation/Upgrading|upgrading]] instructions!

Next release [https://bugs.meego.com/show_bug.cgi?id=16861 0.8.5]

See OTS [[Quality/QA-tools/OTS/Roadmap| roadmap.]]

== Documentation ==

* [[Quality/QA-tools/OTS/UserDocumentation | User Documentation]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation | Installation Ubuntu]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation_rpm | Installation RPM]]
** [[Quality/QA-tools/OTS/UserDocumentation/Upgrading | Upgrading]]
* [[Quality/QA-tools/OTS/DeveloperDocs | Developer Documentation]]
* [[Quality/QA-tools/OTS/AdminDocs | System Administration]]
* [[Quality/QA-tools/OTS/Glossary | Glossary]]

Quality/QA tools development

2011-05-02T06:27:13Z

Eluttine: /* Tools and Maintainers */

= QA tools development =

This page provides information on the development activities and practices of QA tools. The focus is on presenting things that are relevant for people interested in developing the tools. The main page for the end users is [[Quality/QA-tools|here]].

Anyone is welcome to contribute and non-member contributions will be treated with same process and review as member contributions. We follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines]. In addition, you may take personal clone from our [http://meego.gitorious.org/meego-quality-assurance/ git repositories] and create merge request. Tool maintainers in our projects will review your contributions and decide on merge.

'''Targets:'''

* Improve MeeGo test reporting tools - target from MeeGo Quality Assurance
* Improve MeeGo test automation (execution and software installation) - target from MeeGo release engineering

"As Core OS release release manager I want to verify trunk:testing packages frequently so that I know the quality of nightly/weekly releases."

== Tools and Maintainers ==

Tool maintainers are selected based on developer experience with particular tool/package or seniority. Tool maintainers have been agreed [[Quality/QA-tools/Meetings|in the QA-tools meeting]] Tuesday September 7th 2010. Changes, if needed, are discussed also there.

In practice only tool maintainers will have commit and review right to particular repository - later several people may have rights to repository based on merit (as proposed by tool maintainer). Others must follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines] to submit patches or personal clone + merge request approach.

The maintainer of the tree shall update the changelog.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Gitorious'''||'''Maintainer''' ||'''Substitute'''
|-
| [[Quality/QA-tools/Test-definition|test-definition]]||[http://meego.gitorious.org/meego-quality-assurance/test-definition Gitorious] || Sampo Saaristo || Timo Härkönen
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||[http://meego.gitorious.org/meego-quality-assurance/testrunner-lite Gitorious] || Sampo Saaristo || Kyösti Ranto
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || [http://meego.gitorious.org/meego-quality-assurance/testrunner Gitorious] || Kyösti Ranto || Timo Härkönen
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] ||[http://meego.gitorious.org/meego-quality-assurance/testplanner Gitorious] || Kyösti Ranto || N/A
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] ||[http://meego.gitorious.org/meego-quality-assurance/enables-automated-testing Gitorious] || Timo Härkönen || Timo Mäkimattila
|-
| [[Quality/QA-tools/OTS|OTS - Open Test System]] ||[http://meego.gitorious.org/meego-quality-assurance/ots Gitorious] || Elias Luttinen || Ville Niutanen
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||[http://gitorious.org/qa-tools/meego-ai Gitorious] || Timo Härkönen || N/A
|-
| [[Quality/TestSuite/MCTS|MeeGo Core Test Suite]] || [http://meego.gitorious.org/meego-quality-assurance/mcts/ Gitorious] ||Matti Salmi || Jeff Zheng
|-
| [[Quality/Netbook Test Suite and Utilities|MeeGo Netbook Test Suite]] || [http://gitorious.org/qa-tools/mnts/ Gitorious] ||Jeff Zheng || N/A
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] || [http://gitorious.org/qa-tools/qtuitest-mbt-adapter Gitorious] || Riku Halonen || N/A
|-
| [http://min.sourceforge.net/ MIN test framework] || [http://meego.gitorious.org/meego-quality-assurance/min Gitorious] || Sampo Saaristo || Timo Mäkimattila
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || [http://gitorious.org/TDriver Gitorious] || Petri Kiiskinen || Tatu Lahtela
|-
| Rich Core dumper || [http://meego.gitorious.org/meego-quality-assurance/rich-core Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter settings || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter-settings-public Gitorious] || Carol Rus || Raimo Gratseff
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] || [http://meego.gitorious.org/meego-quality-assurance/hat-control Gitorious] || Marko Junttila || Riku Halonen
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || [http://meego.gitorious.org/meego-quality-assurance/qa-reports Gitorious] || Sami Hangaslammi || Jarno Keskikangas
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] || [http://meego.gitorious.com/meego-quality-assurance/scripts-and-utils Gitorious] || N/A || N/A
|-
| [[Quality/TestSuite/handset-test-suite/handset-ux-test_Releases | handset_ux_tests]] || [http://meego.gitorious.com/meego-quality-assurance/handset-ux-tests Gitorious] || JessicaJi || N/A
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] || [http://meego.gitorious.org/meego-quality-assurance/meego-testing-hudson-plugin Gitorious] || Alexey Kuznetsov || Timo Härkönen
|-
| Service OS based Flasher || [http://meego.gitorious.org/meego-quality-assurance/meego-ai-serviceos Gitorious] || Jing Wang || N/A
|-
| [[Quality/QA-tools/Qpid C wrapper|Qpid C wrapper library - libcqpid]] || [http://meego.gitorious.org/meego-quality-assurance/libcqpid Gitorious] || Sami Lahtinen || N/A
|}

If you are interested in the user experience work regarding these tools, you can find more information [[Quality/QA-tools/User experience|here]].

=== Overview ===

The figure below tries to summarize the relations and tasks of the tools when used in test automation context.

[[File:testautomationtools.png]]

xfig file:[[File:qatools.fig]]

== Release Practices ==

Here is the workflow for QA tools release practices.

{| border="1" cellspacing="0"
|+
|'''Role'''
|'''Description'''
|-
| Developer || Anyone who wants to participate in qa-tools development
|-
| VCS Maintainer || Component owner who has commit rights in version control system (VCS)
|-
| Package Maintainer || Integrator whose responsibility is the OBS packaging
|-
| Release Management || Third party who is responsible of trunk:testing releases(?)
|}

[[File:Release.png]]

Kivio file: [[File:Release.flw]]

# Developer creates merge request(s) in gitorious.
# VCS Maintainer tests and accepts merge requests.
# VCS Maintainer checks/updates change logs.
# VCS Maintainer tags a version.
# VCS maintainer sends email to [http://lists.meego.com/pipermail/meego-qa/ meego-qa mailing list] based on the following template
Topic: Integration request: package-name version
PACKAGE: package-name
TAG: tag name
URL: link to sources
CHANGES: short description of changes containing bugs.meego.com bug numbers of fixed bugs
# Package maintainer updates the OBS package.
# Package maintainer tests the OBS package.
# If the package belongs to tools:testing and passes testing, Package Maintainer may accept it. If the package belongs to trunk:testing, Package Maintainer creates a promotional request to Release Management. (If the package belongs to both repositories, we let the Release Management set bugs fixed by the package to RELEASED state).
# Host side tools are updated to tools:testing after verifying functionality
# Package maintainer replies to meego-qa list about the actions done with the updated package. e.g. 'Updated in devel:quality and sent promotion request to testing'
# Release Management accepts the package. Or not. (Follow meego-packaging and meego-commits.)

''' YouTube videos '''

YouTube is a good way to communicate new features. You can find existing demo videos on [http://www.youtube.com/user/meegoqatools meegoqatools channel on Youtube].

If you shoot a video to YouTube, promote it on meego-qa mailing list!

You can find some hints how to shoot, edit, and upload a video here: [[YouTube_Hints]]

=== Release checklist ===
To make sure fixes are released without delay, check that the following conditions are met

# Change logs are updated and contain relevant references to MeeGo bugzilla
# Created obs request include fixes bug numbers from MeeGo bugzilla
# Bugzilla items listed in changes are set as resolved
# Spec file matches [[Packaging/Guidelines|MeeGo packaging guidelines]]
# Rpmlint warnings are either fixed or explained by comments in the spec file. e.g. eat packages install files into root's home and the reasoning for it needs to be explained
# Host side tool packages use the same source tar ball to produce debian and rpm packages

== Roadmap ==

The focus is currently on [[ARM/N900/QA|N900 Developer Edition QA]]. Hence the N900 related list below doesn't have a comprehensive information about target builds or priorities.

When you add a new bug, add correct dependencies to the corresponding roadmap meta bug.

The features in the roadmap are followed with META FEA bugs. The features are split to small tool specific FEA:s that block the feature META bug. The META bug is then the last bug to be closed when the feature is finished. You can also follow the tool bug progression from the dependency trees of the META bugs.

Adding a new feature to the roadmap:
# Add a feature bug describing the main purpose of the feature with META and FEA tags.
# Add separate bugs for each tool specific change
# Add correct dependencies between tool specific bugs (e.g. testrunner bug depends on testrunner-lite bug that depends on test-definition bug...)
# Make all of the bugs block the META bug

A list of defined features:

{| border="1" cellspacing="0"
|+
|'''Feature'''
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12980&hide_resolved=0 Measurement support]
|-
| [https://bugs.meego.com/show_bug.cgi?id=12810 Easy install]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=12454&hide_resolved=0 Parallel testing]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12981&hide_resolved=0 Events feature in automatic testing]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12937&hide_resolved=0 MCTS coverage support]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=12833&hide_resolved=0 Test environment validation]
|-
| [http://bugs.meego.com/showdependencytree.cgi?id=13092&hide_resolved=0 Test equipment control]
|-
| [https://bugs.meego.com/showdependencytree.cgi?id=12971&hide_resolved=0 Qt Creator integration]
|-
| [https://bugs.meego.com/show_bug.cgi?id=13190 A tool that combines Testrunner and Testplanner]
|-
| [[Quality/QA-tools/OTS/Roadmap|OTS releases]]
|}

== Design/ Planning ==

* [[Quality/QA-tools/MCTS test automation design|MCTS Test Automation]] (QA Tools support for MCTS)

== Documentation ==

Please make sure that all the relevant documentation regarding the tools is kept up-to-date whenever you update any of the tools. Please consider the end users of the tool as the primary readers of the documentation and make the documentation task-oriented for end user needs. Separate developer documentation can exist as well.

'''Wiki guidelines'''

Every tool should have a wiki page that contains at least 1) Overview of the tool and its benefits 2) Installation instructions 3) Basic use tutorial 4) Contact information.

Make sure that you are familiar with [[Wiki contribution guidelines|MeeGo wiki contribution guidelines]] before creating new content. Currently, there are quite a lot problems relating to e.g. page names, wiki links, deep hierarchies and obsolete pages in our wiki section.

'''Documentation checklist'''

The following table lists the tool-specific documentation that should exist (marked with 'x'). These should be checked frequently and more in depth in the future. Bugs will be filed for the missing or inaccurate documentation (marked as 'NOK' i.e. "Not OK").

{| border="1" cellspacing="0"
|+
|'''Tool''' ||'''Doxygen'''||'''Help''' ||'''Man pages''' || '''Wiki'''
|-
| test-definition || || || || x Checked: asinnela 2011-03-03
|-
| testrunner-lite || x || x Checked: asinnela 2011-03-07 || x Checked: asinnela 2011-03-07, NOK [http://bugs.meego.com/show_bug.cgi?id=14074 Bug 14074] || x Checked: asinnela 2011-03-07, NOK [http://bugs.meego.com/show_bug.cgi?id=14073 Bug 14073]
|-
| Testrunner || x || x Checked: asinnela 2011-03-07 || || x Checked: asinnela 2011-03-07
|-
| Testplanner || x || x Checked: asinnela 2011-03-10 || || x Checked: asinnela 2011-03-07
|-
| eat - enables automated testing || || || || x Checked: asinnela 2011-03-08
|-
| ots - open testing system || x || x || x || x Checked: asinnela 2011-03-25
|-
| MIN test framework || x || x || x ||
|-
| Scripts and utils || || || || x Checked: asinnela 2011-03-11
|-
| MeeGo Fast Feedback Testing || x || x || || x Checked: asinnela 2011-03-11
|-
| Qpid C wrapper library - libcqpid || x || || || x Page created, content to be added.
|}

'''Other documentation'''

* [[Quality/QA-tools/Autotest-guide|Autotest-Guide]]
* [[Quality/QA-tools/How_to_set_up_repositories|How to set up the repositories that are needed to install QA tools]]

== Meetings ==

All meetings will be held in <code>#meego-meeting</code> on <code>irc.freenode.net</code>.

* Team meetings
** QA-tools weekly meetings are held on every Tuesday 08:00 UTC in #meego-meeting2 on irc.freenode.net (please note the "2") from May 3rd 2011 onwards.
** [[Quality/QA-tools/Meetings|Meeting agendas and minutes]]

* Architecture meetings
** Architecture meetings will be held on-demand basis.
** [[Quality/QA-tools/Arch-Meetings|Meeting agendas and minutes]]

* Workshops
** Face-2-face meetings within the team.
** [[Quality/QA-tools/Workshops|Meeting agendas and minutes]]

== Collaboration spaces ==

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://lists.meego.com/listinfo/meego-dev meego-dev@meego.com mailing list], please prefix with 'QA-tools' for team related topics.
** Please also poke team members or Ville Ilvonen either by email or on IRC because of high traffic @ meego-dev
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
** [http://timoph.fi/qa-tools-stats/ Old #meego-qa-tools statistics]
** [http://timoph.fi/qa-tools-logs-archive/ Archived #meego-qa-tools logs]
* Gitorious team, http://meego.gitorious.org/meego-quality-assurance/
* [http://www.youtube.com/user/meegoqatools Youtube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]
* MeeGo OBS - devel:quality
* This wiki area
* [[Quality/QA-tools/ServiceOS|ServiceOS]]
* [[Quality/QA-tools/PXEInstall|PXEInstallation]]

== Team members ==

The current team members are (in no particular order):

{| border="1" cellspacing="0"
|+
| '''Name'''
| '''Role'''
| '''Affiliation'''
| '''IRC nickname'''
|-
| Riku Halonen || Team member || Nokia || rikhalon
|-
| Kari Sievi || Team member || Digia || sievi
|-
| Timo Härkönen || Team member || Digia || timoph
|-
| Carol Rus || Team member || Digia || carrus
|-
| Sami Lahtinen || Team member || Digia || slahtinen
|-
| Raimo Gratseff || Team member || Digia || rrraimo
|-
| Kyösti Ranto || Team member || Digia || kyranto
|-
| Joonas Kylänpää || Team member || Digia || Kaadlajk
|-
| Timo Mäkimattila || Team member || Digia || timakima
|-
| Elias Luttinen || Team member || Digia || eluttine
|-
| Ville Niutanen || Team member || Digia || Villen
|-
| Vesa Poikajärvi || Team member || Digia || vesse
|-
| Alexey Kuznetsov || Team member || Digia || alkuznet
|-
| Daniil Chuiko || Team member || Digia || dachuiko
|-
| Jarmo Savinen || Team member || Digia || jasavi
|-
| Sampo Saaristo || Team member || Sofica || sampos
|-
| Ling Yu || Team member || Intel || -
|-
| Jing Wang || Team member || Intel || -
|-
| Tuomo Mäkinen || Team member || Ixonos || -
|-
| Jouni Leppäkases || Team member || Ixonos || jouni
|-
| Jarno Keskikangas || Team member || Leonidas || jakeskik
|-
| Janne Hietamäki || Team member || Leonidas || _janne
|-
| Sami Hangaslammi || Team member || Leonidas || sahangas
|-
|}

 
[[Category:QA]]

Quality/QA-tools/OTS

2011-04-29T13:08:25Z

Eluttine: /* Releases */

= OTS Index =

Welcome to the Open Test System (OTS) Wiki Index.

== Introduction ==

OTS is the '''Open Test Service''' for testing software systems on evolving hardware architectures.

It was born out of the test framework incrementally developed for use on [http://maemo.org/ Maemo] project and is in use for 24/7 testing service by [http://www.nokia.com/ Nokia].

More detailed info can be found from [[Quality/QA-tools/OTS/About|about]] page.

== Releases ==

Current release [http://meego.gitorious.org/meego-quality-assurance/ots tag 0.8.4]. See [[Quality/QA-tools/OTS/UserDocumentation/Upgrading|upgrading]] instructions!

Next release [https://bugs.meego.com/show_bug.cgi?id=16861 0.8.5]

See OTS [[Quality/QA-tools/OTS/Roadmap| roadmap.]]

== Documentation ==

* [[Quality/QA-tools/OTS/UserDocumentation | User Documentation]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation | Installation Ubuntu]]
** [[Quality/QA-tools/OTS/UserDocumentation/Installation_rpm | Installation RPM]]
** [[Quality/QA-tools/OTS/UserDocumentation/Upgrading | Upgrading]]
* [[Quality/QA-tools/OTS/DeveloperDocs | Developer Documentation]]
* [[Quality/QA-tools/OTS/AdminDocs | System Administration]]
* [[Quality/QA-tools/OTS/Glossary | Glossary]]

Quality/QA-tools/OTS/Roadmap

2011-04-29T09:36:51Z

Eluttine: /* OTS 0.8 */

= OTS Roadmap =

All features and bugs are listed in [https://bugs.meego.com/buglist.cgi?classification=MeeGo%20Projects&query_format=advanced&component=ots&product=MeeGo%20Quality%20Assurance bugs.meego.com]

Releases are available in bugzilla: 

{{#bugzilla:
|columns=id,summary
|component=ots
|search=META
|depends=*
|sort=summary
}}

== OTS 0.9 ==

[https://bugs.meego.com/showdependencytree.cgi?id=10866&hide_resolved=0 Status]

This release aims to collate the features of 6Pack and OTS.

The Conductor will be the main focus with particular attention paid to the variation points in the architecture and configurability.

Aim to have Python APIs in the Conductor (rather than the CL)

Study the viability of lower level extension points on the test results.

'''In progress'''

=== Goals ===

* Bring reliability of ots.server up to 0.1 standards
* A more coherent system
* 6Pack integration
* APIs are enough for 3rd party plugin development in ots.server
* Create small releases 0.8.1, 0.8.2 and so on

== OTS 0.8 ==

This release aims to address the issues that will naturally arise in moving from a closed source system maintained in-house to a widely distributed Open Source system. i.e. documentability support, a code base that supports distributed development.

'''Released on 28th of January 2011.'''

=== Goals ===

* Good developer documentation
* No functional changes from 0.1 release
* APIs are stable enough for 3rd party plugin development in ots.server

== OTS 0.1 ==

This release is based on legacy code. Only minor refactoring is done. API:s are subject to change and development documentation will be very limited.

'''Released on 28th of september 2010.'''

=== Goals ===

* Fully functioning test system with installation documentation.
* Anybody can setup an OTS instance and execute testruns.
* Development moved to open source mode.

Quality/QA-tools/hat-control

2011-04-07T11:11:25Z

Eluttine: /* Using HAT SW to control usb and power switches. */

== HAT Device ==

[[File:HAT_purkki1.jpg]]

HAT device is test hardware to PC USB interface, which allows accurate measurements from DUT. Device has two switchable power outputs and two switchable USB paths. The power and data lines of the USB can switched on or off separately. HAT device has also four sensor inputs for different sensors. Currently only current measurement sensor is available, but other sensors will be available soon. Sensor inputs without sensor HW can be directly used to measure voltage levels if needed.

[[File:Hw_concept.jpg]]

== HAT device specs ==

'''Sensors inputs:'''
*Analog input resolution is 12bit at 10kHz (for one channel. For two channels 10kHz/2 = 5kHz)
*Analog input voltage range 0 - 2.44V
*Input impedance ~1Mohm
*Sensor inputs have one digital output line (TTL) for controlling sensor (e.g sensor gain)
'''USB:'''
*Data+ and data- lines can swithced off or on.
*Power line can be swithced off or on.
*Maximum current 500mA
*LED indicates data lines switch state.
'''Power'''
*Absolute maximum input voltage 20V
*Absolute maximum input current 1.5A
*Two power outputs.
*LED indicates power line switch state.

== HAT-control ==

HAT-control is software that is used to control HAT (Hardware Accessory for Testing) device. SW contains two applications. Driver (hat_drv) application controls HAT device via USB. The control SW (hat_ctrl) controls HAT device using driver. Communication between driver and control processes is done using shared memory.

== SW Installation ==

HAT-control sw can be installed to Ubuntu 10.04. It should work also other distributions, but it is not tested yet.

HAT SW dependences:

* libusb-1.0.8
* liblabjackusb
* glib-2.0

'''Libusb installation:'''

1. Install libusb-1.0.x package:

sudo apt-get install libusb-1.0

'''glib-2.0 installation:'''

1. Install glib-2.0 package:

sudo apt-get install libglib2.0-dev

'''Liblabjackusb installation:'''

1. Get exodriver sources:

git clone https://github.com/labjack/exodriver.git

2. Go liblabjackusb folder

$ cd exodriver/liblabjackusb

3. Build library

$ make

4. Install library

$ sudo make install

5. Liblabjackusb needs access to the /dev/bus/usb. Run following commands in labjack-exodriver root folder.

$ cd ..
$ sudo cp 10-labjack.rules /etc/udev/rules.d
$ sudo udevadm control --reload-rules

'''Building HAT SW'''

1. Build HAT SW:

Get sources using git (or some otherway):

$ git clone git://gitorious.org/meego-quality-assurance/hat-control.git

Go to hat-control folder and compile sources (autoconf, automake, libtool and pkg-config are required)

$ autoreconf -i
$ ./configure --prefix=/usr
$ make
$ sudo make install

== Using HAT SW to control usb and power switches. ==

1. Connect HAT device to USB port and start HAT driver.

$ hat_drv &

Driver should print 'hat_drv: HAT driver started succesfully', if it has started succesfully.
It also shows serial numeber of the controller device.

2. Use hat_ctrl SW to control HAT device. For example switch power output 1 on

$ hat_ctrl -pwr1=on

Get all parameters just type

$ hat_ctrl --help

== New features ==

'''Multiple HAT support'''

Multiple HAT support will be added in couple of weeks. HAT driver and control software will have new parameter "-SN [SerialNumber]" which will specify the HAT device. When you have only one HAT device, you don't need to add "-SN" parameter. So, no modifications to excistence setup is needed if used only one HAT device.

'''New current sensor'''

The HAT Current Sensor can be used with HAT device by connecting it to one of the sensor inputs of HAT device. The sensor can be used for measuring the current from the device under test (DUT). The sensor has two measurement ranges, 0-100mA and 0-1.5A. The range is software selectable.

== Further development ==

HAT SW is now very early state. There might be major changes in the near future. Command line parameters might change in near future.

Quality/QA-tools/hat-control

2011-04-07T11:08:45Z

Eluttine: /* SW Installation */

== HAT Device ==

[[File:HAT_purkki1.jpg]]

HAT device is test hardware to PC USB interface, which allows accurate measurements from DUT. Device has two switchable power outputs and two switchable USB paths. The power and data lines of the USB can switched on or off separately. HAT device has also four sensor inputs for different sensors. Currently only current measurement sensor is available, but other sensors will be available soon. Sensor inputs without sensor HW can be directly used to measure voltage levels if needed.

[[File:Hw_concept.jpg]]

== HAT device specs ==

'''Sensors inputs:'''
*Analog input resolution is 12bit at 10kHz (for one channel. For two channels 10kHz/2 = 5kHz)
*Analog input voltage range 0 - 2.44V
*Input impedance ~1Mohm
*Sensor inputs have one digital output line (TTL) for controlling sensor (e.g sensor gain)
'''USB:'''
*Data+ and data- lines can swithced off or on.
*Power line can be swithced off or on.
*Maximum current 500mA
*LED indicates data lines switch state.
'''Power'''
*Absolute maximum input voltage 20V
*Absolute maximum input current 1.5A
*Two power outputs.
*LED indicates power line switch state.

== HAT-control ==

HAT-control is software that is used to control HAT (Hardware Accessory for Testing) device. SW contains two applications. Driver (hat_drv) application controls HAT device via USB. The control SW (hat_ctrl) controls HAT device using driver. Communication between driver and control processes is done using shared memory.

== SW Installation ==

HAT-control sw can be installed to Ubuntu 10.04. It should work also other distributions, but it is not tested yet.

HAT SW dependences:

* libusb-1.0.8
* liblabjackusb
* glib-2.0

'''Libusb installation:'''

1. Install libusb-1.0.x package:

sudo apt-get install libusb-1.0

'''glib-2.0 installation:'''

1. Install glib-2.0 package:

sudo apt-get install libglib2.0-dev

'''Liblabjackusb installation:'''

1. Get exodriver sources:

git clone https://github.com/labjack/exodriver.git

2. Go liblabjackusb folder

$ cd exodriver/liblabjackusb

3. Build library

$ make

4. Install library

$ sudo make install

5. Liblabjackusb needs access to the /dev/bus/usb. Run following commands in labjack-exodriver root folder.

$ cd ..
$ sudo cp 10-labjack.rules /etc/udev/rules.d
$ sudo udevadm control --reload-rules

'''Building HAT SW'''

1. Build HAT SW:

Get sources using git (or some otherway):

$ git clone git://gitorious.org/meego-quality-assurance/hat-control.git

Go to hat-control folder and compile sources (autoconf, automake, libtool and pkg-config are required)

$ autoreconf -i
$ ./configure --prefix=/usr
$ make
$ sudo make install

== Using HAT SW to control usb and power switches. ==

1. Connect HAT device to USB port and start HAT driver.

$ cd src
$ hat_drv &

Driver should print 'hat_drv: HAT driver started succesfully', if it has started succesfully.
It also shows serial numeber of the controller device.

2. Use hat_ctrl SW to control HAT device. For example switch power output 1 on

$ hat_ctrl -pwr1=on

Get all parameters just type

$ hat_ctrl --help

== New features ==

'''Multiple HAT support'''

Multiple HAT support will be added in couple of weeks. HAT driver and control software will have new parameter "-SN [SerialNumber]" which will specify the HAT device. When you have only one HAT device, you don't need to add "-SN" parameter. So, no modifications to excistence setup is needed if used only one HAT device.

'''New current sensor'''

The HAT Current Sensor can be used with HAT device by connecting it to one of the sensor inputs of HAT device. The sensor can be used for measuring the current from the device under test (DUT). The sensor has two measurement ranges, 0-100mA and 0-1.5A. The range is software selectable.

== Further development ==

HAT SW is now very early state. There might be major changes in the near future. Command line parameters might change in near future.

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:42:05Z

Eluttine: /* Triggering a chroot test */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install OTS trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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 [[Quality/QA-tools/TDriver|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 [[Image_Creation|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

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:39:34Z

Eluttine: /* Using conductor */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install OTS trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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 [[Quality/QA-tools/TDriver|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 [[Image_Creation|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 file

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

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:39:14Z

Eluttine: /* Using ots_trigger */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install OTS trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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 [[Quality/QA-tools/TDriver|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 [[Image_Creation|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 file

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

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:37:26Z

Eluttine: /* Using ots_trigger */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install ots_trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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 [[Quality/QA-tools/TDriver|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 [[Image_Creation|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 file

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

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:36:25Z

Eluttine: /* Running tests in chroot environment */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install ots_trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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 [[Quality/QA-tools/TDriver|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 [[Image_Creation|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 file

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

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:35:17Z

Eluttine: /* Running tests in chroot environment */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install ots_trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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. Chrooted based testing is primarily targeted at executing tests with the [[Quality/QA-tools/TDriver|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 [[Image_Creation|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 file

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

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:02:05Z

Eluttine: /* Test plan based executions */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install ots_trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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.

=== How to create rootstrap? ===

Basically you can use any i386 chroot environment you like, but MeeGo Netbook edition is good starting point. First [[Image_Creation|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 file

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

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:01:48Z

Eluttine: /* Test plan based executions */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install ots_trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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.

=== How to create rootstrap? ===

Basically you can use any i386 chroot environment you like, but MeeGo Netbook edition is good starting point. First [[Image_Creation|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 file

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

Quality/QA-tools/OTS/UserDocumentation/Usage

2011-04-04T08:00:50Z

Eluttine: /* How to create rootstrap? */

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

[[Quality/QA-tools/OTS/UserDocumentation/Installation#OTS_tools| How to install ots_trigger]].

Before you can trigger a testrun, you need to have all following:
* OTS server up-and-running [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* OTS worker with hardware configured [http://wiki.meego.com/Quality/QA-tools/OTS/UserDocumentation#Installation]
* Image with eat-device package (enabled test automation environment to hardware) [http://wiki.meego.com/Quality/QA-tools/Autotest-guide]

And one of the following options:
* Test package installed to the device
* Test package installed to the ots-worker or
* Test plan [TODO LINK]

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.

The user can create the test plan with [http://wiki.meego.com/Quality/QA-tools/Testplanner 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 [[Quality/QA-tools/OTS/Plugins/History|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.

=== How to create rootstrap? ===

Basically you can use any i386 chroot environment you like, but MeeGo Netbook edition is good starting point. First [[Image_Creation|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 file

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