A
test suite XML parser
In this section all defined
test suite XML elements are presented. If an element allows or needs child elements these are listed in brackets behind the element name. Each child element can be followed by a character that describes its usage:
- '*' : Element has not to be present and can be repeated several times
- '+' : At least one element of this kind has to be present
- '?' : No or one element of this kind have to be present If no limitation character is noted the element has to be present one time.
An email address
- Example:
<address>test@foo.bar</address>
This element contains the
test users authentication name. It can differ from the user name but often user name and authentication name are the same.
- Example:
<authname>auth_testuser001</authname>
This element represents an attribute-value pair (AVP) of a
test user.
- Attributes:
- Example:
<avp name="email">user@iptel.org</avp>
The configuration element stores
test suite configuration (global) as well as the configuration of the
test cases (local). For every
test case the local configuration can be overwritten and will be used only for the run time of this
test case.
- Example:
<configuration>
<global>
...
</global>
<local>
...
</local
</configuration>
To use a database adapter it has to be specified with this element. It can be only one database adapter defined per
test suite.
- Example:
<dbadapter>
<type>SerctlAdapter</type>
<arg name="serctlPath">/var/serctl/</arg>
<arg name="dbUrl">mysql://ser:heslo@localhost/ser</arg>
</dbadapter>
The domain a
test user belongs to.
- Example:
<domain>iptel.org</domain>
The data needed to send the
test protocol by email.
- Example:
<email>
<address>...</address>
<subject>...</subject>
<smtpaddress>...</smtpaddress>
<smtpport>...</smtpport>
</email>
In the global element configuration data needed for setting up the
test suite is stored.
- Example:
<global>
<users>
...
</users>
<dbadapter>
...
</dbadapter>
</global>
In the local element configuration data needed for setting up
test cases is stored. This element is defined as a container for any kind of sub elements. This means that sub elements can be defined by the user and used in the
test cases. A number of sub elements is already defined because they are needed in the existing
test cases.
- Example:
<local>
<target>
...
</target>
<interface>...</interface>
<modules>
...
</modules>
</local>
This element stores the logging configuration data.
- Example:
<logging>
<email>
...
</email>
<logfilepath>...</logfilepath>
</logging>
The password of a
test user.
- Example:
<password>pass</password>
The realm of a
test user.
The ip address or url of a smtp server.
- Example:
<smtpaddress>smtp.foo.bar</smtpaddress>
The port of a smtp server.
The subject for an email.
- Example:
<subject>Hello World</subject>
The testcase element contains the definition of a
test cases environment. Therefore the local configuration of the
test suite (or parts of it) can be overwritten. This new local configuration is only for this
test case. Furthermore a number of
test users can be defined. These users will be autmatically inserted into a database if this feature is active for the
test suite and they will be written into files needed by this
test case.
- Attributes:
- name : name of test case
- uri : test case uri
- Example:
<testcase name="TestBasicCall" uri="features.basic.call">
<configuration>
...
</configuration>
<testuser ...>
...
</testuser>
<testuser ...>
...
</testuser>
</testcase>
A
test group is a structural element containing a number of
test cases. The semantical separation of
test cases into
test groups makes easier to handle them and the
test protocol more readable.
Test groups have neither effect on the behavior of
test cases nor any influence to the performance of a
test suite.
- Attributes:
- name : name of test group
- Example:
<testgroup name="dialing">
<testcase ...>
...
</testcase>
<testcase ...>
...
</testcase>
</testgroup>
This element is the top element of a
test suite XML file. It contains the definition of a
test suite and the definition of its
test groups and
test cases. The global and the default local configuration as well as parameters for logging can be set under this element.
- Attributes:
- name : name of test suite
- Example:
<testsuite name="osser">
<configuration>
...
</configuration>
<logging>
...
</logging>
<testgroup ...>
...
</testgroup>
<testgroup ...>
...
</testgroup>
</testsuite>
This element contains the definition of
test user needed by a
test case. For every
test user a mode can be set. The mode 'files_only' means that this user is only inserted into the files the
test case needs, 'db_only' stands for inserting the user only into the database (if
test suite supports this feature) and for 'all' the
test user is inserted into files and database (if
test suite supports writing into the database). If the feature "users.static" is active for a
test suite the user is not written into a database even if the mode is 'db_only' or 'all'. The attribute 'prefix' stands for a prefix that is used to write the data into files: If more than one user has to be written into a file they can be distinguished by this prefix (e.g. prefix='u1' then the wildcards in the files have to look like [#U1_USERNAME#]).
- Attributes:
- mode : (all | files_only | db_only)
- prefix :
- Example:
<testuser mode="all" prefix="u1">
<uuid>...</uuid>
<username attribute1="1" attribute2="2">...</username>
<username>...</username>
<authname>...</authname>
<domain>...</domain>
<realm>...</realm>
<password>...</password>
<avp ...>...</avp>
<avp ...>...</avp>
</testuser>
This element specifies the type of the parent element.
One username of a
test user. It can have any number of undefined attributes.
- Example:
<username>testuser001</username>
The uuid of a
test user.
- Example:
<uuid>__test_user_001</uuid>
