Kategorie:Tree Elements/en

All elements of a testsuite are organized as a hierarchical tree and are referred to as "Tree Elements" of a test suite. They are displayed and managed in the so-called project- or navigation tree, which is shown on the left of the expecco application. The test suite being edited is shown as the top-element in the tree.

For historical reasons, the Test Suite is also sometimes referred to as "Test Project" or just "Project" in this document.

You can give tree items an arbitrary name. This name is not used within expecco to reference an item (see "IDs"-Section below). Thus, you can change the name of any item at any time without a need to search for uses of the item. Because all references are via the ID, this also applies to any suite which imports your suite, or suites which you have imported. The references will be correct, and new names will appear automatically.

The name can be further translated by a model language translation table, so that both the user interface of expecco and the names attached to items are translated by different translation mapping tables. This makes it possible to present the same model to team users speaking different languages. Notice that the "UI-language" (which is used for Menus, Labels, Buttons etc.) can be different from the "Model Language", which is used to label elements in the tree and diagrams. Both are set via the "Settings" dialog and are stored in your personal settings file.

Each element in the project has two special IDs (Identifiers). One is the so called "Functional-ID" which is assigned once, when the element is created initially and never changed thereafter. The other is the "Version-ID". This is reassigned with every modification. Inside expecco, elements are referred to by their ID, not by name. This makes it easy to change the name at any time later without a need to change other parts of the suite.

The "Version-ID" is used to quickly detect identical elements (for example, when merging projects from different files).

The "Functional-ID" is used when reimporting libraries; i.e. to identify which blocks should be automatically replaced by newer versions.

The name of a tree element is not used by the system to identity elements; this is only used for presentation to the user. By using IDs, reimport, compare and merging of libraries is possible without conflicts or indeterminism, even if elements have been renamed in the meantime.

As described above, the ID of a suite plays a major role in expecco's reimport mechanism (i.e. when you upgrade an imported library to a newer version). Expecco checks if the function-ID of the library-to-be-imported matches the function-ID of the already imported library, and if they match, then reimports all individual action blocks again by using the function-IDs as reimport criteria.

This can be done automatically, and expecco can search for new versions of a given library within a folder, and perform such update-reimports for you. Whenever a suite is saved, the functionID of the suite remains unchanged, and expecco assumes, that you are simply writing a new version of that suite to a file.

However: If you ever save a suite/library under a different name, and use this as the starting-base for a new suite/library, you should also assign a new versionID to that suite before saving. This tells expecco, that your intent is to make this a new suite, which is not to be considered in future reimport operations. On the other hand, if you change the function-ID of a library, it will no longer be considered to be a different version of the library and will refuse the reimport.
The same applies to the IDs of individual actions.

Symbolic tags can be attached to tree elements. The main use of a tag is to group items by function and make finding items in search boxes easier (the search functions provide a check box to enable/disable search by tag).

Some tags affect the behaviour of the editor:

• elements tagged as "obsolete" will not be presented in dialogs to insert or drag&drop new steps.
• elements tagged as "private" will only be presented inside their library/project, but not outside.

In addition, tags can be used to filter tests for execution or to associate colors. For example, the diagram settings dialog allows for particular colors to be attached to particular tags. You can use this to mark critical, obsolete, input/output related or other items by color both in the tree and in activity diagrams. Finally, tags are used to identify GUI actions, and only actions with matching tags are presented in the GUI browser's action/attribute selection trees.

Some tree elements also allow for additional tagged values to be attached to it. Tagged values are tuples consisting of "name", "type", "value" and additional "attributes". For example: ("Foo", Integer, 123, READONLY).

Tagged values are not (currently) used by expecco itself, but may be needed when models are imported or exported from/to other modelling tools, such as Enterprise Architect, Rose etc. Those programs use tagged values to specify stereotypes, connections and other attributes of a model element. When tagged values are attached to an element, these are handled transparently by expecco - i.e. they are not touched and left for other tools to be used. When loading a suite, they are remembered and saved unchanged when the suite is later saved back onto a file.

A testplan contains a list of "test cases", also called "test case items" or "test items" for short. A test case item can be either an action (i.e. a block), or another testplan. Test cases within a test plan are normally executed sequentially, until either the last test case has been executed, or any test case reports a failure or error. However, individual items can be skipped or marked as optional, which means that their outcome does not stop the overall testplan execution.

Please navigate to "Testplan" for more detail on elementary blocks.

A performance test consists of three types of items:

• load generators
• measuring blocks
• test actions

Together, these generate load on the system under test and measure its behavior during the test action execution. Support for performance tests is being developed and an as-yet unpublished feature of expecco.

Libraries are collections of tree items to be reused in other suites or libraries. Libraries can contain any type of element, including test plans, datatypes, attachments, elementary and compound blocks. Libraries can also use and import additional libraries. There is no technical difference between a library and a suite. Any suite can be saved as ".ets" file, and imported by any other suite. When imported, they are found under the "Imports" node in the navigation tree.

Libraries like the Standard Library or the Qt-Interface Library and others are provided by eXept either as part of the standard delivery, or as additional extension, which must be purchased (licensed) separately. However, you can (and usually will) also create your own project-specific libraries. Or provide them as a supplier to a third party, or acquire them from a third party.

Already included in all releases of expecco are the following libraries:

• Standard Library
• Selenium Library

Upon request, other libraries are available. For example:

• Interfaces to specific rich-client GUIs (Qt, Java SWT, Java Swing, Java FX, Android, Windows Mobile, iOS, ST/X, Ranorex)
• Interfaces to specific applications like SAP, Siebel,...
• Interfaces to QM systems, like expecco ALM, Polarion, HP-Quality Center
• Interfaces to Bugtracking systems like JIRA
• Bridges to manipulate and access internals of the System Under Test, if written in Java or a .NET language.
• Databases
• Webservices
• CAN/MOST
• MQTT, Some/IP, ZeroMQ
• GPIB, VISA, OPC
• Importers for test-description/activity diagrams in various formats (Excel, Word, Enterprise Architect, MindMap)
• Various Document and EDI formats (EDIFACT, IDoc, PDF, XML, IDL, etc)