- 1 Introduction
- 2 Common Attributes of all Tree Items
- 3 Test Items
- 4 Libraries
- 5 Action Blocks
- 6 Management
- 7 Miscellaneous
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 traditional reasons, the "Test Suite" is also sometimes referred to as "Test Project" or "Project" in this document.
Common Attributes of all Tree Items
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.
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 version-ID of the library-to-be-imported matches the ID of the already imported library, and if they match, then reimports all individual action blocks again by using the 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 you intent is to make this a new suite, which is not to be considered in future reimport operations.
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. E.g. elements tagged as "obsolete" will not be presented in dialogs to insert new steps.
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.
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, but may be needed when models are imported or exported from/to other modelling tools, such as Enterprise Architect, Rose etc., where tagged values are used 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.
A testplan contains a list if 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 blocks. They are nested in the "Imports" node. Libraries like the Standard Library or the Qt-Interface library are provided by eXept, either as part of the standard delivery or as additional extension, which must be purchased separately. However, you can also create your own project-specific libraries. Or provide them as a supplier to a third party, or acquire them from a third party.
Libraries can contain any type of element, including datatypes, attachments, elementary and compound blocks. Libraries can also use and import additional libraries.
Already included in all releases of expecco are the following libraries:
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.
- 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)
By default, imported libraries behave like "statically linked code". This means, that a copy of the required parts of the imported library is loaded into the test suite. After the import, the suite is independent of the original imported library: it can be changed, enhanced or even deleted (which you should not) without affecting the testsuite which imported it. As a consequence, this prevents the "DLL hell", commonly known in the MS windows world, where the installation of new libraries may affect functions which used to work before, without actually touching any of the affected functions. If a suite worked at some time on the past, it will continue to do so, even if other group members change or break the import library.
However, at some occasion, you may want to upgrade your test suite, in order to make use of additional functions in an import library or to get new advanced versions of the blocks contained therein. For this, an explicit "reimport" operation is needed, in order to upgrade a project's imported libraries to the new version.
Notice, that a reimport is a non-trivial operation: there might be new pins, changed datatype definitions, missing actions which were present before and many other possible problems. The reimport operation will detect these and provide an appropriate trouble-resolving dialog. Also, it is completely protected by the undo mechanism: if there is too much trouble with the new version, you can go back to the original and import individual blocks manually via drag & drop, replace blocks and rewire missing connections as required.
If a block was previously imported, but is no longer present in the new library version, a new folder named "Lost & Found" is created, and the previously imported block can be found there.
Virtual libraries allow for the behavior of a group of actions to be specified and changed at runtime. Similar to abstract functions in an OO-programming language, virtual blocks only define the interface (number and types of pins) of a block, but no concrete implementation. A virtual library is a collection of such virtual blocks. Its components can be used and placed like any other block with a test scenario. However, for execution, a concrete library needs to specified, which contains concrete implementations for every virtual block. The choice of a concrete library can be done statically or even dynamically at execution time (for example, to dynamically determine which communication protocol is required, and associate corresponding implementation blocks at the time the system under test is investigated).
Elementary blocks are usually provided by programmers or by eXept, as part of their standard or plugin libraries. They are typically used to implement low-level functionality, helper blocks or communication interfaces which are required by higher level test scenarios. Most of the elementary block's code consists of a few lines of code. The code of elementary blocks is stored within a suite and can be inspected (and even changed) at any time - even during a test suite's execution. There is no need to recompile, link or even shut down the expecco system, when an elementary block's code is changed.
Please navigate to "Elementary Block" for more detail on elementary blocks.
A compound block is a block which is defined by an internal activity diagram. This diagram contains blocks which themself are either elementary or compound. This makes every block highly reusable, as arbitrary complex hierarchies of actions are possible. Semantically, these diagrams are similar to petri nets or UML activity diagrams: the flow of information between blocks is via data flow: outgoing values are forwarded to other blocks via connections. Blocks are activated and executed, whenever its required inputs are arriving.
Please navigate to " Compound Block" for more detail.
Simple sequential actions can also be defined in a tabular keyword-action representation. This presents actions to be performed as a table with input/output values. Of course, sequential execution is a subset of the more general execution structure in a compound action, in that they define a strictly sequential list of actions to be executed. And can as such be represented in a compound network as well. Although they cannot represent parallel execution, branches and loops, many beginners prefer the simpler user interface provided by keyword actions.
If there is a need for more complex control structures, keyword actions can be later converted to full-featured compound blocks, if there is a need.
Please navigate to " Keyword Action Blocks" for more detail.
A virtual block is used to place a step whose execution is defined dynamically at runtime. Similar to a virtual function in programming languages, only the block's interface is defined in a network. At execution time, one of multiple concrete actions is chosen to be actually executed. Virtual blocks are very useful, if the same sequence is to be executed on multiple different technologies or devices. For example, if different measurement devices, different protocols or different mobile devices are to be used in a test, and the type is to be determined dynamically when the test is started or even during the test run. Using virtual block libraries, it is possible to replace a whole bunch of actions with alternative implementations, without a need to change anything in the diagrams.
The determination of which concrete block to use can be done via two mechanisms:
- by importing a concrete library for a virtual library
- by specifying explicitly which concrete action to use
With the first strategy, you have to import a concrete library, which contains concrete implementations for all virtual blocks in the virtual library.
With the second strategy, you add a "Performer-Pin" to the virtual step, and pass the concrete block as argument. This can be either a freeze value, or a performer-reference-value computed or passed in from another block. It may also be a performer-reference value from an environment variable.
Please navigate to "Virtual Block" for more detail.
A test data generator block is used to generate simple tabular data for a test. You specify rows for data tuples (similar to database rows of data columns), and time-deltas. When executed, the data generator will generate value tuples at its output pin(s) which should be fed as input to other blocks.
Please navigate to "Test Data Generator Block" for more detail.
A compound GUI block is used to model non-modal user interfaces. The action blocks contain a UI and a compound network, to implement more complex, stateful user interfaces. Their use is described in a separate document.
Please navigate to "GUIBlock Element" for more detail.
An elementary GUI block is used to model modal (blocking) user interfaces. This is an action block which - when executed - opens a GUI in a modal dialog. The GUI can be edited to contain arbitrary components (Check boxes, Input fields, Buttons etc.). When close, the entered values are send to the UI-block's output pins.
Such elementary GUI blocks are perfect to let the tester enter complex data during execution time. Notice, that for simple values (strings, numbers, filenames, yes-no questions, etc.), the standard library already contains a number of existing blocks.
A datatype element represents a user-defined data types. There are both builtin types (String, Integer, etc.) and user defined types, which can be constructed by various mechanisms (structures, unions, classes, enums, tuples, arrays, etc.)
Please navigate to "Datatype" for more detail.
A resource element represents a physical, logical or human resource. Examples for physical resources are measurement devices, equipment or human operators. Non-physical resources are database-locks or synchronization semaphores. Expecco includes a resource management, which can be used to synchronize concurrent access and use of such resources within a test suite. If running under the control of the expeccoNET QM system, resources are even managed and access is controlled among multiple testhosts, while executing multiple tests in parallel.
A skill is a part of the description of a resource or the requirement of a block. It describes a particular attribute of a resource.
An inventory is a collection of resources.
Folder elements are containers for grouping of other elements.
Please navigate to " Folder" for more detail.
An attachment is used to manage any file together with a test suite.
Please navigate to "Attachment" for more detail.
Documentation elements can be used to add additional documentation to the test suite. They are simple text-holding elements, and typically contain instructions from the test developer to the test operator.
Please navigate to "Documentation" for more detail.
A report template is used to customize a report. It is a kind of "attachment" describing the format, layout and detail of a report. Multiple report templates can be embedded inside a suite (or a template library) and used to manually or automatically generate multiple different reports from the same run. (manually via the menu; automatically via report-generator action blocks).
Please navigate to "Report Template" for more detail.
Diese Kategorie enthält zurzeit keine Seiten oder Medien.