Testsuite Editor-Metadata Editor/en

Misc Editor (outdated screenshot - the current version shows more fields)

The misc editor is used to view and edit some miscellaneous settings and additional information for the test suite or (in a readonly version) for imported suites or libraries. It can be found on the "Misc" tab after selecting the test suite in the navigation tree.

To the right, you see an example for an opened misc editor.

Version

Release Name

An optional field for a descriptive name of the test suite's version.

Author

An optional field for the name of the test suite's author (filled in automatically).

Version

This shows an internally generated version number useful to quickly identify the current version. It is constructed from a sequential number and the suite's last edit author. The sequence number will be incremented whenever the suite is saved.

Project File Path

The path to the file from which the current testsuite was loaded. Only used for documentation.

Library Interface

For a concrete library, this field specifies which virtual library interface is implemented by this library. For more information please read the section on virtual blocks and virtual libraries.

Prerequisites

Expecco Version

Allows for the minimum required expecco version for this test suite to be specified. If this suite is loaded into an older expecco, a warn box will appear (this is useful for libraries which call into the expecco API and use functions which are not present in older versions).

Extension Packages

Lists required extension packages from the underlying execution framework. This is especially used by plugin-libraries which require additional low-level DLL functionality. Packages are named using the standard Smalltalk/X package naming scheme (foo:bar/baz/...). For an extension package to be found, it must be located below the expecco installation directory in a directory named "foo/bar/baz/..." under the "packages" subfolder.

Plugin UUIDs

Lists the required plugin id(s). Used by libraries which require a specific plugin to be present. Especially used by plugin-libraries which implement a block interface to the plugin's operations. To verify at package loading time, that any API entries used by extension blocks will be present at execution time.

Load / Unload

Allows for an action to be automatically executed whenever the suite (or import library) is loaded / unloaded. This can be used to check for the availability of hardware, software or to give additional information automatically to a test operator. To use this, simply drag and drop an existing activity block into one of these fields.

Notice: these actions are only executed if the suite is loaded interactively via the user interface. They are (by purpose) not executed when tests are executed automatically (via command line or inside a test-host). There are multiple reasons for this, one being that suites might be composed from multiple files and executed as a single suite, and that the preLoad/postLoad actions are usually meant to either add project specific menu items to the expecco UI, or to perform other test-developer related actions. Executing those on any load of a suite would make the behavior very nondeterministic, especially in view that loaded suites are cached inside expecco when running as a test host for expecco ALM or other QM systems.

GUI Extensions

Allows for a folder full of actions to be attached to expecco's main-menu. If a folder is dropped into that field, all of that folder's actions are presented as menu items in the "Extra" menu. This is very useful to make common functions (calibration, test-setup, tear-down etc.) easily accessible to the test-operator.

The action will be executed whenever the corresponding menu item is selected, independent of any ongoing test executions.

Testplan Execution

Allows for additional pre- and post-execution actions to be automatically executed with any test plan execution. Different actions can be specified depending on the test plan's outcome, for example to trigger further reporting or alarm processing. It may also be used to add actions which send email notifications or which contact a QM-system for automatic issue generation (e.g. into Bugzilla, jira or other bug tracking systems).

Notice: These actions are not logged in the activity-log. Because they are not logged, they should not have any influence on the actual test execution. Especially, they should not be used to setup equipment, protocols etc. Only use them for "meta" operations, such as statistics, reporting, etc.

Pre- and post actions which do affect the test execution should be defined in the testplan, which also provides pre- and post execution hooks.

Also notice: errors in these actions may open a debugger, ignoring your "Open Debugger on Error" settings.

---

Copyright © 2014-2024 eXept Software AG