Meego Wiki
Views

Quality/TestSuite/BLTS Common Library

From MeeGo wiki
< Quality | TestSuite(Difference between revisions)
Jump to: navigation, search
(Created page with "== Introduction == Blts-common package (0.4.0) provides common functions used in BLTS test assets gathered in one library. It includes common functionality like: ;*logging ;*tim…")
 
Line 16: Line 16:
=== Building packages ===
=== Building packages ===
-
The blts-common package comes with a packaging script that can be used to build tarball out of the sources, RPM package or Debian package. To build RPM package, in the root directory execute command:
+
{{:Quality/TestSuite/Building_BLTS_Packages}}
-
 
+
-
<pre>
+
-
./pack.sh -r
+
-
</pre>
+
-
 
+
-
To get packaging script help, execute command:
+
-
 
+
-
<pre>
+
-
./pack.sh -h
+
-
</pre>
+
The building environment requires the following RPM packages installed:
The building environment requires the following RPM packages installed:

Latest revision as of 13:53, 17 December 2010

Contents

Introduction

Blts-common package (0.4.0) provides common functions used in BLTS test assets gathered in one library. It includes common functionality like:

  • logging
  • timing
  • checking for required components (kernel modules, libraries, binaries,...)
  • XML result writing
  • configuration file handling
  • command-line frontend (CLI) for test drivers

Limitations

Current common library CLI implementation requires starting tests as root.

Building packages

The source package includes the pack.sh script, which is used for building RPM and Debian packages and source tar packages. To build an RPM package with the script, execute this command in the top level source directory of asset: 

./pack.sh -r

To get help about the packaging script, execute 

./pack.sh -h

The asset can also be built manually by executing: 

./autogen.sh
./configure
make

The building environment requires the following RPM packages installed:

  • flex
  • bison
  • libxml2-devel

Using the common library with BLTS tests

All BLTS test packages have dependency to the blts-common package so it is mandatory and must be installed first. The library package can be installed in the device by executing the command: 

rpm -ivh libbltscommon1_{version}.rpm

Results XML writer part of the common library requires that the test environment must have following package installed:

  • libxml2

The common library command-line frontend offers following general arguments for all BLTS test drivers:

General Switch Function
-l Used log file
-e Execute single or multiple selected tests, for example -e 1,4,5.
-en Execute test by name, for example -en "My test X"
-s Show list of all tests
-C Used configuration file
-? Help message
-xml, -axml Create result XML. -axml appends results to an existing XML file.
-auto Silent logging for test automation. Only the results are printed to stdout.
-v Verbose logging (default)
-vv Even more verbose logging


Using the common library API

The development package can be installed by executing the command: 

rpm -ivh libbltscommon-devel_{version}.rpm

blts-common library can be used with own test modules by doing modifications to configure.ac file: 

# Checks for libraries.
AC_CHECK_LIB([bltscommon], [log_open],,[AC_MSG_ERROR([cannot find libbltscommon])])

# Library configs
BLTS_COMMON_CFLAGS=`pkg-config --cflags bltscommon`
BLTS_COMMON_LIBS=`pkg-config --libs bltscommon`

AC_SUBST(BLTS_COMMON_CFLAGS)
AC_SUBST(BLTS_COMMON_LIBS)

or simply by adding this line: 

PKG_CHECK_MODULES([BLTSCOMMON],[bltscommon])

Using the dependency checker 

#include <blts_dep_check.h>

depcheck(rulesfile,loglevel);

The parameter rulesfile here is a name of a file containing rules to be checked and the parameter loglevel can be value between 0-2.

  • 0 = quiet
  • 1 = log failures
  • 2 = log all

In rules file there must be only one rule per line and the format for a defined rule format is <strictness> <type> <name>

  • <strictness> is one of (required|optional)
  • <type> is one of (kmod|bin|lib|file)
* kmod - kernel module name without path e.g. "g_ether"
* bin - executable binary without path e.g. "aplay"
* lib - shared library name without path e.g. "libfoo.so"
* file - any file with full path
  • <name> depends on type

Example of rules file (used for checking ALSA components): 

required kmod snd_pcm
optional bin aplay
required lib libasound.so
optional file /usr/share/alsa-base/alsa.default

Using logging functions 

#include <blts_log.h>

int blts_log_open(const char *filename, unsigned int flags);  	//open given log file
int blts_log_close();  						//close current log file

void blts_log_set_level(int level); 				//setter for logging level
int blts_log_get_level(); 					//getter for logging level
void blts_log_print_level(int level, const char *format, ...); 	//print to current log file

int blts_log_start_syslog_capture();				//start syslog capture (in child process)
int blts_log_end_syslog_capture();				//stop syslog capture

The common library supports four different logging levels:

  • trace level logging
  • debug level logging
  • warning level logging
  • error level logging

Messages logged with a level other than trace are printed to the log file by default and to stdout when using -v argument. To get trace level messages visible, -vv argument must be used.

The following macros can be used to log messages with a different levels:

  • BLTS_TRACE()
  • BLTS_DEBUG()
  • BLTS_WARNING()
  • BLTS_ERROR()
  • BLTS_LOGGED_PERROR() - errno error level logging

There is also two trace level macros to use for tracking function usage:

  • FUNC_ENTER() - shows when entered to certain function
  • FUNC_LEAVE() - shows when about to exit from function

The syslog_capture functions can be used to log system messages when executing test cases if necessary. The syslog path is hard coded "/var/log/tests/kmsg.log"

CLI frontend example

The blts-common package comes with an example that can used as an starting point when developing own test drivers. The example source codes files are located in subfolder src/blts-cli-example. The CLI frontend example shows also how to use configuration files and parameter variations in your own test drivers. See README.ParameterVariation documentation for the further instructions.

Module Design and Architecture

Both Debian and RPM packaging is provided.

The blts-common package consists of libbltscommon1 runtime library and libbltscommon-devel development library. There is also some example files that show how to use blts-common library.

Architecture diagram

References

blts-common blts-common library

Change History

Version Date Handled By Status Comments
0.1 17-Dec-2010 Aki Nyman Draft Page created (refers to blts-common package 0.4.0)
Retrieved from "http://wiki.meego.com/Quality/TestSuite/BLTS_Common_Library"
Personal tools