https://doc.expecco.de/w2.x/api.php?action=feedcontributions&user=Mawalch&feedformat=atomexpecco Wiki (Version 2.x) - Benutzerbeiträge [de]2024-03-29T13:47:04ZBenutzerbeiträgeMediaWiki 1.33.0https://doc.expecco.de/w2.x/index.php?title=WindowsAutomation_Reference_1.0&diff=10590WindowsAutomation Reference 1.02018-02-28T22:57:48Z<p>Mawalch: </p>
<hr />
<div>This is the WindowsAutomation-Plugin documentation.<br />
<br />
This expecco plugin provides facilities to automate tests incorporating applications with a GUI based on Windows Presentation Foundation (WPF). It also lets you access GUI components, to use and validate them in a test.<br />
<br />
=Features=<br />
*Automated GUI testing of WPF applications<br />
*Parallel remote test-execution on multiple systems<br />
*Performs tests against completely built and executable WPF applications. No source code changes / recompilation of the application is required<br />
*Access GUI components, using XPath-like locators.<br />
*Access objects of the application live at execution time.<br />
*Consists of an expecco block library and tools which help to model tests and inspect the GUI of the application<br />
<br />
=Installation and Connection=<br />
The WindowsAutomation testing plugin uses a so called ".NET-Bridge" which consists of two parts: one side is a plugin for expecco, the other side is an .NET console application (the "WindowsAutomationApplication").<br />
<br />
==Requirements==<br />
On the test executing machine.<br />
*.NET Framework 3.5 [http://www.microsoft.com/en-us/download/details.aspx?id=21] or higher.<br />
* One of the following operation systems:<br />
::- Windows XP (with the Windows Automation API library [http://www.microsoft.com/en-us/download/details.aspx?id=13821])<br />
::- Windows Vista (with the Windows Automation API library [http://www.microsoft.com/en-us/download/details.aspx?id=23432])<br />
::- Windows 7<br />
::- Windows 8<br />
::- Windows 8.1<br />
::- Windows Server 2003 (with the Windows Automation API library [http://www.microsoft.com/en-us/download/details.aspx?id=7483])<br />
::- Windows Server 2008(with the Windows Automation API library [http://www.microsoft.com/en-us/download/details.aspx?id=11850])<br />
::- Windows Server 2008 R2<br />
::- Windows Server 2012<br />
::- Windows Server 2012 R2<br />
<br />
==Plugin Components==<br />
The plugin consists of the following parts:<br />
* The GUI Browser, used to explore your application.<br />
* The WindowsAutomation Library, provides blocks that you can use in your test-cases.<br />
* The WindowsAutomationApplication, provides the interface between the tested application and your tests (i.e. expecco).<br />
<br />
==Installing and Configuring the Plugin in Expecco==<br />
The plugin is usually installed automatically by the installer; either included in the main expecco installation or provided as a separate installable add-on package. Its files are stored in the "plugin" subfolder of the expecco installation folder. You can also copy those files manually to that folder, if required. Expecco detects the plugin automatically during startup. So it may be required to restart any expecco session.<br />
<br />
If you want expecco to automatically connect to the local computer by opening up a connection navigate to "Extras->Settings->Plugins->WindowsAutomation". Make sure the Path of the WindowsAutomationApplication is entered correctly and the checkbox is selected.<br><br />
To set up a manual connection unselect the checkbox, open up the connection in expecco and subsequently start the WindowsAutomationApplication.<br />
<br />
==Installing and Running the WindowsAutomationApplication==<br />
The ''WindowsAutomationApplication'' is a .NET console application. It uses the so called ".Net-Bridge" to connect to expecco. You just need to copy the folder containing the "WindowsAutomationApplication.exe" to the computer you want to run the tests on. The ''WindowsAutomationApplication'' does not need any further installation.<br />
<br />
To run the client manually and connect to expecco on the default port, port ''9988'', without any extensions just double click onto the "WindowsAutomationApplication.exe".<br />
<br />
===Arguments===<br />
[[Bild:WindowsAutomation&DevExpress.png|thumb|220px|The GuiBrowser with and without the DevExpress extension.]]<br />
{| class="wikitable"<br />
|-<br />
! Arguments !! Description<br />
|-<br />
| -port <int> || The TCP-Port to run the connection on.<br />
|-<br />
| -mode <server/client>|| To start the .Net-Bridge as TCP-Server or to run as TCP-Client.<br />
|-<br />
| -keepAlive <true/false>|| To keep the .Net-Bridge alive for reconnect. (If started as Server only!)<br />
|-<br />
| -log <path> || Path to write a logfile.<br />
|}<br />
<br />
===Additional Arguments for the WindowsAutomationApplication.DevExpress===<br />
The WindowsAutomationApplication.DevExpress is an enhanced client application for the PlugIn. It can be used to browse through applications build with DevExpress. To take benefit out of the extension you have to extend the applications you want to browse through.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Arguments !! Description<br />
|-<br />
| -extend <path> || Path of an application within the .Net-VM to be shown with the DevExpress extension.<br />
|-<br />
| -extendDynamically <true/false>|| To work with dynamic GUI applications or save some performance.<br />
|-<br />
| -recordMap <path> || Path to write an xMap for an extended application.<br />
|-<br />
| -map <path> || Path of an xMap to extend the Browser with.<br />
|}<br />
<br />
<br />
If you want to run the ''WindowsAutomationApplication'' on another TCP port you have to start the client using the command prompt, specifying the port number using the ''-port'' parameter.<br />
C:\Programme\exept\expecco\plugin\windowsAutomation\systemDLL\WindowsAutomationIDEClient>WindowsAutomationApplication.exe -port 9987<br />
<br />
=Settings=<br />
[[Bild:WinAuto_settings.png|thumb|220px|Windows Automation settings dialog.]]<br />
Open "Extras->Settings->Plugins->WindowsAutomation" to inspect or change the plugin settings. The settings are composed in four categories: connection settings, execution settings, recording settings and advanced settings.<br />
<br />
For further information on connection settings please refer to the chapter "Installation and Connection".<br />
<br />
<br />
The execution settings affect the way blocks are executed. You are able to decide how they respond to a failure while execution. Potentially an element they are trying to address is not properly constructed yet. If the check box "Retry Execution" is checked the delay time adjusted in the text box "Execution Timeout" will be applied and the execution will be repeated till an error appears.<br />
<br />
<br />
In the recording settings you can select which devices you want to record. You have the choice between mouse, keyboard or both of them.<br />
The recording mode can be switched. Recording input devices is default and recommended. However you can use recording keycodes to record key combinations and hotkeys. Due to performance and stability issues the use of recording keycodes is not recommended if another recording mode can be used.<br />
<br />
Another option is to record event based changes. Recording events is a higher level way of recording. Since handles have to been added to the windows only windows opened after recording was initialized are recorded properly. Events are a clean and simple way of recording if the application you want to record interaction with does support them.<br />
<br />
Recording all events is not recommended since one user interaction might trigger few events.<br />
<br />
<br />
The check box "Filter Windows GUI Elements" allows you to activate or deactivate a filter in the GUI Browser. If it is activated you just see windows belonging to applications. The menu bar, file system windows and temporarily shown windows for example tool tip windows are not displayed.<br />
If you activate "Show Warnings" unexpected events occurring during the connection will raise a warning message.<br />
<br />
The check box "Update Top Elements" allows you to decide if new applications appear in the tree of the GUI Browser by themselves. Please be aware that the plugin might run smoother if this check box is unselected.<br />
<br />
=GUI Browser=<br />
The GUI browser allows you to explore a running WPF application. You can browse the application, inspect element properties and execute actions. For a more detailed description on how to use and what to do with the GUI browser also see [[Expecco GUI Tests Extension Reference]].<br />
<br />
=WindowsAutomation Library=<br />
[[Bild:WinAuto_lib.png|thumb|220px|The Windows Automation library.]]<br />
For automation and testing of an application, a library of building blocks is provided, which contains functional blocks for all of those operations.<br />
<br />
The ''WindowsAutomation Library'' consists of a set of predefined function blocks which are used to model your tests. Import this library via expecco's "Import Library" menu-function.<br />
<br />
<br />
==Connections==<br />
:;Settings<br />
:: Settings valid for the current connection. You usually do not need to make a change on these.<br />
<br />
::;Set Execution Timeout<br />
::: Set the timeout for each execution.<br />
::: '''timeout''' <Integer> - Timeout in milliseconds.<br />
<br />
::;Set Execution Delay<br />
::: Set the delay between each try for each execution.<br />
::: '''delay''' <Integer> - Delay in milliseconds.<br />
<br><br />
<br />
:;Setup Connection<br />
:: Establish a connection to a target host by its network address.<br />
:: Optional: '''ip''' <String> - The IP-network address or host name of the host you want to connect to. Default is '''localhost'''.<br />
:: Optional: '''port''' <Integer> - The TCP port to use for the connection. The default port is '''9988'''.<br />
:: Optional: '''name''' <String> - A identifier for the connection. Default is '''local'''.<br />
<br />
:;Close Connection<br />
:: Close down all connections.<br />
<br />
==Elements==<br />
Element actions, sorted by the type of components and pattern.<br />
<br />
===By Components===<br />
[[Bild:WinAuto_byComponent.png|thumb|220px|By Components.]]<br />
Element actions sorted by the type of components.<br />
<br />
:;Click<br />
:: Click onto an element.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Double Click<br />
:: Double-Click onto an element.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Right Click<br />
:: Right-Click onto an element.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Set Focus<br />
:: Set the focus onto an element.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:; Get Property Value<br />
:: Get any property value.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
:: Return: '''value''' <String> - The current property value.<br />
<br />
:; Get Property Value As Boolean<br />
:: Get any property value as boolean.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
:: Return: '''isBoolean''' <Boolean> - Identifies whether the property has a boolean value or not.<br />
:: Return: '''value''' <Boolean> - The current property value.<br />
<br />
:; Is Boolean Property<br />
:: Check if a property value is boolean.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
:: Return: '''isBoolean''' <Boolean> - Identifies whether the property has a boolean value or not.<br />
<br />
:; Get Name<br />
:: Get the name.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''name''' <String> - The elements current name.<br />
<br />
:; Get Class Name<br />
:: Get the classname.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''className''' <String> - The elements current classname.<br />
<br />
:; Get Position<br />
:: Get the position.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''position''' <String> - The elements current position.<br />
<br />
:; Is Enabled<br />
:: Check if the element is enabled.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''isEnabled''' <Boolean> - Identifies if the element is enabled or not.<br />
<br />
:; Is Focusable<br />
:: Check if the element in focusable.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''isFocusable''' <Boolean> - Identifies if the element is focusable or not.<br />
<br><br />
<br />
:;Button<br />
<br />
::;Perform Click<br />
::: Simulate the click onto a button.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br><br />
<br />
:;RadioButton<br />
<br />
::;Select<br />
::: Select an Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Unselect<br />
::: Unselect an Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Toggle<br />
::: Toogle between states.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Is Selected<br />
::: Check if the RadioButton is selected.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isSelected''' <Boolean> - Identifies if the element is currently selected.<br />
<br><br />
<br />
:;CheckBox<br />
<br />
::;Check<br />
::: Check the CheckBox.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Uncheck<br />
::: Uncheck the CheckBox.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Toggle<br />
::: Toogle the state.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Is Checked<br />
::: Check if the CheckBox is checked.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isChecked''' <Boolean> - Identifies if the element is currently checked.<br />
<br />
<br><br />
<br />
:;List<br />
<br />
::;Has Enabled List Item<br />
::: Check if List has specified Child List Item and if Child List Item is enabled.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: Return: '''hasEnabledEntry''' <Boolean> - Identifies if the specified element is a child list item.<br />
::: Return: '''path''' <String> - Identifies for the element.<br />
<br />
::;Has List Item<br />
::: Check if List has specified Child List Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: Return: '''hasEntry''' <Boolean> - Identifies if the specified element is a child list item.<br />
::: Return: '''path''' <String> - Identifies for the element.<br />
<br><br />
<br />
:;Menu<br />
<br />
::;Get Menu Entry Property Value<br />
::: Get any property value for Child Menu Entry.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
::: Return: '''value''' <String> - The current property value.<br />
<br />
::;Has Enabled Menu Entry<br />
::: Check if Menu has specified Child Menu Item and if Child Menu Item is enabled.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: Return: '''hasEnabledEntry''' <Boolean> - Identifies if the specified element is a child menu item.<br />
::: Return: '''path''' <String> - Identifies for the element.<br />
<br />
::;Has Menu Entry<br />
::: Check if Menu has specified Child Menu Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: Return: '''hasEntry''' <Boolean> - Identifies if the specified element is a child menu item.<br />
::: Return: '''path''' <String> - Identifies for the element.<br />
<br />
::;Select Menu Entry<br />
::: Select an Child Menu Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entry name''' <String> - Identifier for the child element.<br />
::: Return: '''entryPath''' <String> - Identifier of selected Menu. Can be used to cascade menus.<br />
<br />
::;Open Menu<br />
::: Perform the Action of an Menu Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
<br><br />
<br />
:;ScrollBar<br />
<br />
::;Scroll<br />
::: Scroll for a large decrement.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Scroll Small Decrement<br />
::: Scroll for a small decrement.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Is Horizontal Oriented<br />
::: Check the scrollbars orientation.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isHorizontal''' <Boolean> - Identifies if the element is aligned in a horizontal direction.<br />
<br />
::; Is Vertical Oriented<br />
::: Check the scrollbars orientation.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isVertical''' <Boolean> - Identifies if the element is aligned in a vertical direction.<br />
<br><br />
<br />
:;Tab<br />
<br />
::;Has Enabled Tab Item<br />
::: Check if Tab has specified Child Tab Item and if Child Tab Item is enabled.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: Return: '''hasEnabledEntry''' <Boolean> - Identifies if the specified element is a child tab item.<br />
::: Return: '''path''' <String> - Identifies for the element.<br />
<br />
::;Has Tab Item<br />
::: Check if Tab has specified Child Tab Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: Return: '''hasEntry''' <Boolean> - Identifies if the specified element is a child tab item.<br />
::: Return: '''path''' <String> - Identifies for the element.<br />
<br><br />
<br />
:;Text<br />
<br />
::;Set Text<br />
::: Change the text.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''text''' <String> - Text to change to.<br />
<br />
::; Is Read Only<br />
::: Check if the field is read only.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isReadOnly''' <Boolean> - Identifies if the element is read only or not.<br />
<br />
::; Has Keyboard Focus<br />
::: Check if the element does have the focus.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''hasFocus''' <Boolean> - Identifies if the element is currently focused.<br />
<br><br />
<br />
:;Tree<br />
<br />
::;Has Enabled Tree Item<br />
::: Check if Treehas specified Child Tree Item and if Child Tree Item is enabled.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: Return: '''hasEnabledEntry''' <Boolean> - Identifies if the specified element is a child tree item.<br />
::: Return: '''path''' <String> - Identifies for the element.<br />
<br />
::;Has Tree Item<br />
::: Check if Tab has specified Child Tree Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''entryName''' <String> - Identifier for the child element.<br />
::: Return: '''hasEntry''' <Boolean> - Identifies if the specified element is a child tree item.<br />
::: Return: '''path''' <String> - Identifies for the element.<br />
<br><br />
<br />
:;Window<br />
<br />
::;Maximize<br />
::: Maximize a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Minimize<br />
::: Minimize a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Normalize<br />
::: Normalize a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Close<br />
::: Close a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Rotate<br />
::: Rotate a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''value''' <String> - The degree you want to rotate the window.<br />
<br />
::;Resize<br />
::: Resize a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''valueForX''' <String> - New size for dimension x.<br />
::: '''valueForY''' <String> - New size for dimension y.<br />
<br />
::;Move<br />
::: Move a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''valueForX''' <String> - X-coordinate you want to move the upper left corner of the window to.<br />
::: '''valueForY''' <String> - Y-coordinate you want to move the upper left corner of the window to.<br />
<br />
::; Get Interaction State<br />
::: Get the interaction state.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''state''' <String> - The window interaction state.<br />
<br />
::; Get Visual State<br />
::: Get the visual state.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''state''' <String> - The current visual state.<br />
<br />
::; Is Maximized<br />
::: Check if the window is maximized.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isMaximized''' <Boolean> - Identifies if the element is maximized.<br />
<br />
::; Is Minimized<br />
::: Check if the window is minimized.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isMinimized''' <Boolean> - Identifies if the element is minimized.<br />
<br />
::; Is Topmost<br />
::: Check if the window is topmost.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isTopmost''' <Boolean> - Identifies if the element is topmost.<br />
<br />
<br />
::; Is Offscreen<br />
::: Check if the window is offscreen.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''isOffscreen''' <Boolean> - Identifies if the element is aligned in offscreen.<br />
<br />
::; Can Maximize<br />
::: Check if the window can maximize.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''canMaximize''' <Boolean> - Identifies if the window can be maximized.<br />
<br />
::; Can Minimize<br />
::: Check if the window can minimize.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''canMinimize''' <Boolean> - Identifies if the window can be minimized.<br />
<br />
::; Can Move<br />
::: Check if the window can move.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''canMove''' <Boolean> - Identifies if the window can be moved.<br />
<br />
::; Can Rotate<br />
::: Check if the window can rotate.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''canRotate''' <Boolean> - Identifies if the window can be rotated.<br />
<br />
::; Can Resize<br />
::: Check if the window can resize.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: Return: '''canResize''' <Boolean> - Identifies if the window can be resized.<br />
<br><br />
<br />
===By Pattern===<br />
[[Bild:WinAuto_byPattern.png|thumb|220px|By Pattern.]]<br />
Element actions sorted by there pattern.<br />
If you want to learn more about UI Automation Control Pattern you can find the documentation at the MSDN [http://msdn.microsoft.com/library/ms752362].<br />
<br />
:;Invoke Pattern<br />
<br />
::;Invoke<br />
::: Invoke an Element, for Example a Button and perform its distinct Action.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br><br />
<br />
:;Menu Pattern<br />
<br />
::;Click Menu<br />
::: Perform the Action of an Menu Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br><br />
<br />
:;Scroll Item Pattern<br />
<br />
::;Scroll<br />
::: Scroll for a large decrement.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Scroll Small Decrement<br />
:::Scroll for a small decrement.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
<br><br />
<br />
:;Selection Item Pattern<br />
<br />
::;AddSelection<br />
::: Select an Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;RemoveSelection<br />
::: Unselect an Item.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br><br />
<br />
:;Toogle Pattern<br />
<br />
::;Toggle<br />
::: Toogle an Element, for Example a Button and Switch its Status.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br><br />
<br />
:;Transform Pattern<br />
<br />
::;Rotate<br />
::: Rotate a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''value''' <String> - The degree you want to rotate the window.<br />
<br />
::;Resize<br />
::: Resize a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''valueForX''' <String> - New size for dimension x.<br />
::: '''valueForY''' <String> - New size for dimension y.<br />
<br />
::;Move<br />
::: Move a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''valueForX''' <String> - X-coordinate you want to move the upper left corner of the window to.<br />
::: '''valueForY''' <String> - Y-coordinate you want to move the upper left corner of the window to.<br />
<br />
<br><br />
<br />
:;Window Pattern<br />
<br />
::;Maximize Window<br />
::: Maximize a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Minimize Window<br />
::: Minimize a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Normalize Window<br />
::: Normalize a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::;Close Window<br />
::: Close a window.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
<br><br />
<br />
:;Value Pattern<br />
<br />
::;Set Value<br />
::: Change the value, for example the text, of an element.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''value''' <String> - Value to change to.<br />
<br />
<br><br />
<br />
==Implementation==<br />
Blocks implementing core functionality are stored in here.<br />
They should not be needed for building up tests.<br />
<br />
==Input Devices==<br />
[[Bild:WinAuto_inputDevices.png|thumb|220px|Input Devices.]]<br />
Mouse and Keyboard operations are implemented in here.<br />
<br />
===Mouse===<br />
:;Click<br />
:: Click onto an element.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Double Click<br />
:: Double-Click onto an element.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Right Click<br />
:: Right-Click onto an element.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
===Keyboard===<br />
:;Backspace<br />
:: Simulating stroke onto backspace.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Caps Lock<br />
:: Simulating stroke onto caps lock.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Enter<br />
:: Simulating stroke onto enter.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Esc<br />
:: Simulating stroke onto escape.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Space Bar<br />
:: Simulating stroke onto the space bar.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
:;Tab<br />
:: Simulating stroke onto tab.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
<br><br />
<br />
:;Any Key<br />
<br />
::; Send Key<br />
::: Simulating stroke onto any key.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''key''' <String> - Key or text you want to simulate key strokes for.<br />
<br />
::; Send Key + CTRL<br />
::: Simulating stroke onto a function key while ctrl is pressed.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''key''' <String> - Key or text you want to simulate key strokes for.<br />
<br />
::; Send Key + ALT<br />
::: Simulating stroke onto a function key while alt is pressed.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''key''' <String> - Key or text you want to simulate key strokes for.<br />
<br />
::; Send Key + SHIFT<br />
::: Simulating stroke onto a function key while shift is pressed.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''key''' <String> - Key or text you want to simulate key strokes for.<br />
<br />
::; Send Key + CTRL + ALT<br />
::: Simulating stroke onto a function key while ctrl and alt are pressed.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''key''' <String> - Key or text you want to simulate key strokes for.<br />
<br />
::; Send Random Phrase<br />
::: Simulate the key stroes for the input of a random phrase.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
<br><br />
<br />
:;Arrow Key<br />
<br />
::; Up<br />
::: Simulating stroke onto up.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Down<br />
::: Simulating stroke onto down.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Right<br />
::: Simulating stroke onto right.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Left<br />
::: Simulating stroke onto left.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
<br><br />
<br />
:;Function Key<br />
<br />
::; F1 ... F12<br />
::: Simulating stroke onto a function key.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
<br><br />
<br />
:;Numpad<br />
<br />
::; Num Lock<br />
::: Simulating stroke onto numlock.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; +<br />
::: Simulating stroke onto plus.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; -<br />
::: Simulating stroke onto minus.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; *<br />
::: Simulating stroke onto times.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; /<br />
::: Simulating stroke onto divide.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; End<br />
::: Simulating stroke onto end.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Page Down<br />
::: Simulating stroke onto page down.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Page UP<br />
::: Simulating stroke onto page up.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Home<br />
::: Simulating stroke onto pos1.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Insert<br />
::: Simulating stroke onto insert.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
::; Delete<br />
::: Simulating stroke onto delete.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
<br />
==Properties==<br />
[[Bild:WinAuto_properties.png|thumb|220px|Properties.]]<br />
Blocks to access property values.<br />
<br />
:;Get Property Value<br />
:: Get any property value.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
:: Return: '''value''' <String> - The current property value.<br />
<br />
:;Get Name<br />
:: Get the name.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''name''' <String> - The elements current name.<br />
<br />
:;Get Class Name<br />
:: Get the classname.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''classname''' <String> - The elements current classname.<br />
<br />
:;Get Position<br />
:: Get the position.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''position''' <String> - The elements current position.<br />
<br />
:;Is Enabled<br />
:: Check if the element is enabled.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''isEnabled''' <Boolean> - Identifies if the element is enabled or not.<br />
<br />
:;Is Focusable<br />
:: Check if the element in focusable.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: Return: '''isFocusable''' <Boolean> - Identifies if the element is focusable or not.<br />
<br><br />
<br />
:;Boolean<br />
<br />
::; Get Property Value As Boolean<br />
::: Get any property value as boolean.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
::: Return: '''isBoolean''' <Boolean> - Identifies whether the property has a boolean value or not.<br />
::: Return: '''value''' <String> - The current property value.<br />
<br />
::; Is Boolean Property<br />
::: Check if a property value is boolean.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
::: Return: '''isBoolean''' <Boolean> - Identifies whether the property has a boolean value or not.<br />
<br />
::; Is True<br />
::: Check if a property value is true.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
::: Return: '''isTrue''' <Boolean> - Identifies whether the property equals true or not. If the value is not true it does not equal false in either case!<br />
<br />
::; Is False<br />
::: Check if a property value is false.<br />
::: '''path''' <String> - Identifier for the element a command should be executed for.<br />
::: '''property''' <String> - The identifier for a property, for example to get the property value.<br />
::: Return: '''isFalse''' <Boolean> - Identifies whether the property equals false or not. If the value is not false it does not equal true in either case!<br />
<br />
==Search Subtree==<br />
[[Bild:WinAuto_subtree.png|thumb|220px|Search Subtree.]]<br />
Blocks to search the subtree of an element for children.<br />
<br />
:;Search For Property<br />
:: Search for any property value.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: '''propertyName''' <String> - The identifier for a property.<br />
:: '''propertyValue''' <String> - The value to identify the child element.<br />
:: Return: '''elementFound''' <Boolean> - True if the specified element could be found, false if not.<br />
:: Return: '''foundElement''' <String> - The XPath to the found element.<br />
<br />
:;Search For Bounding Rectangle<br />
:: Search for a specific name property.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: '''boundingRectangle''' <String> - The boundingRectangle of the element.<br />
:: Return: '''elementFound''' <Boolean> - True if the specified element could be found, false if not.<br />
:: Return: '''foundElement''' <String> - The XPath to the found element.<br />
<br />
:;Search For Name<br />
:: Search for a specific name property.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: '''name''' <String> - The name of the element.<br />
:: Return: '''elementFound''' <Boolean> - True if the specified element could be found, false if not.<br />
:: Return: '''foundElement''' <String> - The XPath to the found element.<br />
<br />
:;Search For Value<br />
:: Search for a specific value property.<br />
:: '''path''' <String> - Identifier for the element a command should be executed for.<br />
:: '''value ''' <String> - The value of the element.<br />
:: Return: '''elementFound''' <Boolean> - True if the specified element could be found, false if not.<br />
:: Return: '''foundElement''' <String> - The XPath to the found element.<br />
<br />
=Example=<br />
A tutorial on how to use the Windows Automation Plugin can be found here: [[First Steps with Windows Automation]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:WinAuto_lib.png&diff=10589Datei:WinAuto lib.png2018-02-28T22:51:23Z<p>Mawalch: Mawalch lud eine neue Version von „Datei:WinAuto lib.png“ hoch</p>
<hr />
<div>Importing file</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:WinAuto_subtree.png&diff=10588Datei:WinAuto subtree.png2018-02-28T22:50:38Z<p>Mawalch: Mawalch lud eine neue Version von „Datei:WinAuto subtree.png“ hoch</p>
<hr />
<div>Importing file</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:WinAuto_properties.png&diff=10587Datei:WinAuto properties.png2018-02-28T22:50:12Z<p>Mawalch: Mawalch lud eine neue Version von „Datei:WinAuto properties.png“ hoch</p>
<hr />
<div>Importing file</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:WinAuto_inputDevices.png&diff=10586Datei:WinAuto inputDevices.png2018-02-28T22:49:26Z<p>Mawalch: Mawalch lud eine neue Version von „Datei:WinAuto inputDevices.png“ hoch</p>
<hr />
<div>Importing file</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:WinAuto_byComponent.png&diff=10585Datei:WinAuto byComponent.png2018-02-28T22:45:45Z<p>Mawalch: Mawalch lud eine neue Version von „Datei:WinAuto byComponent.png“ hoch</p>
<hr />
<div>Importing file</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:Tree_Elements.png&diff=10584Datei:Tree Elements.png2018-02-27T10:39:36Z<p>Mawalch: Mawalch lud eine neue Version von „Datei:Tree Elements.png“ hoch</p>
<hr />
<div>Importing file</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Mobile_Testing_Plugin&diff=10583Mobile Testing Plugin2018-02-26T13:03:18Z<p>Mawalch: </p>
<hr />
<div>= Einleitung =<br />
Mit dem Mobile Testing Plugin können Anwendungen auf Android- und iOS-Geräten getestet werden. Dabei ist es egal, ob reale mobile Endgeräte oder emulierte Geräte verwendet werden. Das Plugin kann (und wird üblicherweise) zusammen mit dem [[Expecco_GUI_Tests_Extension_Reference|GUI-Browser]] verwendet werden, der das Erstellen von Tests unterstützt. Zudem ist damit das Aufzeichnen von Testabläufen möglich.<br />
<br />
Zur Verbindung mit den Geräten wird [http://appium.io/ Appium] verwendet. Appium ist ein freies Open-Source-Framework zum Testen und Automatisieren von mobilen Anwendungen.<br />
<br />
Zur Einarbeitung in das Mobile Plugin empfehlen wir das [[#Tutorial|Tutorial]] zu bearbeiten. Dieses führt anhand eines Beispiels Schritt für Schritt durch die Erstellung eines Testfalls und erklärt die nötigen Grundlagen.<br />
<br />
= Installation und Aufbau =<br />
Zur Verwendung des Mobile Testing Plugins müssen Sie expecco inkl. Plugins installiert haben und Sie benötigen die entsprechenden Lizenzen. expecco kommuniziert mit den Mobilgeräten über einen Appium-Server, der entweder auf demselben Rechner wie expecco läuft, oder auf einem zweiten Rechner. Dieser muss für expecco erreichbar sein.<br />
<br />
'''Installationsübersicht mit expecco 2.11:'''<br />
* Appium-Server<sup>ab</sup> 1.6.4<br />
für Android-Geräte ab der Version 4.3:<br />
* Java JDK<sup>a</sup> Version 7 oder 8<br />
* Android SDK<sup>a</sup><br />
für iOS-Geräte ab Version 9.3:<br />
* Xcode 8.3.x<br />
* Apple-Entwickler-Zertifikat mit zugehörigem privaten Schlüssel<br />
* Provisioning Profile mit den verwendeten Mobilgeräten<br />
<sup>a</sup> enthalten in Mobile Testing Supplement<br><br />
<sup>b</sup> enthalten in Mobile Testing Supplement for Mac OS<br />
<br />
'''Installationsübersicht mit expecco 2.10:'''<br />
* Appium-Server<sup>ab</sup> 1.4.16<br />
für Android-Geräte ab der Version 2.3.3 bis Version 6.0:<br />
* Java JDK Version<sup>a</sup> 7 oder 8<br />
* Android SDK<sup>a</sup><br />
für iOS-Geräte bis Version 9.3:<br />
* Xcode 7.3.x<br />
* Apple-Entwickler-Zertifikat<sup>c</sup> mit zugehörigem privaten Schlüssel<br />
* Provisioning Profile<sup>c</sup> mit den verwendeten Mobilgeräten<br />
<sup>a</sup> enthalten in Mobile Testing Supplement<br><br />
<sup>b</sup> enthalten in Mobile Testing Supplement for Mac OS<br><br />
<sup>c</sup> zum Signieren der App<br />
<br />
Beachten Sie, dass aufgrund der Voraussetzungen iOS-Geräte nur von einem Mac aus angesteuert werden können. expecco kann dann über das Netzwerk mit dem Appium-Server auf dem Mac kommunizieren, um auf den dort angeschlossenen iOS-Geräten zu testen. Im Folgenden wird die Installation von Appium und anderer nötiger Programme für Windows und Mac OS erklärt.<br />
<br />
[[Datei:MobileTestingAufbau.png | 400px]]<br />
<br />
== Windows ==<br />
Am einfachsten installieren Sie alles mit unserem Mobile Testing Supplement:<br />
<br />
*'''expecco 2.11''': [http://download.exept.de/transfer/h-expecco-2.11.1/MobileTestingSupplement_1.6.0.2_Setup.exe Mobile Testing Supplement 1.6.0.2]<br />
:Dieses installiert ein Java JDK der Version 8, android-sdk und Appium in der Version 1.6.4. Außerdem bietet das Supplement auch einen universellen adb-Treiber ([http://download.clockworkmod.com/test/UniversalAdbDriverSetup.msi ClockworkMod]) an. Dieser vereint Treiber für ein breites Spektrum an Android-Geräten, sodass Sie nicht für jedes Gerät einen eigenen Treiber suchen und installieren müssen.<br />
*expecco 2.10: [http://download.exept.de/transfer/h-expecco-2.10.0/Mobile_Testing_Supplement_1.5.0.0_Setup.exe Mobile Testing Supplement 1.5.0.0]<br />
:Dieses installiert ein Java JDK der Version 8, android-sdk und Appium in der Version 1.4.16. Während der Installation wird die grafische Oberfläche von Appium gestartet, dieses Fenster können Sie sofort wieder schließen. Außerdem bietet das Supplement auch einen universellen adb-Treiber ([http://download.clockworkmod.com/test/UniversalAdbDriverSetup.msi ClockworkMod]) an. Dieser vereint Treiber für ein breites Spektrum an Android-Geräten, sodass Sie nicht für jedes Gerät einen eigenen Treiber suchen und installieren müssen.<br />
<br />
Beim Starten von Appium kann es vorkommen, dass die Windows-Firewall den Node-Server blockiert. In diesem Fall kann expecco keinen Appium-Server starten. Starten Sie daher nach der Installation am besten die Datei ''appium.cmd'' im Ordner ''appium'' des Mobile Testing Supplements. Wenn sich der Appium-Server starten lässt, sollte es auch von expecco aus funktionieren. Meldet sich hingegen die Windows-Firewall, lassen Sie den Zugriff zu.<br />
<br />
== Mac OS ==<br />
=== expecco 2.11 ===<br />
Auf dem verwendeten Mac sollte als Betriebssystemversion OS X 10.12 (Sierra) und Xcode 8.3 oder neuer laufen. Sie können eine aktuelle Version von Xcode über den App Store installieren. Außerdem benötigt Appium eine Java-Installation. Installieren Sie dazu ein JDK in Version 7 oder 8. Mithilfe unseres [http://download.exept.de/transfer/h-expecco-2.11.1/Mobile_Testing_Supplement_for_Mac_OS_1.0.94.tar.bz2 Mobile Testing Supplements für Mac OS (1.0.94)] können Sie nun noch Appium 1.6.4 installieren. Nachdem Sie es heruntergeladen haben, können Sie es in ein Verzeichnis Ihrer Wahl (z. B. Ihr Home-Verzeichnis) verschieben und dort entpacken. Ein geeigneter Befehl in einer Shell könnte so aussehen:<br />
<br />
tar -xvpf Mobile_Testing_Supplement_for_Mac_OS_1.0.94.tar.bz2<br />
<br />
''Hinweis: Zur Automatisierung von iOS-Geräten ab Version 10 ist grundsätzlich eine Installation von einem vergleichbar neuen Xcode 8 nötig (für iOS 10.'''2''' mind. Xcode 8.'''2''', für iOS 10.'''3''' mind. Xcode 8.'''3''', usw.), die auf älteren Betriebssystemen möglicherweise nicht läuft. Wenn Sie also auf eine neuere iOS-Version wechseln, benötigen Sie in der Regel auch eine neuere Xcode-Version, was wiederum eine Aktualisierung des Betriebssystems erforderlich machen kann (siehe auch [https://en.wikipedia.org/wiki/Xcode#Version_comparison_table Xcode-Versionen]).''<br />
<br />
Wenn Xcode 8.3 oder neuer Ihre Standard-Xcode-Installation ist, können Sie Appium direkt starten:<br />
Mobile_Testing_Supplement/bin/start-appium-1.6.4<br />
Falls kein ausreichend neues Xcode als Standard konfiguriert ist, müssen Sie Appium den entsprechenden Pfad über die Umgebungsvariable ''DEVELOPER_DIR'' angeben. Wenn Sie Xcode z. B. in ''/Applications/Xcode-8.3.app'' installiert haben, können Sie Appium so starten:<br />
DEVELOPER_DIR="/Applications/Xcode-8.3.app/Contents/Developer" Mobile_Testing_Supplement/bin/start-appium-1.6.4<br />
Was in Ihrem System als Standard-Xcode-Installation gesetzt ist, können Sie mit diesem Befehl herausfinden:<br />
xcode-select -p<br />
Wenn Appium Ihre Xcode-Installation nicht findet, erscheint beim Verbinden eine Fehlermeldung in der Art:<br />
''<blockquote>org.openqa.selenium.SessionNotCreatedException - A new session could not be created. (Original error: Could not find path to Xcode, environment variable DEVELOPER_DIR set to: /Applications/Xcode.app but no Xcode found)</blockquote>''<br />
Starten Sie in einem solchen Fall Appium erneut unter Angabe eines gültigen ''DEVELOPER_DIR''.<br />
<br />
Um eine Testverbindung mit einem Gerät aufbauen zu können, brauchen Sie einen Apple-Account. Zur Evaluierung können Sie einen kostenlosen Account verwenden. Dieser hat den Nachteil, dass erstellte Profile nur eine Woche gültig sind und danach neu erstellt werden müssen. Seien Sie auch vorsichtig, wenn Sie sich den Account teilen, da es vorkommen kann, dass Zertifikate widerrufen werden oder durch automatische Generierung ungültig werden. Als Folge können bereits signierte Apps nicht mehr verwendet werden.<br />
<br />
Schließen Sie zuerst das Gerät, das Sie verwenden möchten, über USB an den Mac an. Starten Sie Xcode und öffnen Sie ''Preferences''. Wechseln Sie zur Seite der Accounts und legen Sie einen Eintrag mit Ihrem Account an. Anschließend können Sie auf ''Manage Certificates...'' klicken, um die Zertifikate zu sehen, die zu diesem Account gehören. Zum Ausführen von Tests benötigen Sie ein iOS-Development-Zertifikat und den dazugehörigen privaten Schlüssel. Wenn Sie noch keines besitzen, erstellen Sie eines. Wenn Sie bereits eines haben, aber es nicht in Ihrem Schlüsselbund vorhanden ist (erkennbar an dem Hinweis "Not in Keychain"), können Sie es importieren. Öffnen Sie in jedem Fall die Schlüsselbundverwaltung auf dem Mac und wählen Sie den Schlüsselbund ''Anmeldung'' aus. Wenn Sie ein Zertifikat aus einer PKCS#12-Datei (Endung typischerweise .p12) importieren wollen, geht das über das Menü ''Ablage'' > ''Objekte importieren''. Falls Sie nicht wissen, wo das Zertifikat gespeichert ist, können Sie es in Xcode auch widerrufen und in Ihrem Schlüsselbund neu anlegen. Machen Sie das jedoch nur, wenn Sie wissen, dass das alte Zertifikat nicht mehr in Verwendung ist, da es danach nicht mehr benutzt werden kann. Nun sollte der Schlüsselbund ein iOS-Development-Zertifikat enthalten. Wählen Sie im Rechtsklick-Menü den Punkt ''Informationen'' aus. Unter den Details des Zertifikats finden Sie die Team-ID, die hier als Organisationseinheit bezeichnet wird. Tragen Sie diese in den Einstellungen des Plugins im Feld ''Team-ID'' ein, siehe [[#Konfiguration_des_Plugins|Konfiguration des Plugins]].<br />
<br />
Kehren Sie zu Xcode zurück und wählen Sie im Menü ''File'' den Eintrag ''Open...'', um das WebDriverAgent-Projekt zu öffnen. Dieses befindet sich im Verzeichnis des Mobile Testing Supplements unter<br />
''<nowiki>Mobile_Testing_Supplement/lib/node_modules/appium-1.6.4-beta/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj</nowiki>''<br />
<br />
[[Datei:MobileTestingWebDriverAgentXcode.png]]<br />
<br />
Wählen Sie ''WebDriverAgentLib'' und die Seite ''General'' aus. Setzen Sie dort im Abschnitt ''Signing'' die Option ''Automatically manage signing'' und wählen Sie dann ein Team aus. Wechseln Sie nun zu ''WebDriverAgentRunner'' und ebenfalls zur Seite ''General''. Setzen Sie auch hier das automatische Signieren und wählen Sie auch hier Ihr Team aus. Es sollten an dieser Stelle Fehler angezeigt werden, dass kein Provisioning Profile angelegt oder gefunden wurde. Wechseln Sie deshalb zur Seite ''Build Settings'' und suchen Sie hier im Abschnitt ''Packaging'' den Eintrag ''Product Bundle Identifier''. Ändern Sie diesen von com.facebook.WebDriverAgentRunner zu etwas, das von Xcode akzeptiert wird, indem Sie den Präfix ändern. Xcode kann nun ein passendes Provisioning Profile generieren und die Fehler auf der General-Seite sollten verschwinden. Danach können Sie Xcode beenden.<br />
<br />
Wenn Sie sich nun von expecco eine Verbindung zu Ihrem Gerät aufbauen, wird der WebDriverAgent darauf installiert und gestartet, um anschließend zur zu testenden App zu wechseln. Auf dem Gerät muss jedoch noch der Ausführung des WebDriverAgents vertraut werden. Öffnen Sie dazu während des Verbindungsaufbaus auf dem Gerät in die Einstellungen und dort unter ''Allgemein'' den Eintrag ''Geräteverwaltung''. Dieser Eintrag ist nur sichtbar, wenn eine Entwickler-App auf dem Gerät installiert ist. Sie müssen daher möglicherweise warten, bis der WebDriverAgent installiert ist, bevor der Eintrag erscheint. Wählen Sie dort den Eintrag Ihres Apple-Accounts und vertrauen Sie ihm. Da der WebDriverAgent wieder deinstalliert wird, wenn der Start nicht funktioniert hat, müssen Sie dies während des Verbindungsaufbaus tun. Falls Ihnen das zu hektisch ist, können Sie auch folgenden Code ausführen:<br />
<br />
''<nowiki>xcodebuild -project Mobile_Testing_Supplement/lib/node_modules/appium-1.6.4-beta/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination 'id=<udid>' test</nowiki>''<br />
<br />
Damit wird der WebDriverAgent auf dem Gerät installiert ohne dass er wieder gelöscht wird. In der [https://support.apple.com/en-us/HT204460 Dokumentation von Apple] finden Sie nähere Informationen zum Installieren und Vertrauen solcher Apps.<br />
<br />
=== expecco 2.10 ===<br />
Auf dem verwendeten Mac sollte als Betriebssystemversion OS X 10.11.5 (El Capitan) oder neuer laufen. Zur Automatisierung mit iOS-Geräten bis Version 9.3 ist eine Installation von Xcode 7.3 nötig, die auf älteren Betriebssystemen nicht läuft (siehe auch [https://en.wikipedia.org/wiki/Xcode#Version_comparison_table Xcode-Versionen]). Installieren Sie Xcode aus dem App Store. Außerdem benötigt Appium eine Java-Installation. Installieren Sie dazu ein JDK in Version 7 oder 8. Mithilfe unseres [http://download.exept.de/transfer/h-expecco-2.10.0/Mobile_Testing_Supplement_for_Mac_OS_1.0.tar.bz2 Mobile Testing Supplements für Mac OS] können Sie nun noch Appium 1.4.16 installieren. Nachdem Sie es heruntergeladen haben, können Sie es in ein Verzeichnis Ihrer Wahl (z. B. Ihr Home-Verzeichnis) verschieben und dort entpacken. Ein geeigneter Befehl in einer Shell könnte so aussehen:<br />
tar -xvpf Mobile_Testing_Supplement_for_Mac_OS_1.0.tar.bz2<br />
Wenn Xcode 7.3 Ihre Standard-Xcode-Installation ist, können Sie Appium direkt starten:<br />
Mobile_Testing_Supplement/bin/start-appium-1.4.16<br />
Falls Xcode 7.3 nicht als Standard-Xcode konfiguriert ist, müssen Sie Appium den entsprechenden Pfad über die Umgebungsvariable ''DEVELOPER_DIR'' angeben. Wenn Sie Xcode z. B. in ''/Applications/Xcode-7.3.app'' installiert haben, können Sie Appium so starten:<br />
DEVELOPER_DIR="/Applications/Xcode-7.3.app/Contents/Developer" Mobile_Testing_Supplement/bin/start-appium-1.4.16<br />
Was in Ihrem System als Standard-Xcode-Installation gesetzt ist, können Sie mit diesem Befehl herausfinden:<br />
xcode-select -p<br />
Wenn Appium Ihre Xcode-Installation nicht findet, erscheint beim Verbinden eine Fehlermeldung in der Art:<br />
''<blockquote>org.openqa.selenium.SessionNotCreatedException - A new session could not be created. (Original error: Could not find path to Xcode, environment variable DEVELOPER_DIR set to: /Applications/Xcode.app but no Xcode found)</blockquote>''<br />
Starten Sie in einem solchen Fall Appium erneut unter Angabe eines gültigen ''DEVELOPER_DIR''.<br />
<br />
== Konfiguration des Plugins ==<br />
Bevor Sie loslegen, sollten Sie die Einstellungen des Mobile Testing Plugins überprüfen und ggf. anpassen. Öffnen Sie im Menü den Punkt ''Extras'' > ''Einstellungen'' und dort unter ''Erweiterungen'' den Eintrag ''Mobile Testing'' (s. Abb.). Standardmäßig werden diese Pfade automatisch gefunden (1). Um einen Pfad manuell anzupassen, deaktivieren Sie den entsprechenden Haken rechts davon. Sie erhalten in einer Drop-down-Liste einige Pfade zur Auswahl. Ist ein eingetragener Pfad falsch oder kann er nicht gefunden werden, wird das Feld rot markiert und es erscheint ein diesbezüglicher Hinweis. Stellen Sie sicher, dass alle Pfade richtig angegeben sind.<br />
<br />
[[Datei:MobileTestingEinstellungen.png | thumb | 400px | Konfiguration des Plugins]]<br />
<br />
*'''appium''': Geben Sie hier den Pfad zur ausführbaren Datei an mit der Appium in der Kommandozeile gestartet werden kann. Unter Windows wird diese Datei in der Regel ''appium.cmd'' heißen. Dieser Pfad wird benutzt, wenn expecco einen Appium-Server startet.<br />
*'''node''': Geben Sie hier den Pfad zur ausführbaren Datei an, die Node startet. Dieser Pfad wird beim Starten eines Servers an Appium weitergegeben, damit Appium ihn unabhängig von der PATH-Variablen findet. Unter Windows heißt diese Datei in der Regel ''node.exe''.<br />
*'''JAVA_HOME''': Geben Sie hier den Pfad zu einem JDK an. Dieser Pfad wird an jeden Appium-Server weitergegeben. Lassen Sie das Feld frei, um den Wert aus der Umgebungsvariablen zu verwenden. Um einzustellen, welches Java von expecco verwendet werden soll, setzen Sie diesen Pfad in den Einstellungen für die Java Bridge.<br />
*'''ANDROID_HOME''': Geben Sie hier den Pfad zu einem SDK von Android an. Dieser Pfad wird an jeden Appium-Server weitergegeben. Lassen Sie das Feld frei, um den Wert aus der Umgebungsvariablen zu verwenden.<br />
*'''adb''': Hier steht der Pfad zum adb-Befehl. Unter Windows heißt die Datei adb.exe. Diese wird von expecco beispielsweise verwendet, um die Liste der angeschlossenen Geräte zu erhalten. Diesen Pfad sollten Sie automatisch wählen lassen, da dann der Befehl im ANDROID_HOME-Verzeichnis verwendet wird. Dieser wird auch von Appium verwendet. Falls expecco und Appium jedoch verschiedene Versionen von adb verwenden kann es zu Konflikten kommen.<br />
*'''android.bat''': Diese Datei wird nur benötigt, um damit den AVD und den SDK Manager zu starten. Automatisch wird hier die Datei im ANDROID_HOME-Verzeichnis gesucht.<br />
*'''aapt''': Geben Sie hier den Pfad zum aapt-Befehl an. Unter Windows heißt diese Datei ''aapt.exe''. expecco verwendet aapt nur im Verbindungseditor, um das Paket und die Activities einer apk-Datei zu lesen. Automatisch wird hier die Datei im ANDROID_HOME-Verzeichnis gesucht.<br />
<br />
[[Datei:MobileTestingJavaBridgeEinstellungen.png | thumb | 400px | Konfiguration des JDKs]]<br />
<br />
Ab expecco 2.11 gibt es das Feld ''Team-ID''. Wenn Sie iOS-Tests ausführen, tragen Sie hier die Team-ID Ihres Zertifikats ein. Diese wird für jede iOS-Verbindung verwendet, außer Sie setzen den Wert im Einzelfall in den Verbindungseinstellungen um. Wie Sie die Team-ID erhalten, lesen Sie im Abschnitt zur [[#expecco_2.11|Installation auf Mac OS mit expecco 2.11]]. Mit expecco 2.10 können Sie die Team-ID nur für jede Verbindungseinstellung extra als Capability eintragen. Dazu müssen Sie jedoch die [[#Erweiterte_Ansicht|erweiterte Ansicht]] verwenden. Geben Sie hier die Capability ''xcodeOrgId'' an und setzen Sie als Wert die Team-ID des Zertifikats.<br />
<br />
Die Einstellung zur Serveradresse unten auf der Seite bezieht sich auf das Verhalten des Verbindungseditors. Dieser prüft am Ende, ob die Serveradresse auf ''/wd/hub'' endet, da dies die übliche Form ist. Falls nicht, wird in einem Dialog gefragt, wie darauf reagiert werden soll. Das festgelegte Verhalten kann hier eingesehen und verändert werden.<br />
<br />
Wechseln Sie ebenfalls zum Eintrag ''Java Bridge'' (s. Abb.). Hier muss der Pfad zu Ihrer Java-Installation angegeben werden, die von expecco benutzt wird. Tragen Sie hier ein JDK ein. Falls Sie unter Windows das aus dem Mobile Testing Supplement verwenden möchten, lautet der Pfad<br />
<nowiki>C:\Program Files (x86)\exept\Mobile Testing Supplement\jdk</nowiki><br />
Sie können auch die Systemeinstellungen verwenden.<br />
<br />
== Android-Gerät vorbereiten ==<br />
Wenn Sie ein Android-Gerät unter Windows anschließen benötigen Sie möglicherweise noch einen adb-Treiber für das Gerät. Einen passenden Treiber finden Sie üblicherweise auf der jeweiligen Webseite des Herstellers. Haben Sie den Universal-Treiber aus dem Mobile Testing Supplement installiert, sollte für die meisten Geräte bereits alles funktionieren. In einigen Fällen versucht auch Windows automatisch einen Treiber zu installieren, wenn Sie das Gerät zum ersten mal anschließen.<br />
<br />
Bevor Sie ein Mobilgerät mit dem Appium-Plugin ansteuern können, müssen Sie für dieses Debugging erlauben. Für Android-Geräte finden Sie diese Option in den Einstellungen unter ''[https://www.droidwiki.org/wiki/Entwickleroptionen Entwickleroptionen]'' mit dem Namen ''[https://www.droidwiki.org/USB-Debugging USB-Debugging]''. Falls die Entwickleroptionen nicht angezeigt werden, können Sie diese freischalten, indem Sie unter ''Über das Telefon'' siebenmal auf ''Build-Nummer'' tippen. Aktivieren Sie auch die Funktion ''Wach bleiben'', damit das Gerät nicht während der Testerstellung oder -ausführung den Bildschirm abschaltet. Aus Sicherheitsgründen muss USB-Debugging für jeden Computer einzeln zugelassen werden. Beim Verbinden des Geräts mit dem PC über USB müssen Sie dabei am Gerät der Verbindung zustimmen. Falls Sie dies für Ihren Computer noch nicht getan haben, aber auf dem Gerät kein entsprechender Dialog erscheint, kann es helfen, das Gerät aus- und wieder einzustecken. Das kann insbesondere dann passieren, wenn Sie den ADB-Treiber installiert haben während das Gerät bereits über USB angeschlossen war. Falls auch das nicht hilft, öffnen Sie die Benachrichtigungen, indem Sie sie vom oberen Bildschirmrand herunter ziehen. Dort finden Sie die USB-Verbindung und Sie können die Optionen dazu öffnen. Wählen Sie einen anderen Verbindungstypen aus; in der Regel sollten MTP oder PTP funktionieren.<br />
<br />
Sie können auch auf einem Emulator testen. Dieser muss nicht mehr gesondert vorbereitet werden, da er bereits für USB-Debugging ausgelegt ist. Es ist sogar möglich, einen Emulator bei Testbeginn zu starten.<br />
<br />
Um zu überprüfen, ob ein Gerät, das Sie an Ihren Rechner angeschlossen haben, verwendet werden kann, öffnen Sie den [[#Verbindungseditor|Verbindungseditor]]. Das Gerät sollte dort angezeigt werden.<br />
<br />
=== Verbindung über WLAN ===<br />
Es ist auch möglich, Android-Geräte über WLAN zu verbinden. Dazu müssen Sie zunächst das Gerät über USB mit dem Rechner verbinden. Öffnen Sie dann die Eingabeaufforderung und geben Sie dort<br />
<nowiki>adb tcpip 5555</nowiki><br />
ein. Damit lauscht das Gerät auf eine TCP/IP-Verbindung an Port 5555. Sollten Sie mehrere Geräte angeschlossen oder Emulatoren laufen haben, müssen Sie genauer angeben, welches Gerät Sie meinen. Geben Sie in diesem Fall<br />
<nowiki>adb devices -l</nowiki><br />
ein. Sie erhalten eine Liste aller Geräte, wobei die erste Spalte deren Kennung ist. Schreiben Sie dann stattdessen<br />
<nowiki>adb -s <Gerätekennung> tcpip 5555</nowiki><br />
mit der Gerätekennung des gewünschten Geräts. Sie können die USB-Verbindung nun trennen. Jetzt müssen Sie die IP-Adresse Ihres Gerätes in Erfahrung bringen. Sie finden diese üblicherweise irgendwo in den Einstellungen des Geräts, beispielsweise beim Status oder in den WLAN-Einstellungen. Geben Sie dann<br />
<nowiki>adb connect <IP-Adresse des Geräts></nowiki><br />
ein. Damit sollte das Gerät nun über WLAN verbunden sein und kann genauso verwendet werden, wie mit USB-Verbindung. Sie können dies überprüfen, indem Sie wieder <tt>adb devices -l</tt> eingeben oder in expecco den Verbindungsdialog öffnen. In der Liste taucht das Gerät mit seiner IP-Adresse und dem Port auf. Bedenken Sie, dass die WLAN-Verbindung nicht mehr besteht, wenn der ADB-Server oder das Gerät neu gestartet werden.<br />
<br />
== iOS-Gerät und App vorbereiten ==<br />
Das Ansteuern von iOS-Geräten ist nur über einen Mac möglich. Lesen Sie daher auch den Abschnitt zur [[#Mac_OS|Installation unter Mac OS]].<br />
<br />
Bevor Sie ein Mobilgerät mit dem Mobile Testing Plugin ansteuern können, müssen Sie für iOS-Geräte ab iOS 8 Debugging erlauben. Aktivieren Sie dazu die Option ''Enable UI Automation'' unter dem Menüpunkt ''Entwickler'' in den Einstellungen des Geräts. Falls Sie den Eintrag ''Entwickler'' in den Einstellungen nicht finden, gehen Sie wie folgt vor: Schließen Sie das Gerät über USB an den Mac an. Dabei müssen Sie ggf. am Gerät noch der Verbindung zustimmen. Starten Sie Xcode und wählen Sie dann in der Menüleiste am oberen Bildschirmrand im Menü ''Window'' den Eintrag ''Devices''. Es öffnet sich ein Fenster, in dem eine Liste der angeschlossenen Geräte angezeigt wird. Wählen Sie dort Ihr Gerät aus. Danach sollte der Eintrag ''Entwickler'' in den Einstellungen auf dem Gerät auftauchen. Dazu müssen Sie möglicherweise die Einstellungen beenden und neu starten.<br />
<br />
[[Datei:Alert.png | thumb | 270px | Alert unter iOS]]<br />
Ein Verbindungsaufbau zu dem Gerät ist nicht möglich solange es bestimmte Alerts zeigt. Ein solcher Alert kann z.&#x202f;B. erscheinen wenn FaceTime aktiviert ist, indem ein Hinweis auf anfallende SMS-Gebühren angezeigt wird (siehe Screenshot). Achten Sie darauf, das Gerät so zu konfigurieren, dass es im Leerlauf keine solchen Alerts zeigt.<br />
<br />
=== expecco 2.11 ===<br />
Sie können beliebige Apps testen, die auf dem verwendeten Gerät lauffähig oder bereits installiert sind. Wenn die App als Development-Build vorliegt, muss die UDID des Geräts in der App hinterlegt sein. In jedem Fall muss der WebDriverAgent für das Gerät signiert werden. Lesen Sie dazu den Abschnitt zur [[#expecco_2.11|Vorbereitung unter Mac OS]].<br />
<br />
Falls Sie in einem Test den Home-Button verwenden wollen, müssen Sie auf dem Gerät AssistiveTouch aktivieren. Sie finden diese Option in den Einstellungen unter ''Allgemein'' > ''Bedienungshilfen'' > ''AssistiveTouch''. Platzieren Sie dann das Menü in der Mitte des oberen Bildschirmrands. Sie können das Drücken des Home-Buttons dann mit dem entsprechenden Menüeintrag im Recorder aufzeichnen oder direkt den Baustein ''Press Home Button'' benutzen.<br />
<br />
=== expecco 2.10 ===<br />
Die App, die Sie verwenden wollen, muss als Development-Build vorliegen. Außerdem muss die UDID des Geräts in der App hinterlegt sein.<br />
<br />
=== Development-Build signieren ===<br />
Ein Development-Build einer App ist nur für eine begrenzte Zahl von Geräten zugelassen und kann auf anderen Geräten nicht gestartet werden. Es ist aber möglich, das Zertifikat und die verwendbaren Geräte in einem Development-Build auszutauschen.<br />
<br />
* Evaluierung mit Demo-App von eXept:<br />
:Gerne stellen wir Ihnen eine Demo-App zur Verfügung, die als Development-Build vorliegt und die wir für Ihr Gerät signieren können. Senden Sie dazu bitte Ihrem eXept-Ansprechpartner die UDID Ihres Gerätes zu. Wie Sie die UDID Ihres Gerätes ermitteln können, ist im folgenden Abschnitt beschrieben.<br />
<br />
* Eigene App für Ihr Testgerät verwenden:<br />
:Wenn Sie von den App-Entwicklern einen Development-Build (IPA-Datei) erhalten, der für Ihr Testgerät zugelassen ist, können Sie diesen direkt verwenden. Dazu müssen Sie den Entwicklern die UDID Ihres Geräts mitteilen, damit sie diese eintragen können. '''Sie können die UDID eines Gerätes mithilfe von Xcode auslesen'''. Starten Sie dazu Xcode und wählen Sie in der Menüleiste am oberen Bildschirmrand im Menü ''Window'' den Eintrag ''Devices''. Es öffnet sich ein Fenster, in dem eine Liste der angeschlossenen Geräte angezeigt wird. Wählen Sie Ihr Gerät aus und suchen Sie in Eigenschaften den Eintrag ''Identifier''. Die UDID ist eine 40-stellige Hexadezimalzahl.<br />
<br />
* Extern entwickelte App für Ihr Testgerät umsignieren:<br />
:Es können auch Apps umsigniert werden, damit Sie auf anderen Geräten lauffähig sind. Dieser Vorgang ist jedoch kompliziert und setzt insbesondere einen Zugang zu einem Apple-Developer-Account voraus. Eine Dokumentation zur Vorgehensweise ist derzeit in Vorbereitung.<br />
<br />
:Für die Evaluierung unterstützen wir Sie gerne beim Umsignieren Ihrer App.<br />
<!--<br />
Melden Sie sich beim [https://developer.apple.com/ Apple-Webinterface] an. Navigieren Sie zu ''Certificates, IDs & Profiles''. Erzeugen Sie hier ggf. ein Developer-Zertifikat und ein Provisioning Profile für Ihr Gerät und laden Sie beide herunter. Sollten Sie noch keinen Developer Account haben, erstellen Sie hier einen: https://developer.apple.com/enroll/. Hierzu müssen Sie sich mit einer Apple-ID anmelden.<br />
<br />
# Team-ID herausfinden (''Membership'' -> ''Team ID'')<br />
# Unter ''Certificates, IDs & Profiles'' Development-Zertifikat auswählen (unter ''+'' anlegen, falls nicht vorhanden) und herunterladen.<br />
# Unter ''App ID'' Wildcard-App-ID erzeugen, falls nicht vorhanden. App-ID notieren (AppID = Prefix.ID)<br />
# Gerät hinzufügen, dazu UDID (bzw. ''Identifier'') des Geräts herausfinden (''Xcode'' -> ''Window'' (oben in Menüleiste) -> ''Devices'')<br />
# Provisionen Profile erstellen: ''iOS App Development'' -> ''AppID'' auswählen -> Zertifikat wählen -> Gerät auswählen -> Profilname anlegen -> Provisioning Profile herunterladen.<br />
# Das heruntergeladene Zertifikat importieren (''Downloads'' -> Zertifikat (.cer)<br />
# SHA1-Fingerabdruck kopieren. Dazu Rechtsklick auf Zertifikat -> ''Information'', anschließend bis zum Ende der Seite scrollen).<br />
# Entitlements.plist erstellen (''Terminal' öffnen -> Downloads/Mobile_Testing_Supplement/bin/gen-entitlements_plist 'Team-ID' 'App ID' Downloads/Mobile_Testing_Supplement/bin/re-sign-ipa <Pfad zum ipa (z.B. Downloads/expeccoMobileDemo.ipa)> \<br />
"<Zertifikat (SHA1-Fingerabdruck, z.B. 76 E8 4B E8 78 D5 D7 F9 2E 09 8B D7 E8 FB CE 30 0C F5 D0 EF)>" \<br />
<Pfad zum Provisionen Profile (z.B. /Users/exept_test/Downloads/dut.mobileprovision)> \<br />
<Pfad für das Ergebnis-ipa (z.B. Downloads/expeccoMobileDemo_re-signed.ipa)> \<br />
[Pfad zur entitlements.plist] (z.B. /Users/exept_test/entitlements.plist)<br />
<br />
Zum Umsignieren können Sie das entsprechende Skript aus dem Mobile Testing Supplement für Mac OS oder jedes beliebige andere Tool (z.B. isign) verwenden.<br />
--><br />
<br />
Weitere Informationen zur Verwendung von iOS-Geräten finden Sie auch in der [http://appium.io/slate/en/master/?java#appium-on-real-ios-devices Dokumentation von Appium].<br />
<br />
=== Native iOS-Apps ===<br />
Sie können auch Apps verwenden, die bereits nativ auf dem Gerät vorhanden sind. Dazu müssen Sie deren Bundle-ID kennen und diese dann in die Verbindungseinstellungen eintragen. Hier eine kleine Auswahl gängiger Apps:<br />
{| style="text-align:left"<br />
! App<br />
!<br />
! Bundle-ID<br />
|-<br />
| App Store<br />
| <br />
| com.apple.AppStore<br />
|-<br />
| Calculator<br />
| <br />
| com.apple.calculator<br />
|-<br />
| Calendar<br />
| <br />
| com.apple.mobilecal<br />
|-<br />
| Camera<br />
| <br />
| com.apple.camera<br />
|-<br />
| Contacts<br />
| <br />
| com.apple.MobileAddressBook<br />
|-<br />
| iTunes Store<br />
| <br />
| com.apple.MobileStore<br />
|-<br />
| Mail<br />
| <br />
| com.apple.mobilemail<br />
|-<br />
| Maps<br />
| <br />
| com.apple.Maps<br />
|-<br />
| Messages<br />
| <br />
| com.apple.MobileSMS<br />
|-<br />
| Phone<br />
| <br />
| com.apple.mobilephone<br />
|-<br />
| Photos<br />
| <br />
| com.apple.mobileslideshow<br />
|-<br />
| Settings<br />
| <br />
| com.apple.Preferences<br />
|}<br />
<br />
Weitere Bundle-IDs finden Sie [https://github.com/joeblau/apple-bundle-identifiers hier].<br />
<br />
= Beispiele =<br />
Bei den Demo-Testsuiten für expecco finden Sie auch Beispiele für Tests mit dem Mobile Testing Plugin. Wählen Sie dazu auf dem Startbildschirm die Option ''Beispiel aus Datei'' und öffnen Sie den Ordner ''mobile''.<br />
<br />
==<span id="TestsuiteMobileTestingDemo"><!-- Referenced by m01_MobileTestingDemo.ets --></span> ''m01_MobileTestingDemo.ets'' ==<br />
Die Testsuite enthält zwei einfache Testpläne: ''Simple CalculatorTest'' und ''Complex Calculator and Messaging Test''. Beide Tests verwenden einen Android-Emulator, den Sie vor Beginn starten müssen. Die Apps, die im Test verwendet werden, gehören zur Grundausstattung des Emulators und müssen daher nicht mehr installiert werden. Da sich die Apps unter jeder Android-Version unterscheiden können, ist es wichtig, dass Ihr Emulator unter Android 6.0 läuft. Außerdem muss die Sprache auf Englisch gestellt sein.<br />
<br />
; Simple CalculatorTest<br />
: Dieser Test verbindet sich mit dem Taschenrechner und gibt die Formel ''2+3'' ein. Das Ergebnis des Rechners wird mit dem erwarteten Wert ''5'' verglichen.<br />
<br />
; Complex Calculator and Messaging Test<br />
: Dieser Test verbindet sich mit dem Taschenrechner und öffnet anschließend den Nachrichtendienst. Dort wartet er auf eine einkommende Nachricht von der Nummer ''15555215556'', in der eine zu berechnende Formel gesendet wird. Die Nachricht wird zuvor über einen Socket beim Emulator erzeugt. Nach dem Eintreffen der Nachricht wird diese vom Test geöffnet und deren Inhalt gelesen. Danach wird wieder der Taschenrechner geöffnet, die erhaltene Formel eingegeben und das Ergebnis gelesen. Anschließend wechselt der Test wieder zum Nachrichtendienst und sendet das Ergebnis als Antwort.<br />
<br />
== ''m02_expeccoMobileDemo.ets'' und ''m03_expeccoMobileDemoIOS.ets'' ==<br />
Diese sind Bestandteil des Tutorials zum Mobile Testing Plugin. Der jeweils enthaltene Testfall ist unvollständig und wird im Zuge des Tutorials ergänzt. Lesen Sie dazu den Abschnitt [[#Tutorial|Tutorial]].<br />
<br />
= Tutorial =<br />
Dieses Tutorial beschreibt das grundsätzliche Vorgehen zur Erstellung von Tests mit dem Mobile Testing Plugin. Grundlage dafür ist ein mitgeliefertes Beispiel, bestehend aus einer einfachen App und einer expecco-Testsuite.<br />
<br />
Die App ''expecco Mobile Demo'' berechnet und überprüft verschiedene alltägliche Codes: die IBAN aus dem europäischen Zahlungsverkehr, die internationalen GTIN-13-Produktcodes, wie man sie bei Strichcodes im Einzelhandel findet, und die Seriennummern auf Euro-Banknoten.<br />
<br />
Die Testsuite enthält Testfälle für einzelne Funktionen der App. Dabei sind noch nicht alle Funktionen abgedeckt, sondern werden im Laufe des Tutorials ergänzt.<br />
<br />
Es gibt zwei Versionen dieses Tutorials:<br />
*'''[[#Erste_Schritte_mit_Android|Erste Schritte mit Android]]'''<br />
*'''[[#Erste_Schritte_mit_iOS|Erste Schritte mit iOS]]'''<br />
<br />
Das Vorgehen ist in beiden Versionen nahezu identisch, lediglich die Verbindungskonfigurationen werden unterschiedlich erzeugt. Die fertigen Tests unterscheiden sich dann im Wesentlichen in den Pfaden zur Adressierung der benutzten Elemente, da diese technologieabhängig sind.<br />
<br />
==<span id="FirstStepsAndroid"><!-- Referenced by m02_expeccoMobileDemo.ets --></span> Erste Schritte mit Android ==<br />
Es wird vorausgesetzt, dass Sie das Kapitel [[#Installation_und_Aufbau|Installation und Aufbau]] bereits gelesen und die nötigen Vorbereitungen für die Verwendung von Android-Geräten unter Windows abgeschlossen haben.<br />
<br />
=== Schritt 1: Demo ausführen ===<br />
Starten Sie expecco und öffnen Sie die Testsuite ''m02_expeccoMobileDemo.ets'' über die Schaltfläche ''Beispiel aus Datei'' (Abb. 1). Ab expecco 2.11 befindet sich diese im Unterordner ''mobile''. In dieser Testsuite befindet sich bereits ein vorgefertigter Testplan mit einigen Testfällen für diese App.<br />
<br />
[[Datei:MobileTestingBeispielÖffnen.png | frame | left | Abb. 1: Beispiel-Testsuite öffnen]]<br />
<br clear="all"><br />
In der Testsuite ist das Paket der Demo-App als Anhang enthalten (''expeccoMobileDemo-debug.apk''). Mithilfe des bereitgestellten Bausteins ''Export Demo App'' können Sie die Datei an einen beliebigen Ort auf Ihrem Rechner exportieren. Wählen Sie dazu den Baustein aus (1) und klicken Sie auf den grünen Play-Knopf (2) um den Baustein auszuführen (Abb. 2). Der Baustein öffnet einen Dateidialog, in dem Sie angeben, wo das Paket gespeichert werden soll.<br />
<br />
[[Datei:MobileTestingExportApp.png | frame | left | Abb. 2: App exportieren]]<br />
<br clear="all"><br />
Bevor wir uns mit dem weiteren Inhalt der Testsuite beschäftigen, konfigurieren Sie zuerst die Verbindung und welches Gerät Sie benutzen wollen. Schließen Sie dazu ein Gerät über USB an Ihren Rechner an oder starten Sie einen Emulator.<br />
<br />
[[Datei:MobileTestingVerbinden.png | frame | left | Abb. 3: Verbindungseditor öffnen]]<br />
<br clear="all"><br />
Öffnen Sie nun den GUI-Browser (1) und wählen Sie unter ''Verbinden'' (2) den Eintrag ''Mobile Testing'' (3) (Abb. 3), um den Verbindungsdialog zu öffnen.<br />
<br />
Sie sehen eine Liste aller angeschlossenen Android-Geräte (1) (Abb. 3). Sollte Ihr Gerät nicht in der Liste auftauchen, stellen Sie sicher, dass es eingeschaltet und über USB verbunden ist. Lesen Sie ansonsten den Abschnitt [[#Android-Ger.C3.A4t_vorbereiten|Android-Gerät vorbereiten]]<br />
<br />
[[Datei:MobileTestingGerätAuswählen.png | frame | left | Abb. 4: Gerät im Verbindungsdialog auswählen]]<br />
<br clear="all"><br />
Haben Sie Ihr Gerät in der Liste gefunden, wählen Sie es aus und klicken Sie auf ''Weiter'' (2).<br />
<br />
Als nächstes geben Sie an, welche App Sie verwenden wollen (Abb. 5). Dabei können Sie wählen, ob Sie eine App starten möchten, die bereits auf dem Gerät installiert ist (''App auf dem Gerät'') oder ob eine App installiert und gestartet werden soll (''App installieren''). Für den Fall, dass Sie eine bereits installierte App benutzen wollen, erhalten Sie eine Liste aller auf dem Gerät installierten Pakete (1), die in Systempakete und Fremdpakete (2) unterteilt sind, sowie deren Activities (3). Diese können Sie dann einfach in den jeweiligen Feldern auswählen.<br />
<br />
[[Datei:MobileTestingAppAuswählen.png | frame | left | Abb. 5: Auf dem Gerät installierte App angeben]]<br />
<br clear="all"><br />
Für dieses Tutorial soll die App installiert werden, die Sie eben aus der Testsuite exportiert haben. Wählen Sie also ''App installieren'' aus und tragen Sie bei App (1) den entsprechenden Pfad ein (Abb. 6). Sie können den Knopf links benutzen (2), um einen Dateidialog zu öffnen, mit dem Sie zu der Datei navigieren können, um sie einzugeben. Das Paket (3) und die Activity (4) der App werden automatisch eingetragen. Sollte die App mehrere Activities besitzen, können Sie die gewünschte auswählen. Klicken Sie nun auf ''Weiter'' (5).<br />
<br />
[[Datei:MobileTestingAppInstallieren.png | frame | left | Abb. 6: App angeben, die auf dem Gerät installiert werden soll]]<br />
<br clear="all"><br />
Auf der letzten Seite sehen Sie eine Übersicht aller bisherigen Angaben (1) (Abb. 7). Darunter können Sie einen Namen für die Verbindung angeben, unter dem sie im GUI-Browser angezeigt wird (2). Außerdem lässt sich eine Verbindung über diesen Namen identifizieren und in Bausteinen verwenden; der Name muss daher eindeutig sein. Falls Sie keinen Namen angeben, wird generisch einer erzeugt. Geben Sie als Namen ''expeccoMobileDemo'' ein. Im Feld darunter ist die Adresse zum Appium-Server einzutragen (3). Appium ist die Schnittstelle, über die die angeschlossenen Geräte gesteuert werden. Für dieses Tutorial wird die Verwaltung der Instanzen des Appium-Servers von expecco übernommen. Tragen Sie dafür ist die lokale Standard-Adresse ''<nowiki>http://localhost:4723/wd/hub</nowiki>'' ein. Diese ist immer der unterste Eintrag der Vorschlagsliste. Außerdem ist die Option ''Bei Bedarf starten'' aktiviert (4). expecco überprüft dann, ob an der Adresse bereits ein Appium-Server läuft und startet und beendet ihn bei Bedarf automatisch. Wenn der Port ''4723'' bereits belegt ist oder wenn Sie einmal mehrere Verbindungen parallel betreiben wollen, verwenden Sie an dieser Stelle entsprechend einen anderen Port. Es ist dabei üblich die ungeraden Portnummern oberhalb von ''4723'' zu verwenden, also ''4725'', ''4727'' usw. Natürlich können Sie auch entfernte Server verwenden, das automatische Starten und Beenden eines Servers kann expecco aber nur lokal für Sie übernehmen.<br />
<br />
[[Datei:MobileTestingServerkonfiguration.png | frame | left | Abb. 7: Verbindungsnamen und Appium-Server konfigurieren]]<br />
<br clear="all"><br />
Klicken Sie nun auf ''Speichern'' (5) um die Einstellungen für die Testausführung zu speichern. Einstellungen können als Anhang einer Testsuite oder in eine externe Datei gespeichert werden (Abb. 8). Falls Sie mehrere Projekte gleichzeitig offen haben, können Sie in der Liste das Projekt auswählen, in dem der Anhang angelegt werden soll. Klicken Sie auf ''Speichern'' im Bereich ''Einstellungen im Anhang speichern'' und geben Sie als Name ''expeccoMobileDemo'' an. Klicken Sie nun auf ''Server starten und verbinden'' (6) um mit der angegebenen Konfiguration eine Verbindung herzustellen.<br />
<br />
[[Datei:MobileTestingEinstellungenSpeichern.png | frame | left | Abb. 8: Einstellungen speichern]]<br />
<br clear="all"><br />
Der Verbindungsaufbau kann eine Weile dauern. Warten Sie bis die Verbindung aufgebaut ist und im GUI-Browser angezeigt wird. Sie sehen, dass die App auf dem Gerät gestartet wird. Nun wissen Sie, dass die Konfiguration funktioniert. Die gespeicherten Einstellungen sollen nun für den Test verwendet werden, der dann die gleiche Verbindung aufbaut. Wählen Sie die Verbindung im GUI-Browser aus, machen Sie einen Rechtsklick und wählen Sie im Kontextmenü ''Verbindung abbauen'', damit es zu keinem Konflikt kommt. Wechseln Sie dann zurück zum Reiter der Testsuite.<br />
<br />
In der Testsuite wurden die Einstellungen als Anhang ''expeccoMobileDemo'' angelegt (Abb 9). Wählen Sie den Baustein ''Connect'' (1) aus und wechseln Sie rechts zur Ansicht ''Netzwerk'' (2). Ziehen Sie per Drag-and-drop die Einstellungen in das Netzwerk des Bausteins (3). Verbinden Sie den Ausgangspin ''pathName'' mit dem Eingangspin ''stringOrFilename[1]'' des Bausteins ''Connect from File'' (4). Mit ''Übernehmen'' (5) bestätigen Sie die Änderungen. Dieser Baustein wird zu Beginn des Tests die Verbindung zur App herstellen.<br />
<br />
[[Datei:MobileTestingConnectblock.png | frame | left | Abb. 9: Verbindungsbaustein editieren]]<br />
<br clear="all"><br />
Wechseln Sie nun zum Testplan ''Demo-Test'' (1) (Abb. 10). Dieser Testplan enthält bereits einige fertige Testfälle. Vor und nach der Ausführung (2) ist außerdem jeweils ein Baustein eingetragen: Der eben bearbeitete Baustein ''Connect'' für den Aufbau und der Baustein ''Disconnect'' für den Verbindungsabbau. Durch das Eintragen der beiden Bausteine an dieser Stelle geschieht der Verbindungsabbau insbesondere auch dann, wenn der Test vorzeitig abgebrochen wird, z. B. weil einer der Testfälle fehlschlägt.<br />
<br />
[[Datei:MobileTestingTestplan.png | frame | left | Abb. 10: Testplanausführung]]<br />
<br clear="all"><br />
Jetzt können Sie den Testplan ''Demo-Test'' starten, indem Sie auf den grünen Play-Knopf (3) klicken. Der Testplan sollte ohne Fehler durchlaufen.<br />
<br />
=== Schritt 2: Einen Baustein mit dem Recorder erstellen ===<br />
Mit Hilfe des integrierten Recorders lassen sich einfach Ausführungssequenzen aufnehmen und in einem Baustein speichern. Dafür muss eine Verbindung zu einem Testgerät bestehen, mit dessen Hilfe der Test erstellt wird.<br />
<br />
Um eine Verbindung aufzubauen, wechseln Sie zurück zum GUI-Browser. In diesem ist noch die Verbindung eingetragen, die Sie zuvor angelegt haben. Da für die Verbindung im Testlauf derselbe Name verwendet wurde, wurden die Einstellungen damit überschrieben (In unserem Fall waren die Einstellungen ohnehin identisch). Die Verbindung ist zur Zeit nicht aktiv, da sie am Ende der Ausführung abgebaut wurde. Die Einstellungen sind dort aber noch eingetragen. Um die Verbindung mit dieser Konfiguration wieder aufzubauen, wählen Sie sie aus, gefolgt von einem Rechtsklick und ''Verbinden''.<br />
<br />
Warten Sie, bis die Verbindung aufgebaut ist (1) und drücken Sie dann den Aufnahme-Knopf (2), um eine Aufzeichnung zu starten (Abb. 11).<br />
<br />
[[Datei:MobileTestingRecorderStarten.png | frame | left | Abb. 11: Recorder starten]]<br />
<br clear="all"><br />
Es öffnet sich ein Fenster mit dem Mobile Testing Recorder (Abb. 12). Dieser zeigt einen Screenshot des verbundenen Geräts. Über diese Anzeige können Sie das Gerät fernsteuern. Dabei wird jede Aktion, die Sie ausführen, im Hintergrund aufgezeichnet.<br />
<br />
In der oberen Menüleiste können Sie das Werkzeug auswählen (1), mit dem Sie eine Aktion eingeben möchten. Als Voreinstellung ist das Werkzeug ''Auto'' ausgewählt. Sie können damit bestimmte Aktionen aufzeichnen, indem Sie mit dem Mauszeiger entsprechende Gesten auf der Anzeige ausführen. Wenn Sie zum Beispiel mit der linken Maustaste lange klicken, entspricht das einem langen Antippen des Elements an dieser Stelle. Anstatt die gewünschte Aktion mit der entsprechenden Geste zu bestimmen, können Sie diese alternativ auch manuell auswählen.<br />
<br />
Es soll nun ein neuer Test für das Erkennen korrekter GTIN-13-Codes aufgenommen werden. Klicken Sie zunächst in der Anzeige kurz auf den Button ''GTIN-13 (EAN-13)'' (2) der App um einen entsprechenden Klick auf dem Gerät auszulösen. Während der Ausführung dieser Aktion wird der Rahmen des Recorders kurzzeitig rot. Falls der Recorder danach nicht die aktuelle Ansicht der App darstellen sollte, klicken Sie im Recorder auf das Aktualisierungssymbol (3).<br />
<br />
[[Datei:MobileTestingRecorder1.png | frame | left | Abb. 12: Über Recorder zur GTIN-13-Activity wechseln]]<br />
<br clear="all"><br />
Anschließend soll im Eingabefeld der neuen Seite eine korrekte GTIN-13 eingegeben werden. Führen Sie dazu einen Rechtsklick auf dem Eingabefeld (1) aus und wählen Sie im Kontextmenü die Aktion ''Text setzen'' (2) (Abb. 13). Geben Sie in den sich daraufhin öffnenden Dialog eine beliebige gültige Artikelnummer im GTIN-13-Format ein, bspw. ''4006381333986'' (3). Dieser Text wird nun in der App gesetzt.<br />
<br />
[[Datei:MobileTestingRecorder2.png | frame | left | Abb. 13: GTIN-13-Code über Recorder eingeben]]<br />
<br clear="all"><br />
Klicken Sie nun auf ''Verify'' (1) (Abb. 14). In der App erscheint nun als Ergebnis ''OK'' (2). Der Test soll feststellen, ob tatsächlich dieses Ergebnis angezeigt wird. Nach einem Rechtsklick darauf können Sie im Kontextmenü die Aktion ''Attribut zusichern'' (3) auswählen. Wählen Sie im Dialog, der sich daraufhin öffnet, die Eigenschaft ''text'' (4) aus und bestätigen Sie mit ''OK'' (5). Dieses Mal wird keine Aktion auf dem Gerät ausgelöst, sondern nur ein Baustein aufgezeichnet, der fehlschlägt, sollte das Ergebnis vom erwarteten Wert ''OK'' abweichen.<br />
<br />
[[Datei:MobileTestingRecorder3.png | frame | left | Abb. 14: Antwort der App über Recorder auslesen]]<br />
<br clear="all"><br />
Schließen Sie nun den Recorder. Im ''Arbeitsbereich'' des GUI-Browsers sehen Sie, dass für jede der aufgenommenen Aktionen ein Baustein angelegt wurde (Abb. 15). Sie können nun testen, ob sich das Aufgenommene wieder abspielen lässt. Dazu müssen Sie zunächst die App auf Ihrem Gerät in den Anfangszustand zurückbringen, indem Sie auf dem Gerät die Schaltfläche ''HOME'' oben rechts benutzen. Klicken Sie dann in expecco auf den grünen Play-Knopf (1). Wird alles grün, war die Ausführung erfolgreich. Erstellen Sie nun daraus einen neuen Baustein in der Testsuite, indem Sie auf das Bausteinsymbol (2) in der rechten oberen Ecke klicken. Geben Sie ihm den Namen ''GTIN_Verify_OK'' (3) und bestätigen Sie (4).<br />
<br />
[[Datei:MobileTestingArbeitsbereich.png | frame | left | Abb. 15: Neuen Baustein aus Arbeitsbereich exportieren]]<br />
<br clear="all"><br />
Bauen Sie nun die Verbindung ab, indem Sie die Verbindung auswählen, rechtsklicken und im Kontextmenü ''Verbindung abbauen'' auswählen.<br />
<br />
Wechseln Sie zurück zum Reiter der Testsuite. Dort wurde der neue Baustein angelegt. Wählen Sie wieder den Testplan ''Demo-Test'' aus und fügen Sie den aufgenommenen Testfall ''GTIN_Verify_OK'' per Drag-and-drop am Ende des Testplans hinzu. Übernehmen Sie die Änderung und starten Sie erneut. Der Testplan sollte wieder ohne Fehler durchlaufen.<br />
<br />
=== Schritt 3: XPath anpassen mithilfe des GUI-Browsers ===<br />
Ihr neuer Baustein funktioniert auf anderen Geräten möglicherweise nicht. Die verwendeten Elemente werden über einen XPath adressiert und dieser kann auf anderen Geräten nicht stimmen. Lesen Sie dazu den Abschnitt [[#XPath_anpassen_mithilfe_des_GUI-Browsers|XPath anpassen mithilfe des GUI-Browsers]]. Falls Ihnen ein weiteres Gerät zur Verfügung steht, können Sie nun versuchen, die Pfade in Ihren erstellten Bausteinen zu verallgemeinern. Sie können diesen Schritt aber auch überspringen.<br />
<br />
Wenn es Ihnen schwerfällt, verkürzte Pfade zu finden, orientieren Sie sich dabei an den Pfaden der bereits vorhandenen Bausteine. Starten Sie den Test erneut. Sollte der Test jetzt fehlschlagen, überprüfen Sie die Pfade noch einmal im GUI-Browser.<br />
Um den Test nun auf einem zweiten Gerät auszuführen, öffnen Sie im Menü ''Erweiterungen'' > ''Mobile Testing'' > ''Verbindungseinstellungen erstellen''. Sie erhalten einen Dialog ähnlich zum Verbindungsdialog. Allerdings können Sie hier nur Einstellungen erstellen und speichern aber keine Verbindung herstellen. Sie haben jedoch die Möglichkeit, einzelne Aspekte der Einstellungen zu speichern wie bspw. nur das Gerät. Wählen Sie das neue Gerät aus und klicken Sie länger auf das Symbol zum Speichern im Anhang bis sich das verzögerte Menü öffnet (Abb. 16). Wählen Sie hier ''Geräte-Einstellungen speichern''. Benennen Sie den Anhang am besten nach dem Gerät. Danach können Sie den Dialog wieder schließen.<br />
<br />
[[Datei:MobileTestingGerätSpeichern.png | frame | left | Abb. 16: Einstellungen für ein Gerät speichern]]<br />
<br clear="all"><br />
Wählen Sie den Baustein ''Connect'' aus und ziehen Sie die Einstellungen für das neue Gerät in dessen Netzwerk. Verbinden Sie nun dessen Ausgangspin ''pathName'' mit dem Eingangspin ''stringOrFilename[2]'' des Bausteins ''Connect from File''. Der Baustein Connect from File liest die Angaben an den Eingangspins von oben nach unten ein, mehrfache Eigenschaften werden dabei ersetzt. In diesem Fall werden also die Einstellungen zum verwendeten Gerät ersetzt, während die übrigen Einstellungen gleich bleiben. Wenn Sie die Pfade geschickt gewählt haben, wird der Test nun auch auf dem anderen Gerät erfolgreich ablaufen.<br />
<br />
=== Schritt 4: Noch einen Baustein erstellen ===<br />
Falls sich gleiche Abläufe im Test wiederholen, können Sie dafür bereits erstellte Bausteine wiederverwenden oder abwandeln. Der in Schritt 2 erstellte Baustein prüft die Erkennung korrekter GTIN-13-Codes. Es fehlt noch ein Test, der umgekehrt das Erkennen eines falschen GTIN-13-Codes prüft. Die Struktur der beiden Tests ist identisch, sie unterscheiden sich lediglich in ihren Parametern. Kopieren Sie daher den Baustein ''GTIN_Verify_OK'' und benennen Sie die Kopie in ''GTIN_Verify_NOT_OK'' um. Ändern Sie die Eingabe der GTIN-13 in einen falschen Code zum Beispiel durch Ändern der letzten Ziffer (''4006381333987'') und setzen Sie den Überprüfungswert der Ausgabe auf ''NOT OK'' (Abb. 17).<br />
<br />
[[Datei:MobileTestingGTIN_Verify_NOT_OK.png | frame | left | Abb. 17: Baustein editieren]]<br />
<br clear="all"><br />
Fügen Sie diesen neuen Test ebenfalls zum Testplan Demo-Test hinzu und setzen Sie ihn ans Ende. Führen Sie den Testplan aus, aber vergessen Sie nicht, vorher die Verbindung im GUI-Browser abzubauen.<br />
<br />
Der neue Test wird fehlschlagen, weil Ihr aufgenommener Baustein nicht wieder zur Startseite der App zurückkehrt, die Tests aber jeweils von dort aus starten. In den anderen Bausteinen ist dies bereits berücksichtigt; sie führen abschließend immer den Baustein ''Back to main menu'' aus. Sie sehen das, indem Sie einen der anderen Bausteine, z. B. ''GTIN_Calculate'', auswählen und auf seine Schema-Ansicht wechseln. Dort steht der Baustein ''Back to main menu'' im Feld ''Nach Ausführung'' (Abb. 18). Wie beim entsprechenden Feld beim Testplan wird auch dieser Baustein immer am Ende ausgeführt, unabhängig davon, ob der Test erfolgreich verläuft oder abbricht. Ergänzen Sie diesen Eintrag nun in Ihren Bausteinen ''GTIN_Verify_OK'' und ''GTIN_Verify_NOT_OK''. Wählen Sie dazu den Baustein aus und ziehen Sie in der Schema-Ansicht den Baustein ''Back to main menu'' einfach auf das Eingabefeld ''Nach Ausführung''. Nun können Sie den Testplan starten und alle Tests sollten wieder problemlos ausgeführt werden.<br />
<br />
[[Datei:AppiumDemo Nach Ausführung.png | frame | left | Abb. 18: Nach-Ausführungs-Baustein setzen]]<br />
<br clear="all"><br />
<br />
=== Schritt 5: Test vervollständigen ===<br />
Für die Activity IBAN sind bereits alle Antwortmöglichkeiten der App mit Testfällen abgedeckt. In der GTIN-13-Activity werden ein korrekter und ein fehlerhafter Code getestet und eine Prüfziffer berechnet, das Verhalten der App bei Eingaben falscher Länge wird aber bisher nicht getestet (Bei Verify '''Input must be exactly 13 digits''. und ''…12 digits''. bei Calculate). Die Activity zum Prüfen der Seriennummern von Eurobanknoten wird noch gar nicht getestet. Wie bei der IBAN können hier drei Fälle auftreten: eine korrekte Seriennummer wurde eingegeben (Antwort: ''OK''), eine falsche Seriennummer wurde eingegeben (Antwort: ''NOT OK'') oder die Angabe entspricht nicht dem Format (Antwort: ''A serial number consists of 12 characters with the first one or two being capital letters (A-Z).''). Sie können die Testabdeckung jetzt noch erweitern, indem Sie entsprechende Testfälle erstellen. Die Bausteine dafür können Sie wie in Schritt 2 mit dem Recorder erstellen und die XPaths bei Bedarf verallgemeinern. Wenn Sie mit dem grundsätzlichen Umgang mit expecco vertraut sind, können Sie Bausteine natürlich auch ohne Recorder erstellen, indem Sie sie manuell aus vorhandenen Bausteinen der Bibliothek zusammensetzen. Sie können auch beide Vorgehensweisen nach Belieben kombinieren.<br />
<br />
Beachten Sie, dass die hier vorgestellten Testfälle jeweils nur einzelne Eingaben prüfen. Wenn Sie Testfälle für Ihre eigenen Apps schreiben, wollen Sie vermutlich engmaschiger testen, indem Sie noch weitere unterschiedliche Werte eingeben, die insbesondere auch Randfälle enthalten.<br />
<br />
==<span id="FirstStepsIOS"><!-- Referenced by m03_expeccoMobileDemoIOS.ets --></span> Erste Schritte mit iOS ==<br />
Es wird vorausgesetzt, dass Sie das Kapitel [[#Installation_und_Aufbau|Installation und Aufbau]] bereits gelesen und die nötigen Vorbereitungen für die Verwendung von iOS-Geräten unter Mac OS abgeschlossen haben. Schließen Sie das Gerät, das Sie verwenden wollen, an den Mac an. Laden Sie die iOS-Version der [http://download.exept.de/transfer/h-expecco-2.11.0-pre/expeccoMobileDemo.ipa expeccoMobileDemo-App] auf den Mac herunter. Da es sich bei der App um einen Debug-Build handelt, müssen Sie sie noch für Ihr Gerät signieren (siehe [[#iOS-Ger.C3.A4t_und_App_vorbereiten|iOS-Gerät und App vorbereiten]]). Starten Sie nun einen Appium-Server auf dem Mac.<br />
<br />
=== Schritt 1: Demo ausführen ===<br />
Starten Sie expecco und öffnen Sie die Testsuite ''m03_expeccoMobileDemoIOS.ets'' über die Schaltfläche ''Beispiel aus Datei'' (Abb. 1). Ab expecco 2.11 befindet sich diese im Unterordner ''mobile''. Ansonsten laden Sie die Testsuite [http://download.exept.de/transfer/h-expecco-2.10.0/m03_expeccoMobileDemoIOS.ets m03_expeccoMobileDemoIOS.ets] auf den Rechner, auf dem sich Ihre expecco-Installation befindet, und öffnen diese. In dieser Testsuite befindet sich bereits ein vorgefertigter Testplan mit einigen Testfällen für diese App.<br />
<br />
[[Datei:MobileTestingIOSBeispielÖffnen.png | frame | left | Abb. 1: Beispiel-Testsuite öffnen]]<br />
<br clear="all"><br />
Bevor wir uns mit dem weiteren Inhalt der Testsuite beschäftigen, konfigurieren Sie zuerst die Verbindung und welches Gerät Sie benutzen wollen. Öffnen Sie nun den GUI-Browser (1) und wählen Sie unter ''Verbinden'' (2) den Eintrag ''Mobile Testing'' (3) (Abb. 2), um den Verbindungsdialog zu öffnen.<br />
[[Datei:MobileTestingVerbinden.png | frame | left | Abb. 2: Verbindungseditor öffnen]]<br />
<br clear="all"><br />
<br />
Hier können Sie ein iOS-Gerät nur von Hand eintragen. Wählen Sie dazu ''iOS-Gerät eingeben'' (Abb. 3). Den Namen und die iOS-Version des Geräts können Sie dessen Eigenschaften entnehmen. Um die Gerätekennung des Geräts zu erfahren, öffnen Sie auf dem Mac in Xcode das Fenster Devices (Command-Shift-2). Dort werden alle angeschlossenen Geräte sowie die zur Verfügung stehenden Simulatoren angezeigt. Hier sehen Sie auch die Gerätekennung (udid) Ihres Geräts und welche Apps installiert wurden. Nachdem Sie das Gerät im Verbindungseditor eingegeben haben, wählen Sie es in der Liste aus und klicken Sie dann auf Weiter.<br />
<br />
[[Datei:MobileTestingIOSGerät.png | frame | left | Abb. 3: Hinzufügen eines iOS-Geräts]]<br />
<br clear="all"><br />
<br />
Als nächstes geben Sie an, welche App Sie verwenden wollen. Dabei können Sie wählen, ob Sie eine App starten möchten, die bereits auf dem Gerät installiert ist (''App auf dem Gerät'') oder ob eine App installiert und gestartet werden soll (''App installieren''). Für den Fall, dass Sie eine bereits installierte App benutzen wollen, müssen Sie deren Bundle-ID angeben. Diese erfahren Sie ebenfalls im Devices-Fenster von Xcode. Für die Demo-App lautet sie beispielsweise ''de.exept.expeccoMobileDemo''.<br />
<br />
Für dieses Tutorial soll die Demo-App erst installiert werden. Wählen Sie also ''App installieren'' aus und tragen Sie bei App den Pfad zu der Datei auf dem Mac ein (Abb. 4). Wenn Sie expecco 2.11 verwenden, können Sie auf dieser Seite auch die Team-ID angeben, die für iOS-Verbindungen angibt, welches Zertifiat verwendet werden soll. Falls Sie bereits in den [[#Konfiguration_des_Plugins|Plugin-Einstellungen]] eine ID angegeben haben, wird diese verwendet. Sie wird hier grau dargestellt, solange Sie keinen anderen Wert angeben. Klicken Sie nun auf ''Weiter''.<br />
<br />
[[Datei:MobileTestingIOSAppInstallieren.png | frame | left | Abb. 4: App angeben, die auf dem Gerät installiert werden soll]]<br />
<br clear="all"><br />
<br />
Auf der letzten Seite sehen Sie eine Übersicht aller bisherigen Angaben (1) (Abb. 5). Unterhalb der Capabilityliste können Sie einen Namen für die Verbindung angeben, unter dem sie im GUI-Browser angezeigt wird (2). Außerdem lässt sich eine Verbindung über diesen Namen identifizieren und in Bausteinen verwenden; der Name muss daher eindeutig sein. Falls Sie keinen Namen angeben, wird generisch einer erzeugt. Geben Sie als Namen ''expeccoMobileDemo'' ein. Im Feld darunter ist die Adresse zum Appium-Server einzutragen (3). Wenn Sie den Appium-Server mit Standardeinstellungen gestartet haben, müssen Sie dazu nur in der Standardadresse (unterster Eintrag der Vorschlagsliste) ''localhost'' durch die IP-Adresse des Macs ersetzen (im Bild ''172.23.1.49''). Um sicher zu gehen, auf welchem Port der Appium-Server lauscht, sehen Sie in dessen Ausgabe. Dort finden am Anfang die Zeile<br />
<nowiki>info: Appium REST http interface listener started on 0.0.0.0:4723</nowiki><br />
Steht hier am Ende nicht der Standardport ''4723'' ändern Sie diese Angabe entsprechend ebenfalls in der Konfiguration.<br />
<br />
Wenn die Option ''Bei Bedarf starten'' (4) aktiviert ist, überprüft expecco, ob an der Adresse bereits ein Appium-Server läuft, und startet und beendet ihn bei Bedarf automatisch. Das ist allerdings nur für lokale Serveradressen möglich, schalten Sie diese Option daher ab.<br />
<br />
[[Datei:MobileTestingServerkonfigurationIOS.png | frame | left | Abb. 5: Verbindungsnamen und Appium-Server konfigurieren]]<br />
<br clear="all"><br />
<br />
Klicken Sie nun auf ''Speichern'' (5) um die Einstellungen für die Testausführung zu speichern. Einstellungen können als Anhang einer Testsuite oder in eine externe Datei gespeichert werden (Abb. 6). Falls Sie mehrere Projekte gleichzeitig offen haben, können Sie in der Liste das Projekt auswählen, in dem der Anhang angelegt werden soll. Klicken Sie auf ''Speichern'' im Bereich ''Einstellungen im Anhang speichern'' und geben Sie als Name ''expeccoMobileDemo'' an. Klicken Sie nun auf ''Verbinden'' (6) um mit der angegebenen Konfiguration eine Verbindung herzustellen.<br />
<br />
[[Datei:MobileTestingEinstellungenSpeichern.png | frame | left | Abb. 6: Einstellungen speichern]]<br />
<br clear="all"><br />
<br />
Der Verbindungsaufbau kann eine Weile dauern. Wenn Sie die Server-Adresse korrekt angegeben haben, sollten Sie in der Ausgabe des Appium-Servers den Verbindungsversuch erkennen. Auf Ihrem iOS-Gerät sollte dabei die App gestartet werden. Passiert nichts auf dem Gerät, kann es daran liegen, dass entweder das Gerät oder die App nicht gefunden wird. Versucht Appium hingegen, die App zu starten und dies schlägt fehl, ist wahrscheinlich die App falsch signiert. Deinstallieren Sie in diesem Fall die App, damit sie mit einer neuen Signatur wieder installiert werden kann.<br />
<br />
Warten Sie bis die Verbindung aufgebaut ist und im GUI-Browser angezeigt wird. Nun wissen Sie, dass die Konfiguration funktioniert. Die gespeicherten Einstellungen sollen nun für den Test verwendet werden, der dann die gleiche Verbindung aufbaut. Wählen Sie die Verbindung im GUI-Browser aus, machen Sie einen Rechtsklick und wählen Sie im Kontextmenü ''Verbindung abbauen'', damit es zu keinem Konflikt kommt. Wechseln Sie dann zurück zum Reiter der Testsuite.<br />
<br />
In der Testsuite wurden die Einstellungen als Anhang ''expeccoMobileDemo'' angelegt (Abb 7). Wählen Sie den Baustein ''Connect'' (1) aus und wechseln Sie rechts zur Ansicht ''Netzwerk'' (2). Ziehen Sie per Drag-and-drop die Einstellungen in das Netzwerk des Bausteins (3). Verbinden Sie den Ausgangspin ''pathName'' mit dem Eingangspin ''stringOrFilename[1]'' des Bausteins ''Connect from File'' (4). Mit ''Übernehmen'' (5) bestätigen Sie die Änderungen. Dieser Baustein wird zu Beginn des Tests die Verbindung zur App herstellen.<br />
<br />
[[Datei:MobileTestingConnectblock.png | frame | left | Abb. 7: Verbindungsbaustein editieren]]<br />
<br clear="all"><br />
<br />
Wechseln Sie nun zum Testplan ''Demo-Test'' (1) (Abb. 8). Dieser Testplan enthält bereits einige fertige Testfälle. Vor und nach der Ausführung (2) ist außerdem jeweils ein Baustein eingetragen: Der eben bearbeitete Baustein ''Connect'' für den Aufbau und der Baustein ''Disconnect'' für den Verbindungsabbau. Durch das Eintragen der beiden Bausteine an dieser Stelle geschieht der Verbindungsabbau insbesondere auch dann, wenn der Test vorzeitig abgebrochen wird, z. B. weil einer der Testfälle fehlschlägt.<br />
<br />
[[Datei:MobileTestingTestplan.png | frame | left | Abb. 8: Testplanausführung]]<br />
<br clear="all"><br />
Jetzt können Sie den Testplan ''Demo-Test'' starten, indem Sie auf den grünen Play-Knopf (3) klicken. Der Testplan sollte ohne Fehler durchlaufen.<br />
<br />
=== Schritt 2: Einen Baustein mit dem Recorder erstellen ===<br />
Mit Hilfe des integrierten Recorders lassen sich einfach Ausführungssequenzen aufnehmen und in einem Baustein speichern. Dafür muss eine Verbindung zu einem Testgerät bestehen, mit dessen Hilfe der Test erstellt wird.<br />
<br />
Um eine Verbindung aufzubauen, wechseln Sie zurück zum GUI-Browser. In diesem ist noch die Verbindung eingetragen, die Sie zuvor angelegt haben. Da für die Verbindung im Testlauf derselbe Name verwendet wurde, wurden die Einstellungen damit überschrieben (In unserem Fall waren die Einstellungen ohnehin identisch). Die Verbindung ist zur Zeit nicht aktiv, da sie am Ende der Ausführung abgebaut wurde. Die Einstellungen sind dort aber noch eingetragen. Um die Verbindung mit dieser Konfiguration wieder aufzubauen, wählen Sie sie aus, gefolgt von einem Rechtsklick und ''Verbinden''.<br />
<br />
Warten Sie, bis die Verbindung aufgebaut ist (1) und drücken Sie dann den Aufnahme-Knopf (2), um eine Aufzeichnung zu starten (Abb. 9).<br />
<br />
[[Datei:MobileTestingRecorderStarten.png | frame | left | Abb. 9: Recorder starten]]<br />
<br clear="all"><br />
Es öffnet sich ein Fenster mit dem Mobile Testing Recorder (Abb. 10). Dieser zeigt einen Screenshot des verbundenen Geräts. Über diese Anzeige können Sie das Gerät fernsteuern. Dabei wird jede Aktion, die Sie ausführen, im Hintergrund aufgezeichnet.<br />
<br />
In der oberen Menüleiste können Sie das Werkzeug auswählen (1), mit dem Sie eine Aktion eingeben möchten. Als Voreinstellung ist das Werkzeug ''Auto'' ausgewählt. Sie können damit bestimmte Aktionen aufzeichnen, indem Sie mit dem Mauszeiger entsprechende Gesten auf der Anzeige ausführen. Wenn Sie zum Beispiel mit der linken Maustaste lange klicken, entspricht das einem langen Antippen des Elements an dieser Stelle. Anstatt die gewünschte Aktion mit der entsprechenden Geste zu bestimmen, können Sie diese alternativ auch manuell auswählen.<br />
<br />
Es soll nun ein neuer Test für das Erkennen korrekter GTIN-13-Codes aufgenommen werden. Klicken Sie zunächst in der Anzeige kurz auf den Button ''GTIN-13 (EAN-13)'' (2) der App um einen entsprechenden Klick auf dem Gerät auszulösen. Während der Ausführung dieser Aktion wird der Rahmen des Recorders kurzzeitig rot. Falls der Recorder danach nicht die aktuelle Ansicht der App darstellen sollte, klicken Sie im Recorder auf das Aktualisierungssymbol (3).<br />
<br />
[[Datei:MobileTestingRecorder1iOS.png | frame | left | Abb. 10: Über Recorder zur GTIN-13-Activity wechseln]]<br />
<br clear="all"><br />
Anschließend soll im Eingabefeld der neuen Seite eine korrekte GTIN-13 eingegeben werden. Führen Sie dazu einen Rechtsklick auf dem Eingabefeld (1) aus und wählen Sie im Kontextmenü die Aktion ''Text setzen'' (2) (Abb. 11). Geben Sie in den sich daraufhin öffnenden Dialog eine beliebige gültige Artikelnummer im GTIN-13-Format ein, bspw. ''4006381333986'' (3). Dieser Text wird nun in der App gesetzt.<br />
<br />
[[Datei:MobileTestingRecorder2iOS.png | frame | left | Abb. 11: GTIN-13-Code über Recorder eingeben]]<br />
<br clear="all"><br />
Klicken Sie nun auf ''Verify'' (1) (Abb. 12). In der App erscheint nun als Ergebnis ''OK'' (2). Der Test soll feststellen, ob tatsächlich dieses Ergebnis angezeigt wird. Nach einem Rechtsklick darauf können Sie im Kontextmenü die Aktion ''Attribut zusichern'' (3) auswählen. Wählen Sie im Dialog, der sich daraufhin öffnet, die Eigenschaft ''value'' (4) aus und bestätigen Sie mit ''OK'' (5). Dieses Mal wird keine Aktion auf dem Gerät ausgelöst, sondern nur ein Baustein aufgezeichnet, der fehlschlägt, sollte das Ergebnis vom erwarteten Wert ''OK'' abweichen.<br />
<br />
[[Datei:MobileTestingRecorder3iOS.png | frame | left | Abb. 12: Antwort der App über Recorder auslesen]]<br />
<br clear="all"><br />
Schließen Sie nun den Recorder. Im ''Arbeitsbereich'' des GUI-Browsers sehen Sie, dass für jede der aufgenommenen Aktionen ein Baustein angelegt wurde (Abb. 13). Sie können nun testen, ob sich das Aufgenommene wieder abspielen lässt. Dazu müssen Sie zunächst die App auf Ihrem Gerät in den Anfangszustand zurückbringen, indem Sie auf dem Gerät die Schaltfläche ''Home'' oben links benutzen. Klicken Sie dann in expecco auf den grünen Play-Knopf (1). Wird alles grün, war die Ausführung erfolgreich. Erstellen Sie nun daraus einen neuen Baustein in der Testsuite, indem Sie auf das Bausteinsymbol (2) in der rechten oberen Ecke klicken. Geben Sie ihm den Namen ''GTIN_Verify_OK'' (3) und bestätigen Sie (4).<br />
<br />
[[Datei:MobileTestingArbeitsbereich.png | frame | left | Abb. 13: Neuen Baustein aus Arbeitsbereich exportieren]]<br />
<br clear="all"><br />
Bauen Sie nun die Verbindung ab, indem Sie die Verbindung auswählen, rechtsklicken und im Kontextmenü ''Verbindung abbauen'' auswählen.<br />
<br />
Wechseln Sie zurück zum Reiter der Testsuite. Dort wurde der neue Baustein angelegt. Wählen Sie wieder den Testplan ''Demo-Test'' aus und fügen Sie den aufgenommenen Testfall ''GTIN_Verify_OK'' per Drag-and-drop am Ende des Testplans hinzu. Übernehmen Sie die Änderung und starten Sie erneut. Der Testplan sollte wieder ohne Fehler durchlaufen.<br />
<br />
=== Schritt 3: XPath anpassen mithilfe des GUI-Browsers ===<br />
Ihr neuer Baustein funktioniert auf anderen Geräten möglicherweise nicht. Die verwendeten Elemente werden über einen XPath adressiert und dieser kann auf anderen Geräten nicht stimmen. Lesen Sie dazu den Abschnitt [[#XPath_anpassen_mithilfe_des_GUI-Browsers|XPath anpassen mithilfe des GUI-Browsers]]. Falls Ihnen ein weiteres Gerät zur Verfügung steht, können Sie nun versuchen, die Pfade in Ihren erstellten Bausteinen zu verallgemeinern. Sie können diesen Schritt aber auch überspringen.<br />
<br />
Wenn es Ihnen schwerfällt, verkürzte Pfade zu finden, orientieren Sie sich dabei an den Pfaden der bereits vorhandenen Bausteine. Starten Sie den Test erneut. Sollte der Test jetzt fehlschlagen, überprüfen Sie die Pfade noch einmal im GUI-Browser.<br />
Um den Test nun auf einem zweiten Gerät auszuführen, öffnen Sie im Menü ''Erweiterungen'' > ''Mobile Testing'' > ''Verbindungseinstellungen erstellen''. Sie erhalten einen Dialog ähnlich zum Verbindungsdialog. Allerdings können Sie hier nur Einstellungen erstellen und speichern aber keine Verbindung herstellen. Sie haben jedoch die Möglichkeit, einzelne Aspekte der Einstellungen zu speichern wie bspw. nur das Gerät. Geben Sie das neue Gerät ein und wählen Sie es aus. Klicken Sie länger auf das Symbol zum Speichern im Anhang bis sich das verzögerte Menü öffnet und wählen Sie hier ''Geräte-Einstellungen speichern'' (Abb. 14). Benennen Sie den Anhang am besten nach dem Gerät. Danach können Sie den Dialog wieder schließen.<br />
<br />
[[Datei:MobileTestingGerätSpeichern.png | frame | left | Abb. 14: Einstellungen für ein Gerät speichern]]<br />
<br clear="all"><br />
Wählen Sie den Baustein ''Connect'' aus und ziehen Sie die Einstellungen für das neue Gerät in dessen Netzwerk. Verbinden Sie nun dessen Ausgangspin ''pathName'' mit dem Eingangspin ''stringOrFilename[2]'' des Bausteins ''Connect from File''. Der Baustein Connect from File liest die Angaben an den Eingangspins von oben nach unten ein, mehrfache Eigenschaften werden dabei ersetzt. In diesem Fall werden also die Einstellungen zum verwendeten Gerät ersetzt, während die übrigen Einstellungen gleich bleiben. Wenn Sie die Pfade geschickt gewählt haben, wird der Test nun auch auf dem anderen Gerät erfolgreich ablaufen.<br />
<br />
=== Schritt 4: Noch einen Baustein erstellen ===<br />
Falls sich gleiche Abläufe im Test wiederholen, können Sie dafür bereits erstellte Bausteine wieder-verwenden oder abwandeln. Der in Schritt 2 erstellte Baustein prüft die Erkennung korrekter GTIN-13-Codes. Es fehlt noch ein Test, der umgekehrt das Erkennen eines falschen GTIN-13-Codes prüft. Die Struktur der beiden Tests ist identisch, sie unterscheiden sich lediglich in ihren Parametern. Kopieren Sie daher den Baustein ''GTIN_Verify_OK'' und benennen Sie die Kopie in ''GTIN_Verify_NOT_OK'' um. Ändern Sie die Eingabe der GTIN-13 in einen falschen Code zum Beispiel durch Ändern der letzten Ziffer (''4006381333987'') und setzen Sie den Überprüfungswert der Ausgabe auf ''NOT OK'' (Abb. 15).<br />
<br />
[[Datei:MobileTestingGTIN_Verify_NOT_OK_iOS.png | frame | left | Abb. 15: Baustein editieren]]<br />
<br clear="all"><br />
Fügen Sie diesen neuen Test ebenfalls zum Testplan Demo-Test hinzu und setzen Sie ihn ans Ende. Führen Sie den Testplan aus, aber vergessen Sie nicht, vorher die Verbindung im GUI-Browser abzubauen.<br />
<br />
Der neue Test wird fehlschlagen, weil Ihr aufgenommener Baustein nicht wieder zur Startseite der App zurückkehrt, die Tests aber jeweils von dort aus starten. In den anderen Bausteinen ist dies bereits berücksichtigt; sie führen abschließend immer den Baustein ''Back to main menu'' aus. Sie sehen das, indem Sie einen der anderen Bausteine, z. B. ''GTIN_Calculate'', auswählen und auf seine Schema-Ansicht wechseln. Dort steht der Baustein ''Back to main menu'' im Feld ''Nach Ausführung'' (Abb. 16). Wie beim entsprechenden Feld beim Testplan wird auch dieser Baustein immer am Ende ausgeführt, unabhängig davon, ob der Test erfolgreich verläuft oder abbricht. Ergänzen Sie diesen Eintrag nun in Ihren Bausteinen ''GTIN_Verify_OK'' und ''GTIN_Verify_NOT_OK''. Wählen Sie dazu den Baustein aus und ziehen Sie in der Schema-Ansicht den Baustein ''Back to main menu'' einfach auf das Eingabefeld ''Nach Ausführung''. Nun können Sie den Testplan starten und alle Tests sollten wieder problemlos ausgeführt werden.<br />
<br />
[[Datei:AppiumDemo Nach Ausführung.png | frame | left | Abb. 16: Nach-Ausführungs-Baustein setzen]]<br />
<br clear="all"><br />
<br />
=== Schritt 5: Test vervollständigen ===<br />
Für die Activity IBAN sind bereits alle Antwortmöglichkeiten der App mit Testfällen abgedeckt. In der GTIN-13-Activity werden ein korrekter und ein fehlerhafter Code getestet und eine Prüfziffer berechnet, das Verhalten der App bei Eingaben falscher Länge wird aber bisher nicht getestet (Bei Verify '''Input must be exactly 13 digits''. und ''…12 digits''. bei Calculate). Die Activity zum Prüfen der Seriennummern von Eurobanknoten wird noch gar nicht getestet. Wie bei der IBAN können hier drei Fälle auftreten: eine korrekte Seriennummer wurde eingegeben (Antwort: ''OK''), eine falsche Seriennummer wurde eingegeben (Antwort: ''NOT OK'') oder die Angabe entspricht nicht dem Format (Antwort: ''A serial number consists of 12 characters with the first one or two being capital letters (A-Z).''). Sie können die Testabdeckung jetzt noch erweitern, indem Sie entsprechende Testfälle erstellen. Die Bausteine dafür können Sie wie in Schritt 2 mit dem Recorder erstellen und die XPaths bei Bedarf verallgemeinern. Wenn Sie mit dem grundsätzlichen Umgang mit expecco vertraut sind, können Sie Bausteine natürlich auch ohne Recorder erstellen, indem Sie sie manuell aus vorhandenen Bausteinen der Bibliothek zusammensetzen. Sie können auch beide Vorgehensweisen nach Belieben kombinieren.<br />
<br />
Beachten Sie, dass die hier vorgestellten Testfälle jeweils nur einzelne Eingaben prüfen. Wenn Sie Testfälle für Ihre eigenen Apps schreiben, wollen Sie vermutlich engmaschiger testen, indem Sie noch weitere unterschiedliche Werte eingeben, die insbesondere auch Randfälle enthalten.<br />
<br />
= Dialoge des Mobile Testing Plugins =<br />
== Verbindungseditor ==<br />
Mithilfe des Verbindungseditors können Sie schnell Verbindungen definieren, ändern oder aufbauen. Je nach Aufgabe weist der Dialog kleine Unterschiede auf und wird unterschiedlich geöffnet:<br />
*Wenn Sie eine Verbindung aufbauen wollen, erreichen Sie den Dialog im GUI-Browser, indem Sie auf ''Verbinden'' klicken und dann ''Mobile Testing'' auswählen.<br />
*Um eine bestehende Verbindung im GUI-Browser zu ändern oder zu kopieren, wählen Sie diese aus, machen einen Rechtsklick und wählen im Kontextmenü entsprechend ''Verbindung bearbeiten'' oder ''Verbindung kopieren'' aus.<br />
*Wollen Sie Verbindungseinstellungen nicht für den GUI-Browser sondern zur Verwendung in einem Test erstellen, wählen Sie im Menü des Mobile Testing Plugins den Punkt ''Verbindungseinstellungen erstellen...''. Darüber können nur die Einstellungen für eine Verbindung erstellt werden, ohne dass eine Verbindung im GUI-Browser angelegt wird.<br />
<br />
Das Menü des Verbindungseditors weist verschiedenen Schaltflächen auf, von denen manche nur beim Erstellen von Verbindungseinstellungen sichtbar sind:<br />
[[Datei:MobileTestingVerbindungseditorMenu.png]]<br />
#''Einstellungen löschen'': Setzt alle Einträge zurück. (Nur beim Erstellen von Einstellungen sichtbar.)<br />
#''Einstellungen aus Datei laden'': Erlaubt das Öffnen einer gespeicherten Einstellungsdatei (*.csf). Deren Einstellungen werden in den Dialog übernommen. Bereits getätigte Eingaben ohne Konflikt bleiben dabei erhalten.<br />
#''Einstellungen aus Anhang laden'': Erlaubt das Öffnen eines Anhangs mit Verbindungseinstellungen aus einem geöffneten Projekt. Diese Einstellungen werden in den Dialog übernommen. Bereits getätigte Eingaben ohne Konflikt bleiben dabei erhalten.<br />
#''Einstellungen in Datei speichern'' und<br />
#''Einstellungen in Anhang speichern'': Hier können Sie die eingetragenen Einstellungen in eine Datei (*.csf) speichern oder als Anhang in einem geöffneten Projekt anlegen. Beide Optionen besitzen ein verzögertes Menü, in dem Sie auswählen können, nur einen bestimmten Teil der Einstellungen zu speichern. (Nur beim Erstellen von Einstellungen sichtbar.)<br />
#''Erweiterte Ansicht'': Damit können Sie in die erweiterte Ansicht wechseln, um zusätzliche Einstellungen vorzunehmen. Lesen Sie dazu mehr am Ende des Kapitels. (Nur beim Erstellen von Einstellungen sichtbar.)<br />
#''Hilfe'': An der rechten Seite wird ein Hilfetext zum jeweiligen Schritt ein- oder ausgeblendet.<br />
<br />
<br />
Der Dialog ist in drei Schritte unterteilt. Im ersten Schritt wählen Sie das Gerät, das Sie verwenden möchten, im zweiten Schritt wählen Sie aus, welche App verwendet werden soll und im letzten Schritt erfolgen die Einstellungen zum Appium-Server.<br />
<br />
===<span id="AppiumConnectionEditorStep1"><!-- Referenced by AppiumConnectionEditor in Mobile Testing Plugin --></span>Schritt 1: Gerät auswählen===<br />
Im oberen Teil erhalten Sie eine Liste aller angeschlossenen Appium-Geräte, die erkannt werden. Mit der Checkbox darunter können Sie die Geräte ausblenden, die zwar erkannt werden, aber nicht bereit sind. Falls Sie ein Gerät eintragen wollen, das nicht angeschlossen ist, können Sie dies mit dem entsprechenden Knopf ''Android-Gerät eingeben'' bzw. ''iOS-Gerät eingeben'' anlegen. Dazu müssen Sie jedoch die benötigten Eigenschaften Ihres Geräts kennen. Das Gerät wird dann in einer zweiten Geräteliste angelegt und kann dort ausgewählt werden. Wenn keine Liste mit angeschlossenen Elementen angezeigt werden kann, werden stattdessen verschiedene Meldungen angezeigt:<br />
*Keine Geräte gefunden<br />
*:expecco konnte keine Android-Geräte finden.<br />
*:Um eine Verbindung zu einem Gerät automatisch zu konfigurieren, stellen Sie sicher, dass es<br />
*:*angeschlossen ist<br />
*:*eingeschaltet ist<br />
*:*einen passenden adb-Treiber installiert hat<br />
*:*für Debugging freigeschaltet ist.<br />
*Keine verfügbaren Geräte gefunden<br />
*:expecco konnte keine verfügbaren Android-Geräte finden. Es wurden aber nicht verfügbare gefunden, z.B. mit dem Status "unauthorized".<br />
*:Um eine Verbindung zu einem Gerät automatisch zu konfigurieren, stellen Sie sicher, dass es<br />
*:*angeschlossen ist<br />
*:*eingeschaltet ist<br />
*:*einen passenden adb-Treiber installiert hat<br />
*:*für Debugging freigeschaltet ist.<br />
*:Um nicht verfügbare Geräte anzuzeigen, aktivieren Sie unten diese Option.<br />
*Verbindung verloren<br />
*:expecco hat die Verbindung zum adb-Server verloren. Versuchen Sie die Verbindung wieder herzustellen, indem Sie auf den Button klicken.<br />
*Verbindung fehlgeschlagen<br />
*:expecco konnte sich nicht mit dem adb-Server verbinden. Möglicherweise läuft er nicht oder der angegebene Pfad stimmt nicht.<br />
*:Überprüfen Sie die adb-Konfiguration in den Einstellungen und versuchen Sie den adb-Server zu starten und eine Verbindung herzustellen indem Sie auf den Knopf klicken.<br />
*Verbinden ...<br />
*:expecco verbindet sich mit dem adb-Server. Dies kann einige Sekunden dauern.<br />
*adb-Server starten ...<br />
*:expecco startet den adb-Server. Dies kann einige Sekunden dauern.<br />
<br />
<!--Bei ''Automatisierung durch'' können Sie angeben, welche Automation-Engine verwendet werden soll. Lassen Sie die Einstellung auf ''(Default)'' wird die entsprechende Capability gar nicht gesetzt. Ansonsten stehen Appium, Selendroid und ab expecco 2.11 XCUITest zur Verfügung. In der Regel wird Selendroid nur für Android-Geräte vor Version 4.1 gebraucht.-->Mit ''Weiter'' gelangen Sie zum nächsten Schritt. Wenn Sie Einstellungen für den GUI-Browser eingeben, ist das erst möglich, wenn ein Gerät ausgewählt wurde.<br />
<br />
===<span id="AppiumConnectionEditorStep2"><!-- Referenced by AppiumConnectionEditor in Mobile Testing Plugin --></span>Schritt 2: App auswählen===<br />
Hier können Sie Angaben zur App machen, die getestet werden soll. Dabei können Sie entscheiden, ob Sie eine App verwenden wollen, die bereits auf dem Gerät installiert ist, oder ob für den Test eine App installiert werden soll. Wählen Sie oben den entsprechenden Reiter aus. Je nachdem, ob Sie im vorigen Schritt ein Android- oder ein iOS-Gerät ausgewählt haben, ändert sich die erforderte Eingabe.<br />
<br />
*'''Android'''<br />
**''App auf dem Gerät''<br />
**:Wenn Sie im ersten Schritt ein angeschlossenes Gerät ausgewählt haben, werden die Pakete aller installierten Apps automatisch abgerufen und Sie können die Auswahl aus den Drop-down-Listen treffen. Die installierten Apps sind in Fremdpakete und Systempakete unterteilt; wählen Sie die entsprechende Paketliste aus. Diese Auswahl gehört nicht zu den Einstellungen, sondern stellt nur die entsprechende Paketliste zur Verfügung. Sie können den Filter benutzen, um die Liste weiter einzuschränken und dann das gewünschte Paket auswählen. Die Activities des ausgwählten Pakets werden ebenfalls automatisch abgerufen und als Drop-down-Liste zur Verfügung gestellt. Wählen Sie die Activity aus, die gestartet werden soll. In der Regel wird automatisch eine Activity aus der Liste eingetragen. Falls Sie kein verbundenes Gerät verwenden, müssen Sie die Eingabe des Pakets und der Activity von Hand vornehmen.<br />
**''App installieren''<br />
**:Geben Sie bei ''App'' den Pfad zu einer App an. Der Pfad muss für den Appium-Server gültig sein, der verwendet wird. Sie können auch eine URL angeben. Benutzen Sie einen lokalen Appium-Server, können Sie den rechten Butten benutzen, um zu der Installationsdatei der App zu navigieren und diesen Pfad einzutragen. Wenn möglich werden dabei auch das entsprechende Paket und die Activity in den Feldern darunter eingetragen. Diese Angabe ist aber nicht notwendig.<br />
<br />
*'''iOS'''<br />
**''App auf dem Gerät''<br />
**:Geben Sie die Bundle-ID einer installierten App an. Sie können die IDs der installierten Apps bspw. mithilfe von Xcode erfahren. Starten Sie dazu Xcode und wählen Sie in der Menüleiste am oberen Bildschirmrand im Menü ''Window'' den Eintrag ''Devices''. Es öffnet sich ein Fenster, in dem eine Liste der angeschlossenen Geräte angezeigt wird. Wenn Sie Ihr Gerät auswählen, sehen Sie in der Übersicht eine Auflistung der von Ihnen installierten Apps.<br />
**''App installieren''<br />
**:Geben Sie bei ''App'' den Pfad zu einer App an. Der Pfad muss für den Appium-Server gültig sein, der verwendet wird. Sie können auch eine URL angeben. Zu den Vorraussetzungen an Apps für reale Geräte lesen Sie bitte den Abschnitt [[#iOS-Ger.C3.A4t_und_App_vorbereiten|iOS-Geräte und App vorbereiten]].<br />
<br />
Im unteren Teil können Sie festlegen, ob die App beim Verbindungsabbau zurückgesetzt bzw. deinstalliert werden soll, und ob sie initial zurückgesetzt werden soll. Auch hier wird die entsprechende Capability gar nicht gesetzt, wenn Sie ''(Default)'' auswählen. Mit ''Weiter'' gelangen Sie zum nächsten Schritt.<br />
<br />
===<span id="AppiumConnectionEditorStep3"><!-- Referenced by AppiumConnectionEditor in Mobile Testing Plugin --></span>Schritt 3: Servereinstellungen===<br />
Im letzten Schritt befindet sich zunächst im oberen Teil eine Liste aller Capabilities, die sich aus Ihren Angaben der vorigen Schritte ergeben. Wenn Sie sich mit Appium auskennen und noch zusätzliche Capabilities setzen möchten, die der Verbindungseditor nicht abdeckt, können Sie durch Klicken auf ''Bearbeiten'' in die erweiterte Ansicht gelangen. Lesen Sie dazu den Abschnitt weiter unten.<br />
<br />
Wenn Sie Einstellungen für den GUI-Browser eingeben, können Sie den ''Verbindungsnamen'' eintragen, mit dem die Verbindung angezeigt wird. Dies ist auch der Name unter dem Bausteine diese Verbindung verwenden können, wenn sie aufgebaut ist. Wenn Sie das Feld frei lassen, wird ein Name generiert. Um die Adresse für den Appium-Server anzugeben, erhalten Sie die lokale Standard-Adresse und bereits verwendete Adressen zur Auswahl. Wenn Sie den Haken für ''Bei Bedarf starten'' setzen, versucht expecco beim Verbinden einen Appium-Server an der angegebenen Adresse zu starten, wenn dort noch keiner läuft. Dieser Server wird dann beim Beenden der Verbindung ebenfalls heruntergefahren. Dies funktioniert nur für lokale Adressen. Achten Sie darauf, nur Portnummern zu verwenden, die auch frei sind. Verwenden Sie am besten nur ungerade Portnummern ab dem Standardport 4723. Beim Verbindungsaufbau wird ebenfalls die folgende Portnummer verwendet, wodurch es sonst zu Konflikten kommen könnte.<br />
<br />
Je nachdem, wie Sie den Dialog geöffnet haben, gibt es nun verschiedene Schaltflächen um ihn abzuschließen. In jedem Fall haben Sie die Option zu speichern. Dabei öffnet sich ein Dialog, indem Sie entweder ein geöffnet Projekt auswählen können, um die Einstellungen dort als Anhang zu speichern, oder auswählen es in einer Datei zu speichern, die Sie anschließend angeben können. Durch das Speichern wird der Dialog nicht beendet, wodurch Sie anschließend noch eine andere Option auswählen könnten.<br />
<br />
Wenn Sie den Editor zum Verbindungsaufbau geöffnet haben, können Sie abschließend auf ''Verbinden'' oder ''Server starten und verbinden'' klicken, je nachdem, ob der Haken für den Serverstart gesetzt ist. Für das Ändern oder Kopieren einer Verbindung im GUI-Brower heißt diese Option ''Übernehmen'', da in diesem Fall nur der Verbindungseintrag geändert bzw. neu angelegt wird, der Verbindungsaufbau aber nicht gestartet wird. Das können Sie bei Bedarf anschließend über das Kontextmenü tun. Falls Sie Capabilities einer bestehenden Verbindung geändert haben, fordert Sie anschließend ein Dialog auf zu entscheiden, ob diese Änderungen direkt übernommen werden sollen, indem die Verbindung abgebaut und mit den neuen Verbindungen aufgebaut wird, oder nicht. In diesem Fall werden die Änderungen erst wirksam, nachdem Sie die Verbindung neu aufbauen.<br />
<br />
Zur Verwendung des Verbindungseditors lesen Sie auch den entsprechenden Abschnitt im jeweiligen Tutorial in Schritt 1 (Android: [[#Schritt_1:_Demo_ausf.C3.BChren|Demo ausführen]], iOS: [[#Schritt_1:_Demo_ausf.C3.BChren_2|Demo ausführen]]).<br />
<br />
===Erweiterte Ansicht===<br />
Die erweiterte Ansicht des Verbindungseditors erhalten Sie entweder durch Klicken auf ''Bearbeiten'' im dritten Schritt oder jederzeit über den entsprechenden Menüeintrag, wenn Sie den Editor über das Plugin-Menü gestartet haben. In dieser Ansicht erhalten Sie eine Liste aller eingestellten Appium-Capabilities. Zu dieser können Sie weitere hinzufügen, Einträge ändern oder entfernen. Um eine Capability hinzuzufügen, wählen Sie diese aus der Drop-down-Liste des Eingabefelds aus. In dieser befinden sich alle bekannten Capabilities sortiert in die Kategorien ''Common'', ''Android'' und ''iOS''. Haben Sie eine Capability ausgewählt, wird ein kurzer Informationstext dazu angezeigt. Sie können in das Feld auch von Hand eine Capability eingeben. Klicken Sie dann auf ''Hinzufügen'', um die Capabilitiy in die Liste einzutragen. Dort können Sie in der rechten Spalte den Wert setzen. Um einen Entrag zu löschen, wählen Sie diesen aus und klicken Sie auf ''Entfernen''. Mit ''Zurück'' verlassen Sie die erweiterte Ansicht.<br />
<br />
[[Datei:MobileTestingErweiterteAnsicht.png]]<br />
<br />
== Laufende Appium-Server ==<br />
Im Menü des Mobile Testing Plugins finden Sie den Eintrag ''Appium-Server...''. Mit diesem öffnen Sie ein Fenster mit einer Übersicht aller Appium-Server, die von expecco gestartet wurden und auf welchem Port diese laufen. Durch Klicken auf das Icon in der Spalte ''Log anzeigen'' können Sie das Logfile des entsprechenden Servers anschauen. Dieses wird beim Beenden des Servers wieder gelöscht. Mit den icons in der Spalte ''Beenden'' kann der entsprechenden Server beendet werden. Allerdings wird dies verhindert, wenn expecco über diesen Server noch eine offene Verbindung hat.<br />
<br />
Außerdem können Sie hier auch Server starten. Verwenden Sie die Eingabefelder zur Konfiguration der Serveradresse. Sie können die Felder auch frei lassen, um die Standardwerte zu verwenden. Bitte beachten Sie, dass Server nur lokal gestartet werden können und der gewählte Port nicht belegt sein darf. Typischerweise werden die ungeraden Portnummern ab 4723 verwendet. Die folgende Portnummer wird beim Verbinden mit einem Gerät ebenfalls benötigt, wodurch es mit den geraden Nummern zu Konflikten kommen könnte.<br />
<br />
[[Datei:MobileTestingAppiumServer.png]]<br />
<br />
Im Menü des Mobile Testing Plugins finden Sie auch den Eintrag ''Alle Verbindungen und Server beenden''. Dies ist für den Fall gedacht, dass Verbindungen oder Server auf andere Weise nicht beendet werden können. Beenden Sie Verbindungen wenn möglich immer im GUI-Browser oder durch Ausführen eines entsprechenden Bausteins. Server, die Sie in der Server-Übersicht gestartet haben, beenden Sie dort; Server, die mit einer Verbindung gestartet wurden, werden automatisch mit dieser beendet.<br />
<br />
Beachten Sie, dass in der Übersicht nur Server aufgelistet sind, die von expecco gestartet und verwaltet werden. Mögliche andere Appium-Server, die auf andere Art gestartet wurden, werden nicht erkannt.<br />
<br />
== Recorder ==<br />
Besteht im GUI-Browser eine Verbindung zu einem Gerät, kann der integrierte Recorder verwendet werden, um mit diesem Gerät einen Testabschnitt aufzunehmen. Sie starten den Recorder, indem Sie im GUI-Browser die entsprechende Verbindung auswählen und dann auf den Aufnahme-Knopf klicken. Für den Recorder öffnet sich ein neues Fenster. Die aufgezeichneten Aktionen werden im Arbeitsbereich des GUI-Browsers angelegt. Daher ist es möglich, das Aufgenommene parallel zu editieren.<br />
<br />
[[Datei:MobileTestingRecorder.png|caption|]]<br />
<br />
;Komponenten des Recorderfensters<br />
#'''Aktualisieren''': Holt das aktuelle Bild und den aktuellen Elementbaum vom Gerät. Dies wird nötig, wenn das Gerät zur Ausführung einer Aktion länger braucht oder sich etwas ohne das Anstoßen durch den Recorder ändert.<br />
#'''Follow-Mouse''': Das Element unter dem Mauszeiger wird im GUI-Browser ausgewählt.<br />
#'''Element-Highlighting''': Das Elements unter dem Mauszeiger wird rot umrandet.<br />
#'''Elemente einzeichnen''': Die Rahmen aller Elemente der Ansicht werden angezeigt.<br />
#'''Werkzeuge''': Auswahl, mit welchem Werkzeug aufgenommen werden soll. Die gewählte Aktion wird bei einem Klick auf die Anzeige ausgelöst. Dabei stehen folgende Aktionen zur Verfügung:<br />
#*Aktionen auf Elemente:<br />
#**Klicken: Kurzer Klick auf das Element über dem der Cursor steht. Zur genaueren Bestimmung, welches Element verwendet wird, benutzen Sie die Funktion Follow-Mouse oder Highlight-Selected.<br />
#**Element antippen: Ähnlich zum Klicken, nur dass zusätzlich die Dauer des Klicks aufgezeichnet wird. Dadurch sind auch längere Klicks möglich.<br />
#**Text setzen: Ermöglicht das Setzen eines Textes in Eingabefelder.<br />
#**Text löschen: Löscht den Text eines Eingabefelds.<br />
#*Aktionen auf das Gerät:<br />
#**Antippen: Löst einen Klick auf die Bildschirmposition aus, bei dem auch die Dauer berücksichtigt wird.<br />
#**Wischen: Wischen in einer geraden Linie vom Punkt des Drückens des Mausknopfes bis zum Loslassen. Die Dauer wird ebenfalls aufgezeichnet.<br />
#:Beachten Sie bei diesen Aktionen, dass das Ergebnis sich auf verschiedenen Geräten unterscheiden kann, bspw. bei verschiedenen Bildschirmauflösungen.<br />
#*Erstellen von Testablauf-Bausteinen<br />
#**Attribut prüfen: Vergleicht den Wert eines festgelegten Attributs des Elements mit einem vorgegebenen Wert. Das Ergebnis triggert den entsprechenden Ausgang.<br />
#**Attribut zusichern: Vergleicht den Wert eines festgelegten Attributs des Elements mit einem vorgegebenen Wert. Bei Ungleichheit schlägt der Test fehl.<br />
#*Auto<br />
#:Ist das Auto-Werkzeug ausgewählt, können alle Aktionen durch spezifische Eingabeweise benutzt werden: ''Klicken'', ''Element antippen'' und ''Wischen'' funktionieren weiterhin durch Klicken, wobei sie anhand der Dauer und der Bewegung des Cursors unterschieden werden. Um ein ''Antippen'' auszulösen, halten Sie beim Klicken Strg gedrückt. Die übrigen Aktionen erhalten Sie durch einen Rechtsklick auf das Element in einem Kontextmenü.<br />
#'''Softkeys''': Nur unter Android. Simuliert das Drücken der Knöpfe Zurück, Home, Fensterliste und Power.<br />
#'''Home-Button''': Nur unter iOS ab expecco 2.11. Ermöglicht das Drücken des Home-Buttons. Funktioniert nur, wenn AssistiveTouch aktiviert ist und sich das Menü in der Mitte des oberen Bildschirmrands befindet.<br />
#'''Anzeige''': Zeigt einen Screenshot des Geräts. Aktionen werden mit der Maus je nach Werkzeug ausgelöst. Wenn eine neue Aktion eingegeben werden kann, hat das Fenster einen grünen Rahmen, sonst ist er rot.<br />
#'''Fenster an Bild anpassen''': Ändert die Größe des Fensters so, dass der Screenshot vollständig angezeigt werden kann.<br />
#'''Bild an Fenster anpassen''': Skaliert den Screenshot auf eine Größe, mit der er die volle Größe des Fensters ausnutzt.<br />
#'''Ausrichtung anpassen''': Korrigiert das Bild, falls dieses auf dem Kopf stehen sollte. Über den Pfeil rechts daneben kann das Bild auch um 90° gedreht werden, falls dies einmal nötig sein sollte. Die Ausrichtung des Bildes ist für die Funktion des Recorders unerheblich, dieser arbeitet ausschließlich auf den erhaltenen Elementen.<br />
#'''Skalierung''': Ändert die Skalierung des Screenshots. Kann auch über den Schieberegler rechts daneben angepasst werden.<br />
#'''Kontrollleuchte''': Zeigt den Zustand des Recorders an<br />
#:''grün'': Der Recorder ist bereit<br />
#:''rot'': Der Recorder ist blockiert, weil die Anzeige und die Elementliste aktualisiert werden<br />
#:''grau'': Der Recorder kann nicht mehr verwendet werden, da die Verbindung zum Gerät verloren gegangen ist<br />
<br />
;Verwendung<br />
Mit jedem Klick im Fenster wird eine Aktion ausgelöst und im Arbeitsbereich des GUI-Browsers aufgezeichnet. Dort können Sie das Aufgenommene abspielen, editieren oder daraus einen neuen Baustein erstellen. Zur Verwendung des Recorders lesen Sie auch Schritt 2 im Tutorial ([[#Schritt_2:_Einen_Baustein_mit_dem_Recorder_erstellen|Android]] bzw. [[#Schritt_2:_Einen_Baustein_mit_dem_Recorder_erstellen_2|iOS]]).<br />
<br />
== AVD Manager und SDK Manager ==<br />
AVD Manager und SDK Manager sind beides Anwendungen von Android. Im Menü des Mobile Testing Plugins bietet expecco die Möglichkeit, diese zu starten. Ansonsten finden Sie diese Programme bei Ihrer Android-Installation. Mit dem AVD Manager können Sie AVDs, also Konfigurationen für Emulatoren, erstellen, bearbeiten und starten. Mit dem SDK Manager erhalten Sie einen Überblick über Ihre Android-Installation und können diese bei Bedarf erweitern.<br />
<br />
= XPath anpassen mithilfe des GUI-Browsers =<br />
Bausteine, die auf einem Gerät fehlerfrei funktionieren, tun dies auf anderen Geräten möglicherweise nicht. Auch können kleine Änderungen der App dazu führen, dass ein Baustein nicht mehr den gewünschten Effekt hat. Man sollte einen Baustein daher so robust formulieren, dass er für eine Vielzahl von Geräten verwendet werden kann und kleine Anpassungen an der App verkraftet. Dazu muss man das grundlegende Funktionsprinzip der Adressierung verstehen. Dies wird im Folgenden am Beispiel der App aus dem Tutorial erläutert.<br />
<br />
Die Ansicht der App setzt sich aus einzelnen Elementen zusammen. Dazu gehören die Schaltflächen ''GTIN-13 (EAN-13)'' und ''Verify'', das Eingabefeld der Zahl ''4006381333986'' und das Ergebnisfeld, in dem OK erscheint, wie auch alle anderen auf der Anzeige sichtbaren Dinge. Diese sichtbaren Elemente sind in unsichtbare Strukturelemente eingebettet. Alle Elemente zusammen sind in einer zusammenhängenden Hierarchie, dem Elementbaum, organisiert.<br />
<br />
[[Datei:MobileTestingGUIBrowser.png | frame | left | Abb. 1: Funktionen des GUI-Browsers]]<br />
<br clear="all"><br />
Sie können sich diesen Baum im GUI-Browser ansehen. Wechseln Sie dazu in den GUI-Browser (Abb. 1) und starten Sie eine beliebige Verbindung. Sobald die Verbindung aufgebaut ist, können Sie den gesamten Baum aufklappen (1) (Klick bei gedrückter Strg-Taste). Er enthält alle Elemente der aktuellen Seite der App.<br />
<br />
Ein Baustein, der nun ein bestimmtes Element verwendet, muss dieses eindeutig angeben, indem er dessen Position im Elementbaum mit einem Pfad im XPath-Format beschreibt. Dieses Format ist ein verbreiteter Web-Standard für XML-Dokumente und -Datenbanken, eignet sich aber genauso für Pfade im Elementbaum.<br />
<br />
Wenn Sie ein Element im Baum auswählen, wird unten der von expecco automatisch generierte XPath (2) für das Element angezeigt, der auch beim Aufzeichnen verwendet wird. Oberhalb davon in der Mitte des Fensters befindet sich eine Liste der Eigenschaften (3) des ausgewählten Elements. Man nennt diese Eigenschaften auch Attribute. Sie beschreiben das Element näher wie beispielsweise seinen Typ, seinen Text oder andere Informationen zu seinem Zustand. Links unten können Sie zur besseren Orientierung im Baum die ''Vorschau'' (4) aktivieren, um sich den Bildausschnitt des Elements anzeigen zu lassen.<br />
<br />
Der Elementbaum für gleiche Ansicht einer App kann sich je nach Gerät unterscheiden. Es sind diese Unterschiede, die verhindern, eine Aufnahme von einem Gerät unverändert auch auf allen anderen Geräten abzuspielen: Ein XPath, der im einen Elementbaum ein bestimmtes Element identifiziert, beschreibt nicht unbedingt das gleiche Element im Elementbaum auf einem anderen Gerät. Es kann stattdessen passieren, dass der XPath auf kein Element, auf ein falsches Element oder auf mehrere Elemente passt. Dann schlägt der Test fehl oder er verhält sich unerwartet.<br />
<br />
Man könnte natürlich für jedes Gerät einen eigenen Testfall schreiben. Das brächte aber unverhältnismäßigen Aufwand bei Testerstellung und -wartung mit sich. Das Problem lässt sich auch anders lösen, da ein jeweiliges Element nicht nur durch genau einen XPath beschrieben wird. Vielmehr erlaubt der Standard mithilfe verschiedener Merkmale unterschiedliche Beschreibungen für ein und dasselbe Element zu formulieren. Das Ziel ist daher, einen Pfad zu finden, der auf allen für den Test verwendeten Geräten funktioniert und überall eindeutig zum richtigen Element führt.<br />
<br />
Im Beispiel besteht die Verbindung zur Android-App aus dem Tutorial und der Eintrag des GTIN-13-Buttons ist ausgewählt (5). Dessen automatisch generierter XPath (2) kann beispielsweise so aussehen:<br />
<br />
<blockquote>//hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.view.ViewGroup/android.widget.FrameLayout[@resource id='android:id/content']/android.widget.RelativeLayout/android.widget.Button[@resource-id='de.exept.expeccomobiledemo:id/gtin_13']</blockquote><br />
<br />
Er ist offensichtlich lang und unübersichtlich. Der sehr viel kürzere Pfad<br />
<br />
<blockquote>//*[@text='GTIN-13 (EAN-13)']</blockquote><br />
<br />
führt zum selben Element.<br />
<br />
Für die iOS-App lautet der automatisch generierte XPath für diesen Button beispielsweise<br />
<br />
<blockquote>//AppiumAUT/XCUIElementTypeApplication/XCUIElementTypeWindow[1]/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeButton[2]</blockquote><br />
bzw.<br />
<blockquote>//AppiumAUT/UIAApplication/UIAWindow[1]/UIAButton[2]</blockquote><br />
<br />
und kann kürzer als<br />
<br />
<blockquote>//*[@name='GTIN-13 (EAN-13)']</blockquote><br />
<br />
geschrieben werden.<br />
<br />
Sie können den Pfad entsprechend im GUI-Browser ändern und durch ''Pfad überprüfen'' (6) feststellen, ob er weiterhin auf das ausgewählte Element zeigt, was expecco mit ''Verify Path: OK'' (7) bestätigen sollte. Der erste, sehr viel längere Pfad, beschreibt den gesamten Weg vom obersten Element des Baumes bis hin zum gesuchten Button. Der zweite Pfad hingegen wählt mit * zunächst sämtliche Elemente des Baumes und schränkt die Auswahl dann auf genau die Elemente ein, die ein ''text''- bzw. ''name''-Attribut mit dem Wert ''GTIN-13 (EAN-13)'' besitzen, in unserem Fall also genau der eine Button, den wir suchen.<br />
<br />
Im folgenden werden Android-ähnliche Pfade zur Veranschaulichung verwendet. Die Elemente in iOS-Apps heißen zwar anders, wodurch andere Pfade entstehen; das Prinzip ist jedoch das gleiche.<br />
<br />
[[Datei:MobileTestingBaum1.png | frame | Abb. 2: Elementbaum einer fiktiven App]]<br />
<br />
Sie können solche Pfade mit Hilfe weniger Regeln selbst formulieren. Sehen Sie sich den einfachen Baum einer fiktiven Android-App in Abb. 2 an: Die Einrückungen innerhalb des Baumes geben die Hierarchie der Elemente wieder. Ein Element ist ein ''Kind'' eines anderen Elementes, wenn jenes andere Element das nächsthöhere Element mit einem um eins geringeren Einzug ist. Jenes Element ist das ''Elternelement'' des Kindes. Sind mehrere untereinander stehende Elemente gleich eingerückt, so sind sie also alle Kinder desselben Elternelements.<br />
<br />
Ein Pfad durch alle Ebenen der Hierarchie zum TextView-Element ist nun:<br />
<br />
<blockquote>//hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.TextView</blockquote><br />
<br />
Die Elemente sind mit Schrägstrichen voneinander getrennt. Es fällt auf, dass der Name des ersten Elements nicht mit dem im Baum übereinstimmt. Das oberste Element in der Hierarchie heißt immer ''hierarchy'' (für iOS wäre es ''AppiumAUT''), expecco zeigt im Baum stattdessen den Namen der Verbindung an, damit man mehrere Verbindungen voneinander unterscheiden kann. Die weiteren Elemente tragen jeweils das Präfix ''android.widget.'', das im Baum zur besseren Übersicht nicht angezeigt wird. Bei IOS gibt es kein Präfix, das durch einen Punkt abgetrennt wäre, expecco 2.11 blendet aber entsprechend ''XCUIElementType'' am Anfang aus. Mit jedem Schrägstrich führt der Pfad über eine Eltern-Kind-Beziehung in eine tiefere Hierarchie-Ebene, d. h. ''FrameLayout'' ist ein Kindelement von ''hierarchy'', ''LinearLayout'' ist ein Kind von ''FrameLayout'' usw. Die in eckigen Klammern geschriebenen Wörter dienen nur als Orientierungshilfe im Baum. Sie gehören nicht zum Typ.<br />
<br />
Ein Pfad muss nicht beim Element ''hierarchy'' beginnen. Man kann den Pfad beginnend mit einem beliebigen Element des Baumes bilden. Man kann also verkürzt auch<br />
<br />
<blockquote>//android.widget.TextView</blockquote><br />
<br />
schreiben. Der Pfad führt zum selben ''TextView''-Element, da es nur ein Element dieses Typs gibt. Anders verhält es sich bei dem Pfad<br />
<br />
<blockquote>//android.widget.Button.</blockquote><br />
<br />
Da es zwei Elemente vom Typ ''Button'' gibt, passt dieser Pfad auf zwei Elemente, nämlich den Button, der mit "''An''" markiert ist, und den ''Button'', der mit "''Aus''" markiert ist. Es würde an dieser Stelle aber auch nicht helfen den langen Pfad von ''hierarchy'' aus beginnend anzugeben. Um einen mehrdeutigen Pfad weiter zu differenzieren, kann man explizit ein Element aus einer Menge wählen, indem man den numerischen Index in eckigen Klammern dahinter schreibt. Der Pfad aus dem obigen Beispiel lässt sich damit so anpassen, dass er eindeutig auf den ''Button'' mit der Markierung "''Aus''" weist:<br />
<br />
<blockquote>//android.widget.Button[1].</blockquote><br />
<br />
Ihnen fällt sicher auf, dass der Index eine 1 ist obwohl das zweite Element gemeint ist. Das kommt daher, dass die Zählung bei 0 beginnt. Der Button mit der Markierung "An" hat also die Nummer 0 und der ''Button'' mit der Markierung "''Aus''" hat die Nummer 1.<br />
<br />
Dieser Ansatz, einen expliziten Index zu verwenden, hat zwei Nachteile: Zum einen lässt sich an dem Pfad nur schwer ablesen welches Element gemeint ist, zum andern ist der Pfad sehr empfindlich schon gegenüber kleinsten Änderungen, wie zum Beispiel dem Vertauschen der beiden ''Button''-Elemente oder dem Einfügen eines weiteren ''Button''-Elements in der App.<br />
<br />
Es wäre daher wünschenswert, das gemeinte Element über eine ihm charakteristische Eigenschaft wie einen Attributwert, zu adressieren. Für Android-Apps eignet sich hierfür häufig das Attribut ''resource-id''. Im Idealfall muss bei der Entwicklung der App darauf geachtet werden, dass jedes Element eine eindeutige Id erhält. Die ''resource-id'' hat den großen Vorteil, dass sie unabhängig vom Text des Elements oder der Spracheinstellung des Geräts ist. Für iOS-Apps kann entsprechend das Attribut ''name'' verwendet werden, wenn es von der App sinnvoll gesetzt wird. Der XPath-Standard erlaubt solche Auswahlbedingungen zu einem Element anzugeben. Angenommen, der ''Button'' mit der Markierung "''Aus''" hat die Eigenschaft ''resource-id'' mit dem Wert ''off'' und der ''Button'' mit der Markierung "''An''" hat als ''resource-id'' den Wert ''on'', dann kann man als eindeutigen Pfad für den "Aus"-''Button''<br />
<br />
<blockquote>//android.widget.Button[@resource-id='off']</blockquote><br />
<br />
formulieren. Wie an dem Beispiel zu sehen werden solche Bedingungen wie ein Index in eckigen Klammern an den Elementtyp angehängt. Der Name eines Attributes wird mit einem @ eingeleitet und der Wert mit einem = in Anführungszeichen angehängt. Ist der Attributwert global eindeutig, kann man den vorausgehenden Pfad sogar durch den globalen Platzhalter * ersetzen, der auf jedes Element passt. Das obige Beispiel mit dem GTIN-13-''Button'' war ein solcher Fall.<br />
<br />
[[Datei:MobileTestingBaum2.png | frame | Abb. 3: Elementbaum einer fiktiven App mit Erweiterungen]]<br />
<br />
Abb. 3 zeigt eine Erweiterung des Beispiels aus Abb. 2. Die App hat nun ein weiteres, nahezu identisches ''LinearLayout'' bekommen. Die ''Buttons'' sind in ihren Attributen jeweils ununterscheidbar. Deshalb funktioniert der vorige Ansatz nicht, einen eindeutigen Pfad nur mithilfe eines Attributwerts zu formulieren. Offensichtlich unterscheiden sich aber ihre benachbarten ''TextViews''. Es ist möglich die jeweilige ''TextView'' in den Pfad mit aufzunehmen, um einen ''Button'' dennoch eindeutig zu adressieren. Ein Pfad zum ''Button'' mit der Markierung "''An''" unterhalb der ''TextView'' mit der Markierung "''Druckschalter''" kann dabei wie folgt aussehen:<br />
<br />
<blockquote>//android.widget.TextView[@resource-id='push']/../android.widget.Button[@resource-id='on']</blockquote><br />
<br />
Der erste Teil beschreibt den Pfad zu der ''TextView'' mit der Markierung "''Druckschalter''" und der ''resource-id'' mit dem Wert ''push''. Danach folgt ein Schrägstrich gefolgt von zwei Punkten. Die zwei Punkte sind eine spezielle Elementbezeichnung, die nicht ein Kindelement benennt, sondern zum Elternelement wechselt, in diesem Fall also das ''LinearLayout'', in dem die ''TextView'' eingebettet ist. Im Kontext dieses ''LinearLayout'' ist der restliche Pfad, nämlich der ''Button'' mit der ''resource-id'' mit dem Wert ''on'', eindeutig.<br />
<br />
Der XPath-Standard bietet noch sehr viel mehr Ausdrucksmittel. Mit der hier knapp vorgestellten Auswahl ist es aber bereits möglich für die meisten praktischen Testfälle gute Pfade zu formulieren. Eine vollständige Einführung in XPath ginge über den Umfang dieser Einführung weit hinaus. Sie finden zahlreiche weiterführende Dokumentationen im Web und in Büchern.<br />
<br />
Eine universelle Strategie zum Erstellen guter XPaths gibt es nicht, da sie von den Testanforderungen abhängt. In der Regel ist es sinnvoll, den XPath kurz und dennoch eindeutig zu halten. Häufig lassen sich Elemente über Eigenschaften identifizieren wie beispielsweise ihren Text. Will man aber gerade den Text eines Elements auslesen, kann dieser natürlich nicht im Pfad verwendet werden, da er vorher nicht bekannt ist. Ebenso wird der Text variieren, wenn die App mit verschiedenen Sprachen gestartet wird.<br />
<br />
Jeder Baustein, der auf einem Element arbeitet, hat einen Eingangspin für den XPath. Im GUI-Browser finden Sie in der Mitte oben eine Liste von Bausteinen mit Aktionen, die Sie auf das ausgewählte Element anwenden können. Suchen Sie den Baustein ''Click'' (8) im Ordner Elements und wählen Sie ihn aus (Abb. 1). Er wird im rechten Teil unter ''Test'' eingefügt, der Pin für den XPath ist mit dem automatisch generierten Pfad des Elements vorbelegt (9). Sie können den Baustein hier auch ausführen. Die Ansicht wechselt dann auf ''Lauf''. Ändert sich durch die Aktion der Zustand Ihrer App, müssen Sie den Baum anschließend aktualisieren (10).<br />
<br />
Wenn Sie in der unteren Liste eine Eigenschaft auswählen, wechselt die Anzeige der Bausteine zu ''Eigenschaften'', wo Sie die eigenschaftsbezogenen Bausteine finden. Wie bei den Aktionen können Sie auch hier einen Baustein auswählen, der dann rechts in Test mit dem Pfad des Elements und der ausgewählten Eigenschaft eingetragen wird, sodass Sie ihn direkt ausführen können.<br />
<br />
=<span id="troubleshooting"><!-- Referenced by error dialog on connection error --></span>Probleme und Lösungen=<br />
==Allgemeine Hinweise==<br />
*Wenn ein über USB angeschlossenes Android-Gerät nicht im Verbindungsdialog auftaucht, versuchen Sie, den USB-Verbindungstyp zu ändern. In der Regel sollten MTP oder PTP funktionieren. Siehe auch [[#Android-Ger.C3.A4t_vorbereiten|Android-Gerät vorbereiten]].<br />
*In manchen Fällen erscheint beim Verbinden eines iOS-Geräts über USB der Hinweis, das verwendete Kabel sei nicht zertifiziert. In diesem Fall hilft es nur, das entsprechende Kabel auszutauschen.<br />
*Beachten Sie, dass im [[#Recorder|Recorder]] auch Elemente berücksichtigt werden, die Sie auf dem Bildschirm nicht sehen. Schalten Sie daher das Element-Highlighting an oder nutzen Sie Follow-Mouse-Funktion und den Elementbaum im GUI-Browser, um festzustellen, ob das richtige Element verwendet wird.<br />
*Stellen Sie sicher, dass beim Verbindungsaufbau mit einem iOS-Gerät keine Alerts geöffnet sind. Der Aufbau schlägt sonst fehl, da die App nicht in den Vordergrund kommen kann. Siehe auch [[#iOS-Ger.C3.A4t_und_App_vorbereiten|iOS-Gerät und App vorbereiten]].<br />
*Um einen iOS-Simulator zu verwenden müssen Sie keine udid angeben. In Xcode erhalten Sie die Namen der verfügbaren Simulatoren. Starten Sie dazu Xcode und wählen Sie in der Menüleiste am oberen Bildschirmrand im Menü ''Window'' den Eintrag ''Devices''. Hier sind neben den angeschlossenen Geräten auch die verfügbaren Simulatoren aufgelistet. Beachten Sie dabei, dass auf Simulatoren keine ''.ipa''-Dateien sondern nur ''.app''-Dateien installiert werden können.<br />
<br />
==Verbindungsaufbau schlägt fehl==<br />
Schlägt der Verbindungsaufbau mit dem Appium-Server fehl, erhalten Sie in expecco folgende Fehlermeldung:<br />
<br />
[[Datei:MobileTestingVerbindungsfehler.png]]<br />
<br />
Hier sehen Sie die Art des aufgetretenen Fehlers. Klicken Sie auf ''Details'' um nähere Informationen zu erhalten. Mögliche Fehler sind:<br />
*''org.openqa.selenium.remote.UnreachableBrowserException''<br />
:Der angegebene Server läuft nicht oder ist nicht erreichbar. Überprüfen Sie die Serveradresse.<br />
*''org.openqa.selenium.WebDriverException''<br />
:Lesen Sie in den Details in der ersten Zeile die Meldung hinter ''Original Error'':<br />
:*''Unknown device or simulator UDID''<br />
::Entweder ist das Gerät nicht richtig angeschlossen oder die udid stimmt nicht.<br />
:*''Unable to launch WebDriverAgent because of xcodebuild failure: xcodebuild failed with code 65''<br />
::Dieser Fehler kann verschiedene Ursachen haben. Entweder konnte tatsächlich der WebDriverAgent nicht gebaut werden, weil die Signierungseinstellungen falsch sind oder das passende Provisioning Profile fehlt. Lesen Sie dazu den Abschnitt zur Verbereitung unter [[#expecco_2.11|Mac OS mit expecco 2.11]]. Es kann auch sein, dass der WebDriverAgent auf dem Gerät nicht gestartet werden kann, weil sich beispielsweise ein Alert im Vordergrund befindet oder Sie dem Entwickler nicht vertraut haben.<br />
:*''Could not install app: 'Command 'ios-deploy [...] exited with code 253'''<br />
::Die angegebene App kann nicht auf dem iOS-Gerät installiert werden, weil es nicht im Provisioning Profile der App eingetragen ist.<br />
:*''Bad app: [...] App paths need to be absolute, or relative to the appium server install dir, or a URL to compressed file, or a special app name.'''<br />
::Der Pfad zur App ist falsch. Stellen Sie sicher, dass sich die Datei unter dem angegebenen Pfad auf dem Mac befindet.<br />
:*''packageAndLaunchActivityFromManifest failed.''<br />
::Die angegebene ''apk''-Datei ist vermutlich kaputt.<br />
:*''Could not find app apk at [...]''<br />
::Der Pfad zur App ist falsch. Stellen Sie sicher, dass sich die ''apk''-Datei m angegebenen Pfad befindet.</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Release_Notes_2.x&diff=10577Release Notes 2.x2018-02-22T14:27:42Z<p>Mawalch: /* Release 18.1 [previously known as "2.12"] (Spring 2018) */</p>
<hr />
<div>see also: [[Release Notes 1.x]]<br />
<br />
== Release 18.1 [previously known as "2.12"] (Spring 2018) ==<br />
With this release, we will start a new naming scheme, <br />
using the publishing year as major version number and the delivery within the year as minor vsn. <br />
<br>Thus, this version will be named "18.1.x" in marketing material.<br />
<br />
<br />
* Fix: attachment handling when moving items across projects (into/out of imported projects)<br />
<br />
* Feature: logInconclusive and logError actions (similar to logFailure, these mark the test's outcome, but continue execution)<br />
* Feature: many GUIBrowser enhancements<br />
* Feature: Connect multiple (same-named) pins<br />
* Feature: FileBrowser: dump can be changed to be hex, octal, decimal or binary; character decoding in EBCDIC or 7-bit ASCII (to ignore high/parity bit)<br />
* Feature: FileBrowser: search pattern can be entered as hex byte sequence<br />
* Feature: [[Settings UpdatesSettings/en#Expecco_as_a_Patches_Server_.282.12.29|Patches server]]: one expecco may deliver patches to all other installations in the local network<br />
* Feature: can pass [[ElementaryBlock Element/en#Environment_.28Shell-.29_Variables|shell environment variables to shell, batch actions]] (and all derived actions, like Ruby, Node.js, etc.)<br />
* Feature: [[ElementaryBlock Element/en#Matching_stdin.2Fstderr_against_a_Pattern|prompt matching in shell, batch actions]] (and all derived actions, like Ruby, Node.js, etc.)<br />
* Feature: [[DiagramElements-Pin/en#Do_not_Log_Pin-Value_in_Activitylog_Attribute|individual control over pin-value in activity log]] (e.g. to suppress passwords, cryptokeys etc.)<br />
* Feature: [[DiagramElements-Pin/en#Output_Pin_Value_Timestamped_Attribute|output pin values can be individually timestamped]] (via step's pin menu)<br />
* Feature: [[ElementaryBlock Element/en#Node.js-Script_Blocks|Node.js script blocks]] and [[ElementaryBlock Element/en#Node.js_Blocks|Node.js elementary action blocks]]<br />
* Feature: [[VNC Plugin Reference/en|VNC GUI Testing plugin]]<br />
<!-- * Feature: Message/Document browser --><br />
* Feature: "''Interrupt & Debug''" button in the [[Test Editor/en|Test-Runner]] (to interrupt runaway elementary blocks)<br />
<br />
* Performance: Speed improvement in testplan execution<br />
<br />
* UI Enhancement: coloring by type is now on by default (if you don't like it, go to "Settings"-"Look&nbsp;&amp;&nbsp;Feel"-"Diagram&nbsp;Editor"-"Look-Elements" and turn it off again)<br />
* UI Enhancement: Limit the number of levels in follow activity<br />
* UI Enhancement: ActivityTree shows activities with handled exceptions in orange (used to be red). Also, the handling activity shows where the handled exception was thrown. Finally, the automatic navigation to the first error (after a run) will skip over handled exceptions, to place you immediately to the activity which was responsible for the failure or error.<br />
* UI Enhancement: recently modified and recently executed menus in main-menu<br />
* UI enhancement: "''Select Step in Diagram''" menu-function in the activity log tree viewer<br />
* UI enhancement: "''Exchange Connections''" menu-function in the network editor<br />
* UI enhancement: "''Import Attachments''" tools menu-function (to import many files)<br />
* UI enhancement: more information and functions in the Diff-viewer; new menu item in the "''Extra''"-menu: "''Compare two Testsuite Files''"<br />
* UI enhancement: "''Add/Remove Tag''" menu functions (in tree) can also be applied recursively to children of the selected item<br />
* UI enhancement: when a step is selected at the time a new step is created by the "''New Step''" function or by paste, the new step is automatically connected via trigger-out/trigger-in<br />
<br />
== Release 2.11.1 (Fall 2017) ==<br />
* Bugfix Release including all patches for Release 2.11<br />
* Fix: Windows Automation - Stability<br />
* Fix: Problems with OLE<br />
<br />
== Release 2.11 (Spring 2017) ==<br />
* Fix: JSON parameter save/reload fixed<br />
* Fix: method name check in codeView was disabled<br />
* Feature: "must be executed" attribute in action definition<br />
* Feature: Erweiterung des expecco GUI Automation Framework<br />
* Feature: Neue Anbindungen an Technologien im Bereich Automotive und Maschinenbau<br />
* Feature: Rechnergebundene Einzelplatz Lizenz<br />
<br />
* Packaging: Neues expecco Bundle: expecco Testcenter - Testautomatisierung mit integriertem Test- und Ressourcenmanagement<br />
<br />
<br />
== Release 2.10.1 (= 2.10 + Patches) ==<br />
* Fix: keyboard focus for menu<br />
* Backward Compatibility Fix: the fixes in the JavaScript "indexOf()"-functions (done in 2.8) lead to problems with a customer (which migrated from 2.7.5 to 2.10). For this, two flags have been added to the suite-attributes, which enforce the old behavior for individual and/or all imported libraries. This allows for old code (which expects the wrong 1-based indexOf return values) to coexist with new code (which expects the correct 0-based versions) within a single test suite.<br />
<br />
* Feature: [[Settings UpdatesSettings/en|Patches can be loaded via HTTP]] (FTP was blocked in some customers' networks)<br />
* Performance: Bulk data transfers to network drives under Windows.<br />
<br />
== Release 2.10 (Fall 2016) ==<br />
* Feature: Mobile Testing Plugin (renamed from "''Appium Plugin''") got more support functions to administer appium & adb connections<br />
* Feature: new "Reimport Tool" for bulk reimport and library (dependency) checking<br />
* Feature: DLL-mapping dialog in the settings. For a typical usage example, see [[AutoIt Library#Installation|Installation of AutoIt]]<br />
* Feature: New blocks in the stdlib ("''Split by Size''" and "''Split by Element''"), to split collections (strings) into sized pieces or at a separator.<br />
* Feature: New command line options to specify individual parameter values<br />
* Feature: More formats supported for external parameter files (JSON)<br />
* Feature: new [[Starting expecco via Command Line/en#Detailed_Option_Description|command line]] arguments: -E, -P:, --parameter:, --silent, --licenseServerHost, --licenseServerPort<br />
* Feature: the new [[Java Interface Library v2|Java Bridge V2]]/DotNET Bridge V2 is now used by the default. The new bridge uses only a single port for communication (thus making firewall/router setup easier), supports casts, better controllable argument-type specification, is faster in its communication and supports asynchronous messages with lazy results. In case of backward compatibility problems, the old bridge is still available and can be used by changing the settings.<br />
* Feature: custom print length of the pin and log values for the report<br />
* Feature: [[CompoundBlock Editor-CompoundWorksheet Editor/en#Controlling_Logging_and_Tracing|"''Ignore All Skip in Trace''"]] settings to enforce a full trace (for debugging)<br />
<br />
* Performance: (dramatic) speedup in some image handling functions.<br />
* Performance: speedup (50%) in the XML reader.<br />
* Performance: speedup initial startup by not loading unlicensed plugins<br />
<br />
* UI enhancement: GUI Browser: double click on action/attribute item adds it to the list<br />
* UI enhancement: GUI Browser: reconnect/fix autostart when deleting recorded steps<br />
* UI enhancement: GUI Browser: better undo handling<br />
* UI enhancement: GUI Browser: keep tree and selection on refresh (not all technologies)<br />
* UI enhancement: better replace-step dialog in diagram editor (library filter added)<br />
* UI enhancement: Line numbers in the attachment editor<br />
* UI enhancement: Line numbers and trim-blank-lines option in multiline freeze value entry<br />
* UI enhancement: color settings for red-green deficiency (in status color dialog)<br />
<br />
* Change: SerialPort Plugin: the port parameter pins (baudrate, stop-bits, parity etc.) are now parameter pins. This will only affect you, if the open-serial-port block is triggered via one of those pins (which is very very unlikely)<br />
<br />
* Fix: All leftover (unclosed) external connections (Sockets, Serial Lines, Bridges) are closed after a testrun, when in slave mode<br />
* Fix: All leftover (unterminated) started appium servers are closed after a testrun, when in slave mode<br />
* Fix: Multiline freeze value editor interpreted strings starting with digits as numeric value<br />
* Fix: Multiline freeze value editor allows for empty lines at the end<br />
<br />
<br />
== Release 2.9 (June/2016) ==<br />
* Feature: Mobile Testing (aka "Appium")-Plugin: Add recorder<br />
* Feature: Mobile Testing Plugin: Update capabilities<br />
* Feature: Mobile Testing Plugin: Settings Dialog for setting up external auxiliary programs (adb, Appium Server, AVD Manager, SDK Manager)<br />
* Feature: Mobile Testing Plugin: New menu for launching auxiliary programs (Appium Server, AVD Manager, SDK Manager)<br />
* Feature: Mobile Testing Plugin: New buttons in Android Wizard to refresh the device list, launch AVD Manager, install APKs.<br />
* Feature: Mobile Testing Plugin: Save and load connection settings in and from attachments in test suite.<br />
* Feature: Mobile Testing Plugin: Allow editing and copying of connection settings.<br />
* Feature: Mobile Testing Plugin: Allow adding arbitrary capabilities for forward compatibility.<br />
* Feature: Mobile Testing Plugin Bundle: Update contents, in particular use Appium Server 1.4.16.<br />
* Feature: Mobile Testing Plugin Bundle: Remove Android emulator from bundle as it is huge. If needed, download and install it separately.<br />
* Feature: [[Java Interface Library v2|New Java Bridge (still experimental in 2.9)]]. The old Java Bridge is still available and enabled by default.<br />
<br />
* UI enhancement: Mobile Testing Plugin: More verbose warning dialogs.<br />
* UI enhancement: Mobile Testing Plugin: Remove obsolete "Emulator Settings" from connection dialog (using the wizard is superior now).<br />
* UI enhancement: Mobile Testing Plugin: Make newCommandTimeout capability user visible<br />
* UI enhancement: Mobile Testing Plugin: Remove unimportantView from default capabilities<br />
* UI enhancement: Mobile Testing Plugin: Automatically select entry in Android Wizard if only one is available.<br />
* UI enhancement: Mobile Testing Plugin: Highlight unknown capabilities to give a hint in case of bad spelling.<br />
* UI enhancement: Mobile Testing Plugin: Add a search filter for packages in the Android Wizard.<br />
* UI enhancement: General/Linux: Support for Anti-Aliased XFT-Fonts.<br />
<br />
* STD-LIB: Image Save block supports writing of JPEG images.<br />
* Mobile Testing Library: New blocks for multi-touch actions<br />
* Mobile Testing Library: New block for reading capabilities from files<br />
* Mobile Testing Library: New blocks for reading logs<br />
* Mobile Testing Library: New block "Find Elements by XPath" for finding sets of elements<br />
* Mobile Testing Library: New blocks for consecutive actions on single elements<br />
* Mobile Testing Library: New block for taking screenshots<br />
* Mobile Testing Library: New blocks for pressKeyCode API, make old blocks (sendKeyEvent API) obsolete<br />
<br />
* Localization: Mobile Testing Plugin: German translation mostly complete.<br />
* Documentation: Update and add more documentation to Appium library.<br />
<br />
* Fix: Mobile Testing Plugin: Timeout in Android Wizard if adb does not return.<br />
* Fix: Mobile Testing Plugin: Do not cut off multi-line status messages in Android Wizard.<br />
* Fix: Mobile Testing Plugin: Fix error and bad behavior when cancelling file dialog in connection settings.<br />
* Fix: Mobile Testing Plugin: Do not drop connection settings on connection error.<br />
* Fix: Mobile Testing Plugin: Use Java path from Settings<br />
* Fix: XML/XPath - accepts underscore ('_') and Unicode characters in element and attribute names.<br />
* Fix: RemoteAccess Plugin - fix error waiting for prompt<br />
* Fix: RemoteAccess Plugin - fix response in same line as command<br />
* Fix: Java GUI Plugin - fix error in "Verify Path"<br />
<br />
<br />
== Release 2.8 (Q4/2015) ==<br />
'''Notice: You have to install a patch for expecco 2.7.5, if you want to load a Testsuite which was edited in expecco 2.8 and uses some of the new features! [[release2.8 incompatibilities|(More info)]]'''<br />
<br />
* Feature: [[TableDrivenBlock Element|Table driven actions]]; these offer a simpler, table oriented interface<br />
* Feature: Mobile Testing-Plugin (was "Appium"-Plugin) for Android and Apple iOS test automation for mobile devices<br />
* Feature: Variable number of pins in groups ([[DiagramElements-Pin/en#Variable_Number_of_Pins|"Variable Pin Groups"]])<br />
* Feature: First release of the [[User Defined Menu Items#Useful_Building_Blocks_for_Custom_Menu_Operations|Expecco Reflection Library]] (to automate expecco itself)<br />
* Feature: Enum datatype: support for individual assigned enum values, described in the [[Datatype Editor/en#Enumeration_Types|Datatype Editor Documentation]] and the [[Datatype Element/en#Enumeration_Types|Datatype Element Documentation]] and also the [[Expecco API/en#Enum Type Functions|API Documentation]].<br />
* Feature: [[Starting expecco via Command Line#Expecco_REST_Service_Interface|REST service]] for remote controlling expecco execution<br />
* Feature: New [[ElementaryBlock Element/en#Ruby_Script_Blocks|Ruby actions]]<br />
* Feature: Better execution directory settings for [[ElementaryBlock Element/en#Shell_Script_Blocks|Shell blocks]]<br />
* Feature: New step attributes for more specific [[CompoundBlock Editor-CompoundWorksheet Editor/en#Step_Specific_Options_.28Context_Menu.29|"skip in log/trace"]] options (for looping actions)<br />
* Feature: New user preference setting to ignore all [[CompoundBlock Editor-CompoundWorksheet Editor/en#Step_Specific_Options_.28Context_Menu.29|skip-in-log]] attributes (for debugging)<br />
* Feature: "immediate fork new process" flag now also in block description or dynamically from elementary code<br />
* Feature: Improved performer data type handling; virtual steps now only accept valid performers, and freeze value choices are filtered for valid performers.<br />
* Feature: Option to start background action before or after pre-action<br />
* Feature: New constraint datatype type (for better freeze value selection)<br />
* Feature/Fix: compatibility of indexOf() / lastIndexOf() JavaScript functions (allow substring search)<br />
* Feature: Data inspector for strings shows another (XML-DOM) tab if the string is an XML string. This tab shows the parsed XML DOM-tree.<br />
* Feature: Attachments can now be declared as binary file attachment. These will not be interpreted; especially, no cr/lf translation and utf8 or similar character translation is performed. Binary attachments are required, e.g. to embed jar or other code files.<br />
<br />
* UI enhancement: Multiline labels in steps (use "\" as line-separator)<br />
* UI enhancement: Additional custom headline and custom text block in reports (can be filled in right before printing).<br />
* UI enhancement: Can now also set breakpoints on steps and code lines of readonly actions (e.g. in an imported library)<br />
* UI enhancement: Undo gives a warning when about to undo past the previous file-save state<br />
* UI enhancement: Added a menu item in "Extras" - "Debugging" to stop [[User Defined Menu Items#Asynchronous_.28Background.29_Actions|background menu actions]]<br />
* UI enhancement: Added more convenient pin-comment editing support to the schema editor<br />
* UI enhancement: Text editor has a new "split" menu function in its tools-submenu<br />
* UI enhancement: Better "New Step" and "Replace Step" dialogs in the diagram editor (showing preview, code and contents; also show attachments).<br />
* UI enhancement: Better autoconnect and matching blocks search algorithm in the "Place and Select New Step" function (i.e. New Step function, when an output pin is selected)<br />
* UI enhancement: New scale diagram function (scale and spread multiple steps)<br />
* UI enhancement: Lint performs a number of checks on a block being edited and gives immediate warnings in the info line (same checks as in the tree's error- and special search tabs)<br />
* UI enhancement: New lint-error check rules to detect consumed pin values in loops and multi-triggered chains.<br />
* UI enhancement: Double click on a search item to navigate to it in the tree<br />
* UI enhancement: Codeview and network view in the activitylog indicate that they are readonly.<br />
* UI enhancement: Secondary navigation tree for drag&drop.<br />
* UI enhancement: Warn if it is due time to check for updates.<br />
<br />
* STD-LIB: Collection creator and multi-setter blocks with variable number of pins (alternating key-value pairs)<br />
* STD-LIB: New DLL-Mapping block<br />
* STD-LIB: New blocks "File [modification time]", "File [access time]" and "File [creation time]".<br />
* STD-LIB: Additional blocks for event queue handling.<br />
* STD-LIB: Additional blocks for static step-local storage.<br />
* STD-LIB: Better versions for FAIL/WARN/INFO, LogFAIL, logWARNING and logINFO. New "Transcriber with Timestamp" action.<br />
* STD-LIB: Fixed some collection-type issues (now pins are #-template-typed, instead of Collection), which required a downcast in many suites.<br />
* STD-LIB: New blocks: "Trigger Periodically" and "Counter"<br />
* STD-LIB: New blocks: "Enumtype symbol<->integer"<br />
<br />
* Fix: Freeze value menu of unions of enums did not merge the individual enum values<br />
* Fix: Freeze value menu of unions of constraint dataType-types<br />
* Fix: The search breakpoints function (in the errors-tab of the treeview) now also finds statement breakpoints.<br />
* Fix: Fixes and improvements in the SOAP, REST and WSDL frameworks<br />
* Fix: Enum numeric value assignments were lost sometimes when saving/restoring<br />
* Fix: Search for references of a variable did not find them in imported libraries<br />
* Fix: Report of looped testplans (pre-action was reported multiple times)<br />
* Fix: behavior of cancel pin (did neither drive triggerOut-pin, nor exception-pin)<br />
* Fix: Fixes for crashes in follow mouse and backward (XPath) compatibility in WindowsAutomation Plugin<br />
* Fix: The embedded type editor for defined classes lost its code window, when reopened on another class type.<br />
* Fix: Proper class naming is now enforced in the type editor.<br />
<br />
<br />
== Release 2.7.5 (2015-06-09) ==<br />
'''New features''':<br />
* The JavaFX plugin now supports keyboard input. Use the block "''Request Focus''" to focus an input field and the block "''Type Text''" to enter any text.<br />
<br />
'''Bugfixes''':<br />
* The JavaFX plugin now provides improved connection handling.<br />
<br />
<br />
For expecco running under Linux you need glibc >= 2.14<br />
<br />
Tested technology versions:<br />
* Selenium<br />
* The Java Bridge requires a JDK version 1.6 or higher<br />
* JavaFX testing requires JavaFX 8<br />
* Qt: Qt 2.6.3 (MinGW, vs2008), Qt 4.8.4 (MinGW, vs2008, vs2010, vs2013), Qt 5.4.2 (vs2010, vs2013)<br />
* .NET<br />
* MFC<br />
* HTML 5<br />
* DevExpress<br />
* Android<br />
* iOS<br />
* Windows CE/Mobile Phone<br />
* CANoe: 8.2 SP4<br />
* WSDL-Import: it is required that you re-import your WSDL-Definitions in your Testsuites<br />
<br />
==Release 2.7.1 ==<br />
* Convenient menu functions to add the special [[Expecco API#Using a Particular JVM Connection / Executing Groovy on a Possibly Remote Machine|"java" and "groovy"]] input pins to a Groovy elementary block.<br />
* Standard library: new blocks: "''Directory [ Contents as Filenames ]''", "''Directory [ Contents as Pathnames ]''", "''Directory [ Contents as Basenames ]''", "''File [ isReadable? ]''" and "''File [ isWritable? ]''"<br />
<br />
==Release 2.7 ==<br />
* Patches go into a release specific directory (e.g. patches-2.7.0.5)<br />
* configurable external editor for attachments and csv data (e.g. excel or openoffice calculator)<br />
* tree view: markers in search lists; add to/remove from remembered list menu items<br />
* tree view: folders can have tags, too<br />
* tree view: per-tag icons in tree<br />
* [[Starting expecco via Command Line/en#Utility_Functions|"--diff" command line option]]<br />
* [[Starting expecco via Command Line/en#Startup|"--settings" command line option]]<br />
* Scatter/Gather composition of test plans from multiple suites [[Starting expecco via Command Line/en#Scatter Gather Test Suite Composition|via command line arguments]]<br />
* library: background OS process and background block actions<br />
* improved type checks and preference settings<br />
* schema editor: cursor up/down keys in pin name fields<br />
* schema and diagram editor: additional menu functions in multiple-pin selection menu<br />
* new blocks in the StandardLibrary: ExceptionClassifier, WriteCSV, Load/Save Environment from/to CSV<br />
* [[SAP Testing|SAP plugin and VBScript action blocks]]<br />
* change in the handling of Groovy callbacks. Please read [[Expecco API/en#Attention_.2F_Warning|"Attention / Warning"]] and [[Expecco API/en#Special_Functions|"Special Functions"]] in the Groovy API documentation.<br />
* improved Groovy debugging support<br />
* new common Android and iPhone/iPad testing framework<br />
* option to save a per-run report, when a suite is executed in a loop (especially useful, when running until fail or until success)<br />
* block assertions: assert-executed / assert-all outputs written / assert any output written<br />
* License server support<br />
<br />
<br />
==Release 2.6.2 bugfix release - April 2014 ==<br />
Thus is a stable release consisting of the 2.6.1 base version INCLUDING all 2.6.1 patches (up to April).<br />
<br />
==Release 2.6.1 update - January 2014 ==<br />
* [[Expecco API#Groovy_Elementary_Blocks|groovy action]]: the java-bridge can be passed in via pin named "java" or environment var named "JAVA". GroovyShell can be passed in via pin named "groovy" or variable named "GROOVY". Pins are optional for backward compatibility.<br />
<br />
==Release 2.6 - November 2013 ==<br />
* New testplan execution loop mode: "loop until required test fails"<br />
* More options for automatic check for and installation of updates & patches<br />
* Better default directories in file open/save/import dialogs.<br />
* Tuned automatic reimport when multiple libraries are imported.<br />
* Improved Java object inspector<br />
* New attachment contents representation modes.<br />
* Step tooltips include the underlying block's tree location.<br />
* Shift click on connection selects all underlying connections.<br />
* Give an indication (colorize menubar) if running with root/Admin rights.<br />
* Option to put the custom operations menu into the top menu<br />
* Additional tab in tree view to search by item-type<br />
* Additional search options for interfaces and concrete actions<br />
* Various bug fixes & enhancements:<br />
** handle duplicate attachment filenames,<br />
** fixed some type conversions,<br />
** fixed clipboard handling under XWindow/Qt desktop,<br />
** fixed non-changing testplan/testitem spec page.<br />
** added string search in resources, skills and inventories<br />
** no longer close expanded tree items when reimporting<br />
** fixed making an imported library writable, which is imported by another sub-import<br />
** fixed freeze of template pin to boolean/enum<br />
** fixed enum values which start with a digit (aka '001 aaa')<br />
** remove freeze value connection via menu<br />
<br />
<br />
==Release 2.5 ==<br />
* Can refer to [[Environment Editor#Initialization Types|shell environment variables]] in an environment variable's initializer.<br />
* New elementary block type: Groovy Code. Installs script code to be executed in a Java target or a local JVM.<br />
* New keyword driven actions<br />
* Additional checks in save dialogs to prevent overwriting another testsuite/library<br />
* Optional automatic reimport or check for reimportable imports (configure via settings dialog)<br />
* Additional freeze value validation when types are edited<br />
* New plugin: Jar Import<br />
* New and much improved manual test import plugin<br />
* Speedup, improvements and fixes in the JavaBridge plugin<br />
* Menu actions can [[Misc Editor#Background_Actions|execute in the background]] (name as "...&")<br />
* Background actions in testplan and testcase<br />
* Much faster: startup, plugin loading and bridge communication<br />
* Multiple freeze value menu organizations for enum types (hierarchical selection)<br />
<br />
===Release 2.5.1 - July 2013 ===<br />
<!-- This is a bugfix release, in which various patches and small enhancements from the past few months have been integrated.<br />
<br><br />
--><br />
* Automatic & semiautomatic update from server<br />
<br />
<br />
==Release 2.4 - February 2013 ==<br />
This is a bugfix release, in which various patches and small enhancements from the past few months have been integrated.<br />
<br />
<br />
==Release 2.3 - December 2012 ==<br />
* New integrated GUI Browser<br />
* New menu functions: "minimize/restore all Windows"<br />
* Polarion compatible report<br />
* Improved Project-Diff-Browser<br />
<br />
<br />
==Release 2.2==<br />
* New SchemaEditor menu functions: copy/paste pin interface<br />
* New plugin: [[GembirdPowerControlPlugin Reference#|Gembird Power Control Plugin]]<br />
* New debug-menu function: "close all temporary windows"<br />
* [[Probe|Probes]]; easy recording and check of pinValues<br />
* JUnit compatible report<br />
* HTTP and SOAP transmission log (optional on Transcript)<br />
* Fixed WSDL/SOAP for document-style operations<br />
* Better inspector (hex dump tab, hex representation of floats)<br />
<br />
<br />
==Release 2.1 - November 2011==<br />
* Condition variables for simple (and easy to use) control of testcase execution<br />
* [[Webservices#REST_Baustein|REST-Call]] blocks<br />
* Option to disable logging of activityNotifications (from the underlying language framework)<br />
* URL-override for SOAP service call blocks via the SOAP_URL environment variable.<br />
* Access to the certificate store (for SSL/HTTPS), allows adding and removing individual certificates<br />
* Elementary steps can have a variable number of output-pins (for multiplexer, dispatcher, round-robin generators etc.)<br />
* New menu function: "Generate Value Extractor" for Dictionary-typed pin values. (in the activityLog, output pin-data menu)<br />
* New tree-menu function: "Refactor"->"Change Variable Access", to search for and replace environment variable references.<br />
* New datatype [[Datatype Element#Special_Types|"struct"]], to represent arbitrary compound (struct) values.<br />
* GUI improvements: better annotation-text editors; line numbers, tags in file viewer<br />
* Allow for multi pin-value parametrization in testplan (block with multiple inputs in a testplan item)<br />
* Proxy support for HTTP-fetch blocks<br />
* Recording feature for Java Swing GUIs<br />
* Enhanced Java Swing Function Block Library<br />
* GUI Browser improvements: tree view with widget specific icons, record tree actions<br />
<br />
<br />
==Release 2.0==<br />
* Elementary steps can have a variable number of input-pins (improves the format, plus, string-concat and many other blocks)<br />
* Statistic page added to the project editor<br />
* Improved manual test import plugin; nicer Manualtest runner GUI; user definable manual test GUI<br />
* Allow for pin-value parametrization in testplan (block with a single input parameter in a testplan item)<br />
* Configurable max. cleanup time after terminating a run; Confirmation Dialog when longer.<br />
* ActivityLog: added "Select in Tree" from log-entry<br />
* HTTPS / SSL Support for HTTP blocks</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Konzepte&diff=10576Konzepte2018-02-21T11:36:22Z<p>Mawalch: </p>
<hr />
<div>#REDIRECT[[Concepts/en]]<br />
<br />
[[Category:Temporary Short Redirect]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Konzepte&diff=10575Konzepte2018-02-21T11:35:55Z<p>Mawalch: Content is an exact duplicate of Concepts/en. Replace with redirect.</p>
<hr />
<div>#REDIRECT[[Concepts/en]]<br />
<br />
[[Category:Temporary short redirect]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Reimport_Tool&diff=10574Reimport Tool2018-02-20T11:59:05Z<p>Mawalch: </p>
<hr />
<div>Dieses Werkzeug erlaubt es dem Benutzer seine Bibliotheken auf den aktuellsten Stand zu bringen.<br />
Dabei definiert der Benutzer eine Menge von Bibliotheks-Dateien die auf Aktualität überprüft werden<br />
und gegebenenfalls zusätzliche Bibliotheken die für den Reimport mit herangezogen aber selbst<br />
nicht modifiziert werden.<br />
Das Reimport Tool entscheidet dann in welcher Reihenfolge diese Bibliotheken geladen, modifiziert<br />
und zurückgeschrieben werden. Dabei werden innerhalb einer Bibliothek nur die direkt zu reimportierenden<br />
Bibliotheken betrachtet und falls erforderlich reimportiert.<br />
Um zu garantieren, dass alle verschachtelten Bibliotheken auf dem aktuellsten Stand sind, müssen zuerst die<br />
direkt importierten Bibliotheken auf den neusten Stand gebracht werden.<br />
Dabei wird für den Reimport eine Reihenfolge der zu aktualisierenden Bibliotheken so festgelegt, dass zuerst<br />
die Bibliotheken aktualisiert werden, für die bereits aktuelle Bibliotheken zur Verfügung stehen.<br />
Im weiteren Verlauf werden nun diese aktualisierten Bibliotheken für den Reimport herangezogen.<br />
<br />
Dabei kann der Benutzer entscheiden, ob die bereits aktualisierten Bibliotheken sofort<br />
nach dem jeweiligen Reimport überschrieben werden oder erst am Ende des ganzen Reimports (Alles oder Nichts).<br />
<br />
Werden Bibliotheken mit der gleichen Funktionalität (FID) während des Reimports erkannt, werden diese<br />
zwar aktualisiert aber nicht für den Reimport in andere Testsuiten mit einbezogen, da keine Eindeutigkeit existiert!<br />
<br />
Treten beim Reimport Fehler beziehungsweise Warnungen auf kann der Benutzer entscheiden wie diese zu behandeln sind. <br />
Es besteht die Auswahl zwischen Abbruch der zu reimportierende Bibliothek, der Testsuite oder dem ganzen Reimport. Im Falle<br />
einer Warnung kann der Benutzer diese ignorieren und mit dem Reimport fortfahren.<br />
Beim Abbruch des Reimports ist zu berücksichtigen, das falls man sich für das Überschreiben der Dateien erst am Ende des<br />
Reimports entschieden hat, alle bis dahin gemachten Änderungen verloren gehen!<br />
<br />
Beim Laden der zu aktualisierenden Bibliotheken bzw. der zusätzlichen Bibliotheken für den Reimport<br />
kann der Benutzer zwischen einem Verzeichnis, einem Verzeichnis mit allen<br />
Unterverzeichnissen oder auch einer Datei, die die vollständigen Pfadnamen der Dateien enthält auswählen.<br />
Diese Datei kann über den Testsuite Browser oder auch vom Benutzer selbst angelegt werden. Dabei ist zu<br />
berücksichtigen, dass pro Zeile ein vollständiger Pfadname steht (Leerzeilen sind erlaubt).<br />
<br />
Beispiel für einen Dateiinhalt, der gelesen und ausgeführt werden kann:<br />
C:\Pfad\Datei1.etc<br />
C:\Pfad\UnterOrdner\Datei2.etc<br />
C:\Pfad\UnterOrdner\Datei3.etc<br />
<br />
Die angegebenen Pfadnamen unterliegen keiner Sortierung.<br />
Diese Datei kann auch über den Testsuite Browser erzeugt, gelesen und geändert werden.<br />
<br />
;Wichtiger Hinweis!<br />
:Während des Reimports muss mindestens ein expecco Browser geöffnet sein ansonsten wird expecco verlassen und somit der Reimport abgebrochen! Dieses Fehlverhalten wird in der nächsten Version von expecco behoben sein. Ebenso kann der Reimport momentan nicht über die Kommandozeile ausgeführt werden.<br />
<br />
<br />
Das Werkzeug zum Reimport von Bibliotheken finden Sie unter Extras / Werkzeuge in der Menüleiste.<br />
<br />
<br />
<br />
==Einstellungen==<br />
Die Einstellungen finden Sie unter Extras / Einstellungen.<br />
<br />
===Wie sollen Warnungen behandelt werden===<br />
;Öffne Browser<br />
:Warnungen werden in einem Fenster angezeigt; der Benutzer kann dann entscheiden wie er die Warnungen behandeln möchte (blockierend).<br />
;Überspringen der Testsuite<br />
:Die Aktualisierung der Testsuite wird abgebrochen und es wird mit der nächsten Testsuite fortgefahren. Die original Datei bleibt unverändert.<br />
;Überspringen der Bibliothek für den Reimport<br />
:Die gerade zu reimportierende Bibliothek wird übersprungen und es wird mit der nächsten zu reimportierenden Bibliothek in der Testsuite fortgefahren.<br />
;Warnungen ignorieren<br />
:Es wird kein Fenster bezüglich Warnungen geöffnet; der Reimport der Bibliothek wird als erfolgreich gewertet.<br />
;Reimport abbrechen<br />
:Abbruch des Reimports. Alle Änderungen die bis zu diesem Zeitpunkt nicht übernommen wurden gehen verloren (siehe dazu: 'Vorhandene Testsuite sofort nach dem Ändern überschreiben').<br />
<br />
===Wie sollen Fehler behandelt werden===<br />
;Öffne Browser<br />
:Fehler werden in einem Fenster angezeigt; der Benutzer kann dann entscheiden wie er die Fehlermeldungen behandeln möchte (blockierend).<br />
;Überspringen der Testsuite<br />
:Die Aktualisierung der Testsuite wird abgebrochen und es wird mit der nächsten Testsuite fortgefahren. Die original Datei bleibt unverändert.<br />
;Überspringen der Bibliothek für den Reimport<br />
:Die gerade zu reimportierende Bibliothek wird übersprungen und es wird mit der nächsten zu reimportierenden Bibliothek in der Testsuite fortgefahren.<br />
;Reimport abbrechen<br />
:Abbruch des Reimports. Alle Änderungen die bis zu diesem Zeitpunkt nicht übernommen wurden gehen verloren (siehe dazu: 'Vorhandene Testsuite sofort nach dem Ändern überschreiben').<br />
<br />
===Testsuite sichern===<br />
;Vorhandene Testsuiten überschreiben (Voreinstellung)<br />
:Nach Aktualisierung der Testsuiten werden die original Dateien überschrieben <br />
;In Ordner speichern<br />
:Die aktualisierten Testsuiten werden in einem definierten Ordner abgelegt, die originale Dateien werden nicht überschrieben!<br />
<br />
===Logdaten===<br />
;Dateinamen festlegen (optional)<br />
:Alle durchgeführten Operationen als auch Fehler und Warnungen werden während des Reimports in diese Log-Datei geschrieben.<br />
<br />
===Weitere===<br />
;Reduzierte Bibliotheken nicht reimportieren (Voreinstellung)<br />
:Reduzierte Bibliotheken werden nicht reimportiert.<br />
;Vorhandene Testsuite sofort nach dem Ändern überschreiben<br />
:Standardmäßig werden modifizierte Testsuite-Dateien erst am Ende des Reimports überschrieben. Wird der Reimport vorzeitig abgebrochen gehen alle Änderungen die bis zu diesem Zeitpunkt vorgenommen wurden verloren.<br />
<br />
==Laden von Testsuiten==<br />
<br />
Zunächst wird der Benutzer aufgefordert, eine Liste der zu modifizierenden Testsuiten einzugeben.<br />
Nach dem Laden dieser Testsuiten kann der Benutzer zusätzliche Bibliotheken hinzufügen<br />
die für den Reimport verwendet selbst aber nicht modifiziert werden (z. B. die Standard-Bibliothek).<br />
<br />
<br />
Zum Laden von Testsuiten werden folgende Optionen angeboten:<br />
<br />
;Öffnen<br />
:Handelt es sich bei der selektierten Datei um eine Testsuite, so wird ausschließlich diese Testsuite geladen.<br />
:Handelt es sich bei der selektierten Datei um ein Verzeichnis, so werden alle Testsuiten innerhalb dieses Verzeichnisses geladen.<br />
<br />
:Andernfalls wird davon ausgegangen, dass es sich bei Datei um eine Benutzer definierte Datei handelt, welche die vollständigen Pfadnamen der zu ladenden Testsuiten enthält.<br />
<br />
;Öffnen (rekursiv)<br />
:Laden aller Testsuiten innerhalb des selektierten Verzeichnis einschließlich aller Unterverzeichnissen (rekursiv).</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Konzepte&diff=10573Konzepte2018-02-20T11:58:02Z<p>Mawalch: </p>
<hr />
<div>[[Category:Incomplete]]<br />
[[Category:Work In Progress]]<br />
[[Category:Marked for Deletion]]<br />
<br />
== Introduction ==<br />
<br />
=== The Situation ===<br />
<br />
Since graphical and interactive modeling came up in computer science, a remarkable number of tools have been developed to facilitate the generative creation of products, especially high-technology products.<br />
For a long period of time, big attention has been turned to the automated '''generation''' of products, but less attention was spent towards the automation of product '''testing''', especially in the development phase (less so in manufacturing).<br />
<br />
Classic testing was - and still is - more than often the unstructured sum of multiple individual, partial tests, in most cases performed by the developers themselves, and often inconsequently conducted due to the lack of time. This usually leads to using proprietary testing systems, which in addition are incompletely and sometimes erroneously implemented, and for all aspects of the testing, the collaboration or support of an expert is required.<br />
<br />
Today, the steadily increasing complexity of high technology products, together with the continuous shortage of development cycle times, but also the expectations of the customers regarding quality and reliability, let testing become one of the major issues of modern product development. Also the markets for which products are generated are changing - Increasing concurrence and economical challenge raise the need for reusable work. Internationalization and outsourcing bring up new requirements for logistics and communication. Accordingly, also decentralized tests have to be well organized, and a division of the testing process into distinct testing roles becomes indispensable.<br />
<br />
=== The Solution ===<br />
<br />
The German-based eXept Software AG was one of the first and earliest software companies to take this topic serious and, as a result of many years of development, the expecco system is a professional approach to this issue. Utilizing the newest technologies of the current UML 2.0 standard, and extending them by a set of powerful special features, expecco is the state-of-the-art solution for modeling, executing and evaluating tests efficiently. Using standard interfaces, existing tests and testing systems can easily be embedded into the expecco test workflow on one side, and expecco itself can be embedded in existing frameworks. This allows a seamless integration of expecco into almost any existing infrastructure.<br />
<br />
expecco is a modern, element based, modular test and quality ensurance platform, which aims at the consolidation of tests and partial test systems into an automated, interactive test center, and making them accessible to wider person subgroups dependent on their particular role in the test events.<br />
<br />
The concept of test modeling introduced by expecco decisively eases the development, execution and evaluation of even most complex test scenarios. This leads to a significant productivity improvement at the creation and maintenance of test scenarios. The integrated versioning of test sequences and test results, the concise library concept, the generally intelligible representation of test scenarios, the wide debug features, and flexible enterprise integration, are additional considerable features.<br />
<br />
By introducing different roles for the people involved, it also - and especially - suits complex and distributed test scenarios. The usage of built-in as well as self-defined libraries is the basis for the exchangeability and extensive reuse of your work. Sophisticated standard libraries provide you with the typical elements that are frequently used.<br />
<br />
== Overview and Structure of this Document ==<br />
<br />
This chapter will give a brief overview on the topical categories of the expecco system, and on the most important terms which apply to them. In the subsequent chapters, each of the mentioned categories will be discussed, explaining each of the according elements individually, as well as the way they are used in cooperation in the expecco System.<br />
<br />
=== User Roles ===<br />
Users of expecco may take different ''roles'' during the testing operation. Depending on the project size and other factors, it is both possible that a single person takes any of these roles, or that a group of persons is split and assigned the distinct roles:<br />
<br />
* The <span class="KEYWD">'''Coder'''</span> is responsible for the generation of building blocks for the test scenario. These building blocks are typically elementary blocks, which are either programmed explicitly, or which invoke existing procedures of the system under test via some communication mechanism like Shell commands, RPC, SOAP, DLL-calls, Java-method calls etc. Typically, the Coder is a programmer. In many companies, Coders are also part of the product-development team, and they provide low-level interfacing function blocks to the testers in form of a library which is maintained and versioned with the product being developed.<br />
* The <span class="KEYWD">'''Composer'''</span> is creating test scenarios by arranging elementary building blocks into higher level networks of activity diagrams. There is no need for the composer to be a programmer, which does not say, that he often is and the distinction between Coder and Composer roles is always present. Typically, the composer has broad domain knowledge of the system under test, knows typical usage scenarios, has an understanding of possible failures and is well informed about the systems overall requirements.<br />
* The <span class="KEYWD">'''Tester'''</span> is executing tests. Typically, he has to stage the hardware environment of the test, like posing and connecting measurement units and probes, and care for configuration details, such as hostnames, IP addresses, measurement device specifics etc. Very often, the Tester is also the Composer of the test, and often even the Coder.<br />
* The <span class="KEYWD">'''Auditor'''</span> is interpreting test results. He evaluates the test results and generates reports for these results. Typically, the analyzer is the interface to the project-, quality- and product-management.<br />
<br />
These user roles are described in detail in the chapter [[ Concepts/en#Architecture and User Roles | "Architecture and User Roles" ]].<br />
<br />
=== Dataflow Modeling and Activity Diagrams ===<br />
<br />
The expecco System makes use of ''Activity Diagrams'' as they are known from the UML 2.0 standard. Although there are many other possible kinds for process modeling in the UML specification, Activity Diagrams offer the best approach to model ''dataflow'' driven processes. This is a fundamental difference to the other diagram types in the UML specification, which are all more or less controlflow driven.<br />
<br />
However, dataflow modeling is the easiest modeling technique for humans to understand, because it resembles most to the way humans use to think and act. The process pattern is divided into distinct blocks, which represent associated subject parts of the process to be modeled. Instances of these blocks are supplied with data, which causes them to execute, and produce resulting data, which can be passed to other block instances or otherwise evaluated. To illustrate this, think of a person that works somewhere in an office: an information is coming in (in his input-basket or todo-list), the person acts due to this information, and supplies the resulting information when the job is done (sends it out via an output basket, email or whatever).<br />
<br />
Another important issue in this context is ''parallelism'': Launching activities in a dataflow model is not achieved by explicit calls, instead the presence of the required information is initiating the activity. From a controlflow style diagram, if at all parallelism can be created with it, it is not easy for humans to anticipate the parallelism behavior of the model, especially when the diagram gets more complex. In a dataflow diagram on the other hand, parallel behavior is directly visible and almost always obvious. Using a real world picture, think of parallel execution as having multiple desks, each with its input and output baskets, and multiple workers doing their work on these jobs (tasks).<br />
<br />
=== Workflows, Blocks, Steps, Activities ===<br />
<br />
The major task to create test scenarios in expecco is the creation of ''Workflows''.<br />
Using the expecco GUI, these Workflows are modeled in the form of <span class="KEYWD">Activity Diagrams</span>, as mentioned before.<br />
activity diagrams are not the only way to create workflows, neither are they the same thing.<br />
While a workflow is an abstract executable network, an activity diagram is a graphical, possibly editable <span class="EMPH">representation</span> of a workflow.<br />
The usual terminology would tell that workflows are made up of so-called <span class="KEYWD">Blocks</span>, but to be more precise, the following distinction has to be made:<br />
<br />
<br />
* An '"'Action Block"'' (also hereafter often referred to as "block" or "action") is the '''representation and definition''' of an operation (or part of it) to be modeled. Inside an expecco project, blocks are organized in a tree as so-called <span class="KEYWD">Tree Elements</span> (or occasionally "Tree Items"). Blocks are abstract generalizations of activities, i.e. they are never executed directly, instead they provide a '''blueprint for the behavior of activities''' that are spawned from them. Thus an action describes a possible activity. It becomes a real activity, once it is performed.<br />
<br />
* A ''"Step"'' is a '''modeling instance''' of an action block. In a workflow, steps are placed and interconnected to model the desired behavior. While blocks are unique objects within a project, '''any number''' of according steps can be embedded in any workflow, each representing an '''individual instance of the block's blueprint'''. The steps inside a workflow mark the spawning points for the activities which are created from the according blocks when the workflow is executed.<br />
<br />
* An ''"Activity"'' is a '''concrete executing instance''' of a step, and exists only as long as it is being executed. Multiple activities can be spawned concurrently from the same step or different steps which are associated with the same or different action blocks. Activities are created when a step inside a workflow is being invoked (i.e. activated or triggered).<br />
<br />
Since workflows can, in their entireness, also be regarded as assembled blocks, there is a special type of block in expecco which contains such a (sub-)workflow. These so-called ''"Compound Blocks"'' can then in turn be integrated into other workflows. Compound blocks are the key to the unlimited flexibility and reusability of the expecco workflow system. They allow not only to organize, but also to easily re-organize activity patterns, divide existing patterns into partial ones, and even to automatically generate new patterns out of arbitrary subsets of existing ones. This helps to create intuitively associable structures, and to rearrange them with ease whenever needed.<br />
<br />
In contrast, the so-called ''"Elementary Blocks"'' do not combine other blocks, but instead are used for basic data processing, and to provide access to the operating system and to the interfaces of the real world. They are needed to exchange information with the testing environment outside the system, e.g. to exchange signals, obtain measurement values, display dialogs, etc. This is achieved either by programmatic, scripting or dll call access, or by remote invocation methods like RPC, SOAP, DCOM, DCE, OLE, or CORBA.<br />
<br />
Workflows and activity diagrams are described in detail in the chapter [[Concepts#Workflows and Activity Diagrams|"Workflows and Activity Diagrams"]].<br />
<br />
=== Tests, Test Plans, Test Runs, and Test Results ===<br />
<br />
A ''"Test Case"'', (or "''Test''" for short) in terms of the expecco system, is a block which can either fail or succeed when executed. A ''"Test Plan"'' is a set of individual tests which are sequentially processed when the test plan is processed. A ''"Test Run"'' designates the execution of a test plan or a single test case, providing tracing and logging information on each step of the execution and an overall result status, called the test's "''verdict''". A verdict is simple OK/not-OK information, whereas a ''"Test Result"'', is the collection of the overall verdict PLUS all individual (sub-)results PLUS the set of collected log messages, tracing data, execution times etc. of a test run.<br />
<br />
Test results can be stored either in a database (Oracle, SQL, Access, etc.), or as a standardized XML file or in one of the common formats which are understood by other third party tools (Jenkins, JUnit, CSV/Excel, etc.). This information can be further processed, and be used to generate reports, statistics, etc., which can finally be stored as PDF or HTML viewable files.<br />
<br />
Because the desired appearance of a report usually depends on company-specific style guides, these reports are customized in level of detail and graphical appearance via a set of customizable rules. A standard default set of rules is included in the expecco release, either to work with immediately, or as a starting point for your own, personalized reports. In addition, arbitrary transformations are possible for experienced users, by taking the XML report file and processing it via standard XSLT rulesets.<br />
<br />
Tests, test plans, test runs, and test results are described in detail in the chapter [[Concepts#Using Elementary Blocks|"Using Elementary Blocks"]].<br />
<br />
=== Resources, Skills, Requirements and Inventories ===<br />
<br />
Notice: to begin using expecco, you will probably not need to deal with shared resources, skills and inventories and may want to skip this section. It is not required for expecco's operation, but a very useful feature, when your test infrastructure becomes more complex.<br />
<br />
<br />
In addition to its input data values, a block may also require a set of ''"Resources"'' for its activity to be started. Possible resources could be human operators, machinery, measurement devices, hardware resources or database locks.<br />
<br />
To honor the fact that some resources (especially humans) can take different roles, a resource is defined by a set of ''"Skills"''. A skill is a pattern for a particular kind of ability or feature. A block may define a set of ''"Requirements"'' which are necessary for its processing, and an activity can only be spawned from it if enough resources can be allocated to meet the needs hereby defined.<br />
<br />
Besides the obvious use of resources to model skills and availability of humans or devices, they can also be very useful for process synchronization. Semaphores, database locks, mutual exclusion and limiting parallel execution can all be easily modeled using resources.<br />
<br />
Resources are managed and held by ''"Inventories"''. Whenever an activity is started, the matching resources are allocated (fetched) from the assigned inventory and moved into a temporary inventory, which is held by the activity during execution. When the activity is finished, all allocated resources are returned to the inventory they were taken from.<br />
<br />
Inventories form a hierarchy, where sub-inventories allocate resources from a parent inventory. Thus, during test execution, resources are requested from a temporary execution inventory, which requests its resources from a lab inventory, which may even request more resources from a department inventory.<br />
<br />
When used in isolation (e.g. without expecco ALM), the maintenance of the inventory is done completely within the executing expecco, and the tester will maintain and configure its contents. However, when used in a department infrastructure, resources must be maintained on a broader scale, to prevent shared (mis-)use when testers start their tests on their personal machine. For this, expecco ALM maintains such inventories and locks non-sharable resources while tests are running.<br />
<br />
Resources, skills, requirements and inventories are described in detail in the chapter [[Concepts#Resource Management|"Resource Management"]].<br />
<br />
=== Testsuite and Testsuite Elements ===<br />
<br />
In expecco, test cases are organized in <span class="KEYWD">Testsuites</span>, which are composed of <span class="KEYWD">Testsuite Elements</span>. You can think of the testsuite elements as the basical units of association when working with expecco: editing a testsuite means editing one or more of its elements. In the expecco GUI, testsuite elements are kept and arranged in the <span class="KEYWD">Element Navigation Tree</span>. There are five categories of testsuite elements:<br />
<br />
* For workflow creation, arrangement and execution, the <span class="KEYWD">Block</span> and <span class="KEYWD">Testplan</span> elements are used.<br />
* For embedded test data (which is not provided by external files, databases, web services etc.), the <span class="KEYWD">Attachment</span> element is used.<br />
* For resource management, the <span class="KEYWD">Skill</span>, <span class="KEYWD">Resource</span> and <span class="KEYWD">Inventory</span> elements are used.<br />
* For project organization, the <span class="KEYWD">Group</span>, <span class="KEYWD">Package</span>, <span class="KEYWD">Library</span> and <span class="KEYWD">Documentation</span> elements are used.<br />
* For individual adaptation and extension, the <span class="KEYWD">Datatype</span> and <span class="KEYWD">Class</span> elements are used.<br />
<br />
There are no further types of testsuite elements that you need to know. However, some of the listed element types include different specialized subtypes.<br />
<br />
Testsuite management concepts are described in detail in the chapter [[Concepts#Testsuites and Testsuite Elements|"Testsuites and Testsuite Elements"]].<br />
<br />
== Architecture and User Roles ==<br />
<br />
A common truth in the context of the development of complex processes, is that they are ideally characterized by generalization and modularization. The development of test software is no exception to this and good practices well-known in the software development world also apply to the development of tests.<br />
<br />
While low-level elements are tested with the built-in means of the language (usually written in the development language by the developers themselves), high-level tests (acceptance, system- and end-to-end tests) are tested by constructing more complex scenarios out of existing building blocks.<br />
<br />
A test essentially is a simulation of some real world behavior and checking the System Under Test (SUT) for its correct behavior inside such scenarios. The simulation consists of artificial stimulations (triggering, parameterization, value passing) and the verification of programmed checking (database checks, physical and time measurements, GUI verification).<br />
<br />
It is this basical level on which the expecco architecture is based. It's about the dissociation of <span class="EMPH">elementary</span> and <span class="EMPH">compound</span> actions, as the prerequisite for intuitive abstraction and modularization. The SUT is not longer understood just as a surrounding subject, but instead comprehended as a discrete unit, which can be <span class="EMPH">communicated</span> with from inside the integrated testing system.<br />
<br />
This view also directly clarifies the question for which types of tests expecco<br />
is applicable: for all test scenarios whose parameters relevant for the evaluation<br />
can be retrieved by use of computers, and whose stimulations required for<br />
the operation can be created by use of computers. In the last consequence,<br />
this can also simply be done by using dialogs, so that in principle, '''any'''<br />
test scenario that is '''evaluatable''' by use of computers,<br />
can be engaged with expecco.<br />
<br />
The modeling architecture of expecco is made up of four consecutive levels.<br />
* The first level is the one that connects the system under test to the testing system. At this point, <span class="KEYWD">elementary building blocks</span> come into use, which primarily serve for creating the communicative interfaces between expecco and the testing environment.<br />
* From those, on the second level, abstract <span class="KEYWD">compound building blocks</span> are composed, which in turn can contain both types of building blocks.<br />
* On the third level, <span class="KEYWD">test plans</span> are generated that combine one or more blocks for sequential execution, and which can also be nested (test plan in test plan). When executing, the <span class="KEYWD">test results</span> are generated, which<br />
* on the fourth layer are logged as result files or documents, or can be made available in a database or a QM tool (expecco ALM, Polarion, JIRA, Quality Center etc.)<br />
<br />
With expecco, a <span class="KEYWD">top-down</span>- as well as a <span class="KEYWD">bottom-up</span>-creation of tests is possible. With the <span class="KEYWD">bottom-up</span> approach, the basic functionalities for communication with the system under test and the measurement devices are created first. From these basical building blocks, more complex building blocks are then composed. With the <span class="KEYWD">top-down</span> approach, in contrast, the test scenarios are created very early and on high level. This is even possible when the system under test or the interfaces to it do not yet exist. Though such a test scenario can not yet execute, it however documents the system behaviour already in an early project phase, and can serve concurrently as requirement and as documentation.<br />
<br />
=== The expecco Role Model ===<br />
<br />
The persons involved in the integrated testing environment take different<br />
<span class="KEYWD">roles</span>. Essential for the reasonable division of<br />
the roles is the <span class="KEYWD">black-box concept</span>, which permits<br />
every subject of one of these roles to act independent of the others. Black-box<br />
means, that for the usage of building blocks, not their internal structure,<br />
but only the interface to the outside, has to be known.<BR><br />
<br />
Depending on the extent and complexity of the conceptual formulation, the<br />
roles can also overlap, one person can cover multiple roles, or one role can<br />
be covered by multiple distinct persons. However, the pivotal thing is that<br />
the division of the roles allows a well defined limitation of the required<br />
skills, as well as the competencies of the people involved.<br />
<br />
=== The User Roles ===<br />
The following paragraphs describe the four distinct user roles introduced by the expecco system:<br />
&nbsp;<br />
<br />
* The Coder Role:<br>The <span class="KEYWD">Coder</span> provides the basic functionalities and interfaces for tests by <span class="EMPH">creating basical building blocks</span> ("<span class="KEYWD">Elementary Blocks</span>", EB). The Coder implements them in programming languages like Smalltalk, Java, C, JavaScript, Perl, Shell, etc. Also direct invocations of existing programs are possible in the form of EBs, on the local platform as well as remotely via RPC, SOAP, DCOM, DCE or CORBA. Preparatively for the Composer, the Coder can also combine EBs into composite building blocks ("<span class="KEYWD">Compound Blocks</span>", CB).<br />
[[Datei:PIC_Concepts_Architecture_UserRoles_Coder.png]]<br />
<br />
* The <span class="KEYWD">Composer</span> Role:<br>The <span class="KEYWD">Composer</span> makes use of existing building blocks (like those supplied by the Coder or a library), and <span class="EMPH">generates assembled composite building blocks</span> ("<span class="KEYWD">Compound Blocks</span>", CB) by interconnection of those existing EBs and CBs. They can in turn be combined into more complex CBs or test lists. In a CB, required resources like e.g. measuring devices or personnel can be declared. With top-down development, the Composer will usually define the demands for the Coder by modularization. The Composer solely needs domain knowledge, but usually no special programming proficiency.<br />
[[Datei:PIC_Concepts_Architecture_UserRoles_Composer.png]]<br />
<br />
* The <span class="KEYWD">Tester</span> Role:<br>The <span class="KEYWD"></span> conducts test preparations and <span class="EMPH">executes concrete</span> <span class="KEYWD">Test Runs</span>. The preparations typically include the setup of the testing environment, as well as configuration details like IP addresses, measuring unit parameters, etc. The Tester either starts the tests manually, or he enrolls them for time guided execution. Before execution of the test, the system assists the Tester to make available all required resources. <span class="KEYWD">Test Results</span> are displayed to the Tester and in addition stored in a database. The Tester needs domain knowledge only as far as it is necessary for the setup of the testing environment.<br />
[[Datei:PIC_Concepts_Architecture_UserRoles_Tester.png]]<br />
<br />
* The <span class="KEYWD">Auditor</span> Role:<br>The <span class="KEYWD">Auditor</span> evaluates the <span class="KEYWD">Test Results</span>, creates statistics and trend analyses, and <span class="EMPH">supplies the evidence of quality</span>. All test data are at the Auditor's disposal in a database, which he can evaluate by means of database tools. He generates <span class="KEYWD">Test Reports</span> out of the collected data, which he typically forwards to the quality-insurance-, project- or product-management. He needs domain knowledge only as far as it is necessary for the understanding of the evaluation.<br />
[[Datei:PIC_Concepts_Architecture_UserRoles_Auditor.png]]<br />
<br />
== Testsuites and Testsuite Elements ==<br />
<br />
In expecco, test cases are organized in <span class="KEYWD">Testsuites</span>.<br />
An expecco Testsuite consists of its so-called <span class="KEYWD">Testsuite Elements</span>,<br />
or often also shortly called <span class="KEYWD">Elements</span>, and of<br />
<span class="EMPH">nothing more or less</span> than these. Note that the elements<br />
are depicted as free, unbound units, that are not structured in their appearance.<br />
Although the GUI provides a hierarchical view on Testsuite elements, they<br />
are <span class="EMPH">not</span> bound to a hierarchical arrangement. Instead,<br />
an element's <span class="KEYWD">Properties</span> may <span class="EMPH">refer</span><br />
to other elements, as explained later.<br />
<br />
Each expecco Testsuite contains<br />
exactly one <span class="KEYWD">Root Element, which represents the test suite itself</span> [[Bild:PIC_GUI_IconSymbol_ProjectComponent_PackageClosed.png]].<br />
It serves as the <span class="EMPH">base node</span> for all<br />
subsequent structures. The Root element also contains the <span class="KEYWD">Global Variable Environment</span> for the test suite, which can be accessed by any<br />
of the other elements.<br />
<br />
=== Element Categories and Types ===<br />
<br />
Testsuite elements are of different <span class="KEYWD">types</span>. The different types serve different needs, which can be grouped into distinct topical <span class="KEYWD">categories</span>. These categories are the <span class="EMPH">Workflow Management</span>, the <span class="EMPH">Resource Management</span>, the <span class="EMPH">Testsuite Organization</span> and the <span class="EMPH">Programmatic Modeling</span>.<br />
<br />
The following list gives an overview on the elements type categories, briefly explaining the role of each elements type, and introducing the icon which is used for it in the expecco GUI:<br />
<br />
* Workflow Management: The elements in this category serve for creation, arrangement and execution of Workflows. The category includes the following elements types:<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_UnspecifiedAction.png]] The <span class="KEYWD">Block elements</span> is the elements type used to contain and to model Workflows and elementary functionalities. There are several different subtypes of this elements type, each having a different icon, but all of those have the same frame as the empty one depicted here (the different subtypes are listed separately below).<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_TestPlan.png]] The <span class="KEYWD">Test Plan Elements</span> is the element type used to model and execute test sequences. A Test Plan can contain references to Block elements, as well as to other Test Plan elements to be processed as nested sub sequences of the superordinate Test Plan.<br />
* Resource Management: The elements in this category serve for definition, assignment / requirement, and housekeeping of Resources. The category includes the following element types:<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Skill.png]] The <span class="KEYWD">Skill Element</span> is the element type used to define and represent a particular type of ability (regarding a resource). Skill elements consist of an attribute list, while the attributes are not assigned any values yet.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Resource.png]] The <span class="KEYWD">Resource Element</span> is the element type used to model and represent a particular real or formal resource. A Resource is defined by a set of Skills, to each of which are given concrete values for the Skill's attributes. The Resource element itself does not yet represent a concrete instance of a resource, but instead serves as a pattern for those instances.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Inventory.png]] The <span class="KEYWD">Inventory Element</span> is the element type used to instantiate and govern concrete instances of Resources. Arbitrary numbers of instances of the according Resource elements can be registered in an Inventory. The Inventory can then be assigned to a Test Plan or other Workflow execution, serving as the pool for the Resources available to the Activities in this execution.<br />
* Testsuite Organization: The elements in this category serve for organization and overall documentation of Testsuite elements. The category includes the following element types:<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Group.png]] The <span class="KEYWD">Group (Folder) Element</span> is the element type used to accumulate elements that are belonging together associatively. The Group element has no other functionality or use other than this. It is the only element that has no element Properties assigned.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_PackageOpened.png]] The <span class="KEYWD">Package Element</span> is the element type used to accumulate Testsuites or Libraries. The Package element is usually created automatically, not by hand. For example, if you include one or more Libraries in your Testsuite, those Libraries will be nested into a self-generated Package named "imports".<br />
** [[Datei:PIC_GUI_IconSymbol_LibraryComponent_PackageClosed.png]] The <span class="KEYWD">Library Element</span> is the Root element of an imported Library (or Testsuite). It does not only serve as a hierarchical root node, but also provides the sub-global Variable Environment for the subject elements in its scope, in the same way as the Root element does it for the Testsuite. Elements below this type cannot be modified or moved, but however can be copied and pasted.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Documentation.png]] The <span class="KEYWD">Documentation Element</span> is the element type used to write down documentation contents that are not bound to a particular Testsuite element. Every element type in expecco already has a Documentation Property (except for the Group element), but each of those Properties is bound to its owning element. The Documentation element is free of this restriction, supplying the Documentation Property as the only one for its type.<br />
* <span class="EMPH">Programmatic Modeling</span>: The elements in this category serve for adaption and creation of proprietary extensions. The category includes the following element types:<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Class.png]] The <span class="KEYWD">Class Element</span> is the element type used to create and represent own or imported programmatical classes. These classes can then be used to introduce according Datatypes, in the same manner as a Datatype can be assigned an existing standard class.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Datatype.png]] The <span class="KEYWD">Datatype Element</span> is the element type used to select additional data types which are not available in the standard default set of provided data types. Datatype elements are referencing to existing, build-in or self-created classes. When a new Datatype is specified, it will from then on be available in all dropdown choosers concerning data types.<br />
* <span class="EMPH">The Block Element Subtypes</span>:The Block element type is the only expecco element type that has specialized <span class="EMPH">subtypes</span>. In the list above, only the abstract Block element type was introduced. The following list shows the concrete subtypes of the Block element type, again briefly explaining the role of each, and introducing the icon which is used for it in the expecco GUI:<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_CompoundAction.png]] The <span class="KEYWD">Compound Block Element</span> is the element type used to contain and model Workflows. Each element of this type contains exactly one so-called <span class="KEYWD">Internal Workflow</span>, also often called the <span class="KEYWD">Internal Network</span> of the Block. There are no further subtypes of the Compound Block element type. All other Block element types are called Elementary Blocks, because in contrast they have no Internal Network, instead implementing elementary functionality blocks.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] The <span class="KEYWD">Smalltalk Code Block Element</span> is the element type used to implement an elementary functionality block in form of Smalltalk style source code. Each element of this type contains exactly one so-called <span class="KEYWD">Code Content</span>, which is interpreted according to the Smalltalk/X syntax at runtime.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] The <span class="KEYWD">JavaScript Code Block Element</span> is the element type used to implement an elementary functionality block in form of JavaScript style source code. Each element of this type contains exactly one so-called <span class="KEYWD">Code Content</span>, which is interpreted according to the JavaScript syntax at runtime.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_ShellScriptAction.png]] The <span class="KEYWD">Shell Script Block Element</span> is the element type used to implement an elementary functionality block in form of Shell Script code. Each element of this type contains exactly one so-called <span class="KEYWD">Script Content</span>, which is interpreted according to a shell or batch script syntax at runtime. Since the content is directly piped to the underlying OS, and is not interpreted by the expecco engine, the executability of the contents depends on the local platform at execution time. The element type also supplies the typical streams from and to the OS process, like <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span>.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_ConsoleCmdAction.png]] The <span class="KEYWD">Console Shell Command Block element</span> is the element type used to implement an elementary functionality block in form of a console command. Each element of this type contains exactly one so-called <span class="KEYWD">Console Command</span> setup, which is executed directly by the underlying OS, as if it had been typed into an OS console window. The executability of the command depends on the local platform at execution time. The element type also supplies the typical streams from and to the OS process, like <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span>.<br />
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_DataGeneratorAction.png]] The <span class="KEYWD">Test Data Generator Block element</span> is the element type used to supply artificially generated data values during runtime. Its purpose is to substitute data inputs which are not yet, or temporarily not available, to enable the user to however run his tests for trial. Each element of this type contains exactly one so-called <span class="KEYWD">Generic Values List</span>, which takes time-value-pairs that are used at runtime to generate each value at its particular generation time and supply it to the output interface.<br />
<br />
=== Including Libraries ===<br />
<br />
Besides the possibility to create Testsuite elements on your own, it is<br />
also possible to integrate existing elements from other Testsuites, simply<br />
by <span class="EMPH">importing</span> them as the contents of a <span class="KEYWD">Library</span>.<br />
These elements can then be used inside your own project in the same manner<br />
as those that you created on your own, but it is <span class="EMPH">not possible<br />
to modify</span> those in-lib elements. The reason for this is to keep the<br />
Librarys version consistent, so changing one of the libs elements is only<br />
possible when working directly inside its project. However, if desired, you<br />
can still make a copy of an in-lib element, and <span class="EMPH">modify<br />
that copy</span> to fit your needs.<br />
<br />
Note that the included Libraries each contain an <span class="EMPH">own</span><br />
Root element, which is <span class="EMPH">distinct</span> from the current<br />
projects Root element. Each of those carries an own Variable Environment,<br />
which is thus valid for all - and only - the elements inside the Librarys<br />
scope.<br />
<br />
By their nature, Libraries are nothing else than Testsuites: a collection<br />
of Testsuite elements. The differences to a practical Testsuite are as regards<br />
content: While the regular Testsuite aims on provision of concretely executable<br />
items, a Library aims on provision of frequently used standard elements.<br />
On the file system, expecco Libraries usually have the "<span class="CODE">.xlib</span>"<br />
suffix, while Testsuites have the "<span class="CODE">.xprj</span>" suffix.<br />
Technically seen, this is the only difference between them, and you can use<br />
both for import, also your own projects. A Testsuite will be named <span class="CODE">.xlib</span><br />
only if the author intended it to be a Library.<br />
<br />
=== Arranging Elements ===<br />
<br />
<br />
Usually, you work with the Testsuite and with its elements using the expecco GUI Browser, which displays the elements inside the <span class="KEYWD">Navigation Tree View</span>. This view displays a tree containing all the elements in an arbitrary hierarchical structure. <span class="EMPH">Arbitrary</span> means that the hierarchical arrangement inside the Tree View does <span class="EMPH">not</span> influence the functionalities of the Testsuite or any of its elements <span class="EMPH">in any way</span>. The only reason to supply a hierarchically arrangeable view for the elements, is to allow the user to group and arrange elements according to his subjective associations.<br />
<br />
Although the arrangement of the elements is technically<br />
arbitrary, some restrictions have been made to the arrangements<br />
possible in the Tree View. The base node of the tree always<br />
is the Root element of the Testsuite. Furthermore, elements<br />
can <span class="EMPH">only</span> be nested directly below<br />
one of the following element types: <span class="KEYWD">Compound<br />
Blocks</span>, <span class="KEYWD">Test Plans</span>, <span class="KEYWD">Packages</span>,<br />
<span class="KEYWD">Libraries</span>, or <span class="KEYWD">Groups</span><br />
(which will all be explained later). Below a Compound Block,<br />
for example, usually other Blocks are placed that are used<br />
only or mainly inside that Compound Block, while below a Test<br />
Plan there might be placed other partial Test Plans or Inventories.<br />
A Group, for example, could serve to embrace a group of Skills<br />
and Resources, or Datatypes and Classes. Apart from these<br />
restrictions, you can arrange your elements by free will.<br />
<br />
Testsuite elements<br />
have <span class="EMPH">names</span>, which serve to make<br />
them distinguishable for the user. The names are a <span class="EMPH">purely<br />
associative feature</span> for the user. The expecco system<br />
does not need them for operation, neither for distinguishing<br />
the elements from each other. Internally, the expecco system<br />
uses other information to do this: Every Testsuite element<br />
has a unique <span class="EMPH">internal ID</span>, which<br />
is not only unique inside the project, but also <span class="EMPH">world<br />
wide</span>. A special algorithm ensures that two elements<br />
that are not identical will <span class="EMPH">never</span><br />
have the same internal ID.<BR><br />
<br />
The user usually<br />
doesn't get in touch with the internal ID, and it is neither<br />
wanted nor possible by normal means of usage in the expecco<br />
system. Thus, the user <span class="EMPH">must</span> use<br />
the associative names to distinguish the elements. Although<br />
it is possible to give the same name to several distinct elements,<br />
this doesnt make much sense, because it will only lead to<br />
confusion for the user: When a element is referenced in<br />
another element's Property Editor, it will be labeled with<br />
the associative name rather than with its ID.<br />
<br />
[[Bild:PIC_Concepts_Projects_TreeComponents.png]]<br />
<br />
=== Element Properties ===<br />
The characteristic contents that make up a element are called the <span class="KEYWD">Element Properties</span>. There are many different types of element properties, but individual element type owns only some of them, according to the kind of element.<br />
<br />
It is important at this point to understand the correct meaning of what is<br />
called "Property" here. A Property in the current context does <span class="EMPH">not</span><br />
mean things like the name, id, or other internal detail. Property here means<br />
a <span class="EMPH">topical unit of information</span> that is characteristic<br />
for the element's <span class="EMPH">purpose</span>, and which is editable<br />
or at least displayable to the user.<br />
<br />
A element never has two properties of the same type, and properties are<br />
never shared between elements, i.e. an element property always belongs<br />
to exactly one element only. When duplicating testsuite elements by copy-paste, the duplicate's properties will initially have the same values, but each of the copies will hold its own,<br />
individual set of properties. (technically, the properties of the pasted elements are<br />
deep copies of the copied one's, so modifying a property of a pasted element<br />
will never affect the properties of the source element or other pasted elements).<br />
<br />
For each element, one or more <span class="KEYWD">element editor pages</span><br />
can be opened in the expecco <span class="KEYWD">GUI Browser</span>. A element<br />
Page contains the <span class="KEYWD">Editors</span> appropriate for the element<br />
to which the Page refers, as depicted in Figure<br />
4.4-2. The GUI Editors are used to access and modify the element Properties,<br />
and for each Property type, there is one specialized Editor. Only one of the<br />
Editors is visible at a time in one Page, but Editors can be switched by using<br />
the rider tags on top of the element Page. Changes on a elements Properties<br />
are accepted or rejected as a whole, so changes in several Editors can be<br />
made before storing its new state. You get detailed information on the GUI<br />
Browser's Page and Editor management in <a href="./DOC_eXpeccoUserGuide_GUI.html#b1f2aa20-f609-11da-9610-0040c7999506">expecco<br />
GUI Documentation/Chapter 3: The GUI Browser Window</a>.<br />
<br />
<br />
Below, you find a list giving a brief<br />
description of each individual Property type, each containing a link to the<br />
explanation of the according GUI Editor that is used to modify the Property.<br />
<br />
===== Documentation Property =====<br />
applies to <span class="EMPH">all</span><br />
element types, <span class="EMPH">except</span> the <span class="KEYWD">Group</span><br />
element. It serves to assign each element an individual documentation<br />
text. Accessing this Property through the GUI is described in<br><br />
the chapter [[expecco GUI Documentation#The Documentation Editor|"The Documentation Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Variable Environment Property =====<br />
applies<br />
to <span class="KEYWD">Project</span>, <span class="KEYWD">Library</span>, <span class="KEYWD">Testplan</span> and <span class="KEYWD">Compound Block</span> elements. It serves to create and preset a scoped variable environment which is then accessible by all subordinated block elements. Accessing this Property through the GUI is described in the chapters [[expecco GUI Documentation#The Testsuite Environment Editor|"The Testsuite Environment Editor"]] and [[expecco GUI Documentation#The Block Environment Editor|"The Block Environment Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Schema Definition Property =====<br />
applies<br />
to <span class="EMPH">all</span> <span class="KEYWD">Block</span><br />
element types. It serves to define the data inputs and outputs<br />
of a block element; i.e. its "outside view" when placed as a step into a network. Accessing this property through the GUI<br />
is described in the chapter [[expecco GUI Documentation#The Schema Editor|"The Schema Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Internal Network Property =====<br />
applies to <span class="KEYWD">Compound Block</span> elements only.<br />
It serves to model the internal workflow of a compound block by<br />
arranging and interconnecting building blocks called <span class="KEYWD">Steps</span> and Connections.<br />
Accessing this property through the GUI is described in the chapter [[expecco GUI Documentation#The Internal Network Editor|"The Internal Network Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
=====Code Content Property =====<br />
applies to <span class="KEYWD">Coded Elementary Block</span> elements only. It serves to contain executable code in a particular programming<br />
language. Accessing this property through the GUI is described<br />
in the chapter [[expecco GUI Documentation#The Program Code Editor|"The Program Code Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
====== Script Content Property ======<br />
applies to <span class="KEYWD">Shell Script and Batch Script Block</span> elements.<br />
It serves to contain script code in an OS dependent scripting<br />
language. Accessing this property through the GUI is described<br />
in the chapter [[expecco GUI Documentation#The Script Code Editor|"The Script Code Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
====== Console Command Property ======<br />
applies to the <span class="KEYWD">Shell/Batch Command Block</span> elements only.<br />
It serves to contain an OS dependent console command. Accessing this property through the GUI is described in the chapter [[expecco GUI Documentation#The Console Command Editor|"The Console Command Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Generic Values List Property =====<br />
applies to <span class="KEYWD">Test Data Generator</span> elements only. It serves to set up a list of typed values, and time<br />
offsets at which those values should be yielded. Accessing this<br />
property through the GUI is described<br />
in the chapter [[expecco GUI Documentation#The Generic Values Editor|"The Generic Values Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Local Test Network Property =====<br />
applies to <span class="EMPH">all</span> <span class="KEYWD">Block</span><br />
elements, <span class="EMPH">except</span> <span class="KEYWD">Test<br />
Data Generator</span> elements. It serves to model and execute<br />
a trial workflow which is held local with the element. Accessing<br />
this property through the GUI is described<br />
in the chapter [[expecco GUI Documentation#The Block Test Editor|"The Block Test Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Skill Requirements Property =====<br />
applies to <span class="EMPH">all</span> <span class="KEYWD">Block</span><br />
elements. It serves to define the set of skills which the block needs for its execution. The resource manager will search for resources which have those skills, allocate and lock them for the execution and finally release them back into the inventory.<br />
Accessing this property through the GUI is<br />
described in the chapter [[expecco GUI Documentation#The Resource Requirement Editor|"The Resource Requirement Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Skill Attributes Property =====<br />
applies to the <span class="KEYWD">Skill</span> element Type only. It serves to define the typed attributes that characterize a Skill object.<br />
Accessing this Property through the GUI is described in the chapter [[expecco GUI Documentation#The Skill Definition Editor|"The Skill Definition Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Resource Definition (Skill Assignments) Property =====<br />
applies<br />
to the <span class="KEYWD">Resource</span> element type only.<br />
It serves to assign one or more Skills to the Resource element<br />
and concretizing them with typed values. Accessing this Property<br />
through the GUI is described<br />
Accessing this Property through the GUI is described in the chapter [[expecco GUI Documentation#The Resource Definition Editor|"The Resource Definition Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Inventory (Resources List) Property =====<br />
applies to<br />
the <span class="KEYWD">Inventory</span> element type only.<br />
It serves to define the set of Resources that the Inventory element<br />
shall contain for disposition on Skill requirement requests. Accessing<br />
this Property through the GUI is described<br />
Accessing this Property through the GUI is described in the chapter [[expecco GUI Documentation#The Inventory Definition Editor|"The Inventory Definition Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Testplan (Test Items List) Property =====<br />
applies to<br />
the <span class="KEYWD">Test Plan</span> element type only.<br />
It serves to set up and arrange a sequence of test items, and<br />
provides the execution wrapper to process that sequence. Accessing<br />
this Property through the GUI is described<br />
Accessing this Property through the GUI is described in the chapter [[expecco GUI Documentation#The Testplan Editor|"The Testplan Editor"]] of the [[expecco GUI Documentation]].<br />
<br />
===== Class Definition Property =====<br />
applies to<br />
the <span class="KEYWD">Class</span> element type only. It serves<br />
to define the programmatic structure of a Class element.<br />
<br />
===== Type Definition Property =====<br />
applies to<br />
the <span class="KEYWD">Datatype</span> element type only. It<br />
serves to select a data type which is not included by default<br />
to be represented by the Datatype element.<br />
<br />
== Workflows and Activity Diagrams ==<br />
<br />
The peculiarity of expecco is the <span class="KEYWD">Workflow Management</span>, which allows the combination of elementary programmatical elements (working steps) into a composite <span class="KEYWD">Workflow</span>. This is done in form of UML-2.0 compliant, so-called <span class="KEYWD">Activity Diagrams</span>. Activity Diagrams consist of building blocks called the <span class="KEYWD">Steps</span>, and of <span class="KEYWD">Connections</span> which interconnect those Steps with each other. Activity Diagrams are <span class="EMPH">data flow driven</span>, which corresponds most to the way in which humans use to think and act: an <span class="EMPH">input</span> is coming in, causing us to perform some particular <span class="EMPH">activity</span>, which in turn yields a resulting <span class="EMPH">output</span>.<br />
<br />
The Steps are depicted as graphical building blocks, which can have so-called <span class="KEYWD">Pins</span>. The Pins serve to <span class="EMPH">interconnect</span> the Steps with each other inside the Activity Diagram. The <span class="KEYWD">Input Pins</span> appear on the left, the <span class="KEYWD">Output Pins</span> on the right side of a building block. Output Pins can be connected to Input Pins by placing <span class="KEYWD">Connections</span> between them.<br />
<br />
In this manner, Steps can interactively be assembled to more complex networks. The likewise created building blocks can then in turn be stored as Compound Block elements, and be used as Steps inside other Workflows again. Like this, complex processes can be graphically modelled and modified in an easily understandable manner, and thus get significantly more transparent, maintainable, and flexible.<br />
[[Bild:PIC_Concepts_Workflows_SymbolicActivityDiagram.png]]<br />
<SPAN class="PICTUREENUM">Figure 5-1: Symbolic depiction of an Activity Diagram, consisting of Steps and Connections</SPAN><br />
[[Bild:PIC_Concepts_Workflows_StepsReferencingComponents.png]]<br />
<SPAN class="PICTUREENUM">Figure 5-2: Steps referencing to Block elements</SPAN><br />
<br />
In an expecco Activity Diagram, Steps are created by drag & drop, i.e. by dragging a Block element from the element Navigation Tree and dropping it to the diagram view of a Workflow Editor. <a href="#15846120-1237-11db-a24a-0040c7999506">Figure 5-2</a> shows the relations between the Steps and the according Block elements: Every Step is referencing <span class="EMPH">exactly one</span> Block element, but multiple Steps can reference the <span class="EMPH">same</span> Block element. Connections are each referencing exactly <span class="EMPH">one</span> Input Pin and exactly <span class="EMPH">one</span> Output Pin.<br />
<br />
Steps are <span class="EMPH">representation instances</span> of Block elements. The Steps themselves are not part of the Testsuite elements. While a Block element is a <span class="KEYWD">Testsuite element</span> that exists exactly one time throughout the Testsuite, the Step instances (as well as the Connections) are <span class="KEYWD">Workflow elements</span>. When a Block element is modified, the changes affect all Steps that reference that Block, also those that have been instantiated before the modification.<br />
=== Data Flow Driven Execution ===<br />
<br />
<span class="KEYWD">Data flow driven execution</span> means that the invocation of a Step takes place in the moment when the data that is required for execution is present. When invoked, the Step takes the required portion of data from the inputs and launches an <span class="KEYWD">Activity</span> instance that uses those data. Input data can be buffered on the Step's inputs, and on invocation, the Step only fetches the first value from each input, leaving the rest of the queue in the buffer for subsequent invocations.<br />
<br />
One of the big advantages of this approach is that you never have to directly implement the creation of Activity instances; this is done <span class="EMPH">implicitly</span> at runtime by passing the input values to the Step. Please keep in mind that invoking a Step does <span class="EMPH">not</span> mean that the Step <span class="EMPH">itself</span> is running. The Step inside the Activity Diagram only serves as a value collector and buffer, and as a <span class="EMPH">spawning point</span> for its Activities.<br />
<br />
<a href="#47e3a0e0-10ca-11db-a24a-0040c7999506">Figure 5.1-1</a> symbolically displays the data flow driven execution principle for a Step instance, which for a better overview is isolated from its surrounding Activity Diagram:<br />
<br />
The Step is present inside of some Workflow, acting as a spawning point for its Activities. The Step has a data input interface in form of Input Pins to the left, and a data output interface in form of Output Pins to the right.<br />
<br />
The Input Pins successively receive input data values, buffering them in a queue on the according Input Pin. Input values are collected and never consumed unless an Activity is launched. As long as not all of the Input Pins relevant for execution obtain a value, no Activity is launched by the Step.<br />
<br />
When the set of required values is complete, the Step initializes a new Activity instance for execution. The Activity is created, but not instantly executed. Note that the Activity object is an internal object of the expecco Execution Engine, which is never displayed inside the Activity Diagram.<br />
<br />
The Step fetches the data values available on the Input Pins, but only the very first value from every Pin. This set of values is then assigned to the input values of the newly spawned Activity. The other values remain inside the buffering queue, advancing one position in the queuing sequence. E.g., a value that was second in the Pin's queue will advance to first, a third value to second, etc. In addition, the Step sets a reference to itself inside the Activity object, so the Activity knows by which Step instance it had been spawned.<br />
<br />
Finally, the spawned Activity is beginning execution, thereby being able to access the values that were previously assigned to it by the Step as a set of values. The Activity operates on the input data and possibly generates new output data, which it can assign to the Step's Output Pins using the previously registered reference to the Step object. The values are then passed to further Steps that are connected to this Step's Output Pins. Although only a fixed set of input values is available to the Activity, it can produce an arbitrary number of output values, provided that at least one Output Pin exists for the Step.<br />
<br />
[[Bild:PIC_Concepts_Workflows_DataflowControl.png]]<br />
<SPAN class="PICTUREENUM">Figure 5.1-1: The data flow driven execution principle</SPAN><br />
[[Bild:PIC_Concepts_Workflows_MultipleActivities.png]]<br />
<SPAN class="PICTUREENUM">Figure 5.1-2: A Step having spawned multiple concurrently running Activities</SPAN><br />
<a href="#cc9ce4a0-117d-11db-a24a-0040c7999506">Figure 5.1-2</a> shows what to understand under the term "<span class="KEYWD">Parallelism</span>": Steps can spawn new Activities regardless of the execution state of any previously spawned Activities, assumed that parallelism is enabled. Activities spawned by the same Step can execute concurrently without directly influencing each other.<br />
<br />
However, it is important to take into account that the output values, generated by different Activities spawned from the same Step, will be passed to the <span class="EMPH">identical</span> Output Pins of that very Step. The order in which the output data values will appear on the Step's Output Pins depends on the points of time when they are yielded. It is possible to <span class="EMPH">limit</span> parallelism individually for each single Step instance, without influencing any other Step referencing to the same Block element.<br />
<br />
The next thing that is important to be considered in this context is the way output values are passed along the Connections. In principle, any number of Connections can be assigned to a Pin, irrespectively whether it is an Input or Output Pin.<br />
<br />
When an Output Pin has more than one Connection, a value that is yielded on that Output Pin will be copied once for each of the Connections, and one copy is then passed along each Connection. This means that every Input Pin of a Step which is connected to this Output Pin, will receive its individual copy of the yielded value.<br />
[[Bild:PIC_Concepts_Workflows_MultipleOutputConnections.png]]<br />
<SPAN class="PICTUREENUM">Figure 5.1-3: A Step passing an Activity's output value to multiple connected Steps</SPAN><br />
=== The Schema Definition ===<br />
<br />
Every building block inside an expecco Activity Diagram is characterized by its <span class="EMPH">input and output interface</span>, which is specified in its associated Block element's <span class="KEYWD">Schema Definition</span> Property. The Schema Definition consists of an ordered set of <span class="KEYWD">Input</span> and <span class="KEYWD">Output Pin Definitions</span>. Note that it does <span class="EMPH">not</span> consist of Pins directly, because Pins occur on a <span class="KEYWD">Step</span> instance only. The Block element, meanwhile, just holds the Pins' <span class="EMPH">definitions</span>.<br />
<br />
According to the black-box concept, the internal implementation of the Block is irrelevant for the integration into a Workflow. You can even embed Steps of a Block which internally is not implemented at all, and make up for the implementation at a later point of time (top-down creation). Meanwhile, you can already use the Block to instantiate Steps in a Workflow, because the data flow interface is already specified. <a href="#cfbea310-0b53-11db-a24a-0040c7999506">Figure 5.2-1</a> shows two exemplary Schema Definition depictions as they appear in the according Editor in the expecco GUI Browser:<br />
<br />
To the left, the <span class="KEYWD">Input Pins</span> are specified, the <span class="KEYWD">Output Pins</span> to the right. Every Pin is assigned a <span class="KEYWD">Datatype</span>, which is displayed as a keyword directly besides each Pin, and which determines the kinds of values that can be received, or transmitted, respectively. Each Pin can be given a textual <span class="EMPH">name</span>, which is not only used to describe its purpose for the user, but also serves as the <span class="EMPH">referencing name for value access</span> from inside a Code Block's or Shell Script Block's code.<br />
<br />
There are some few Block types that have restrictions on creating or removing Pins: The Shell Script Block and Shell Command Block elements have fixed Pins that can't be modified at all, and the Data Generator Block allows creation of Output Pins only. For all other Block elements, Pins can be freely edited.<br />
<br />
[[Bild:PIC_Concepts_Workflows_Basical_Schemes.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.2-1: Two exemplary Schema Definitions as they appear in the expecco Schema Editor</SPAN><br />
<br />
In addition, with the small grey box to the left, an <span class="KEYWD">Triggering Condition Type</span> can be selected. The gating type determines in which way the presence of input values should be evaluated to decide when a Step spawns an Activity: <span class="MENU">AND</span> gating requires <span class="EMPH">all</span> consuming inputs to have a value, <span class="MENU">OR</span> gating requires <span class="EMPH">one or more</span> consuming inputs to have a value, and <span class="MENU">ANDConnected</span> gating requires <span class="EMPH">all connected</span> consuming inputs to have a value.<br />
<br />
[[Bild:PIC_Concepts_Workflows_Basical_Network.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.2-2: An exemplary Activity Diagram as it appears in the expecco Workflow Editor</SPAN><br />
<br />
When the Schema is defined, Step instances of the according Block elements can be placed into Activity Diagrams, and interconnected, as depicted in <a href="#fdfe3c90-0b53-11db-a24a-0040c7999506">Figure 5.2-2</a>. The expecco Workflow Editor displays not only the Pins, but also their names inside the building block.<br />
<br />
A special type of Pin is available only inside the Activity Diagrams: The various Trigger Pins, used for sequencing, interrupting, limiting or delaying Activity executions. The Trigger Pins are individually switched on or off for each Step instance, and no parameters can be defined for them in the Schema Definition.<br />
<br />
In the Schema Editor, additional configuration features are available for the Pins. For example, you can supply a preset value to a Pin, limit the value buffer, set several modes, etc. These settings for the Data Pins are called the <span class="KEYWD">Default Pin Configurations</span> of the Block, which allow the user to assign <span class="EMPH">default values</span> to the parameters of each Pin Configuration.<br />
<br />
[[Bild:PIC_Concepts_Workflows_SchemaDefinition_PinSpecials.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.2-3: Appearance of frozen value, unbuffered Output Pin, and non-consuming Input Pin</SPAN><br />
<br />
Every Step uses the Default Pin Configuration of its Block, which, however, can be locally overwritten inside an Activity Diagram. The Pin Configuration settings affect only the behavior of Steps to the outside, it does not affect the internal functionality of a Block or any of its Steps. The below list gives an overview on the adjustable features:<br />
<br />
To assign a globally fixed value to an Input Pin, the Pin can be <span class="KEYWD">frozen</span> to that value. A frozen Pin always acts as if the specified value had been received, which is fetched on Activity spawn, but never consumed. When freezing a Pin, a text field is displayed besides it, containing a textual representation of the fixed value. Frozen Input Pins cannot be connected to any Output Pins, and are not taken into account by the Triggering Condition of its Step.<br />
<br />
Similar to freezing a Pin to a constant value, Input Pins can also be frozen to an <span class="KEYWD">Environment Variable</span>. While a directly assigned value never changes during runtime, an Environment Variable may change its contents. When a Pin is frozen to an Environment Variable, a spawned Activity will get its current value that it holds in the moment of the Activity's creation.<br />
<br />
You can set a limit for the <span class="KEYWD">Basket Buffer size</span> for each Input Pin. The implicit default value for this setting is unlimited. The purpose of this setting is to limit the number of values that can be queued on an Input Pin. When the limit is reached, no further values are taken into the queue from any delivering Connection. Depending on the mode of the Output Pin that sent the value, this can cause the yielding Step to cease execution until the value has been removed from the Connection.<br />
<br />
For each Input Pin, you can toggle between <span class="KEYWD">consuming</span> and <span class="KEYWD">non-consuming</span> mode. When a consuming Pin obtains a value, this value is taken away from the input queue. A non-consuming Pin leaves the value at the first queue position. Since non-consuming Input Pins would trigger forever, they are implicitly excluded from the Trigger Gating. Consuming Input Pins are displayed as hollow square boxes, while non-consuming Input Pins are displayed as solid squares.<br />
<br />
For each Output Pin, you can toggle between <span class="KEYWD">buffered</span> and <span class="KEYWD">unbuffered</span> mode. An unbuffered Output Pin will send a written value <span class="EMPH">immediately</span> to the connected target Pins, while a buffered Pin collects all written values in a <span class="EMPH">queue</span>, which will finally be sequentially sent, but only if the Activity terminates successfully. Buffered Output Pins are displayed as hollow square boxes, while unbuffered Pins are displayed as solid squares.<br />
<br />
The Editor used by the expecco GUI Browser to edit Schema Definitions is described in detail in<br> <a href="./DOC_eXpeccoUserGuide_GUI.html#179d0da0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.5: The Schema Editor</a>.<br />
<br />
=== Using Activity Diagrams ===<br />
<br />
A <span class="KEYWD">Workflow</span> consists of three basical elements: <span class="KEYWD">Steps</span> which have <span class="KEYWD">Pins</span>, and <span class="KEYWD">Connections</span> that interconnect the Pins. The <span class="KEYWD">Activity Diagram</span> displays these elements, and allows the user to arrange and modify them. Steps are displayed as <span class="EMPH">building blocks</span> with the according set of <span class="EMPH">graphical endpoints</span> for the Pins, and Connections are displayed as <span class="EMPH">lines</span> between the Pins endpoints.<br />
<br />
This chapter describes how Activity Diagrams are structured, and which features apply to the distinct modeling elements. Because the features are numerous, each topical issue is discussed in an individual subchapter. A description of the Editor used to handle Activity Diagrams is available under<br> <a href="./DOC_eXpeccoUserGuide_GUI.html#18c89550-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.10: The Workflow Editor</a>.<br />
<br />
==== The Interface Pins ====<br />
<br />
There are two types of Workflow Editors in the expecco system, which are almost the same. The only difference between these two variants is that the one type supplies <span class="KEYWD">Interface Pins</span> to the Activity Diagram, while the other one does not. The reason for this is the different purpose of the two variants:<br />
<br />
The first variant, called the <span class="KEYWD">Local Test Editor</span>, applies to all Block elements, to Elementary Blocks as well as to Compound Blocks. Its purpose is to allow the user to model one trial network for each Block element, which is kept individually by that element. It supplies a <span class="KEYWD">Test Wrapper</span> object, which embeds the Workflow defined in this editor. Since the Test Wrapper object has no input or output interface, no External Pins are needed.<br />
<br />
The second variant, called the <span class="KEYWD">Internal Network Editor</span>, is the one that supplies External Pins to the diagram, which represent the <span class="KEYWD">Interface Pins</span> of the Block. It is only available for Compound Blocks, which hold an <span class="KEYWD">Internal Workflow</span> Property. These Pins are the Interface Pins of the according Schema Definition of the Block. The Blocks Input Pins are displayed on the left side of the Activity Diagram, and act like Output Pins inside of it. Vice versa, the Blocks Output Pins are displayed to the right, and act like Input Pins inside the Diagram. <a href="#e8a5c2b0-1561-11db-9ca4-0040c7999506">Figure 5.3.1-1</a> shows a Compound Block's Interface Pins, as defined in the Schema Definition, appearing as External Pins in the Internal Workflow's Activity Diagram.<br />
<br />
[[Bild:PIC_Concepts_Workflows_ActivityDiagrams_InterfacePins.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.3.1-1: A Compound Block's Interface Pins in the Internal Workflow's Activity Diagram (schematic)</SPAN><br />
<br />
Note that inside the Activity Diagram, the Interface Pins have the opposite<br />
behavior as when used from the outside: The Input Interface Pins behave as<br />
Output Pins (because they pass the incoming values from the outside to the<br />
Workflow), and the Interface Output Pins behave as Input Pins (because they<br />
pass the outgoing values from the Workflow to the outside).<br />
<br />
Also note that Interface Pins can also be added and deleted directly inside<br />
this Editor, without first having to switch to the Schema Editor. The Interface<br />
Pins' settings can also be edited directly from within the Internal Network<br />
Editor, the context menu for the Interface Pins supplies the identical functionality<br />
as it does in the Schema Definition Editor. However, frozen values are not<br />
displayed here, and the Triggering Condition Type can't be modified from here<br />
either.<BR><br />
<br />
==== Arranging Steps ====<br />
<br />
Steps can be added to the Workflow in several ways. The most usual way is to select a Block element in the <span class="KEYWD">element Navigation Tree</span>, and to simply <span class="EMPH">drag</span> its symbol into the Activity Diagram Area. This creates a new Step instance in the Workflow, which is then depicted as a <span class="EMPH">building block</span> with the appropriate Pins in the Activity Diagram. Such a new Step initially has the Pin Configuration specified in the Block's Schema Definition.<br />
<br />
[[Bild:PIC_Concepts_Workflows_CreatingSteps.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.3.2-1: Initial Step Creation by Drag & Drop</SPAN><br />
<br />
Another possibility to create Step instances is first to <span class="EMPH">copy</span> an existing Step instance, and then <span class="EMPH">paste</span> it into the same or into another Activity Diagram. Multiple Steps can also be copied at once, and can be pasted as a whole. It is not possible to copy and paste single Connections, but when copying multiple Steps at a time, the Connections which are between them are also copied. This allows to copy and paste <span class="EMPH">complete sub structures</span> of existing Workflows, including all Connections comprised.<br />
<br />
[[Bild:PIC_Concepts_Workflows_MovingSteps.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.3.2-2: Positioning Steps</SPAN><br />
<br />
The building blocks can be <span class="EMPH">moved around</span> solely or in groups inside the Activity Diagram. To do so, one or more building blocks are selected, and then dragged to a different location with the mouse. Connections that are inbetween two of the moved building blocks will be moved directly with them, Connections between moved and non-moved building blocks will be rerouted automatically.<br />
<br />
To create a <span class="KEYWD">Connection</span> between two Pins, you simply click on one of the Pins, and drag the mouse pointer to the other one. This creates a Connection object in the Workflow which is then displayed as an angled line between the Pins in the Activity Diagram.<br />
<br />
Note that you can only interconnect a Data Input Pin to a Data Output Pin, or also a Data Output Pin to some kinds of Trigger Input Pins, depending on the Datatype the Trigger Input Pin expects. A Data Pin Connection can <span class="EMPH">only</span> be created when the Pins' Datatypes are <span class="EMPH">compatible</span>. Usually, you will connect Data Pins which have the <span class="EMPH">identical</span> Datatype adjusted, but there are some special cases where other combinations are possible: Pins holding the "<span class="CODE">Any</span>" Datatype can always be connected to any other Pin (presumed the valid direction), regardless of the Datatype adjusted at the other Pin. In addition, some Datatypes may address different subtypes of itself, like the "<span class="CODE">Number</span>" Datatype, which allows connections to all Pins holding the "<span class="CODE">Number</span>", "<span class="CODE">Integer</span>", or "<span class="CODE">Float</span>" Datatype.<br />
<br />
[[Bild:PIC_Concepts_Workflows_CreatingConnections.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.3.2-3: Creating Pin Connections</SPAN><br />
<br />
A more sophisticated way to create new Steps is the possibility to either create new Compound Blocks out of existing Step structures of a Workflow, or to expand the Step structure inside a Compound Block from an existing Step of that Block. In both cases, the selected Steps are removed, and replaced with the according substitute:<br />
<br />
When <span class="EMPH">combining</span> Steps, a new Compound Block is created which obtains the selected sub structure as its Internal Workflow, providing a masking Interface Pin for each Pin of the former sub structure that was connected to Pins not comprised in that sub structure. The structure is substituted with a new Step instance of the new Block, and the semi-internal Connections are replaced with Connections to or from the masking Interface Pins. This keeps the connective functionality unchanged, so no further corrections are necessary.<br />
<br />
When <span class="EMPH">expanding</span> a Step, no new Block elements are generated. Only Steps that refer to Compound Blocks can be expanded. The Step is removed and replaced by a copy of the according Compound Block's Internal Workflow. The complete Workflow is copied, including all internal Connections between the Steps. Connections to the Interface Pins of the expanded Block are replaced by Connections to those Pins of the target Workflow that previously were connected to the substituted Step.<br />
<br />
==== Step Configurations ====<br />
<br />
Inside a Workflow, every Step has an individual <span class="KEYWD">Step Configuration</span>. This comprises the <span class="KEYWD">Local Step Configuration</span> for the parameters directly related to the Step instance object, and a set of <span class="KEYWD">Local Pin Configurations</span>, which hold overdubbing parameters for each of the Data Pins. The Step Configuration can be edited inside the Activity Diagram, using the functions provided by the appropriate context menus.<br />
<br />
Every Step inside a Workflow holds its individual set of <span class="KEYWD">Local Pin Configurations</span>, which comprise a set of parameters for each of the Pins. In the Schema Definition of a Block, the <span class="KEYWD">Default Pin Configurations</span> for those parameters are specified, which are initially applied to every new Step instance. The Steps local Pin Configuration starts as an empty Pin Configuration, which can then be filled individually. When local settings are applied to a Data Pin, they <span class="EMPH">overdub</span> the Blocks according Default Pin Configuration settings, without affecting any of the other Steps in any Workflow. When changes are made to the Block's Schema Definition, those are immediately affecting all according Step instances, but however the individual local Pin Configuration remains in effect.<br />
<br />
The Schema Editor allows editing of the Triggering Condition Type, the Data Pin Definitions, and the Default Pin Configurations<br />
(left column). The Workflow Editor allows, for each Step, editing of the Local<br />
Step Configuration and the Local Pin Configurations (center column). The effective<br />
Step Configuration is then assembled like this:<br><br />
# The <span class="EMPH">effective Gating Type</span> is taken directly from the Schema Definition of the Step's Block;<br />
# The <span class="EMPH">effective Step Configuration</span> is taken directly from the Step Definition in the Workflow;<br><br />
#The <span class="EMPH">effective Pin Configurations</span> are first taken from the Default Pin Configurations of the Schema Definition, but are then overdubbed with the values from the Local Pin Configurations given in the Step Definition of the Workflow.<br />
<br />
The Effective Step Configuration determines how input and output values are handled, and under wchich conditions Activities are spawned. The following two paragraphs give an overview on the settings comprised int the Local Step Configuration and the Local Pin Configuration; all of the mentioned Step specific options are accessible through the Step's Context Menu, as described in <a href="./DOC_eXpeccoUserGuide_GUI.html#f46d3890-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.10.4: Step Specific Options (Context Menu)</a>.<br />
<br />
The <span class="KEYWD">Local Step Configuration</span> comprises parameters that are directly related to the Step object. Because a Step is a <span class="KEYWD">Workflow element</span>, the only possibility to edit these settings in the GUI is through the Workflow Editor for the Workflow object that contains the Step. The following list gives an overview on the adjustable settings:<br />
<br />
Steps can (but dont have to) carry individual <span class="KEYWD">names</span>. If no name is set for the Step, the headline of the according building block will display the name of the Block only. If a name is set, it is displayed first, followed by a colon and the Blocks name. Like with the Block elements, the name of a Step is a <span class="EMPH">purely organizational feature</span> for the user. The expecco system doesnt need the names for operation, instead it uses unique internal IDs.<br />
<br />
Every Step inside a Workflow can be assigned the <span class="KEYWD">Autostart</span> option. Steps with this option on are started automatically each time the Workflow is executed. This is useful to initially invoke certain Steps which are at the beginning of the data flow, or to invoke Steps that have no Input Pins or are intended to run with frozen input values.<br />
<br />
For trial runs that shall overrun certain Exceptions, an <span class="KEYWD">Ignore Exceptions</span> mode is available for each Step. When this option is on, exceptions will be ignored and not lead to a failure signal at runtime.<br />
<br />
The <span class="KEYWD">Parallelity Limit</span> option is used to adjust a maximum number for the Activities executed in parallel. When this parameter is set to a number, only that number of Activities will be executed, while later Activities will be created, but not executed until other executing Activities of that Step finish their execution. The created Activities are held on a special stack and are fetched for execution in the sequence of their creation.<br />
<br />
The <span class="KEYWD">Separate Process</span> option allows to give every Activity spawned by this Step an own individual OS process.<br />
<br />
The functionality of a <span class="KEYWD">Local Pin Configuration</span> is exactly the same as for the <span class="KEYWD">Default Pin Configuration</span>, which is accessible in the Schema Editor. The overdubbing mechanism works on a per-parameter level: When a parameter is set to a value in the Local Pin Configuration, then this value is taken into account for the <span class="KEYWD">Effective Pin Configuration</span>. Parameters for which no value is specified in the Local Pin Configuration will be assigned the value that is given in the Default Pin Configuration. The Pin Configuration affects only the Step's behaviour towards the comprising Workflow, but does <span class="EMPH">not</span> affect the internal functionality. There are four settings for Input Pins, and one setting for Output Pins:<br />
<br />
To assign a globally fixed value to an Input Pin, the Pin can be <span class="KEYWD">frozen</span> to that value. A frozen Pin always acts as if the specified value had been received, which is fetched on Activity spawn, but never consumed. When freezing a Pin, a text field is displayed besides it, containing a textual representation of the fixed value. Frozen Input Pins cannot be connected to any Output Pins, and are not taken into account by the Triggering Condition of its Step.<br />
<br />
Similar to freezing a Pin to a constant value, Input Pins can also be frozen to an <span class="KEYWD">Environment Variable</span>. While a directly assigned value never changes during runtime, an Environment Variable may change its contents. When a Pin is frozen to an Environment Variable, a spawned Activity will get its current value that it holds in the moment of the Activity's creation.<br />
<br />
You can set a limit for the <span class="KEYWD">Basket Buffer size</span> for each Input Pin. The implicit default value for this setting is unlimited. The purpose of this setting is to limit the number of values that can be queued on an Input Pin. When the limit is reached, no further values are taken into the queue from any delivering Connection. Depending on the mode of the Output Pin that sent the value, this can cause the yielding Step to cease execution until the value has been removed from the Connection.<br />
<br />
For each Input Pin, you can toggle between <span class="KEYWD">consuming</span> and <span class="KEYWD">non-consuming</span> mode. When a consuming Pin obtains a value, this value is taken away from the input queue. A non-consuming Pin leaves the value at the first queue position. Since non-consuming Input Pins would trigger forever, they are implicitly excluded from the Trigger Gating. Consuming Input Pins are displayed as solid square boxes, while non-consuming Input Pins are displayed as hollow squares.<br />
<br />
For each Output Pin, you can toggle between <span class="KEYWD">buffered</span> and <span class="KEYWD">unbuffered</span> mode. An unbuffered Output Pin will send a written value <span class="EMPH">immediately</span> to the connected target Pins, while a buffered Pin collects all written values in a <span class="EMPH">queue</span>, which will finally be sequentially sent, but only if the Activity terminates successfully. Buffered Output Pins are displayed as solid square boxes, while unbuffered Pins are displayed as hollow squares.<br />
<br />
==== Triggering Condition ====<br />
<br />
<span class="KEYWD">Triggering Condition</span> denotes the <span class="EMPH">rule</span> that determines <span class="EMPH">when to invoke</span> a Step. Invoking a Step means spawning an Activity, and comprises creating it, supplying it with the appropriate input values, and putting it to the Activity execution queue. According to the <span class="EMPH">dataflow driven</span> concept of Activity Diagrams, the decision <span class="EMPH">when</span> this is done is usually made referring to the Input Pins' <span class="EMPH">value occupancies</span>.<br />
<br />
Depending on the <span class="KEYWD">Gating Type</span>, which can be adjusted in the Schema Editor, and on the effective <span class="KEYWD">Input Pin Configurations</span>, the <span class="EMPH">presence of input values</span> on certain Input Pins decides about the readiness of the Step for being invoked. However, one more input plays a role in this decision: The <span class="KEYWD">Enable Trigger Input Pin</span>, if activated, also has to obtain a value before the Activity instance can be initialized.<br />
<br />
In an executing Workflow, the system cyclically performs an <span class="EMPH">occupancy evaluation</span> on each of the Workflow's Step instances, which analyzes the value occupancies of the Data Input Pins according to the adjusted Triggering Condition Type. When the relevant occupancies meet the Gating Type's demands, and the Enable Trigger - if activated - also holds a value, the Step will initialize a new Activity instance.<br />
<br />
There is one parameter inside the effective <span class="KEYWD">Input Pin Configuration</span> that plays a role in the evaluation of value occupancies: The <span class="KEYWD">non-consuming/non-triggering</span> mode of the Pin, which can be adjusted in the Schema Editor, and overdubbed for each Step in the Workflow Editor. When this option is off, the occupancy of the according Pin is relevant for the evaluation. If not, the occupancy of that Pin is not taken into account.<br />
<br />
Non-consuming inputs are intended to have <span class="EMPH">parametric behaviour</span>. In the terms of Activity Diagrams, this means that the value is not taken from the input queue of the Pin, instead each Activity obtains an individual copy of the value. Like this, the parametric value has to be supplied <span class="EMPH">only once</span> (e.g. by another Step that yields the value on an Output Pin), instead of having to supply it for each invocation. Also, no queue is present for the input values, instead the current value is replaced by a new one as soon as the new value is received by the Pin.<br />
<br />
There are three Gating Types available, of which one can be selected at a time, and which is valid for all Steps of the according Block. The most simple one is the <span class="MENU">Or</span> function, which requires <span class="EMPH">only one of the consuming Pins</span> to have a value. The second one, the <span class="MENU">And</span> function, requires <span class="EMPH">all of the consuming Pins</span> to have a value. The third one, the <span class="MENU">AndConnected</span> function, requires <span class="EMPH">all of the connected consuming Pins</span> to have a value; Pins that are not connected are <span class="EMPH">not</span> taken into account. With this function, Pins can remain unconnected, while the <span class="MENU">And</span> function in contrast would cause the Step <span class="EMPH">never</span> to be invoked if one consuming Pin was unconnected. Since the <span class="MENU">AndConnected</span> function is most typically used, it is initially selected in new Block's Schema Definitions.<br />
==== Introducing Triggers ====<br />
<br />
Triggers are a means for <span class="KEYWD">synchronisation</span> of Steps in a Workflow Chart. They allow execution gating and intentional serialization, as well as conditional and timelimit dependent canceling. Although regarded theoretically, everything of these could also be done by using only the Data Input/Output Pins, the use of Triggers facilitates handling and structuring of the Workflow, and improves associative overview of the Workflow Chart.<br />
<br />
<span class="KEYWD">Trigger Pin Connections</span> are handled in a very similar manner as the Data Pin Connections, and all that is said about the wiring options and display properties of those Connections also applies to the Trigger Pin Connections. Trigger Pins can be selected in the same way as Data Pins are selected, and they use the same Context Menu, although differing in the availability of some entries.<br />
<br />
There are five kinds of Trigger Pins, which can be activated and deactivated individually for each Step. The picture to the right shows a sample Step having <span class="EMPH">all possible</span> Trigger Pins activated. All Trigger Pins can be activated and deactivated through the Step's Context Menu.<br />
<br />
[[Bild:PIC_GUI_EditorDetail_WorkflowTriggersShowAll.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.3.5-1</SPAN><br />
<br />
On top of the representation box, you see three possible <span class="KEYWD">Trigger Input Pins</span>, which are (from left to right) the <span class="KEYWD">Enable-Input</span>, the <span class="KEYWD">Cancel-Input</span>, and the <span class="KEYWD">Timelimit-Input</span> trigger pin. At its bottom, you see the two possible <span class="KEYWD">Trigger Output Pins</span>, called (from left to right) the <span class="KEYWD">Enable-Output</span>, and the <span class="KEYWD">Exception-Output</span> trigger pin. Most often used is the <span class="KEYWD">Enable-Input/-Output</span> pin pair. Its major use is to determine the activation sequence of (in regard to synchronisation) equitable Steps, or to trigger execution of trailing activities when a superposed activity has finished. The other pins usually serve for exception handling and conditional branching.<br />
<br />
Here are some abstract examples for the typical use of the different triggers:<br />
<br />
[[Bild:PIC_GUI_EditorDetail_WorkflowTriggersSampleSerial.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.3.5-2</SPAN><br />
<br />
To the left, you can see a typical serialization sequence use case. Notice the two Connections between the <span class="KEYWD">Enable-Trigger</span> pins, the second one selected (red).<br />
<br />
However all of the Steps have their inputs supplied with values, only the first Step is launched immediately; when it is finished, it sends an Enable-Trigger signal to the second Step, which is thereupon launched, and when it is finished, it triggers the third Step in turn.<br />
<br />
It is possible to automatically serialize Steps with Enable-Triggers, by multiselecting the Steps to be involved, and from the Context Menu, choosing the "<span class="MENU">Sequential Execution</span>" option. This creates the needed Trigger Pins and Connections to build an expectedly sequence.<br />
<br />
To the right, you can see some typical canceling / exception handling use cases. To the beginning, all of the Steps are launched at the same time, when getting the Data Input value.<br />
<br />
In the case that the first Step fails, its <span class="KEYWD">Exception-Output</span> pin sends a triggering signal to the <span class="KEYWD">Cancel-Input</span> pin of the second Step, causing it to immediately stop execution (if still running), while the third Step would continue execution normally.<br />
<br />
If the first Step is terminating successful, however, no signal is sent along the Exception-Output pin, and the second Step would continue execution normally. Instead, an Integer value from a regular Data Output pin would be transmitted to the third Step's <span class="KEYWD">Timelimit-Input</span>, which would then cancel the third Step after that number of seconds.<br />
<br />
[[Bild:PIC_GUI_EditorDetail_WorkflowTriggersSampleCancel.png]]<br />
<br />
<SPAN class="PICTUREENUM">Figure 5.3.5-3</SPAN><br />
<br />
Trigger Inputs can not only be connected to Trigger Outputs, but also to Data Outputs in some cases, and Trigger Outputs can be connected to Trigger Inputs as well as to Data Inputs in some cases. The following lineup will discuss the possibilities of each trigger type in detail:<br />
<br />
The <span class="KEYWD">Enable-Input Pin</span> can be connected to any Trigger or Data Output Pin. There are no restrictions to the Output Pin's Datatype, neither to its buffering state. The Enable-Input Pin will trigger the Step-internal enable flag each time a value is received, but the value itself will not be used. Thus, the Datatype is not relevant.<br />
<br />
The <span class="KEYWD">Cancel-Input Pin</span> can be connected to any Trigger or Data Output Pin. There are no restrictions to the Output Pin's Datatype, neither to its buffering state. The Cancel-Input Pin will cancel the execution of any Activities launched from its Step each time a value is received, but the value itself will not be used. Thus, the Datatype is not relevant.<br />
<br />
The <span class="KEYWD">Timelimit-Input Pin</span> can only be connected to Data Output Pins of a numeric Datatype (<span class="CODE">Integer</span>, <span class="CODE">Float</span>, or <span class="CODE">Number</span>), or given a preset value of one of those Datatypes. It cannot be connected to the Trigger Output pins. When a value is received, the Timelimit-Input Pin will wait for that number of seconds, and after that it will cancel the execution of any Activities launched from its Step.<br />
<br />
The <span class="KEYWD">Enable-Output Pin</span> can only be connected to the Enable-Input and Cancel-Input pin. It sends a trigger signal each time an Activity launched by the Step finishes execution successfully. It is also possible to connect it to a Data Input pin of type "<span class="CODE">Any</span>", but for the average user, this option makes no sense. The usual intention is to use it only with Trigger Input pins.<br />
<br />
The <span class="KEYWD">Exception-Output Pin</span> can only be connected to the Enable-Input and Cancel-Input pin. It sends a trigger signal each time an Activity launched by the Step finishes execution with failure. It is also possible to connect it to a Data Input pin of type "<span class="CODE">Any</span>", but for the average user, this option makes no sense. The usual intention is to use it only with Trigger Input pins.<br />
<br />
All Trigger Pins can be activated and deactivated through the Step's Context Menu, as described in <a href="./DOC_eXpeccoUserGuide_GUI.html#f46d3890-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.10.4: Step Specific Options (Context Menu)</a>.<br />
<br />
==== Workflow Execution ====<br />
<br />
Although the Internal Workflow of a Compound Block is modeled inside the <span class="KEYWD">Internal Network Editor</span>, this Editor does <span class="EMPH">not</span> supply any direct execution mechanisms for that Workflow. Instead, the <span class="KEYWD">Local Test Editor</span> is used for modeling trial situations for a particular Block. In the Local Test Editor, Steps of arbitrary Blocks can be combined to a separate Workflow, which can then be executed directly from within that editor. The reason for this extra editor is obvious: While the Internal Network Editor is <span class="EMPH">only</span> intended for the <span class="EMPH">definition</span> of the <span class="KEYWD">Internal Workflow Property</span> of a Compound Block, the Local Test Editor allows to model <span class="EMPH">independent trial Workflows</span>, which dont affect the Block's own behavior, and which in addition are also available to Elementary Blocks.<br />
<br />
In the expecco GUI, there are only two possibilities to execute Workflows: One is through the <span class="KEYWD">Local Test Editor</span>, the other is through the <span class="KEYWD">Test Plan Editor</span>. What both execution models have in common is the <span class="KEYWD">Test Wrapper</span> object. It encapsulates the Workflow to be executed, and serves as the starting point which receives the user's control signals. During execution, Activity Logs are created and kept for later evaluation. In the case of Test Plan executions, the Test Wrapper contains the implicitly generated Workflow as its Internal Workflow Property.<br />
<br />
The difference between these two possibilities is, that the Local Test Editors Test Wrapper directly <span class="EMPH">wraps the trial Workflow</span> which has been modeled in its Activity Diagram, while the Test Plan Editors Test Wrapper <span class="EMPH">wraps a sequence of implicit Steps</span>. The Test Plan Editor does not supply an Activity Diagram. Instead, when a Test Plan is executed in this editor, the according Steps are <span class="EMPH">implicitly created</span>, and automatically sequenced by Enable Triggers. This causes the sequence to stop when one of the spawned Activities fails on execution.<br />
<br />
There are two different events that can cause a Step to initialize an Activity: The first is the <span class="KEYWD">Autostart option</span>, which can be set as a Step Configuration parameter inside the according Activity Diagram. When the Autostart option is set for a Step, the Step will initialize exactly one Activity instance each time the comprising Workflow is beginning an execution. The second is the <span class="KEYWD">Input Pin Evaluation</span>, which analyzes the value occupancies of the Data Input Pins according to the adjusted Triggering Condition Type. The Gating Type can be adjusted in the Schema Editor. When the relevant input values meet the Gating Type's demands, and the Enable Trigger - if activated - also holds a value, the Step will initialize a new Activity instance.<br />
<br />
It is important to know that <span class="EMPH">initializing</span> an Activity is <span class="EMPH">not</span> the same as <span class="EMPH">executing</span> an Activity. When an Activity is initialized, only the internal object is prepared, and the according set of input values is attached to that object. Execution can however start at a later point of time, depending on parallelity limitation of the Step, and on the Activity's position in the execution queue. This means that the values that the internal functionality of the Activity will work on are the first values present at the Step's Input Pins in the moment of the invocation (= Activity initialization), and changes in the value constitution (especially on the parametric Input Pins) are not recognized by the Activity when its execution starts.<br />
<br />
Another important issue when executing Workflows is the so-called <span class="KEYWD">Execution Context</span>, which denotes the <span class="EMPH">executing environment</span> of an Activity. Activities, meanwhile, can only be spawned from Steps, and Steps can only exist inside of Workflows. Executing a Workflow means executing Activities of the Steps inside. This especially affects Compound Block Steps, because these have own Workflows as their internal functionalities. When a Compound Block Step's Activity is executed, it constitutes the Execution Context for all Activities spawned from its internal Steps. The special thing about it is that the Activity not only <span class="EMPH">creates</span> its individual Execution Context, but also <span class="EMPH">inherits</span> the properties of its own encapsulating Execution Context.<br />
<br />
There are several items which are concerned in the Execution Context inheritance. First is the <span class="KEYWD">Variable Environment</span>: Each Compound Block defines an own Variable Environment, possibly overdubbing parts or all of the Variable Environment inherited from its encapsulating Execution Context. Second is the <span class="KEYWD">Inventory</span>: Also, each Compound Block defines an own Local Inventory, that may pass Resource Acquirement Requests to the Inventory of its encapsulating Execution Context. Third, but not of great interest to the user, is the internal <span class="EMPH">logging</span> mechanism: Activity Logs are always attached to the superordinate Activity Log instance in their Execution Context after the Activity has finished execution.<br />
<br />
=== Using Elementary Blocks ===<br />
<br />
<span class="KEYWD">Elementary Blocks</span> provide the <span class="EMPH">basic functionality</span> of an expecco project. They are used to model basical calculation or logical combination units, or to query and control external devices. These can be local or remote processes as well as hardware devices that are attached by some kind of hardware interface.<br />
<br />
In contrast to the Compound Block, an Elementary Block does not contain an Internal Workflow Property. Instead, each specialized Elementary Block type has a particular Property according to that type.<br />
<br />
==== Code Blocks ====<br />
<br />
<DIV ALIGN="LEFT" STYLE="border:0px solid"> The <span class="KEYWD">Code Block element</span> is the element type used to implement an elementary functionality block in form of programmatic <span class="EMPH">source code</span> in a particular <span class="EMPH">programming language</span>. Currently, two syntax patterns are supported: [[Datei:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] JavaScript syntax, and [[Datei:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] Smalltalk syntax.<br />
<br />
Each element of this type contains exactly one <span class="KEYWD">Code Content Property</span>, which holds the <span class="KEYWD">Source Code Text Content</span> that is interpreted according to the used languages syntax at runtime. It is also possible to <span class="EMPH">switch the syntax pattern</span> for already implemented Code Blocks, causing the code to be automatically converted to that particular syntax style.<br />
<br />
The Code Block element type offers all functionalities that are needed to make full programmatic use of the underlying operating system, including access to interfaces, file systems, and other processes, by providing appropriate objects for use inside the code.<br />
<br />
Inside the code, the Data Pins of the Block can be directly accessed using the Pins name, and used as if they were code variables. A single restriction exists for this access, according to the nature of the Data Pins: Reading values is only possible for the Input Pins variables, while writing is only possible for the Output Pins variables.<br />
<br />
==== Shell Script Blocks ====<br />
<br />
The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_ShellScriptAction.png]] <span class="KEYWD">Shell Script Block element</span> is the element type used to implement an elementary functionality block in form of <span class="EMPH">shell script source code</span> in an OS dependent scripting language. The code contents are <span class="EMPH">directly passed</span> to the underlying operating system, so the scope of possible shell or batch script dialects depends on the platform on which the session is running.<br><br />
<br />
Each element of this type contains exactly one <span class="KEYWD">Shell Script Content Property</span>, which holds the <span class="KEYWD">Shell Script Code Text Content</span> that is passed to the operating system at runtime. The features that are available to the script code depend on the used dialect. An Activity of this Block type will only run if the used dialect can be interpreted by the OS. Since the OS interprets the code in a process spawned by expecco, the current OS variable environment of the expecco session also is the initial OS variable environment for the<br />
shell process.<BR><br />
<br />
Inside the code, no direct access to the Data Pins is available. The reason is the nature of the shell and batch execution schema: The according process is running inside a shell, and communicates with the outside via the standard streams <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span>. However, the output of the command can be captured by connecting the according Pins to some evaluating Steps.<br />
<br />
The Shell Script Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Script Content Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#181f0ee0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.7: The Script Code Editor</a>.<br />
<br />
==== Shell Command Blocks ====<br />
<br />
The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_ConsoleCmdAction.png]] <span class="KEYWD">Console Shell Command Block element</span> is the element type used to implement an elementary functionality block in form of a <span class="EMPH">console shell command</span> in an OS dependent manner. The command is <span class="EMPH">directly passed</span> to the underlying operating system, so the scope of possible executables to call depends on the platform on which the session is running.<BR><br />
<br />
Each element<br />
of this type contains exactly one <span class="KEYWD">Console Shell Command Property</span>, which holds the command that is passed to the operating system at runtime. An Activity of this Block type will only run if the specified command can be executed by the OS. Since the OS runs the code in a process spawned by expecco, the current OS variable environment of the expecco session also is the initial OS variable environment<br />
for the shell process.<BR><br />
<br />
For the executing process, no direct access to the Data Pins is available. The reason is the nature of the command execution schema: The according process is running inside a shell, and communicates with the outside via the standard streams <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span>. However, the output of the command can be captured by connecting the according Pins to some evaluating Steps.<br />
<br />
The Shell Command Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Script Content Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#185a9140-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.8: The Console Command Editor</a>.<BR><br />
<br />
==== Test Data Generator Blocks ====<br />
<br />
The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_DataGeneratorAction.png]] <span class="KEYWD">Test Data Generator Block element</span> is the element type used to <span class="EMPH">supply artificially generated data values</span> to other Steps. This is useful especially for simulating elements that are usually delivering the values, but are not always or not yet available. A second purpose for this Block type is to control the execution flow by yielding time scheduled values.<br />
<br />
Each element of this type contains exactly one <span class="KEYWD">Generic Values List Property</span>, which holds a chronologically sorted list of Generic Values Entries. Every entry in that list consists of a Generation Time declaration, and for each Output Pin which is defined in the Block's Schema Definition, possibly one Generic Value. It is not obligatory to assign a Value to every Output Pin per Entry, but if, only one Value per Pin and Entry is possible.<br />
<br />
When an Activity of this Block type is started, time is measured by the Activity from that moment on. When an entrys Generation Time declaration is reached, the according values are sent to the specified Output Pins. The Data Generator Block has no further programmatic or OS specific functions.<br />
<br />
The Data Generator Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Generic Values List Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#189947f0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.9: The Generic Values Editor</a>.<br />
<br />
<br />
==== Schema Definition Restrictions ====<br />
<br />
Unlike the Code Block, the Script and Shell Command Blocks <span class="KEYWD">Data Pin Definitions</span> (which are part of the Schema Definition Property) are <span class="EMPH">fixed</span>, i.e. no Data Pins can be added or removed. However, the Pin Configurations can be modified, and preset values can be given to the Input Pins. The fixed set of Pins comprises just the objects and parameters that are involved in a typical shell/batch or console command call:<br />
<br />
The <span class="CODE">execDir</span> Input Pin takes a String or Filename object that specifies the base directory to which to change when execution starts, also known as the <span class="EMPH">current directory</span>. Relative paths in Script or Batch files are usually interpreted to be relative to this directory.<br />
<br />
The <span class="CODE">command</span> Input Pin is only present at Shell Command Blocks, and takes a String object that specifies the <span class="EMPH">calling path of the executable</span> to be called. If the calling path is given as a relative path, the system will try to find the executable relative to the current directory, as specified with the <span class="CODE">execDir</span> Input Pin.<br />
<br />
The <span class="CODE">args</span> InputPin takes a StringCollection representing the executions <span class="EMPH">arguments</span>, s they would be specified when calling an analogous script from the command line. While command line arguments are separated by whitespace, the arguments here are passed as a collection of string objects. Thus, unlike in command line calls, no quotation marks are needed as delimiters when whitespace are used inside an argument string.<br />
<br />
The <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span> Pins represent the shell and batch typical, OS related <span class="EMPH">stdandard i/o streams</span>. However, in this Block type, they are not directly accessible as the stream objects that are used by the operating system. Instead, the String datatype is used, which collects all of the lines in a single string object.<br />
<br />
For the <span class="CODE">stdin</span> Input Pin, this means that the all input lines have to be collected <span class="EMPH">in total</span> into a string first and initially passed to the <span class="CODE">stdin</span> Pin for execution. After the Activity is spawned, <span class="EMPH">no further input lines</span> can be supplied to the <span class="CODE">stdin</span> Pin.<br />
<br />
For the <span class="CODE">stdout</span> and <span class="CODE">stderr</span> Output Pins, the situation is similar, but still different: By giving values to the <span class="CODE">outNLines</span> and <span class="CODE">errNLines</span> Pins, the block size for each output stream can be adjusted. The block size is the <span class="EMPH">number of lines to collect</span> before the collecting string object is passed to the output pins, and a new collecting string is initialized. If no block size is specified for an output stream, the complete output is collected in a single string object, and not passed until successful termination of the Activity.<br />
<br />
The <span class="CODE">result</span> Output Pin delivers the <span class="EMPH">integer return value</span> of the process, which is directly the return value delivered to the caller by the operating system. The meaning of return values differs between platforms, but most usual, a succeeding call delivers a 0, while errors are indicated with a particular number.<br />
<br />
An individual restriction applies to the <span class="KEYWD">Data Generator Block</span>: Because no input values are ever needed in this Block type, no Input Pin Definitions can be created in the Blocks Schema Definition. Output Pins can be defined as usual, including assignment of the Datatype and other Output Pin specific settings.<br />
<br />
== Test Plans and Test Results ==<br />
<br />
The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_TestPlan.png]] <span class="KEYWD">Test Plan element</span> is the element type used to <span class="EMPH">model and execute</span> individual <span class="KEYWD">Test Plans</span>. A Test Plan is a <span class="EMPH">sequence</span> of individual <span class="KEYWD">Test Items</span> that can be executed. A Test Item is either <span class="EMPH">a Block</span> element, or yet another <span class="EMPH">nested Test Plan</span> element. Each element of this type contains exactly one <span class="KEYWD">Test Items List Property</span>, which serves to set up and arrange the sequence of Test Items. When a Test Plan is processed, its Test Items are processed one by one along their arrangement sequence in the Test List.<br />
<br />
In the expecco GUI, arrangement and execution of Test Plans are performed in a single editor type, the <span class="KEYWD">Test Plan Editor</span>. This editor provides the editable representation of the <span class="KEYWD">Test Items List</span> Property, as well as the user interface needed to start, halt, stop, or debug the Test Plans execution. Accessing the Test Items List Property and executing Test Plans through the GUI is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#1abf5c40-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.17: The Testplan Editor</a>.<br />
<br />
=== Test Lists and Test Items ===<br />
<br />
Inside the Test Plan Editor, Test Items can be created simply by <span class="EMPH">dragging</span> the desired element from the element Navigation Tree to the Test Items List area in the Test Plan Editor. The dragged element can be either a Block element, or another Test Plan element. When dropping a Test Plan into the Test List, its contents will not be expanded, nor visible. Nested Test Plan items are handled in the same way as the Block element items are.<br />
<br />
Inside a Test Plan, Test Items can be individually <span class="EMPH">selected for execution</span>, i.e. included to or excluded from the execution sequence. Additionally, an individual <span class="EMPH">repetition number</span> can be assigned to every Test Item, causing it to be repeated that number of times consecutively. This makes it possible to repeat a single Test Item, without having to create numerous equal Test Item entries.<br />
<br />
Only the Blocks on the Test Plans <span class="EMPH">own</span> basic level can be seen in the Test Items List. The contents of <span class="EMPH">nested</span> Test Plans can only be modified inside <span class="EMPH">their</span> own Test Items Lists. Thus, it is not possible to directly modify the inclusion or repetition numbers for Test Items that are inside a nested Test Plan.<br />
<br />
=== Test Runs and Activity Logs ===<br />
<br />
A <span class="KEYWD">Test Run</span> denotes a <span class="EMPH">single execution</span> of a Test Plan. Like for all other Workflow executions, the Test Run also performs by executing Activities.<br />
<br />
When an Activity is executed, it locally holds its individual <span class="EMPH">logging information</span>, called its <span class="KEYWD">Activity Log</span>. An Activity Log consists of a chronological list of input and output value events, and of the Notice, Warning, and Error messages that are generated during the Activity's execution.<br />
<br />
While a nested Test Plan element is only an <span class="EMPH">organizational</span> part of the containing Test Plan, the Block elements which are embedded make up the <span class="EMPH">functional</span> part of it. However, it would not be precise to say that the Blocks were executed; when a Test Plan is about to be executed, an <span class="EMPH">implicit Workflow</span> is created first, which simply creates one Step instance for each included Block in the sequence, and then chains these Steps using Enable Triggers to arrange the modeled sequence.<br />
<br />
In addition to the Workflow, a <span class="KEYWD">Test Wrapper</span> object is created. The Test Wrapper is an Activity that <span class="EMPH">embraces and processes</span> the given Test Item sequence. This artificially generated Workflow is then assigned to the Test Wrapper object, which is also created in the beginning of the execution. Items that are not activated for execution will not produce an implicit Step inside the Test Wrapper objects Internal Workflow. Finally, the Test Wrapper is started and executes the Workflow.<br />
<br />
Note that when dropping a Block element to the Test List, the according implicitly generated Step at execution time does <span class="EMPH">never receive any values</span> on its Input Pins. Also, values written to the Output Pins are <span class="EMPH">never received by any other Step</span>. For usual, Blocks that are intended to represent Test Items will be designed without Data Pins, or the Data Pins will serve for assigning frozen values only. For most of the cases, Blocks used to represent Test Items will be Compound Blocks. However, this is not a rule. <span class="EMPH">Any</span> Block element can be placed as a Test Item, and its according Step will be invoked in <span class="EMPH">any case</span>, regardless to the Gating Type and Pin Configuration given in the Block's Schema Definition.<br />
<br />
When the Test Plan is executed, for each of its Test Items and their repetitions an Activity is created, which executes the Test Item's internal functionality. During this Test Run, the Test Items List also serves to display the <span class="KEYWD">Activity Tree</span>, which supplies a browseable overview on all Activities that are currently running or already finished. On the Test Plans own basic level, <span class="EMPH">only one</span> Activity can be active at a time, because Test Plan execution always performs sequentially. However, there can be multiple concurrently executing sub Activities below a basic level Activitys node, if the Activity refers to a Compound Block. Inside the Compound Block, <span class="EMPH">no implicit parallelism restrictions</span> are made, so its internal Steps can create concurrent Activities.<br />
<br />
The Test Items List does not only allow the <span class="EMPH">arrangement and setup</span> of Test Items, but also displays the according <span class="EMPH">Activity execution states</span> at runtime, as well as their sub Activities, as a hierarchical tree structure. This structure is called the <span class="KEYWD">Activity Tree</span>. In this structure, it is possible to browse to any Activity that started execution in the current Test Run, and to <span class="EMPH">access its logging information</span> by selecting it. This Activity Tree can also be browsed during runtime, making it possible to keep track on the current execution state. When a repetition number is configured for the Test Item, that many Activity entries will appear as sub Activity entries below the Test Items node at runtime.<br />
<br />
=== Test Results and Test Reports ===<br />
<br />
A <span class="KEYWD">Test Result</span> is the <span class="EMPH">ordered set of Activity Logs</span> that was created during a Test Run. Test Results can be stored to the file system or to a database, and can be reloaded for inspection at a later point of time. To prevent Test Results from getting too large, especially when large tests are conducted launching hundreds or thousands of Activities, the maximum number of kept Activity Logs can be limited. When exceeding the limit, Activity Logs of previously executed Activities are deallocated, but only if no errors occurred inside of them. The reason for this is that, when lots of Activities are running, usually no one will be wanting to read all the logging information that was generated from successful Activities. Instead, normally only the erroneous Activities are of interest, and are thus kept in memory until the end of the Test Run.<br />
<br />
A <span class="KEYWD">Test Report</span> is a representation of the contents of a Test Result, or of part of it, in the form of a <span class="EMPH">document readable by humans</span>. In expecco, Test Reports can be generated in different <span class="EMPH">output formats</span>. The formats currently supported by expecco are the HTML and PDF formats. Style sheets can also be used to adapt the document to enterprise specific style guides.<br />
<br />
When filing out a Test Report, different <span class="EMPH">message categories</span> can be included to or excluded from the output. For example, you could want to only print out error messages, or warnings or notices only, or some kind of combination of these. The Test Result, however, always holds <span class="EMPH">all</span> relevant logging information of the Test Run. When a Test Report is generated, the different message categories which should be comprised in the report can be selected individually, but that does not affect the contents of the Test Result.<br />
<br />
== Resource Management ==<br />
<br />
<span class="KEYWD">Resources</span> play a significant role in the flow control of automated processes. In particular such tests that require the employment of external hardware, like measuring units, controllers, etc., make the consideration of the availability of resources indispensable. This is valid even more when operations shall be executed in parallel. With the expecco Resource Management, you can register your material allegations, be it devices, materials, persons, or also availabilities of immaterial nature. Because the managed resources do not have to relate to real objects obligatorily, you can also implement abstract limitation structures like semaphores or locks with them.<br />
<br />
In expecco, Resources are defined in reference to their <span class="EMPH">abilities</span>, for which we use the term <span class="KEYWD">Skills</span>. Similar to an interface definition, the elementary <span class="KEYWD">Attributes</span> that characterize an ability are summarized in such a Skill object. A <span class="KEYWD">Resource</span> is characterized by a set of such Skills, and concretized by assigning <span class="EMPH">values</span> to the Skill's Attributes.<br />
<br />
Resources can then be accumulated into <span class="KEYWD">Inventories</span>, which represent <span class="EMPH">availability sets</span> of Resources. The Inventory object takes care of the distribution and availability of its Resource entries during runtime. Inventories can be assigned to <span class="EMPH">Workflow execution contexts</span>, then offering their Resources to the Activities that run in that context. Activities claim their need for Resources by specifying according <span class="KEYWD">Requirements</span>, and try to reserve an adequate Resource by requesting the Inventory for the according concrete Skills.<br />
<br />
The acquisition of Resources, finally, is performed by the <span class="KEYWD">Activities</span> during runtime. For each Block element (except for the Test Data Generator Block), <span class="KEYWD">Skill Requirements</span> can be specified, which will cause an according Activity to request the Inventory of its <span class="KEYWD">Execution Context</span> for Resources that meet the specified demands. An Activity will <span class="EMPH">not</span> execute unless adequate Resources have been reserved, and keeps them reserved until it has finished execution.<br />
<br />
A special feature in this context applies to <span class="KEYWD">Compound Blocks</span>: Every Activity that relates to a Compound Block gets its own individual <span class="KEYWD">Local Inventory</span>. Here, a preoccupation of certain amounts of Resources can be configured, and additional Resource instances can be created repeatedly for each of these Activities. The Local Inventory will then be used as the first level Inventory for all sub Activities that run in this Activity's execution context.<br />
<br />
When an Activity is created, each Skill Requirement of the according Block's Skill Requirements Property causes a <span class="KEYWD">Resource Acquisition Request</span> to the Execution Context's Inventory. When an Inventory receives such a Resource Acquisition Request, it successively checks all of its available Resources for <span class="EMPH">adequacy</span>, until a fitting Resource instance is found or the end is reached. Adequacy refers to the Skill Requirement that caused the request: The Inventory first looks whether the Resource contains a Skill Assignment that corresponds to the given Skill Requirement, i.e. an Assignment that references the same Skill element as the Requirement does. If so, for each Skill Attribute, the Attribute Comparison is evaluated, using the currently checked Resource's corresponding Attribute Value. If all of the comparisons evaluate to true, the Resource is assumed to be adequate.<br />
<br />
If an adequate Resource instance could be found, the Inventory marks it as being acquired by the requesting Activity. If no adequate Resource instance is present or available, the request is passed to the Inventory belonging to the next higher execution context. For Compound Blocks, a restriction can be configured to the request passing when using preallocation: If the same Skill element as that of the request is also registered in the Compound Block's own Skill Requirements, the configured Request Pass-On Mode decides whether the request is passed upwards, or whether the Resource could exclusively be acquired from this Inventory.<br />
<br />
=== Defining Skills ===<br />
<br />
The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Skill.png]] <span class="KEYWD">Skill element</span> serves to summarize the elementary <span class="KEYWD">Skill Attributes</span> that <span class="EMPH">characterize</span> a Skill. It is important that only the <span class="EMPH">nature</span> of the Skill is defined in the form of its Skill Attributes, but <span class="EMPH">no</span> concrete values are ever assigned directly to the Skill. Later on, one or more Skills can be assigned to a Resource, which is then concretizing them by <span class="EMPH">value assignments</span>. These specifications are taken into account during runtime to decide about the suitability of a Resource for a particular usage purpose.<br />
<br />
Each element of this type contains exactly one <span class="KEYWD">Skill Attributes Property</span>, which serves to set up and configure the Skill Attributes. This is done in expecco using the <span class="KEYWD">Skill Definition Editor</span>.<br />
<br />
A <span class="KEYWD">Skill Attribute</span> consists of two elements: The <span class="KEYWD">Attribute Name</span>, which serves as the key of association for the user, and the <span class="KEYWD">Attribute Datatype</span>, which determines what kind of value can be assigned to the Attribute. The user can add and remove Skill Attributes, set the Attribute Names, and select the Attribute Datatypes. Internally, the Skill Attributes are ordered as a sequence, which also determines the appearance sequence of the Skill Attributes in other editors when concerned.<br />
<br />
Note that the Attribute Name is a <span class="EMPH">purely organizational feature</span> for the user to associate the Attributes to real world's properties. Theoretically, multiple Attributes can have the same name. However, this is not recommended, because it will only lead to confusion for the user.<br />
<br />
As mentioned, the Skill Attributes do not get any values assigned. The Skill element serves only as a pattern for concrete abilities. For example, one could define a Skill named "Voltage Measure Range", which could carry Attributes like "Lower Limit" and "Upper Limit". Different real measure devices could have different voltage measure ranges, but however, the same Skill element can be used to classify them. The Resource element is then responsible to concretize the Attributes with values.<br />
<br />
In the <span class="KEYWD">Skill Definition Editor</span>, a new Skill Attribute can be created simply by clicking the according button. The editor provides a list with one row for each Skill Attribute. Two of the columns have editable fields, allowing to specify the Attribute Name by typing into a text field, and to select the Attribute Datatype by selecting from a dropdown box.<br />
<br />
The Skill Definition Editor is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#19a19030-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.13: The Skill Definition Editor</a>.<br />
<br />
=== Defining Resources ===<br />
<br />
The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Resource.png]] <span class="KEYWD">Resource element</span> is used to represent a concrete Resource <span class="EMPH">type</span>. The Resource element itself still does <span class="EMPH">not</span> represent a concrete <span class="EMPH">instance</span> of a Resource; this is achieved in a later step when setting up an Inventory. The Resource element however defines the type of the Resource using <span class="EMPH">concrete values</span>, thereby allowing to specify concrete Resource types, like e.g. a particular measurement unit model, a certain controller type, etc.<br />
<br />
Each element of this type contains exactly one <span class="KEYWD">Skill Assignments Property</span>, which serves to set up and concretize the list of Skill Assignments. This is done using the <span class="KEYWD">Resource Definition Editor</span>.<br />
<br />
A <span class="KEYWD">Skill Assignment</span> consists of a <span class="KEYWD">Skill Reference</span> to the according Skill element, and of a set of <span class="KEYWD">Skill AttributeValues</span>, one for each Skill Attribute of the referenced Skill. Like this, the Resource is assigned one or more of the Skills that were defined in advance, concretizing them by <span class="EMPH">value assignments</span>. For every Skill Attribute of each Skill, a value is given according to the <span class="KEYWD">Attribute Datatype</span> that was defined for the Skill Attribute. These specifications are taken into account later to decide about the suitability of the Resource for a particular usage purpose.<br />
<br />
When a Resource instance is checked for adequacy for a particular Skill Requirement in a Resource Acquisition Request, the Attribute Values defined in the corresponding Skill Assignment are used for comparison against the Requirement's demands. Only if all of the comparisons evaluate to true, the Resource will be assumed adequate to meet the requesting Activity's needs.<br />
<br />
In the <span class="KEYWD">Resource Definition Editor</span>, new Skill Assignments can be created simply by <span class="EMPH">dragging</span> a Skill element from the element Navigation Tree to the Skill Assignments List area. Note that only one Skill Assignment entry can be contained in the list for a particular Skill element.<br />
<br />
The Resource Definition Editor is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#19e1cd80-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.14: The Resource Definition Editor</a>.<br />
<br />
=== Defining Inventories ===<br />
<br />
The [[Bild:PIC_GUI_IconSymbol_ProjectComponent_Inventory.png]] <span class="KEYWD">Inventory element</span> serves to represent a set of resources that can be used during a Test Run. An Inventory can be assigned to the context of a Test Run, thus making the Resources that it comprises available to the Activities in the context of the Test Run. One special purpose of Inventories is that when using them, you do not have to define congenerous instances of your resources multiple times. Instead, you can accumulate an arbitrary number of different resources into <span class="KEYWD">Inventories</span> using the <span class="KEYWD">Inventory Editor</span>. By simply assigning an Inventory to a Test Run, you can quickly adjust the flow to the real-world conditions.<br />
<br />
Each element of this type contains exactly one <span class="KEYWD">Resources List Property</span>, which serves to compose and set up the Resource Entries. This is done using the <span class="KEYWD">Inventory Definition Editor</span>.<br />
<br />
A <span class="KEYWD">Resource Entry</span> consists of three elements: The <span class="KEYWD">Resource Reference</span> to the according Resource element, the <span class="KEYWD">Allocation Block Reference</span>, which specifies a Block of which an Activity shall be executed on <span class="EMPH">allocation</span> of the Resource instance, and the <span class="KEYWD">Release Block Reference</span>, which specifies a Block of which an Activity shall be executed when the Resource instance is <span class="EMPH">released</span>.<br />
<br />
Internally, implicit Steps are created for the Allocation and Release Blocks at runtime as the basis for spawning the according Activities. <span class="EMPH">Any</span> Block element type can be used to act as the Allocation or Release Block. However, it has to be taken into account that the according Activities <span class="EMPH">never</span> receive any input values on their Input Data Pins, except frozen or environment values when defined in the Block's Schema Definition. Also, values written to the Output Pins are <span class="EMPH">never</span> received by any other Step.<br />
<br />
In the <span class="KEYWD">Inventory Definition Editor</span>, a Resource entry can be created simply by <span class="EMPH">dragging</span> a Resource element from the element Navigation Tree to the Resources List area. Note that the same Resource element can be dragged multiple times to the same Inventory, as well as to other Inventories, each time generating a new Resource entry in the Inventory's Resources List. This is because the Resource element does <span class="EMPH">not</span> designate a <span class="EMPH">concrete</span> object of reality, but instead only describes a particular <span class="EMPH">kind</span> of object, which in turn can exist in reality multiple times.<br />
<br />
The Inventory Definition Editor is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#1a205d20-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.15: The Inventory Definition Editor</a>.<br />
<br />
=== Defining Resource Requirements ===<br />
<br />
Each [[Datei:PIC_GUI_IconSymbol_ProjectComponent_UnspecifiedAction.png]] <span class="KEYWD">Block element</span> - except for the Test Data Generation Block - can be assigned a set of <span class="KEYWD">Skill Requirements</span>, which describe the <span class="EMPH">abilities that have to be met</span> by a Resource to make it suitable for the Block's functionality. Resources are never directly addressed by a Block's Skill Requirements; instead, these define only what Skills a Resource should meet, and the requested Inventory decides about which Resource fits best and will be reserved for the particular Activity.<br />
<br />
An Activity that refers to a Block element which has Skill Requirements assigned, will always first try to find and <span class="EMPH">allocate suitable Resource objects</span> in the Inventory of its surrounding context, before it starts its execution. Requirements of Blocks referred to by internal Steps of a Network (be it a user defined or an implicitly generated Network) thereby <span class="EMPH">propagate forward</span> to the top, and allocated resources are not released unless the execution of the Activity has finished. Note that in contrast to the Skill element, a Skill Requirement does <span class="EMPH">not</span> appear as an expecco Testsuite element. Skill Requirements <span class="EMPH">only</span> appear in the Block's Skill Requirement Property.<br />
<br />
Each element of this type contains exactly one <span class="KEYWD">Skill Requirements Property</span>, which serves to compose and set up the Skill Requirements. This is done using the <span class="KEYWD">Resource Requirement Editor</span>.<br />
<br />
A <span class="KEYWD">Skill Requirement</span> consists of a <span class="KEYWD">Skill Reference</span> to the according Skill element, a set of <span class="KEYWD">Skill Attribute Comparisons</span> with one for each Skill Attribute of the referenced Skill, and an <span class="KEYWD">Acquisition Configuration</span>.<br />
<br />
A <span class="KEYWD">Skill Attribute Comparison</span> consists of a <span class="KEYWD">Comparison Operator</span> and a <span class="KEYWD">Comparison Value</span>. The Attribute Comparison is used during runtime to evaluate whether a Resource's Skill Assignment fits the needs of the Skill Requirement, or not.<br />
<br />
An <span class="KEYWD">Acquisition Configuration</span> specifies detail on the way how adequate Resources are to be acquired at runtime. For all Block elements, it contains the <span class="KEYWD">Requisition Number</span>, which is the number of adequate Resource instances to be acquired in respect to the particular Skill Requirement. Especially for Compound Blocks, this can be used to reserve a certain number of adequate Resources in advance.<br />
<br />
For Compound Blocks only, which have an implicit local Inventory at runtime, two other values can be configured: The <span class="KEYWD">Generation Number</span>, and the <span class="KEYWD">Request Pass-On Mode</span>. The <span class="KEYWD">Generation Number</span> allows to configure <span class="EMPH">implicit creations</span> of Resource instances inside an Activity's local Inventory when the Activity is created. Naturally, this does <span class="EMPH">not</span> make sense when dealing with <span class="EMPH">real</span> objects, because those will not duplicate themselves just because a new Activity is created. It <span class="EMPH">does</span> make sense, however, for abstract immaterial Resources such as <span class="EMPH">semaphores</span> or <span class="EMPH">locks</span>. The <span class="KEYWD">Request Pass-On Mode</span> determines whether, in case that no adequate Resource can be acquired from the local Inventory, the request should be passed on upwards to the next Execution Context's Inventory, or not.<br />
<br />
In the <span class="KEYWD">Resource Requirement Editor</span>, Skill Requirements can be created simply by <span class="EMPH">dragging</span> a Skill element from the element Navigation Tree to the Skill Requirements List area. Multiple Skill Requirement entries can be contained in the list for a particular Skill element.<br />
<br />
The Resource Requirement Editor is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#1a5f13d0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.16: The Resource Requirement Editor</a>.<br />
<br />
== Variable Environments ==<br />
<br />
<span class="KEYWD">Variable Environments</span> provide a means for supplying general - but however scope dependent - variables, as typically known from most computer operating systems like UNIX, Linux, Windows, macOS, etc. The concept of Variable Environments is widely spread and has proven its usefulness throughout the years, and it also is a basic paradigm for most scripting languages, as well as for some programming languages. The interactive modeling environment that expecco constitutes, also supports a corresponding mechanism.<br />
<br />
In expecco, Variable Environments can be defined in multiple locations. The first possible location to do so is the <span class="KEYWD">Testsuite element</span>. Because the Testsuite element is the <span class="EMPH">base item</span> of an expecco project, the according Variable Environment acts as the <span class="KEYWD">Global Variable Environment</span> of the project, i.e. it is basically valid for all Activities ever executed throughout the project.<br />
<br />
However, the second possible location allows to <span class="EMPH">alter</span> the Environments behavior: For every <span class="KEYWD">Compound Block</span> element, an <span class="EMPH">own</span> Variable Environment can be defined. When a Compound Block Activity is created, a <span class="KEYWD">Local Variable Environment</span> is initialized along that definition. This local Environment is then valid for the <span class="KEYWD">Execution Context</span> which this Activity constitutes for its subordinate Activities.<br />
<br />
The Environment Variables declared in such a local Environment <span class="EMPH">overdub</span> those of the global one, as well as those of the own encapsulating Execution Contexts local one. The expecco Environments act totally <span class="EMPH">transparent</span> regarding the <span class="EMPH">inherited</span> Variables, i.e. those declared in the superordinate Execution Contexts: If a Variable is accessed which is not declared locally, the Environment <span class="EMPH">passes</span> the access request to the Environment of its own encapsulating Execution Context, and so on. For the Activity itself (and thus also for the user, for instance inside a Code or Script content), the access always appears as if only one Environment was present.<br />
<br />
Like this, it is possible to model <span class="EMPH">scoped Variable Environments</span>, which act and behave in the same manner as those used by computer operating systems: They offer the same inheritance mechanism, allow for overwriting and local creation of Variables, and Variable referencing is done by textual keys, allowing them to be accordingly used inside the Code and Shell Script Block elements. In addition, Environment Variables in expecco can be <span class="EMPH">write-protected</span> individually, so Activities can read from, but not write to the protected Variable. Also, writing to an Environment Variable only affects a superordinate Environment if the Variable definition is not locally overdubbed.<br />
<br />
One additional option is included in the expecco Environments, which is unique to expecco, and not found in any other Environment conceptions so far: For each Variable inside a Compound Block's Variable Environment, the <span class="EMPH">scope behavior can be inverted</span>. This means that, although a Variable is declared in a Local Variable Environment, the Environment can however prefer to access the Variable of the same name inside its <span class="EMPH">superordinate</span> Environment. The use of this is that you can configure local default values in such a Variable, which are then only used if <span class="EMPH">none</span> of the parental Environments defined a Variable of the same name.<br />
<br />
Each Compound Block element as well as the Testsuite element has exactly one <span class="KEYWD">Variable Environment Property</span>, which serves to compose and set up the Environment Variables. This is done using the <span class="KEYWD">Variable Environment Editor</span>.<br />
<br />
An <span class="KEYWD">Environment Variable</span> consists of a <span class="KEYWD">Variable Name</span>, which serves as the textual key for accessing the Variable, a <span class="KEYWD">Write Protection</span> flag, which determines write access to the Variable, a <span class="KEYWD">Variable Datatype</span>, determining of what type the Variable's values can be, an <span class="KEYWD">Initialization Mode</span>, specifying how to preset the Variable at the Environment's initialization, and an <span class="KEYWD">Initialization Value</span>, which acts - dependent on the Initialization Mode - either as a fixed value, or as an evaluatable expression that delivers a value.<br />
<br />
There is one additional element in the Variable Environment Property, which only applies to Compound Block elements: The <span class="KEYWD">Overdubbing Mode</span> flag, which determines the direction of overdubbing for the Variable. If the flag is set, name resolution tries to find the Variable in the upmost Environment first. If it is not set, name resolution will forward the accessing request to its parental Environments first, and use its own variable only if no resulting Variable instance was delivered.</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:Exception-cancel-pin.jpg&diff=10572Datei:Exception-cancel-pin.jpg2018-02-18T21:54:35Z<p>Mawalch: </p>
<hr />
<div>Obsolete file, superseded by [[File:Exception-cancel-pin.png]]<br />
<br />
[[Category:Marked for Deletion]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:All-pins.jpg&diff=10571Datei:All-pins.jpg2018-02-18T21:53:57Z<p>Mawalch: </p>
<hr />
<div>Obsolete file, superseded by [[File:All-pins.png]]<br />
<br />
[[Category:Marked for Deletion]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Release_Notes_2.x&diff=10570Release Notes 2.x2018-02-18T21:51:58Z<p>Mawalch: </p>
<hr />
<div>see also: [[Release Notes 1.x]]<br />
<br />
== Release 18.1 [previously known as "2.12"] (Spring 2018) ==<br />
With this release, we will start a new naming scheme, <br />
using the publishing year as major version number and the delivery within the year as minor vsn. <br />
<br>Thus, this version will be named "18.1.x" in marketing material.<br />
<br />
<br />
* Fix: attachment handling when moving items across projects (into/out of imported projects)<br />
<br />
* Feature: logInconclusive and logError actions (similar to logFailure, these mark the test's outcome, but continue execution)<br />
* Feature: many GUIBrowser enhancements<br />
* Feature: Connect multiple (same-named) pins<br />
* Feature: FileBrowser: dump can be changed to be hex, octal, decimal or binary; character decoding in EBCDIC or 7-bit ASCII (to ignore high/parity bit)<br />
* Feature: FileBrowser: search pattern can be entered as hex byte sequence<br />
* Feature: [[Settings UpdatesSettings/en#Expecco_as_a_Patches_Server_.282.12.29|Patches server]]: one expecco may deliver patches to all other installations in the local network<br />
* Feature: can pass [[ElementaryBlock Element/en#Environment_.28Shell-.29_Variables|shell environment variables to shell, batch actions]] (and all derived actions, like Ruby, Node.js, etc.)<br />
* Feature: [[ElementaryBlock Element/en#Matching_stdin.2Fstderr_against_a_Pattern|prompt matching in shell, batch actions]] (and all derived actions, like Ruby, Node.js, etc.)<br />
* Feature: [[DiagramElements-Pin/en#Do_not_Log_Pin-Value_in_Activitylog_Attribute|individual control over pin-value in activity log]] (e.g. to suppress passwords, cryptokeys etc.)<br />
* Feature: [[DiagramElements-Pin/en#Output_Pin_Value_Timestamped_Attribute|output pin values can be individually timestamped]] (via step's pin menu)<br />
* Feature: [[ElementaryBlock Element/en#Node.js-Script_Blocks|Node.js script blocks]] and [[ElementaryBlock Element/en#Node.js_Blocks|Node.js elementary action blocks]]<br />
* Feature: [[VNC Plugin Reference/en|VNC GUI Testing plugin]]<br />
<!-- * Feature: Message/Document browser --><br />
* Feature: "''Interrupt & Debug''" button in the [[Test Editor/en|Test-Runner]] (to interrupt runaway elementary blocks)<br />
<br />
* Performance: Speed improvement in testplan execution<br />
<br />
* UI Enhancement: coloring by type is now on by default (if you don't like it, go to "Settings"-"Look&Feel"-"Diagram Editor"-"Look Elements" and turn it off again)<br />
* UI Enhancement: Limit the number of levels in follow activity<br />
* UI Enhancement: ActivityTree shows activities with handled exceptions in orange (used to be red). Also, the handling activity shows where the handled exception was thrown. Finally, the automatic navigation to the first error (after a run) will skip over handled exceptions, to place you immediately to the activity which was responsible for the failure or error.<br />
* UI Enhancement: recently modified and recently executed menus in main-menu<br />
* UI enhancement: "''Select Step in Diagram''" menu-function in the activity log tree viewer<br />
* UI enhancement: "''Exchange Connections''" menu-function in the network editor<br />
* UI enhancement: "''Import Attachments''" tools menu-function (to import many files)<br />
* UI enhancement: more information and functions in the Diff-viewer; new menu item in the "''Extra''"-menu: "''Compare two Testsuite Files''"<br />
* UI enhancement: "''Add/Remove Tag''" menu functions (in tree) can also be applied recursively to children of the selected item<br />
* UI enhancement: when a step is selected at the time a new step is created by the "''New Step''" function or by paste, the new step is automatically connected via trigger-out/trigger-in<br />
<br />
<br />
== Release 2.11.1 (Fall 2017) ==<br />
* Bugfix Release including all patches for Release 2.11<br />
* Fix: Windows Automation - Stability<br />
* Fix: Problems with OLE<br />
<br />
== Release 2.11 (Spring 2017) ==<br />
* Fix: JSON parameter save/reload fixed<br />
* Fix: method name check in codeView was disabled<br />
* Feature: "must be executed" attribute in action definition<br />
* Feature: Erweiterung des expecco GUI Automation Framework<br />
* Feature: Neue Anbindungen an Technologien im Bereich Automotive und Maschinenbau<br />
* Feature: Rechnergebundene Einzelplatz Lizenz<br />
<br />
* Packaging: Neues expecco Bundle: expecco Testcenter - Testautomatisierung mit integriertem Test- und Ressourcenmanagement<br />
<br />
<br />
== Release 2.10.1 (= 2.10 + Patches) ==<br />
* Fix: keyboard focus for menu<br />
* Backward Compatibility Fix: the fixes in the JavaScript "indexOf()"-functions (done in 2.8) lead to problems with a customer (which migrated from 2.7.5 to 2.10). For this, two flags have been added to the suite-attributes, which enforce the old behavior for individual and/or all imported libraries. This allows for old code (which expects the wrong 1-based indexOf return values) to coexist with new code (which expects the correct 0-based versions) within a single test suite.<br />
<br />
* Feature: [[Settings UpdatesSettings/en|Patches can be loaded via HTTP]] (FTP was blocked in some customers' networks)<br />
* Performance: Bulk data transfers to network drives under Windows.<br />
<br />
== Release 2.10 (Fall 2016) ==<br />
* Feature: Mobile Testing Plugin (renamed from "''Appium Plugin''") got more support functions to administer appium & adb connections<br />
* Feature: new "Reimport Tool" for bulk reimport and library (dependency) checking<br />
* Feature: DLL-mapping dialog in the settings. For a typical usage example, see [[AutoIt Library#Installation|Installation of AutoIt]]<br />
* Feature: New blocks in the stdlib ("''Split by Size''" and "''Split by Element''"), to split collections (strings) into sized pieces or at a separator.<br />
* Feature: New command line options to specify individual parameter values<br />
* Feature: More formats supported for external parameter files (JSON)<br />
* Feature: new [[Starting expecco via Command Line/en#Detailed_Option_Description|command line]] arguments: -E, -P:, --parameter:, --silent, --licenseServerHost, --licenseServerPort<br />
* Feature: the new [[Java Interface Library v2|Java Bridge V2]]/DotNET Bridge V2 is now used by the default. The new bridge uses only a single port for communication (thus making firewall/router setup easier), supports casts, better controllable argument-type specification, is faster in its communication and supports asynchronous messages with lazy results. In case of backward compatibility problems, the old bridge is still available and can be used by changing the settings.<br />
* Feature: custom print length of the pin and log values for the report<br />
* Feature: [[CompoundBlock Editor-CompoundWorksheet Editor/en#Controlling_Logging_and_Tracing|"''Ignore All Skip in Trace''"]] settings to enforce a full trace (for debugging)<br />
<br />
* Performance: (dramatic) speedup in some image handling functions.<br />
* Performance: speedup (50%) in the XML reader.<br />
* Performance: speedup initial startup by not loading unlicensed plugins<br />
<br />
* UI enhancement: GUI Browser: double click on action/attribute item adds it to the list<br />
* UI enhancement: GUI Browser: reconnect/fix autostart when deleting recorded steps<br />
* UI enhancement: GUI Browser: better undo handling<br />
* UI enhancement: GUI Browser: keep tree and selection on refresh (not all technologies)<br />
* UI enhancement: better replace-step dialog in diagram editor (library filter added)<br />
* UI enhancement: Line numbers in the attachment editor<br />
* UI enhancement: Line numbers and trim-blank-lines option in multiline freeze value entry<br />
* UI enhancement: color settings for red-green deficiency (in status color dialog)<br />
<br />
* Change: SerialPort Plugin: the port parameter pins (baudrate, stop-bits, parity etc.) are now parameter pins. This will only affect you, if the open-serial-port block is triggered via one of those pins (which is very very unlikely)<br />
<br />
* Fix: All leftover (unclosed) external connections (Sockets, Serial Lines, Bridges) are closed after a testrun, when in slave mode<br />
* Fix: All leftover (unterminated) started appium servers are closed after a testrun, when in slave mode<br />
* Fix: Multiline freeze value editor interpreted strings starting with digits as numeric value<br />
* Fix: Multiline freeze value editor allows for empty lines at the end<br />
<br />
<br />
== Release 2.9 (June/2016) ==<br />
* Feature: Mobile Testing (aka "Appium")-Plugin: Add recorder<br />
* Feature: Mobile Testing Plugin: Update capabilities<br />
* Feature: Mobile Testing Plugin: Settings Dialog for setting up external auxiliary programs (adb, Appium Server, AVD Manager, SDK Manager)<br />
* Feature: Mobile Testing Plugin: New menu for launching auxiliary programs (Appium Server, AVD Manager, SDK Manager)<br />
* Feature: Mobile Testing Plugin: New buttons in Android Wizard to refresh the device list, launch AVD Manager, install APKs.<br />
* Feature: Mobile Testing Plugin: Save and load connection settings in and from attachments in test suite.<br />
* Feature: Mobile Testing Plugin: Allow editing and copying of connection settings.<br />
* Feature: Mobile Testing Plugin: Allow adding arbitrary capabilities for forward compatibility.<br />
* Feature: Mobile Testing Plugin Bundle: Update contents, in particular use Appium Server 1.4.16.<br />
* Feature: Mobile Testing Plugin Bundle: Remove Android emulator from bundle as it is huge. If needed, download and install it separately.<br />
* Feature: [[Java Interface Library v2|New Java Bridge (still experimental in 2.9)]]. The old Java Bridge is still available and enabled by default.<br />
<br />
* UI enhancement: Mobile Testing Plugin: More verbose warning dialogs.<br />
* UI enhancement: Mobile Testing Plugin: Remove obsolete "Emulator Settings" from connection dialog (using the wizard is superior now).<br />
* UI enhancement: Mobile Testing Plugin: Make newCommandTimeout capability user visible<br />
* UI enhancement: Mobile Testing Plugin: Remove unimportantView from default capabilities<br />
* UI enhancement: Mobile Testing Plugin: Automatically select entry in Android Wizard if only one is available.<br />
* UI enhancement: Mobile Testing Plugin: Highlight unknown capabilities to give a hint in case of bad spelling.<br />
* UI enhancement: Mobile Testing Plugin: Add a search filter for packages in the Android Wizard.<br />
* UI enhancement: General/Linux: Support for Anti-Aliased XFT-Fonts.<br />
<br />
* STD-LIB: Image Save block supports writing of JPEG images.<br />
* Mobile Testing Library: New blocks for multi-touch actions<br />
* Mobile Testing Library: New block for reading capabilities from files<br />
* Mobile Testing Library: New blocks for reading logs<br />
* Mobile Testing Library: New block "Find Elements by XPath" for finding sets of elements<br />
* Mobile Testing Library: New blocks for consecutive actions on single elements<br />
* Mobile Testing Library: New block for taking screenshots<br />
* Mobile Testing Library: New blocks for pressKeyCode API, make old blocks (sendKeyEvent API) obsolete<br />
<br />
* Localization: Mobile Testing Plugin: German translation mostly complete.<br />
* Documentation: Update and add more documentation to Appium library.<br />
<br />
* Fix: Mobile Testing Plugin: Timeout in Android Wizard if adb does not return.<br />
* Fix: Mobile Testing Plugin: Do not cut off multi-line status messages in Android Wizard.<br />
* Fix: Mobile Testing Plugin: Fix error and bad behavior when cancelling file dialog in connection settings.<br />
* Fix: Mobile Testing Plugin: Do not drop connection settings on connection error.<br />
* Fix: Mobile Testing Plugin: Use Java path from Settings<br />
* Fix: XML/XPath - accepts underscore ('_') and Unicode characters in element and attribute names.<br />
* Fix: RemoteAccess Plugin - fix error waiting for prompt<br />
* Fix: RemoteAccess Plugin - fix response in same line as command<br />
* Fix: Java GUI Plugin - fix error in "Verify Path"<br />
<br />
<br />
== Release 2.8 (Q4/2015) ==<br />
'''Notice: You have to install a patch for expecco 2.7.5, if you want to load a Testsuite which was edited in expecco 2.8 and uses some of the new features! [[release2.8 incompatibilities|(More info)]]'''<br />
<br />
* Feature: [[TableDrivenBlock Element|Table driven actions]]; these offer a simpler, table oriented interface<br />
* Feature: Mobile Testing-Plugin (was "Appium"-Plugin) for Android and Apple iOS test automation for mobile devices<br />
* Feature: Variable number of pins in groups ([[DiagramElements-Pin/en#Variable_Number_of_Pins|"Variable Pin Groups"]])<br />
* Feature: First release of the [[User Defined Menu Items#Useful_Building_Blocks_for_Custom_Menu_Operations|Expecco Reflection Library]] (to automate expecco itself)<br />
* Feature: Enum datatype: support for individual assigned enum values, described in the [[Datatype Editor/en#Enumeration_Types|Datatype Editor Documentation]] and the [[Datatype Element/en#Enumeration_Types|Datatype Element Documentation]] and also the [[Expecco API/en#Enum Type Functions|API Documentation]].<br />
* Feature: [[Starting expecco via Command Line#Expecco_REST_Service_Interface|REST service]] for remote controlling expecco execution<br />
* Feature: New [[ElementaryBlock Element/en#Ruby_Script_Blocks|Ruby actions]]<br />
* Feature: Better execution directory settings for [[ElementaryBlock Element/en#Shell_Script_Blocks|Shell blocks]]<br />
* Feature: New step attributes for more specific [[CompoundBlock Editor-CompoundWorksheet Editor/en#Step_Specific_Options_.28Context_Menu.29|"skip in log/trace"]] options (for looping actions)<br />
* Feature: New user preference setting to ignore all [[CompoundBlock Editor-CompoundWorksheet Editor/en#Step_Specific_Options_.28Context_Menu.29|skip-in-log]] attributes (for debugging)<br />
* Feature: "immediate fork new process" flag now also in block description or dynamically from elementary code<br />
* Feature: Improved performer data type handling; virtual steps now only accept valid performers, and freeze value choices are filtered for valid performers.<br />
* Feature: Option to start background action before or after pre-action<br />
* Feature: New constraint datatype type (for better freeze value selection)<br />
* Feature/Fix: compatibility of indexOf() / lastIndexOf() JavaScript functions (allow substring search)<br />
* Feature: Data inspector for strings shows another (XML-DOM) tab if the string is an XML string. This tab shows the parsed XML DOM-tree.<br />
* Feature: Attachments can now be declared as binary file attachment. These will not be interpreted; especially, no cr/lf translation and utf8 or similar character translation is performed. Binary attachments are required, e.g. to embed jar or other code files.<br />
<br />
* UI enhancement: Multiline labels in steps (use "\" as line-separator)<br />
* UI enhancement: Additional custom headline and custom text block in reports (can be filled in right before printing).<br />
* UI enhancement: Can now also set breakpoints on steps and code lines of readonly actions (e.g. in an imported library)<br />
* UI enhancement: Undo gives a warning when about to undo past the previous file-save state<br />
* UI enhancement: Added a menu item in "Extras" - "Debugging" to stop [[User Defined Menu Items#Asynchronous_.28Background.29_Actions|background menu actions]]<br />
* UI enhancement: Added more convenient pin-comment editing support to the schema editor<br />
* UI enhancement: Text editor has a new "split" menu function in its tools-submenu<br />
* UI enhancement: Better "New Step" and "Replace Step" dialogs in the diagram editor (showing preview, code and contents; also show attachments).<br />
* UI enhancement: Better autoconnect and matching blocks search algorithm in the "Place and Select New Step" function (i.e. New Step function, when an output pin is selected)<br />
* UI enhancement: New scale diagram function (scale and spread multiple steps)<br />
* UI enhancement: Lint performs a number of checks on a block being edited and gives immediate warnings in the info line (same checks as in the tree's error- and special search tabs)<br />
* UI enhancement: New lint-error check rules to detect consumed pin values in loops and multi-triggered chains.<br />
* UI enhancement: Double click on a search item to navigate to it in the tree<br />
* UI enhancement: Codeview and network view in the activitylog indicate that they are readonly.<br />
* UI enhancement: Secondary navigation tree for drag&drop.<br />
* UI enhancement: Warn if it is due time to check for updates.<br />
<br />
* STD-LIB: Collection creator and multi-setter blocks with variable number of pins (alternating key-value pairs)<br />
* STD-LIB: New DLL-Mapping block<br />
* STD-LIB: New blocks "File [modification time]", "File [access time]" and "File [creation time]".<br />
* STD-LIB: Additional blocks for event queue handling.<br />
* STD-LIB: Additional blocks for static step-local storage.<br />
* STD-LIB: Better versions for FAIL/WARN/INFO, LogFAIL, logWARNING and logINFO. New "Transcriber with Timestamp" action.<br />
* STD-LIB: Fixed some collection-type issues (now pins are #-template-typed, instead of Collection), which required a downcast in many suites.<br />
* STD-LIB: New blocks: "Trigger Periodically" and "Counter"<br />
* STD-LIB: New blocks: "Enumtype symbol<->integer"<br />
<br />
* Fix: Freeze value menu of unions of enums did not merge the individual enum values<br />
* Fix: Freeze value menu of unions of constraint dataType-types<br />
* Fix: The search breakpoints function (in the errors-tab of the treeview) now also finds statement breakpoints.<br />
* Fix: Fixes and improvements in the SOAP, REST and WSDL frameworks<br />
* Fix: Enum numeric value assignments were lost sometimes when saving/restoring<br />
* Fix: Search for references of a variable did not find them in imported libraries<br />
* Fix: Report of looped testplans (pre-action was reported multiple times)<br />
* Fix: behavior of cancel pin (did neither drive triggerOut-pin, nor exception-pin)<br />
* Fix: Fixes for crashes in follow mouse and backward (XPath) compatibility in WindowsAutomation Plugin<br />
* Fix: The embedded type editor for defined classes lost its code window, when reopened on another class type.<br />
* Fix: Proper class naming is now enforced in the type editor.<br />
<br />
<br />
== Release 2.7.5 (2015-06-09) ==<br />
'''New features''':<br />
* The JavaFX plugin now supports keyboard input. Use the block "''Request Focus''" to focus an input field and the block "''Type Text''" to enter any text.<br />
<br />
'''Bugfixes''':<br />
* The JavaFX plugin now provides improved connection handling.<br />
<br />
<br />
For expecco running under Linux you need glibc >= 2.14<br />
<br />
Tested technology versions:<br />
* Selenium<br />
* The Java Bridge requires a JDK version 1.6 or higher<br />
* JavaFX testing requires JavaFX 8<br />
* Qt: Qt 2.6.3 (MinGW, vs2008), Qt 4.8.4 (MinGW, vs2008, vs2010, vs2013), Qt 5.4.2 (vs2010, vs2013)<br />
* .NET<br />
* MFC<br />
* HTML 5<br />
* DevExpress<br />
* Android<br />
* iOS<br />
* Windows CE/Mobile Phone<br />
* CANoe: 8.2 SP4<br />
* WSDL-Import: it is required that you re-import your WSDL-Definitions in your Testsuites<br />
<br />
==Release 2.7.1 ==<br />
* Convenient menu functions to add the special [[Expecco API#Using a Particular JVM Connection / Executing Groovy on a Possibly Remote Machine|"java" and "groovy"]] input pins to a Groovy elementary block.<br />
* Standard library: new blocks: "''Directory [ Contents as Filenames ]''", "''Directory [ Contents as Pathnames ]''", "''Directory [ Contents as Basenames ]''", "''File [ isReadable? ]''" and "''File [ isWritable? ]''"<br />
<br />
==Release 2.7 ==<br />
* Patches go into a release specific directory (e.g. patches-2.7.0.5)<br />
* configurable external editor for attachments and csv data (e.g. excel or openoffice calculator)<br />
* tree view: markers in search lists; add to/remove from remembered list menu items<br />
* tree view: folders can have tags, too<br />
* tree view: per-tag icons in tree<br />
* [[Starting expecco via Command Line/en#Utility_Functions|"--diff" command line option]]<br />
* [[Starting expecco via Command Line/en#Startup|"--settings" command line option]]<br />
* Scatter/Gather composition of test plans from multiple suites [[Starting expecco via Command Line/en#Scatter Gather Test Suite Composition|via command line arguments]]<br />
* library: background OS process and background block actions<br />
* improved type checks and preference settings<br />
* schema editor: cursor up/down keys in pin name fields<br />
* schema and diagram editor: additional menu functions in multiple-pin selection menu<br />
* new blocks in the StandardLibrary: ExceptionClassifier, WriteCSV, Load/Save Environment from/to CSV<br />
* [[SAP Testing|SAP plugin and VBScript action blocks]]<br />
* change in the handling of Groovy callbacks. Please read [[Expecco API/en#Attention_.2F_Warning|"Attention / Warning"]] and [[Expecco API/en#Special_Functions|"Special Functions"]] in the Groovy API documentation.<br />
* improved Groovy debugging support<br />
* new common Android and iPhone/iPad testing framework<br />
* option to save a per-run report, when a suite is executed in a loop (especially useful, when running until fail or until success)<br />
* block assertions: assert-executed / assert-all outputs written / assert any output written<br />
* License server support<br />
<br />
<br />
==Release 2.6.2 bugfix release - April 2014 ==<br />
Thus is a stable release consisting of the 2.6.1 base version INCLUDING all 2.6.1 patches (up to April).<br />
<br />
==Release 2.6.1 update - January 2014 ==<br />
* [[Expecco API#Groovy_Elementary_Blocks|groovy action]]: the java-bridge can be passed in via pin named "java" or environment var named "JAVA". GroovyShell can be passed in via pin named "groovy" or variable named "GROOVY". Pins are optional for backward compatibility.<br />
<br />
==Release 2.6 - November 2013 ==<br />
* New testplan execution loop mode: "loop until required test fails"<br />
* More options for automatic check for and installation of updates & patches<br />
* Better default directories in file open/save/import dialogs.<br />
* Tuned automatic reimport when multiple libraries are imported.<br />
* Improved Java object inspector<br />
* New attachment contents representation modes.<br />
* Step tooltips include the underlying block's tree location.<br />
* Shift click on connection selects all underlying connections.<br />
* Give an indication (colorize menubar) if running with root/Admin rights.<br />
* Option to put the custom operations menu into the top menu<br />
* Additional tab in tree view to search by item-type<br />
* Additional search options for interfaces and concrete actions<br />
* Various bug fixes & enhancements:<br />
** handle duplicate attachment filenames,<br />
** fixed some type conversions,<br />
** fixed clipboard handling under XWindow/Qt desktop,<br />
** fixed non-changing testplan/testitem spec page.<br />
** added string search in resources, skills and inventories<br />
** no longer close expanded tree items when reimporting<br />
** fixed making an imported library writable, which is imported by another sub-import<br />
** fixed freeze of template pin to boolean/enum<br />
** fixed enum values which start with a digit (aka '001 aaa')<br />
** remove freeze value connection via menu<br />
<br />
<br />
==Release 2.5 ==<br />
* Can refer to [[Environment Editor#Initialization Types|shell environment variables]] in an environment variable's initializer.<br />
* New elementary block type: Groovy Code. Installs script code to be executed in a Java target or a local JVM.<br />
* New keyword driven actions<br />
* Additional checks in save dialogs to prevent overwriting another testsuite/library<br />
* Optional automatic reimport or check for reimportable imports (configure via settings dialog)<br />
* Additional freeze value validation when types are edited<br />
* New plugin: Jar Import<br />
* New and much improved manual test import plugin<br />
* Speedup, improvements and fixes in the JavaBridge plugin<br />
* Menu actions can [[Misc Editor#Background_Actions|execute in the background]] (name as "...&")<br />
* Background actions in testplan and testcase<br />
* Much faster: startup, plugin loading and bridge communication<br />
* Multiple freeze value menu organizations for enum types (hierarchical selection)<br />
<br />
===Release 2.5.1 - July 2013 ===<br />
<!-- This is a bugfix release, in which various patches and small enhancements from the past few months have been integrated.<br />
<br><br />
--><br />
* Automatic & semiautomatic update from server<br />
<br />
<br />
==Release 2.4 - February 2013 ==<br />
This is a bugfix release, in which various patches and small enhancements from the past few months have been integrated.<br />
<br />
<br />
==Release 2.3 - December 2012 ==<br />
* New integrated GUI Browser<br />
* New menu functions: "minimize/restore all Windows"<br />
* Polarion compatible report<br />
* Improved Project-Diff-Browser<br />
<br />
<br />
==Release 2.2==<br />
* New SchemaEditor menu functions: copy/paste pin interface<br />
* New plugin: [[GembirdPowerControlPlugin Reference#|Gembird Power Control Plugin]]<br />
* New debug-menu function: "close all temporary windows"<br />
* [[Probe|Probes]]; easy recording and check of pinValues<br />
* JUnit compatible report<br />
* HTTP and SOAP transmission log (optional on Transcript)<br />
* Fixed WSDL/SOAP for document-style operations<br />
* Better inspector (hex dump tab, hex representation of floats)<br />
<br />
<br />
==Release 2.1 - November 2011==<br />
* Condition variables for simple (and easy to use) control of testcase execution<br />
* [[Webservices#REST_Baustein|REST-Call]] blocks<br />
* Option to disable logging of activityNotifications (from the underlying language framework)<br />
* URL-override for SOAP service call blocks via the SOAP_URL environment variable.<br />
* Access to the certificate store (for SSL/HTTPS), allows adding and removing individual certificates<br />
* Elementary steps can have a variable number of output-pins (for multiplexer, dispatcher, round-robin generators etc.)<br />
* New menu function: "Generate Value Extractor" for Dictionary-typed pin values. (in the activityLog, output pin-data menu)<br />
* New tree-menu function: "Refactor"->"Change Variable Access", to search for and replace environment variable references.<br />
* New datatype [[Datatype Element#Special_Types|"struct"]], to represent arbitrary compound (struct) values.<br />
* GUI improvements: better annotation-text editors; line numbers, tags in file viewer<br />
* Allow for multi pin-value parametrization in testplan (block with multiple inputs in a testplan item)<br />
* Proxy support for HTTP-fetch blocks<br />
* Recording feature for Java Swing GUIs<br />
* Enhanced Java Swing Function Block Library<br />
* GUI Browser improvements: tree view with widget specific icons, record tree actions<br />
<br />
<br />
==Release 2.0==<br />
* Elementary steps can have a variable number of input-pins (improves the format, plus, string-concat and many other blocks)<br />
* Statistic page added to the project editor<br />
* Improved manual test import plugin; nicer Manualtest runner GUI; user definable manual test GUI<br />
* Allow for pin-value parametrization in testplan (block with a single input parameter in a testplan item)<br />
* Configurable max. cleanup time after terminating a run; Confirmation Dialog when longer.<br />
* ActivityLog: added "Select in Tree" from log-entry<br />
* HTTPS / SSL Support for HTTP blocks</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Release_Notes_1.x&diff=10569Release Notes 1.x2018-02-18T21:27:02Z<p>Mawalch: </p>
<hr />
<div>== Update Patch 1.9.1.1 ==<br />
(patch applied to the iX-Demo CD)<br />
<br />
* fixed the settings dialog's "mark new items" checkbox.<br />
* improved the termination timeout handling (long time spent in post action)<br />
* fixed the "search for active block" button's function<br />
* fixed a scroll-offset bug in the diagram editor<br />
&nbsp;<br />
<br />
== Release 1.9.1 ==<br />
Release date: Jan 2011<br />
<br>(release candidate: 1.8.3.30)<br />
<br />
* New blocks in the [[StandardLibrary ReleaseNotes#1.8.3|StandardLibrary 1.8.3]] and [[StandardLibrary ReleaseNotes#1.9.1|StandardLibrary 1.9.1]]<br />
* Separate model language translations<br />
* URL attachments<br />
* EBCDIC support<br />
* HP Quality Center Interface improved (up/download of tests and test-sets, autologout)<br />
* New plugin: Android Mobile Apps Interface<br />
* XMI import plugin improved (can now import test cases from Enterprise Architect models)<br />
* [[Java GUI Plugins|Java Swing plugin]] improved<br />
* Much improved Java-Bridge functionality: can now inject code dynamically<br />
* [[SeleniumLibrary Reference|Web Interfacing]] updated to use newest Selenium Version.<br />
* Improved browser profile handling (for example for proxy setup)<br />
* Firefox profile now includes Firebug and Firepath for web page analysis<br />
* additional [[SeleniumLibrary Reference|Web interface]] blocks (waitForAndXXX, table-accessors, table enumerators)<br />
* Optional cyclePeriod when looping a testplan<br />
* Suspend new activities when a debugger is open (option)<br />
* [[WebSphere MQ|WebSpere MQ (IBM Middleware interface)]] client interface plugin/library<br />
* Tagsearch includes Step-Tags<br />
* Can now save individual TestCase- and ActivityLog results to a file<br />
* New elementary block-type: Batch-script<br />
* Search for steps by name in result log<br />
* New variable-types in environment: [[Environment Editor#Initialization_Types|SecretConstant, RequestFromUserWhenFirstUsed and SecretFromUserWhenFirstUsed]]<br />
* Screenshot also via main menu<br />
* Code-editor now supports code completion (CTRL-Shift) and variable-correction (define as local or pin)<br />
* Optional sound when operator input is required<br />
* More execution control in the Control & Monitoring Window.<br />
* "Abort TestPlan" function in debugger.<br />
* Search for modified actions, search for values in tree<br />
* Improved XML-inspector (skip empty text, xml-text display)<br />
* Can now disable a plugin in the settings (will hide its menus)<br />
* Paste step with selected connection inserts the pasted step into the flow<br />
* improved single step function & breakpoint behavior<br />
* prerequisite package loading and prerequisite plugin checking<br />
* much improved [[AndroidLibrary Reference|Android mobile-phone testing support]]<br />
* rename variable menu-function<br />
* improved references to variable search function (looks into code)<br />
* embedded inspector (better environment variable value display) in the activity log<br />
* webtest functionality upgraded to current selenium/firefox versions<br />
* regex matching text search in tree (in addition to existing glob-matching search)<br />
* search for consumed input value in cycles (lint)<br />
* pause on error option in blockTester<br />
* default parallelity of new steps is now "limited to 1"<br />
* grouping of user defined types<br />
* shrink-wrap of imported libraries<br />
* colorize by tag configuration<br />
* customizable operation menu<br />
* improved the diff-viewer, added attachment diffs<br />
&nbsp;<br />
<br />
== Release 1.8.2 ==<br />
Release date: Jul 2010<br />
<br />
* Network Editor: allow connecting to a frozen pin (freeze to same value)<br />
* Network Editor: new menu function: "Extract Compound Action" (without replacing the selection)<br />
* Network Editor: new menu function: "Insert Step at Connection"<br />
* Network Editor: automatic "connect-through" when deleting steps from eni-eno chains<br />
* More testplan information for expeccoNET: operator needed; selectable testCases.<br />
* Search for halts and breakpoints<br />
* Breakpoint-toggling also in the log-viewer<br />
* Load resources from expeccoNET<br />
* New plugin: JIRA Interface (for issue validation)<br />
* New plugin: HP Quality Center Interface (up/download of test-suites)<br />
* New plugin/library: Swift-Message Handling<br />
* Fixed CTRL-a in some subviews<br />
* More attributes in annotations<br />
&nbsp;<br />
<br />
== Release 1.8.1 ==<br />
Release date: May 2010 (skipped for 1.8.2)<br />
<br />
* New blocks in the [[StandardLibrary ReleaseNotes#1.8.1|StandardLibrary 1.8.1]]<br />
* Triggering Mailbox Pins (see Collect Block as an example)<br />
* ExecutionTime-Output pin<br />
* More search options (search for virtual, iterated and exception handling steps)<br />
* New step flags: "Skip Children in Trace", "Assert Output Written" and "Assert Executed"<br />
* New Settings flag "Open Debugger for Handled Exceptions"<br />
* Report: can now include screenshots and other images<br />
* Report: new "Print as Flat List" option.<br />
* Report: speedup for big PDF reports<br />
* Elementary Code Editor: Senders and References search now includes elementary code in search<br />
&nbsp;<br />
<br />
== Release 1.8.0 ==<br />
Release date: April 2010 (skipped for 1.8.1)<br />
<br />
* Different connection styles (direct, curved)<br />
* WSDL import plugin fixed and enhanced.<br />
* Some report improvements (more variables)<br />
* XML-RPC Blocks<br />
* Jira Plugin<br />
* Skill, Resource and Inventory Interface for expeccoNET<br />
&nbsp;<br />
<br />
== Release 1.7.4 ==<br />
Release date: Februrary 2010<br />
<br />
* New blocks in the [[StandardLibrary ReleaseNotes#1.7.4|StandardLibrary 1.7.4]]<br />
* Implicit virtual block resolving specified in environment<br />
* Implicit virtual block resolving via virtual library specified in environment<br />
* Resource & skill access API fixed & enhanced<br />
* Enhanced display of virtual action in execution log<br />
* Fixed error-display in network if error occurs in action setup<br />
* Virtual blocks can now also be used as pre- and post-action<br />
* Fixed the input-pin handling of virtual blocks<br />
* [[Tools TestSuiteDifferenceBrowser|TestSuite diff viewer]] (to compare two project versions)<br />
* New tree-menu-functions: "Generate Instance Creator" & "Generate Field Extractor"<br />
* New tree-menu-function: "Sort Children"<br />
* New type-kind: CType.<br />
* Added a new kind of inspector-view: CDatumInspector to show C-data in a structured, hierarchical list<br />
* Non-Blocking DLL-calls<br />
&nbsp;<br />
<br />
== Release 1.7.3 ==<br />
Internal Release date: January 2010<br />
<br />
* New blocks in the [[StandardLibrary ReleaseNotes#1.7.3|StandardLibrary 1.7.3]]<br />
* Can now force connect of incompatible pins with CTRL-key<br />
* Default inventory now in testSuite (moved up from the testplan)<br />
* PostLoad & preUnload actions for suite and imported libraries<br />
&nbsp;<br />
<br />
== Release 1.7.2 ==<br />
Release date: October 2009<br />
<br />
* VariableList: added nameFilter and sortability<br />
* New blocks in the [[StandardLibrary ReleaseNotes#1.7.2|StandardLibrary 1.7.2]]<br />
&nbsp;<br />
<br />
== Release 1.7.1 ==<br />
Release date: September 2009<br />
<br />
* When saving test suites that were originally signed with a expecco demo version, convert all demo signatures to final signatures - if you have got a dongle.<br />
* Now can load test suites saved with expecco-developer with expecco-pro (and developer with pro - as long as you do not features that are supported only by expecco-pro in your test suite)<br />
* all blocks tagged in the [[StandardLibrary ReleaseNotes#1.7.1|StandardLibrary 1.7.1]]<br />
* new blocks in the [[StandardLibrary ReleaseNotes#1.7.1|StandardLibrary 1.7.1]]<br />
&nbsp;<br />
<br />
== Release 1.7.0 ==<br />
Release date: July 2009<br />
<br />
* RunTimeLimit for individual testCases<br />
* Better flyby info for steps and actions<br />
* Folders in the tree can have a documentation<br />
* Log files (.elf) are now zipped ([[HowtoReadZippedElf|Reading zipped .elf files with expecco < Rel1.7]])<br />
* WebTest: SeliniumRc has been updated to V1.0.1 and supports now Firfox3.5, Interne Explorer 8 and Google Chrome<br />
* New functions in network-editor:<br />
** Exchange connections of two pins;<br />
** Resize to min/max;<br />
** Better chooser for new steps;<br />
** Insert & connect function (find best match for selected pins);<br />
** "insert step" function ("select step and connection")<br />
** Can place and connect new steps via the menu without drag&drop (intelligent selection list)<br />
** Multiple pin variable-freeze<br />
** Drop connection onto a step (for trigger-in/trigger-out connection)<br />
** Connection-colors<br />
*In code-editor<br />
** F4/F5 (comment / uncomment) now also work with JavaScript code<br />
** Syntax color configuration in preferences dialog<br />
** "Implementors" menu-function fixed<br />
&nbsp;<br />
Bug Fixes and Improvements:<br />
* Sound file access fixed<br />
* Activity-log display update speed improved<br />
* Keep dialogs visible (auto raise windows from dialog-blocks)<br />
&nbsp;<br />
<br />
== Release 1.6 ==<br />
Release date: Mar 2009<br />
* Improved report, allows multiple report templates<br />
* Search for Missing Attachments<br />
* Optional Debug-Check of Pin Value against Pin Type (in elementary code)<br />
* Scripting (Remote Control)<br />
* "execute until success" loop feature<br />
* Attachment output can provide contents of file (instead of pathname)<br />
* SOA Testing: Generation of SOAP Call EB's from an imported WSDL (PRO Version only)<br />
* CodeGenerator can generate EB from a CB (PRO Version only)<br />
* More command line options for report generation (if executed via batch script)<br />
* "make your own elementary GUI" blocks with the UI Editor (PRO Version only)<br />
* Both console (expecco.com) and non-console (expecco.exe) executables are provided<br />
* --noBanner option<br />
* New blocks in the [[StandardLibrary ReleaseNotes#1.6.2|StandardLibrary 1.6.2]]<br />
&nbsp;<br />
<br />
== Release 1.5 ==<br />
Release date: 13.08.2008<br />
* File Attachment<br />
* Drag & Drop of Attachment<br />
* New ZIP-File Format<br />
* Improved Routing and Editor Functions<br />
* More Search Functions<br />
* Drag&Drop from Search<br />
&nbsp;<br />
<br />
== Release 1.4 ==<br />
* XML Parser Speedup<br />
* FileBrowser, Notebook and ProcessMonitor added<br />
* Acoustic test-execution feedback<br />
* Stop-on-Error can be turned off when running a TestSuite<br />
* Filter data messages in the Log-Viewer<br />
* Better presentation of detail-data in the Log-Viewer when double-clicking (Inspector)<br />
* Timelimit for testSuite execution<br />
* Looping & Loopcount for testSuite execution<br />
&nbsp;<br />
<br />
== Release 1.3 ==<br />
* Acoustic test-execution feedback<br />
* Stop-on-Error can be turned off when running a TestSuite<br />
* Filter data messages in the Log-Viewer<br />
* Better presentation of detail-data in the Log-Viewer when double-clicking (Inspector)<br />
* Timelimit for testSuite execution<br />
* Looping & Loopcount for testSuite execution<br />
* FileBrowser, Notebook and ProcessMonitor added<br />
&nbsp;</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Editoren&diff=10568Editoren2018-02-18T21:19:41Z<p>Mawalch: </p>
<hr />
<div>* [[Scheme Editor|Schemaeditor]]<br />
* [[ElementaryBlock Editor-Code Editor|Code Editor von Elementarblöcken]]<br />
<br />
* [[KeywordBlock Editor-KeywordActionList Editor|Keyword Aktionslisteneditor]]<br />
<br />
* [[CompoundBlock Editor-CompoundWorksheet Editor | Diagrammeditor von Compoundblöcken]]<br />
* [[CompoundBlock Editor-Environment Editor|Variableneditor von Compoundblöcken]]<br />
* [[BlockFunctionalityTestEditor|Block Test Editor]]<br />
* [[BlockFunctionalityRunner|Block Testlauf Editor]]<br />
* [[BlockSkill Editor]]<br />
<br />
* [[TestDataGeneratorBlock Editor-TestData Editor]]<br />
<br />
* [[TableDrivenBlock Editor-Table Editor]]<br />
<br />
* [[Testplan Editor-TestplanEnvironment Editor]]<br />
* [[Testplan Editor-TestplanListView Editor]]<br />
* [[Testplan Editor-ReportParameter Editor]]<br />
<br />
* [[Testsuite Editor-Environment Editor]]<br />
* [[Testsuite Editor-ExecutionSettings Editor]]<br />
* [[Testsuite Editor-ReportParameter Editor]]<br />
* [[Testsuite Editor-Metadata Editor]]<br />
* [[Testsuite Editor-StatisticData Editor]]<br />
<br />
* [[TestsuiteHistory Editor]]<br />
<br />
* [[Datatype Editor]]<br />
<br />
* [[Inventory Editor]]<br />
<br />
* [[ReportParameter Editor]]<br />
<br />
* [[Resource Editor]]<br />
<br />
* [[Skill Editor]]<br />
<br />
* [[CategoryContainer Editor]]<br />
<br />
* [[FileAttachment Editor]]<br />
<br />
* [[URLAttachment Editor]]<br />
<br />
* [[ReportTemplateAttachment Editor]]<br />
<br />
* [[GUI Editor-GUICode Editor]]<br />
<br />
* [[Documentation Editor|Dokumentationseditor]]<br />
* [[History Editor|Historyanzeige]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Weitere_Funktionen&diff=10567Weitere Funktionen2018-02-18T21:17:55Z<p>Mawalch: </p>
<hr />
<div>=== Im "''Extras''" - "''Werkzeuge''"-Menu ===<br />
* "''Explorer''" / "''Explorer In''...":<br>öffnet einen Windows Explorer in einem der Arbeitsverzeichnisse (nur auf Windows-Plattform)<br />
<br />
* "''Finder''" / "''Finder In''...":<br>öffnet einen Finder in einem der Arbeitsverzeichnisse (nur auf macOS-Plattform)<br />
<br />
* "''Bildschirmabzug ''":<br>erzeugt einen Abzug eines Bildschirmbereichs (in BMP-, PNG- oder TIFF-Format)<br />
<br />
* "''Bildschirmabzug gleicher Bereich ''":<br>erzeugt einen Abzug des vorigen Bereichs<br />
<br />
* [[Tools ModelTranslationEditor|"''Model Translation Editor''"]]:<br>Zur Definition von länderspezifischen Bezeichnungen von Elementen<br />
<br />
* [[Tools ImportScripts|"''Shell oder Batch Scripte Importieren''"]]:<br>Generiert Blöcke zur Ausführung bereits vorliegender Skripte.<br />
<br />
* [[Tools ImportAttachments|"''Anhänge Importieren''"]]:<br>Importiert ganze Ordner als Anhänge.</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Smalltalk&diff=10566Smalltalk2018-02-18T21:14:46Z<p>Mawalch: /* Smalltalk/X */</p>
<hr />
<div>= Smalltalk =<br />
<br />
== Pakete ==<br />
<br />
* [[ SOAP ]]<br />
* [[ SOAP WSDL ]]<br />
<br />
=Smalltalk/X=<br />
<br />
'''Smalltalk/X ist eine vollständige Implementierung der Programmiersprache Smalltalk, mit umfangreicher Klassenbibliothek und grafischer Entwicklungsumgebung'''<br />
<br />
<br><br />
<br />
Die Sprache beinhaltet modernste Konzepte kombiniert mit inkrementeller Übersetzung. Daraus resultieren extrem kurze turn-around-Zeiten und es erlaubt das Programmieren während das Programm läuft. Das macht Smalltalk/X zu einer der produktivsten Plattformen für die Projektentwicklung.<br />
Smalltalk/X ist schnell, sicher, stabil und leistungsfähig, stark in kritischen Projekten, im langjährigen Einsatz sowohl bei eXept als auch bei vielen Industriekunden und damit eine hervorragende Plattform zur Entwicklung von performanten und robusten Anwendungen.<br />
<br />
<br><br />
<br><br />
<br />
'''Durch klicken auf den Link "Alles über Smalltalk" werden Sie auf eine Seite geleitet welche Ihnen alle Details zu Smalltalk sowie Bspw. Allgemeine Informationen, einen Keyword Index oder ein System Overview näher bringt:<br />
'''<br />
<br />
<br><br />
[http://live.exept.de/doc/online/english/TOP.html Alles über Smalltalk]<br />
<br />
=Smalltalk und eXept=<br />
<br />
Smalltalk/X wurde komplett in unserem Haus entwickelt und wird ständig erweitert und gepflegt. Es stellt die Grundlage für unsere Produkte dar. Die Vorzüge von Smalltalk/X in Verbindung mit dem umfassenden Know-how unseres Teams machen eXept schnell und flexibel bei Entwicklung der technologisch führenden Testautomatisierungslösung expecco.</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:Test3.avi&diff=10565Datei:Test3.avi2018-02-18T21:13:39Z<p>Mawalch: </p>
<hr />
<div>[[Category:Marked for Deletion]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:Test2.mp4&diff=10564Datei:Test2.mp42018-02-18T21:13:25Z<p>Mawalch: </p>
<hr />
<div>[[Category:Marked for Deletion]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Datei:Testtt.mp4&diff=10563Datei:Testtt.mp42018-02-18T21:13:12Z<p>Mawalch: </p>
<hr />
<div>[[Category:Marked for Deletion]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Kommandozeile_%26_Remote_Control_Dienste&diff=10562Kommandozeile & Remote Control Dienste2018-02-18T12:54:16Z<p>Mawalch: </p>
<hr />
<div>=== Kommandozeile und Remote Control Dienste ===<br />
* [[Command Line Options|Kommandozeile, Optionen und RPC-Dienste]]<br />
** [[Command Line Options#Command_Line|Kommandozeile]]<br />
** [[Command Line Options#Expecco_SOAP_Service_Interface|Remote Steuerung mit SOAP]]<br />
** [[Command Line Options#Expecco_REST_Service_Interface|Remote Steuerung mit REST]]<br />
** [[Command Line Options#Scripting|Scripting mit File oder über Telnet]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Installation&diff=10561Installation2018-02-18T12:29:13Z<p>Mawalch: Minor rephrasing</p>
<hr />
<div>== Installation von expecco auf Windows ==<br />
<br />
Sie erhalten eine E-Mail mit dem Link zu den expecco-Installationsdateien. Die Installationsdateien haben z.B. die Namen<br />
<br />
* expeccoSetup-2.7.0.22.exe -> für die expecco-Basisinstallation<br />
* expeccoPluginSetup-2.7.0.22.exe -> für optionale Plugins.<br />
<br />
wobei hier 2.7.0 der Versionsnummer von expecco entspricht und 22 der Build-Nummer.<br />
Die Installationsdatei für die Plugins benötigen Sie nur dann, wenn Sie optionale Plugins lizenziert haben.<br />
Die Versionsnummer von ''expeccoSetup'' und ''expeccoPluginSetup'' muss gleich sein.<br />
<br />
Bitte laden Sie die Installationsprogramme auf Ihren Rechner.<br />
Führen Sie zuerst das Installationsprogramm für die expecco-Basisinstallation aus (''expeccoSetup-***.exe'').<br />
Folgen Sie dabei dem Installationsassistenten.<br />
Sie können hier das Laufwerk und das Verzeichnis angeben, unter dem expecco installiert werden soll.<br />
Außerdem können Sie die Komponenten angeben, die Sie installieren wollen.<br />
<br />
Falls Sie Plugins für expecco lizenziert haben, führen Sie jetzt das Installationsprogramm für die expecco-Plugins aus (''expeccoPluginSetup-***.exe'').<br />
Im Installationsassistenten können Sie zu installierende Plugins auswählen.<br />
Angeboten werden alle Plugins - auch solche für die Sie keine Lizenzen erworben haben.<br />
Falls Sie nicht lizenzierte Plugins installieren, ist deren Funktion in expecco nicht verfügbar und entsprechende Menu-Einträge entweder unsichtbar oder ausgegraut.<br />
Installierte, aber nicht lizenzierte Plugins sind erst dann verfügbar, wenn die dazu passenden Lizenzen (nach-)installiert wurden.<br />
Ansonsten belegen Sie nur Platz auf der Festplatte.<br />
Weitere Plugins können auch jederzeit nachträglich installiert werden. Auch können weitere Lizenzen jederzeit später erworben werden.<br />
<br />
Nach der Installation finden Sie auf Ihrem Desktop das expecco-Symbol.<br />
Über dieses Symbol können Sie expecco nun starten.<br />
Beim erstmaligen Ausführen, erscheint ein Fenster, in dem eine Lizenz verlangt wird.<br />
Je nachdem, ob Sie eine Einzellizenz oder eine Floating-Lizenz (per Lizenzserver) nutzen, müssen Sie die Lizenz entsprechend nachfolgender Beschreibung installieren.<br />
<br />
=== Automatische Installation von expecco via Commandline ===<br />
<br />
Sie können expecco über die Commandline via Batchdatei oder ähnlichem installieren. Führen Sie dazu expecco wie folgt aus:<br />
<br />
expeccoSetup-x.x.exe /S<br />
expeccoPluginSetup-x.x.exe /S<br />
<br />
Das "/S" steht für "Silent" und expecco installiert sich ohne GUI und ohne Fragen zu stellen.<br />
Sie können optional auch ein spezifisches Installationsverzeichnis angeben:<br />
<br />
expeccoSetup-x.x.exe /S /D="C:\Program Files (x86)\exept"<br />
expeccoPluginSetup-x.x.exe /S /D="C:\Program Files (x86)\exept"<br />
<br />
Damit expecco nach der Installation direkt starten kann, muss sichergestellt werden, dass eine Lizenz auf dem Zielrechner vorhanden ist. Hierfür kommen folgende Varianten in Frage.<br />
<br />
'''Lizenz aus lokaler Lizenzdatei und Dongle''':<br><br />
Stecken Sie den Dongle in den Zielrechner. Kopieren Sie Ihre Lizenzdatei in Ihr Benutzerverzeichnis bspw. "C:\Users\IhrBenutzername\" unter dem Name ".expeccoLicense", sodass die Datei "C:\Users\IhrBenutzername\.expeccoLicense" Ihrer Lizenzdatei entspricht.<br />
<br />
'''Lizenz vom Lizenzserver''':<br />
Hier müssen zunächst eine "Template" Lizenzdatei und "Template" expecco Einstellungen-Datei erstellt werden. Sie benötigen dafür ein laufendes expecco, welches mit Ihrem Lizenzserver verbunden ist. Starten Sie dieses expecco und konfigurieren Sie unter "Extras" -> "Einstellungen" -> "Lizenzinstallation" -> "Lizenz vom Lizenzserver" Ihre "Template" Lizenzdatei. Diese sollte alle Plugins, die auf dem Zielrechner für die automatisierte expecco Installation über Commandline benötigt werden, enthalten. Fordern Sie diese Lizenz vom Lizenzserver an. Setzen Sie den Haken "Lizenzserver nutzen" und drücken Sie anschließend "Sichern". expecco hat nun die benötigten Template Dateien unter "C:\Users\IhrBenutzername\AppData\Roaming\expecco" angelegt. Kopieren Sie die ".expeccoPreferences" und die "expeccoLicenseServerLicense" Datei vor der automatischen expecco Installation in das entsprechende Verzeichnis auf Ihrem Zielrechner. expecco kann somit direkt nach der automatischen Installation starten.<br />
<br />
=== Autostart von expecco ===<br />
<br />
Öffnen Sie dazu mit der Windows-Taste & "R" ein Ausführen-Fenster. Geben Sie dort "shell:startup" ein. Danach öffnet sich der Autostart-Ordner. Kopieren Sie die expecco-Verknüpfung vom Desktop in diesen Ordner. Nun wird expecco, nachdem sich dieser Benutzer angemeldet hat, automatisch gestartet. Folgend können Sie konfigurieren, dass sich dieser Benutzer automatisch anmeldet, wenn der Rechner angeschaltet wird. Drücken Sie dazu erneut Windows-Taste & "R". Geben Sie nun "netplwiz" ein. Es öffnet sich der Benutzerkonten-Dialog. In diesem können Sie den Haken "Benutzer müssen Benutzernamen und Kennwort eingeben" abwählen. Diese Einstellung gilt nur für das Anmelden nachdem der Rechner hochgefahren ist.<br />
<br />
Übrigens können diverse Parameter auf der [[Command Line Options|expecco-Kommandozeile]] angegeben werden. Hier sind insbesondere die Optionen [[Command Line Options#Startup|"--licenseFile"]], [[Command Line Options#Startup|"--licenseServer"]] und [[Command Line Options#Startup|"--licenseServerPort"]] zu erwähnen.<br />
<br />
=== Update Installation von expecco (Windows) ===<br />
<br />
Wie bei der Erstinstallation erhalten eine E-Mail mit dem Link zu den neuen expecco-Installationsdateien.<br />
Bitte laden Sie die Installationsprogramme herunter.<br />
Bei der Ausführung des Basis-Installationsprogramms ''expeccoSetup-***.exe'' erkennt expecco, dass es bereits installiert ist, und zeigt einen Dialog an, in dem Sie um eine Bestätigung gebeten werden, dass die alte expecco-Version deinstalliert werden darf.<br />
Bestätigen Sie bitte diesen Dialog. Die alte expecco-Version wird mit allen Plugins deinstalliert.<br />
Ihre Einstellungen, Lizenzdateien und Ihre Testsuiten bleiben erhalten.<br />
Anschließend wird die neue expecco-Version wie bei der Erstinstallation (s.o.) installiert.<br />
Installieren Sie ggf. die Plugins über die neue Installationsdatei ''expeccoPluginSetup-***.exe''.<br />
<br />
=== Lizenz installieren ===<br />
<br />
Beim erstmaligen Ausführen erscheint ein Fenster, in dem eine Lizenz verlangt wird. Je nachdem, ob Sie eine Einzellizenz oder eine Floating-Lizenz (per Lizenzserver) nutzen, können Sie die Lizenz konfigurieren.<br />
<br />
[[#Konfiguration der Einzellizenz | Konfiguration der Einzellizenz]]<br />
<br />
[[#Konfiguration der Floating-Lizenz | Konfiguration der Floating-Lizenz]]<br />
<br />
== Installation von expecco auf Linux ==<br />
<br />
=== Benötigte Linux Softwarepakete ===<br />
<br />
expecco läuft sowohl auf 32- als auch auf 64-bit Linux Systemen. Es ist als 32-bit-Programm übersetzt, und benötigt daher auch auf amd64/x86-64 - Installationen die Bibliotheken in der 32-bit Version. Es wird eine glibc in der Version >= 2.10 benötigt.<br />
<br />
Installieren Sie über Ihren Paketmanager Ihrer Linux-Distribution folgende Pakete (alle als 32-bit-Pakete):<br />
<br />
* libXinerama<br />
* libxrandr<br />
* libXft<br />
* libusb<br />
* unixODBC<br />
* libglib-2_0-0<br />
<br />
<br />
ACHTUNG: Falls Sie expecco 32-bit auf einem 64-bit OS installieren wollen, benötigen Sie auch den ld-linux für 32bit. Diesen können Sie mit folgendem Paket installieren:<br />
<br />
* libc6-i386<br />
<br />
Diese Pakete hängen von weiteren Paketen ab, die der Paketmanager automatisch mit installiert.<br />
<br />
In Ubuntu 15.04 (32-bit) installieren Sie die Pakete mit dem Kommando:<br />
<br />
sudo apt-get update && sudo apt-get install -y \<br />
libxinerama1 libxft2 libxrandr2 unixodbc odbcinst libusb-1.0.0<br />
<br />
<br />
In Ubuntu 15.04 (64-bit) für ein 32-bit expecco installieren Sie die Pakete mit dem Kommando:<br />
<br />
sudo apt-get update && sudo apt-get install -y \<br />
libxinerama1:i386 libxft2:i386 libxrandr2:i386 unixodbc:i386 odbcinst:i386 libusb-1.0.0:i386<br />
<br />
=== Installation von expecco (Linux) ===<br />
<br />
Sie erhalten eine E-Mail mit dem Link zu der expecco-Installationsdatei. Die Installationsdatei hat z.B. den Namen:<br />
<br />
* expecco-2.7.0.22.x86.package<br />
<br />
wobei hier 2.7.0 der Versionsnummer von expecco entspricht und 22 der Build-Nummer. Die Installationsdatei enthält das expecco-Basispaket sowie die Plugins.<br />
<br />
Für die Installation benötigen Sie bei einer erstmaligen Installation außerdem noch das ''autopackage'' Paket. Sie können es hier herunterladen: http://download.exept.de/transfer/autopackage/autopackage.tar.bz2. Entpacken Sie das Archive und installieren Sie dieses durch das Ausführen der INSTALL Datei im Root Verzeichnis des Archives. Sie werden ggf. gefragt ob die GUI Komponenten vom "Autopackage" herunter geladen und installiert werden sollen. Wählen Sie "NEIN" aus, da diese nicht benötigt werden und unter Umständen zu Fehlern führen können. <br />
<br />
Laden Sie die expecco-Installationsdatei und ggf. ''autopackage.tar.bz2'' in dasselbe Verzeichnis auf Ihrem Rechner.<br />
<br />
Sie können die Installation als Benutzer ''root'' oder als normaler Benutzer ausführen. Wenn Sie expecco als Benutzer ''root'' installieren, wird expecco im Verzeichnis ''/opt/expecco/bin'' installiert. Bei einer Installation als normaler Benutzer, wird expecco in Ihrem Home-Verzeichnis nach ''.local/bin'' installiert. <br />
<br />
Führen Sie aus:<br />
<br />
bash ./expecco-2.7.0.22.x86.package<br />
<br />
expecco wird daraufhin installiert, es erscheint folgende Ausgabe:<br />
<br />
<br />
# Preparing package: expecco - Graphical Test Modeling<br />
# Checking for required C library versions ... passed<br />
This may take a moment, please wait ... done<br />
# Installing package: expecco - Graphical Test Modeling (package 1 of 1)<br />
# 100%[==================================================] Extracting<br />
# Copying files to /opt/expecco/plugin<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/packages/exept/technologyBridge<br />
# Copying files to /opt/expecco/packages/exept/technologyBridge/javaBridge<br />
# Copying files to /opt/expecco/packages/exept/technologyBridge/javaBridge/javaBridge_Server_Client<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/packages/stx/libsnmp<br />
# Copying files to /opt/expecco/packages/stx/libsnmp/net-snmp-5.7.2/mibs<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/testsuites/libraries<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/bin<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/lib<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/packages/exept/expecco/doc<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/testsuites/libraries<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/testsuites/examples<br />
# 100%[==================================================] Copying<br />
# Copying files to /opt/expecco/packages/exept/expecco/reportGenerator/tools<br />
# Copying files to /opt/expecco/packages/exept/pdf/afm<br />
# 100%[==================================================] Copying<br />
# Installing USB Dongle access...<br />
# Updating package database...<br />
The following package was successfully installed:<br />
* expecco - Graphical Test Modeling<br />
This installation used 478.74 MiB (502.00 MB) of disk space.<br />
Remove this package by running package remove expecco from the command line.<br />
<br />
=== Spezielle Installations-Optionen ===<br />
<br />
Sie können das Verzeichnis, in das expecco installiert wird, wie folgt festlegen:<br />
<br />
bash expecco-2.7.0.22.x86.package<br />
Installation als root nach /opt/expecco (Starten mit: /opt/expecco/bin/expecco)<br />
<br />
bash expecco-2.7.0.22.x86.package --prefix /opt/expecco-2.7<br />
Installation als root nach /opt/expecco-2.7 (Starten mit: /opt/expecco-2.7/bin/expecco)<br />
<br />
bash expecco-2.7.0.22.x86.package --local-only<br />
Installation als Benutzer nach $HOME/.local (Starten mit ~/.local/bin/expecco)<br />
<br />
bash expecco-2.7.0.22.x86.package --local-only --prefix ~/expecco<br />
Installation als Benutzer nach $HOME/expecco (Starten mit ~/expecco/bin/expecco)<br />
<br />
=== Update Installation von expecco (Linux) ===<br />
<br />
Wie bei der Erstinstallation erhalten eine E-Mail mit dem Link zu der neuen expecco-Installationsdatei.<br />
Bitte laden Sie das Installationsprogramme herunter. Bei der Ausführung des Installationsprogramms ''bash expecco-***.x86.package'' erkennt expecco, dass eine andere Version bereits installiert wurde. Die alte expecco-Version wird mit allen Plugins automatisch deinstalliert. Ihre Einstellungen, Lizenzdateien und Ihre Testsuiten bleiben erhalten. Anschließend wird die neue expecco-Version wie bei der Erstinstallation (s.o.) installiert.<br />
<br />
=== Zusätzlich symbolische Links (libodbc,...) ===<br />
<br />
Aufgrund eines Fehlers in Ubuntu 14.04 und 14.10 müssen fehlende symbolische Links manuell angelegt werden. In Ubuntu 15.04 wurde der Fehler behoben.<br />
<br />
Es fehlen die Dateien: libodbc.so.2 sowie libodbcinst.so.2, die im Verzeichnis /usr/lib/i386-linux-gnu liegen.<br />
<br />
Die fehlenden Links können wie folgt angelegt werden:<br />
<br />
cd /usr/lib/i386-linux-gnu<br />
sudo ln -s libodbc.so.1 libodbc.so.2<br />
sudo ln -s libodbcinst.so.1 libodbcinst.so.2<br />
<br />
=== Lizenz installieren ===<br />
<br />
Installieren Sie die Lizenz wie im nächsten Abschnitt beschrieben.<br />
<br />
== Installation von expecco auf macOS ==<br />
<br />
Achtung: die macOS-Version ist z.Z. im Beta Test und lediglich auf Anfrage verfügbar.<br />
<br />
=== Benötigte macOS Softwarepakete ===<br />
<br />
expecco läuft auf 64-bit x64_64 macOS-Systemen (eine Version für ältere 32bit Maschinen ist auf Anfrage erhältlich). Es wird mindestens macOS 10.6 benötigt.<br />
<br />
expecco benötigt XQuartz. Dieses sollten Sie vorher vom Apple Store oder [https://www.xquartz.org/ xquartz.org] installieren, falls nicht bereits vorinstalliert (kostenlos).<br />
<br />
=== Installation von expecco (macOS) ===<br />
<br />
Sie erhalten eine E-Mail mit dem Link zu der expecco-Installationsdatei. Die Installationsdatei hat z.B. den Namen:<br />
<br />
* expecco-2.11.0.1.dmg<br />
<br />
wobei hier 2.11.0 der Versionsnummer von expecco entspricht und 1 der Build-Nummer. Die Installationsdatei enthält das expecco-Basispaket sowie die Plugins.<br />
<br />
Zur Installation öffnen Sie die "dmg"-Datei und verschieben "expecco.app" in den "Application"-Ordner (oder Ihren privaten "Application"-Ordner).<br />
<br />
== Konfiguration der Lizenz ==<br />
<br />
Beim erstmaligen Ausführen erscheint ein Fenster, in dem eine Lizenz verlangt wird. Falls Sie bereits eine Lizenz installiert haben und diese wechseln möchten können Sie den selben Dialog unter "Extras" -> "Einstellungen" -> "Lizenzinstallation" öffnen, allerdings müssen Sie in diesem Fall nach dem Wechseln der Lizenz expecco neu starten.<br />
<br />
[[#Konfiguration der Einzellizenz | Konfiguration der Einzellizenz]]<br />
<br />
[[#Konfiguration der Floating-Lizenz | Konfiguration der Floating-Lizenz]]<br />
<br />
[[#Auslösen einer Floating-Lizenz | Auslösen einer Floating-Lizenz]]<br />
<br />
=== Konfiguration der Einzellizenz ===<br />
<br />
Einzellizenzen werden üblicherweise mit einem USB-Dongle genutzt.<br />
Ausnahmsweise können auch zeitlich limitierte Einzellizenzen ohne Dongle verwendet werden (sog. "''Demo Lizenz''").<br />
In beiden Fällen erhalten Sie eine Lizenzdatei.<br />
Lizenzdateien und Dongle müssen jeweils zusammenpassen, wobei eine Lizenzdatei auch zu mehreren Dongles desselben Kunden passen kann.<br />
<br />
# falls Sie einen Dongle erhalten haben, stecken Sie ihn in einen freien USB-Port in Ihrem Rechner.<br />
# Speichern Sie die Lizenzdatei auf Ihrem Rechner<br />
# Ziehen Sie dann entweder die Datei mit der Maus aus dem Windows-Explorer in den Lizenzdialog, oder Sie wählen im Lizenzdialog Ihre Lizenzdatei direkt aus.<br />
# Sie werden aufgefordert, expecco neu zu starten. Nach dem Neustart können Sie expecco nutzen.<br />
<br />
Lizenzdateien ohne Dongle sind zeitlich beschränkt.<br />
Wenn Sie versehentlich den expecco-Dongle nicht in Ihren Rechner eingesteckt haben und expecco starten, erhalten Sie einen Hinweis, dass die Lizenz abgelaufen sei.<br />
Sobald Sie den Dongle einstecken (bevor Sie expecco starten), erscheint dieser Hinweis beim Start von expecco nicht mehr.<br />
<br />
Solange Sie mit expecco arbeiten, wird überwacht, ob der Dongle vorhanden ist.<br />
Wenn Sie den Dongle währenddessen aus Ihrem Rechner entfernen, erhalten Sie einen Hinweis und können keine Tests mehr ausführen oder verändern.<br />
Sie können allerdings die gerade bearbeitete Testsuite noch abspeichern, so dass keine Änderungen verloren gehen.<br />
<br />
=== Konfiguration der Floating-Lizenz ===<br />
<br />
Um eine Floating-Lizenz zu nutzen, benötigen Sie einen expecco-Lizenzserver.<br />
Der Lizenzserver ist unter einem Rechnername bzw. IP-Adresse und einer Portnummer zu erreichen.<br />
Der Administrator des Lizenzservers kann Ihnen diese Informationen geben, falls er eine andere als die default-Portnummer konfiguriert hat.<br />
Es muss sichergestellt sein, dass eine TCP-Verbindung zum entsprechenden Port im Lizenzserver aufgebaut werden kann.<br />
Router und Firewalls sind entsprechen zu konfigurieren bzw. Ports freizuschalten.<br />
<br />
Beim Start von expecco öffnet sich der Lizenzdialog.<br />
Wählen Sie hier die Lizenzserver-Kachel aus.<br />
Tragen Sie den Rechnernamen bzw. die IP-Adresse sowie die Portnummer des Lizenzservers ein.<br />
Im allgemeinen kann die vorgeschlagene default Portnummer unverändert übernommen werden.<br />
Lediglich in Netzwerken, bei denen nur bestimmte Ports durch Firewalls oder Router durchgeschaltet werden ist es u.U. notwendig, eine andere Portnummer zu verwenden.<br />
Der Administrator des Lizenzservers kann Ihnen in diesem Fall diese Informationen geben<br />
<br />
Sie können jetzt auswählen, welche expecco-Ausprägung Sie verwenden wollen: ''expecco-developer'' oder ''expecco-runtime''.<br />
Über die Schaltfläche ''Plugin-Liste vom Server aktualisieren'' erhalten Sie die verfügbaren Plugins (bzw. Plugins für die noch Floating-Lizenzen verfügbar sind).<br />
Wählen Sie die Plugins aus, die Sie für Ihre Tests benötigen.<br />
Von den meisten Plugins benötigen Sie nur eine Lizenz.<br />
Einzelne Plugins können für auf mehrere Rechner verteilte Tests mehr als eine Lizenz von einem Plugin benötigen - Sie können das für derartige Plugins angeben.<br />
Im Dialog wird angezeigt, wie viele Lizenzen für ein bestimmtes Plugin auf dem Lizenzserver momentan noch zur Verfügung stehen.<br />
Per Tooltip können Sie auch in Erfahrung bringen, wie viele Lizenzen generell vorhanden sind.<br />
Die Differenz sind die momentan von anderen Benutzern verwendeten Lizenzen.<br />
<br />
Über die Schaltfläche ''Lizenzdatei installieren'' werden die Lizenzen vom Lizenzserver abonniert.<br />
Starten Sie jetzt expecco neu, damit die lizenzierten Plugins geladen werden.<br />
<br />
Wenn expecco beendet wird, werden alle Lizenzen wieder an den Lizenzserver zurück gegeben.<br />
Expecco erneuert regelmäßig die Lizenzen vom Lizenzserver.<br />
Wenn der Lizenzserver über einen gewissen Zeitraum nicht mehr erreichbar sein sollte (ca. 15 Minuten), wird expecco gesperrt, so dass keine Tests mehr ausgeführt oder verändert werden können. Geänderte Testsuiten können aber noch abgespeichert werden.<br />
<br />
Wenn expecco nicht regulär beendet wurde, z.B. wenn der Rechner einfach ausgeschaltet wird, fallen die Lizenzen nach diesem Zeitraum an den Lizenzserver zurück und können dann von anderen Benutzern genutzt werden.<br />
<br />
expecco merkt sich, welche Lizenzen zuletzt abonniert wurden.<br />
Wenn expecco gestartet wird, versucht es, die zuletzt abonnierten Lizenzen wieder zu erhalten.<br />
Sollte das nicht möglich sein, da alle Lizenzen momentan vergeben sind, erscheint der Lizenzdialog, in dem die nicht oder nur teilweise erhaltenen Lizenzen rot unterlegt sind.<br />
<br />
Wenn Sie neue Lizenzen benötigen oder bisher verwendete Lizenzen nicht mehr benötigen, können Sie die anzufordernden Lizenzen jederzeit über den Lizenzdialog anpassen.<br />
Sie erreichen ihn über das Menü ''Extras -> Einstellungen -> Lizenzinstallation''.<br />
<br />
=== Auslösen einer Floating-Lizenz ===<br />
<br />
'''Verfügbar ab expecco Version 2.10.x.x'''<br />
<br />
Auch wenn Ihr expecco keine Netzwerkverbindung hat, ist es möglich expecco mit einer Floating-Lizenz zu betreiben. Die Lizenz für expecco wird für eine bestimmte Zeitspanne ausgelöst. Nachdem diese Zeitspanne verstrichen ist, wird die ausgelöste Lizenz automatisch wieder eingegliedert.<br />
<br />
'''Es gibt keine Möglichkeit eine ausgelöste Lizenz vor ihrem Ablauf wieder einzugliedern!'''<br />
<br />
Hierfür brauchen Sie einen Lizenzservice (expecco ALM), aus welchem die Floating-Lizenz ausgelöst wird.<br />
<br />
Zum Auslösen einer Floating-Lizenz starten Sie expecco und rufen Sie den Lizenzdialog unter "Extras" -> "Einstellungen" -> "Lizenzinstallation" auf (beim erstmaligem Start erscheint dieser automatisch) und navigieren Sie in den Reiter "Ausgelöste Floating-Lizenz".<br />
<br />
Dort haben Sie folgende Möglichkeiten:<br />
==== Eine Anfrage zum Auslösen einer Floating-Lizenz erstellen ====<br />
Stellen Sie sich Ihre gewünschte Lizenz zusammen. Definieren Sie den Typ (Runtime / Pro), die Plugins und wie lange Sie die Lizenz auslösen möchten. Sie können Ihre Anfrage dann entweder in eine Datei speichern oder in die Zwischenablage legen.<br />
<br />
Rufen Sie nun das Web-Interface vom Lizenzservice (expecco ALM) mit einem Gerät, welches darauf Zugang besitzt auf. Navigieren Sie in expecco ALM zu "Lizenzservice" -> "expecco Lizenzen" -> "Lizenz auslösen". Dort können Sie dann Ihre Anfrage entweder über Datei hochladen oder aus der Zwischenablage in das freie Feld einfügen.<br />
<br />
Nach dem erfolgreichen Einspielen Ihrer Anfrage wird Ihnen Ihre Anfrage zur Gegenprüfung im Detail angezeigt. Sie können hier die Dauer der Auslösung ggf. erneut anpassen. Über den Knopf "Auslösen bestätigen" wird die Lizenz endgültig ausgelöst. Danach ist diese Lizenz bis zum Ablauf der Dauer ausschließlich für das expecco, von welchem die Anfrage erstellt wurde reserviert. Ihnen wird anschließend der Bestätigungsschlüssel angezeigt. Diesen können Sie wiederum als Datei speichern oder über Rechtsklick "Kopieren" in die Zwischenablage legen.<br />
<br />
Jetzt müssen Sie diesen Bestätigungsschlüssel an expecco übertragen (über USB-Stick, Zuruf, Telefon usw.) und eingeben oder die Datei auswählen.<br />
<br />
==== Eine bereits ausgelöste Floating-Lizenz in Betrieb nehmen ====<br />
Falls Sie expecco aus Versehen während dem Prozess des Auslösens geschlossen haben oder der Prozess durch etwas ähnlich unterbrochen wurde, ist die ausgelöste Lizenz nicht verloren. Sie können diese Lizenz anhand Ihrer Anfrage und zugehörigem Bestätigungsschlüssel jederzeit in expecco aktivieren.<br />
<br />
Öffnen Sie dazu den Lizenzservice (expecco ALM) und navigieren Sie nach "Lizenzservice" -> "expecco Lizenzen" -> "Im Einsatz". Suchen Sie in dieser Liste nach einer passenden Lizenz. Eine passende Lizenz erkennen Sie bspw. an der Spalte "Rechnername", diese Spalte sollte mit dem Rechnernamen auf dem expecco installiert ist übereinstimmen. Übertragen Sie die Anfrage sowie den Bestätigungsschlüssel aus den Spalten "Auslöse-Anfrage-Datei" und "Auslösungsschlüssel" zu expecco.<br />
<br />
In expecco müssen Sie die Auslöse-Anfrage-Datei auswählen und diese dann mit dem Bestätigungsschlüssel aktivieren.<br />
<br />
==== Die aktuell verwendete ausgelöste Floating-Lizenz verlängern ====<br />
<br />
Das Verlängern einer ausgelösten Floating-Lizenz wird nur solange diese gültig ist unterstützt. Nach dem Ablauf der Lizenz muss man diese durch eine neue Anfrage erneuern.<br />
<br />
Öffnen Sie dazu den Lizenzservice (expecco ALM) und navigieren Sie nach "Lizenzservice" -> "expecco Lizenzen" -> "Im Einsatz". Suchen Sie in dieser Liste nach einer passenden Lizenz. Eine passende Lizenz erkennen Sie bspw. an der Spalte "Rechnername". Diese Spalte sollte mit dem Rechnernamen, auf dem expecco installiert ist, übereinstimmen.<br />
<br />
Klicken Sie nun auf "Verlängern". Sie werden automatisch auf die Seite "Lizenz verlängern" weitergeleitet. Ihre Lizenz ist bereits vorselektiert. Sie können nun das gewünschte Datum eingeben. Danach wird Ihnen ein neuer Bestätigungsschlüssel angezeigt, diesen müssen Sie in expecco eingeben.<br />
<br />
=== Änderung des Lizenztyps nach der Installation ===<br />
<br />
Über das Menü ''"Extras" - "Einstellungen" - "Lizenzinstallation"'' können Sie die Lizenz nachträglich ändern.<br />
<br />
'''Die Änderung des Lizenztyps werden permanent gespeichert, wenn Sie die Einstellung mit der Schaltfläche "Sichern" abspeichern.'''</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Import/Export_von_Spezifikationen&diff=10560Import/Export von Spezifikationen2018-02-18T12:22:41Z<p>Mawalch: </p>
<hr />
<div>* [[WSDL Service Import Plugin]] – importiert Servicebeschreibungen und generiert automatisch SOAP Serviceaktionen<br />
* [[XMI Diagram Import Plugin]] – importiert XMI Aktivitätsdiagramme aus Enterprise Architect</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Expecco_UI&diff=10559Expecco UI2018-02-18T12:21:22Z<p>Mawalch: </p>
<hr />
<div>* [[General Info on the Expecco UI|Allgemeine Informationen zum expecco Userinterface]]<br />
* [[Menu]] empty!<br />
* [[Toolbar]] empty!<br />
* [[Navigation Tree]] empty!<br />
* [[Settings]] empty!<br />
* [[Testsuite Browser]] empty!<br />
* [[Expecco Remote Control App]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Themensammlung&diff=10558Themensammlung2018-02-18T12:20:55Z<p>Mawalch: </p>
<hr />
<div>[[Online Documentation/en|English Version]]<br />
<br />
= expecco =<br />
<br />
== Release Notes ==<br />
<br />
* [[Release Notes expecco]]<br />
<br />
== Allgemeines, Übersicht, Konzepte ==<br />
<br />
* [[expecco Overview|Übersicht]]<br />
* [[expecco Architecture|Architektur von expecco]]<br />
* [[Concepts|Konzepte]] - Testplan, Testcase (Testfall), Activities (Aktivität), Verdicts (Ergebnisse)<br />
* [[Glossary|Glossar]]<br />
* [[FAQ]]<br />
=== Installation, Konfiguration & Einstellungen ===<br />
* [[Installation]] - Erstinstallation, Lizenzen, Patches<br />
* [[Configuration & Setup|Konfiguration und Einstellungen]] - JRE/JDK Einstellungen, Pfade<br />
* [[Personal Settings|Persönliche Einstellungen]] - Einstellungen des Editors<br />
=== Kommandozeile und Remote Control Dienste ===<br />
* [[Command Line Options|Kommandozeile, Optionen und RPC Dienste]]<br />
** [[Command Line Options#Command_Line|Kommandozeile]]<br />
** [[Command Line Options#Expecco_SOAP_Service_Interface|Remote Steuerung mit SOAP]]<br />
** [[Command Line Options#Expecco_REST_Service_Interface|Remote Steuerung mit REST]]<br />
** [[Command Line Options#Scripting|Scripting mit File oder über Telnet]]<br />
<br />
=== Anbindung expecco ALM ===<br />
Auf der Hilfeseite "[[Anbindung expecco ALM|Anbindung expecco ALM]]" erhalten Sie Informationen zu folgenden Themen:<br />
* Die Anbindung an expecco ALM an sich<br />
* Laden und Speichern der Testsuiten über expecco ALM<br />
* Die automatische Versionierung der Testsuiten durch expecco ALM<br />
* Das Speichern von Testresultaten nach expecco ALM<br />
* Die Testausführung über expecco ALM<br />
<br />
=== Reportgenerierung ===<br />
* [[Report Generation|Reportgenerierung]]<br />
<br />
== expecco UI ==<br />
<br />
* [[General Info on the Expecco UI|Allgemeine Informationen zum expecco Userinterface]]<br />
* [[Menu]] empty!<br />
* [[Toolbar]] empty!<br />
* [[Navigation Tree]] empty!<br />
* [[Settings]] empty!<br />
* [[Testsuite Browser]] empty!<br />
* [[Expecco Remote Control App]]<br />
<br />
==Elemente der Testsuite==<br />
<br />
* [[Tree Elements|"Tree"-Elemente]]<br />
<br />
* [[Folder Element|Ordner]]<br />
* [[Testplan Element|Testplan-Element]]<br />
* [[Block Element|Aktionen/Aktionsblöcke]]<br />
** [[ElementaryBlock Element|Elementare Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#Smalltalk_and_JavaScript_Blocks|Smalltalk Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#Smalltalk_and_JavaScript_Blocks|JavaScript Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#Groovy_Blocks|Groovy Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#VisualBasic_Blocks|VisualBasic Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#Shell_Script Blocks|Shell/Batch Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#DLL-Calls|DLL-Aufruf Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#SOAP-Calls|SOAP]], [[ElementaryBlock Element#REST-Calls|REST]] und [[ElementaryBlock Element#XML-RPC-Calls|XML-RPC]] Aktionsblöcke<br />
** [[CompoundBlock Element|Zusammengesetzte Aktionsblöcke]]<br />
** [[KeywordBlock Element|Keyword-Driven Aktionsblöcke]]<br />
** [[TestDataGeneratorBlock Element|Testdatengenerator]]<br />
** [[VirtualBlock Element|Virtuelle Aktion]]<br />
** [[UnimplementedBlock Element|Unimplementierte Aktion]]<br />
** [[GUIBlock Element|GUI Aktion]]<br />
* [[Datatype Element|Datentyp-Element]]<br />
* [[Inventory Element|Inventar-Element]]<br />
* [[Skill Element|Skill-Element]]<br />
* [[Resource Element|Ressource-Element]]<br />
* [[Attachment Element|Anhänge]]<br />
* [[ReportTemplate Element|Report-Templates]]<br />
<br />
== Editoren ==<br />
<br />
* [[Scheme Editor|Schemaeditor]]<br />
* [[ElementaryBlock Editor-Code Editor|Code Editor von Elementarblöcken]]<br />
<br />
* [[KeywordBlock Editor-KeywordActionList Editor|Keyword Aktionslisteneditor]]<br />
<br />
* [[CompoundBlock Editor-CompoundWorksheet Editor|Diagrammeditor von Compoundblöcken]]<br />
* [[CompoundBlock Editor-Environment Editor|Variableneditor von Compoundblöcken]]<br />
* [[BlockFunctionalityTestEditor|Block Test Editor]]<br />
* [[BlockFunctionalityRunner|Block Testlauf Editor]]<br />
* [[BlockSkill Editor]]<br />
<br />
* [[TestDataGeneratorBlock Editor-TestData Editor]]<br />
<br />
* [[TableDrivenBlock Editor-Table Editor]]<br />
<br />
* [[Testplan Editor-TestplanEnvironment Editor]]<br />
* [[Testplan Editor-TestplanListView Editor]]<br />
* [[Testplan Editor-ReportParameter Editor]]<br />
<br />
* [[Testsuite Editor-Environment Editor]]<br />
* [[Testsuite Editor-ExecutionSettings Editor]]<br />
* [[Testsuite Editor-ReportParameter Editor]]<br />
* [[Testsuite Editor-Metadata Editor]]<br />
* [[Testsuite Editor-StatisticData Editor]]<br />
<br />
* [[TestsuiteHistory Editor]]<br />
<br />
* [[Datatype Editor]]<br />
<br />
* [[Inventory Editor]]<br />
<br />
* [[ReportParameter Editor]]<br />
<br />
* [[Resource Editor]]<br />
<br />
* [[Skill Editor]]<br />
<br />
* [[CategoryContainer Editor]]<br />
<br />
* [[FileAttachment Editor]]<br />
<br />
* [[URLAttachment Editor]]<br />
<br />
* [[ReportTemplateAttachment Editor]]<br />
<br />
* [[GUI Editor-GUICode Editor]]<br />
<br />
* [[Documentation Editor|Dokumentationseditor]]<br />
* [[History Editor|Historyanzeige]]<br />
<br />
==Diagramm-Elemente==<br />
<br />
* [[DiagramElements-Step|Schritt]]<br />
<br />
* [[DiagramElements-Pin|Pins (Ein- und Ausgänge)]]<br />
<br />
** [[DiagramElements-Pin#Input Pin - Eingang]]<br />
*** [[DiagramElements-Pin#Enable Input Pin|Enable/Trigger Eingang]]<br />
*** [[DiagramElements-Pin#Cancel Input Pin|Cancel/Abbruch Eingang]]<br />
*** [[DiagramElements-Pin#Iterate Input Pin|Iterationszähler Eingang]]<br />
*** [[DiagramElements-Pin#Timelimit Input Pin|Zeitlimit Eingang]]<br />
*** [[DiagramElements-Pin#Performer Input Pin|Performer/Ausführer]]<br />
** [[DiagramElements-Pin#Output Pin - Ausgang]]<br />
*** [[DiagramElements-Pin#Exception Output Pin|Ausnahme Ausgang]]<br />
*** [[DiagramElements-Pin#Enable Output Pin|Enable/Trigger Ausgang]]<br />
*** [[DiagramElements-Pin#ExecutionTime Output Pin|Ausführungszeit Ausgang]]<br />
<br />
* [[DiagramElements-Connection|Verbindung]]<br />
<br />
* [[DiagramElements-AttachmentStep|Schritt mit Dateianhang]]<br />
* [[DiagramElements-PinDescription|Pin Beschreibung]]<br />
* [[DiagramElements-Annotation|Annotation/Notiz]]<br />
* [[DiagramElements-Probe|Messfühler]]<br />
<br />
== Werkzeuge ==<br />
<br />
=== Debugger ===<br />
<br />
* [[Tools Debugger|Debugger]]: Der eingebaute Debugger<br />
<br />
=== Weitere Werkzeuge im "Extras"-Menu ===<br />
<br />
* [[Tools Notepad|Notizblock]]: Ein Texteditor und Code-Ausführungsfenster (Miniscripte)<br />
<br />
* [[Tools FileBrowser|Dateibrowser]]: Werkzeug zum Suchen, zur Anzeige und Bearbeiten von Dateien<br />
<br />
* [[Tools ClassBrowser|Klassenbrowser]]: Werkzeug für Experten zur Exploration, Ansicht und Bearbeiten der unterliegenden Basisklassen<br />
<br />
* [[Tools ProcessMonitor|Prozessmonitor]]: Zeigt die laufenden Prozesse (Threads innerhalb expecco)<br />
<br />
* [[Tools Transcript|Transcript]]: Systemmeldungen, Nachrichten und Tracefenster<br />
<br />
* [[Tools TestSuiteDifferenceBrowser|Test Suite Difference Browser]]: Visualisiert Unterschiede zwischen Bausteinbibliotheken<br />
<br />
* [[Tools ReimportTool|Reimport Tool]]: Zum Prüfen der Abhängigkeiten und rekursiven Reimport von Bibliotheken<br />
<br />
=== Weitere Funktionen im "Extras"-Menu ===<br />
<br />
* "Explorer" / "Explorer In...":<br>öffnet einen Windows Explorer in einem der Arbeitsverzeichnisse (nur auf Windows-Plattform)<br />
<br />
* "Finder" / "Finder In...":<br>öffnet einen Finder in einem der Arbeitsverzeichnisse (nur auf Mac OSX-Plattform)<br />
<br />
* "Screenshot":<br>erzeugt einen Abzug des Bildschirms (in BMP-, PNG- oder TIFF-Format)<br />
<br />
* [[Tools ModelTranslationEditor|"Model Translation Editor"]]:<br>Zur Definition von Länderspezifischen Bezeichnungen von Elementen<br />
<br />
* [[Tools ImportScripts|"Import Shell oder Batch Scripts"]]:<br>Generiert Blöcke zur Ausführung bereits vorliegender Scripte.<br />
<br />
=== Low-Level Debugfunktionen im "Extras"-"Debugging"-Menu ===<br />
<br />
* [[ToolsMenuFunctions#ShowAllExternalConnections|"Zeige externe Verbindungen"]]:<br>findet offene Dateihandles/Filedescriptoren und zeigt diese in einem Inspektor.<br />
<br />
* [[ToolsMenuFunctions#ShutDownBridgeConnections|"Bridge Verbindungen Schließen"]]:<br>bricht bestehende/übrig gebliebene Java- und .NET-Bridgeverbindungen ab<br />
<br />
* [[ToolsMenuFunctions#CloseAllSocketConnections|"Alle Socket Verbindungen Schließen"]]:<br>bricht bestehende/übrig gebliebene Socket-Verbindungen (IPC) ab<br />
<br />
* [[ToolsMenuFunctions#CloseAllSerialConnections|"Alle Seriellen Verbindungen Schließen"]]:<br>bricht bestehende/übrig geblieben Verbindungen zur Seriellen Schnittstelle ab<br />
<br />
* [[ToolsMenuFunctions#ShowMemoryUsageByObjectType|"Speichernutzung per Objekttyp"]]:<br>Detailinformation zur Speicherauslastung<br />
<br />
* [[ToolsMenuFunctions#Memory_Cleanup|"Memory Cleanup"]]:<br>Erzwingt eine Bereinigung und Freigabe ungenutzter Ressourcen (insbes. Schließen von Dateien, Sockets, etc. die nicht mehr referenziert werden)<br />
<br />
== API von Elementaraktionen ==<br />
* [[Expecco API|Expecco API]] - Informationen für Entwickler von Elementarblöcken<br />
** [[Expecco API#JavaScript_and_Smalltalk_Elementary_Blocks|JavaScript und Smalltalk Elementaraktionen]]<br />
** [[Expecco API#Groovy_Elementary_Blocks|Groovy Elementaraktionen]]<br />
** [[Expecco API#VisualBasic_Elementary_Blocks|VisualBasic Elementaraktionen]]<br />
<br />
== Standard Libraries ==<br />
<br />
Die folgenden Bibliotheken sind bereits im Basispaket enthalten und müssen nicht separat lizenziert werden.<br />
<br />
* [[Standard Library]] -- Gemeinsame, domänenübergreifende Standardbibliothek<br />
* [[Expecco Reflection Library]] -- Aktionen um expecco selbst zu automatisieren<br />
* [[SeleniumLibrary Reference]] -- Testen von Webapplikationen in Webbrowsern (mit Selenium)<br />
<br />
== Schnittstellen zum getesteten System (System Under Test, SUT) ==<br />
<br />
* [[COM/OLE]] -- How to invoke COM interfaces<br />
* [[CORBA]] -- How to invoke CORBA interfaces<br />
* [[FTP]] -- FTP-Schnittstelle<br />
* [[HTTP]] -- HTTP-Schnittstelle<br />
* [[HTTPS]] -- HTTP (SSL) Schnittstelle<br />
* [[SOAP]] -- SOAP-Schnittstelle<br />
* [[XML-RPC]] -- XML-RPC Schnittstelle<br />
* [[REST]] -- REST-Schnittstelle<br />
* [[Telnet]] -- Telnet-Schnittstelle<br />
* [[Sockets]] -- Generische Low Level Socket Schnittstelle<br />
* [[Pipes]] -- Pipes<br />
* [[Shared Memory]] - Shared Memory<br />
* [[DLL Calls]]<br />
<br />
== Plugins und Erweiterungen ==<br />
<br />
=== UI Testing ===<br />
<br />
==== Web Browser UI Testing ====<br />
<br />
* [[Selenium Web Test Plugin]] -- Testen von Webapplikationen (Teil des Basissystems)<br />
* [[SeleniumLibrary Reference]] -- Library Referenz<br />
<br />
==== GUI Testing ====<br />
<br />
* [[Expecco GUI Tests Extension Reference|GUI Browser: Gemeinsame Basis der verschiedenen GUI Test Erweiterungen]]<br>Diese Erweiterung dient als Basis für die verschiedenen UI Technologieanbindungen. Sie ist Voraussetzung für (und beinhaltet in) den Erweiterungen für die Java GUI, Mobile GUI, Qt und Windows Automation GUI Erweiterungen.<br />
<br />
* [[Java GUI Plugins|Java Swing/SWT UI Testing]]<br>Diese Erweiterungen stellen Schnittstellen zu Anwendungen mit Java GUIs, basierend auf Swing und/oder SWT bereit.<br />
<br />
* [[Mobile Testing Plugin|Mobile Testing auf Android und iOS]]<br>Diese Erweiterung bietet Zugriff auf Mobilgeräte basierend auf Android und iOS. Die Kommunikation erfolgt über eine Appium-Schnittstelle.<br />
<br />
* [[VNC Plugin Reference|UI Testing über VNC]]<br>Diese Erweiterung realisiert den Zugriff auf UI-Anwendungen über die VNC (RFB) Schnittstelle. Mit dieser können beliebige Anwendungen getestet werden (sofern ein VNC-Server auf dem Zielsystem erreichbar ist), allerdings sind Attribute nur sehr eingeschränkt abrufbar. Sie dient daher vornehmlich als Fallback-Lösung, falls andere Plugins nicht zum Einsatz kommen können.<br />
<br />
* [[Qt Plugin Reference|UI Testing von Qt-Anwendungen]]<br>Diese Erweiterung realisiert den Zugriff auf UI-Anwendungen basierend auf dem Qt Framework.<br />
<br />
* [[OpenETS Plugin Reference|UI Testing von OpenETS Anwendungen]]<br>Diese Erweiterung realisiert den Zugriff auf UI-Anwendungen basierend auf dem OpenETS Framework. OpenETS ("Open Expecco Test Service") ist eine von eXept erhältliche C-Bibliothek, die Entwickler zu ihrem C-Programm binden, und die Kommunikation mit expecco übernimmt. Damit können beliebige C/C++ Anwendungen automatisiert werden.<br />
<br />
* [[WindowsAutomation Reference 1.0|Windows Automation GUI Access Interfacing Library]]<br>Realisiert den Zugriff auf Windows Anwendungen über die UI Automation Schnittstelle.<br />
<br />
* [[AutoIt Library|AutoIt GUI Interface Library]]<br>Bietet Zugriff auf Windows Anwendungen über AutoIt. Dies ist eine Low-Level Schnittstelle, welche nur eine eingeschränkte Sicht der Attribute von Komponenten erlaubt. Allerdings kann damit jedes GUI angesprochen werden, unabhängig von dessen darunterliegenden Technologie. Es ist daher oft hilfreich, wenn keinerlei Information über die Struktur des GUIs vorliegt.<br />
<br />
=== Code Ausführung ===<br />
* [[Groovy Code Execution Plugin]] -- erlaubt es mit Groovy, Programme im SUT auszuführen<br />
* [[VBScript|VisualBasic Script Plugin]] -- erlaubt es, VisualBasic Programme lokal oder im SUT auszuführen (nur Windows)<br />
* [[Java Browser]] -- Browser für Java-Klassen im SUT<br />
* [[Java Debugger]] -- debug Groovy Aktionen und andere Programme in einer Java VM (via Java Bridge)<br />
* [[SmallSense]] -- code completion für Groovy code.<br />
<br />
=== Plugins zur Unterstützung manueller/teilmanueller Tests ===<br />
* [[Manual Test Plugin]] -- führt den Tester (Bediener) durch manuelle Tests<br />
* [[Manual Test Import Plugin]] -- importiert Testspezifikationen aus Word- oder Exceldokumenten<br />
<br />
=== Verschiedene Plugins ===<br />
* [[GembirdPowerControlPlugin Reference]] -- kontrolliert eine fernsteuerbare Stromversorgung zum autom. An- bzw. Abschalten von Geräten (Teil des Basissystems)<br />
<br />
=== QM Schnittstellen ===<br />
<br />
* [[PolarionPlugin Reference]] - bringt Testautomatisierung mit expecco in das PolarionALM System<br />
* [[expecco ALM Plugin Reference]] - Testautomatisierung mit expecco ALM<br />
* [[HP Quality Center Plugin Reference]] - Testautomatisierung mit HP Quality Center<br />
* [[Jira Plugin Reference]] - Issue Einträge/Aktualisierung in Jira<br />
<br />
=== Import/Export von Spezifikationen ===<br />
<br />
* [[WSDL Service Import Plugin]] -- importiert Servicebeschreibungen und generiert automatisch SOAP Serviceaktionen<br />
* [[XMI Diagram Import Plugin]] -- importiert XMI Aktivitätsdiagramme aus Enterprise Architect<br />
<br />
=== Daten/Nachrichten/Dokument Formate ===<br />
<br />
* [[ASN.1 Support]] -- liest ASN.1-Spezifikationen; lesen/schreiben/verifizieren/modifizieren von ASN.1-codierten Nachrichten<br />
* [[GDMO Support]] -- lesen/schreiben/verifizieren/modifizieren von GDMO Objekten<br />
* [[DTD, XSD Support]] -- liest Datentyp-Spezifikationen<br />
* [[SWIFT Plugin]] -- lesen/schreiben/verifizieren/modifizieren von SWIFT Nachrichten<br />
* [[EDI/Edifact Plugin|EDI / EDIFACT Plugin]] -- lesen/schreiben/verifizieren/modifizieren von EDI/EDIFACT-Nachrichten; Liest Metabeschreibungen in verschiedenen Formaten;<br />
* [[EDI/Idoc Plugin|EDI / Idoc Plugin]] -- wird noch dokumentiert<br />
* [[EDI/X12 Plugin|EDI / X12 Plugin]] -- wird noch dokumentiert<br />
* [[PDF Support]] -- liest PDF Dateien; generiert PDF Dokumente<br />
* [[ODF Support]] -- liest ODF Dateien<br />
* [[JSON Support]] -- kodieren/dekodieren von JSON Nachrichten<br />
* [[PEG Parser]] -- zur schnellen Realisierung von Parsern für beliebigen Text/Nachrichten<br />
<br />
=== Kommunikation/Protokolle ===<br />
<br />
* [[FTP Support]] -- FTP client / FTP server / SFTP client<br />
* [[HTTP Support]] -- HTTP client / HTTP server<br />
* [[Telnet Protocol]] -- client / server<br />
* [[SSL Protocol]]<br />
* [[IMAP & POP3 Support]]<br />
* [[NFS Support]] -- server<br />
* [[Sun RPC Support]] -- client & server<br />
* [[Thrift Support]]<br />
* [[MQueue Plugin]] -- websphere/mainframe interface<br />
* [[Serial Port Communication]]<br />
* [[Parallel Port Communication]]<br />
* [[USB Port Communication]]<br />
* [[ChipCard/SmartCard Package]] - GSM, EC, ISO7816 cards and other standards via GemPlus, Oros and other interfaces<br />
* [[GPIB Interface]] - Schnittstelle für Messgeräte<br />
* [[CanBUS Interface]] - low level Zugriff über serielle oder USB Schnittstelle<br />
* [[LDAP Interface]]<br />
* [[OLE Interface]]<br />
<br />
=== Databases ===<br />
* [[ODBC Interface]] (Teil des Basissystems)<br />
* [[SQLite Interface]] (Teil des Basissystems)<br />
* [[Oracle Native Interface]]<br />
<br />
==== NoSQL ====<br />
* [[Cassandra Interface]]<br />
* [[CouchDB Interface]]<br />
* [[MongoDB Interface]]<br />
* [[SandstoneDB Interface]]<br />
* [[Goods-DB Interface]]<br />
<br />
=== API ===<br />
* [[Plugin API]] - Informationen für Plugin-Entwickler<br />
<br />
=== [[expecco Mobile Remote App|Mobile Remote App]] ===<br />
<br />
== Spezifische Anpassungen ==<br />
<br />
* [[User Defined Menu Items|Benutzerdefinierte Menus]]<br />
&nbsp;<br />
<br />
== Konzepte, Hinweise, Tipps und Tricks ==<br />
<br />
* [[expecco API]]<br />
* [[Executor]]<br />
* [[Executor#Activity]]<br />
<br />
* [[Generating Test Data|Generieren von Testdaten]]<br />
* [[Parametrizing Tests|Parametrisierung von Tests]]<br />
* [[Organizing Libraries|Organisieren von Bibliotheken]]<br />
* [[Reimporting a Library|Reimportieren von Bibliotheken]]<br />
* [[Uses of Tags|Nutzung von Etiketten (Tags)]]<br />
<br />
* [[Common Errors|Common Errors and How to Deal with them]]<br />
<br />
== Known Limitations ==<br />
* [[Numeric Limits]]<br />
* [[Supported Image File Formats]]<br />
* [[OSX Specific Limitations]]<br />
<br />
== Tutorials ==<br />
<br />
* [[Testing Java Applications using Groovy blocks]]<br />
<br />
= [[expecco ALM Architecture|expecco ALM]] =<br />
<br />
=== Release Notes ===<br />
* [[expecco ALM Release Notes 2.0.0|2.0.0]]<br />
* [[expecco ALM Release Notes 1.10.0|1.10.0]]<br />
* [[expecco ALM Release Notes 1.9.5|1.9.5]]<br />
<br />
=== Konzepte ===<br />
* [[expecco ALM Architecture|Architektur]]<br />
* [[expecco ALM User Permissions|Benutzerrechte]]<br />
<br />
== [[expecco ALM Installation|Installation]] ==<br />
<br />
== Erstmaliges Einrichten ==<br />
=== [[expecco ALM Einrichten Vorgehensweise|Vorgehensweise]] ===<br />
<br />
=== Benutzer einrichten ===<br />
=== Projekte einrichten ===<br />
=== Workflows festlegen ===<br />
<br />
== Module ==<br />
<br />
=== Testmanagement ===<br />
* [[Anbindung expecco ALM|expecco Anbindung an expecco ALM für Datenbank und Versionierung von Testsuiten]]<br />
<br />
=== Lizenzserver ===<br />
* [[License Server Overview|Übersicht]]<br />
* [[Lizenzservice Installation|Installation]] - Erstinstallation, Lizenzdateien, Updates<br />
<br />
=== Einstellungen ===<br />
* [[expecco ALM System Settings LDAP|System - Benutzeranmeldung über LDAP]]<br />
<br />
== Mobile Anwendung (Android) ==<br />
* [[expecco ALM App]]<br />
<br />
= Lizenzserver =<br />
* [[License Server Overview|Übersicht]]<br />
* [[Lizenzservice Installation|Installation]] - Erstinstallation, Lizenzdateien, Updates<br />
<br />
= Tutorials =<br />
* [[Testcenter Tutorial|expecco Testcenter]]<br />
<br />
= Smalltalk =<br />
<br />
== Pakete ==<br />
* [[SOAP]]<br />
* [[SOAP WSDL]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Expecco_Remote_Control_App&diff=10556Expecco Remote Control App2018-02-18T12:20:13Z<p>Mawalch: Mawalch verschob die Seite Expecco Remote Control APP nach Expecco Remote Control App: proper spelling</p>
<hr />
<div>=Einführung=<br />
<br />
Die Expecco Remote Control App dient zur Verfolgung und Interaktion mit einer laufenden Testsuite auf einem Android Mobilgerät (Telefon oder Tablet). Sie zeigt eine Liste der ausgeführten Testfälle, deren Status (Passed/Failed) und ermöglicht außerdem die Fernsteuerung (Stopp/Pause/Run) des Testlaufs, sowie das Beantworten von Eingabeaufforderungen.<br />
<br />
Zur Beantwortung von Eingabeaufforderungen muss die Testsuite nicht geändert werden: Warn- und Infoboxen, Ja/Nein Bestätigungen sowie Texteingaben die von der Suite erfragt werden, erscheinen auch auf dieser App, und können entweder am Bildschirm oder auf dem Mobilgerät beantwortet werden.<br />
<br />
Dies ist besonders praktisch, wenn technische Geräte, die eine manuelle Interaktion (Schalten, Ablesen oder Einstecken) erfordern, und dazu normalerweise der PC-Arbeitsplatz verlassen werden muss.<br />
<br />
Mit der Remote Control App können Sie nun die den Testlauf fortsetzen, ohne den Weg zurück zum PC gehen zu müssen.<br />
<br />
=Guide=<br />
# Installieren Sie die expecco Remote Control App (via Google Play) auf Ihr Android Device<br />
# starten Sie die App und verbinden sich mit einem laufenden expecco durch Eingabe des Hostnamen sowie Port.<br />
Sie können den Port in expecco beliebig konfigurieren, falls die Voreinstellung zu Konflikten mit anderen Diensten führt.<br />
Außerdem können Sie auf der Expecco-Seite ein Passwort vereinbaren, so dass dieses im Mobilgerät zuerst eingegeben werden muss (Pairing zu einem bestimmten Gerät).<br />
<br />
=Hauptansicht=<br />
Die Hauptansicht liefert Ihnen einen Überblick über den gerade ausgeführten Testplan, sowie den darin gerade ausgeführten Testfall.<br />
<br />
=Start/Stopp/Pause=<br />
Ein Klick auf Pause suspendiert den Lauf. Mit Run wird die Ausführung fortgesetzt.<br />
Durch klick auf Stopp kann er abgebrochen werden.<br />
<br />
=Anhänge und Kommentare=<br />
Sie können während dem Lauf ein Photo machen, und dieses als Anhang (Logeintrag) im Resultat ablegen.<br />
Auch können Kommentare eingegeben, die als Textanhang abgelegt werden.</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Expecco_Remote_Control_APP&diff=10557Expecco Remote Control APP2018-02-18T12:20:13Z<p>Mawalch: Mawalch verschob die Seite Expecco Remote Control APP nach Expecco Remote Control App: proper spelling</p>
<hr />
<div>#WEITERLEITUNG [[Expecco Remote Control App]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Aktionen/Aktionsbl%C3%B6cke&diff=10555Aktionen/Aktionsblöcke2018-02-18T12:16:05Z<p>Mawalch: </p>
<hr />
<div>* [[Block Element|Aktionen/Aktionsblöcke]]<br />
** [[ElementaryBlock Element|Elementare Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#Smalltalk_and_JavaScript_Blocks|Smalltalk Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#Smalltalk_and_JavaScript_Blocks|JavaScript Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#Groovy_Blocks|Groovy Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#VisualBasic_Blocks|VisualBasic Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#Shell_Script Blocks|Shell/Batch Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#DLL-Calls|DLL-Aufruf Aktionsblöcke]]<br />
*** [[ElementaryBlock Element#SOAP-Calls|SOAP]], [[ElementaryBlock Element#REST-Calls|REST]] und [[ElementaryBlock Element#XML-RPC-Calls|XML-RPC]] Aktionsblöcke<br />
** [[CompoundBlock Element|Zusammengesetzte Aktionsblöcke]]<br />
** [[KeywordBlock Element|Keyword-Driven Aktionsblöcke]]<br />
** [[TestDataGeneratorBlock Element|Testdatengenerator]]<br />
** [[VirtualBlock Element|Virtuelle Aktion]]<br />
** [[UnimplementedBlock Element|Unimplementierte Aktion]]<br />
** [[GUIBlock Element|GUI Aktion]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Mobile_Testing_Plugin&diff=10554Mobile Testing Plugin2018-02-18T12:08:33Z<p>Mawalch: Fix typo, cleanup</p>
<hr />
<div>= Einleitung =<br />
Mit dem Mobile Testing Plugin können Anwendungen auf Android- und iOS-Geräten getestet werden. Dabei ist es egal, ob reale mobile Endgeräte oder emulierte Geräte verwendet werden. Das Plugin kann (und wird üblicherweise) zusammen mit dem [[Expecco_GUI_Tests_Extension_Reference|GUI-Browser]] verwendet werden, der das Erstellen von Tests unterstützt. Zudem ist damit das Aufzeichnen von Testabläufen möglich.<br />
<br />
Zur Verbindung mit den Geräten wird [http://appium.io/ Appium] verwendet. Appium ist ein freies Open-Source-Framework zum Testen und Automatisieren von mobilen Anwendungen.<br />
<br />
Zur Einarbeitung in das Mobile Plugin empfehlen wir das [[#Tutorial|Tutorial]] zu bearbeiten. Dieses führt anhand eines Beispiels Schritt für Schritt durch die Erstellung eines Testfalls und erklärt die nötigen Grundlagen.<br />
<br />
= Installation und Aufbau =<br />
Zur Verwendung des Mobile Testing Plugins müssen Sie expecco inkl. Plugins installiert haben und Sie benötigen die entsprechenden Lizenzen. expecco kommuniziert mit den Mobilgeräten über einen Appium-Server, der entweder auf demselben Rechner wie expecco läuft, oder auf einem zweiten Rechner. Dieser muss für expecco erreichbar sein.<br />
<br />
'''Installationsübersicht mit expecco 2.11:'''<br />
* Appium-Server<sup>ab</sup> 1.6.4<br />
für Android-Geräte ab der Version 4.3:<br />
* Java JDK<sup>a</sup> Version 7 oder 8<br />
* Android SDK<sup>a</sup><br />
für iOS-Geräte ab Version 9.3:<br />
* Xcode 8.3.x<br />
* Apple-Entwickler-Zertifikat mit zugehörigem privaten Schlüssel<br />
* Provisioning Profile mit den verwendeten Mobilgeräten<br />
<sup>a</sup> enthalten in Mobile Testing Supplement<br><br />
<sup>b</sup> enthalten in Mobile Testing Supplement for Mac OS<br />
<br />
'''Installationsübersicht mit expecco 2.10:'''<br />
* Appium-Server<sup>ab</sup> 1.4.16<br />
für Android-Geräte ab der Version 2.3.3 bis Version 6.0:<br />
* Java JDK Version<sup>a</sup> 7 oder 8<br />
* Android SDK<sup>a</sup><br />
für iOS-Geräte bis Version 9.3:<br />
* Xcode 7.3.x<br />
* Apple-Entwickler-Zertifikat<sup>c</sup> mit zugehörigem privaten Schlüssel<br />
* Provisioning Profile<sup>c</sup> mit den verwendeten Mobilgeräten<br />
<sup>a</sup> enthalten in Mobile Testing Supplement<br><br />
<sup>b</sup> enthalten in Mobile Testing Supplement for Mac OS<br><br />
<sup>c</sup> zum Signieren der App<br />
<br />
Beachten Sie, dass aufgrund der Voraussetzungen iOS-Geräte nur von einem Mac aus angesteuert werden können. expecco kann dann über das Netzwerk mit dem Appium-Server auf dem Mac kommunizieren, um auf den dort angeschlossenen iOS-Geräten zu testen. Im Folgenden wird die Installation von Appium und anderer nötiger Programme für Windows und Mac OS erklärt.<br />
<br />
[[Datei:MobileTestingAufbau.png | 400px]]<br />
<br />
== Windows ==<br />
Am einfachsten installieren Sie alles mit unserem Mobile Testing Supplement:<br />
<br />
*'''expecco 2.11''': [http://download.exept.de/transfer/h-expecco-2.11.1/MobileTestingSupplement_1.6.0.2_Setup.exe Mobile Testing Supplement 1.6.0.2]<br />
:Dieses installiert ein Java JDK der Version 8, android-sdk und Appium in der Version 1.6.4. Außerdem bietet das Supplement auch einen universellen adb-Treiber ([http://download.clockworkmod.com/test/UniversalAdbDriverSetup.msi ClockworkMod]) an. Dieser vereint Treiber für ein breites Spektrum an Android-Geräten, sodass Sie nicht für jedes Gerät einen eigenen Treiber suchen und installieren müssen.<br />
*expecco 2.10: [http://download.exept.de/transfer/h-expecco-2.10.0/Mobile_Testing_Supplement_1.5.0.0_Setup.exe Mobile Testing Supplement 1.5.0.0]<br />
:Dieses installiert ein Java JDK der Version 8, android-sdk und Appium in der Version 1.4.16. Während der Installation wird die grafische Oberfläche von Appium gestartet, dieses Fenster können Sie sofort wieder schließen. Außerdem bietet das Supplement auch einen universellen adb-Treiber ([http://download.clockworkmod.com/test/UniversalAdbDriverSetup.msi ClockworkMod]) an. Dieser vereint Treiber für ein breites Spektrum an Android-Geräten, sodass Sie nicht für jedes Gerät einen eigenen Treiber suchen und installieren müssen.<br />
<br />
Beim Starten von Appium kann es vorkommen, dass die Windows-Firewall den Node-Server blockiert. In diesem Fall kann expecco keinen Appium-Server starten. Starten Sie daher nach der Installation am besten die Datei ''appium.cmd'' im Ordner ''appium'' des Mobile Testing Supplements. Wenn sich der Appium-Server starten lässt, sollte es auch von expecco aus funktionieren. Meldet sich hingegen die Windows-Firewall, lassen Sie den Zugriff zu.<br />
<br />
== Mac OS ==<br />
=== expecco 2.11 ===<br />
Auf dem verwendeten Mac sollte als Betriebssystemversion OS X 10.12 (Sierra) und Xcode 8.3 oder neuer laufen. Sie können eine aktuelle Version von Xcode über den App Store installieren. Außerdem benötigt Appium eine Java-Installation. Installieren Sie dazu ein JDK in Version 7 oder 8. Mithilfe unseres [http://download.exept.de/transfer/h-expecco-2.11.1/Mobile_Testing_Supplement_for_Mac_OS_1.0.94.tar.bz2 Mobile Testing Supplements für Mac OS (1.0.94)] können Sie nun noch Appium 1.6.4 installieren. Nachdem Sie es heruntergeladen haben, können Sie es in ein Verzeichnis Ihrer Wahl (z. B. Ihr Home-Verzeichnis) verschieben und dort entpacken. Ein geeigneter Befehl in einer Shell könnte so aussehen:<br />
<br />
tar -xvpf Mobile_Testing_Supplement_for_Mac_OS_1.0.94.tar.bz2<br />
<br />
''Hinweis: Zur Automatisierung von iOS-Geräten ab Version 10 ist grundsätzlich eine Installation von einem vergleichbar neuen Xcode 8 nötig (für iOS 10.'''2''' mind. Xcode 8.'''2''', für iOS 10.'''3''' mind. Xcode 8.'''3''', usw.), die auf älteren Betriebssystemen möglicherweise nicht läuft. Wenn Sie also auf eine neuere iOS-Version wechseln, benötigen Sie in der Regel auch eine neuere Xcode-Version, was wiederum eine Aktualisierung des Betriebssystems erforderlich machen kann (siehe auch [https://en.wikipedia.org/wiki/Xcode#Version_comparison_table Xcode-Versionen]).''<br />
<br />
Wenn Xcode 8.3 oder neuer Ihre Standard-Xcode-Installation ist, können Sie Appium direkt starten:<br />
Mobile_Testing_Supplement/bin/start-appium-1.6.4<br />
Falls kein ausreichend neues Xcode als Standard konfiguriert ist, müssen Sie Appium den entsprechenden Pfad über die Umgebungsvariable ''DEVELOPER_DIR'' angeben. Wenn Sie Xcode z. B. in ''/Applications/Xcode-8.3.app'' installiert haben, können Sie Appium so starten:<br />
DEVELOPER_DIR="/Applications/Xcode-8.3.app/Contents/Developer" Mobile_Testing_Supplement/bin/start-appium-1.6.4<br />
Was in Ihrem System als Standard-Xcode-Installation gesetzt ist, können Sie mit diesem Befehl herausfinden:<br />
xcode-select -p<br />
Wenn Appium Ihre Xcode-Installation nicht findet, erscheint beim Verbinden eine Fehlermeldung in der Art:<br />
''<blockquote>org.openqa.selenium.SessionNotCreatedException - A new session could not be created. (Original error: Could not find path to Xcode, environment variable DEVELOPER_DIR set to: /Applications/Xcode.app but no Xcode found)</blockquote>''<br />
Starten Sie in einem solchen Fall Appium erneut unter Angabe eines gültigen ''DEVELOPER_DIR''.<br />
<br />
Um eine Testverbindung mit einem Gerät aufbauen zu können, brauchen Sie einen Apple-Account. Zur Evaluierung können Sie einen kostenlosen Account verwenden. Dieser hat den Nachteil, dass erstellte Profile nur eine Woche gültig sind und danach neu erstellt werden müssen. Seien Sie auch vorsichtig, wenn Sie sich den Account teilen, da es vorkommen kann, dass Zertifikate widerrufen werden oder durch automatische Generierung ungültig werden. Als Folge können bereits signierte Apps nicht mehr verwendet werden.<br />
<br />
Schließen Sie zuerst das Gerät, das Sie verwenden möchten, über USB an den Mac an. Starten Sie Xcode und öffnen Sie ''Preferences''. Wechseln Sie zur Seite der Accounts und legen Sie einen Eintrag mit Ihrem Account an. Anschließend können Sie auf ''Manage Certificates...'' klicken, um die Zertifikate zu sehen, die zu diesem Account gehören. Zum Ausführen von Tests benötigen Sie ein iOS-Development-Zertifikat und den dazugehörigen privaten Schlüssel. Wenn Sie noch keines besitzen, erstellen Sie eines. Wenn Sie bereits eines haben, aber es nicht in Ihrem Schlüsselbund vorhanden ist (erkennbar an dem Hinweis "Not in Keychain"), können Sie es importieren. Öffnen Sie in jedem Fall die Schlüsselbundverwaltung auf dem Mac und wählen Sie den Schlüsselbund ''Anmeldung'' aus. Wenn Sie ein Zertifikat aus einer PKCS#12-Datei (Endung typischerweise .p12) importieren wollen, geht das über das Menü ''Ablage'' > ''Objekte importieren''. Falls Sie nicht wissen, wo das Zertifikat gespeichert ist, können Sie es in Xcode auch widerrufen und in Ihrem Schlüsselbund neu anlegen. Machen Sie das jedoch nur, wenn Sie wissen, dass das alte Zertifikat nicht mehr in Verwendung ist, da es danach nicht mehr benutzt werden kann. Nun sollte der Schlüsselbund ein iOS-Development-Zertifikat enthalten. Wählen Sie im Rechtsklick-Menü den Punkt ''Informationen'' aus. Unter den Details des Zertifikats finden Sie die Team-ID, die hier als Organisationseinheit bezeichnet wird. Tragen Sie diese in den Einstellungen des Plugins im Feld ''Team-ID'' ein, siehe [[#Konfiguration_des_Plugins|Konfiguration des Plugins]].<br />
<br />
Kehren Sie zu Xcode zurück und wählen Sie im Menü ''File'' den Eintrag ''Open...'', um das WebDriverAgent-Projekt zu öffnen. Dieses befindet sich im Verzeichnis des Mobile Testing Supplements unter<br />
''<nowiki>Mobile_Testing_Supplement/lib/node_modules/appium-1.6.4-beta/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj</nowiki>''<br />
<br />
[[Datei:MobileTestingWebDriverAgentXcode.png]]<br />
<br />
Wählen Sie ''WebDriverAgentLib'' und die Seite ''General'' aus. Setzen Sie dort im Abschnitt ''Signing'' die Option ''Automatically manage signing'' und wählen Sie dann ein Team aus. Wechseln Sie nun zu ''WebDriverAgentRunner'' und ebenfalls zur Seite ''General''. Setzen Sie auch hier das automatische Signieren und wählen Sie auch hier Ihr Team aus. Es sollten an dieser Stelle Fehler angezeigt werden, dass kein Provisioning Profile angelegt oder gefunden wurde. Wechseln Sie deshalb zur Seite ''Build Settings'' und suchen Sie hier im Abschnitt ''Packaging'' den Eintrag ''Product Bundle Identifier''. Ändern Sie diesen von com.facebook.WebDriverAgentRunner zu etwas, das von Xcode akzeptiert wird, indem Sie den Präfix ändern. Xcode kann nun ein passendes Provisioning Profile generieren und die Fehler auf der General-Seite sollten verschwinden. Danach können Sie Xcode beenden.<br />
<br />
Wenn Sie sich nun von expecco eine Verbindung zu Ihrem Gerät aufbauen, wird der WebDriverAgent darauf installiert und gestartet, um anschließend zur zu testenden App zu wechseln. Auf dem Gerät muss jedoch noch der Ausführung des WebDriverAgents vertraut werden. Öffnen Sie dazu während des Verbindungsaufbaus auf dem Gerät in die Einstellungen und dort unter ''Allgemein'' den Eintrag ''Geräteverwaltung''. Dieser Eintrag ist nur sichtbar, wenn eine Entwickler-App auf dem Gerät installiert ist. Sie müssen daher möglicherweise warten, bis der WebDriverAgent installiert ist, bevor der Eintrag erscheint. Wählen Sie dort den Eintrag Ihres Apple-Accounts und vertrauen Sie ihm. Da der WebDriverAgent wieder deinstalliert wird, wenn der Start nicht funktioniert hat, müssen Sie dies während des Verbindungsaufbaus tun. Falls Ihnen das zu hektisch ist, können Sie auch folgenden Code ausführen:<br />
<br />
''<nowiki>xcodebuild -project Mobile_Testing_Supplement/lib/node_modules/appium-1.6.4-beta/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination 'id=<udid>' test</nowiki>''<br />
<br />
Damit wird der WebDriverAgent auf dem Gerät installiert ohne dass er wieder gelöscht wird. In der [https://support.apple.com/en-us/HT204460 Dokumentation von Apple] finden Sie nähere Infos zum Installieren und Vertrauen solcher Apps.<br />
<br />
=== expecco 2.10 ===<br />
Auf dem verwendeten Mac sollte als Betriebssystemversion OS X 10.11.5 (El Capitan) oder neuer laufen. Zur Automatisierung mit iOS-Geräten bis Version 9.3 ist eine Installation von Xcode 7.3 nötig, die auf älteren Betriebssystemen nicht läuft (siehe auch [https://en.wikipedia.org/wiki/Xcode#Version_comparison_table Xcode-Versionen]). Installieren Sie Xcode aus dem App Store. Außerdem benötigt Appium eine Java-Installation. Installieren Sie dazu ein JDK in Version 7 oder 8. Mithilfe unseres [http://download.exept.de/transfer/h-expecco-2.10.0/Mobile_Testing_Supplement_for_Mac_OS_1.0.tar.bz2 Mobile Testing Supplements für Mac OS] können Sie nun noch Appium 1.4.16 installieren. Nachdem Sie es heruntergeladen haben, können Sie es in ein Verzeichnis Ihrer Wahl (z. B. Ihr Home-Verzeichnis) verschieben und dort entpacken. Ein geeigneter Befehl in einer Shell könnte so aussehen:<br />
tar -xvpf Mobile_Testing_Supplement_for_Mac_OS_1.0.tar.bz2<br />
Wenn Xcode 7.3 Ihre Standard-Xcode-Installation ist, können Sie Appium direkt starten:<br />
Mobile_Testing_Supplement/bin/start-appium-1.4.16<br />
Falls Xcode 7.3 nicht als Standard-Xcode konfiguriert ist, müssen Sie Appium den entsprechenden Pfad über die Umgebungsvariable ''DEVELOPER_DIR'' angeben. Wenn Sie Xcode z. B. in ''/Applications/Xcode-7.3.app'' installiert haben, können Sie Appium so starten:<br />
DEVELOPER_DIR="/Applications/Xcode-7.3.app/Contents/Developer" Mobile_Testing_Supplement/bin/start-appium-1.4.16<br />
Was in Ihrem System als Standard-Xcode-Installation gesetzt ist, können Sie mit diesem Befehl herausfinden:<br />
xcode-select -p<br />
Wenn Appium Ihre Xcode-Installation nicht findet, erscheint beim Verbinden eine Fehlermeldung in der Art:<br />
''<blockquote>org.openqa.selenium.SessionNotCreatedException - A new session could not be created. (Original error: Could not find path to Xcode, environment variable DEVELOPER_DIR set to: /Applications/Xcode.app but no Xcode found)</blockquote>''<br />
Starten Sie in einem solchen Fall Appium erneut unter Angabe eines gültigen ''DEVELOPER_DIR''.<br />
<br />
== Konfiguration des Plugins ==<br />
Bevor Sie loslegen, sollten Sie die Einstellungen des Mobile Testing Plugins überprüfen und ggf. anpassen. Öffnen Sie im Menü den Punkt ''Extras'' > ''Einstellungen'' und dort unter ''Erweiterungen'' den Eintrag ''Mobile Testing'' (s. Abb.). Standardmäßig werden diese Pfade automatisch gefunden (1). Um einen Pfad manuell anzupassen, deaktivieren Sie den entsprechenden Haken rechts davon. Sie erhalten in einer Drop-down-Liste einige Pfade zur Auswahl. Ist ein eingetragener Pfad falsch oder kann er nicht gefunden werden, wird das Feld rot markiert und es erscheint ein diesbezüglicher Hinweis. Stellen Sie sicher, dass alle Pfade richtig angegeben sind.<br />
<br />
[[Datei:MobileTestingEinstellungen.png | thumb | 400px | Konfiguration des Plugins]]<br />
<br />
*'''appium''': Geben Sie hier den Pfad zur ausführbaren Datei an mit der Appium in der Kommandozeile gestartet werden kann. Unter Windows wird diese Datei in der Regel ''appium.cmd'' heißen. Dieser Pfad wird benutzt, wenn expecco einen Appium-Server startet.<br />
*'''node''': Geben Sie hier den Pfad zur ausführbaren Datei an, die Node startet. Dieser Pfad wird beim Starten eines Servers an Appium weitergegeben, damit Appium ihn unabhängig von der PATH-Variablen findet. Unter Windows heißt diese Datei in der Regel ''node.exe''.<br />
*'''JAVA_HOME''': Geben Sie hier den Pfad zu einem JDK an. Dieser Pfad wird an jeden Appium-Server weitergegeben. Lassen Sie das Feld frei, um den Wert aus der Umgebungsvariablen zu verwenden. Um einzustellen, welches Java von expecco verwendet werden soll, setzen Sie diesen Pfad in den Einstellungen für die Java Bridge.<br />
*'''ANDROID_HOME''': Geben Sie hier den Pfad zu einem SDK von Android an. Dieser Pfad wird an jeden Appium-Server weitergegeben. Lassen Sie das Feld frei, um den Wert aus der Umgebungsvariablen zu verwenden.<br />
*'''adb''': Hier steht der Pfad zum adb-Befehl. Unter Windows heißt die Datei adb.exe. Diese wird von expecco beispielsweise verwendet, um die Liste der angeschlossenen Geräte zu erhalten. Diesen Pfad sollten Sie automatisch wählen lassen, da dann der Befehl im ANDROID_HOME-Verzeichnis verwendet wird. Dieser wird auch von Appium verwendet. Falls expecco und Appium jedoch verschiedene Versionen von adb verwenden kann es zu Konflikten kommen.<br />
*'''android.bat''': Diese Datei wird nur benötigt, um damit den AVD und den SDK Manager zu starten. Automatisch wird hier die Datei im ANDROID_HOME-Verzeichnis gesucht.<br />
*'''aapt''': Geben Sie hier den Pfad zum aapt-Befehl an. Unter Windows heißt diese Datei ''aapt.exe''. expecco verwendet aapt nur im Verbindungseditor, um das Paket und die Activities einer apk-Datei zu lesen. Automatisch wird hier die Datei im ANDROID_HOME-Verzeichnis gesucht.<br />
<br />
[[Datei:MobileTestingJavaBridgeEinstellungen.png | thumb | 400px | Konfiguration des JDKs]]<br />
<br />
Ab expecco 2.11 gibt es das Feld ''Team-ID''. Wenn Sie iOS-Tests ausführen, tragen Sie hier die Team-ID Ihres Zertifikats ein. Diese wird für jede iOS-Verbindung verwendet, außer Sie setzen den Wert im Einzelfall in den Verbindungseinstellungen um. Wie Sie die Team-ID erhalten, lesen Sie im Abschnitt zur [[#expecco_2.11|Installation auf Mac OS mit expecco 2.11]]. Mit expecco 2.10 können Sie die Team-ID nur für jede Verbindungseinstellung extra als Capability eintragen. Dazu müssen Sie jedoch die [[#Erweiterte_Ansicht|erweiterte Ansicht]] verwenden. Geben Sie hier die Capability ''xcodeOrgId'' an und setzen Sie als Wert die Team-ID des Zertifikats.<br />
<br />
Die Einstellung zur Serveradresse unten auf der Seite bezieht sich auf das Verhalten des Verbindungseditors. Dieser prüft am Ende, ob die Serveradresse auf ''/wd/hub'' endet, da dies die übliche Form ist. Falls nicht, wird in einem Dialog gefragt, wie darauf reagiert werden soll. Das festgelegte Verhalten kann hier eingesehen und verändert werden.<br />
<br />
Wechseln Sie ebenfalls zum Eintrag ''Java Bridge'' (s. Abb.). Hier muss der Pfad zu Ihrer Java-Installation angegeben werden, die von expecco benutzt wird. Tragen Sie hier ein JDK ein. Falls Sie unter Windows das aus dem Mobile Testing Supplement verwenden möchten, lautet der Pfad<br />
<nowiki>C:\Program Files (x86)\exept\Mobile Testing Supplement\jdk</nowiki><br />
Sie können auch die Systemeinstellungen verwenden.<br />
<br />
== Android-Gerät vorbereiten ==<br />
Wenn Sie ein Android-Gerät unter Windows anschließen benötigen Sie möglicherweise noch einen adb-Treiber für das Gerät. Einen passenden Treiber finden Sie üblicherweise auf der jeweiligen Webseite des Herstellers. Haben Sie den Universal-Treiber aus dem Mobile Testing Supplement installiert, sollte für die meisten Geräte bereits alles funktionieren. In einigen Fällen versucht auch Windows automatisch einen Treiber zu installieren, wenn Sie das Gerät zum ersten mal anschließen.<br />
<br />
Bevor Sie ein Mobilgerät mit dem Appium-Plugin ansteuern können, müssen Sie für dieses Debugging erlauben. Für Android-Geräte finden Sie diese Option in den Einstellungen unter ''[https://www.droidwiki.org/wiki/Entwickleroptionen Entwickleroptionen]'' mit dem Namen ''[https://www.droidwiki.org/USB-Debugging USB-Debugging]''. Falls die Entwickleroptionen nicht angezeigt werden, können Sie diese freischalten, indem Sie unter ''Über das Telefon'' siebenmal auf ''Build-Nummer'' tippen. Aktivieren Sie auch die Funktion ''Wach bleiben'', damit das Gerät nicht während der Testerstellung oder -ausführung den Bildschirm abschaltet. Aus Sicherheitsgründen muss USB-Debugging für jeden Computer einzeln zugelassen werden. Beim Verbinden des Geräts mit dem PC über USB müssen Sie dabei am Gerät der Verbindung zustimmen. Falls Sie dies für Ihren Computer noch nicht getan haben, aber auf dem Gerät kein entsprechender Dialog erscheint, kann es helfen, das Gerät aus- und wieder einzustecken. Das kann insbesondere dann passieren, wenn Sie den ADB-Treiber installiert haben während das Gerät bereits über USB angeschlossen war. Falls auch das nicht hilft, öffnen Sie die Benachrichtigungen, indem Sie sie vom oberen Bildschirmrand herunter ziehen. Dort finden Sie die USB-Verbindung und Sie können die Optionen dazu öffnen. Wählen Sie einen anderen Verbindungstypen aus; in der Regel sollten MTP oder PTP funktionieren.<br />
<br />
Sie können auch auf einem Emulator testen. Dieser muss nicht mehr gesondert vorbereitet werden, da er bereits für USB-Debugging ausgelegt ist. Es ist sogar möglich, einen Emulator bei Testbeginn zu starten.<br />
<br />
Um zu überprüfen, ob ein Gerät, das Sie an Ihren Rechner angeschlossen haben, verwendet werden kann, öffnen Sie den [[#Verbindungseditor|Verbindungseditor]]. Das Gerät sollte dort angezeigt werden.<br />
<br />
=== Verbindung über WLAN ===<br />
Es ist auch möglich, Android-Geräte über WLAN zu verbinden. Dazu müssen Sie zunächst das Gerät über USB mit dem Rechner verbinden. Öffnen Sie dann die Eingabeaufforderung und geben Sie dort<br />
<nowiki>adb tcpip 5555</nowiki><br />
ein. Damit lauscht das Gerät auf eine TCP/IP-Verbindung an Port 5555. Sollten Sie mehrere Geräte angeschlossen oder Emulatoren laufen haben, müssen Sie genauer angeben, welches Gerät Sie meinen. Geben Sie in diesem Fall<br />
<nowiki>adb devices -l</nowiki><br />
ein. Sie erhalten eine Liste aller Geräte, wobei die erste Spalte deren Kennung ist. Schreiben Sie dann stattdessen<br />
<nowiki>adb -s <Gerätekennung> tcpip 5555</nowiki><br />
mit der Gerätekennung des gewünschten Geräts. Sie können die USB-Verbindung nun trennen. Jetzt müssen Sie die IP-Adresse Ihres Gerätes in Erfahrung bringen. Sie finden diese üblicherweise irgendwo in den Einstellungen des Geräts, beispielsweise beim Status oder in den WLAN-Einstellungen. Geben Sie dann<br />
<nowiki>adb connect <IP-Adresse des Geräts></nowiki><br />
ein. Damit sollte das Gerät nun über WLAN verbunden sein und kann genauso verwendet werden, wie mit USB-Verbindung. Sie können dies überprüfen, indem Sie wieder <tt>adb devices -l</tt> eingeben oder in expecco den Verbindungsdialog öffnen. In der Liste taucht das Gerät mit seiner IP-Adresse und dem Port auf. Bedenken Sie, dass die WLAN-Verbindung nicht mehr besteht, wenn der ADB-Server oder das Gerät neu gestartet werden.<br />
<br />
== iOS-Gerät und App vorbereiten ==<br />
Das Ansteuern von iOS-Geräten ist nur über einen Mac möglich. Lesen Sie daher auch den Abschnitt zur [[#Mac_OS|Installation unter Mac OS]].<br />
<br />
Bevor Sie ein Mobilgerät mit dem Mobile Testing Plugin ansteuern können, müssen Sie für iOS-Geräte ab iOS 8 Debugging erlauben. Aktivieren Sie dazu die Option ''Enable UI Automation'' unter dem Menüpunkt ''Entwickler'' in den Einstellungen des Geräts. Falls Sie den Eintrag ''Entwickler'' in den Einstellungen nicht finden, gehen Sie wie folgt vor: Schließen Sie das Gerät über USB an den Mac an. Dabei müssen Sie ggf. am Gerät noch der Verbindung zustimmen. Starten Sie Xcode und wählen Sie dann in der Menüleiste am oberen Bildschirmrand im Menü ''Window'' den Eintrag ''Devices''. Es öffnet sich ein Fenster, in dem eine Liste der angeschlossenen Geräte angezeigt wird. Wählen Sie dort Ihr Gerät aus. Danach sollte der Eintrag ''Entwickler'' in den Einstellungen auf dem Gerät auftauchen. Dazu müssen Sie möglicherweise die Einstellungen beenden und neu starten.<br />
<br />
[[Datei:Alert.png | thumb | 270px | Alert unter iOS]]<br />
Ein Verbindungsaufbau zu dem Gerät ist nicht möglich solange es bestimmte Alerts zeigt. Ein solcher Alert kann z.&#x202f;B. erscheinen wenn FaceTime aktiviert ist, indem ein Hinweis auf anfallende SMS-Gebühren angezeigt wird (siehe Screenshot). Achten Sie darauf, das Gerät so zu konfigurieren, dass es im Leerlauf keine solchen Alerts zeigt.<br />
<br />
=== expecco 2.11 ===<br />
Sie können beliebige Apps testen, die auf dem verwendeten Gerät lauffähig oder bereits installiert sind. Wenn die App als Development-Build vorliegt, muss die UDID des Geräts in der App hinterlegt sein. In jedem Fall muss der WebDriverAgent für das Gerät signiert werden. Lesen Sie dazu den Abschnitt zur [[#expecco_2.11|Vorbereitung unter Mac OS]].<br />
<br />
Falls Sie in einem Test den Home-Button verwenden wollen, müssen Sie auf dem Gerät AssistiveTouch aktivieren. Sie finden diese Option in den Einstellungen unter ''Allgemein'' > ''Bedienungshilfen'' > ''AssistiveTouch''. Platzieren Sie dann das Menü in der Mitte des oberen Bildschirmrands. Sie können das Drücken des Home-Buttons dann mit dem entsprechenden Menüeintrag im Recorder aufzeichnen oder direkt den Baustein ''Press Home Button'' benutzen.<br />
<br />
=== expecco 2.10 ===<br />
Die App, die Sie verwenden wollen, muss als Development-Build vorliegen. Außerdem muss die UDID des Geräts in der App hinterlegt sein.<br />
<br />
=== Development-Build signieren ===<br />
Ein Development-Build einer App ist nur für eine begrenzte Zahl von Geräten zugelassen und kann auf anderen Geräten nicht gestartet werden. Es ist aber möglich, das Zertifikat und die verwendbaren Geräte in einem Development-Build auszutauschen.<br />
<br />
* Evaluierung mit Demo-App von eXept:<br />
:Gerne stellen wir Ihnen eine Demo-App zur Verfügung, die als Development-Build vorliegt und die wir für Ihr Gerät signieren können. Senden Sie dazu bitte Ihrem eXept-Ansprechpartner die UDID Ihres Gerätes zu. Wie Sie die UDID Ihres Gerätes ermitteln können, ist im folgenden Abschnitt beschrieben.<br />
<br />
* Eigene App für Ihr Testgerät verwenden:<br />
:Wenn Sie von den App-Entwicklern einen Development-Build (IPA-Datei) erhalten, der für Ihr Testgerät zugelassen ist, können Sie diesen direkt verwenden. Dazu müssen Sie den Entwicklern die UDID Ihres Geräts mitteilen, damit sie diese eintragen können. '''Sie können die UDID eines Gerätes mithilfe von Xcode auslesen'''. Starten Sie dazu Xcode und wählen Sie in der Menüleiste am oberen Bildschirmrand im Menü ''Window'' den Eintrag ''Devices''. Es öffnet sich ein Fenster, in dem eine Liste der angeschlossenen Geräte angezeigt wird. Wählen Sie Ihr Gerät aus und suchen Sie in Eigenschaften den Eintrag ''Identifier''. Die UDID ist eine 40-stellige Hexadezimalzahl.<br />
<br />
* Extern entwickelte App für Ihr Testgerät umsignieren:<br />
:Es können auch Apps umsigniert werden, damit Sie auf anderen Geräten lauffähig sind. Dieser Vorgang ist jedoch kompliziert und setzt insbesondere einen Zugang zu einem Apple-Developer-Account voraus. Eine Dokumentation zur Vorgehensweise ist derzeit in Vorbereitung.<br />
<br />
:Für die Evaluierung unterstützen wir Sie gerne beim Umsignieren Ihrer App.<br />
<!--<br />
Melden Sie sich beim [https://developer.apple.com/ Apple-Webinterface] an. Navigieren Sie zu ''Certificates, IDs & Profiles''. Erzeugen Sie hier ggf. ein Developer-Zertifikat und ein Provisioning Profile für Ihr Gerät und laden Sie beide herunter. Sollten Sie noch keinen Developer Account haben, erstellen Sie hier einen: https://developer.apple.com/enroll/. Hierzu müssen Sie sich mit einer Apple-ID anmelden.<br />
<br />
# Team-ID herausfinden (''Membership'' -> ''Team ID'')<br />
# Unter ''Certificates, IDs & Profiles'' Development-Zertifikat auswählen (unter ''+'' anlegen, falls nicht vorhanden) und herunterladen.<br />
# Unter ''App ID'' Wildcard-App-ID erzeugen, falls nicht vorhanden. App-ID notieren (AppID = Prefix.ID)<br />
# Gerät hinzufügen, dazu UDID (bzw. ''Identifier'') des Geräts herausfinden (''Xcode'' -> ''Window'' (oben in Menüleiste) -> ''Devices'')<br />
# Provisionen Profile erstellen: ''iOS App Development'' -> ''AppID'' auswählen -> Zertifikat wählen -> Gerät auswählen -> Profilname anlegen -> Provisioning Profile herunterladen.<br />
# Das heruntergeladene Zertifikat importieren (''Downloads'' -> Zertifikat (.cer)<br />
# SHA1-Fingerabdruck kopieren. Dazu Rechtsklick auf Zertifikat -> ''Information'', anschließend bis zum Ende der Seite scrollen).<br />
# Entitlements.plist erstellen (''Terminal' öffnen -> Downloads/Mobile_Testing_Supplement/bin/gen-entitlements_plist 'Team-ID' 'App ID' Downloads/Mobile_Testing_Supplement/bin/re-sign-ipa <Pfad zum ipa (z.B. Downloads/expeccoMobileDemo.ipa)> \<br />
"<Zertifikat (SHA1-Fingerabdruck, z.B. 76 E8 4B E8 78 D5 D7 F9 2E 09 8B D7 E8 FB CE 30 0C F5 D0 EF)>" \<br />
<Pfad zum Provisionen Profile (z.B. /Users/exept_test/Downloads/dut.mobileprovision)> \<br />
<Pfad für das Ergebnis-ipa (z.B. Downloads/expeccoMobileDemo_re-signed.ipa)> \<br />
[Pfad zur entitlements.plist] (z.B. /Users/exept_test/entitlements.plist)<br />
<br />
Zum Umsignieren können Sie das entsprechende Skript aus dem Mobile Testing Supplement für Mac OS oder jedes beliebige andere Tool (z.B. isign) verwenden.<br />
--><br />
<br />
Weitere Informationen zur Verwendung von iOS-Geräten finden Sie auch in der [http://appium.io/slate/en/master/?java#appium-on-real-ios-devices Dokumentation von Appium].<br />
<br />
=== Native iOS-Apps ===<br />
Sie können auch Apps verwenden, die bereits nativ auf dem Gerät vorhanden sind. Dazu müssen Sie deren Bundle-ID kennen und diese dann in die Verbindungseinstellungen eintragen. Hier eine kleine Auswahl gängiger Apps:<br />
{| style="text-align:left"<br />
! App<br />
!<br />
! Bundle-ID<br />
|-<br />
| App Store<br />
| <br />
| com.apple.AppStore<br />
|-<br />
| Calculator<br />
| <br />
| com.apple.calculator<br />
|-<br />
| Calendar<br />
| <br />
| com.apple.mobilecal<br />
|-<br />
| Camera<br />
| <br />
| com.apple.camera<br />
|-<br />
| Contacts<br />
| <br />
| com.apple.MobileAddressBook<br />
|-<br />
| iTunes Store<br />
| <br />
| com.apple.MobileStore<br />
|-<br />
| Mail<br />
| <br />
| com.apple.mobilemail<br />
|-<br />
| Maps<br />
| <br />
| com.apple.Maps<br />
|-<br />
| Messages<br />
| <br />
| com.apple.MobileSMS<br />
|-<br />
| Phone<br />
| <br />
| com.apple.mobilephone<br />
|-<br />
| Photos<br />
| <br />
| com.apple.mobileslideshow<br />
|-<br />
| Settings<br />
| <br />
| com.apple.Preferences<br />
|}<br />
<br />
Weitere Bundle-IDs finden Sie [https://github.com/joeblau/apple-bundle-identifiers hier].<br />
<br />
= Beispiele =<br />
Bei den Demo-Testsuiten für expecco finden Sie auch Beispiele für Tests mit dem Mobile Testing Plugin. Wählen Sie dazu auf dem Startbildschirm die Option ''Beispiel aus Datei'' und öffnen Sie den Ordner ''mobile''.<br />
<br />
==<span id="TestsuiteMobileTestingDemo"><!-- Referenced by m01_MobileTestingDemo.ets --></span> ''m01_MobileTestingDemo.ets'' ==<br />
Die Testsuite enthält zwei einfache Testpläne: ''Simple CalculatorTest'' und ''Complex Calculator and Messaging Test''. Beide Tests verwenden einen Android-Emulator, den Sie vor Beginn starten müssen. Die Apps, die im Test verwendet werden, gehören zur Grundausstattung des Emulators und müssen daher nicht mehr installiert werden. Da sich die Apps unter jeder Android-Version unterscheiden können, ist es wichtig, dass Ihr Emulator unter Android 6.0 läuft. Außerdem muss die Sprache auf Englisch gestellt sein.<br />
<br />
; Simple CalculatorTest<br />
: Dieser Test verbindet sich mit dem Taschenrechner und gibt die Formel ''2+3'' ein. Das Ergebnis des Rechners wird mit dem erwarteten Wert ''5'' verglichen.<br />
<br />
; Complex Calculator and Messaging Test<br />
: Dieser Test verbindet sich mit dem Taschenrechner und öffnet anschließend den Nachrichtendienst. Dort wartet er auf eine einkommende Nachricht von der Nummer ''15555215556'', in der eine zu berechnende Formel gesendet wird. Die Nachricht wird zuvor über einen Socket beim Emulator erzeugt. Nach dem Eintreffen der Nachricht wird diese vom Test geöffnet und deren Inhalt gelesen. Danach wird wieder der Taschenrechner geöffnet, die erhaltene Formel eingegeben und das Ergebnis gelesen. Anschließend wechselt der Test wieder zum Nachrichtendienst und sendet das Ergebnis als Antwort.<br />
<br />
== ''m02_expeccoMobileDemo.ets'' und ''m03_expeccoMobileDemoIOS.ets'' ==<br />
Diese sind Bestandteil des Tutorials zum Mobile Testing Plugin. Der jeweils enthaltene Testfall ist unvollständig und wird im Zuge des Tutorials ergänzt. Lesen Sie dazu den Abschnitt [[#Tutorial|Tutorial]].<br />
<br />
= Tutorial =<br />
Dieses Tutorial beschreibt das grundsätzliche Vorgehen zur Erstellung von Tests mit dem Mobile Testing Plugin. Grundlage dafür ist ein mitgeliefertes Beispiel, bestehend aus einer einfachen App und einer expecco-Testsuite.<br />
<br />
Die App ''expecco Mobile Demo'' berechnet und überprüft verschiedene alltägliche Codes: die IBAN aus dem europäischen Zahlungsverkehr, die internationalen GTIN-13-Produktcodes, wie man sie bei Strichcodes im Einzelhandel findet, und die Seriennummern auf Euro-Banknoten.<br />
<br />
Die Testsuite enthält Testfälle für einzelne Funktionen der App. Dabei sind noch nicht alle Funktionen abgedeckt, sondern werden im Laufe des Tutorials ergänzt.<br />
<br />
Es gibt zwei Versionen dieses Tutorials:<br />
*'''[[#Erste_Schritte_mit_Android|Erste Schritte mit Android]]'''<br />
*'''[[#Erste_Schritte_mit_iOS|Erste Schritte mit iOS]]'''<br />
<br />
Das Vorgehen ist in beiden Versionen nahezu identisch, lediglich die Verbindungskonfigurationen werden unterschiedlich erzeugt. Die fertigen Tests unterscheiden sich dann im Wesentlichen in den Pfaden zur Adressierung der benutzten Elemente, da diese technologieabhängig sind.<br />
<br />
==<span id="FirstStepsAndroid"><!-- Referenced by m02_expeccoMobileDemo.ets --></span> Erste Schritte mit Android ==<br />
Es wird vorausgesetzt, dass Sie das Kapitel [[#Installation_und_Aufbau|Installation und Aufbau]] bereits gelesen und die nötigen Vorbereitungen für die Verwendung von Android-Geräten unter Windows abgeschlossen haben.<br />
<br />
=== Schritt 1: Demo ausführen ===<br />
Starten Sie expecco und öffnen Sie die Testsuite ''m02_expeccoMobileDemo.ets'' über die Schaltfläche ''Beispiel aus Datei'' (Abb. 1). Ab expecco 2.11 befindet sich diese im Unterordner ''mobile''. In dieser Testsuite befindet sich bereits ein vorgefertigter Testplan mit einigen Testfällen für diese App.<br />
<br />
[[Datei:MobileTestingBeispielÖffnen.png | frame | left | Abb. 1: Beispiel-Testsuite öffnen]]<br />
<br clear="all"><br />
In der Testsuite ist das Paket der Demo-App als Anhang enthalten (''expeccoMobileDemo-debug.apk''). Mithilfe des bereitgestellten Bausteins ''Export Demo App'' können Sie die Datei an einen beliebigen Ort auf Ihrem Rechner exportieren. Wählen Sie dazu den Baustein aus (1) und klicken Sie auf den grünen Play-Knopf (2) um den Baustein auszuführen (Abb. 2). Der Baustein öffnet einen Dateidialog, in dem Sie angeben, wo das Paket gespeichert werden soll.<br />
<br />
[[Datei:MobileTestingExportApp.png | frame | left | Abb. 2: App exportieren]]<br />
<br clear="all"><br />
Bevor wir uns mit dem weiteren Inhalt der Testsuite beschäftigen, konfigurieren Sie zuerst die Verbindung und welches Gerät Sie benutzen wollen. Schließen Sie dazu ein Gerät über USB an Ihren Rechner an oder starten Sie einen Emulator.<br />
<br />
[[Datei:MobileTestingVerbinden.png | frame | left | Abb. 3: Verbindungseditor öffnen]]<br />
<br clear="all"><br />
Öffnen Sie nun den GUI-Browser (1) und wählen Sie unter ''Verbinden'' (2) den Eintrag ''Mobile Testing'' (3) (Abb. 3), um den Verbindungsdialog zu öffnen.<br />
<br />
Sie sehen eine Liste aller angeschlossenen Android-Geräte (1) (Abb. 3). Sollte Ihr Gerät nicht in der Liste auftauchen, stellen Sie sicher, dass es eingeschaltet und über USB verbunden ist. Lesen Sie ansonsten den Abschnitt [[#Android-Ger.C3.A4t_vorbereiten|Android-Gerät vorbereiten]]<br />
<br />
[[Datei:MobileTestingGerätAuswählen.png | frame | left | Abb. 4: Gerät im Verbindungsdialog auswählen]]<br />
<br clear="all"><br />
Haben Sie Ihr Gerät in der Liste gefunden, wählen Sie es aus und klicken Sie auf ''Weiter'' (2).<br />
<br />
Als nächstes geben Sie an, welche App Sie verwenden wollen (Abb. 5). Dabei können Sie wählen, ob Sie eine App starten möchten, die bereits auf dem Gerät installiert ist (''App auf dem Gerät'') oder ob eine App installiert und gestartet werden soll (''App installieren''). Für den Fall, dass Sie eine bereits installierte App benutzen wollen, erhalten Sie eine Liste aller auf dem Gerät installierten Pakete (1), die in Systempakete und Fremdpakete (2) unterteilt sind, sowie deren Activities (3). Diese können Sie dann einfach in den jeweiligen Feldern auswählen.<br />
<br />
[[Datei:MobileTestingAppAuswählen.png | frame | left | Abb. 5: Auf dem Gerät installierte App angeben]]<br />
<br clear="all"><br />
Für dieses Tutorial soll die App installiert werden, die Sie eben aus der Testsuite exportiert haben. Wählen Sie also ''App installieren'' aus und tragen Sie bei App (1) den entsprechenden Pfad ein (Abb. 6). Sie können den Knopf links benutzen (2), um einen Dateidialog zu öffnen, mit dem Sie zu der Datei navigieren können, um sie einzugeben. Das Paket (3) und die Activity (4) der App werden automatisch eingetragen. Sollte die App mehrere Activities besitzen, können Sie die gewünschte auswählen. Klicken Sie nun auf ''Weiter'' (5).<br />
<br />
[[Datei:MobileTestingAppInstallieren.png | frame | left | Abb. 6: App angeben, die auf dem Gerät installiert werden soll]]<br />
<br clear="all"><br />
Auf der letzten Seite sehen Sie eine Übersicht aller bisherigen Angaben (1) (Abb. 7). Darunter können Sie einen Namen für die Verbindung angeben, unter dem sie im GUI-Browser angezeigt wird (2). Außerdem lässt sich eine Verbindung über diesen Namen identifizieren und in Bausteinen verwenden; der Name muss daher eindeutig sein. Falls Sie keinen Namen angeben, wird generisch einer erzeugt. Geben Sie als Namen ''expeccoMobileDemo'' ein. Im Feld darunter ist die Adresse zum Appium-Server einzutragen (3). Appium ist die Schnittstelle, über die die angeschlossenen Geräte gesteuert werden. Für dieses Tutorial wird die Verwaltung der Instanzen des Appium-Servers von expecco übernommen. Tragen Sie dafür ist die lokale Standard-Adresse ''<nowiki>http://localhost:4723/wd/hub</nowiki>'' ein. Diese ist immer der unterste Eintrag der Vorschlagsliste. Außerdem ist die Option ''Bei Bedarf starten'' aktiviert (4). expecco überprüft dann, ob an der Adresse bereits ein Appium-Server läuft und startet und beendet ihn bei Bedarf automatisch. Wenn der Port ''4723'' bereits belegt ist oder wenn Sie einmal mehrere Verbindungen parallel betreiben wollen, verwenden Sie an dieser Stelle entsprechend einen anderen Port. Es ist dabei üblich die ungeraden Portnummern oberhalb von ''4723'' zu verwenden, also ''4725'', ''4727'' usw. Natürlich können Sie auch entfernte Server verwenden, das automatische Starten und Beenden eines Servers kann expecco aber nur lokal für Sie übernehmen.<br />
<br />
[[Datei:MobileTestingServerkonfiguration.png | frame | left | Abb. 7: Verbindungsnamen und Appium-Server konfigurieren]]<br />
<br clear="all"><br />
Klicken Sie nun auf ''Speichern'' (5) um die Einstellungen für die Testausführung zu speichern. Einstellungen können als Anhang einer Testsuite oder in eine externe Datei gespeichert werden (Abb. 8). Falls Sie mehrere Projekte gleichzeitig offen haben, können Sie in der Liste das Projekt auswählen, in dem der Anhang angelegt werden soll. Klicken Sie auf ''Speichern'' im Bereich ''Einstellungen im Anhang speichern'' und geben Sie als Name ''expeccoMobileDemo'' an. Klicken Sie nun auf ''Server starten und verbinden'' (6) um mit der angegebenen Konfiguration eine Verbindung herzustellen.<br />
<br />
[[Datei:MobileTestingEinstellungenSpeichern.png | frame | left | Abb. 8: Einstellungen speichern]]<br />
<br clear="all"><br />
Der Verbindungsaufbau kann eine Weile dauern. Warten Sie bis die Verbindung aufgebaut ist und im GUI-Browser angezeigt wird. Sie sehen, dass die App auf dem Gerät gestartet wird. Nun wissen Sie, dass die Konfiguration funktioniert. Die gespeicherten Einstellungen sollen nun für den Test verwendet werden, der dann die gleiche Verbindung aufbaut. Wählen Sie die Verbindung im GUI-Browser aus, machen Sie einen Rechtsklick und wählen Sie im Kontextmenü ''Verbindung abbauen'', damit es zu keinem Konflikt kommt. Wechseln Sie dann zurück zum Reiter der Testsuite.<br />
<br />
In der Testsuite wurden die Einstellungen als Anhang ''expeccoMobileDemo'' angelegt (Abb 9). Wählen Sie den Baustein ''Connect'' (1) aus und wechseln Sie rechts zur Ansicht ''Netzwerk'' (2). Ziehen Sie per Drag-and-drop die Einstellungen in das Netzwerk des Bausteins (3). Verbinden Sie den Ausgangspin ''pathName'' mit dem Eingangspin ''stringOrFilename[1]'' des Bausteins ''Connect from File'' (4). Mit ''Übernehmen'' (5) bestätigen Sie die Änderungen. Dieser Baustein wird zu Beginn des Tests die Verbindung zur App herstellen.<br />
<br />
[[Datei:MobileTestingConnectblock.png | frame | left | Abb. 9: Verbindungsbaustein editieren]]<br />
<br clear="all"><br />
Wechseln Sie nun zum Testplan ''Demo-Test'' (1) (Abb. 10). Dieser Testplan enthält bereits einige fertige Testfälle. Vor und nach der Ausführung (2) ist außerdem jeweils ein Baustein eingetragen: Der eben bearbeitete Baustein ''Connect'' für den Aufbau und der Baustein ''Disconnect'' für den Verbindungsabbau. Durch das Eintragen der beiden Bausteine an dieser Stelle geschieht der Verbindungsabbau insbesondere auch dann, wenn der Test vorzeitig abgebrochen wird, z. B. weil einer der Testfälle fehlschlägt.<br />
<br />
[[Datei:MobileTestingTestplan.png | frame | left | Abb. 10: Testplanausführung]]<br />
<br clear="all"><br />
Jetzt können Sie den Testplan ''Demo-Test'' starten, indem Sie auf den grünen Play-Knopf (3) klicken. Der Testplan sollte ohne Fehler durchlaufen.<br />
<br />
=== Schritt 2: Einen Baustein mit dem Recorder erstellen ===<br />
Mit Hilfe des integrierten Recorders lassen sich einfach Ausführungssequenzen aufnehmen und in einem Baustein speichern. Dafür muss eine Verbindung zu einem Testgerät bestehen, mit dessen Hilfe der Test erstellt wird.<br />
<br />
Um eine Verbindung aufzubauen, wechseln Sie zurück zum GUI-Browser. In diesem ist noch die Verbindung eingetragen, die Sie zuvor angelegt haben. Da für die Verbindung im Testlauf derselbe Name verwendet wurde, wurden die Einstellungen damit überschrieben (In unserem Fall waren die Einstellungen ohnehin identisch). Die Verbindung ist zur Zeit nicht aktiv, da sie am Ende der Ausführung abgebaut wurde. Die Einstellungen sind dort aber noch eingetragen. Um die Verbindung mit dieser Konfiguration wieder aufzubauen, wählen Sie sie aus, gefolgt von einem Rechtsklick und ''Verbinden''.<br />
<br />
Warten Sie, bis die Verbindung aufgebaut ist (1) und drücken Sie dann den Aufnahme-Knopf (2), um eine Aufzeichnung zu starten (Abb. 11).<br />
<br />
[[Datei:MobileTestingRecorderStarten.png | frame | left | Abb. 11: Recorder starten]]<br />
<br clear="all"><br />
Es öffnet sich ein Fenster mit dem Mobile Testing Recorder (Abb. 12). Dieser zeigt einen Screenshot des verbundenen Geräts. Über diese Anzeige können Sie das Gerät fernsteuern. Dabei wird jede Aktion, die Sie ausführen, im Hintergrund aufgezeichnet.<br />
<br />
In der oberen Menüleiste können Sie das Werkzeug auswählen (1), mit dem Sie eine Aktion eingeben möchten. Als Voreinstellung ist das Werkzeug ''Auto'' ausgewählt. Sie können damit bestimmte Aktionen aufzeichnen, indem Sie mit dem Mauszeiger entsprechende Gesten auf der Anzeige ausführen. Wenn Sie zum Beispiel mit der linken Maustaste lange klicken, entspricht das einem langen Antippen des Elements an dieser Stelle. Anstatt die gewünschte Aktion mit der entsprechenden Geste zu bestimmen, können Sie diese alternativ auch manuell auswählen.<br />
<br />
Es soll nun ein neuer Test für das Erkennen korrekter GTIN-13-Codes aufgenommen werden. Klicken Sie zunächst in der Anzeige kurz auf den Button ''GTIN-13 (EAN-13)'' (2) der App um einen entsprechenden Klick auf dem Gerät auszulösen. Während der Ausführung dieser Aktion wird der Rahmen des Recorders kurzzeitig rot. Falls der Recorder danach nicht die aktuelle Ansicht der App darstellen sollte, klicken Sie im Recorder auf das Aktualisierungssymbol (3).<br />
<br />
[[Datei:MobileTestingRecorder1.png | frame | left | Abb. 12: Über Recorder zur GTIN-13-Activity wechseln]]<br />
<br clear="all"><br />
Anschließend soll im Eingabefeld der neuen Seite eine korrekte GTIN-13 eingegeben werden. Führen Sie dazu einen Rechtsklick auf dem Eingabefeld (1) aus und wählen Sie im Kontextmenü die Aktion ''Text setzen'' (2) (Abb. 13). Geben Sie in den sich daraufhin öffnenden Dialog eine beliebige gültige Artikelnummer im GTIN-13-Format ein, bspw. ''4006381333986'' (3). Dieser Text wird nun in der App gesetzt.<br />
<br />
[[Datei:MobileTestingRecorder2.png | frame | left | Abb. 13: GTIN-13-Code über Recorder eingeben]]<br />
<br clear="all"><br />
Klicken Sie nun auf ''Verify'' (1) (Abb. 14). In der App erscheint nun als Ergebnis ''OK'' (2). Der Test soll feststellen, ob tatsächlich dieses Ergebnis angezeigt wird. Nach einem Rechtsklick darauf können Sie im Kontextmenü die Aktion ''Attribut zusichern'' (3) auswählen. Wählen Sie im Dialog, der sich daraufhin öffnet, die Eigenschaft ''text'' (4) aus und bestätigen Sie mit ''OK'' (5). Dieses Mal wird keine Aktion auf dem Gerät ausgelöst, sondern nur ein Baustein aufgezeichnet, der fehlschlägt, sollte das Ergebnis vom erwarteten Wert ''OK'' abweichen.<br />
<br />
[[Datei:MobileTestingRecorder3.png | frame | left | Abb. 14: Antwort der App über Recorder auslesen]]<br />
<br clear="all"><br />
Schließen Sie nun den Recorder. Im ''Arbeitsbereich'' des GUI-Browsers sehen Sie, dass für jede der aufgenommenen Aktionen ein Baustein angelegt wurde (Abb. 15). Sie können nun testen, ob sich das Aufgenommene wieder abspielen lässt. Dazu müssen Sie zunächst die App auf Ihrem Gerät in den Anfangszustand zurückbringen, indem Sie auf dem Gerät die Schaltfläche ''HOME'' oben rechts benutzen. Klicken Sie dann in expecco auf den grünen Play-Knopf (1). Wird alles grün, war die Ausführung erfolgreich. Erstellen Sie nun daraus einen neuen Baustein in der Testsuite, indem Sie auf das Bausteinsymbol (2) in der rechten oberen Ecke klicken. Geben Sie ihm den Namen ''GTIN_Verify_OK'' (3) und bestätigen Sie (4).<br />
<br />
[[Datei:MobileTestingArbeitsbereich.png | frame | left | Abb. 15: Neuen Baustein aus Arbeitsbereich exportieren]]<br />
<br clear="all"><br />
Bauen Sie nun die Verbindung ab, indem Sie die Verbindung auswählen, rechtsklicken und im Kontextmenü ''Verbindung abbauen'' auswählen.<br />
<br />
Wechseln Sie zurück zum Reiter der Testsuite. Dort wurde der neue Baustein angelegt. Wählen Sie wieder den Testplan ''Demo-Test'' aus und fügen Sie den aufgenommenen Testfall ''GTIN_Verify_OK'' per Drag-and-drop am Ende des Testplans hinzu. Übernehmen Sie die Änderung und starten Sie erneut. Der Testplan sollte wieder ohne Fehler durchlaufen.<br />
<br />
=== Schritt 3: XPath anpassen mithilfe des GUI-Browsers ===<br />
Ihr neuer Baustein funktioniert auf anderen Geräten möglicherweise nicht. Die verwendeten Elemente werden über einen XPath adressiert und dieser kann auf anderen Geräten nicht stimmen. Lesen Sie dazu den Abschnitt [[#XPath_anpassen_mithilfe_des_GUI-Browsers|XPath anpassen mithilfe des GUI-Browsers]]. Falls Ihnen ein weiteres Gerät zur Verfügung steht, können Sie nun versuchen, die Pfade in Ihren erstellten Bausteinen zu verallgemeinern. Sie können diesen Schritt aber auch überspringen.<br />
<br />
Wenn es Ihnen schwerfällt, verkürzte Pfade zu finden, orientieren Sie sich dabei an den Pfaden der bereits vorhandenen Bausteine. Starten Sie den Test erneut. Sollte der Test jetzt fehlschlagen, überprüfen Sie die Pfade noch einmal im GUI-Browser.<br />
Um den Test nun auf einem zweiten Gerät auszuführen, öffnen Sie im Menü ''Erweiterungen'' > ''Mobile Testing'' > ''Verbindungseinstellungen erstellen''. Sie erhalten einen Dialog ähnlich zum Verbindungsdialog. Allerdings können Sie hier nur Einstellungen erstellen und speichern aber keine Verbindung herstellen. Sie haben jedoch die Möglichkeit, einzelne Aspekte der Einstellungen zu speichern wie bspw. nur das Gerät. Wählen Sie das neue Gerät aus und klicken Sie länger auf das Symbol zum Speichern im Anhang bis sich das verzögerte Menü öffnet (Abb. 16). Wählen Sie hier ''Geräte-Einstellungen speichern''. Benennen Sie den Anhang am besten nach dem Gerät. Danach können Sie den Dialog wieder schließen.<br />
<br />
[[Datei:MobileTestingGerätSpeichern.png | frame | left | Abb. 16: Einstellungen für ein Gerät speichern]]<br />
<br clear="all"><br />
Wählen Sie den Baustein ''Connect'' aus und ziehen Sie die Einstellungen für das neue Gerät in dessen Netzwerk. Verbinden Sie nun dessen Ausgangspin ''pathName'' mit dem Eingangspin ''stringOrFilename[2]'' des Bausteins ''Connect from File''. Der Baustein Connect from File liest die Angaben an den Eingangspins von oben nach unten ein, mehrfache Eigenschaften werden dabei ersetzt. In diesem Fall werden also die Einstellungen zum verwendeten Gerät ersetzt, während die übrigen Einstellungen gleich bleiben. Wenn Sie die Pfade geschickt gewählt haben, wird der Test nun auch auf dem anderen Gerät erfolgreich ablaufen.<br />
<br />
=== Schritt 4: Noch einen Baustein erstellen ===<br />
Falls sich gleiche Abläufe im Test wiederholen, können Sie dafür bereits erstellte Bausteine wiederverwenden oder abwandeln. Der in Schritt 2 erstellte Baustein prüft die Erkennung korrekter GTIN-13-Codes. Es fehlt noch ein Test, der umgekehrt das Erkennen eines falschen GTIN-13-Codes prüft. Die Struktur der beiden Tests ist identisch, sie unterscheiden sich lediglich in ihren Parametern. Kopieren Sie daher den Baustein ''GTIN_Verify_OK'' und benennen Sie die Kopie in ''GTIN_Verify_NOT_OK'' um. Ändern Sie die Eingabe der GTIN-13 in einen falschen Code zum Beispiel durch Ändern der letzten Ziffer (''4006381333987'') und setzen Sie den Überprüfungswert der Ausgabe auf ''NOT OK'' (Abb. 17).<br />
<br />
[[Datei:MobileTestingGTIN_Verify_NOT_OK.png | frame | left | Abb. 17: Baustein editieren]]<br />
<br clear="all"><br />
Fügen Sie diesen neuen Test ebenfalls zum Testplan Demo-Test hinzu und setzen Sie ihn ans Ende. Führen Sie den Testplan aus, aber vergessen Sie nicht, vorher die Verbindung im GUI-Browser abzubauen.<br />
<br />
Der neue Test wird fehlschlagen, weil Ihr aufgenommener Baustein nicht wieder zur Startseite der App zurückkehrt, die Tests aber jeweils von dort aus starten. In den anderen Bausteinen ist dies bereits berücksichtigt; sie führen abschließend immer den Baustein ''Back to main menu'' aus. Sie sehen das, indem Sie einen der anderen Bausteine, z. B. ''GTIN_Calculate'', auswählen und auf seine Schema-Ansicht wechseln. Dort steht der Baustein ''Back to main menu'' im Feld ''Nach Ausführung'' (Abb. 18). Wie beim entsprechenden Feld beim Testplan wird auch dieser Baustein immer am Ende ausgeführt, unabhängig davon, ob der Test erfolgreich verläuft oder abbricht. Ergänzen Sie diesen Eintrag nun in Ihren Bausteinen ''GTIN_Verify_OK'' und ''GTIN_Verify_NOT_OK''. Wählen Sie dazu den Baustein aus und ziehen Sie in der Schema-Ansicht den Baustein ''Back to main menu'' einfach auf das Eingabefeld ''Nach Ausführung''. Nun können Sie den Testplan starten und alle Tests sollten wieder problemlos ausgeführt werden.<br />
<br />
[[Datei:AppiumDemo Nach Ausführung.png | frame | left | Abb. 18: Nach-Ausführungs-Baustein setzen]]<br />
<br clear="all"><br />
<br />
=== Schritt 5: Test vervollständigen ===<br />
Für die Activity IBAN sind bereits alle Antwortmöglichkeiten der App mit Testfällen abgedeckt. In der GTIN-13-Activity werden ein korrekter und ein fehlerhafter Code getestet und eine Prüfziffer berechnet, das Verhalten der App bei Eingaben falscher Länge wird aber bisher nicht getestet (Bei Verify '''Input must be exactly 13 digits''. und ''…12 digits''. bei Calculate). Die Activity zum Prüfen der Seriennummern von Eurobanknoten wird noch gar nicht getestet. Wie bei der IBAN können hier drei Fälle auftreten: eine korrekte Seriennummer wurde eingegeben (Antwort: ''OK''), eine falsche Seriennummer wurde eingegeben (Antwort: ''NOT OK'') oder die Angabe entspricht nicht dem Format (Antwort: ''A serial number consists of 12 characters with the first one or two being capital letters (A-Z).''). Sie können die Testabdeckung jetzt noch erweitern, indem Sie entsprechende Testfälle erstellen. Die Bausteine dafür können Sie wie in Schritt 2 mit dem Recorder erstellen und die XPaths bei Bedarf verallgemeinern. Wenn Sie mit dem grundsätzlichen Umgang mit expecco vertraut sind, können Sie Bausteine natürlich auch ohne Recorder erstellen, indem Sie sie manuell aus vorhandenen Bausteinen der Bibliothek zusammensetzen. Sie können auch beide Vorgehensweisen nach Belieben kombinieren.<br />
<br />
Beachten Sie, dass die hier vorgestellten Testfälle jeweils nur einzelne Eingaben prüfen. Wenn Sie Testfälle für Ihre eigenen Apps schreiben, wollen Sie vermutlich engmaschiger testen, indem Sie noch weitere unterschiedliche Werte eingeben, die insbesondere auch Randfälle enthalten.<br />
<br />
==<span id="FirstStepsIOS"><!-- Referenced by m03_expeccoMobileDemoIOS.ets --></span> Erste Schritte mit iOS ==<br />
Es wird vorausgesetzt, dass Sie das Kapitel [[#Installation_und_Aufbau|Installation und Aufbau]] bereits gelesen und die nötigen Vorbereitungen für die Verwendung von iOS-Geräten unter Mac OS abgeschlossen haben. Schließen Sie das Gerät, das Sie verwenden wollen, an den Mac an. Laden Sie die iOS-Version der [http://download.exept.de/transfer/h-expecco-2.11.0-pre/expeccoMobileDemo.ipa expeccoMobileDemo-App] auf den Mac herunter. Da es sich bei der App um einen Debug-Build handelt, müssen Sie sie noch für Ihr Gerät signieren (siehe [[#iOS-Ger.C3.A4t_und_App_vorbereiten|iOS-Gerät und App vorbereiten]]). Starten Sie nun einen Appium-Server auf dem Mac.<br />
<br />
=== Schritt 1: Demo ausführen ===<br />
Starten Sie expecco und öffnen Sie die Testsuite ''m03_expeccoMobileDemoIOS.ets'' über die Schaltfläche ''Beispiel aus Datei'' (Abb. 1). Ab expecco 2.11 befindet sich diese im Unterordner ''mobile''. Ansonsten laden Sie die Testsuite [http://download.exept.de/transfer/h-expecco-2.10.0/m03_expeccoMobileDemoIOS.ets m03_expeccoMobileDemoIOS.ets] auf den Rechner, auf dem sich Ihre expecco-Installation befindet, und öffnen diese. In dieser Testsuite befindet sich bereits ein vorgefertigter Testplan mit einigen Testfällen für diese App.<br />
<br />
[[Datei:MobileTestingIOSBeispielÖffnen.png | frame | left | Abb. 1: Beispiel-Testsuite öffnen]]<br />
<br clear="all"><br />
Bevor wir uns mit dem weiteren Inhalt der Testsuite beschäftigen, konfigurieren Sie zuerst die Verbindung und welches Gerät Sie benutzen wollen. Öffnen Sie nun den GUI-Browser (1) und wählen Sie unter ''Verbinden'' (2) den Eintrag ''Mobile Testing'' (3) (Abb. 2), um den Verbindungsdialog zu öffnen.<br />
[[Datei:MobileTestingVerbinden.png | frame | left | Abb. 2: Verbindungseditor öffnen]]<br />
<br clear="all"><br />
<br />
Hier können Sie ein iOS-Gerät nur von Hand eintragen. Wählen Sie dazu ''iOS-Gerät eingeben'' (Abb. 3). Den Namen und die iOS-Version des Geräts können Sie dessen Eigenschaften entnehmen. Um die Gerätekennung des Geräts zu erfahren, öffnen Sie auf dem Mac in Xcode das Fenster Devices (Command-Shift-2). Dort werden alle angeschlossenen Geräte sowie die zur Verfügung stehenden Simulatoren angezeigt. Hier sehen Sie auch die Gerätekennung (udid) Ihres Geräts und welche Apps installiert wurden. Nachdem Sie das Gerät im Verbindungseditor eingegeben haben, wählen Sie es in der Liste aus und klicken Sie dann auf Weiter.<br />
<br />
[[Datei:MobileTestingIOSGerät.png | frame | left | Abb. 3: Hinzufügen eines iOS-Geräts]]<br />
<br clear="all"><br />
<br />
Als nächstes geben Sie an, welche App Sie verwenden wollen. Dabei können Sie wählen, ob Sie eine App starten möchten, die bereits auf dem Gerät installiert ist (''App auf dem Gerät'') oder ob eine App installiert und gestartet werden soll (''App installieren''). Für den Fall, dass Sie eine bereits installierte App benutzen wollen, müssen Sie deren Bundle-ID angeben. Diese erfahren Sie ebenfalls im Devices-Fenster von Xcode. Für die Demo-App lautet sie beispielsweise ''de.exept.expeccoMobileDemo''.<br />
<br />
Für dieses Tutorial soll die Demo-App erst installiert werden. Wählen Sie also ''App installieren'' aus und tragen Sie bei App den Pfad zu der Datei auf dem Mac ein (Abb. 4). Wenn Sie expecco 2.11 verwenden, können Sie auf dieser Seite auch die Team-ID angeben, die für iOS-Verbindungen angibt, welches Zertifiat verwendet werden soll. Falls Sie bereits in den [[#Konfiguration_des_Plugins|Plugin-Einstellungen]] eine ID angegeben haben, wird diese verwendet. Sie wird hier grau dargestellt, solange Sie keinen anderen Wert angeben. Klicken Sie nun auf ''Weiter''.<br />
<br />
[[Datei:MobileTestingIOSAppInstallieren.png | frame | left | Abb. 4: App angeben, die auf dem Gerät installiert werden soll]]<br />
<br clear="all"><br />
<br />
Auf der letzten Seite sehen Sie eine Übersicht aller bisherigen Angaben (1) (Abb. 5). Unterhalb der Capabilityliste können Sie einen Namen für die Verbindung angeben, unter dem sie im GUI-Browser angezeigt wird (2). Außerdem lässt sich eine Verbindung über diesen Namen identifizieren und in Bausteinen verwenden; der Name muss daher eindeutig sein. Falls Sie keinen Namen angeben, wird generisch einer erzeugt. Geben Sie als Namen ''expeccoMobileDemo'' ein. Im Feld darunter ist die Adresse zum Appium-Server einzutragen (3). Wenn Sie den Appium-Server mit Standardeinstellungen gestartet haben, müssen Sie dazu nur in der Standardadresse (unterster Eintrag der Vorschlagsliste) ''localhost'' durch die IP-Adresse des Macs ersetzen (im Bild ''172.23.1.49''). Um sicher zu gehen, auf welchem Port der Appium-Server lauscht, sehen Sie in dessen Ausgabe. Dort finden am Anfang die Zeile<br />
<nowiki>info: Appium REST http interface listener started on 0.0.0.0:4723</nowiki><br />
Steht hier am Ende nicht der Standardport ''4723'' ändern Sie diese Angabe entsprechend ebenfalls in der Konfiguration.<br />
<br />
Wenn die Option ''Bei Bedarf starten'' (4) aktiviert ist, überprüft expecco, ob an der Adresse bereits ein Appium-Server läuft, und startet und beendet ihn bei Bedarf automatisch. Das ist allerdings nur für lokale Serveradressen möglich, schalten Sie diese Option daher ab.<br />
<br />
[[Datei:MobileTestingServerkonfigurationIOS.png | frame | left | Abb. 5: Verbindungsnamen und Appium-Server konfigurieren]]<br />
<br clear="all"><br />
<br />
Klicken Sie nun auf ''Speichern'' (5) um die Einstellungen für die Testausführung zu speichern. Einstellungen können als Anhang einer Testsuite oder in eine externe Datei gespeichert werden (Abb. 6). Falls Sie mehrere Projekte gleichzeitig offen haben, können Sie in der Liste das Projekt auswählen, in dem der Anhang angelegt werden soll. Klicken Sie auf ''Speichern'' im Bereich ''Einstellungen im Anhang speichern'' und geben Sie als Name ''expeccoMobileDemo'' an. Klicken Sie nun auf ''Verbinden'' (6) um mit der angegebenen Konfiguration eine Verbindung herzustellen.<br />
<br />
[[Datei:MobileTestingEinstellungenSpeichern.png | frame | left | Abb. 6: Einstellungen speichern]]<br />
<br clear="all"><br />
<br />
Der Verbindungsaufbau kann eine Weile dauern. Wenn Sie die Server-Adresse korrekt angegeben haben, sollten Sie in der Ausgabe des Appium-Servers den Verbindungsversuch erkennen. Auf Ihrem iOS-Gerät sollte dabei die App gestartet werden. Passiert nichts auf dem Gerät, kann es daran liegen, dass entweder das Gerät oder die App nicht gefunden wird. Versucht Appium hingegen, die App zu starten und dies schlägt fehl, ist wahrscheinlich die App falsch signiert. Deinstallieren Sie in diesem Fall die App, damit sie mit einer neuen Signatur wieder installiert werden kann.<br />
<br />
Warten Sie bis die Verbindung aufgebaut ist und im GUI-Browser angezeigt wird. Nun wissen Sie, dass die Konfiguration funktioniert. Die gespeicherten Einstellungen sollen nun für den Test verwendet werden, der dann die gleiche Verbindung aufbaut. Wählen Sie die Verbindung im GUI-Browser aus, machen Sie einen Rechtsklick und wählen Sie im Kontextmenü ''Verbindung abbauen'', damit es zu keinem Konflikt kommt. Wechseln Sie dann zurück zum Reiter der Testsuite.<br />
<br />
In der Testsuite wurden die Einstellungen als Anhang ''expeccoMobileDemo'' angelegt (Abb 7). Wählen Sie den Baustein ''Connect'' (1) aus und wechseln Sie rechts zur Ansicht ''Netzwerk'' (2). Ziehen Sie per Drag-and-drop die Einstellungen in das Netzwerk des Bausteins (3). Verbinden Sie den Ausgangspin ''pathName'' mit dem Eingangspin ''stringOrFilename[1]'' des Bausteins ''Connect from File'' (4). Mit ''Übernehmen'' (5) bestätigen Sie die Änderungen. Dieser Baustein wird zu Beginn des Tests die Verbindung zur App herstellen.<br />
<br />
[[Datei:MobileTestingConnectblock.png | frame | left | Abb. 7: Verbindungsbaustein editieren]]<br />
<br clear="all"><br />
<br />
Wechseln Sie nun zum Testplan ''Demo-Test'' (1) (Abb. 8). Dieser Testplan enthält bereits einige fertige Testfälle. Vor und nach der Ausführung (2) ist außerdem jeweils ein Baustein eingetragen: Der eben bearbeitete Baustein ''Connect'' für den Aufbau und der Baustein ''Disconnect'' für den Verbindungsabbau. Durch das Eintragen der beiden Bausteine an dieser Stelle geschieht der Verbindungsabbau insbesondere auch dann, wenn der Test vorzeitig abgebrochen wird, z. B. weil einer der Testfälle fehlschlägt.<br />
<br />
[[Datei:MobileTestingTestplan.png | frame | left | Abb. 8: Testplanausführung]]<br />
<br clear="all"><br />
Jetzt können Sie den Testplan ''Demo-Test'' starten, indem Sie auf den grünen Play-Knopf (3) klicken. Der Testplan sollte ohne Fehler durchlaufen.<br />
<br />
=== Schritt 2: Einen Baustein mit dem Recorder erstellen ===<br />
Mit Hilfe des integrierten Recorders lassen sich einfach Ausführungssequenzen aufnehmen und in einem Baustein speichern. Dafür muss eine Verbindung zu einem Testgerät bestehen, mit dessen Hilfe der Test erstellt wird.<br />
<br />
Um eine Verbindung aufzubauen, wechseln Sie zurück zum GUI-Browser. In diesem ist noch die Verbindung eingetragen, die Sie zuvor angelegt haben. Da für die Verbindung im Testlauf derselbe Name verwendet wurde, wurden die Einstellungen damit überschrieben (In unserem Fall waren die Einstellungen ohnehin identisch). Die Verbindung ist zur Zeit nicht aktiv, da sie am Ende der Ausführung abgebaut wurde. Die Einstellungen sind dort aber noch eingetragen. Um die Verbindung mit dieser Konfiguration wieder aufzubauen, wählen Sie sie aus, gefolgt von einem Rechtsklick und ''Verbinden''.<br />
<br />
Warten Sie, bis die Verbindung aufgebaut ist (1) und drücken Sie dann den Aufnahme-Knopf (2), um eine Aufzeichnung zu starten (Abb. 9).<br />
<br />
[[Datei:MobileTestingRecorderStarten.png | frame | left | Abb. 9: Recorder starten]]<br />
<br clear="all"><br />
Es öffnet sich ein Fenster mit dem Mobile Testing Recorder (Abb. 10). Dieser zeigt einen Screenshot des verbundenen Geräts. Über diese Anzeige können Sie das Gerät fernsteuern. Dabei wird jede Aktion, die Sie ausführen, im Hintergrund aufgezeichnet.<br />
<br />
In der oberen Menüleiste können Sie das Werkzeug auswählen (1), mit dem Sie eine Aktion eingeben möchten. Als Voreinstellung ist das Werkzeug ''Auto'' ausgewählt. Sie können damit bestimmte Aktionen aufzeichnen, indem Sie mit dem Mauszeiger entsprechende Gesten auf der Anzeige ausführen. Wenn Sie zum Beispiel mit der linken Maustaste lange klicken, entspricht das einem langen Antippen des Elements an dieser Stelle. Anstatt die gewünschte Aktion mit der entsprechenden Geste zu bestimmen, können Sie diese alternativ auch manuell auswählen.<br />
<br />
Es soll nun ein neuer Test für das Erkennen korrekter GTIN-13-Codes aufgenommen werden. Klicken Sie zunächst in der Anzeige kurz auf den Button ''GTIN-13 (EAN-13)'' (2) der App um einen entsprechenden Klick auf dem Gerät auszulösen. Während der Ausführung dieser Aktion wird der Rahmen des Recorders kurzzeitig rot. Falls der Recorder danach nicht die aktuelle Ansicht der App darstellen sollte, klicken Sie im Recorder auf das Aktualisierungssymbol (3).<br />
<br />
[[Datei:MobileTestingRecorder1iOS.png | frame | left | Abb. 10: Über Recorder zur GTIN-13-Activity wechseln]]<br />
<br clear="all"><br />
Anschließend soll im Eingabefeld der neuen Seite eine korrekte GTIN-13 eingegeben werden. Führen Sie dazu einen Rechtsklick auf dem Eingabefeld (1) aus und wählen Sie im Kontextmenü die Aktion ''Text setzen'' (2) (Abb. 11). Geben Sie in den sich daraufhin öffnenden Dialog eine beliebige gültige Artikelnummer im GTIN-13-Format ein, bspw. ''4006381333986'' (3). Dieser Text wird nun in der App gesetzt.<br />
<br />
[[Datei:MobileTestingRecorder2iOS.png | frame | left | Abb. 11: GTIN-13-Code über Recorder eingeben]]<br />
<br clear="all"><br />
Klicken Sie nun auf ''Verify'' (1) (Abb. 12). In der App erscheint nun als Ergebnis ''OK'' (2). Der Test soll feststellen, ob tatsächlich dieses Ergebnis angezeigt wird. Nach einem Rechtsklick darauf können Sie im Kontextmenü die Aktion ''Attribut zusichern'' (3) auswählen. Wählen Sie im Dialog, der sich daraufhin öffnet, die Eigenschaft ''value'' (4) aus und bestätigen Sie mit ''OK'' (5). Dieses Mal wird keine Aktion auf dem Gerät ausgelöst, sondern nur ein Baustein aufgezeichnet, der fehlschlägt, sollte das Ergebnis vom erwarteten Wert ''OK'' abweichen.<br />
<br />
[[Datei:MobileTestingRecorder3iOS.png | frame | left | Abb. 12: Antwort der App über Recorder auslesen]]<br />
<br clear="all"><br />
Schließen Sie nun den Recorder. Im ''Arbeitsbereich'' des GUI-Browsers sehen Sie, dass für jede der aufgenommenen Aktionen ein Baustein angelegt wurde (Abb. 13). Sie können nun testen, ob sich das Aufgenommene wieder abspielen lässt. Dazu müssen Sie zunächst die App auf Ihrem Gerät in den Anfangszustand zurückbringen, indem Sie auf dem Gerät die Schaltfläche ''Home'' oben links benutzen. Klicken Sie dann in expecco auf den grünen Play-Knopf (1). Wird alles grün, war die Ausführung erfolgreich. Erstellen Sie nun daraus einen neuen Baustein in der Testsuite, indem Sie auf das Bausteinsymbol (2) in der rechten oberen Ecke klicken. Geben Sie ihm den Namen ''GTIN_Verify_OK'' (3) und bestätigen Sie (4).<br />
<br />
[[Datei:MobileTestingArbeitsbereich.png | frame | left | Abb. 13: Neuen Baustein aus Arbeitsbereich exportieren]]<br />
<br clear="all"><br />
Bauen Sie nun die Verbindung ab, indem Sie die Verbindung auswählen, rechtsklicken und im Kontextmenü ''Verbindung abbauen'' auswählen.<br />
<br />
Wechseln Sie zurück zum Reiter der Testsuite. Dort wurde der neue Baustein angelegt. Wählen Sie wieder den Testplan ''Demo-Test'' aus und fügen Sie den aufgenommenen Testfall ''GTIN_Verify_OK'' per Drag-and-drop am Ende des Testplans hinzu. Übernehmen Sie die Änderung und starten Sie erneut. Der Testplan sollte wieder ohne Fehler durchlaufen.<br />
<br />
=== Schritt 3: XPath anpassen mithilfe des GUI-Browsers ===<br />
Ihr neuer Baustein funktioniert auf anderen Geräten möglicherweise nicht. Die verwendeten Elemente werden über einen XPath adressiert und dieser kann auf anderen Geräten nicht stimmen. Lesen Sie dazu den Abschnitt [[#XPath_anpassen_mithilfe_des_GUI-Browsers|XPath anpassen mithilfe des GUI-Browsers]]. Falls Ihnen ein weiteres Gerät zur Verfügung steht, können Sie nun versuchen, die Pfade in Ihren erstellten Bausteinen zu verallgemeinern. Sie können diesen Schritt aber auch überspringen.<br />
<br />
Wenn es Ihnen schwerfällt, verkürzte Pfade zu finden, orientieren Sie sich dabei an den Pfaden der bereits vorhandenen Bausteine. Starten Sie den Test erneut. Sollte der Test jetzt fehlschlagen, überprüfen Sie die Pfade noch einmal im GUI-Browser.<br />
Um den Test nun auf einem zweiten Gerät auszuführen, öffnen Sie im Menü ''Erweiterungen'' > ''Mobile Testing'' > ''Verbindungseinstellungen erstellen''. Sie erhalten einen Dialog ähnlich zum Verbindungsdialog. Allerdings können Sie hier nur Einstellungen erstellen und speichern aber keine Verbindung herstellen. Sie haben jedoch die Möglichkeit, einzelne Aspekte der Einstellungen zu speichern wie bspw. nur das Gerät. Geben Sie das neue Gerät ein und wählen Sie es aus. Klicken Sie länger auf das Symbol zum Speichern im Anhang bis sich das verzögerte Menü öffnet und wählen Sie hier ''Geräte-Einstellungen speichern'' (Abb. 14). Benennen Sie den Anhang am besten nach dem Gerät. Danach können Sie den Dialog wieder schließen.<br />
<br />
[[Datei:MobileTestingGerätSpeichern.png | frame | left | Abb. 14: Einstellungen für ein Gerät speichern]]<br />
<br clear="all"><br />
Wählen Sie den Baustein ''Connect'' aus und ziehen Sie die Einstellungen für das neue Gerät in dessen Netzwerk. Verbinden Sie nun dessen Ausgangspin ''pathName'' mit dem Eingangspin ''stringOrFilename[2]'' des Bausteins ''Connect from File''. Der Baustein Connect from File liest die Angaben an den Eingangspins von oben nach unten ein, mehrfache Eigenschaften werden dabei ersetzt. In diesem Fall werden also die Einstellungen zum verwendeten Gerät ersetzt, während die übrigen Einstellungen gleich bleiben. Wenn Sie die Pfade geschickt gewählt haben, wird der Test nun auch auf dem anderen Gerät erfolgreich ablaufen.<br />
<br />
=== Schritt 4: Noch einen Baustein erstellen ===<br />
Falls sich gleiche Abläufe im Test wiederholen, können Sie dafür bereits erstellte Bausteine wieder-verwenden oder abwandeln. Der in Schritt 2 erstellte Baustein prüft die Erkennung korrekter GTIN-13-Codes. Es fehlt noch ein Test, der umgekehrt das Erkennen eines falschen GTIN-13-Codes prüft. Die Struktur der beiden Tests ist identisch, sie unterscheiden sich lediglich in ihren Parametern. Kopieren Sie daher den Baustein ''GTIN_Verify_OK'' und benennen Sie die Kopie in ''GTIN_Verify_NOT_OK'' um. Ändern Sie die Eingabe der GTIN-13 in einen falschen Code zum Beispiel durch Ändern der letzten Ziffer (''4006381333987'') und setzen Sie den Überprüfungswert der Ausgabe auf ''NOT OK'' (Abb. 15).<br />
<br />
[[Datei:MobileTestingGTIN_Verify_NOT_OK_iOS.png | frame | left | Abb. 15: Baustein editieren]]<br />
<br clear="all"><br />
Fügen Sie diesen neuen Test ebenfalls zum Testplan Demo-Test hinzu und setzen Sie ihn ans Ende. Führen Sie den Testplan aus, aber vergessen Sie nicht, vorher die Verbindung im GUI-Browser abzubauen.<br />
<br />
Der neue Test wird fehlschlagen, weil Ihr aufgenommener Baustein nicht wieder zur Startseite der App zurückkehrt, die Tests aber jeweils von dort aus starten. In den anderen Bausteinen ist dies bereits berücksichtigt; sie führen abschließend immer den Baustein ''Back to main menu'' aus. Sie sehen das, indem Sie einen der anderen Bausteine, z. B. ''GTIN_Calculate'', auswählen und auf seine Schema-Ansicht wechseln. Dort steht der Baustein ''Back to main menu'' im Feld ''Nach Ausführung'' (Abb. 16). Wie beim entsprechenden Feld beim Testplan wird auch dieser Baustein immer am Ende ausgeführt, unabhängig davon, ob der Test erfolgreich verläuft oder abbricht. Ergänzen Sie diesen Eintrag nun in Ihren Bausteinen ''GTIN_Verify_OK'' und ''GTIN_Verify_NOT_OK''. Wählen Sie dazu den Baustein aus und ziehen Sie in der Schema-Ansicht den Baustein ''Back to main menu'' einfach auf das Eingabefeld ''Nach Ausführung''. Nun können Sie den Testplan starten und alle Tests sollten wieder problemlos ausgeführt werden.<br />
<br />
[[Datei:AppiumDemo Nach Ausführung.png | frame | left | Abb. 16: Nach-Ausführungs-Baustein setzen]]<br />
<br clear="all"><br />
<br />
=== Schritt 5: Test vervollständigen ===<br />
Für die Activity IBAN sind bereits alle Antwortmöglichkeiten der App mit Testfällen abgedeckt. In der GTIN-13-Activity werden ein korrekter und ein fehlerhafter Code getestet und eine Prüfziffer berechnet, das Verhalten der App bei Eingaben falscher Länge wird aber bisher nicht getestet (Bei Verify '''Input must be exactly 13 digits''. und ''…12 digits''. bei Calculate). Die Activity zum Prüfen der Seriennummern von Eurobanknoten wird noch gar nicht getestet. Wie bei der IBAN können hier drei Fälle auftreten: eine korrekte Seriennummer wurde eingegeben (Antwort: ''OK''), eine falsche Seriennummer wurde eingegeben (Antwort: ''NOT OK'') oder die Angabe entspricht nicht dem Format (Antwort: ''A serial number consists of 12 characters with the first one or two being capital letters (A-Z).''). Sie können die Testabdeckung jetzt noch erweitern, indem Sie entsprechende Testfälle erstellen. Die Bausteine dafür können Sie wie in Schritt 2 mit dem Recorder erstellen und die XPaths bei Bedarf verallgemeinern. Wenn Sie mit dem grundsätzlichen Umgang mit expecco vertraut sind, können Sie Bausteine natürlich auch ohne Recorder erstellen, indem Sie sie manuell aus vorhandenen Bausteinen der Bibliothek zusammensetzen. Sie können auch beide Vorgehensweisen nach Belieben kombinieren.<br />
<br />
Beachten Sie, dass die hier vorgestellten Testfälle jeweils nur einzelne Eingaben prüfen. Wenn Sie Testfälle für Ihre eigenen Apps schreiben, wollen Sie vermutlich engmaschiger testen, indem Sie noch weitere unterschiedliche Werte eingeben, die insbesondere auch Randfälle enthalten.<br />
<br />
= Dialoge des Mobile Testing Plugins =<br />
== Verbindungseditor ==<br />
Mithilfe des Verbindungseditors können Sie schnell Verbindungen definieren, ändern oder aufbauen. Je nach Aufgabe weist der Dialog kleine Unterschiede auf und wird unterschiedlich geöffnet:<br />
*Wenn Sie eine Verbindung aufbauen wollen, erreichen Sie den Dialog im GUI-Browser, indem Sie auf ''Verbinden'' klicken und dann ''Mobile Testing'' auswählen.<br />
*Um eine bestehende Verbindung im GUI-Browser zu ändern oder zu kopieren, wählen Sie diese aus, machen einen Rechtsklick und wählen im Kontextmenü entsprechend ''Verbindung bearbeiten'' oder ''Verbindung kopieren'' aus.<br />
*Wollen Sie Verbindungseinstellungen nicht für den GUI-Browser sondern zur Verwendung in einem Test erstellen, wählen Sie im Menü des Mobile Testing Plugins den Punkt ''Verbindungseinstellungen erstellen...''. Darüber können nur die Einstellungen für eine Verbindung erstellt werden, ohne dass eine Verbindung im GUI-Browser angelegt wird.<br />
<br />
Das Menü des Verbindungseditors weist verschiedenen Schaltflächen auf, von denen manche nur beim Erstellen von Verbindungseinstellungen sichtbar sind:<br />
[[Datei:MobileTestingVerbindungseditorMenu.png]]<br />
#''Einstellungen löschen'': Setzt alle Einträge zurück. (Nur beim Erstellen von Einstellungen sichtbar.)<br />
#''Einstellungen aus Datei laden'': Erlaubt das Öffnen einer gespeicherten Einstellungsdatei (*.csf). Deren Einstellungen werden in den Dialog übernommen. Bereits getätigte Eingaben ohne Konflikt bleiben dabei erhalten.<br />
#''Einstellungen aus Anhang laden'': Erlaubt das Öffnen eines Anhangs mit Verbindungseinstellungen aus einem geöffneten Projekt. Diese Einstellungen werden in den Dialog übernommen. Bereits getätigte Eingaben ohne Konflikt bleiben dabei erhalten.<br />
#''Einstellungen in Datei speichern'' und<br />
#''Einstellungen in Anhang speichern'': Hier können Sie die eingetragenen Einstellungen in eine Datei (*.csf) speichern oder als Anhang in einem geöffneten Projekt anlegen. Beide Optionen besitzen ein verzögertes Menü, in dem Sie auswählen können, nur einen bestimmten Teil der Einstellungen zu speichern. (Nur beim Erstellen von Einstellungen sichtbar.)<br />
#''Erweiterte Ansicht'': Damit können Sie in die erweiterte Ansicht wechseln, um zusätzliche Einstellungen vorzunehmen. Lesen Sie dazu mehr am Ende des Kapitels. (Nur beim Erstellen von Einstellungen sichtbar.)<br />
#''Hilfe'': An der rechten Seite wird ein Hilfetext zum jeweiligen Schritt ein- oder ausgeblendet.<br />
<br />
<br />
Der Dialog ist in drei Schritte unterteilt. Im ersten Schritt wählen Sie das Gerät, das Sie verwenden möchten, im zweiten Schritt wählen Sie aus, welche App verwendet werden soll und im letzten Schritt erfolgen die Einstellungen zum Appium-Server.<br />
<br />
===<span id="AppiumConnectionEditorStep1"><!-- Referenced by AppiumConnectionEditor in Mobile Testing Plugin --></span>Schritt 1: Gerät auswählen===<br />
Im oberen Teil erhalten Sie eine Liste aller angeschlossenen Appium-Geräte, die erkannt werden. Mit der Checkbox darunter können Sie die Geräte ausblenden, die zwar erkannt werden, aber nicht bereit sind. Falls Sie ein Gerät eintragen wollen, das nicht angeschlossen ist, können Sie dies mit dem entsprechenden Knopf ''Android-Gerät eingeben'' bzw. ''iOS-Gerät eingeben'' anlegen. Dazu müssen Sie jedoch die benötigten Eigenschaften Ihres Geräts kennen. Das Gerät wird dann in einer zweiten Geräteliste angelegt und kann dort ausgewählt werden. Wenn keine Liste mit angeschlossenen Elementen angezeigt werden kann, werden stattdessen verschiedene Meldungen angezeigt:<br />
*Keine Geräte gefunden<br />
*:expecco konnte keine Android-Geräte finden.<br />
*:Um eine Verbindung zu einem Gerät automatisch zu konfigurieren, stellen Sie sicher, dass es<br />
*:*angeschlossen ist<br />
*:*eingeschaltet ist<br />
*:*einen passenden adb-Treiber installiert hat<br />
*:*für Debugging freigeschaltet ist.<br />
*Keine verfügbaren Geräte gefunden<br />
*:expecco konnte keine verfügbaren Android-Geräte finden. Es wurden aber nicht verfügbare gefunden, z.B. mit dem Status "unauthorized".<br />
*:Um eine Verbindung zu einem Gerät automatisch zu konfigurieren, stellen Sie sicher, dass es<br />
*:*angeschlossen ist<br />
*:*eingeschaltet ist<br />
*:*einen passenden adb-Treiber installiert hat<br />
*:*für Debugging freigeschaltet ist.<br />
*:Um nicht verfügbare Geräte anzuzeigen, aktivieren Sie unten diese Option.<br />
*Verbindung verloren<br />
*:expecco hat die Verbindung zum adb-Server verloren. Versuchen Sie die Verbindung wieder herzustellen, indem Sie auf den Button klicken.<br />
*Verbindung fehlgeschlagen<br />
*:expecco konnte sich nicht mit dem adb-Server verbinden. Möglicherweise läuft er nicht oder der angegebene Pfad stimmt nicht.<br />
*:Überprüfen Sie die adb-Konfiguration in den Einstellungen und versuchen Sie den adb-Server zu starten und eine Verbindung herzustellen indem Sie auf den Knopf klicken.<br />
*Verbinden ...<br />
*:expecco verbindet sich mit dem adb-Server. Dies kann einige Sekunden dauern.<br />
*adb-Server starten ...<br />
*:expecco startet den adb-Server. Dies kann einige Sekunden dauern.<br />
<br />
<!--Bei ''Automatisierung durch'' können Sie angeben, welche Automation-Engine verwendet werden soll. Lassen Sie die Einstellung auf ''(Default)'' wird die entsprechende Capability gar nicht gesetzt. Ansonsten stehen Appium, Selendroid und ab expecco 2.11 XCUITest zur Verfügung. In der Regel wird Selendroid nur für Android-Geräte vor Version 4.1 gebraucht.-->Mit ''Weiter'' gelangen Sie zum nächsten Schritt. Wenn Sie Einstellungen für den GUI-Browser eingeben, ist das erst möglich, wenn ein Gerät ausgewählt wurde.<br />
<br />
===<span id="AppiumConnectionEditorStep2"><!-- Referenced by AppiumConnectionEditor in Mobile Testing Plugin --></span>Schritt 2: App auswählen===<br />
Hier können Sie Angaben zur App machen, die getestet werden soll. Dabei können Sie entscheiden, ob Sie eine App verwenden wollen, die bereits auf dem Gerät installiert ist, oder ob für den Test eine App installiert werden soll. Wählen Sie oben den entsprechenden Reiter aus. Je nachdem, ob Sie im vorigen Schritt ein Android- oder ein iOS-Gerät ausgewählt haben, ändert sich die erforderte Eingabe.<br />
<br />
*'''Android'''<br />
**''App auf dem Gerät''<br />
**:Wenn Sie im ersten Schritt ein angeschlossenes Gerät ausgewählt haben, werden die Pakete aller installierten Apps automatisch abgerufen und Sie können die Auswahl aus den Drop-down-Listen treffen. Die installierten Apps sind in Fremdpakete und Systempakete unterteilt; wählen Sie die entsprechende Paketliste aus. Diese Auswahl gehört nicht zu den Einstellungen, sondern stellt nur die entsprechende Paketliste zur Verfügung. Sie können den Filter benutzen, um die Liste weiter einzuschränken und dann das gewünschte Paket auswählen. Die Activities des ausgwählten Pakets werden ebenfalls automatisch abgerufen und als Drop-down-Liste zur Verfügung gestellt. Wählen Sie die Activity aus, die gestartet werden soll. In der Regel wird automatisch eine Activity aus der Liste eingetragen. Falls Sie kein verbundenes Gerät verwenden, müssen Sie die Eingabe des Pakets und der Activity von Hand vornehmen.<br />
**''App installieren''<br />
**:Geben Sie bei ''App'' den Pfad zu einer App an. Der Pfad muss für den Appium-Server gültig sein, der verwendet wird. Sie können auch eine URL angeben. Benutzen Sie einen lokalen Appium-Server, können Sie den rechten Butten benutzen, um zu der Installationsdatei der App zu navigieren und diesen Pfad einzutragen. Wenn möglich werden dabei auch das entsprechende Paket und die Activity in den Feldern darunter eingetragen. Diese Angabe ist aber nicht notwendig.<br />
<br />
*'''iOS'''<br />
**''App auf dem Gerät''<br />
**:Geben Sie die Bundle-ID einer installierten App an. Sie können die IDs der installierten Apps bspw. mithilfe von Xcode erfahren. Starten Sie dazu Xcode und wählen Sie in der Menüleiste am oberen Bildschirmrand im Menü ''Window'' den Eintrag ''Devices''. Es öffnet sich ein Fenster, in dem eine Liste der angeschlossenen Geräte angezeigt wird. Wenn Sie Ihr Gerät auswählen, sehen Sie in der Übersicht eine Auflistung der von Ihnen installierten Apps.<br />
**''App installieren''<br />
**:Geben Sie bei ''App'' den Pfad zu einer App an. Der Pfad muss für den Appium-Server gültig sein, der verwendet wird. Sie können auch eine URL angeben. Zu den Vorraussetzungen an Apps für reale Geräte lesen Sie bitte den Abschnitt [[#iOS-Ger.C3.A4t_und_App_vorbereiten|iOS-Geräte und App vorbereiten]].<br />
<br />
Im unteren Teil können Sie festlegen, ob die App beim Verbindungsabbau zurückgesetzt bzw. deinstalliert werden soll, und ob sie initial zurückgesetzt werden soll. Auch hier wird die entsprechende Capability gar nicht gesetzt, wenn Sie ''(Default)'' auswählen. Mit ''Weiter'' gelangen Sie zum nächsten Schritt.<br />
<br />
===<span id="AppiumConnectionEditorStep3"><!-- Referenced by AppiumConnectionEditor in Mobile Testing Plugin --></span>Schritt 3: Servereinstellungen===<br />
Im letzten Schritt befindet sich zunächst im oberen Teil eine Liste aller Capabilities, die sich aus Ihren Angaben der vorigen Schritte ergeben. Wenn Sie sich mit Appium auskennen und noch zusätzliche Capabilities setzen möchten, die der Verbindungseditor nicht abdeckt, können Sie durch Klicken auf ''Bearbeiten'' in die erweiterte Ansicht gelangen. Lesen Sie dazu den Abschnitt weiter unten.<br />
<br />
Wenn Sie Einstellungen für den GUI-Browser eingeben, können Sie den ''Verbindungsnamen'' eintragen, mit dem die Verbindung angezeigt wird. Dies ist auch der Name unter dem Bausteine diese Verbindung verwenden können, wenn sie aufgebaut ist. Wenn Sie das Feld frei lassen, wird ein Name generiert. Um die Adresse für den Appium-Server anzugeben, erhalten Sie die lokale Standard-Adresse und bereits verwendete Adressen zur Auswahl. Wenn Sie den Haken für ''Bei Bedarf starten'' setzen, versucht expecco beim Verbinden einen Appium-Server an der angegebenen Adresse zu starten, wenn dort noch keiner läuft. Dieser Server wird dann beim Beenden der Verbindung ebenfalls heruntergefahren. Dies funktioniert nur für lokale Adressen. Achten Sie darauf, nur Portnummern zu verwenden, die auch frei sind. Verwenden Sie am besten nur ungerade Portnummern ab dem Standardport 4723. Beim Verbindungsaufbau wird ebenfalls die folgende Portnummer verwendet, wodurch es sonst zu Konflikten kommen könnte.<br />
<br />
Je nachdem, wie Sie den Dialog geöffnet haben, gibt es nun verschiedene Schaltflächen um ihn abzuschließen. In jedem Fall haben Sie die Option zu speichern. Dabei öffnet sich ein Dialog, indem Sie entweder ein geöffnet Projekt auswählen können, um die Einstellungen dort als Anhang zu speichern, oder auswählen es in einer Datei zu speichern, die Sie anschließend angeben können. Durch das Speichern wird der Dialog nicht beendet, wodurch Sie anschließend noch eine andere Option auswählen könnten.<br />
<br />
Wenn Sie den Editor zum Verbindungsaufbau geöffnet haben, können Sie abschließend auf ''Verbinden'' oder ''Server starten und verbinden'' klicken, je nachdem, ob der Haken für den Serverstart gesetzt ist. Für das Ändern oder Kopieren einer Verbindung im GUI-Brower heißt diese Option ''Übernehmen'', da in diesem Fall nur der Verbindungseintrag geändert bzw. neu angelegt wird, der Verbindungsaufbau aber nicht gestartet wird. Das können Sie bei Bedarf anschließend über das Kontextmenü tun. Falls Sie Capabilities einer bestehenden Verbindung geändert haben, fordert Sie anschließend ein Dialog auf zu entscheiden, ob diese Änderungen direkt übernommen werden sollen, indem die Verbindung abgebaut und mit den neuen Verbindungen aufgebaut wird, oder nicht. In diesem Fall werden die Änderungen erst wirksam, nachdem Sie die Verbindung neu aufbauen.<br />
<br />
Zur Verwendung des Verbindungseditors lesen Sie auch den entsprechenden Abschnitt im jeweiligen Tutorial in Schritt 1 (Android: [[#Schritt_1:_Demo_ausf.C3.BChren|Demo ausführen]], iOS: [[#Schritt_1:_Demo_ausf.C3.BChren_2|Demo ausführen]]).<br />
<br />
===Erweiterte Ansicht===<br />
Die erweiterte Ansicht des Verbindungseditors erhalten Sie entweder durch Klicken auf ''Bearbeiten'' im dritten Schritt oder jederzeit über den entsprechenden Menüeintrag, wenn Sie den Editor über das Plugin-Menü gestartet haben. In dieser Ansicht erhalten Sie eine Liste aller eingestellten Appium-Capabilities. Zu dieser können Sie weitere hinzufügen, Einträge ändern oder entfernen. Um eine Capability hinzuzufügen, wählen Sie diese aus der Drop-down-Liste des Eingabefelds aus. In dieser befinden sich alle bekannten Capabilities sortiert in die Kategorien ''Common'', ''Android'' und ''iOS''. Haben Sie eine Capability ausgewählt, wird ein kurzer Informationstext dazu angezeigt. Sie können in das Feld auch von Hand eine Capability eingeben. Klicken Sie dann auf ''Hinzufügen'', um die Capabilitiy in die Liste einzutragen. Dort können Sie in der rechten Spalte den Wert setzen. Um einen Entrag zu löschen, wählen Sie diesen aus und klicken Sie auf ''Entfernen''. Mit ''Zurück'' verlassen Sie die erweiterte Ansicht.<br />
<br />
[[Datei:MobileTestingErweiterteAnsicht.png]]<br />
<br />
== Laufende Appium-Server ==<br />
Im Menü des Mobile Testing Plugins finden Sie den Eintrag ''Appium-Server...''. Mit diesem öffnen Sie ein Fenster mit einer Übersicht aller Appium-Server, die von expecco gestartet wurden und auf welchem Port diese laufen. Durch Klicken auf das Icon in der Spalte ''Log anzeigen'' können Sie das Logfile des entsprechenden Servers anschauen. Dieses wird beim Beenden des Servers wieder gelöscht. Mit den icons in der Spalte ''Beenden'' kann der entsprechenden Server beendet werden. Allerdings wird dies verhindert, wenn expecco über diesen Server noch eine offene Verbindung hat.<br />
<br />
Außerdem können Sie hier auch Server starten. Verwenden Sie die Eingabefelder zur Konfiguration der Serveradresse. Sie können die Felder auch frei lassen, um die Standardwerte zu verwenden. Bitte beachten Sie, dass Server nur lokal gestartet werden können und der gewählte Port nicht belegt sein darf. Typischerweise werden die ungeraden Portnummern ab 4723 verwendet. Die folgende Portnummer wird beim Verbinden mit einem Gerät ebenfalls benötigt, wodurch es mit den geraden Nummern zu Konflikten kommen könnte.<br />
<br />
[[Datei:MobileTestingAppiumServer.png]]<br />
<br />
Im Menü des Mobile Testing Plugins finden Sie auch den Eintrag ''Alle Verbindungen und Server beenden''. Dies ist für den Fall gedacht, dass Verbindungen oder Server auf andere Weise nicht beendet werden können. Beenden Sie Verbindungen wenn möglich immer im GUI-Browser oder durch Ausführen eines entsprechenden Bausteins. Server, die Sie in der Server-Übersicht gestartet haben, beenden Sie dort; Server, die mit einer Verbindung gestartet wurden, werden automatisch mit dieser beendet.<br />
<br />
Beachten Sie, dass in der Übersicht nur Server aufgelistet sind, die von expecco gestartet und verwaltet werden. Mögliche andere Appium-Server, die auf andere Art gestartet wurden, werden nicht erkannt.<br />
<br />
== Recorder ==<br />
Besteht im GUI-Browser eine Verbindung zu einem Gerät, kann der integrierte Recorder verwendet werden, um mit diesem Gerät einen Testabschnitt aufzunehmen. Sie starten den Recorder, indem Sie im GUI-Browser die entsprechende Verbindung auswählen und dann auf den Aufnahme-Knopf klicken. Für den Recorder öffnet sich ein neues Fenster. Die aufgezeichneten Aktionen werden im Arbeitsbereich des GUI-Browsers angelegt. Daher ist es möglich, das Aufgenommene parallel zu editieren.<br />
<br />
[[Datei:MobileTestingRecorder.png|caption|]]<br />
<br />
;Komponenten des Recorderfensters<br />
#'''Aktualisieren''': Holt das aktuelle Bild und den aktuellen Elementbaum vom Gerät. Dies wird nötig, wenn das Gerät zur Ausführung einer Aktion länger braucht oder sich etwas ohne das Anstoßen durch den Recorder ändert.<br />
#'''Follow-Mouse''': Das Element unter dem Mauszeiger wird im GUI-Browser ausgewählt.<br />
#'''Element-Highlighting''': Das Elements unter dem Mauszeiger wird rot umrandet.<br />
#'''Elemente einzeichnen''': Die Rahmen aller Elemente der Ansicht werden angezeigt.<br />
#'''Werkzeuge''': Auswahl, mit welchem Werkzeug aufgenommen werden soll. Die gewählte Aktion wird bei einem Klick auf die Anzeige ausgelöst. Dabei stehen folgende Aktionen zur Verfügung:<br />
#*Aktionen auf Elemente:<br />
#**Klicken: Kurzer Klick auf das Element über dem der Cursor steht. Zur genaueren Bestimmung, welches Element verwendet wird, benutzen Sie die Funktion Follow-Mouse oder Highlight-Selected.<br />
#**Element antippen: Ähnlich zum Klicken, nur dass zusätzlich die Dauer des Klicks aufgezeichnet wird. Dadurch sind auch längere Klicks möglich.<br />
#**Text setzen: Ermöglicht das Setzen eines Textes in Eingabefelder.<br />
#**Text löschen: Löscht den Text eines Eingabefelds.<br />
#*Aktionen auf das Gerät:<br />
#**Antippen: Löst einen Klick auf die Bildschirmposition aus, bei dem auch die Dauer berücksichtigt wird.<br />
#**Wischen: Wischen in einer geraden Linie vom Punkt des Drückens des Mausknopfes bis zum Loslassen. Die Dauer wird ebenfalls aufgezeichnet.<br />
#:Beachten Sie bei diesen Aktionen, dass das Ergebnis sich auf verschiedenen Geräten unterscheiden kann, bspw. bei verschiedenen Bildschirmauflösungen.<br />
#*Erstellen von Testablauf-Bausteinen<br />
#**Attribut prüfen: Vergleicht den Wert eines festgelegten Attributs des Elements mit einem vorgegebenen Wert. Das Ergebnis triggert den entsprechenden Ausgang.<br />
#**Attribut zusichern: Vergleicht den Wert eines festgelegten Attributs des Elements mit einem vorgegebenen Wert. Bei Ungleichheit schlägt der Test fehl.<br />
#*Auto<br />
#:Ist das Auto-Werkzeug ausgewählt, können alle Aktionen durch spezifische Eingabeweise benutzt werden: ''Klicken'', ''Element antippen'' und ''Wischen'' funktionieren weiterhin durch Klicken, wobei sie anhand der Dauer und der Bewegung des Cursors unterschieden werden. Um ein ''Antippen'' auszulösen, halten Sie beim Klicken Strg gedrückt. Die übrigen Aktionen erhalten Sie durch einen Rechtsklick auf das Element in einem Kontextmenü.<br />
#'''Softkeys''': Nur unter Android. Simuliert das Drücken der Knöpfe Zurück, Home, Fensterliste und Power.<br />
#'''Home-Button''': Nur unter iOS ab expecco 2.11. Ermöglicht das Drücken des Home-Buttons. Funktioniert nur, wenn AssistiveTouch aktiviert ist und sich das Menü in der Mitte des oberen Bildschirmrands befindet.<br />
#'''Anzeige''': Zeigt einen Screenshot des Geräts. Aktionen werden mit der Maus je nach Werkzeug ausgelöst. Wenn eine neue Aktion eingegeben werden kann, hat das Fenster einen grünen Rahmen, sonst ist er rot.<br />
#'''Fenster an Bild anpassen''': Ändert die Größe des Fensters so, dass der Screenshot vollständig angezeigt werden kann.<br />
#'''Bild an Fenster anpassen''': Skaliert den Screenshot auf eine Größe, mit der er die volle Größe des Fensters ausnutzt.<br />
#'''Ausrichtung anpassen''': Korrigiert das Bild, falls dieses auf dem Kopf stehen sollte. Über den Pfeil rechts daneben kann das Bild auch um 90° gedreht werden, falls dies einmal nötig sein sollte. Die Ausrichtung des Bildes ist für die Funktion des Recorders unerheblich, dieser arbeitet ausschließlich auf den erhaltenen Elementen.<br />
#'''Skalierung''': Ändert die Skalierung des Screenshots. Kann auch über den Schieberegler rechts daneben angepasst werden.<br />
#'''Kontrollleuchte''': Zeigt den Zustand des Recorders an<br />
#:''grün'': Der Recorder ist bereit<br />
#:''rot'': Der Recorder ist blockiert, weil die Anzeige und die Elementliste aktualisiert werden<br />
#:''grau'': Der Recorder kann nicht mehr verwendet werden, da die Verbindung zum Gerät verloren gegangen ist<br />
<br />
;Verwendung<br />
Mit jedem Klick im Fenster wird eine Aktion ausgelöst und im Arbeitsbereich des GUI-Browsers aufgezeichnet. Dort können Sie das Aufgenommene abspielen, editieren oder daraus einen neuen Baustein erstellen. Zur Verwendung des Recorders lesen Sie auch Schritt 2 im Tutorial ([[#Schritt_2:_Einen_Baustein_mit_dem_Recorder_erstellen|Android]] bzw. [[#Schritt_2:_Einen_Baustein_mit_dem_Recorder_erstellen_2|iOS]]).<br />
<br />
== AVD Manager und SDK Manager ==<br />
AVD Manager und SDK Manager sind beides Anwendungen von Android. Im Menü des Mobile Testing Plugins bietet expecco die Möglichkeit, diese zu starten. Ansonsten finden Sie diese Programme bei Ihrer Android-Installation. Mit dem AVD Manager können Sie AVDs, also Konfigurationen für Emulatoren, erstellen, bearbeiten und starten. Mit dem SDK Manager erhalten Sie einen Überblick über Ihre Android-Installation und können diese bei Bedarf erweitern.<br />
<br />
= XPath anpassen mithilfe des GUI-Browsers =<br />
Bausteine, die auf einem Gerät fehlerfrei funktionieren, tun dies auf anderen Geräten möglicherweise nicht. Auch können kleine Änderungen der App dazu führen, dass ein Baustein nicht mehr den gewünschten Effekt hat. Man sollte einen Baustein daher so robust formulieren, dass er für eine Vielzahl von Geräten verwendet werden kann und kleine Anpassungen an der App verkraftet. Dazu muss man das grundlegende Funktionsprinzip der Adressierung verstehen. Dies wird im Folgenden am Beispiel der App aus dem Tutorial erläutert.<br />
<br />
Die Ansicht der App setzt sich aus einzelnen Elementen zusammen. Dazu gehören die Schaltflächen ''GTIN-13 (EAN-13)'' und ''Verify'', das Eingabefeld der Zahl ''4006381333986'' und das Ergebnisfeld, in dem OK erscheint, wie auch alle anderen auf der Anzeige sichtbaren Dinge. Diese sichtbaren Elemente sind in unsichtbare Strukturelemente eingebettet. Alle Elemente zusammen sind in einer zusammenhängenden Hierarchie, dem Elementbaum, organisiert.<br />
<br />
[[Datei:MobileTestingGUIBrowser.png | frame | left | Abb. 1: Funktionen des GUI-Browsers]]<br />
<br clear="all"><br />
Sie können sich diesen Baum im GUI-Browser ansehen. Wechseln Sie dazu in den GUI-Browser (Abb. 1) und starten Sie eine beliebige Verbindung. Sobald die Verbindung aufgebaut ist, können Sie den gesamten Baum aufklappen (1) (Klick bei gedrückter Strg-Taste). Er enthält alle Elemente der aktuellen Seite der App.<br />
<br />
Ein Baustein, der nun ein bestimmtes Element verwendet, muss dieses eindeutig angeben, indem er dessen Position im Elementbaum mit einem Pfad im XPath-Format beschreibt. Dieses Format ist ein verbreiteter Web-Standard für XML-Dokumente und -Datenbanken, eignet sich aber genauso für Pfade im Elementbaum.<br />
<br />
Wenn Sie ein Element im Baum auswählen, wird unten der von expecco automatisch generierte XPath (2) für das Element angezeigt, der auch beim Aufzeichnen verwendet wird. Oberhalb davon in der Mitte des Fensters befindet sich eine Liste der Eigenschaften (3) des ausgewählten Elements. Man nennt diese Eigenschaften auch Attribute. Sie beschreiben das Element näher wie beispielsweise seinen Typ, seinen Text oder andere Informationen zu seinem Zustand. Links unten können Sie zur besseren Orientierung im Baum die ''Vorschau'' (4) aktivieren, um sich den Bildausschnitt des Elements anzeigen zu lassen.<br />
<br />
Der Elementbaum für gleiche Ansicht einer App kann sich je nach Gerät unterscheiden. Es sind diese Unterschiede, die verhindern, eine Aufnahme von einem Gerät unverändert auch auf allen anderen Geräten abzuspielen: Ein XPath, der im einen Elementbaum ein bestimmtes Element identifiziert, beschreibt nicht unbedingt das gleiche Element im Elementbaum auf einem anderen Gerät. Es kann stattdessen passieren, dass der XPath auf kein Element, auf ein falsches Element oder auf mehrere Elemente passt. Dann schlägt der Test fehl oder er verhält sich unerwartet.<br />
<br />
Man könnte natürlich für jedes Gerät einen eigenen Testfall schreiben. Das brächte aber unverhältnismäßigen Aufwand bei Testerstellung und -wartung mit sich. Das Problem lässt sich auch anders lösen, da ein jeweiliges Element nicht nur durch genau einen XPath beschrieben wird. Vielmehr erlaubt der Standard mithilfe verschiedener Merkmale unterschiedliche Beschreibungen für ein und dasselbe Element zu formulieren. Das Ziel ist daher, einen Pfad zu finden, der auf allen für den Test verwendeten Geräten funktioniert und überall eindeutig zum richtigen Element führt.<br />
<br />
Im Beispiel besteht die Verbindung zur Android-App aus dem Tutorial und der Eintrag des GTIN-13-Buttons ist ausgewählt (5). Dessen automatisch generierter XPath (2) kann beispielsweise so aussehen:<br />
<br />
<blockquote>//hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.view.ViewGroup/android.widget.FrameLayout[@resource id='android:id/content']/android.widget.RelativeLayout/android.widget.Button[@resource-id='de.exept.expeccomobiledemo:id/gtin_13']</blockquote><br />
<br />
Er ist offensichtlich lang und unübersichtlich. Der sehr viel kürzere Pfad<br />
<br />
<blockquote>//*[@text='GTIN-13 (EAN-13)']</blockquote><br />
<br />
führt zum selben Element.<br />
<br />
Für die iOS-App lautet der automatisch generierte XPath für diesen Button beispielsweise<br />
<br />
<blockquote>//AppiumAUT/XCUIElementTypeApplication/XCUIElementTypeWindow[1]/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeButton[2]</blockquote><br />
bzw.<br />
<blockquote>//AppiumAUT/UIAApplication/UIAWindow[1]/UIAButton[2]</blockquote><br />
<br />
und kann kürzer als<br />
<br />
<blockquote>//*[@name='GTIN-13 (EAN-13)']</blockquote><br />
<br />
geschrieben werden.<br />
<br />
Sie können den Pfad entsprechend im GUI-Browser ändern und durch ''Pfad überprüfen'' (6) feststellen, ob er weiterhin auf das ausgewählte Element zeigt, was expecco mit ''Verify Path: OK'' (7) bestätigen sollte. Der erste, sehr viel längere Pfad, beschreibt den gesamten Weg vom obersten Element des Baumes bis hin zum gesuchten Button. Der zweite Pfad hingegen wählt mit * zunächst sämtliche Elemente des Baumes und schränkt die Auswahl dann auf genau die Elemente ein, die ein ''text''- bzw. ''name''-Attribut mit dem Wert ''GTIN-13 (EAN-13)'' besitzen, in unserem Fall also genau der eine Button, den wir suchen.<br />
<br />
Im folgenden werden Android-ähnliche Pfade zur Veranschaulichung verwendet. Die Elemente in iOS-Apps heißen zwar anders, wodurch andere Pfade entstehen; das Prinzip ist jedoch das gleiche.<br />
<br />
[[Datei:MobileTestingBaum1.png | frame | Abb. 2: Elementbaum einer fiktiven App]]<br />
<br />
Sie können solche Pfade mit Hilfe weniger Regeln selbst formulieren. Sehen Sie sich den einfachen Baum einer fiktiven Android-App in Abb. 2 an: Die Einrückungen innerhalb des Baumes geben die Hierarchie der Elemente wieder. Ein Element ist ein ''Kind'' eines anderen Elementes, wenn jenes andere Element das nächsthöhere Element mit einem um eins geringeren Einzug ist. Jenes Element ist das ''Elternelement'' des Kindes. Sind mehrere untereinander stehende Elemente gleich eingerückt, so sind sie also alle Kinder desselben Elternelements.<br />
<br />
Ein Pfad durch alle Ebenen der Hierarchie zum TextView-Element ist nun:<br />
<br />
<blockquote>//hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.TextView</blockquote><br />
<br />
Die Elemente sind mit Schrägstrichen voneinander getrennt. Es fällt auf, dass der Name des ersten Elements nicht mit dem im Baum übereinstimmt. Das oberste Element in der Hierarchie heißt immer ''hierarchy'' (für iOS wäre es ''AppiumAUT''), expecco zeigt im Baum stattdessen den Namen der Verbindung an, damit man mehrere Verbindungen voneinander unterscheiden kann. Die weiteren Elemente tragen jeweils das Präfix ''android.widget.'', das im Baum zur besseren Übersicht nicht angezeigt wird. Bei IOS gibt es kein Präfix, das durch einen Punkt abgetrennt wäre, expecco 2.11 blendet aber entsprechend ''XCUIElementType'' am Anfang aus. Mit jedem Schrägstrich führt der Pfad über eine Eltern-Kind-Beziehung in eine tiefere Hierarchie-Ebene, d. h. ''FrameLayout'' ist ein Kindelement von ''hierarchy'', ''LinearLayout'' ist ein Kind von ''FrameLayout'' usw. Die in eckigen Klammern geschriebenen Wörter dienen nur als Orientierungshilfe im Baum. Sie gehören nicht zum Typ.<br />
<br />
Ein Pfad muss nicht beim Element ''hierarchy'' beginnen. Man kann den Pfad beginnend mit einem beliebigen Element des Baumes bilden. Man kann also verkürzt auch<br />
<br />
<blockquote>//android.widget.TextView</blockquote><br />
<br />
schreiben. Der Pfad führt zum selben ''TextView''-Element, da es nur ein Element dieses Typs gibt. Anders verhält es sich bei dem Pfad<br />
<br />
<blockquote>//android.widget.Button.</blockquote><br />
<br />
Da es zwei Elemente vom Typ ''Button'' gibt, passt dieser Pfad auf zwei Elemente, nämlich den Button, der mit "''An''" markiert ist, und den ''Button'', der mit "''Aus''" markiert ist. Es würde an dieser Stelle aber auch nicht helfen den langen Pfad von ''hierarchy'' aus beginnend anzugeben. Um einen mehrdeutigen Pfad weiter zu differenzieren, kann man explizit ein Element aus einer Menge wählen, indem man den numerischen Index in eckigen Klammern dahinter schreibt. Der Pfad aus dem obigen Beispiel lässt sich damit so anpassen, dass er eindeutig auf den ''Button'' mit der Markierung "''Aus''" weist:<br />
<br />
<blockquote>//android.widget.Button[1].</blockquote><br />
<br />
Ihnen fällt sicher auf, dass der Index eine 1 ist obwohl das zweite Element gemeint ist. Das kommt daher, dass die Zählung bei 0 beginnt. Der Button mit der Markierung "An" hat also die Nummer 0 und der ''Button'' mit der Markierung "''Aus''" hat die Nummer 1.<br />
<br />
Dieser Ansatz, einen expliziten Index zu verwenden, hat zwei Nachteile: Zum einen lässt sich an dem Pfad nur schwer ablesen welches Element gemeint ist, zum andern ist der Pfad sehr empfindlich schon gegenüber kleinsten Änderungen, wie zum Beispiel dem Vertauschen der beiden ''Button''-Elemente oder dem Einfügen eines weiteren ''Button''-Elements in der App.<br />
<br />
Es wäre daher wünschenswert, das gemeinte Element über eine ihm charakteristische Eigenschaft wie einen Attributwert, zu adressieren. Für Android-Apps eignet sich hierfür häufig das Attribut ''resource-id''. Im Idealfall muss bei der Entwicklung der App darauf geachtet werden, dass jedes Element eine eindeutige Id erhält. Die ''resource-id'' hat den großen Vorteil, dass sie unabhängig vom Text des Elements oder der Spracheinstellung des Geräts ist. Für iOS-Apps kann entsprechend das Attribut ''name'' verwendet werden, wenn es von der App sinnvoll gesetzt wird. Der XPath-Standard erlaubt solche Auswahlbedingungen zu einem Element anzugeben. Angenommen, der ''Button'' mit der Markierung "''Aus''" hat die Eigenschaft ''resource-id'' mit dem Wert ''off'' und der ''Button'' mit der Markierung "''An''" hat als ''resource-id'' den Wert ''on'', dann kann man als eindeutigen Pfad für den "Aus"-''Button''<br />
<br />
<blockquote>//android.widget.Button[@resource-id='off']</blockquote><br />
<br />
formulieren. Wie an dem Beispiel zu sehen werden solche Bedingungen wie ein Index in eckigen Klammern an den Elementtyp angehängt. Der Name eines Attributes wird mit einem @ eingeleitet und der Wert mit einem = in Anführungszeichen angehängt. Ist der Attributwert global eindeutig, kann man den vorausgehenden Pfad sogar durch den globalen Platzhalter * ersetzen, der auf jedes Element passt. Das obige Beispiel mit dem GTIN-13-''Button'' war ein solcher Fall.<br />
<br />
[[Datei:MobileTestingBaum2.png | frame | Abb. 3: Elementbaum einer fiktiven App mit Erweiterungen]]<br />
<br />
Abb. 3 zeigt eine Erweiterung des Beispiels aus Abb. 2. Die App hat nun ein weiteres, nahezu identisches ''LinearLayout'' bekommen. Die ''Buttons'' sind in ihren Attributen jeweils ununterscheidbar. Deshalb funktioniert der vorige Ansatz nicht, einen eindeutigen Pfad nur mithilfe eines Attributwerts zu formulieren. Offensichtlich unterscheiden sich aber ihre benachbarten ''TextViews''. Es ist möglich die jeweilige ''TextView'' in den Pfad mit aufzunehmen, um einen ''Button'' dennoch eindeutig zu adressieren. Ein Pfad zum ''Button'' mit der Markierung "''An''" unterhalb der ''TextView'' mit der Markierung "''Druckschalter''" kann dabei wie folgt aussehen:<br />
<br />
<blockquote>//android.widget.TextView[@resource-id='push']/../android.widget.Button[@resource-id='on']</blockquote><br />
<br />
Der erste Teil beschreibt den Pfad zu der ''TextView'' mit der Markierung "''Druckschalter''" und der ''resource-id'' mit dem Wert ''push''. Danach folgt ein Schrägstrich gefolgt von zwei Punkten. Die zwei Punkte sind eine spezielle Elementbezeichnung, die nicht ein Kindelement benennt, sondern zum Elternelement wechselt, in diesem Fall also das ''LinearLayout'', in dem die ''TextView'' eingebettet ist. Im Kontext dieses ''LinearLayout'' ist der restliche Pfad, nämlich der ''Button'' mit der ''resource-id'' mit dem Wert ''on'', eindeutig.<br />
<br />
Der XPath-Standard bietet noch sehr viel mehr Ausdrucksmittel. Mit der hier knapp vorgestellten Auswahl ist es aber bereits möglich für die meisten praktischen Testfälle gute Pfade zu formulieren. Eine vollständige Einführung in XPath ginge über den Umfang dieser Einführung weit hinaus. Sie finden zahlreiche weiterführende Dokumentationen im Web und in Büchern.<br />
<br />
Eine universelle Strategie zum Erstellen guter XPaths gibt es nicht, da sie von den Testanforderungen abhängt. In der Regel ist es sinnvoll, den XPath kurz und dennoch eindeutig zu halten. Häufig lassen sich Elemente über Eigenschaften identifizieren wie beispielsweise ihren Text. Will man aber gerade den Text eines Elements auslesen, kann dieser natürlich nicht im Pfad verwendet werden, da er vorher nicht bekannt ist. Ebenso wird der Text variieren, wenn die App mit verschiedenen Sprachen gestartet wird.<br />
<br />
Jeder Baustein, der auf einem Element arbeitet, hat einen Eingangspin für den XPath. Im GUI-Browser finden Sie in der Mitte oben eine Liste von Bausteinen mit Aktionen, die Sie auf das ausgewählte Element anwenden können. Suchen Sie den Baustein ''Click'' (8) im Ordner Elements und wählen Sie ihn aus (Abb. 1). Er wird im rechten Teil unter ''Test'' eingefügt, der Pin für den XPath ist mit dem automatisch generierten Pfad des Elements vorbelegt (9). Sie können den Baustein hier auch ausführen. Die Ansicht wechselt dann auf ''Lauf''. Ändert sich durch die Aktion der Zustand Ihrer App, müssen Sie den Baum anschließend aktualisieren (10).<br />
<br />
Wenn Sie in der unteren Liste eine Eigenschaft auswählen, wechselt die Anzeige der Bausteine zu ''Eigenschaften'', wo Sie die eigenschaftsbezogenen Bausteine finden. Wie bei den Aktionen können Sie auch hier einen Baustein auswählen, der dann rechts in Test mit dem Pfad des Elements und der ausgewählten Eigenschaft eingetragen wird, sodass Sie ihn direkt ausführen können.<br />
<br />
=<span id="troubleshooting"><!-- Referenced by error dialog on connection error --></span>Probleme und Lösungen=<br />
==Allgemeine Hinweise==<br />
*Wenn ein über USB angeschlossenes Android-Gerät nicht im Verbindungsdialog auftaucht, versuchen Sie, den USB-Verbindungstyp zu ändern. In der Regel sollten MTP oder PTP funktionieren. Siehe auch [[#Android-Ger.C3.A4t_vorbereiten|Android-Gerät vorbereiten]].<br />
*In manchen Fällen erscheint beim Verbinden eines iOS-Geräts über USB der Hinweis, das verwendete Kabel sei nicht zertifiziert. In diesem Fall hilft es nur, das entsprechende Kabel auszutauschen.<br />
*Beachten Sie, dass im [[#Recorder|Recorder]] auch Elemente berücksichtigt werden, die Sie auf dem Bildschirm nicht sehen. Schalten Sie daher das Element-Highlighting an oder nutzen Sie Follow-Mouse-Funktion und den Elementbaum im GUI-Browser, um festzustellen, ob das richtige Element verwendet wird.<br />
*Stellen Sie sicher, dass beim Verbindungsaufbau mit einem iOS-Gerät keine Alerts geöffnet sind. Der Aufbau schlägt sonst fehl, da die App nicht in den Vordergrund kommen kann. Siehe auch [[#iOS-Ger.C3.A4t_und_App_vorbereiten|iOS-Gerät und App vorbereiten]].<br />
*Um einen iOS-Simulator zu verwenden müssen Sie keine udid angeben. In Xcode erhalten Sie die Namen der verfügbaren Simulatoren. Starten Sie dazu Xcode und wählen Sie in der Menüleiste am oberen Bildschirmrand im Menü ''Window'' den Eintrag ''Devices''. Hier sind neben den angeschlossenen Geräten auch die verfügbaren Simulatoren aufgelistet. Beachten Sie dabei, dass auf Simulatoren keine ''.ipa''-Dateien sondern nur ''.app''-Dateien installiert werden können.<br />
<br />
==Verbindungsaufbau schlägt fehl==<br />
Schlägt der Verbindungsaufbau mit dem Appium-Server fehl, erhalten Sie in expecco folgende Fehlermeldung:<br />
<br />
[[Datei:MobileTestingVerbindungsfehler.png]]<br />
<br />
Hier sehen Sie die Art des aufgetretenen Fehlers. Klicken Sie auf ''Details'' um nähere Informationen zu erhalten. Mögliche Fehler sind:<br />
*''org.openqa.selenium.remote.UnreachableBrowserException''<br />
:Der angegebene Server läuft nicht oder ist nicht erreichbar. Überprüfen Sie die Serveradresse.<br />
*''org.openqa.selenium.WebDriverException''<br />
:Lesen Sie in den Details in der ersten Zeile die Meldung hinter ''Original Error'':<br />
:*''Unknown device or simulator UDID''<br />
::Entweder ist das Gerät nicht richtig angeschlossen oder die udid stimmt nicht.<br />
:*''Unable to launch WebDriverAgent because of xcodebuild failure: xcodebuild failed with code 65''<br />
::Dieser Fehler kann verschiedene Ursachen haben. Entweder konnte tatsächlich der WebDriverAgent nicht gebaut werden, weil die Signierungseinstellungen falsch sind oder das passende Provisioning Profile fehlt. Lesen Sie dazu den Abschnitt zur Verbereitung unter [[#expecco_2.11|Mac OS mit expecco 2.11]]. Es kann auch sein, dass der WebDriverAgent auf dem Gerät nicht gestartet werden kann, weil sich beispielsweise ein Alert im Vordergrund befindet oder Sie dem Entwickler nicht vertraut haben.<br />
:*''Could not install app: 'Command 'ios-deploy [...] exited with code 253'''<br />
::Die angegebene App kann nicht auf dem iOS-Gerät installiert werden, weil es nicht im Provisioning Profile der App eingetragen ist.<br />
:*''Bad app: [...] App paths need to be absolute, or relative to the appium server install dir, or a URL to compressed file, or a special app name.'''<br />
::Der Pfad zur App ist falsch. Stellen Sie sicher, dass sich die Datei unter dem angegebenen Pfad auf dem Mac befindet.<br />
:*''packageAndLaunchActivityFromManifest failed.''<br />
::Die angegebene ''apk''-Datei ist vermutlich kaputt.<br />
:*''Could not find app apk at [...]''<br />
::Der Pfad zur App ist falsch. Stellen Sie sicher, dass sich die ''apk''-Datei m angegebenen Pfad befindet.</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Tutorials&diff=10553Tutorials2018-02-16T23:16:35Z<p>Mawalch: s/Appium Plugin/Mobile Testing Plugin</p>
<hr />
<div>== Erste Schritte mit expecco ==<br />
<br />
Die Ersten Schritte richten sich an alle, die expecco zum ersten Mal benutzen und sollen als erste Starthilfe dienen. Anhand eines einfachen Beispiels wollen wir Ihnen einen Überblick über expecco verschaffen. Es empfiehlt sich expecco parallel zum Tutorial zu starten um alle Schritte innerhalb von expecco nachvollziehen zu können.<br />
<br />
<br><br />
<br />
'''Hier können Sie "Erste Schritte mit expecco" nutzen:'''<br />
<br><br />
[[Medium:Erste_Schritte_mit_expecco.pdf|Erste Schritte mit expecco.pdf]]<br />
<br />
<br><br />
<br />
== Erste Schritte mit Android ==<br />
<br />
Mit dem Mobile Testing Plugin lassen sich Tests für Apps auf Android- oder iOS-Mobilgeräten erstellen und ausführen. Dieses Tutorial beschreibt das grundsätzliche Vorgehen anhand eines mit gelieferten Beispiels für Android, bestehend aus einer einfachen App und einer expecco-Testsuite. Die App expecco Mobile Demo berechnet und überprüft verschiedene alltägliche Codes: die IBAN aus dem europäischen Zahlungsverkehr, die internationalen GTIN-13-Produktcodes, wie man sie bei Strichcodes im Einzelhandel findet, und die Seriennummern auf Euro-Banknoten. Die Testsuite enthält Testfälle für einzelne Funktionen der App. Dabei sind noch nicht alle Funktionen abgedeckt, sondern werden im Laufe des Tutorials ergänzt.<br />
<br />
<br><br />
<br />
'''Hier können Sie "Erste Schritte mit Android" nutzen:'''<br />
<br><br />
<br />
[[Medium:Erste_Schritte_mit_Android.pdf|Erste Schritte mit Android.pdf]]<br />
<br />
<br><br />
<br />
'''Der folgende Link leitet Sie zu der Seite "YouTube" weiter und bietet Ihnen ein Tutorial zum Thema "Testen mit Android":'''<br />
<br><br />
[https://www.youtube.com/watch?v=H8H4gQO_Tx8 Testing with Android]<br />
<br />
<br />
== Bibliotheken ==<br />
'''Hier können Sie "Organisieren von Bibliotheken" nutzen:'''<br />
<br><br />
<br />
[[Organizing Libraries|Tutorial: Organisieren von Bibliotheken]]<br />
<br />
<br><br />
<br />
'''Der folgende Link leitet Sie auf die Seite "YouTube" weiter und bietet Ihnen ein Tutorial zum Thema "Verwendung von Bibliotheken":'''<br />
<br><br />
[https://www.youtube.com/watch?v=moi3AiexalQ Verwendung von Bibliotheken]<br />
<br />
<br><br />
<br />
==Generieren von Testdaten==<br />
<br />
One of the most frequently asked questions is "How can I generate testdata". Due to expecco's flexibility, there are multiple solutions to solving this task. Depending on the kind and amount of data to be generated, one of several patterns applies. The following gives you a rough overview on that theme.<br />
<br />
<br><br />
'''Hier können Sie "Generieren von Testdaten" nutzen:'''<br />
<br />
[[Generating Test Data|Tutorial: Generieren von Testdaten]]<br />
<br />
<br><br />
<br />
'''Der folgende Link leitet Sie auf die Seite "YouTube" weiter und bietet Ihnen ein Tutorial zum Thema "Umgang mit Bausteinen":'''<br />
<br><br />
[https://www.youtube.com/watch?v=GYXXyJWmNT8 Umgang mit Bausteinen]<br />
<br />
<br><br />
<br />
== Weitere Tutorials ==<br />
<br />
* [[Testing Java Applications using Groovy blocks]]<br />
Through this tutorial, we'll use a simple "Bank Account" application as system under test.<br />
<br />
<br><br />
<br />
* [[expecco API]]<br />
Before you start programming, please read the [[How_to_Program/en|"How to Program"]] document, which describes how program code is handled in expecco.<br />
Unless you are familiar with the dynamics of a Smalltalk development environment, some of it may be unknown to you, and you will have more fun and be more productive, if you know the power of the tools. For the best development experience, take a look at the debugger, workspace (notepad) and data inspectors.<br />
<br />
The rest of this document describes the syntax and semantics of the elementary action languages; for tool usage, please read the [[How_to_Program/en|HowTo]] document.<br />
<br />
<br><br />
<br />
* [[Parametrizing Tests|Parametrisierung von Tests]]<br />
Parameter values (like hostnames, port numbers, user names, DB names etc.) should usually not be used literally as freeze value or hard coded into an elementary block's code, because this may make the suite harder to maintain in that you'd have to search for such values whenever a change is required (using the string search facility in the left tree view).<br />
<br />
<br><br />
<br />
* [[Common_Errors/en|Common Errors and How to Deal with them]]<br />
This document lists the most common error situations and provides advice on how to fix it. It is incomplete and does not cover all possible errors.<br />
<br />
<br><br />
<br />
* [[Executor]]<br />
<br />
<br><br />
<br />
* [[Executor#Activity]]<br />
<br />
<br><br />
<br />
* [[Reimporting a Library|Reimportieren von Bibliotheken]]<br />
<br />
<br><br />
<br />
* [[Uses of Tags|Nutzung von Etiketten (Tags)]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Tutorials&diff=10552Tutorials2018-02-15T12:01:12Z<p>Mawalch: Cleaning</p>
<hr />
<div>== Erste Schritte mit expecco ==<br />
<br />
Die Ersten Schritte richten sich an alle, die expecco zum ersten Mal benutzen und sollen als erste Starthilfe dienen. Anhand eines einfachen Beispiels wollen wir Ihnen einen Überblick über expecco verschaffen. Es empfiehlt sich expecco parallel zum Tutorial zu starten um alle Schritte innerhalb von expecco nachvollziehen zu können.<br />
<br />
<br><br />
<br />
'''Hier können Sie "Erste Schritte mit expecco" nutzen:'''<br />
<br><br />
[[Medium:Erste_Schritte_mit_expecco.pdf|Erste Schritte mit expecco.pdf]]<br />
<br />
<br><br />
<br />
== Erste Schritte mit Android ==<br />
<br />
Mit dem Appium-Plugin lassen sich Tests für Apps auf Android- oder iOS-Mobilgeräten erstellen und ausführen. Dieses Tutorial beschreibt das grundsätzliche Vorgehen anhand eines mit gelieferten Beispiels für Android, bestehend aus einer einfachen App und einer expecco-Testsuite. Die App expecco Mobile Demo berechnet und überprüft verschiedene alltägliche Codes: die IBAN aus dem europäischen Zahlungsverkehr, die internationalen GTIN-13-Produktcodes, wie man sie bei Strichcodes im Einzelhandel findet, und die Seriennummern auf Euro-Banknoten. Die Testsuite enthält Testfälle für einzelne Funktionen der App. Dabei sind noch nicht alle Funktionen abgedeckt, sondern werden im Laufe des Tutorials ergänzt.<br />
<br />
<br><br />
<br />
'''Hier können Sie "Erste Schritte mit Android" nutzen:'''<br />
<br><br />
<br />
[[Medium:Erste_Schritte_mit_Android.pdf|Erste Schritte mit Android.pdf]]<br />
<br />
<br><br />
<br />
'''Der folgende Link leitet Sie zu der Seite "YouTube" weiter und bietet Ihnen ein Tutorial zum Thema "Testen mit Android":'''<br />
<br><br />
[https://www.youtube.com/watch?v=H8H4gQO_Tx8 Testing with Android]<br />
<br />
<br />
== Bibliotheken ==<br />
'''Hier können Sie "Organisieren von Bibliotheken" nutzen:'''<br />
<br><br />
<br />
[[Organizing Libraries|Tutorial: Organisieren von Bibliotheken]]<br />
<br />
<br><br />
<br />
'''Der folgende Link leitet Sie auf die Seite "YouTube" weiter und bietet Ihnen ein Tutorial zum Thema "Verwendung von Bibliotheken":'''<br />
<br><br />
[https://www.youtube.com/watch?v=moi3AiexalQ Verwendung von Bibliotheken]<br />
<br />
<br><br />
<br />
==Generieren von Testdaten==<br />
<br />
One of the most frequently asked questions is "How can I generate testdata". Due to expecco's flexibility, there are multiple solutions to solving this task. Depending on the kind and amount of data to be generated, one of several patterns applies. The following gives you a rough overview on that theme.<br />
<br />
<br><br />
'''Hier können Sie "Generieren von Testdaten" nutzen:'''<br />
<br />
[[Generating Test Data|Tutorial: Generieren von Testdaten]]<br />
<br />
<br><br />
<br />
'''Der folgende Link leitet Sie auf die Seite "YouTube" weiter und bietet Ihnen ein Tutorial zum Thema "Umgang mit Bausteinen":'''<br />
<br><br />
[https://www.youtube.com/watch?v=GYXXyJWmNT8 Umgang mit Bausteinen]<br />
<br />
<br><br />
<br />
== Weitere Tutorials ==<br />
<br />
* [[Testing Java Applications using Groovy blocks]]<br />
Through this tutorial, we'll use a simple "Bank Account" application as system under test.<br />
<br />
<br><br />
<br />
* [[expecco API]]<br />
Before you start programming, please read the [[How_to_Program/en|"How to Program"]] document, which describes how program code is handled in expecco.<br />
Unless you are familiar with the dynamics of a Smalltalk development environment, some of it may be unknown to you, and you will have more fun and be more productive, if you know the power of the tools. For the best development experience, take a look at the debugger, workspace (notepad) and data inspectors.<br />
<br />
The rest of this document describes the syntax and semantics of the elementary action languages; for tool usage, please read the [[How_to_Program/en|HowTo]] document.<br />
<br />
<br><br />
<br />
* [[Parametrizing Tests|Parametrisierung von Tests]]<br />
Parameter values (like hostnames, port numbers, user names, DB names etc.) should usually not be used literally as freeze value or hard coded into an elementary block's code, because this may make the suite harder to maintain in that you'd have to search for such values whenever a change is required (using the string search facility in the left tree view).<br />
<br />
<br><br />
<br />
* [[Common_Errors/en|Common Errors and How to Deal with them]]<br />
This document lists the most common error situations and provides advice on how to fix it. It is incomplete and does not cover all possible errors.<br />
<br />
<br><br />
<br />
* [[Executor]]<br />
<br />
<br><br />
<br />
* [[Executor#Activity]]<br />
<br />
<br><br />
<br />
* [[Reimporting a Library|Reimportieren von Bibliotheken]]<br />
<br />
<br><br />
<br />
* [[Uses of Tags|Nutzung von Etiketten (Tags)]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=SOAP_WSDL&diff=10551SOAP WSDL2018-02-13T13:36:21Z<p>Mawalch: </p>
<hr />
<div>== SOAP WSDL Package ==<br />
<br />
== Basic Usage ==<br />
<br />
These chapter describes the basic underlying implementation.<br />
The code generated by the WSDL class generator calls those functions.<br />
<br />
<br />
To make a SOAP request as a client, given a WSDL (either as file, string or URL),<br />
you have to:<br />
* create a service from the WSDL<br />
* instantiate a client<br />
* create a call object with call arguments<br />
* perform the call<br />
* extract the values from the returned result object<br />
<br />
==== Creating a Service Instance ====<br />
<br />
The service instance keeps the information about the available entry points, the protocol and encoding and the data types.<br />
You need a WSDL to create a service. This can come from multiple sources:<br />
<br />
====== From URL (preferred) ======<br />
<br />
this is the preferred method, especially as it will automatically deal with imported schema definitions<br />
(i.e. if the WSDL refers to other documents via an import)<br />
<br />
<code><pre><br />
service := SprayWSDLService onUrl: 'anUrlString'<br />
</pre></code><br />
<br />
====== From a String ======<br />
<br />
this only works, if the WSDL is self contained (eg. contains all required definitions and does not import other documents).<br />
If it does, missing documents will be fetched automatically via HTTP (see description on transports below).<br />
<br />
<code><pre><br />
service := SprayWSDLService onXmlString: 'wsdlString'<br />
</pre></code><br />
<br />
====== From a Set of Files/Strings ======<br />
<br />
when a WSDL URL is parsed, a transport object instance is used to fetch imported documents.<br />
By default, an instance of SptHTTPClient is used to fetch required documents.<br />
<br />
A mock transport class named SptHTTPLocalTransport can be used. This keeps a list of string documents in a dictionary mapped by URL<br />
and delivers that contents, when asked for (i.e. it simulates an SptHTTPClient-transport).<br />
<br />
Thus, if you have a WSDL document, which imports other documents, AND you want to prevent WSDL fetches via HTTP of your program at runtime, you should setup an instance of SptHTTPLocalTransport, give it all the documents (incl. any imported docs),<br />
and provide that as a document retriever.<br />
<br />
For example, if you have a WSDL in (urlA), which imports urlB and urlC,<br />
create a transport which contains all three documents as:<br />
<code><pre><br />
localTransport := SptHTTPLocalTransport new.<br />
<br />
localTransport localDocuments<br />
at: urlA "eg something like: 'http://foo.services.de:30050/partner/PartnerBusinessService?SCHEMA'"<br />
put:<br />
'<?xml version="1.0"?><br />
... the whole urlA document as string...<br />
'.<br />
<br />
localTransport localDocuments<br />
at: urlB "eg something like: 'http://foo.services.de..."<br />
put:<br />
'<?xml version="1.0"?><br />
... the whole urlB document as string...<br />
'.<br />
<br />
localTransport localDocuments<br />
at: urlC "eg something like: 'http://foo.services.de..."<br />
put:<br />
'<?xml version="1.0"?><br />
... the whole urlC document as string...<br />
'.<br />
</pre></code><br />
and then create the service with:<br />
<code><pre><br />
definitions := WSDLDefinitions<br />
onUrl: urlA<br />
transport: localTransport.<br />
service := SprayWSDLService onDefinitions: definitions.<br />
</pre></code><br />
In such a setup, all required import URLs will be fetched from there (e.g. no HTTP requests required).<br />
<br />
You can provide the URL contents from class variables, class getter methods, etc.<br />
Of course, you can also read the documents from a local file, and setup the localTransport instance<br />
from their contents.<br />
<br />
====== From Binary Storage ======<br />
<br />
All of the above methods require some initial processing time (in the order of a few 100ms),<br />
because they read the textual WSDL with the XML parser, and construct a rather complicated object structure containing those definitions. (most of the space is taken up by XML-schema definitions, which are kept as XML-node trees).<br />
<br />
The original Dolphin implementation used Smalltalk binary object storage to speed this up.<br />
Definition objects were converted to a binary store bytes at development time, those kept in a class variable in the deployed end-user image<br />
and restored from it at execution time.<br />
<br />
Be aware, that binary storage data is both system dependent and hard to analyze in case of errors.<br />
Our experience is that it is worth to have the WSDL around in plain text, as fixes are much easier to make there, in case of problems.<br />
<br />
==== Instantiating a Client ====<br />
<br />
Once you have the service object,<br />
you need a client to a concrete partner service. This client prepares the outgoing and incoming envelopes, to save some processing time in the actual message send.<br />
<br />
To create a client, use either:<br />
<code><pre><br />
client := service createClient<br />
</pre></code><br />
which creates a client to the service's default host (which is the one specified in the WSDL).<br />
<br />
Often, this is not the one you want to connect to (for example, if you have a local test service running,<br />
and/or the host address of the service is different for in-house connections). Also, some WSDLs do not include a valid service URL.<br />
<br />
Then use:<br />
<code><pre><br />
client := service createClientTo:'http://foo.bar.com:4933/bla/...'.<br />
</pre></code><br />
<br />
==== Create a Call Object with Call Arguments ====<br />
<br />
Finally, an actual service call is to be performed.<br />
<br />
This is a two-step operation: first, a call instance is created, which takes the name of the operation and its arguments, and generates an out-envelope (which includes the XML representation of the arguments, as specified in the WSDL's encoding information). The second step is the actual call, which is described below.<br />
<br />
Call argument objects fall into two categories:<br />
* simple objects (xsd:simpleTypes, which can be directly mapped to Smalltalk objects)<br />
* complex objects (in the XML schema, these are xsd:complexType elements)<br />
<br />
Simple types are mapped to corresponding Smalltalk objects:<br />
<br />
* xsd:string - String<br />
* xsd:int - Integer<br />
* xsd:integer - Integer<br />
* xsd:boolean - Boolean<br />
* xsd:date - Date<br />
* xsd:time - Time<br />
* etc.<br />
<br />
There are a few xsd:simpleTypes, for which no standard Smalltalk object exists on all machines (xsd:datetime). Depending on the dialect, these are either mapped to existing classes or to classes from the SOAP framework. For example, xsd:datetime is mapped to the Timestamp class in Smalltalk/X but to SOAP__XeXSDDateTime in VSE.<br />
<br />
Complex types must be represented as instances of one of:<br />
<br />
* an XeQstruct - this is a special kind of Dictionary, which uses qualified names (e.g. XML names with namespace and prefix) as keys. This is the default representation used by the SOAP framework.<br />
* a Dictionary - if values are given as dictionary instance, it must contain key-value mappings for the sub-elements. The keys are the localName of the schema's element names (i.e. if the element is named foo:someType, then the key should be 'foo' only).<br />
* a special data holder object - this must understand getter- and setter messages, corresponding to the local names of the elements.<br />
<br />
A concrete example is found in the BLZ-testcase:<br />
<code><pre><br />
call := client send: 'getBank' withArguments:getBankArg.<br />
</pre></code><br />
<br />
==== Performing the Service Call ====<br />
<br />
Finally, execute the call by giving it a #value message (think of the call object as a block, which does the call for you):<br />
<code><pre><br />
result := call value.<br />
</pre></code><br />
<br />
this harmless looking message performs the transfer. It sets up the communication (usually HTTP, where the SOAP message is wrapped into an HTTP-request), sends the message in an asynchronous send process, awaits the response, decodes the returned XML and instantiates the result object(s).<br />
<br />
Notice that SOAP allows for multiple return values to be specified in the WSDL.<br />
If this is the case, the result returned by #value is the first return value,<br />
and a sequenceable collection of all return values is retrieved via #outParameters.<br />
<br />
==== Debugging / Logging HTTP Traffic ====<br />
Take a look at "UserPreferences" and the SOAP__SptHTTPRequest's Verbose class variable. See the chapter at the end on logging flags.<br />
<br />
A call object's in/out XML can be inspected with:<br />
<code><br />
call in xml inspect.<br />
call out xml inspect.<br />
</code><br />
<br />
== WSDL Class Generator ==<br />
<br />
The wsdl class generator takes WSDL definitions and generates a client class containing entries for the operations, and type classes which hold the arguments and return values.<br />
<br />
==== Generating Classes ====<br />
<br />
First, instantiate the WSDLClassBuilder.<br />
<br />
You need either a service instance (see above) or a WSDL definitions object, as argument to the instantiation message.<br />
<br />
For example:<br />
<code><pre><br />
service := SprayWSDLService onXmlString:'... a lot of WSDL here ...'<br />
builder := WSDLClassBuilder service: service<br />
</pre></code><br />
or:<br />
<code><pre><br />
definitions := WSDLDefinitions onURL:'http://.....?wsdl'.<br />
builder := WSDLClassBuilder definitions: definitions<br />
</pre></code><br />
<br />
Then let it generate the classes with:<br />
<code><pre><br />
builder generate<br />
</pre></code><br />
<br />
Unless overwritten by the setup messages below,<br />
the generated client class will have a name constructed from the service name in the WSDL.<br />
It will have a "SOAP__" prefix, followed by the service name and "Client" (i.e. "SOAP__<service name>Client").<br />
For example, if the DeBeKa partnerservice-WSDL is used, the client class name would be "SOAP__PartnerServiceClient".<br />
<br />
Data objects are generated for all non-simpleType objects, which are recursively reached/used by the WSDL operations,<br />
starting with the individual operation arguments.<br />
Datatype class names are constructed in a similar fashion: a "SOAP__" prefix, the service name, an underline, and the type name from the XSD-schema.<br />
For example, if the WSDL contains an XSD type named "bestaetigePartner", the generated type class would be named "SOAP__PartnerService_bestaetigePartner".<br />
The service name is included, to avoid a name conflict with type classes from other services.<br />
<br />
The builder's naming defaults can be overwritten via setup methods described below.<br />
This must of course be done before calling the #generate method.<br />
<br />
===== clientClassName: aString =====<br />
defines (overwrites) the name of the generated client class. Thus, if you say:<br />
<code><pre><br />
builder clientClassName: 'DBK_PService'.<br />
</pre></code><br />
the generated client class will be named "DBK_PService" instead of "SOAP_PartnerServiceClient"<br />
<br />
<br />
===== typeClassNamePrefix: aString =====<br />
defines (overwrites) the prefix to be used for type classes. This includes the namespace prefix. Thus, if you say:<br />
<code><pre><br />
builder typeClassNamePrefix: 'DBK_'.<br />
</pre></code><br />
all generated type classes will be named "DBK_<schema name>".<br />
<br />
<br />
===== classNamePrefix: aString =====<br />
defines (overwrites) the prefix to be used for all classes (i.e. type- and client classes). This includes the namespace prefix. Thus, if you say:<br />
<code><pre><br />
builder classNamePrefix: 'DBK_'.<br />
</pre></code><br />
all generated type classes will be named "DBK_<schema name>", and the client class will be "DBK_<serviceName>Client".<br />
<br />
==== Generated Data Holder Classes (TypeClasses) ====<br />
<br />
For each used XSD type, a corresponding Smalltalk class is created.<br />
These are (and should be) complete passive objects which exist only as data holders.<br />
Their instance variable structure and getter/setter interface directly corresponds to the element-structure of the corresponding XSD types.<br />
<br />
However, all element names are converted to lowercaseFirst (unless the forceLowercaseFieldNames option is set to false, as described below).<br />
Also, multiple occurs fields are given a name with a trailing underscore ("_"), and an additional adder-method is generated.<br />
I.e. for a multiple-occurs element named "foo", a getter named "foo_" (which returns the multiple elements as an array), a setter named "foo_:", which expects the multiple values as an array), and an adder "add_foo:" (which expects a single object to be added) are generated.<br />
<br />
The translation to lowercase is done, because most Smalltalks give a warning about or even forbid instance variables with an uppercase first character. However, you may prefer having the original XSD schema names as instance variables and getter/setter names.<br />
Then use:<br />
<code><pre><br />
builder forceLowercaseFieldNames: false<br />
</pre></code><br />
before calling the generate method.<br />
<br />
<br />
==== Using Generated Client Classes ====<br />
<br />
The client class is generated as a subclass of SOAP__SprayWSDLService.<br />
It has to be instantiated, and contains a number of helper methods and the SOAP operation API in a category named "operations".<br />
Each operation expects a request-argument object as parameter, as specified in the WSDL.<br />
For example, in the partnerService, you will find methods named "bestaetigePartner:", "listPartner:" etc.<br />
<br />
The generated methods are written to include comments and naming hints (argument names) which will help in instantiating the required argument objects correctly.<br />
<br />
The default destination URL is returned by the "destinationUrl" method. By default, this returns the URL as found in the original WSDL.<br />
A setter method "destinationUrl:" allows for this default to be overwritten.<br />
<br />
To instantiate a service client, use:<br />
<code><pre><br />
serviceClient := <generatedServiceClientClass> new.<br />
</pre></code><br />
to use a different URL, change it with:<br />
<code><pre><br />
serviceClient destinationUrl: 'http://...'.<br />
</pre></code><br />
<br />
Once instantiated, the serviceClient can be reused for multiple requests to the same service host.<br />
It does not keep connections open between service calls (unless your underlying HTTP interface does so, and the HTTP connection was opened with the "connection: keep" option - which is not done by default).<br />
<br />
Then setup the service arguments. Look into the source of the client classes' operation methods, to see what it expects,<br />
and the source of the corresponding type-class to see what elements it has:<br />
<code><pre><br />
arg := <operationTypeClass> new.<br />
arg foo: valueForFoo.<br />
arg bar: valueForBar.<br />
...<br />
</pre></code><br />
<br />
Finally, perform the service call with:<br />
<code><pre><br />
rslt := serviceClient operation: arg.<br />
</pre></code><br />
the returned result-object will be an instance of the response type-class, with getters as specified in the WSDL. Look at the comments in the getters, to see what you get.<br />
<br />
==== Instantiating Argument Objects ====<br />
<br />
The generated data holding type classes will have getters and setters for their elements.<br />
If the schema includes restrictions (such as a length restriction on a string, or an enumeration of allowed values), the setters will also perform verification of the argument.<br />
In addition, the generated code includes comments, which describe any restrictions.<br />
<br />
The verification can be disabled via a central flag, as returned by: "SOAP__SoapSetting verifySoapCallArguments".<br />
You can change this method to return false for deployed images.<br />
<br />
==== Accessing the Last Call Object (after a service call) ====<br />
<br />
The generated client class has an instance variable, which holds the previous request object.<br />
This can be inspected in case of an error. For example,<br />
<code><pre><br />
serviceClient lastRequest out xml<br />
</pre></code><br />
returns the last out-going request's full XML envelope,<br />
<br>and:<br />
<code><pre><br />
serviceClient lastRequest in xml<br />
</pre></code><br />
contains the last response.<br />
<br />
== Example: PartnerService ==<br />
=== Generating the PartnerService classes ===<br />
<br />
The following code example is also found in "WSDLClassBuilderTest >> testClassBuilder_02".<br />
<br />
Generating the partnerService classes:<br />
<br />
<code><pre><br />
definitions := WSDLDefinitions<br />
onUrl: 'http://plan-eval-esb.services.debeka.de:30050/partner/proxyservice/PartnerBusinessService?WSDL'.<br />
<br />
builder := WSDLClassBuilder definitions:definitions.<br />
builder generate.<br />
</pre></code><br />
<br />
this will generate the following classes (into the class category "SOAP-Generated-partnerService"):<br />
<br />
* SOAP__PartnerServiceClient<br />
* SOAP__PartnerService_addressType<br />
* SOAP__PartnerService_bestaetigepartner<br />
* SOAP__PartnerService_fehler<br />
* ...<br />
* SOAP__PartnerService_personType<br />
* SOAP__PartnerService_seitenSuche<br />
<br />
=== Using PartnerService ===<br />
<br />
To call the partnerService at its default service port address,<br />
use:<br />
<br />
<code><pre><br />
service := SOAP__PartnerService new.<br />
<br />
suchArg := SOAP_PartnerService_seitenSuche new.<br />
suchArg ergebnisType:'ALLES'.<br />
result := service listePartner: suchArg.<br />
<br />
"result will be an instance of kontrollTyp"<br />
Transcript show: result code.<br />
Transcript show: result fehler.<br />
Transcript show: result information.<br />
</pre></code><br />
<br />
for a different service URL (in-house test service), use:<br />
<code><pre><br />
service := SOAP__PartnerService new.<br />
service destinationUrl:'http://testServer:8080/partner/proxyservice/PartnerBusinessService.<br />
...<br />
</pre></code><br />
<br />
== SOAP Package Structure ==<br />
<br />
The whole package is structured into a number of sub-packages, of which some are usable outside the SOAP context.<br />
Each package has a subpackage (named "XX_test" in ST/X and usually "XXTES" in VSE).<br />
<br />
In ST/X, all SOAP classes live in a separate namespace ("SOAP"), and thus have a "SOAP::" prefix in their name.<br />
Inside the namespace, the prefix is not needed to refer to a class which is in the same namespace.<br />
Therefore, in ST/X code, you will find class references without prefix.<br />
<br />
For VSE, which has no namespaces, class names are translated by prefixing the name with "<namespace>__". Thus all classes will have a "SOAP__" prefix in VSE. This is automatically done by the STX-VSE class exporter, which was developed specifically for this purpose.<br />
<br />
Notice, that this automatic rewrite can of course not detect situations where class names are constructed dynamically,<br />
and referred to via "Smalltalk at:". Such code had to be identified and manually changed to deal with both dialects.<br />
Usually, you will find code like "Smalltalk isSmalltalkX ifTrue:[...]" or "Smalltalk isVisualSmalltalkEnterprise ifTrue:[...]" in those parts. The goal is to keep a common code base, so that future improvements and fixes will be immediately available in both dialects.<br />
<br />
===== Package: xe ("stx_goodies_soap_xe") =====<br />
contains classes to represent qualified names, XSD schema definitions, XSD typespaces and mappings etc.<br />
there are no input/output or GUI related operations in this package.<br />
Most of the classes found there can be mapped one-by-one to corresponding elements from an XSD schema definition.<br />
Object hierarchies of them are created by the WSDL readers, the SOAP envelope creators and the SOAP encoders.<br />
&nbsp;<br />
<br />
===== Package: spray ("stx_goodies_soap_spray") =====<br />
the basic SOAP framework. Includes both client and server code (however, the server part was not part of the VSE porting effort, and may not run without further debugging).<br />
The spray package does not need a WSDL. In theory, it is possible to setup the above described service/client/call objects manually, by appropriate instance creation and initialization messages. In practice, the setup is too complicated, and the WSDL subpackage does this for you.<br />
<br />
===== Package: wsdl ("stx_goodies_soap_wsdl") =====<br />
this contains classes to represent the information inside a WSDL,<br />
and to create a service object from it. Most of the code is in WSDLDefinitions, which deals with all xsd-schema handling, especially with the import of other documents (using transport objects).<br />
<br />
===== Package: yaxo ("stx_goodies_xml_yaxo") =====<br />
the YAXO ("yet another xml o-stands-for-whatever") XML parser.<br />
Reads XML and generates a hierarchy of XML nodes. This parser lives in its own namespace called "YAXO"; thus, in VSE, all of its classes will have a "YAXO__" prefix.<br />
<br />
The SOAP framework is prepared to use different XML parsers, and uses adaptors which transforms the different XML nodes into its own XeNode representation. Currently three adaptors are present, for YAXO, VisualWorks XML parser and ExoboxXML parser.<br />
XML parsing speed is crucial when WSDLs are read and to decode SOAP envelopes. If performance ever becomes a major issue, you may replace this by a high speed XML parser (written in C), and create a matching adaptor (take SOAP::SoYaxXMLParserAdapter as a base).<br />
<br />
===== Package: soap ("stx_goodies_soap") =====<br />
contains all the rest, such as error classes, abstract classes, encoders/decoders, transport interfaces (adapters to HTTP), etc.<br />
<br />
===== Package: auth ("stx_goodies_soap_spray_auth") =====<br />
additional classes which deal with authentication. This is currently not maintained, and provided "as-is". No effort has been made in porting or verifying its usefulness. However, it seems to compile (at least) in VSE.<br />
Exept does not currently use these classes in any of its projects - we recommend using regular SOAP over a secure SSH (HTTPS) connection. Then this package will not be needed at all.<br />
<br />
== Classes of Special Interest ==<br />
<br />
==== SOAP__SptHTTPRequest ====<br />
performs the actual HTTP get operation for both WSDL fetching AND the actual SOAP call.<br />
The entry is "send:" which dispatches to either "send_VSE" or "send_NonVSE" (for ST/X).<br />
There, different mechanisms are used.<br />
"send_VSE" calls out to the WinInet DLL, after setting up the parameters, whereas "send_NonVSE" uses the Smalltalk socket interface and/or HTTP framework from Smalltalk/X. In ST/X, the call is asynchronous and non-blocking, meaning that the GUI is still responding while waiting for a response. In VSE, the DLL-call is blocking the VM. Be careful in case of bad/wrong network setup, if a service is unreachable, the GUI may be blocked for a longer time (it is probably a good idea to make the timeouts configurable...)<br />
<br />
==== SOAP__SpraySoapSend ====<br />
the basic call entry. By placing a halt on the "value" method, you can single step through the send/receive process.<br />
In case of decoding errors (wrong XML/WSDL), it provides the raw XML response via additional getter methods (try #inXmlOrEmpty).<br />
Also, in case of xsd:schema errors (wrong restrictions etc.), less strict API entries (extractResuming) are provided which may be able to decode a response even if erroneous.<br />
<br />
==== SOAP__WSDLClassBuilder ====<br />
the new builder class, which was not part of the original SOAP package. Generates the client class, enumerates all reachable non-simple type classes and uses the XeClassBuilder to generate type classes.<br />
XeClassBuilder used to be present in the original (2010 SOAP) version, but has been much enhanced to generate reasonable argument and type names, comments and verification code. Also, array handling and restricted simple type handling was added.<br />
<br />
==== UserPreferences ====<br />
In ST/X, the "UserPreferences current" holds all settings of the current user session.<br />
In VSE, a mimicri interface is provided for compatibility.<br />
This provides some debugging/logging flags of interest:<br />
* logHTTPRequests<br>to enable/disable logging of HTTP traffic on the Transcript. Set to true during development, false for deployed applications. The SOAP__SptHTTPRequest also contains a private Verbose class variable, which can be also set to true (nil counts as false).<br />
<br />
* soapLoggingLevel<br>controls how much debugging info is emitted from SOAP itself.<br />
<br />
* soapErrorDebugging<br>if this returns true, you will get a debugger whenever a SOAP-internal error occurs. Otherwise, the error might be reported as a SOAPFault.</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Starting_expecco_via_Command_Line/en&diff=10550Starting expecco via Command Line/en2018-02-12T19:27:46Z<p>Mawalch: Fix link to Polarion Plugin Documentation</p>
<hr />
<div>== Introduction ==<br />
<br />
expecco can be started manually via the command line, by batch or shell scripts or automatically via the crontab (Unix) or scheduled tasks / services (Windows) mechanism of the operating system. Thus, you can have tests to execute unattended and without GUI "overnight". This is also the method to integrate expecco with other quality tools, such as Jenkins, HP-Quality Center, Polarion, expecco ALM etc.<br />
<br />
Command line options allow for test suites to be loaded, executed and result files being generated without requiring user interaction.<br />
<br />
In addition to the above, expecco can also be started in a slave mode as a service, to wait for incoming test-run request from a QM system, such as expecco ALM or Polarion. Expecco can respond to request via SOAP or REST calls to load, execute and report test suites. The expeccoNET automation environment assumes that expecco is already running on each slave host, and each has been started with a "--server" command line argument. It uses HTTP+SOAP/REST to communicate with those expecco slaves by default.<br />
<br />
In this later "slave mode", expecco is installed to run as a daemon process (under Unix) or as a service (under Windows), and will be automatically started by the operating system, when it boots. The details of how it is installed vary between operating systems: under Unix, it needs to be registered in the init-tab-folder, under Windows it needs to be installed as a Windows service.<br />
<br />
== Command Line ==<br />
<br />
If expecco is started without command line arguments, it will open up showing the initial welcome screen. The same behavior as if started via the desktop.<br />
<br />
With a single file argument, expecco will read a test suite from the given file and open an editor window on it (but will not execute it).<br />
<br />
'''expecco <testsuite filename>'''<br />
<br />
This is the same behavior as if a test suite file (.ets) is dropped onto the expecco icon via the desktop.<br />
<br />
The simplest command line to execute a test suite is:<br />
<br />
'''expecco --execute <testsuite filename> ...'''<br />
<br />
:<testsuite filename> is the test suite's filename, as saved from within the expecco GUI application. This should be a saved ".ets" testSuite file. If more than one test suite filename is given, each is processed in sequence. All top-level test plans as found in the test suite(s) are executed (see below for more options).<br />
<br />
:By default, the overall execution outcome is returned by the command's return value (exit code), which is<br />
::0 - all PASSED<br />
::non-zero - any ERROR, FAILURES or INCONCLUSIVE items.<br />
<br />
The return value is useful if expecco is started via a makefile, or from Jenkins, for example.<br />
<br>If the caller needs a different exit code, use one of the "--exitCodeOnXXX" options as described below.<br />
This is useful to avoid that a ''make'' or ''jenkins'' job interprets this exit code as "expecco malfunction" and stops execution.<br />
<br />
To get a list of available options, type:<br />
'''expecco --help'''<br />
<br />
<br />
=== Command Line Options ===<br />
Command line options are handled at two places: the runtime system (Smalltalk/X VM) and the expecco application itself.<br />
When expecco is started, the VM is first to look for command line arguments and processes any of the VM options, until<br />
a non-VM option is encountered. It passes the remaining options to expecco's main entry.<br />
Thus, any option which is given after the first non-VM option will not be handled by the VM, but by expecco. Therefore, no VM options should be placed after the first non-VM option. VM options are marked as "''VM option''" in the list below.<br />
<br />
Also, some options are specific to the operating system, on which expecco is executed. These are marked as "''Windows''", "''Linux''" etc.<br />
<br />
=== Recommended Command Line Options ===<br />
<br />
To start expecco on an existing test suite, use:<br />
<br />
'''expecco <testsuite filename>'''<br />
<br />
this is also the way expecco is started, when a test suite file is double-clicked on the Linux or Windows desktop, or when a test-suite document is dropped onto the expecco icon.<br />
The above opens the expecco GUI and loads the given test suite initially. However, it does not automatically execute any test.<br />
<br />
To execute a suite, add a "'''--execute'''" argument (or in expecco 2.10, "-E"), as in:<br />
<br />
'''expecco --execute <testsuite filename>'''<br />
<br />
You will notice, that expecco shows a banner initially; this can be disabled with a '''--noBanner''' option. Also, under windows, a small tray icon is shown in the lower right, which provides a controlling UI. This is disabled with '''--noTray'''.<br />
<br />
Finally, as mentioned before, the test's outcome is reported via the exit code. If you want a little more information on the status of individual test cases, use a '''--verdicts''' option.<br />
<br />
This makes the following a good start for your command line:<br />
<br />
'''expecco --noBanner --noTray --verdicts --execute <testsuite filename>'''<br />
<br />
or, if you want to use a special parameter-file, to provide values for (some of) the project-variables:<br />
<br />
'''expecco --noBanner --noTray --verdicts --parameter &lt;param-file&gt; --execute &lt;filename&gt;'''<br />
<br />
Parameter files are XML, CSV or JSON-files containing key-value pairs. They are usually created by saving an environment from within the expecco GUI (see [[Environment Editor]]).<br />
<br />
All of the above command lines opened an expecco UI window.<br />
To execute a suite without GUI, add a "'''--noWindow'''" argument.<br />
<br />
To compose "scatter-gather" test cases from possibly multiple suites, found in a directory use:<br />
<br />
'''expecco --suiteDirectory &lt;dirName&gt; --testCaseNames "T01,T02,T05" --execute'''<br />
<br />
or, to explicitly specify the suite-files where test cases are taken from, use:<br />
<br />
'''expecco --testCaseNames "T01,T02,T05" --execute &lt;suiteFile1&gt;.ets &lt;suiteFile2&gt;.ets ...'''<br />
<br />
Finally, to get a report, add a "'''--xxxReportFile &lt;fileName&gt;'''" argument, as in:<br />
<br />
'''expecco --noBanner --noWindow --noTray --verdicts --parameter &lt;param-file&gt;''' \<br />
''' --pdfReportFile result.pdf --execute &lt;filename&gt;'''<br />
<br />
All options are described in more detail below.<br />
<br />
=== Executing Multiple Test Suites in Sequence ===<br />
<br />
It is possible to run multiple (possibly different) test suites with one command line to reduce startup and project loading times.<br />
For this, provide multiple "--execute &lt;filename&gt;" arguments to the command line, as in:<br />
<br />
'''expecco --execute &lt;suiteFile1&gt;.ets --execute <suiteFile2&gt;.ets ...'''<br />
<br />
with this command line, expecco first executes the toplevel testplan(s) from "suiteFile1.ets", then those from "suiteFile2.ets". All parameters (i.e. top-level variable values) will be taken from within the corresponding suite file.<br />
<br />
To change individual parameters, use "--parameter:key=value" arguments before the corresponding --execute argument. For example, to execute the same suite with different parameters, use a command line like:<br />
<br />
'''expecco --parameter:device=samsung --execute mobileTest.ets''' \<br />
''' --parameter:device=nexus --execute mobileTest.ets'''<br />
<br />
=== Opening a Previous Result File ===<br />
<br />
As described below, expecco can generate result files in various formats and different detail. The pdf, HTML and JUnit outputs will contain summary information to be read by humans, archived or to be passed to other programs (e.g. to Jenkins for statistics).<br />
<br />
The native result file (.elf) contains all trace and logging information including the original test suite.<br />
<br />
As such, it can be archived to ensure that the test result can always be associated to the exact suite being executed, even if the suite file is lost or has been modified in the meanwhile.<br />
<br />
These .elf result files are generated either via corresponding command line options or manually via the "''Test Results''"-"''Save Result As...''" menu item.<br />
Like regular suite files, they can be opened via the command line or via the "''File''"-"''Open...''" menu item.<br />
<br />
When opened, the original suite (at the time of execution), the trace- and log data and the execution times will be presented. It is even possible to re-execute individual blocks, test plans or the whole suite.<br />
<br />
This feature is very powerful, in that it allows for the result file to be given to a developer and will help to analyse the data values, control flows and even to rerun tests and reproduce errors/failures.<br />
<br />
=== Detailed Option Description ===<br />
<br />
==== Information/Debugging/Logging ====<br />
<br />
*'''<code>--help</code>'''<br>Prints an up-to-date list of possible options and command line arguments.<p></p><br />
<br />
*'''<code>--version</code>'''<br>Prints the expecco release identification and exits.<p></p><br />
<br />
*'''<code>--noBanner</code>''' (''VM option'')<br>Suppress the splash startup banner.<p></p><br />
<br />
*'''<code>--console</code>''' (''VM option'', ''Windows only'')<br>Open a debug console window for Stdout and Stderr.<p></p><br />
<br />
*'''<code>--verbose</code>''' (''VM option'')<br>Additional startup, execution and result info is sent in human readable format to the stderr output. This is mainly meant to analyze startup problems and is actually more useful for expecco developers. It may be too much of printout, so try "''--verdicts''" instead.<p></p><br />
<br />
*'''<code>--debug</code>'''<br>Turns on startup debugging. By default, if an error occurs during startup, expecco terminates itself. With this option enabled, a command line debugger is opened instead. This is probably only useful for plugin developers.<p></p><br />
<br />
*'''<code>--silent</code>'''<br>Suppresses most info, warning and error messages which are sent to stderr/stdout. This is mainly meant to remove unwanted informational messages (for example, when plugins cannot be loaded during startup, etc.).<br>(this option is available with expecco vsn >= 2.10)<p></p><br />
<br />
==== Startup ====<br />
<br />
*'''<code>--settings <fileName></code>'''<br>Force using <fileName> instead of the default "<code>~/.expecco/.expeccoPreferences</code>" to be used for the settings file name. Useful if you want different setups to be linked to different desktop icons, or to start expecco with particular settings from a batch or shell script. To generate a preferences file, open the "''Extras''" - ''Settings''" dialog, change the settings as required, and select the "''File''"-"''Save As...''" menu item.<p></p><br />
<br />
*'''<code>--licenseFile <fileName></code>'''<br>Use this license, instead of the default "<code>~/.expecco/.expeccoLicense</code>". If a license server (floating licenses) is used, the license server's hostname and port information is read from the settings file.<p></p><br />
<br />
*'''<code>--licenseServerHost <hostName></code>'''<br>Use this host as license server, instead of the one specified in the settings file (or if no settings file was ever specified). This may be needed when running expecco as a test slave (daemon or service).<br>(this option is available with expecco vsn >= 2.10)<p></p><br />
<br />
*'''<code>--licenseServerPort <portNr></code>'''<br>Use this port-nr when contacting the license server, instead of the one specified in the settings file (or if no settings file was ever specified). This may be needed when running expecco as a test slave (daemon or service).<br>(this option is available with expecco vsn >= 2.10)<p></p><br />
<br />
*'''<code>--noTray</code>''' (''Windows only'')<br>Disable the tray control icon (server and execute modes only).<p></p><br />
<br />
*'''<code>--tray</code>'''<br>Force a tray window to be shown, even if running in non-server (slave) mode. The tray window displays the current execution status, memory situation, thread status and other internal information, which is probably only useful for developers.<br>(this option is available with expecco vsn >= 2.10)<p></p><br />
<br />
*'''<code>--noWindow</code>'''<br>Do not open the main window (useful when scripting or executing only).<p></p><br />
<br />
*'''<code>--noDisplay</code>'''<br>Do not open any window (useful when scripting or executing only).<p></p><br />
<br />
*'''<code>--noPlugins</code>'''<br>Disable plugin loading. This makes startup somewhat faster, depending on the number of plugins found in your installation directory. You can still force individual plugins to be loaded using the "'''--loadPlugin'''" option. Use "''--noPlugins''" followed by a list of individual "''--loadPlugin''" options, to tune startup time with a minimum set of required plugins being loaded.<p></p><br />
<br />
*'''<code>--loadPlugin <pluginName></code>'''<br>Force loading a specific plugin. This is only useful if a "'''--noPlugins'''" option was given before. ''pluginName'' is the name of the folder in the "plugin" folder (under the expecco installation folder). Use "''--noPlugins''" followed by a list of individual "loadPlugin" options, to tune startup time with a minimum set of required plugins being loaded.<p></p><br />
<br />
*'''<code>--noUpdateCheck</code>'''<br>If configured by the user's settings, expecco automatically checks for updates and patches when started (by checking the eXept web-server for the presence of new patch files). This option disables that check, even if configured in the settings. Notice, that this is usually controlled by the user settings; however, in situations where settings are shared among multiple machines (network drive) and a test host has no (or should not have) internet access, it may be useful to disable this from the command line. It is especially useful, if you are disconnected from the Internet (isolated test-lab), to avoid time delays resulting from connection failures.<p></p><br />
<br />
*'''<code>--requireLogin</code>'''<br>Opens expecco in a (lightweight) multi-user mode, in which a username must be entered before the actual interaction with expecco begins. This user name will be used to load custom per-user settings (named "<code>.expeccoSettings_<name></code>") and will also be used in the generated reports. Also, the "''File''" menu will contain an additional "''Logout''" menu item, which brings back the initial login dialog.<br>This mode is useful, if expecco is used on a machine by multiple users, and expecco should remain opened (i.e. as a test stand). For example in a production floor, where tests are executed in multiple shifts by multiple operators.<p></p><br />
<br />
*'''<code>--load <fileName or packageName></code>'''<br>Loads a class file, extension or user plugin. The argument must be either the name of a Smalltalk source or binary file, or the name of a package (which must be found in the "<code>packages</code>" subfolder under the expecco installation folder). For details on how to generate such packages, read [[Creating_new_Class_Library_Packages/en | "Creating new Class Library Packages"]].<br />
<br />
==== Test Execution ====<br />
*'''<code>--execute &lt;fileName&gt;</code>'''<br>read and execute a suite. Starting with expecco 2.10, you can also use "-E &lt;fileName&gt;", which makes the command line a bit shorter.<p></p><br />
<br />
*'''<code>--execute</code>'''<br>without a filename, this should be the last argument of a scatter-gather dynamically generated suite command (see below: scatter-gather tests)<p></p><br />
<br />
==== Test Selection ====<br />
<br />
the following options allow for individual test plans to be selected for execution from a suite which contains multiple test plans. Without any such option, ''--execute'' will run all top-level testplans found in the suite in sequence.<br />
<br />
*'''<code>--testPlanName <namePattern></code>'''<br>Only execute test plans with a matching name.<br>For backward compatibility, "'''<code>--testSuiteName <namePattern></code>'''" is still supported and has the same effect.<p></p><br />
<br />
*'''<code>--testPlanTag <tagPattern></code>'''<br>Only execute test plans with a matching tag.<br>For backward compatibility, "'''<code>--testSuiteTag <tagPattern></code>'''" is still supported and has the same effect.<p></p><br />
<br />
*'''<code>--testPlanID <uuid></code>'''<br>Only execute that particular test plan (repeat to execute multiple test plans).<br>Starting with release 2.7, the following shortcut can also be used: '''<code>--testSuiteID "<uuid1>,<uuid2>,...,<uuidN>"</code>'''.<br>For backward compatibility, "'''<code>--testSuiteID <uuid></code>'''" is still supported and has the same effect.<p></p><br />
<br />
==== Scatter Gather Test Suite Composition ====<br />
<br />
these options allow for a test plan to be composed out of a single or multiple of individual suite files. When composing, a new test plan is temporarily created, which contains the specified test cases. This is in contrast to the above options, where preexisting test plans are selected for execution.<br />
<br />
Typically, this kind of composition is used when expecco is called from a QA system, such as Polarion or HP Quality Center, where individual "test sets" are composed out of a collection of existing test cases.<br />
<br />
Notice, that this may lead to longer startup times, depending on the number of suites found in the suite directory, because suite files there will be opened and searched for matching test cases. If the same set of tests needs to be executed multiple times, it may be a good idea to use the "--saveSuite" option, to have the composed suite saved into a file for later reuse.<br />
<br />
Also notice, that this works best, if testcase have unique names or are known by their ID (which is globally unique). If your test management system can provide unique identifiers, these should be used to name your testcases inside the suite (typically, a unique name of the test-case or requirement is used to name corresponding test-cases).<br />
<br>(These options are only available in release &ge; 2.7)<br />
<br />
*'''<code>--suiteDirectory <dirName></code>'''<br>defines the directory, where test suite files are searched for composed test plans. Test cases as specified in one of the options below must be found in one of the files present there. Notice, that the first file which contains a requested test case action will be chosen. Thus, you should ensure, that only one version of each suite is present there. Typically, an up-to-date test suite directory as checked out from the revision control system is specified here. If this argument is not given, test cases are searched in the list of explicitly listed suite files (".ets" arguments).<p>This option also specifies the directory where suites are found for remote execution (see description of SOAP and REST services below).</p><p></p><br />
<br />
*'''<code>--suiteTitle <string></code>'''<br>defines the name of the new test plan, which is created dynamically. This is used to control the labels in the generated report files.<p></p><br />
<br />
*'''<code>--testCaseNames <name-list></code>'''<br>defines the test cases to be included in the test by name. name-list is a list of comma-separated names of the individual test actions.<br>Please only use this option, if your testcases have unique names and are found only once in any suite found in the suite directory. Otherwise, the first suite which contains that name will be chosen (see below for better selection options).<p></p><br />
<br />
*'''<code>--testCaseFIDs <id-list></code>'''<br>defines the test cases to be included in the test by function ID. id-list is a list of comma-separated UUIDs of the individual test actions.<br>This option is probably not very user-friendly for a human, but allows for a calling program (or script) that the testcase is found even if it has been renamed in the meanwhile (remember that functional IDs are assigned once when an item is created and remain unchanged over the whole lifetime).<p></p><br />
<br />
*'''<code>--testCaseIDs <id-list></code>'''<br>defines the test cases to be included in the test by version ID. id-list is a list of comma-separated UUIDs of the individual test actions.<br>This option may be very unfriendly for a human user, but allows for a calling program (or script) to ensure that a particular testcase with a particular version is found and executed, even if the testcase has been renamed or modified in the meantime (remember that the ID is changed with every modification). If the same testcase is found in multiple suite files (i.e. in different versions), this will ensure that the correct version will be executed<p></p><br />
<br />
*'''<code>--saveSuite <fileName></code>'''<br>saves the generated as-hoq suite. Useful if you want to archive such a dynamically generated scatter-gather suite separately from the result file(s), or to automatically construct new suites. Notice that the ".elf" result file will always include the generated ad-hoq suite, so archival of the generated ad-hoq suite is only needed if you generate pdf, HTML or other non-elf reports.<p></p><br />
<br />
==== Test Parameters ====<br />
<br />
*'''<code>--parameter &lt;fileName&gt;</code>''' / '''<code>-P &lt;fileName&gt;</code>'''<br>Load a parameter set from a file. A parameter set contains values for a test suite's top environment. This can be either in XML format, as generated with the [[Environment_Editor|"''Save-Parameter-Set''" menu function]], a CSV file, containing key-value pairs or a JSON file containing a JSON dictionary object.<p>Parameter files in either format can be created manually in a text editor, provided by a QM system (such as expecco ALM, HP Quality Center or similar), generated by another controlling program or generated by expecco itself via the "''Save-Parameter''" menu function of the [[Environment_Editor|environment editor]].</p><p>The parameter file may contain values for a subset of the environment variables. In this case, the values from the parameter file overwrite corresponding values present in the loaded test suite, leaving other values unchanged.</p><br />
<br />
*'''<code>--parameter:&lt;key&gt;=&lt;value&gt;</code>''' / '''<code>-P:&lt;key&gt;=&lt;value&gt;</code>'''<br>Sets an individual parameter for the next "--execute" argument.<p>If multiple "--execute" arguments are given (i.e. multiple suites are to be executed in sequence), these parameter values are collected and given to the next execution only, and overwrite corresponding values from either a parameter set (see above) or from the suite itself.</p><p>Thus, it is possible to execute the same suite with different parameters in one command line (see example above).<br>(this option is available with expecco vsn >= 2.10)</p><br />
<br />
==== Test Execution via Scripting ====<br />
*'''<code>--scriptFile &lt;fileName&gt;</code>'''<br>read and execute a script from a file (see scripting below).<br />
<br />
==== Reporting ====<br />
<br />
*'''<code>--verdicts</code>'''<br>Send execution and result info in human readable format to the stderr output. (see [[#Verdicts Example|example below]].)<p></p><br />
<br />
*'''<code>--logFile <fileName></code>'''<br>Used to change the name of the generated log file, where stderr is written to.<br>This is only useful if running in server mode.<p></p><br />
<br />
*'''<code>--exitCode <n></code>'''<br>Defines the exit code to be used independent of the test outcome.<br>The default is 0 (zero) if all tests pass, and non-zero when they do not. However, some calling programs (make/jenkins,...) may misinterpret this exit code and treat the whole job as non-executable. Use this flag to prevent this. It is still possible to change the exitCode for a particular outcome by adding one of the following options after this option.<p></p><br />
<br />
*'''<code>--exitCodeOnFail <n></code>'''<br>Defines the exit code in case any test ends with a test-failure status.<br>The default is 0 (zero), so that when you run expecco out of make, Jenkins or other tools which check for the exit status, the calling program does not interpret this status as if expecco itself failed to execute. This option also changes the exitCodeOnError and exitCodeOnInconclusive values (see below), unless explicitly defined by those options.<p></p><br />
<br />
*'''<code>--exitCodeOnError <n></code>'''<br>Defines the exit code in case any test ends with a test-error status.<br>The default is 0 (zero), so that when you run expecco out of make, Jenkins or other tools which check for the exit status, the calling program does not interpret this status as if expecco itself failed to execute. This option also changes the exitCodeOnInconclusive values (see below), unless explicitly defined by that option.<p></p><br />
<br />
*'''<code>--exitCodeOnInconclusive <n></code>'''<br>Defines the exit code in case any test ends with an inconclusive status.<br>The default is 0 (zero), so that when you run expecco out of make, Jenkins or other tools which check for the exit status, the calling program does not interpret this status as if expecco itself failed to execute.<p></p><br />
<br />
*'''<code>--elfReportFile <elfFilename></code>'''<br>Writes a report in expecco's native XML logfile format. The report contains a lot of detail information and could be processed by an XSLT processor or a similar tool. It also contains enough additional information about test plans and actions so that expecco can redisplay the activity log tree from this file. The generated file can be opened directly via the command line ("expecco <file>.elf") or by double clicking on the elf-file in the operating system's desktop.<p></p><br />
<br />
*'''<code>--csvReportFile <csvFilename></code>'''<br>Writes a summary report in CSV format. Each row consists of:<br><br />
** ''TESTSUITE'' - the filename<br />
** ''TESTPLAN'' - the test plan<br />
** ''TESTCASE'' - the test case<br />
** ''VERDICT'' - the test result; one of SUCCESS, FAILED, ERROR or INCONCLUSIVE<br />
** ''INFO'' - additional info in case of failure<br />
:Additional pseudo verdicts such as STARTTIME, ENDTIME etc. are written. A typical CVS output file can be found in the [[#CSV File Example|examples]].<p></p><br />
<br />
*'''<code>--textReportFile <textFilename></code>'''<br>Writes a summary report in a human readable textual format. A typical text output file can be found in the [[#Textual File Example|examples]].<p></p><br />
<br />
*'''<code>--xmlReportFile <xmlFilename></code>'''<br>Writes a report in XML format. The report contains a lot of detail information and could usually be processed by an XSLT processor or similar tool. A typical XML output file can be found in the [[#XML File Example|examples]].<p></p><br />
<br />
*'''<code>--pdfReportFile <pdfFilename></code>'''<br>Writes a summary report in pdf format.<p></p><br />
<br />
*'''<code>--htmlReportFile <htmlFilename></code>'''<br>Writes a summary report in HTML format.<p></p><br />
<br />
*'''<code>--junitReportFile <htmlFilename></code>'''<br>Writes a summary report in a JUnit compatible XML format. Useful, when expecco is to be started by Jenkins or similar driver programs.<p></p><br />
<br />
*'''<code>--polarionReportFile <htmlFilename></code>'''<br>Writes a summary report in an XML format which is especially suited for the Polarion QM tool. The structure of the generated XML is the same as with the JUnit format above, but a slightly different time format is used.<p></p><br />
<br />
*'''<code>--reportTemplateName <name></code>'''<br>Use the given report template (must be an element inside the test suite) for the following "--xxxReportFile" argument. If no such argument is given, the default template as defined in the suite is used.<p></p><br />
<br />
==== Services ====<br />
<br />
*'''<code>--server</code>'''<br>Starts expecco in server mode. This combines the "''--service''", "''--infoService''" and "''--remoteControlService''" flags. All of those services as described below are started with that single command line argument.<p></p><br />
<br />
*'''<code>--service</code>'''<br>Starts expecco in server mode. In this mode, HTTP-SOAP and HTTP-REST requests can be used to remote-control expecco's execution; especially, to execute and monitor tests, and upload results. The most obvious use for this is for expecco to act as an execution host (test slave) for an expecco ALM or Polarion server.<br>However, because standard protocols are used, this may also be used to interface the execution engine to many other QM management or automation systems (e.g. HP Quality Center). The interface is described below.<p></p><br />
<br />
*'''<code>--infoService</code>'''<br>Provide an additional info service which allows for monitoring and control of an expecco server via a web browser (server mode only).<p></p><br />
<br />
*'''<code>--remoteControlService</code>'''<br>Provide an additional service to interact with a running test. Dialog requests, single stepping, starting, pausing and stopping of tests is possible via remote REST requests. This service is used by the Android remote control app, which is available upon request (server mode only).<p></p><br />
<br />
*'''<code>--port <portNr></code>'''<br>Used to change the HTTP and SOAP port numbers, when running in server mode.<br>The default is 9090 (server mode only).<p></p><br />
<br />
*'''<code>--scripting <portNr></code>'''<br>Enable scripting (remote control via Telnet ASCII interface) on portNr ([[#Scripting Example|see more below]]).<p></p><br />
<br />
*'''<code>--allowHost <hostName></code>'''<br>Allow hostName to connect to the scripting port. Repeat for multiple hosts (see more below).<p></p><br />
<br />
==== Utility Functions ====<br />
<br />
*'''<code>--diff <file1> <file2></code>'''<br>Print differences between two test suites. This can be used e.g. to automatically generate log messages for a revision control system (please read the section on "Integration with Source Code Management System" below).<br>(This function is only available in release &ge; 2.7)<p></p><br />
<br />
=== Command Exit Status ===<br />
<br />
*0 - all tests passed<br />
<br />
*>0 various other errors (command line, file not found, etc.)<br />
<br />
*101 - at least one test failed (FAIL status). This exitCode can be overwritten by a command line argument.<br />
<br />
*102 - at least one test was inconclusive (INCONCLUSIVE status). This exitCode can be overwritten by a command line argument.<br />
<br />
*103 - at least one test lead to an error (ERROR status). This exitCode can be overwritten by a command line argument.<br />
<br><br />
The diff option returns 0 if the compared suites are the same, or 200+n, (where n is the number of differences) otherwise.<br />
<br />
== Sample Outputs ==<br />
<br />
The following output files were generated by executing the test suite from the file:<br />
:"C:\Programme\exept\expecco\testsuites\projects\Example.ets"<br />
which contains a single test plan named:<br />
:"Example Testplan"<br />
which contains three test cases named:<br />
:"Test1"<br />
:"Test2"<br />
:"Test3-Should fail"<br />
of which the first two are supposed to PASS and the last one generates an ERROR.<br />
<br />
All timestamp information is written in ISO8601 format.<br />
<br />
Be reminded that the following reports are condensed reports, which only contain a subset of the information contained in expecco's native ".elf" file format. The "elf" file contains all of the execution, trace and data-flow information and the original suite as executed. "elf"-files can be reloaded at any time into the expecco UI and the test be reexecuted. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail).<br />
<br />
Thus it is highly recommended that these "elf" files are archived after a test run, in addition to any of the condensed report files (e.g. pdf or JUnit report).<br />
<br />
<br />
=== CSV File Example ("<code>--csvReportFile</code>" option) ===<br />
<br />
By default, entries are separated by ";"-characters. Additional double quotes (") are used to delimit strings with embedded ";" or spaces. Any double quote within such a string is doubled.<br />
CSV is a simple and very common interchange format.<br />
For example, CSV files can be imported into Microsoft Word, Excel and OpenOffice (and many other).<br />
<br />
TESTSUITE;TESTPLAN;TESTCASE;VERDICT;INFO<br />
;;;StartTime;2008-10-31T08:57:13.689<br />
"C:\Programme\exept\expecco\testsuites\projects\Example.ets";"Example Testplan";Test1;PASSED; <br />
"C:\Programme\exept\expecco\testsuites\projects\Example.ets";"Example Testplan";Test2;PASSED; <br />
"C:\Programme\exept\expecco\testsuites\projects\Example.ets";"Example Testplan";"Test3 - Should fail";ERROR; <br />
;;;EndTime;2008-10-31T08:57:18.746<br />
<br />
=== XML File Example ("<code>--xmlReportFile</code>" option) ===<br />
<br />
<SummaryReport><br />
<StartTime>2008-10-31T08:56:49.774</StartTime> <br />
<TestSuite><br />
<File>C:\Programme\exept\expecco\testsuites\projects\Example.ets</File> <br />
<TestPlan><br />
<Name>Example Testplan</Name> <br />
<TestCase><br />
<Name>Test 1</Name> <br />
<Verdict>PASSED</Verdict> <br />
</TestCase><br />
<TestCase><br />
<Name>Test 2</Name> <br />
<Verdict>PASSED</Verdict> <br />
</TestCase><br />
<TestCase><br />
<Name>Test 3 - Should fail</Name> <br />
<Verdict>ERROR</Verdict> <br />
</TestCase><br />
</TestPlan><br />
</TestSuite><br />
<EndTime>2008-10-31T08:56:55.142</EndTime> <br />
</SummaryReport><br />
<br />
This is not to be confused with the "elf" result file format, which is also XML based, but contains a lot more detail.<br />
<br />
Notice also, that the JUnit report format ("<code>--junitReport</code>" option) is similar in structure but uses different tags.<br />
JUnit reports are compatible to reports generated by Java JUnit frameworks.<br />
They can thus be used to generate reports and trends in Jenkins/Hudson and other tools which understand the JUnit report format.<br />
<br />
=== Textual File Example ("<code>--textReportFile</code>" option) ===<br />
<br />
Test Execution Summary<br />
Start: 2008-10-31 08:56:12.751<br />
TestSuite: "C:\Programme\exept\expecco\testsuites\projects\Example.ets<br />
TestPlan: Example Testplan<br />
Test 1 ....................... PASSED<br />
Test 2 ....................... PASSED<br />
Test 3 - Should fail ......... ERROR<br />
Finish: 2008-10-31 08:56:18.009<br />
<br />
<br />
<!--Orginal:<br />
<br />
--------------------------------------------------------------------------------------------------------------<br />
TESTSUITE;TESTPLAN;TESTCASE;VERDICT;INFO<br />
;;;StartTime;2008-10-31T08:57:13.689<br />
"C:\Programme\exept\expecco\testsuites\projects\Example.ets";"Example Testplan";Test1;PASSED; <br />
"C:\Programme\exept\expecco\testsuites\projects\Example.ets";"Example Testplan";Test2;PASSED; <br />
"C:\Programme\exept\expecco\testsuites\projects\Example.ets";"Example Testplan";"Test3 - Should fail";ERROR; <br />
;;;EndTime;2008-10-31T08:57:18.746<br />
--------------------------------------------------------------------------------------------------------------<br />
<br />
----------------------------------------------------------------------------<br />
<SummaryReport><br />
<StartTime>2008-10-31T08:56:49.774</StartTime> <br />
<TestSuite><br />
<File>C:\Programme\exept\expecco\testsuites\projects\Example.ets</File> <br />
<TestPlan><br />
<Name>Example Testplan</Name> <br />
<TestCase><br />
<Name>Test 1</Name> <br />
<Verdict>PASSED</Verdict> <br />
</TestCase><br />
<TestCase><br />
<Name>Test 2</Name> <br />
<Verdict>PASSED</Verdict> <br />
</TestCase><br />
<TestCase><br />
<Name>Test 3 - Should fail</Name> <br />
<Verdict>ERROR</Verdict> <br />
</TestCase><br />
</TestPlan><br />
</TestSuite><br />
<EndTime>2008-10-31T08:56:55.142</EndTime> <br />
</SummaryReport><br />
----------------------------------------------------------------------------<br />
<br />
-------------------------------------------------------------------------<br />
Test Execution Summary<br />
Start: 2008-10-31 08:56:12.751<br />
<br />
TestSuite: "C:\Programme\exept\expecco\testsuites\projects\Example.ets<br />
TestPlan: Example Testplan<br />
Test 1 ....................... PASSED<br />
Test 2 ....................... PASSED<br />
Test 3 - Should fail ......... ERROR<br />
<br />
Finish: 2008-10-31 08:56:18.009<br />
------------------------------------------------------------------------- --><br />
<br />
=== Verdicts Example ===<br />
<br />
the "<code>--verdicts</code>" option generates a simple trace on the standard error (to be redirected into a file):<br />
<br />
C:\selftest\commandLineArgs> expecco --noBanner --noTray --verdicts <br />
--parameter paramesForTest.xpar --execute parameterTest.ets<br><br />
Expecco [info]: start testSuite "parameterTest.ets"...<br />
Expecco [info]: using parameters "paramesForTest.xpar"...<br />
Expecco [info]: start testPlan "Test Parameters From CommandLine"<br />
Expecco [info]: start testCase "Validate Parameters"<br />
Expecco [info]: done testCase "Validate Parameters"; STATUS=PASSED<br />
Expecco [info]: done testPlan "Test Parameters From CommandLine"; STATUS=PASSED<br />
Expecco [info]: done testSuite "parameterTest.ets"; STATUS=PASSED<br />
<br />
== Integration with Quality Management and Automation Tools ==<br />
<br />
=== Integration with Jenkins ===<br />
<br />
To have expecco tests being executed automatically by Jenkins, take the following example as a guideline. This is a real world setup, taken from our own setup within eXept.<br />
<br />
# Create a test job, which is triggered by a successful build (or a change in the test suite repository)<br />
# Check the "Block Build while prerequisite Jobs are Active" flag<br />
# Check either the "Trigger from Source Code Management" or the "Trigger from other Job" flags<br />
# Check "Abort build if it is Stuck" (just to make sure, that a faulty suite does not block Jenkins)<br />
# Check "Fail the Build if Stuck" and give it a reasonable elastic Time-out Strategy (we use 300% of the last 10 builds, to make sure a longer execution time due to more test cases will not be interpreted as a stuck, and an extra timeout of 30 minutes. The timeout is very generous for the expected execution time of a few minutes).<br />
# Check "Run xvnc during Build" to allow for monitoring, what is going on. This is also required, if the test needs a UI.<br />
# Define the "Build Procedure" as "Execute Shell Script" (Unix/Linux) or "Execute Batch Job" (Windows)<br />
# Enter a build procedure similar to the ours, which is:<br />
#::<code>cd exept\expecco\application<br />
#::del *.junit<br />
#::expecco.com --noBanner --exitOnInternalError --noTray \<br />
#::::--jUnitReportFile selfTestResult.junit \<br />
#::::--execute ..\projects\expecco\eXpeccoSelfTest.ets<br />
#::expecco.com --noBanner --noTray \<br />
#::::--jUnitReportFile CommunicationWithExpeccoNETResult.junit \<br />
#::::--execute ..\projects\expecco\CommunicationWithExpeccoNET.ets</code><br />
#:The details (especially paths and names) will of cause be different in your setup. The above uses the relative paths as it first changes the current directory to where the previous build has compiled the executable, which will of course not be the case in your setup.<br />
# Define a "Post-build Action"<br />
# Check "Publish JUnit Test Results"<br />
# Enter a path expression to declare the location of the resulting reports. Here, we used:<PRE>exept\expecco\application\*.junit</PRE><br />
# Check the "Publish Test Attachments" flag, so the results will be presented in the Jenkins management console<br />
<br />
That's it! Because expecco has been told to generate JUnit compatible report files, we can use Jenkins' existing JUnit support. However, the JUnit XML format does not support the full range of information which is present in the native expecco result files (especially the activity log and pin value information is not included). Therefore, it is a good idea to also generate a regular ".elf" (expecco log file) and add it to the archived build artefacts.<br />
<br />
=== Integration with expecco ALM ===<br />
Expecco and expecco ALM (formerly called "''expeccoNET''") have been originally designed to work together. Therefore, only a minimum setup is required:<br />
# ensure that an expecco test execution slave is running on each test host (server farm, virtual machines, etc.). Depending on the operating system, this is either done by installing expecco as a service (Windows), or by adding appropriate startup actions to your "init.d" files (Unix).<br />
# define the test host(s) in expecco ALM.<br />
# (optionally) define the devices available and attached to the execution slave machine in expecco ALM<br />
<br />
Expecco ALM will ask the expecco slaves about their operating system environment. So jobs will be automatically executed on matching CPU/OS machines. However, if tests require special resources (devices) to be attached, these must be defined and listed in expecco ALM as well. If your test has corresponding resource-requirements defined (see resources/inventory), expecco ALM will both ensure that the test will execute on the correct machine, and also reserve the resource during the execution. Also, test scheduling, if defined to be automatic, will be optimized to minimize resource usage, and to ensure that a higher number of tests can be executed in parallel.<br />
<br />
=== Integration into a SOA Infrastructure ===<br />
<br />
For this, expecco should be started on the test host(s) in so called "slave" mode.<br />
In this mode, expecco awaits for execution commands via SOAP or REST, executes tests in the background and returns status information (progress) and results (reports).<br />
<br />
Because tests may execute for a long time (hours or even days), the execution is performed asynchronously; first, the test has to be downloaded to the slave, then execution started. The start-command returns a ticket, which is a test-run-identifier, by which the execution progress can be queried (polled) while the test is running. Finally, a "finished" status is returned, upon which the result can be acquired via another service call.<br />
<br />
Multiple such test slaves can be started on multiple machines, and each test slave may (if required) execute multiple tests in parallel (although this is usually limited to one, to avoid conflicts when external resources are accessed).<br />
<br />
To start expecco in slave mode, use the command line:<br />
expecco --service<br />
<br />
or, if the default port (9090) is not available, use:<br />
expecco --service --port 9090<br />
<br />
The service interface is described below; typically, you can talk to expecco via:<br />
http://localhost:9090/expeccoService<br />
or:<br />
http://localhost:9090/expeccoService/rest<br />
<br />
The SOAP wsdl is returned via:<br />
http://localhost:9090/wsdl/ExpeccoSOAPService.wsdl<br />
<br />
and - if the inforService is also running - general status information with:<br />
http://localhost:9090/info<br />
<br />
=== Integration with HP Quality Center ===<br />
<br />
This is described in the [[HP Quality Center Plugin]] document.<br />
<br />
=== Integration with Polarion ===<br />
This is described in the [[PolarionPlugin Reference/en|Polarion Plugin]] document.<br />
<br />
== Integration with Source Code Management Tools ==<br />
<br />
=== Background Info on what is Contained in a ".ets" File ===<br />
Expecco stores testsuites in a file with '.ets' extension (which stands for: "''Expecco-Test-Suite''") and result logs in '.elf' files (stands for: "''Expecco-Log-File''").<br />
These are technically zip files - i.e. a bundle of individual files which can be extracted with the common zip command line tool (winzip under Windows systems, zip/unzip under Unix systems).<br />
<br />
For example, "<code>unzip -l foo.ets</code>" lists the individual components, of which especially the block descriptions and attachments may be of interest.<br />
<br />
Notice, that you have to be careful when ets-files are bundled with zip manually: for various consistency checks, expecco generates a validation signature of the components and saves this as an additional file inside the .ets file.<br />
This signature file must be preserved and it must be consistent with the other zip-components. In effect, this means that an ets can only be constructed from the very same components, using the very same signature file as were extracted before. Otherwise, expecco refuses to load the ".ets" file later.<br />
<br />
=== Version Management of ".ets" files ===<br />
<br />
Unless a QA system like "expecco ALM" is used, ets-files can be stored and maintained in any other source code management (SCM) system, for example, CVS, SVN, hg/Mercurial, git, Perforce etc.<br />
Make sure to store the .ets as binary file, and/or disable source expansion of version tag lines (for example, "$Header" or "$Id" in CVS). Consult your particular SCM system's documentation on how this is done.<br />
<br />
As an alternative, it is possible to unzip the ets into individual components, store them separately, and zip them back into an ets, when a previous version is extracted from the SCM system. However, you must be careful to preserve the contents exactly as is, including the signature and other meta data, and not mix versions. I.e. all individual component files must be checkedIn/out in sync and as a group - it is not possible to update individual files from previous versions. The reason is that action blocks are referred to by their versionID, and these IDs will certainly be inconsistent, when previous versions of individual action blocks are mixed into another version's suite.<br />
<br />
If, for whatever reason, you must checkin individual action blocks, we highly recommend to check in BOTH the bundled ets (and use that for later test execution), AND check in the individual components, and use only those for meta actions, such as comparison, documentation or other administrative tasks.<br />
<br />
=== Generating Diff Lists or other Version Information ===<br />
<br />
Many source code management systems allow for hook-scripts to be added to checkin/checkout actions, and/or to redefine the command to be used for diff-list generation.<br />
<br />
For example, in the SVN system, an external diff tool can be defined. You could write a little shell or batch script, which calls expecco with the "<code>--diff</code>" option which is described above. Thus, you would get meaningful diff output even from checked in ets-bundle files.<br />
<br />
The "<code>expecco --diff</code>" option is also useful as a command line tool to get diff lists - even if your SCM system does not allow for such automatic hooks.<br />
<br />
== Scripting ==<br />
<br />
Expecco can be scripted either by reading a script from a file or remote controlled via a telnet like command-line interface.<br />
This is useful to execute complex test scenarios and meta tasks, to create or manipulate test suites automatically and for self-testing expecco by using another expecco to control its GUI.<br />
It can also be used to execute and automate more complex scenarios without using expecco ALM.<br />
<br>Example uses are:<br />
* Sequentially load and/or execute all suites found in a folder, reimport libraries, save the updated suite<br />
* Construct new suites by merging/selecting tests from other suites<br />
* Bulk renaming, commenting, attributing etc.<br />
* Change attachments inside a number of suites<br />
* Controlling an application or web interface (via a GUI plugin) and saving a sequence of screen shots<br />
<br />
By default, the scripting interface expects expressions in JavaScript syntax (but with a Smalltalk object model), similar to the language used for elementary block definition. However, the language can be changed to Smalltalk syntax via a "~" directive.<br />
<br />
=== Script File Example ===<br />
<br />
To control expecco via a scriptfile, use the "<code>--scriptFile &lt;filename&gt;</code>" command line argument, where <filename> must be a file containing JavaScript expressions.<br />
<br />
For example, the following script file named "run3Suites.js" may contain the code:<br />
<PRE><br />
// Example for an automatic expecco script.<br />
// (loads and executes a number of test suites)<br />
//<br />
<br />
// to enable debugging in case of an error.<br />
// STXScriptingServer.errorDebugging(true);<br />
<br />
var files = [<br />
"foo.ets",<br />
"bar.ets",<br />
"baz.ets",<br />
];<br />
<br />
<br />
Expecco::ExpeccoPreferences.current.automaticReimportOnLoad(true);<br />
Expecco::ExpeccoPreferences.current.checkForReimportableImportsOnLoad(true);<br />
Expecco::ExpeccoPreferences.current.checkForAnchestorOnAutomaticReimport(false);<br />
// Expecco::ExpeccoPreferences.current.libraryPath(importPathes);<br />
<br />
// --------------------<br />
<br />
function executeTestPlan ( aTestPlan ) {<br />
Stderr.nextPutLine("executing testplan "+aTestPlan.name()+"...");<br />
resultList = aTestPlan.execute();<br />
Stderr.nextPutLine("done.");<br />
}<br />
<br />
function runSuite(suiteFile) {<br />
var loadedProject;<br />
<br />
Stderr.nextPutLine("loading "+suiteFile+"...");<br />
expecco.loadProjectFromFile(suiteFile);<br />
loadedProject = expecco.project();<br />
<br />
if (loadedProject == null) {<br />
Stderr.nextPutLine("failed to load library "+suiteFile+".");<br />
Smalltalk.exit(1);<br />
} else {<br />
loadedProject.allTestPlansDo( executTestPlan );<br />
}<br />
};<br />
<br />
files.do(runSuite);<br />
</PRE><br />
<br />
And can be executed with:<br />
<br />
expecco --scriptFile run3Suites.js<br />
<br />
for windowless operation, use the "<code>--noWindow</code>" command line argument.<br />
To speed up the startup, you can turn off the loading of plugins, with a "<code>--noPlugins</code>" argument (and possibly load any required plugins explicitly via additional plugin arguments).<br />
Finally, enable debug messages with a "<code>--debug</code>" argument.<br />
Thus, the recommended options for scripting are:<br />
<br />
expecco --debug --noPlugins --noWindow --scriptFile run3Suites.js<br />
<br />
of course, this command line can be put into a shell (or batch) script file, and then executed with a single word command.<br />
<br />
=== Telnet Scripting Example ===<br />
<br />
The remote scripting service is enabled when a "<code>--scripting</code>" command line argument is given.<br />
By default, the service only accepts connections from the local host (for security reasons). Using the "<code>--allowHost</code>" option, more hosts can be gained access to the scripting feature - but be aware, that this opens a potential security hole, as all of the internal functions can be accessed via the scripting system (and this includes the possibility to write files and call operating system services with the access rights of the one who started the scripting server).<br />
<br />
When used with a remote script connection (telnet),<br />
additional connection- and execution related commands are introduced by lines starting with the "~" (tilde) escape character (similar to telnet).<br />
For example, "~." (tilde-period) is used to close the connection.<br />
Press "~?" (tilde-question) for help.<br />
<br />
The following is a trace of a typical scripting session (user input in bold):<br />
<br />
c:\programs\expecco> <b>expecco --scripting 8008</b><br />
c:\programs\expecco> ... expecco now running in the background with GUI ...<br />
...<br />
c:\programs\expecco> <b>telnet localhost 8008</b><br />
Welcome to Expecco (Type ~? for help)<br />
> <b>println(expecco);</b><br />
an Expecco::Browser<br />
> <b>expecco.menuNewProject();</b><br />
...expecco performs the new-function from its menu...<br />
> <b>expecco.loadProjectFromFile("C:\Users\cg\testsuites\webedition\projects\BearerTest.ets");</b><br />
...expecco loads the testSuite...<br />
> <b>expecco.close();</b><br />
> <b>~.</b><br />
Lost Connection.<br />
c:\programs\expecco><br />
<br />
You can also start a scripting session without an initial expecco browser window:<br />
<br />
c:\programs\expecco> <b>expecco --noWindow --scripting 8008</b><br />
c:\programs\expecco> ... expecco now running in the background without GUI ...<br />
...<br />
c:\programs\expecco> <b>telnet localhost 8008</b><br />
Welcome to Expecco (Type ~? for help)<br />
> <b>println(expecco);</b><br />
an Expecco::Browser<br />
> <b>expecco;</b><br />
> <b>~v+</b> // turn result-printing on<br />
> <b>expecco</b><br />
an Expecco::Browser<br />
> <b>~v-</b> // and off again<br />
> <b>expecco.loadProjectFromFile("~/SomeTest.ets");</b><br />
...expecco loads the testSuite...<br />
> <b>var blk = expecco.project.elementWithName("My Action");</b><br />
> <b>blk.name("My Fun Action");</b><br />
> <b>expecco.saveProjectToFile("~/ModifiedTest.ets");</b><br />
> <b>expecco.close();</b><br />
><b>~.</b><br />
Lost Connection.<br />
c:\programs\expecco><br />
<br />
== Scripting API Overview ==<br />
<br />
A few objects are predefined by name; among them are "''expecco''", which refers to the browser itself (i.e. the UI) and "''environment''", which refers to a collection of variable bindings (this is a dictionary of interpreter variables - not to be confused with a variable environment as known inside an expecco activity block).<br />
<BR>New variables can be defined with a "<code>var &lt;name&gt;;</code>" statement. For example:<br />
<CODE><PRE><br />
var ws;<br />
<br />
ws = new ExpeccoWorkspaceApplication;<br />
ws.open();<br />
ws.close();<br />
</PRE></CODE><br />
<br />
==== expecco Object ====<br />
<br />
The variable named "''expecco''" refers to the opened GUI-object, which represents the expecco application itself.<br />
<br />
===== Expecco Functions =====<br />
<br />
*'''project()'''<br>the current project<br />
*'''currentApplication()'''<br>the current page (initially, there is only one)<br />
*'''currentTreeApplication()'''<br>the current tree sub-application<br />
<br />
*'''selectModelItem( anItem )'''<br>select an item and open an editor for it<br />
*'''selectedModelItems()'''<br>returns a collection of selected items<br />
<br />
===== Menu Functions =====<br />
These execute the underlying menu functions (as if clicked by the user).<br />
<br />
*'''menuNewProject()'''<br>creates a new testSuite<br />
*'''menuOpen()'''<br>opens a dialog requesting a testSuite<br />
*'''menuExit()'''<br>closes the expecco application<br />
<br />
*'''loadProjectFromFile(fileNameString)'''<br>load a testSuite<br />
*'''saveProjectToFile(fileNameString)'''<br>save the testSuite<br />
*'''selectTestPlanWithName(testPlaneNameString)'''<br>select a testplan item by name<br />
*'''selectTestPlanWithFunctionalId(uuid)'''<br>select a testplan item by uuid<br />
<br />
*'''testSuite()'''<br>retrieves the testSuite object (see below)<br />
<br />
===== Test Suite (Project) Functions =====<br />
the project as returned by the above "project()" function provides access to its elements:<br />
<br>(see also [[ Expecco API#Test Suite Project Functions]])<br />
<br />
*'''authorName()'''<br>get the author name string<br />
*'''authorName(aString)'''<br>set the author name string<br />
*'''versionString()'''<br>get the version string<br />
*'''versionString(aString)'''<br>set the version string<br />
*'''projectsWorkingDirectory()'''<br>the directory, where attachments etc. are found<br />
*'''ensureEnvironment()'''<br>an instantiated environment (concrete values). See below.<br />
*'''elementWithName( nameString )'''<br>returns a matching element or null if not found<br />
*'''elementWithId( aUUID )'''<br>returns that element or null if not present. (create the UUID with "<stringConstant>.asUUID" )<br />
*'''elementWithFunctionalId( aUUID )'''<br>returns that element or null if not present<br />
<br />
==== Environment Object ====<br />
<br />
Environment objects are used to store key-value bindings for expecco variables. Environments form a hierarchy, where values are searched for in an environment's parent environment, if not present. This hierarchy follows the containing compound activity chain up to the project (= test suite) environment.<br />
Additional temporary environments are kept by the executor and the browser, to keep temporary values for a single execution's or a single session's lifetime.<br />
<br />
*'''at(key)'''<br>retrieves a value, given the name of the entry. Raises and error if no variable exists by that name.<br />
*'''at_ifAbsent(key, default)'''<br>like above, but returns default if no variable exists by that name (instead of raising an error).<br />
*'''includesKey(key)'''<br>true if a variable by that name exists, false otherwise.<br />
*'''at_put(key, value)'''<br>store value as variable named key. Raises an error, in an attempt to change a readOnly variable<br />
*'''environmentDescription()'''<br>returns the environment's description. This describes types, default values and read/write attributes per entry.<br />
&nbsp;<br />
<br />
==== EnvironmentDescription Object ====<br />
<br />
This is a collection of entries which describe variables of an environment. It does only hold the description, not the bindings themselves; i.e. it contains the information required to instantiate an environment. EnvironmentDescriptions inherit from OrderedCollection and therefore entries are accessed via "at:" using a numeric index from 1 to the environmentDescription's size.<br />
<br />
Entries (as per variable) provide the following protocol:<br />
<br />
*'''name()'''<br>the name of the variable<br />
*'''isReadOnly()'''<br>true if readonly<br />
*'''defaultValue()'''<br>the initial value, assigned when the environment is created<br />
*'''datatype()'''<br>the type of the variable<br />
*'''comment()'''<br>description<br />
&nbsp;<br />
<br />
== Remote Controlling and Monitoring Expecco ==<br />
<br />
Expecco itself can be automated by various mechanisms:<br />
<br />
* via command line arguments (described in [[ #Command Line | "Command Line"]] above)<br />
<br />
* via script files (see [[ #Script File Example | "Script File Example"]] above)<br />
<br />
* via the telnet interface (see [[ #Telnet Scripting Example | "Telnet Scripting Example"]] above)<br />
<br />
* via standard RPC mechanisms, such as SOAP or REST.<br />
<br />
Especially the RPC mechanisms are useful to integrate expecco into the company test infrastructure.<br />
Such interfaces are meant for programmatic control of an expecco slave from quality management, application life cycle and other scheduling tools.<br />
Our own companion product, expecco ALM and third party tools, such as Polarion use these service interfaces.<br />
<br />
Notice, that for integration into a Jenkins infrastructure, command line arguments or scripts may be a more cost effective means to control automated expecco testruns.<br />
<br />
=== Expecco as a Slave Node in a Test Lab ===<br />
<br />
The service interfaces are useful to control unmonitored slave machines in the network, among which expecco test execution jobs are scheduled by another program. Expecco ALM and other quality management tools use these to initiate test runs in a test server farm.<br />
For this, the basic operations "download of a suite", "execute a suite" and "requesting execution results" are available as service calls.<br />
<br />
Both SOAP and REST services are available, if expecco is started with the "''--server''" argument.<br />
An optional "''--port''" argument allows for the HTTP port to be changed from the default (9090) on which expecco is listening.<br />
<br />
For debugging and testing, the service can be also be started from the interactive UI, via expecco's main menu (in the "''Extras''" - "''Web-Services''" - "''Start / Stop''" menu items).<br />
<br />
These services use HTTP requests as transport layer.<br />
<br />
==== Expecco SOAP Service Interface ====<br />
<br />
This accepts SOAP requests, via the URL "<code>/expeccoService</code>". I.e. the default URL is "<code>host:9090/expeccoService</code>".<br />
A partial WSDL spec can be acquired from the running service via "<code>host:9090/wsdl/ExpeccoSOAPService.wsdl</code>" (partial, because it is currently not does not contain complete type information).<br />
<br />
The service entries are:<br />
<br />
===== Loading and Executing a Suite =====<br />
<br />
The execute request is the main service entry. It passes the suite and also optional parameters.<br />
<br />
The test suite can be bade available to expecco either by passing it with the request (as base64 CDATA), or by passing a URL from which expecco can fetch the suite itself.<br />
<br />
The execute call contains the following fields:<br />
<br />
<message name="expecco_executeProject_v5_Request"><br />
<part name="id" type="UUID"/><br />
<part name="testSuiteId" type="UUID"/><br />
<part name="dataSource" type="xsd:string"/><br />
<part name="dataSourceUri" type="xsd:string"/><br />
<part name="environment" type="xsd:arrayType"/><br />
<part name="testplans" type="xsd:arrayType"/><br />
<part name="resources" type="xsd:arrayType"/><br />
<part name="optionalParameters" type="xsd:arrayType"/><br />
</message><br />
<br />
and responds with:<br />
<br />
<message name="expecco_executeProject_v5_Response"><br />
<part name="result" type="xsd:string"/><br />
</message><br />
<br />
This call starts execution, and immediately returns a response, which consists of an identifier.<br />
This identifier can later be used to ask expecco about the execution status. As a test may take a long time to finish,<br />
it is useful to poll via status requests from time to time, to see if the execution has finished and to get progress status.<br />
<br />
The parameters are:<br />
<br />
* id - mandatory; a ticket ID; this should be a UUID-string, to avoid possible conflicts<br />
* testSuiteId - mandatory; the UUID of the suite to execute. See below for details about download optimizations<br />
* dataSource - optional; if present, this should contain the whole ets-file's contents as a Base64 encoded CDATA string<br />
* dataSourceUri - optional; if present, this should be the URI from which expecco shall fetch the suite. See below for details<br />
* environment - optional; top-level environment variable values. This can be used to provide alternative initial values for variables in the top level variable environment (the "Project-Environment")<br />
* testplans - optional; a list of UUIDs of testplans to execute. If not present, all top-level testplans are executed<br />
* resources - optional; a list of resources to be used by the test (see expecco ALM resource description)<br />
* optionalParameters - optional; an array containing additional parameters as key-value elements.<br />
<br />
The "optionalParameters" field:<br />
<br />
A list of key-value elements (i.e. must have an even number of elements, of the form [k1 v1 k2 v2 ... kN vN] ).<br />
Each key is an xsd:string, each value's type depends on the key, but all of them are currently also strings.<br />
The list of supported parameters is open for future extension of the interface. Currently, the following are recognized:<br />
* [ "generateLog" xsd:boolean ] - the boolean arg must be "true" or "false"<br />
* [ "generatePDFReport" xsd:boolean ] - boolean arg, must be either "true" or "false"<br />
<br />
The "testplans" field:<br />
<br />
this allows selective execution of individual test plans and also individual test cases (from within a test plan) from the suite.<br />
If not present, all test plans as present in the suite are executed.<br />
If present, the testPlans parameter must be an xsdarray of pairs (i.e. each array element is again an xsdarray with 2 elements).<br />
Each top level element describes one testplan to be executed. The first element of each being the testplan's UUID, the second another array, listing the testcases by UUID.<br />
For example, if the suite contains three testplans, named "a", "b" and "c", with plan "a" having id-a and "b" having id-b as UUID.<br />
A testPlans argument might look like:<br />
<pre><br />
[<br />
[ id-a ]<br />
[ id-b [ id-tcb-1 id-tcb-2 ] ]<br />
]<br />
</pre><br />
and specify that testplan "a" should be executed fully (i.e. all test cases), and only the testcases tcb-1 and tcb-2 are to be executed from testplan "b".<br />
<br />
The "environment" field:<br />
<br />
-- to be described --<br />
<br />
The "resources" field:<br />
<br />
-- to be described --<br />
<br />
The reply consists of the ticket-id, which has to be passed in further status requests.<br />
<br />
===== Loading Only =====<br />
<br />
It is also possible, to download a suite without execution, via the "download" request:<br />
<br />
<message name="expecco_downloadProject_Request"><br />
<part name="testSuiteId" type="xsd:string"/><br />
<part name="dataSourceBase64" type="xsd:string"/><br />
<part name="dataSourceUri" type="xsd:string"/><br />
<part name="optionalParameters" type="xsd:arrayType"/><br />
</message><br />
<br />
<message name="expecco_downloadProject_Response"><br />
<part name="result" type="xsd:string"/><br />
</message><br />
<br />
===== Download Optimization =====<br />
<br />
Expecco remembers downloaded suites in a temporary folder, to avoid repeated transfers of possibly huge test suites.<br />
If a URI is passed (but no base64 encoded data), expecco checks if the suite is already present on the test host,<br />
and will not fetch it again, if already present. If not present, expecco will fetch the suite via a HTTP request from the URI.<br />
<br />
If no URI is passed (i.e. both data and dataURI fields are empty), expecco will either respond with an error reply, if not present,<br />
or with an OK response, if already present.<br />
<br />
Thus, if you have to pass the suite as data (i.e. there is no file service available, from which expecco could fetch the suite),<br />
it is recommended to first check if a suite is already present (by sending a download request without data) and check for an error return. If no error is reported, the suite is already there and no further download action is required. If there is an error response,<br />
the client should send the suite with another download request, this time with a non-empty data field.<br />
<br />
After any successful download (either via download, or via execute request), the suite can be executed by an execute request without data.<br />
<br />
===== Execution by Suite File Name =====<br />
<br />
An alternative to downloading suites is to execute suites which are already present on the execution slave. For this, expecco should be started with a "--suiteDirectory" option, which specifies the folder name, where common test suites are located.<br />
The executeTestSuiteFile-request is used to execute one of the suites in that directory.<br />
<br />
The call contains the following fields:<br />
<br />
<message name="expecco_executeTestSuiteFile_Request"><br />
<part name="id" type="UUID"/><br />
<part name="fileName" type="xsd:string"/><br />
<part name="environment" type="xsd:arrayType"/><br />
<part name="testplans" type="xsd:arrayType"/><br />
<part name="resources" type="xsd:arrayType"/><br />
<part name="optionalParameters" type="xsd:arrayType"/><br />
</message><br />
<br />
If successful, a ticketID is returned (same as above execute-request).<br />
<br />
===== Status Request =====<br />
<br />
This query returns status information about an ongoing execution. Its single parameter field must contain a ticketId as described in the above execute request.<br />
<br />
<message name="expecco_getExecutionInfo_Request"><br />
<part name="ticketId" type="UUID"/><br />
</message><br />
<br />
<message name="expecco_getExecutionInfo_Response"><br />
<part name="result" type="xsd:string"/><br />
</message><br />
<br />
A client may have to send multiple "getExecutionInfo" requests, until a "finished" status is returned.<br />
Expecco will keep the generated reports and log files in a temporary folder, until fetched via a getResult request.<br />
This allows for both expecco and the client to be turned off and restarted, without loosing any status information.<br />
<br />
===== Result Request =====<br />
<br />
Once finished, reports and log files should be fetched from expecco.<br />
<br />
<message name="expecco_getResult_Request"><br />
<part name="ticketId" type="UUID"/><br />
<part name="removeResultBoolean" type="xsd:string"/><br />
</message><br />
<br />
<message name="expecco_getResult_Response"><br />
<part name="result" type="xsd:string"/><br />
</message><br />
<br />
After the "getResult" request, corresponding files are automatically removed from the temporary folder by expecco.<br />
<br />
===== Terminate/Abort Request =====<br />
<br />
Use this, to abort and terminate an ongoing test execution.<br />
<br />
<message name="expecco_killExecution_Request"><br />
<part name="ticketId" type="xsd:string"/><br />
</message><br />
<br />
<message name="expecco_killExecution_Response"><br />
<part name="result" type="xsd:string"/><br />
</message><br />
<br />
===== Remove Ticket Request =====<br />
<br />
Use this, to tell expecco, that no further interest exists in a ticket.<br />
If the test is still running, it is aborted. If it is about to be started, it will not be.<br />
Any temporary files which might have already been created due to this execution are removed.<br />
<br />
<message name="expecco_killExecution_Request"><br />
<part name="ticketId" type="UUID"/><br />
</message><br />
<br />
<message name="expecco_killExecution_Response"><br />
<part name="result" type="xsd:string"/><br />
</message><br />
<br />
===== Ping =====<br />
<br />
This request answers with information about the host, architecture, disk usage and other status about the machine on which expecco is running. Also, a list of available plugins on the target machine is returned. Of course, it is also useful to see if the expecco service is ready and the communication works as expected.<br />
<br />
<message name="ping_Request"><br />
</message><br />
<br />
<message name="ping_Response"><br />
<part name="result" type="xsd:array"/><br />
</message><br />
<br />
===== Cleanup of Old Result/Log Files =====<br />
<br />
This request can be used to remove all temporary files, especially leftover report- and log files.<br />
This should be used, if a client has crashed, and lost track of<br />
<br />
<message name="expecco_cleanupTempFiles_Request"><br />
</message><br />
<br />
<message name="expecco_cleanupTempFiles_Response"><br />
<part name="result" type="xsd:string"/><br />
</message><br />
<br />
===== Example Wire Protocol Trace =====<br />
<br />
Client asks expecco to execute a suite.<br />
<br />
<-- HTTP Request to expecco --<br />
<pre><br />
<br />
POST / HTTP/1.1 <br />
Connection: Keep-Alive <br />
User-Agent: Smalltalk/X 6.2.5.0 <br />
Host: 127.0.0.1:9090 <br />
Content-Length: 8925 <br />
Content-Type: text/xml; charset="utf-8" <br />
SOAPAction: "" <br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<env:Envelope <br />
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" <br />
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" <br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<br />
<env:Body env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<m:expecco_executeProject_v5 xmlns:m="http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/rpc/"><br />
<optionalParameters xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" <br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
enc:arrayType="xsd:anyType[6]"><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">generateReport</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">true</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">generateLog</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">true</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">runAllTestcasesIfEmptyTestcaseList</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">true</item><br />
</optionalParameters><br />
<br />
<testSuiteId xsi:type="UUID">228168f0-747b-11df-a41b-00ff7b08316c</testSuiteId><br />
<testplans <br />
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" <br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
enc:arrayType="xsd:arrayType[1]"><br />
<item <br />
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" <br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" <br />
enc:arrayType="xsd:anyType[2]"><br />
<item <br />
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" <br />
xsi:type="xsd:string">f71c4700-7477-11df-a41b-00ff7b08316c<br />
</item><br />
<item <br />
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" <br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" <br />
enc:arrayType="xsd:anyType[0]"><br />
</item><br />
</item><br />
</testplans><br />
<id xsi:type="UUID">200d93e1-a258-11e4-b9eb-c48508c91d3c</id><br />
<dataSource xsi:null="1"/><br />
<dataSourceUri xsi:type="xsd:string">http://127.0.0.1:8662/expeccoALM/tentativeObjects/a84b2d96-d133-47db-9fc2-17208b490bfe.a<br />
</dataSourceUri><br />
<environment <br />
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" <br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
enc:arrayType="xsd:anyType[22]"><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_Host__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">sr-laptop</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_LoginUserName__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">admin</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_FullUserName__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">.&#32;&#42;admin&#42;</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_TestHost__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">127.0.0.1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_Definition_UUID__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">e5c9cb30-a253-11e4-9f24-c48508c91d3c</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_Definition_ID__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">d4</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_Definition_Name__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Test&#32;For&#32;Resources&#32;and&#32;Skills</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_Definition_Summary__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string"></item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_Run_UUID__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">200d93e1-a258-11e4-b9eb-c48508c91d3c</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_Run_ID__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">r14</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">__expeccoNET_TestSuite_VersionNumber__</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">1</item><br />
</environment><br />
<br />
<resources <br />
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" <br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
enc:arrayType="xsd:anyType[28]"><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Resource&#32;1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:integer">1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Resource&#32;1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Skill1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">attribute1-1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Integer</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">0</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Resource&#32;1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:integer">1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Resource&#32;1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Skill2</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">attribute2-1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Integer</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">0</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Resource&#32;1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:integer">1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Resource&#32;1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Skill2</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">attribute2-2</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Float</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">0.0</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Resource&#32;2&#32;eeee</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:integer">2</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Resource&#32;2</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Skill1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">attribute1-1</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">Integer</item><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:string">0</item><br />
</resources><br />
</m:expecco_executeProject_v5><br />
</env:Body><br />
</env:Envelope><br />
<br />
</pre><br />
<br />
>-- response from expecco<br />
<br />
<pre><br />
<br />
HTTP/1.1 200 OK <br />
Content-Type: text/xml <br />
Content-Length: 649 <br />
Connection: Keep-Alive <br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<env:Body env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<m:expecco_executeProject_v5Response xmlns:m="http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/rpc/"><br />
<result xsi:type="UUID">200d93e1-a258-11e4-b9eb-c48508c91d3c</result><br />
</m:expecco_executeProject_v5Response><br />
</env:Body><br />
</env:Envelope><br />
<br />
</pre><br />
<br />
Client asks expecco for execution state<br />
<br />
<-- HTTP Request to expecco<br />
<br />
<pre><br />
<br />
POST / HTTP/1.1 <br />
Connection: Keep-Alive <br />
User-Agent: Smalltalk/X 6.2.5.0 <br />
Host: 127.0.0.1:9090 <br />
Content-Length: 635 <br />
Content-Type: text/xml; charset="utf-8" <br />
SOAPAction: "" <br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<env:Body env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<m:expecco_getExecutionInfo xmlns:m="http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/rpc/"><br />
<ticketId xsi:type="UUID">200d93e1-a258-11e4-b9eb-c48508c91d3c</ticketId><br />
</m:expecco_getExecutionInfo><br />
</env:Body><br />
</env:Envelope><br />
<br />
</pre><br />
<br />
>-- response from expecco (while still executing)<br />
<br />
<pre><br />
<br />
HTTP/1.1 200 OK <br />
Content-Type: text/xml <br />
Content-Length: 2579 <br />
Connection: Keep-Alive <br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<env:Body env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<m:expecco_getExecutionInfoResponse xmlns:m="http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/rpc/"><br />
<result><br />
<executionResultState xsi:type="xsd:string">executingTestSuite</executionResultState><br />
<currentActivity xsi:type="xsd:string">executing&#32;Neuer&#32;Testplan</currentActivity><br />
<pdfReportFileURL xsi:null="1"/><br />
<summaryResult><br />
<summaryTestplanExecutionResults xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" enc:arrayType="xsd:anyType[1]"><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><br />
<summaryTestPlanItems xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" enc:arrayType="xsd:anyType[1]"><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><br />
<detailString xsi:null="1"/><br />
<resultActivityState xsi:type="xsd:string">Successful</resultActivityState><br />
<testplanItemName xsi:type="xsd:string">Neue&#32;Aktion</testplanItemName><br />
<expeccoClass xsi:type="xsd:string">Expecco::SummaryTestPlanItemExecutionResult</expeccoClass><br />
</item><br />
</summaryTestPlanItems><br />
<testPlanId xsi:type="xsd:string">22623ef0-757d-11df-a41b-00ff7b08316c</testPlanId><br />
<expeccoClass xsi:type="xsd:string">Expecco::SummaryTestPlanExecutionResult</expeccoClass><br />
<testPlanName xsi:null="1"/><br />
</item><br />
</summaryTestplanExecutionResults><br />
<testSuiteName xsi:type="xsd:string">Test&#32;For&#32;Resources&#32;and&#32;Skills</testSuiteName><br />
<testSuiteId xsi:type="xsd:string">228168f0-747b-11df-a41b-00ff7b08316c</testSuiteId><br />
<expeccoClass xsi:type="xsd:string">Expecco::SummaryTestSuiteExecutionResult</expeccoClass><br />
</summaryResult><br />
<logFileURL xsi:null="1"/><br />
<expeccoClass xsi:type="xsd:string">Expecco::SoapExecutionResult::SummaryEncoding</expeccoClass><br />
<executionProgress xsi:type="xsd:integer">0</executionProgress><br />
</result><br />
</m:expecco_getExecutionInfoResponse><br />
</env:Body><br />
</env:Envelope><br />
<br />
</pre><br />
<br />
>-- response from expecco (after execution)<br />
<br />
<pre><br />
HTTP/1.1 200 OK <br />
Content-Type: text/xml <br />
Content-Length: 2781 <br />
Connection: Keep-Alive <br />
<br />
.....................<br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<env:Body env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<m:expecco_getExecutionInfoResponse xmlns:m="http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/rpc/"><br />
<result><br />
<executionResultState xsi:type="xsd:string">finished</executionResultState><br />
<currentActivity xsi:type="xsd:string">executing&#32;Neuer&#32;Testplan</currentActivity><br />
<pdfReportFileURL xsi:type="xsd:string">http://127.0.0.1:9090/expeccoResultFiles/ad8011e1-a25c-11e4-b9eb-c48508c91d3c.pdf</pdfReportFileURL><br />
<summaryResult><br />
<summaryTestplanExecutionResults xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" enc:arrayType="xsd:anyType[1]"><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><br />
<summaryTestPlanItems xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" enc:arrayType="xsd:anyType[1]"><br />
<item env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><br />
<detailString xsi:null="1"/><br />
<resultActivityState xsi:type="xsd:string">Successful</resultActivityState><br />
<testplanItemName xsi:type="xsd:string">Neue&#32;Aktion</testplanItemName><br />
<expeccoClass xsi:type="xsd:string">Expecco::SummaryTestPlanItemExecutionResult</expeccoClass><br />
</item><br />
</summaryTestPlanItems><br />
<testPlanId xsi:type="xsd:string">22623ef0-757d-11df-a41b-00ff7b08316c</testPlanId><br />
<expeccoClass xsi:type="xsd:string">Expecco::SummaryTestPlanExecutionResult</expeccoClass><br />
<testPlanName xsi:null="1"/><br />
</item><br />
</summaryTestplanExecutionResults><br />
<testSuiteName xsi:type="xsd:string">Test&#32;For&#32;Resources&#32;and&#32;Skills</testSuiteName><br />
<testSuiteId xsi:type="xsd:string">228168f0-747b-11df-a41b-00ff7b08316c</testSuiteId><br />
<expeccoClass xsi:type="xsd:string">Expecco::SummaryTestSuiteExecutionResult</expeccoClass><br />
</summaryResult><br />
<logFileURL xsi:type="xsd:string">http://127.0.0.1:9090/expeccoResultFiles/ad8011e1-a25c-11e4-b9eb-c48508c91d3c.elf</logFileURL><br />
<expeccoClass xsi:type="xsd:string">Expecco::SoapExecutionResult::SummaryEncoding</expeccoClass><br />
<executionProgress xsi:type="xsd:integer">100</executionProgress><br />
</result><br />
</m:expecco_getExecutionInfoResponse><br />
</env:Body><br />
</env:Envelope><br />
<br />
</pre><br />
<br />
Client fetches the report and log files from expecco:<br />
<br />
<-- HTTP Request to expecco (fetch logfile)<br />
<br />
<pre><br />
GET /expeccoResultFiles/ad8011e1-a25c-11e4-b9eb-c48508c91d3c.elf HTTP/1.1 <br />
Connection: Keep-Alive <br />
User-Agent: Mozilla/3.0N <br />
Host: 127.0.0.1:9090 <br />
Accept-Encoding: chunked <br />
Accept-Language: en,* <br />
Accept-Charset: iso-8859-1,*,utf-8 <br />
Accept: */* <br />
</PRE><br />
<br />
>-- HTTP response from expecco <br />
<br />
<PRE><br />
HTTP/1.1 200 OK <br />
Content-Type: application/x-expecco-logfile <br />
Content-Length: 12690 <br />
Connection: Keep-Alive <br />
Cache-Control: max-age=86400 <br />
Last-modified: Thu, 22 Jan 2015 17:32:50 GMT <br />
<br />
... a lot of elf-file data ...<br />
</pre><br />
<br />
<-- HTTP Request to expecco (fetch pdf report)<br />
<br />
<pre><br />
GET /expeccoResultFiles/ad8011e1-a25c-11e4-b9eb-c48508c91d3c.pdf HTTP/1.1 <br />
Connection: Keep-Alive <br />
User-Agent: Mozilla/3.0N <br />
Host: 127.0.0.1:9090 <br />
Accept-Encoding: chunked <br />
Accept-Language: en,* <br />
Accept-Charset: iso-8859-1,*,utf-8 <br />
Accept: */* <br />
</pre><br />
<br />
>-- HTTP response from expecco<br />
<br />
<pre><br />
HTTP/1.1 200 OK <br />
Content-Type: application/pdf <br />
Content-Length: 29768 <br />
Connection: Keep-Alive <br />
Cache-Control: max-age=86400 <br />
Last-modified: Thu, 22 Jan 2015 17:32:51 GMT <br />
<br />
... a lot of pdf data ...<br />
</pre><br />
<br />
Client releases ticket (so expecco can remove the temporary data)<br />
<br />
<-- HTTP Request to expecco<br />
<br />
<pre><br />
POST / HTTP/1.1 <br />
Connection: Keep-Alive <br />
User-Agent: Smalltalk/X 6.2.5.0 <br />
Host: 127.0.0.1:9090 <br />
Content-Length: 627 <br />
Content-Type: text/xml; charset="utf-8" <br />
SOAPAction: "" <br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<env:Body env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<m:expecco_removeTicket xmlns:m="http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/rpc/"><br />
<ticketId xsi:type="UUID">ad8011e1-a25c-11e4-b9eb-c48508c91d3c</ticketId><br />
</m:expecco_removeTicket><br />
</env:Body><br />
</env:Envelope><br />
<br />
</pre><br />
<br />
>-- HTTP response from expecco<br />
<br />
<pre><br />
HTTP/1.1 200 OK <br />
Content-Type: text/xml <br />
Content-Length: 614 <br />
Connection: Keep-Alive <br />
<br />
.....................<br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<env:Body env:encodingStyle="http://www.expecco.net/soap/expecco/v1/"><br />
<m:expecco_removeTicketResponse xmlns:m="http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/rpc/"><br />
<result xsi:type="xsd:boolean">true</result><br />
</m:expecco_removeTicketResponse><br />
</env:Body><br />
</env:Envelope><br />
<br />
</pre><br />
===== Example Session Using "<code>wget</code>" =====<br />
<br />
Using "wget" with SOAP is possible, but a little complicated, because correct SOAP requests have to be constructed, and ticket-numbers be extracted from responses. It is much easier with the REST service.<br />
<br />
See below for a description.<br />
<br />
==== Expecco REST Service Interface ====<br />
<br />
This accepts REST requests, via the URL "<code>/expeccoService/rest</code>". I.e. the default URL is "<code>host:9090/expeccoService/rest</code>".<br />
<br />
The REST service supports the same set of operations as the SOAP service described above, but uses a much more lightweight approach in its parameter encoding. It is both easier to implement on the client side, and also faster than SOAP, due to the minimal encoding/decoding overhead.<br />
Expecco REST calls are all HTTP-GET requests, possibly with attached JSON encoded argument data.<br />
The operation is determined by the URI: the last component is the operation name to be executed.<br />
<br />
See details [[ Starting_expecco_via_Command_Line/rest | "expecco rest service interface"]].<br />
<br />
<br />
=== Expecco Remote Control REST Service Interface ===<br />
<br />
A secondary REST service is available to interact with a running test.<br />
This service is used by the "expecco remote control App", which is available for Android devices (tablets and cell phones).<br />
<br />
This accepts REST requests, via the URL "/remote". I.e. the default URL is "host:9090/remote".<br />
A description of the supported REST calls can be acquired from the running service via "host:9090/remote/protocolInfo".<br />
<br />
When this service is active, the standard Dialog requests (input boxes, with "OK"/"Cancel" buttons) will also be presented on the remote controlling app, and can be answered either on the PC-screen OR on a remote android device.<br />
An obvious application of this is when the test system (hardware) needs manual interaction and you have to leave the workplace for this. Here, it is very convenient to be able to answer questions like "Insert Cable X and press OK to proceed" from a mobile device. Avoiding the need to walk back to the workplace to click on the "OK" button.<br />
<br />
=== Expecco Short Status Information Service ===<br />
<br />
This is a very simple HTTP service, which delivers a single page with a status overview.<br />
This service is started when the "<code>--infoService</code>" or "<code>--server</code>" command line arguments are present.<br />
<br />
This accepts HTTP requests, via the URL "/info".<br />
I.e. the default URL is "<code>host:9090/info</code>".<br />
<br />
The main use of this service is to quickly check the status of a testslave from a remote web browser,<br />
without a need for a more complicated SOAP or REST service client.<br />
<br />
<br />
Back to [[Online_Documentation#Topic:_Execution | Online Documentation]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=PolarionPlugin_Reference/en&diff=10549PolarionPlugin Reference/en2018-02-12T19:23:42Z<p>Mawalch: Weiterleitung nach PolarionPlugin Reference erstellt</p>
<hr />
<div>#REDIRECT[[PolarionPlugin Reference]]<br />
<br />
[[Category:Incomplete]]<br />
[[Category:Empty]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Testsuite_Editor/en&diff=10548Testsuite Editor/en2018-02-12T19:20:55Z<p>Mawalch: </p>
<hr />
<div>This editor is used to manipulate test suite elements.<br />
It consists of the following sub-editors, which are selected via tabs<br />
* [[Testsuite Editor-Environment Editor/en|Environment Editor]]<br />
* [[Testsuite Editor-ExecutionSettings Editor/en|ExecutionSettings Editor]]<br />
* [[Testsuite Editor-ReportParameter Editor/en|ReportParameter Editor]]<br />
* [[Testsuite Editor-Metadata Editor/en|Metadata Editor]]<br />
* [[Testsuite Editor-StatisticData Editor/en|StatisticData Editor]]<br />
* [[History Editor/en|History Editor]]<br />
* [[Documentation Editor/en|Documentation Editor]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Settings_PluginSettings/en&diff=10547Settings PluginSettings/en2018-02-12T18:59:57Z<p>Mawalch: </p>
<hr />
<div>== Plugin Settings ==<br />
Expecco supports extensions called plugins.<br />
These can be loaded and unloaded dynamically using this plugin settings dialog.<br />
Plugins are provided by eXept or third party sources.<br />
For more information, please refer to the<br />
[[:Category:Plugins|"Plugins Documentation"]] or the documentation as provided with the plugin.<br />
<br />
=== Available Plugins and Extensions ===<br />
At the time of writing of this document, the following plugins and extensions<br />
are available or being developed by eXept:<br />
<br />
* [[Settings BPELImportPluginSettings/en|Settings BPELImportPluginSettings]]<br />
* [[Settings DLLCallGeneratorPluginSettings/en|Settings DLLCallGeneratorPluginSettings]]<br />
* [[Settings DotNETBridgeSettings/en|Settings DotNETBridgePluginSettings]]<br />
* [[Settings FreemindImportPluginSettings/en|Settings FreemindImportPluginSettings]]<br />
* [[Settings GUITestPlatformSettings/en|Settings GUITestPlatformSettings]]<br />
* [[Settings GembirdPluginSettings/en|Settings GembirdPluginSettings]]<br />
* [[Settings JavaBridgePluginSettings/en|Settings JavaBridgePluginSettings]]<br />
* [[Settings JavaJARImportPluginSettings/en|Settings JavaJARImportPluginSettings]]<br />
* [[Settings JavaSwingSettings/en|Settings JavaSwingSettings]]<br />
* [[Settings JiraInterfacePluginSettings/en|Settings JiraInterfacePluginSettings]]<br />
* [[Settings ManualTestImport1PluginSettings/en|Settings ManualTestImport1PluginSettings]]<br />
* [[Settings ManualTestImport2PluginSettings/en|Settings ManualTestImport2PluginSettings]]<br />
* [[Settings MobileTestingSettings/en|Settings MobileTestingPluginSettings]]<br />
* [[Settings PolarionInterfacePluginSettings/en|Settings PolarionInterfacePluginSettings]]<br />
* [[Settings PoloniumGUITestPluginSettings/en|Settings PoloniumGUITestPluginSettings]]<br />
* [[Settings QCInterfacePluginSettings/en|Settings QCInterfacePluginSettings]]<br />
* [[Settings QtGUITestPluginSettings/en|Settings QtGUITestPluginSettings]]<br />
* [[Settings SeleniumSettings/en|Settings SeleniumSettings]]<br />
* [[Settings WindowsAutomationSettings/en|Settings WindowsAutomationSettings]]<br />
* [[Settings WSDLImportPluginSettings/en|Settings WSDLImportPluginSettings]]<br />
* [[Settings XMIImportPluginSettings/en|Settings XMIImportPluginSettings]]<br />
* [[Settings XPDLImportPluginSettings/en|Settings XPDLImportPluginSettings]]<br />
<br />
=== Plugin Overview ===<br />
;[[Settings BPELImportPluginSettings/en|BPEL Import Extension]]<br />
: Imports BPEL diagrams<br />
<br />
;[[Settings DLLCallGeneratorPluginSettings/en|DLL Callgenerator Extension]]<br />
: Generates function blocks for entries in a dynamic link library.<br />
<br />
;[[Settings DotNETBridgeSettings/en|DotNET Bridge Extension]]<br />
:The dotNET bridge extension allows for a dotNET (CLR) program to be executed as a slave under the control of expecco. You can access globals, classes, instantiated objects, threads and GUI components of the program, and define arbitrary elementary blocks to manipulate them. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings FreemindImportPluginSettings/en|Freemind-MM Import Extension]]<br />
: Imports FreeMind Mindmap diagrams<br />
<br />
;[[Settings GembirdPluginSettings/en|Gembird Power Manager Control Plugin]]<br />
: This plugin controls a set of lamps (red, green, yellow) via a LAN-controlled power control unit (gembird). This can be used as an optical indicator for running tests (yellow), and the tests outcome (red or green).<br />
<br />
;[[Settings JavaBridgePluginSettings/en|Java Bridge Extension]]<br />
: Similar in function to the dotNET bridge, this extension allows for a Java program to be executed as a slave under the control of expecco. You can access globals, classes, instantiated objects, threads and GUI components of the program, and define arbitrary elementary blocks to manipulate them. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings JavaJARImportPluginSettings/en|Java JAR Import Extension]]<br />
: Similar in function to the DLL call generator plugin, this extension allows for a JAR file containing Java classes to be scanned and elementary blocks to be generated which call static or member functions.<br />
<br />
;[[Settings JavaSwingSettings/en|JavaSwing GUI Test Extension]]<br />
: Provides a visualization of the widget hierarchy of a Java+Swing application. GUI elements can be searched, inspected and validation actions can be added interactively to a test suite's activity diagram. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings JavaSWTGUITestPluginSettings/en|JavaSWT GUI Test Extension]]<br />
: Provides a visualization of the widget hierarchy of a Java+SWT application. GUI elements can be searched, inspected and validation actions can be added interactively to a test suite's activity diagram. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings JiraInterfacePluginSettings/en|JIRA Testresult Reporting]]<br />
: This plugin creates a link between an expecco test case and an issue in a JIRA database. The issue can be automatically closed/reopened, whenever the test case is executed.<br />
<br />
;[[Settings ManualTestImport1PluginSettings/en|Manual Test Import]]<br />
: This plugin imports test specifications for manual tests. These must be present as word (OpenOffice) document with a particular (tabular) format. After the import, a manual test GUI can be used to guide the tester through the test cases, or the resulting test plan can be used as a template for partial or full automation.<br />
<br />
;[[Settings MobileTestingSettings/en|Mobile Testing]]<br />
: Similar to the other GUI Test extensions, this allows for an Android or iOS application's widget hierarchy to be inspected, manipulated and checked. The application may run both on real or emulated hardware. Multiple devices and their interaction may be handled and controlled in a single test suite.<br />
<br />
;[[Settings PolarionInterfacePluginSettings/en|Polarion Interface]]<br />
: This plugin allows for test-suites to be up-/downloaded to/from a Polarion QM server, to fetch and execute Polarion test runs, and to update a tests state to PASS/FAIL, whenever the test case is executed. Also, Polarion itself is extended for the definition and execution of expecco tests.<br />
<br />
;[[Settings PoloniumGUITestPluginSettings/en|Polonium ST/X Application''' Test Plugin]]<br />
: The Polonium plugin adds an interface to the Polonium ST/X GUI test framework. Polonium does for an ST/X fat-client application what Selenium does for a browser based web application. It allows for capture/replay of ST/X GUI application sessions and the validation of a GUI's window contents.<br />
<br />
;[[Settings QtGUITestPluginSettings/en|Qt GUI Test Extension]]<br />
: Similar to the JavaSwing GUI Test extension, this allows for a Qt (-> Trolltech) application's widget hierarchy to be inspected, manipulated and checked. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings QCInterfacePluginSettings/en|Quality Center (QC) Interface]]<br />
: This plugin allows for test-suites to be up-/downloaded to/from a Quality-Center server, to fetch and execute QC test sets, and to update a tests state to PASS/FAIL, whenever the test case is executed.<br />
<br />
;[[Settings SeleniumSettings/en|Webtest Plugin (Selenium Interface)]]<br />
: The Webtest plugin adds an interface to the Selenium Webtest framework. Selenium allows for capture/replay of web sessions and the validation of a web pages' contents. This plugin contains an import feature, which converts captured selenium sessions into an activity diagram. Also, a library consisting of web-page activities is included. Together, they allow for a recorded web session to be enhanced, refactored, reused or parametrized like any ordinary expecco activity diagram.<br />
<br />
:Beside many other possible uses, two extra functionalities of this plugin add much to the value of the expecco product:<br />
:* recorded web sessions can be augmented by semantic checks in the system under test. Especially the real effect of a web-transaction can be checked against the back-end of a web application.<br />
:* by feeding a recorded session's parameters through either a generator-block, or by reading a CSV-file or a database, web-sessions can be parametrized. This can even be done dynamically on the fly, depending upon previous response data. For example, a set of boundary values can be read from a file and fed as input parameter sets to a prerecorded web session, or the output of a web page can be analyzed, transformed and used as input to another session or for a follow up test case.<br />
<br />
;[[Settings WindowsAutomationSettings/en|Windows Automation Extension]]<br />
: Similar to the other GUI Test extensions, this allows for Microsoft MFC/Forms application's widget hierarchies to be inspected, manipulated and checked. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings WSDLImportPluginSettings/en|WSDL Import Extension]]<br />
: Imports WSDL service description and automatically generates libraries containing types and actions to access these operations.<br />
<br />
;[[Settings XMIImportPluginSettings/en|XMI Import / Export Extension]]<br />
: Import/Export of XMI UML diagrams<br />
<br />
;[[Settings XPDLImportPluginSettings/en|XPDL Import Extension]]<br />
: Imports XPDL diagrams<br />
<br />
[[Category:Settings]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Settings_JavaJarImportPluginSettings&diff=10546Settings JavaJarImportPluginSettings2018-02-12T18:59:10Z<p>Mawalch: Weiterleitung nach Settings JavaJARImportPluginSettings/en erstellt</p>
<hr />
<div>#WEITERLEITUNG [[Settings JavaJARImportPluginSettings/en]]<br />
<br />
[[Category:Temporary Short Redirect]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Settings_JavaJARImportPluginSettings&diff=10545Settings JavaJARImportPluginSettings2018-02-12T18:57:47Z<p>Mawalch: Weiterleitung nach Settings JavaJARImportPluginSettings/en erstellt</p>
<hr />
<div>#REDIRECT[[Settings JavaJARImportPluginSettings/en]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Settings_JavaJARImportPluginSettings&diff=10543Settings JavaJARImportPluginSettings2018-02-12T18:57:23Z<p>Mawalch: Mawalch verschob die Seite Settings JavaJarImportPluginSettings nach Settings JavaJARImportPluginSettings: JAR, not Jar</p>
<hr />
<div>#redirect [[ Settings JavaJarImportPluginSettings/en ]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Settings_JavaJarImportPluginSettings&diff=10544Settings JavaJarImportPluginSettings2018-02-12T18:57:23Z<p>Mawalch: Mawalch verschob die Seite Settings JavaJarImportPluginSettings nach Settings JavaJARImportPluginSettings: JAR, not Jar</p>
<hr />
<div>#WEITERLEITUNG [[Settings JavaJARImportPluginSettings]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=VirtualBlock_Element/en&diff=10542VirtualBlock Element/en2018-02-12T18:55:43Z<p>Mawalch: title normalization</p>
<hr />
<div>==What is a Virtual Block==<br />
<br />
A virtual block is used to specify the interface (number of pins and their [[Datatype|datatypes]]), but '''not''' its implementation as an action block.<br />
It can be placed into a network like any other block.<br />
<br />
During the execution, [[DiagramElements-Step|steps]] for virtual actions will determine the real action to be performed dynamically, at execution time.<br />
This is done via one of two mechanisms:<br />
<br />
==== Explicit, Direct Performer: ====<br />
<br />
If the [[DiagramElements-Pin#Performer Input Pin|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's ID specified as its interface.<br />
The reference can be provided by another step (dynamically computed), via the environment using an [[DiagramElements-Environment Freeze Value|environment-freeze value]] or directly as a freeze value. Of course, any environment variables must have been initialized elsewhere before.<br />
<br />
The reference's value can be defined either as the action's ID, or its name. For convenience, actions can be directly dragged from the tree and dropped onto a performer input pin. Obviously, using a constant freeze value as performer-pin input makes the whole virtual mechanism useless, as you could then just place the concrete action. So this is usually only done for testing and demonstration purpose.<br />
In real-world scenarios, the reference is almost always provided by an environment variable, as described below.<br />
<br />
==== Implicit Performer via a mapping in the Environment: ====<br />
<br />
If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[Virtual Library|virtual library]].<br />
<br />
===== Individual Action Mapping: =====<br />
<br />
For this, the environment should contain a mapping from virtual-action-id to concrete action-id. I.e. it must contain a slot where a reference to the virtual action is key, and a reference to the concrete action is the value.<br />
Such mappings cannot be created via the environment editor (as it only creates slots with a string-type namekey), instead, a special block is provided, which creates such a mapping in its surrounding environment.<br />
<br />
===== Virtual Library Mapping: =====<br />
<br />
The most convenient way to specify virtual actions is by providing a virtual- to concrete library mapping. For that, a special block is provided, which expects a reference to a virtual library and a reference to a concrete library as inputs. After that mapping has been created, any reference to any virtual block of that library will be resolved using a corresponding concrete block from the concrete library.<br />
<br />
See the virtualAction sample project for how to define and use virtual libraries.<br />
<br />
==When to use Virtual Blocks==<br />
<br />
Use a virtual block, if:<br />
<br />
* you have to model a function which is realized using different concrete mechanisms. For example: if multiple communication paths exist to some device, and the one to be used has to be determined dynamically during the test (e.g. connected via USB vs. connected via Serial Line vs. Internet connection).<br />
<br />
* you have to create a test which has to deal with multiple devices, which use different setups, parameters or protocols. For example: if you have multiple measurement devices in your lab, which require different interface handling, and the test has to determine dynamically, which device is to be used during test execution. This situation is especially common, when expecco is used together with a test automation system, such as expecco ALM, where expecco ALM chooses dynamically which devices are to be used in a test run and passes that information as parameter set.<br />
<br />
* alternatives are to be configurable by the tester at test-execution time. For example, to select between debug- and non-debug versions of a block, or to select between different test-levels (smoke-test / full-test etc.) and different test-actions are to be performed depending on that choice.<br />
<br />
==How to use Virtual Blocks==<br />
<br />
# define the virtual block and its pins<br />
# define a concrete block with the same number of pins having the same data types.<br />
# copy the virtual blocks ID (either from its documentation-editor tab) or via the copy-ID popup menu function in the element-tree. The paste this ID into the concrete blocks "Interface" field (in the scheme-editor-tab). Alternatively, drag & drop a virtual action into this field. This tells expecco, that the concrete action implements that virtual interface.<br />
# place the virtual action as a step into some network. Notice the additional performer pin<br />
# create an environment variable to hold the concrete ID<br />
# freeze the performer-pin input from the above environment variable<br />
# connect the concrete action to the virtual action:<br />
#* for a demo run: drag&drop the concrete action into the environment variable (or copy-paste its functional-ID)<br />
#* for a real test: create a setup compound action, which sets the environment variable's value to the appropriate ID of a concrete action<br />
# execute the action, where the virtual block has been placed. Notice how you can control the execution.<br />
<br />
[[Category:Tree Elements]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Standard_Library&diff=10541Standard Library2018-02-12T18:47:54Z<p>Mawalch: </p>
<hr />
<div>== Introduction ==<br />
The StandardLibrary contains general domain-independent function blocks. These are useful for any kind of test-development. <br />
<br />
One of the features which make the StandardLibrary very flexible is the dynamic type system of the underlying implementation language. This allows for the blocks to handle a wide range of possible input values. For example, arithmetic blocks ("Arith [ * ]") all allow for Integers, Floats, LargeIntegers, Fractions, FixedPoint-Decimals and Measurement Values to be used as input (where appropriate). And most of the collection blocks ("Collection [ * ]") can deal with Strings, ByteArrays, Buffer-Data, Arrays, OrderedCollections, Tuples, SortedCollections, Sets, HashTables (Dictionaries) and other collection types. Without such a dynamic type system, many more blocks would be needed for a comparable set of functions (see IEC1131, for example, which uses a similar execution model, but a static type system).<br />
<br />
The automatic type conversion between Integer and LargeInteger (whenever a value cannot be represented within 32bit) and vice versa, and the automatic conversion of a quotient to a Fraction and the reduction back to an Integer avoid rounding errors and loss of precision.<br />
&nbsp;<br />
&nbsp;<br />
<br />
{{noprint| 1= <br />
Back to [[Online Documentation#Library_and_Plugin_Overview|Online Documentation]]<br />
}}<br />
<br />
== Numbers ==<br />
<br />
=== Arithmetic ===<br />
<br />
* [[ Arith Sum | '''Arith [ Sum ]''' ]]<br/> Sum of its numeric input values.<br />
* [[ Arith Sumn | '''Arith [ SumN ]''' ]]<br/> Sum of its numeric input values (more input-pins available).<br />
* [[ Arith Sum+ | '''Arith [ Sum+ ]''' ]]<br/> Sum of its numeric input values (arbitrary number of input pins) (2.3.0)<br />
* [[ Arith Distance | '''Arith [ Distance ]''' ]]<br/> Absolute value of difference of its numeric input values.<br />
* [[ Arith Difference | '''Arith [ Difference ]''' ]]<br/> Difference of its numeric input values.<br />
* [[ Arith Difference+ | '''Arith [ Difference+ ]''' ]]<br/> Difference of its numeric input values (arbitrary number of input pins) (2.3.0).<br />
* [[ Arith Product | '''Arith [ Product ]''' ]]<br/> Product of its numeric input values.<br />
* [[ Arith Product+ | '''Arith [ Product+ ]''' ]]<br/> Product of its numeric input values (arbitrary number of input pins) (2.3.0).<br />
* [[ Arith Quotient | '''Arith [ Quotient ]''' ]]<br/> Quotient of its numeric input values.<br />
* [[ Arith Modulu | '''Arith [ Modulu ]''' ]]<br/> Remainder from dividing its numeric input values.<br />
* [[ Arith Square Root | '''Arith [ Square Root ]''' ]]<br/> The square root.<br />
* [[ Arith RaisedTo | '''Arith [ RaisedTo ]''' ]]<br/> Raising x to the n'th power. n max be a fraction (for roots).<br />
* [[ Arith Ln | '''Arith [ Ln ]''' ]]<br/> The natural logarithm (base e).<br />
* [[ Arith Lg | '''Arith [ Lg ]''' ]]<br/> The logarithm base 10.<br />
* [[ Arith Ld | '''Arith [ Ld ]''' ]]<br/> The logarithm base 2. This could also be computed as: ln(input) / ln(2) (1.7.2).<br />
* [[ Arith_Min and Arith_Max | '''Arith [ Min ]''' ]]<br/> Minimum of its numeric input values.<br />
* [[ Arith_Min and Arith_Max | '''Arith [ Max ]''' ]]<br/> Maximum of its numeric input values.<br />
* [[ Arith MinMax | '''Arith [ MinMax ]''' ]]<br/> Both Minimum and Maximum of its numeric input values (1.7.1).<br />
* [[ Arith negated | '''Arith [ Negated ]''' ]]<br/> Negates its numeric input value.<br />
* [[ Arith abs | '''Arith [ Abs ]''' ]]<br/> Returns the absolute value of its numeric input value.<br />
* [[ Arith isEven | '''Arith [ IsEven? ]''' ]]<br/> True if the input is even (divisible by two) (1.7.1).<br />
* [[ Arith isEvenOrOdd | '''Arith [ IsEvenOrOdd? ]''' ]]<br/> Provides the input number at one of its two outputs, depending on the input's divisibility by two.<br />
* [[ Arith isPositive | '''Arith [ IsPositive? ]''' ]]<br/> True if the input is >= 0<br />
* [[ Arith isNegative | '''Arith [ IsNegative? ]''' ]]<br/> True if the input is < 0<br />
* [[ Arith isPositiveOrNegative | '''Arith [ IsPositiveOrNegative? ]''']]<br/> Pass the input number to one of two outputs depending on whether it is >=0 or <0.<br />
* [[ Arith sign | '''Arith [ Sign? ]''' ]]<br/> Pass the input number to one of three outputs depending on whether it is >0, =0 or <0. (1.7.2).<br />
* [[ Arith signum | '''Arith [ Signum ]''' ]]<br/> The signum (-1, 0 or 1) of the incoming number. (1.7.2).<br />
* [[ Arith ceilFloorRound | '''Arith [ Ceiling ]''' ]]<br/> The ceiling (integer above) of the incoming number.<br />
* [[ Arith ceilFloorRound | '''Arith [ Floor ]''' ]]<br/> The floor (integer below) of the incoming number.<br />
* [[ Arith ceilFloorRound | '''Arith [ Round ]''' ]]<br/> The incoming number rounded to the nearest integer. (1.7.1).<br />
* [[ Arith ceilFloorRound | '''Arith [ RoundTo ]''' ]]<br/> The incoming number rounded to the nearest multiple of the rounding value. (1.7.1).<br />
<br />
=== Bit Manipulation ===<br />
* [[ Arith highBit | '''Arith [ HighBit ]''' ]]<br/> The bitNumber of the highest bit (1.7.2).<br />
* [[ Arith highBit | '''Arith [ LowBit ]''' ]]<br/> The bitNumber of the lowest bit (1.7.2). <br />
* [[ Arith leftShift | '''Arith [ LeftShift ]''' ]]<br/> BitShift to the left (1.7.2).<br />
* [[ Arith rightShift | '''Arith [ RightShift ]''' ]]<br/> BitShift to the right (1.7.2).<br />
* [[ Arith bitAnd | '''Arith [ BitAnd ]''' ]]<br/> The bitwise AND of the two integral input values.(1.7.2).<br />
* [[ Arith bitOr | '''Arith [ BitOr ]''' ]]<br/> The bitwise OR of the two integral input values. (1.7.2).<br />
* [[ Arith bitXor | '''Arith [ BitXor ]''' ]]<br/> The bitwise XOR of the two integral input values. (1.7.2).<br />
<br />
=== Trigonometric ===<br />
* [[ Arith Trigonometric | '''Arith [ Sin ]''' ]]<br/> The sine of x.<br />
* [[ Arith Trigonometric | '''Arith [ Cos ]''' ]]<br/> The cosine of x.<br />
* [[ Arith Trigonometric | '''Arith [ Tan ]''' ]]<br/> The tanges of x.<br />
* [[ Arith Trigonometric | '''Arith [ ArcSin ]''' ]]<br/> The arcsine of x. (1.7.1).<br />
* [[ Arith Trigonometric | '''Arith [ ArcCos ]''' ]]<br/> The arccosine of x. (1.7.1).<br />
* [[ Arith Trigonometric | '''Arith [ ArcTan ]''' ]]<br/> The arctangens of x.(1.7.1).<br />
* [[ Arith_Pi%2C_Arith_E | '''Arith [ E ]''' ]]<br/> The euler constant E. (2.71828...).<br />
* [[ Arith_Pi%2C_Arith_E | '''Arith [ Pi ]''' ]]<br/> The constant Pi. (3.14159...).<br />
<br />
=== Misc Math ===<br />
* [[ Arith isPrime | '''Arith [ IsPrime? ]''' ]]<br/> Provides the input number at one of its two outputs, depending on the primeness of the input. (1.7.2).<br />
* [[ Arith isPrimeOrNot | '''Arith [ IsPrimeOrNot? ]''' ]]<br/> Provides the input number at one of its two outputs, depending on the primeness of the input. (1.7.2).<br />
* [[ Arith Binomial Coefficient | '''Arith [ Binomial Coefficient ]''' ]]<br/> Return the number of choices to take k elements from a collection of n elements (Choose k from n).<br />
* [[ Arith Fibonacci | '''Arith [ Fibonacci ]''' ]]<br/> Return the n'th fibonacci number (n >= 1).<br />
<br />
* [[ Arith Factorial | '''Arith [ Factorial ]''' ]]<br/> Factorial of its integral input value.<br />
<br />
=== Modulu Arithmetic ===<br />
* [[ Arith Sum_32 | '''Arith [ 32bit Sum ]''' ]]<br/> Sum in 32 bit number range (1.7.3)<br />
* [[ Arith Diff_32 | '''Arith [ 32bit Difference ]''' ]]<br/> Difference in 32 bit number range (1.7.3)<br />
* [[ Arith Mul_32 | '''Arith [ 32bit Product ]''' ]]<br/> Product in 32 bit number range (1.7.3)<br />
<br />
=== Rounding & Truncation ===<br />
* [[ Arith Ceiling | '''Arith [ Ceiling ]''' ]]<br/> Ceiling (round to next larger integer towards positive infinity)<br />
* [[ Arith Floor | '''Arith [ Floor ]''' ]]<br/> Floor (round to next smaller integer towards negative infinity)<br />
* [[ Arith Truncate | '''Arith [ Truncate ]''' ]]<br/> Round to next integer towards zero<br />
* [[ Arith Round | '''Arith [ Round ]''' ]]<br/> Round to next integer<br />
* [[ Arith RoundTo | '''Arith [ RoundTo ]''' ]]<br/> Round to next multiple of a given grid value<br />
* [[ Arith Round to Scale | '''Arith [ Round to Scale ]''' ]]<br/> Round a FixedPoint number to its scale<br />
* [[ Arith Set Scale | '''Arith [ Set Scale ]''' ]]<br/> Change a FixedPoint number's scale<br />
* [[ Arith Truncate to Scale | '''Arith [ Truncate to Scale ]''' ]]<br/> Truncate a FixedPoint to its scale<br />
<br />
== Assertions, Exceptions & Logging ==<br />
<br />
* [[ FAIL | '''FAIL''' ]]<br/> Report a Failure. This means, that the system under test failed a test.<br />
* [[ FAIL2 | '''FAIL2''' ]]<br/> Report a Failure. This means, that the system under test failed a test. Optionally decorate the failure-message with pre-/postFix string.<br />
* [[ ERROR | '''ERROR''' ]]<br/> Report an Error. This means, that something unexpected (an error) occurred in the expecco test suite itself. The test suite must be fixed. <br />
* [[ ERROR2 | '''ERROR2''' ]]<br/> Report an Error. Optionally decorate the error-message with pre-/postFix string. <br />
* [[ INCONCLUSIVE | '''INCONCLUSIVE''' ]]<br/> Report an Inconclusive state. This means, that we cannot tell, what the test result is. <br />
* [[ INCONCLUSIVE2 | '''INCONCLUSIVE2''' ]]<br/> Report an Inconclusive state. Optionally decorate the message with pre-/postFix string.<br />
* [[ PASS | '''PASS''' ]]<br/> Report a Successful Test. This means, that the system under test passed the test. <br />
* [[ PASS2 | '''PASS2''' ]]<br/> Report a Successful Test. Optionally decorate the pass-message with pre-/postFix string.<br />
* [[ OK | '''OK''' ]]<br/> Finish the current Activity and mark it as successful. <br />
* [[ OK2 | '''OK2''' ]]<br/> Finish the current Activity and mark it as successful. Optionally decorate the success-message with pre-/postFix string.<br />
* [[ ABORT | '''ABORT''' ]]<br/> Finish the current Activity and mark it as aborted.<br />
* [[ HALT | '''HALT''' ]]<br/> Stop end enter the debugger, but only if halts are not ignored in the settings.(1.9.1).<br />
* [[ PAUSE | '''PAUSE''' ]]<br/> Same effect as pressing the "Pause"-button: pauses the executor. Press "Run" or "Single Step", to continue (1.9.1).<br />
<br />
=== Logging & Messages ===<br />
=== Adding Log Entries ===<br />
* [[ Log Failure | '''Log [ Failure ]''' ]]<br/> Report a Failure Message in the Log AND set the outcome to FAILED<br />
* [[ Log Failure | '''Log [ Failure & Details ]''']]<br/> Report a Failure Message with Details.<br />
* [[ Log Warning | '''Log [ Warning ]''' ]]<br/> Report an Warning Message. Optionally decorate the failure-message with pre-/postFix string.<br />
* [[ Log Warning | '''Log [ Warning & Details ]''']]<br/> Report an Warning Message with Details.<br />
* [[ Log Info | '''Log [ Info ]''' ]]<br/> Report an Info Message. Optionally decorate the failure-message with pre-/postFix string.<br />
* [[ Log Info | '''Log [ Info & Details ]''' ]]<br/> Report an Info Message with details.<br />
* [[ Log Data | '''Log [ Data ]''' ]]<br/> Report an Info Message with additional data.<br />
* [[ Log Image | '''Log [ Image ]''' ]]<br/> Report an Info Message with an additional bitmap image.<br />
* [[ Log ScreenDump | '''Log [ Screendump ]''' ]]<br/> Report an Info Message and attach a screen dump of the whole screen.<br />
* [[ Log ScreenDump | '''Log [ Screendump Area ]''' ]]<br/> Report an Info Message and attach a screen dump of a screen area.<br />
* [[ Log ScreenDump to File | '''Log [ Screendump to File]''' ]]<br/> Report an Info Message and save a screen dump of the whole screen at a given path.<br />
* [[ Log ScreenDump to File | '''Log [ Screendump Area to File]''' ]]<br/> Report an Info Message and save a screen dump of a screen area at a given path.<br />
* [[ Log Attach DataFile | '''Log [ Attach DataFile]''' ]]<br/> Report an Info Message and attach a data file. The file will be attached to the generated .elf (report file).<br />
* [[ Log Attach Image | '''Log [ Attach DataFile]''' ]]<br/> Report an Info Message and attach a bitmap image file. The image will be attached to the generated .elf (report file).<br />
* [[ Log Attach ScreenDump | '''Log [ Attach Screendump]''' ]]<br/> Report an Info Message and attach a screen dump image file. The image will be attached to the generated .elf (report file).<br />
* [[ Log Attach ScreenDump | '''Log [ Attach Screendump Area]''' ]]<br/> Report an Info Message and attach a screen dump image file. The image will be attached to the generated .elf (report file).<br />
<br />
=== Info Messages ===<br />
* [[ Information Message | '''Information Message''' ]]<br/> Show a message in the browser's info area (at the bottom). Useful to provide some progress-feedback to the test-operator. Notice: these messages are not persistent in the generated log report. (in contrast to the Log* blocks)<br />
* [[ Information Message | '''Information Message (Warning)''' ]]<br/> Show a warning message in the browser's info area (at the bottom). Useful to provide some progress-feedback to the test-operator. Notice: these messages are not persistent in the generated log report. (in contrast to the Log* blocks)<br />
* [[transcriber | '''Transcriber''' ]]<br/> Displays its input string as a line in the Transcript window. If there is no open Transcript window, a new one will be opened. Useful to provide some feedback to the test-operator. Notice: these messages are not persistent in the generated log report. (in contrast to the Log* blocks)<br />
* [[transcriber without cr | '''Transcriber without CR''' ]]<br/> Displays its input string in the Transcript window like the transcriber, but does not generate a newLine at the end. If there is no open Transcript window, a new one will be opened. Useful to provide some feedback to the test-operator. Notice: these messages are not persistent in the generated log report. (in contrast to the Log* blocks)<br />
* [[ Show Transcript Window | '''Show Transcript Window''' ]]<br/>Ensure that a transcript window is visible. If there is no existing Transcript window, a new one will be opened.<br />
* [[ Hide Transcript Window | '''Hide Transcript Window''' ]]<br/>Ensure that a transcript window is invisible (iconified). If there is no existing Transcript window, this is a NO-Operation.<br />
* [[ Clear Transcript Window | '''Clear Transcript Window''' ]]<br/>Clears the transcript window. If there is no existing Transcript window, this is a NO-Operation (1.9.1).<br />
* [[ Contents of Transcript | '''Contents of Transcript''' ]]<br/>Retrieves the contents of the transcript window as a collection of line-strings (1.9.1).<br />
* [[ Log Start of Testcase on Transcript | '''Log Start of Testcase on Transcript''' ]]<br/>Generates a log message about a started testcase on the Transcript.<br />
* [[ Log Finish of Testcase on Transcript | '''Log Finish of Testcase on Transcript''' ]]<br/>Generates a log message about a finished testcase on the Transcript.<br />
<br />
=== Assertions ===<br />
* [[ Assert Equal | '''Assert [ Equal ]''' ]]<br/> Fail if the two input values are not equal. Notice the difference between identity and equality.<br />
* [[ Assert Not Equal | '''Assert [ Not Equal ]''' ]]<br/> Fail if the two input values are equal.<br />
* [[ Assert Identical | '''Assert [ Identical ]''' ]]<br/> Fail if the two inputs are not identical (the same object).<br />
* [[ Assert Not Identical | '''Assert [ Not Identical ]''' ]]<br/> Fail if the two inputs are identical (the same object).<br />
* [[ Assert True | '''Assert [ True ]''' ]]<br/> Fail if the input value is not true.<br />
* [[ Assert False | '''Assert [ False ]''' ]]<br/> Fail if the input value is not false.<br />
* [[ Assert_Values | '''Assert [ Value is Less or Equal ]''' ]]<br/> Fail if the input value is above a given limit.<br />
* [[ Assert_Values | '''Assert [ Value is Less ]''' ]]<br/> Fail if the input value is not below a given limit.<br />
* [[ Assert_Values | '''Assert [ Value is Greater or Equal ]''' ]]<br/> Fail if the input value is less than a given limit.<br />
* [[ Assert_Values | '''Assert [ Value is Greater ]''' ]]<br/> Fail if the input value is not above a given limit.<br />
* [[ Assert_Values | '''Assert [ Value in Range ]''' ]]<br/> Fail if the input value is not in the given min..max range.<br />
* [[ Assert_Values | '''Assert [ Value NOT in Range ]''' ]]<br/> Fail if the input value is in the given min..max range.<br />
* [[ Assert_Values | '''Assert [ Value in Set ]''' ]]<br/> Fail if the input value is not in the given set of allowed values.<br />
* [[ Assert_Values | '''Assert [ Value NOT in Set ]''' ]]<br/> Fail if the input value is in the given set of allowed values.<br />
* [[ Assert_Values | '''Assert [ Value arrives at Pin1 ]''' ]]<br/> Fail if an input arrived at any other than pin1 (can be used that some value arrives definitely via s particular path).<br />
* [[ Assert same collection contents | '''Assert [ Same Collection Contents ]''' ]]<br/> Fail if the two input collections do not contain the same elements (in the same order) (1.8.1).<br />
* [[ Assert_File_Exists | '''Assert [ File Exists ]''' ]]<br/> Fail if the given filename does not exist (as either file or directory) (1.9.1).<br />
* [[ Assert_File_is_Directory | '''Assert [ File is Directory ]''' ]]<br/> Fail if the given filename does not refer to an existing folder (1.9.1).<br />
<br />
== Collections ==<br />
<br />
* [[ Collection elementAt | '''Collection [ ElementAt ]''' ]]<br/> Retrieve an element by its key. <br />
* [[ Collection elementAt 0 based | '''Collection [ ElementAt 0-based ]''' ]]<br/> Retrieve an element by its numeric key.<br />
* [[ Collection addElement | '''Collection [ AddElement ]''' ]]<br/> Add an element to the collection.<br />
* [[ Collection removeElement | '''Collection [ RemoveElement ]''' ]]<br/> Remove an element from the collection.<br />
* [[ Collection elementAtPut | '''Collection [ ElementAtPut ]''' ]]<br/> Store an element by key/value.<br />
* [[ Collection elementAtPut 0 based | '''Collection [ ElementAtPut 0-based ]''' ]]<br/> Store an element by key/value.<br />
* [[ Collection newDictionary| '''Collection [ NewDictionary ]''' ]]<br/> Create a new Dictionary (aka HashTable).<br />
* [[ Collection newOrderedCollection| '''Collection [ NewOrderedCollection ]''' ]]<br/> Create a new OrderedCollection (dynamic size Vector).<br />
* [[ Collection newSet| '''Collection [ NewSet ]''' ]]<br/> Create a new set.<br />
* [[ Collection newSortedCollection| '''Collection [ NewSortedCollection ]''' ]]<br/> Create a new sorted collection.<br />
* [[ Collection some elements| '''Collection [ Some Elements ]''' ]]<br/> Output a slice of some elements copied from the inCollection (1.7.1).<br />
* [[ Collection first n elements| '''Collection [ First N Elements ]''' ]]<br/> Output the first N elements of the inCollection.<br />
* [[ Collection first n existing elements| '''Collection [ First N existing Elements ]''' ]]<br/> Output the first N existing elements of the inCollection (1.7.1).<br />
* [[ Collection all but first n elements| '''Collection [ All but first N Elements ]''' ]]<br/> Output inCollection without the first N elements.<br />
* [[ Collection last n elements| '''Collection [ Last N Elements ]''' ]]<br/> Output the last N elements of the inCollection.<br />
* [[ Collection last n existing elements| '''Collection [ Last N existing Elements ]''' ]]<br/> Output the last N existing elements of the inCollection (1.7.1).<br />
* [[ Collection all but last n elements| '''Collection [ All but Last N Elements ]''' ]]<br/> Output inCollection without last N elements.<br />
* [[ Collection min| '''Collection [ Min ]''' ]]<br/> Get the minimum-element of the collection.<br />
* [[ Collection max| '''Collection [ Max ]''' ]]<br/> Get the maximum-element of the collection.<br />
* [[ Collection minMax| '''Collection [ MinMax ]''' ]]<br/> Get both the minimum and the maximum-element of the collection (1.7.1).<br />
* [[ Collection size| '''Collection [ Size ]''' ]]<br/> Get the size of the collection.<br />
* [[ Collection includesAll | '''Collection [ IncludesAll ]''' ]]<br/> Checks if a collection includes ALL of the given elements.<br />
* [[ Collection includesAny| '''Collection [ IncludesAny ]''' ]]<br/> Checks if a collection includes ANY of the given elements.<br />
* [[ Collection includes| '''Collection [ Includes ]''' ]]<br/> Checks if a collection includes the given element.<br />
* [[ Collection copy| '''Collection [ Copy ]''' ]]<br/> Passes a copy of the collection to the output pin.<br />
* [[ Collection select elementsMatching |'''Collection [ Select ElementsMatching ]''']]<br/>Generates a new collection containing all elements which match a given pattern.<br />
* [[ Collection select columns|'''Collection [ Select Columns ]''']]<br/>Generates a new collection containing elements with selected columns only.<br />
* [[ Collection select by st expression|'''Collection [ Select/Reject/Collect by ST Expression ]''']]<br/>Generates a new collection containing elements with items selected by Smalltalk expressions.<br />
* [[ Collection sort| '''Collection [ Sort ]''' ]]<br/> Generates a sorted copy of the input collection.<br />
* [[ Collection sort ignoring case| '''Collection [ Sort Ignoring Case ]''' ]]<br/> Generates a sorted copy of the input collection, ignoring case differences when sorting.<br />
* [[ Collection enumerate | '''Collection [ Enumerate ]''']]<br/>Enumerates the elements of a collection.<br />
* [[ Collection enumerate | '''Collection [ Enumerate with EndMark]''']]<br/>Enumerates the elements of a collection with an end mark.<br />
* [[ Collection enumerate | '''Collection [ Enumerate Keys & Values ]''']]<br/>Enumerates the elements of a collection as key & value pairs.<br />
* [[ Collection enumerate | '''Collection [ Reverse Enumerate ]''']]<br/>Enumerates the elements of a collection in reverse order.<br />
* [[Collection average deviation|'''Collection [Average & Deviation]''']]<br/>Computes the average and standard deviation of the elements of a collection.<br />
* [[ data collector | '''Data Collector [ OrderedCollection ]''' ]] <br />Collects all incoming data and sends it as one OrderedCollection to the output pin.<br />
* [[ data collector set | '''Data Collector [ Set ]''' ]] <br />Collects all incoming data and sends it as a Set to the output pin (1.9.1).<br />
<br />
== Compare ==<br />
<br />
Many compare blocks come in two versions: one which generates a true/false boolean value (the 1-way blocks) and another, which sends the result to one of two (or three) different outputs. The later are very useful to split the flow of control to different followup blocks (although that behaviour could also be simulated by using a 1-way compare followed by a pass-data block from the "misc" section).<br />
<br />
Notice: these blocks allow for Numbers, Strings, Collections and some other types to be compared. However, for the order relation compare operations, the types must be compatible; you cannot mix Numbers with Strings or other there.<br />
<br />
* [[ compare 3 way | '''Compare [ 3-Way ]''' ]]<br> Sends a boolean "true" value to one of its three outputs: LESS, EQUAL or GREATER.<br />
<br />
* [[ compare equal 2 way | '''Compare [ Equal 2-Way ]''' ]]<br/> Compare two values for equality; Send the first value to either the triggerYES or the triggerNO output.<br />
<br />
* [[ compare not equal 2 way | '''Compare [ Not Equal 2-Way ]''' ]]<br/> Compare two values for equality; Send the first value to either the triggerYES or the triggerNO output.<br />
<br />
* [[ compare less 2 way | '''Compare [ Less 2-Way ]''' ]]<br/> If the input at in1 is less than in2, send it to the triggerYES output. Otherwise, send it to triggerNO.<br />
<br />
* [[ compare less or equal 2 way | '''Compare [ LessOrEqual 2-Way ]''' ]]<br/> If the input at in1 is less or equal than in2, send it to the triggerYES output. Otherwise, send it to triggerNO.<br />
<br />
* [[ compare greater or equal 2 way | '''Compare [ GreaterOrEqual 2-Way ]''' ]]<br/> If the input at in1 is greater or equal than in2, send it to the triggerYES output. Otherwise, send it to triggerNO.<br />
<br />
* [[ compare greater 2 way | '''Compare [ Greater 2-Way ]''' ]]<br/> If the input at in1 is greater than in2, send it to the triggerYES output. Otherwise, send it to triggerNO.<br />
<br />
* [[ compare equal | '''Compare [ Equal ]''' ]]<br/> Generate a true if in1 is equal to the input value2 in2; otherwise, generate a false.<br />
<br />
* [[ compare not equal | '''Compare [ Not Equal ]''' ]]<br/> Generate true if in1 is not equal to in2; otherwise, generate a false.<br />
<br />
* [[ compare less | '''Compare [ Less ]''' ]]<br/> Generate a true if in1 is less than the input value2 in2; otherwise, generate a false.<br />
<br />
* [[ compare lessorequal | '''Compare [ LessOrEqual ]''' ]]<br/> Generate a true if in1 is less or equal than the input value2 in2; otherwise, generate a false.<br />
<br />
* [[ compare greaterorequal | '''Compare [ GreaterOrEqual ]''' ]]<br/> Generate a true if in1 is greater or equal than the input value2 in2; otherwise, generate a false.<br />
<br />
* [[ compare greater | '''Compare [ Greater ]''' ]]<br/> Generate a true if in1 is greater than to the input value2 in2; otherwise, generate a false.<br />
<br />
* [[ compare identical 2 way | '''Compare [ Identical 2-Way ]''' ]]<br/> Compare two values for identity; Send the first value to either the triggerYES or the triggerNO output.<br />
<br />
* [[ compare not identical 2 way | '''Compare [ Not Identical 2-Way ]''' ]]<br/> Compare two values for identity; Send the first value to either the triggerYES or the triggerNO output.<br />
<br />
* [[Compare same collection contents|'''Compare [ Same Collection Contents ]''']]<br/> Generate a true if the two input collections contain the same elements (in the same order); otherwise, generate a false (1.8.1).<br />
<br />
== Data Generators ==<br />
<br />
* [[ random booleans | '''Random [ Booleans ] ''' ]]<br/> Produces a number (default: 1) of random booleans on its output.<br />
* [[ random floats | '''Random [ Floats ] ''' ]]<br/> Produces a number (default: 1) of random floats on its output.<br />
* [[ random integers | '''Random [ Integers ] ''' ]]<br/> Produces a number (default: 1) of random integers values on its output.<br />
* [[ random time deltas | '''Random [ Time Deltas ] ''' ]]<br/> Produces a number (default: 1) of random timeDeltas on its output.<br />
* [[ random permutation | '''Random [Permutation] ''' ]]<br/> Produces a number (default: 1) of random permutations of the input-collection.<br />
* [[ generate all permutations | '''Generate all Permutations ''' ]]<br/> Produces all permutations of the collection given to its input.<br />
* [[ generate series | '''Generate Series ''' ]]<br/> Produces values from an arithmetic series.<br />
* [[ generate geometric series | '''Generate Geometric Series ''' ]]<br/> Produces values from a geometric series. <br />
* [[ random uuid | '''Generate UUID ''' ]]<br/> Generate a new Universally Unique ID (UUID) as defined in RFC4122<br />
* [[ generate prime numbers | '''Generate Prime Numbers ''' ]]<br/> Produces a collection of prime numbers. (1.7.2) <br />
* [[ next prime number | '''Next Prime ''' ]]<br/> Generates the next prime after some number. (1.7.2)<br />
<br />
== Data Types ==<br />
<br />
Additional Datatypes. No description yet.<br />
<br />
<br />
== Files & Directories ==<br />
<br />
<br />
=== Files ===<br />
<br />
* [[file directory | '''File [ Directory ] ''' ]]<br/> Extract the directory.<br />
* [[file directoryname | '''File [ DirectoryName ] ''' ]]<br/> Extract the directory name (i.e. a string).<br />
* [[file contents | '''File [ Contents ] ''' ]]<br/> Get the contents of a file.<br />
* [[file binarycontents | '''File [ BinaryContents ] ''' ]]<br/> Get the binary contents of a file.<br />
* [[file constructfn | '''File [ ConstructFn ] ''' ]]<br/> Construct a filename from the given components. <br />
* [[file changesuffix | '''File [ ChangeSuffix ] ''' ]]<br/> Construct a filename from the given fileName and a new suffix.<br />
* [[file remove | '''File [ Remove ] ''' ]]<br/> Remove the file named fileToRemove.<br />
* [[file recursive remove|'''File [ Recursive Remove ]''']]<br/> Remove the file/directory named fileToRemove.<br />
* [[file newtempfn | '''File [ NewTempFn ] ''' ]]<br/> Generate a new temporary filename.<br />
* [[file NewTempFnIn | '''File [ NewTempFnIn ] ''' ]]<br/> Generate a new unique temporary filename within a parent directory.<br />
* [[file readcsv | '''File [ ReadCSV ] ''' ]]<br/> Read a csv file.<br />
* [[file read key-value pairs | '''File [ Read Key-Value Pairs ] ''' ]]<br/> Read a file and return a dictionary with the keys and values.<br />
* [[file read key-value TuplePairs | '''File [ Read Key-Value TuplePairs ] ''' ]]<br/> Read a file and return a dictionary with the keys and values.<br />
<br />
=== Queries ===<br />
<br />
* [[file exists | '''File [ Exists ] ''' ]]<br/> Check, if a file exists.<br />
* [[file isdirectory | '''File [ IsDirectory ] ''' ]]<br/> Check, if a file exists and is a directory.<br />
* [[file basename | '''File [ Basename ] ''' ]]<br/> Extract the baseName (i.e. the name without directory prefix)<br />
* [[file suffix | '''File [ Suffix ] ''' ]]<br/> Extract a filename's suffix (i.e. the extension).<br />
* [[file filesize | '''File [ FileSize ] ''' ]]<br/> Get the number of bytes in a file.<br />
* [[file size | '''File [ Size ] ''' ]]<br/> Retrieve a file's size.<br />
<br />
=== Creation ===<br />
<br />
* [[file copy | '''File [ Copy ] ''' ]]<br/> Copy a sourcePath to a destinationPath.<br />
* [[file createempty | '''File [ CreateEmpty ] ''' ]]<br/> Create an empty file.<br />
* [[file create | '''File [ Create ] ''' ]]<br/> Creates a file, taking the contents from the content input pin.<br />
<br />
=== Directories ===<br />
<br />
* [[ Directory Create | '''Directory [ Create ] ''']] <br/> Creates a directory based on the given filepath.<br />
* [[ directoryname | '''Directory [ DirectoryName ] ''']] <br/> Get the name of a directory.<br />
* [[ directory tempdir | '''Directory [ TempDir ] ''']] <br/> Get the temp directory (as filename).<br />
* [[ directory TempDir Name | '''Directory [ TempDir Name ] ''']] <br/> Get the name of the default temporary directory (as path-string).<br />
* [[ directory newtempdir | '''Directory [ NewTempDir ] ''']] <br/> Create a new temporary directory and provide its name.<br />
* [[ directory NewTempDirIn | '''Directory [ NewTempDirIn ] ''']] <br/> Create a new temporary directory in a given parent directory and provide its name (as Filename).<br />
* [[ directory Root | '''Directory [ Root ] ''']] <br/> Provide the name of the root directory (as Filename).<br />
* [[ directory Home | '''Directory [ Home ] ''']] <br/> Provide the name of the user's home directory (as Filename).<br />
* [[ directory Documents | '''Directory [ Documents ] ''']] <br/> Provide the name of the user's documents directory (as Filename).<br />
* [[ directory enumerate | '''Directory [ Enumerate ] ''']] <br/> Get the contents of a directory - that is all the names found there (non-recursive).<br />
<br />
== GUI-Dialogs ==<br />
<br />
<br />
* [[dialog request string | '''Dialog [ Request String ]''' ]] <br/> Requests a string from the user (via a dialog).<br />
* [[dialog request password | '''Dialog [ Request Password ]''' ]] <br/> Requests a password from the user (via a dialog).<br />
* [[dialog request filename | '''Dialog [ Request Filename ]''' ]] <br/> Requests a filename from the user (via a file-dialog).<br />
* [[dialog confirm | '''Dialog [ Confirm ]''' ]] <br/> Requests a confirmation (true / false) from the user (via a dialog).<br />
* [[dialog confirm | '''Dialog [ Confirm 2 Way ]''' ]] <br/> Like above, but provides two separate outputs.<br />
* [[dialog confirm with Cancel | '''Dialog [ Confirm with Cancel ]''']] <br/> Requests a confirmation (true / false) from the user with an additional "Cancel"-Button.<br />
* [[dialog confirm with Cancel | '''Dialog [ Confirm with Cancel 2 Way ]''' ]] <br/> Like above, but provides two separate outputs.<br />
* [[dialog confirm with Cancel | '''Dialog [ Confirm with Cancel 3 Way ]''' ]] <br/> Like above, but provides three separate outputs.<br />
* [[dialog information | '''Dialog [ Information ]''' ]] <br/> Show a Dialog with the informationString.<br />
* [[dialog warning | '''Dialog [ Warning ]''' ]] <br/> Show a Warn-Dialog with the informationString.<br />
* [[Dialog Colored Warning | '''Dialog [ Colored Warning ]''' ]] <br/> Show a Warn-Dialog with the informationString.<br />
* [[Dialog Show Value | '''Dialog [ Show Value ]''' ]] <br/> Show an Information-Dialog to display a value.<br />
* [[Dialog Show Table | '''Dialog [ Show Table ]''' ]] <br/> Show a Dialog to display a table.<br />
<br />
=== Inspecting & Debugging ===<br />
<br />
* [[Inspect | ''' Inspect ''' ]] <br/> Open an inspector window to show some datums contents.<br />
* [[Show Image | ''' Show Image ''' ]] <br/> Open an image viewer to show some image.<br />
* [[Edit Image | ''' Edit Image ''' ]] <br/> Open a bitmap editor to allow some limited image manipulations.<br />
* [[Edit Color | ''' Edit Color ''' ]] <br/> Open a color editor (useful to inspect picked web-page colors).<br />
<br />
=== Support ===<br />
<br />
* [[Color By Name | '''Color [ By Name ]''' ]] <br/> Return a color object, given a color name (such as 'red', 'green' or 'blue')<br />
* [[Color By RGB | '''Color [ By RGB ]''' ]] <br/> Return a color object, given a rgb bytes (red, green, blue)<br />
* [[Color By HLS | '''Color [ By HLS ]''' ]] <br/> Return a color object, given hue (in degrees from 0..360), light (0..1) and saturation (0..1).<br />
* [[Color Get RGB | '''Color [ Get RGB ]''' ]] <br/> Return a colors red/green/blue byte values.<br />
* [[Color Get HLS | '''Color [ Get HLS ]''' ]] <br/> Return a colors hue/light/saturation byte values.<br />
* [[Color Brighter | '''Color [ Brighter ]''' ]] <br/> Return a brightened color (blended with white).<br />
* [[Color Darker | '''Color [ Darker ]''' ]] <br/> Return a darkened color (blended with black).<br />
<br />
== Images ==<br />
<br />
* [[ Image screendump | '''Image [ Screendump ]''' ]]<br/> Take a snapshot of the screen (1.7.2) <br />
* [[ Image screendump | '''Image [ Screendump Area ]''' ]]<br/> Take a snapshot of a part of the screen (1.7.2) <br />
* [[ Image From File | '''Image [ From File ]''' ]]<br/> Read a Bitmap Image File (1.7.2) <br />
* [[ Image From File | '''Image [ From Data ]''' ]]<br/> Read a Bitmap Image from Data (1.7.2) <br />
* [[ Image Save As File | '''Image [ Save as File ]''' ]]<br/> Save a Bitmap Image File (1.7.2) <br />
* [[ Image Get Attributes | '''Image [ Get Attributes ]''' ]]<br/> Get Attributes of a Bitmap Image File (1.7.2) <br />
* [[ Image Magnify | '''Image [ Magnify ]''' ]]<br/> Magnify or Shrink an Image (1.7.2) <br />
* [[ Image Rotate | '''Image [ Rotate ]''' ]]<br/> Rotate an Image (1.7.2) <br />
* [[ Convert to Greyscale | '''Image [ Convert to Greyscale ]''' ]]<br/> Convert an Image to Greyscale (1.7.2) <br />
* [[ Convert to Depth24 | '''Image [ Convert to Depth24 ]''' ]]<br/> Convert an Image to a depth-24 image (1.9.1) <br />
* [[ Image Fetch via HTTP | '''Image [ Fetch via HTTP ]''' ]]<br/> Fetch a Bitmap Image via HTTP (1.7.2)<br />
<br />
== Logic ==<br />
<br />
* [[ Logic not | ''' Logic [ Not ] ''' ]]<br/> Output the negated boolean input value.<br />
* [[ Logic IfTrueIfFalse | ''' Logic [ IfTrueIfFalse ] ''' ]]<br/> If the boolean input value is true, trigger triggerTrue, else trigger triggerFalse<br />
* [[ Logic and | ''' Logic [ And ] ''' ]]<br/> Output TRUE if both boolean inputs are true.<br />
* [[ Logic or | ''' Logic [ Or ] ''' ]]<br/> Output TRUE if one of the boolean inputs is TRUE.<br />
* [[ Logic xor | ''' Logic [ Xor ] ''' ]]<br/> Output TRUE if both boolean inputs have different values.<br />
<br />
== Misc ==<br />
<br />
* [[ start | '''START''' ]]<br/> Does nothing, can be used with autostart as a trigger.<br />
<br />
* [[ JOIN | '''JOIN'''<br />
]]<br/> When ALL inputs are available, continue.<br />
<br />
* [[ datasink | '''Data Sink''' ]]<br/> Consume (and throw away) any data from the input pin.<br />
<br />
* [[ datasource | '''Data Source''' ]]<br/> Pass its input to its output. Can be used to start a dataflow, if the input is frozen and the block is triggered via autoStart or the START node above.<br />
<br />
* [[ Which Pin has Data | '''Which Pin has Data''' ]]<br/> Delivers info from where some datum came (1.9.1).<br />
<br />
* [[ Got at least one Value | '''Got at least one Value?''' ]]<br/> To check if some data arrived at a pin (1.9.1).<br />
<br />
* [[ Input Pin has Value | '''Input Pin has Value?''' ]]<br/> To check if some data arrived at a pin (1.9.1).<br />
<br />
* [[ pass data if true | '''Pass Data if True''' ]]<br/> Used to conditionally pass data along a connection or to block/throw it away in other situations.<br />
<br />
* [[ pass data if false | '''Pass Data if False''' ]]<br/> Used to conditionally pass data along a connection or to block/throw it away in other situations.<br />
<br />
* [[ pass data if true or false | '''Pass Data if True/False''' ]]<br/> Used to conditionally pass data along one of two alternative connection paths.<br />
<br />
* [[ if true false 2 way | '''If True/False (2 way)''' ]]<br/> Passes the incoming boolean to one of two outputs (split execution path) (1.9.1).<br />
<br />
* [[ either or | '''Either - Or''' ]]<br/> Passes one of two input values to the output (1.9.1).<br />
<br />
* [[ distribute | '''Distribute (Load Balancer)''' ]]<br/> Sends the incoming value to the output with the smallest waiting queue size (1.9.1).<br />
<br />
* [[ wait forever | '''Wait Forever''' ]]<br/> Simply waits forever.<br />
<br />
=== Expecco Reflection ===<br />
<br />
These provide info about the state of the tool and execution engine.<br />
<br />
* [[ directory project directory | ''' Directory [ Projects Directory ] ''' ]] <br/> Provides the project directory (that is the root of where attachments, temporary files etc. are located)<br />
<br />
* [[ directory attachment directory | ''' Directory [ Attachment Directory ] ''' ]] <br/> Provides the attachment directory (that is where attachments are located)<br />
<br />
* [[ directory execution directory | ''' Directory [ Executors Directory ] ''' ]] <br/> Provides the execution directory (that is where temporary files are created)<br />
<br />
* [[ directory projectFile path | ''' Directory [ ProjectFile Path] ''' ]] <br/> Retrieves the pathname to the current projectfile (the ".ets"-file) (1.7.4)<br />
<br />
* [[ Control Window IsOpen | ''' Control Window [ IsOpen ] ''' ]] <br/> This block returns true, if a Control & Monitoring window is currently open.<br />
<br />
<br />
* [[ Name of Current Testplan | ''' Name of Current Testplan ''' ]] <br/> This block provides the name of the currently executing testplan (1.7.3).<br />
<br />
* [[ Name of Current Testcase | ''' Name of Current Testcase ''' ]] <br/> This block provides the name of the currently executing testcase (1.7.3).<br />
<br />
* [[ StartTime of Current Testplan | ''' Start Time of Current Testplan ''' ]] <br/> This block provides the startTime of the currently executing testplan (Timestamp) (1.9.1).<br />
<br />
* [[ StartTime of Current Testcase | ''' Start Time of Current Testcase ''' ]] <br/> This block provides the startTime of the currently executing testcase (Timestamp) (1.7.3).<br />
<br />
* [[ Current Testplan | ''' Current Testplan ''' ]] <br/> This block provides a handle to the currently executing testplan (1.9.1).<br />
<br />
* [[ Current Testcase | ''' Current Testcase ''' ]] <br/> This block provides a handle to the currently executing testcase (1.9.1).<br />
<br />
=== Reporting ===<br />
<br />
* [[Report generate | ''' Report [ Generate ] ''' ]] <br/> Generates a report in a specified format for the currently running test execution (1.7.2).<br />
<br />
* [[Report generate | ''' Report [ Generate PDF File ] ''']] <br/> Generates a report in PDF format for the currently running test execution (1.7.2).<br />
<br />
* [[ Report generate | ''' Report [ Generate HTML File ] ''']] <br/> Generates a report in HTML format for the currently running test execution (1.7.2).<br />
<br />
=== Virtual to Concrete Mapping ===<br />
<br />
* [[Local Specify Concrete Block | ''' Local Specify Concrete Block ''' ]] <br/> Setup a local Virtual-to-Concrete mapping for a single virtual block (1.7.4).<br />
<br />
* [[Local Specify Concrete Library | ''' Local Specify Concrete Library ''' ]] <br/> Setup a local Virtual-to-Concrete mapping for a complete virtual library (1.7.4).<br />
<br />
* [[Global Specify Concrete Block | ''' Global Specify Concrete Block ''' ]] <br/> Setup a global Virtual-to-Concrete mapping for a single virtual block (1.7.4).<br />
<br />
* [[Global Specify Concrete Library | ''' Global Specify Concrete Library ''' ]] <br/> Setup a global Virtual-to-Concrete mapping for a complete virtual library (1.7.4).<br />
<br />
* [[Executor Specify Concrete Block | ''' Executor Specify Concrete Block ''' ]] <br/> Setup a Virtual-to-Concrete mapping for a single virtual block which is valid in the current testCase only (1.7.4).<br />
<br />
* [[Executor Specify Concrete Library | ''' Executor Specify Concrete Library ''' ]] <br/> Setup a Virtual-to-Concrete mapping for a complete virtual library which is valid in the current testCase only (1.7.4).<br />
<br />
=== Resources ===<br />
<br />
* [[Get Resource by ID| ''' Get Resource by ID ''' ]] <br/> Retrieve an already acquired resource, given a skill-id (1.7.4).<br />
<br />
* [[Get Name from Resource| ''' Get Name from Resource ''' ]] <br/> Retrieve a resource's name (1.7.4).<br />
<br />
* [[Get SkillAttribute from Resource| ''' Get Skill Attribute from Resource ''' ]] <br/> Retrieve a skillAttribute's value from a resource (1.7.4).<br />
<br />
* [[Get all Resources from Top Inventory| ''' Get all Resources from Top Inventory ''' ]] <br/> Retrieve the collection of all available resources (1.9.1).<br />
<br />
== Networking & Interfacing ==<br />
<br />
* [[ Net IPAdress | ''' Net [ IPAdress ] ''' ]] <br/> Retrieve a hosts TCP/IP address.<br />
* [[ Net LocalIPAdress | ''' Net [ LocalIPAdress ] ''' ]] <br/> Retrieve the machines own IP Address.<br />
<br />
=== Checksums & Cryptography ===<br />
<br />
* [[ Hash_MD5 | ''' Hash [ MD5 ] ''' ]] <br/> Computes the MD5 checksum of a block of bytes (1.7.2) <br />
* [[ Hash_SHA1 | ''' Hash [ SHA1 ] ''' ]] <br/> Computes the SHA1 checksum of a block of bytes (1.7.2) <br />
* [[ Hash_CRC32 | ''' HASH [ CRC32 ] ''' ]]<br/> Computes a crc32 checksum (1.7.2)<br />
<br />
=== FTP ===<br />
<br />
* [[ T_FTPLink | ''' T_FTPLink ''' ]] <br/> This datatype represents the ftp-client object.<br />
* [[ ftp connect-e | ''' FTP [ Connect-E] ''' ]] <br/> Create a ftp-connection.<br />
* [[ ftp get-e | ''' FTP [ Get-E ] ''' ]] <br/> Get a file via ftp, and store it local.<br />
* [[ ftp put-e | ''' FTP [ Put-E ] ''' ]] <br/> Put a local file via ftp to the remote destination.<br />
* [[ ftp close-e | ''' FTP [ Close-E ] ''' ]] <br/> Close a ftp-connection.<br />
* [[ ftp delete-e | ''' FTP [ Delete-E ] ''' ]] <br/> Delete a file via ftp on the remote site.<br />
* [[ ftp put | ''' FTP [ Put ] ''' ]] <br/> Create ftp-connection - Put file - Close connection.<br />
* [[ ftp get | ''' FTP [ Get ] ''' ]] <br/> Create ftp-connection - Get file - Close connection.<br />
<br />
=== HTTP ===<br />
<br />
* [[ http FetchPage | ''' HTTP [ FetchPage ]''' ]] <br/> Fetches a page and provides the fetched document both as text and (optionally, if the output is connected) a tree of HTML-element nodes.<br />
* [[ http Get | ''' HTTP [ Get ]''' ]] <br/> Same as above, for readability.<br />
* [[ http Post | ''' HTTP [ Post ]''' ]] <br/> Generates a POST request (form submit).<br />
* [[ http ParseDocument | ''' HTTP [ ParseDocument ]''' ]] <br/> Parse a string to an html-document.<br />
* [[ http ExtractByTag | ''' HTTP [ Extract by Tag ]''' ]] <br/> Extracts specified nodes from a parsed document.<br />
* [[ http ExtractLinks | ''' HTTP [ ExtractLinks ]''' ]] <br/> Extracts all anchor nodes (<A>-links) from a parsed document.<br />
* [[ http ExtractImages | ''' HTTP [ ExtractImages ]''' ]] <br/> Extracts all image nodes (<IMG>) from a parsed document.<br />
* [[ A HREF | ''' A [ HREF ]''' ]] <br/> Extracts the HREF-url from an anchor element.<br />
* [[ IMG SOURCE | ''' IMG [ SOURCE ]''' ]] <br/> Extracts the IMG-source from an img element.<br />
<br />
==== Server ====<br />
<br />
* [[ http startserver | ''' HTTP [ StartServer ]''' ]] <br/> Start an HTTP server on a given port.<br />
* [[ http stopserver | ''' HTTP [ StopServer ]''' ]] <br/> Stop an HTTP server.<br />
* [[ http Add Default Home Service | ''' HTTP [ Add Default Home Service ]''' ]] <br/> Add a default service to an HTTP server.<br />
* [[ http Add File Service | ''' HTTP [ Add File Service ] ''' ]] <br/> Add a file service to an HTTP server.<br />
<br />
=== IMAP ===<br />
<br />
* [[ imap createconnection | ''' IMAP [ CreateConnection ] ''' ]] <br/> Connect to an IMAP mail server.<br />
* [[ imap fetchunreadmails | ''' IMAP [ FetchUnreadMails ] ''' ]] <br/> Fetch mails from an IMAP mail server.<br />
<br />
=== JSON ===<br />
<br />
* [[ JSON Encode| ''' JSON [ Encode] ''' ]] <br/> Encode an Object into JSON format (1.7.2) <br />
* [[ JSON Decode| ''' JSON [ Decode ] ''' ]]<br/> Decode an Object from JSON format (1.7.2)<br />
<br />
=== SMTP ===<br />
<br />
* [[SMTP send email | ''' SMTP [ send email ] ''' ]] <br/> Send an email via SMTP server<br />
<br />
=== Source Code Management ===<br />
<br />
* [[ cvs checkout | ''' CVS [ Checkout ] ''' ]] <br/> Check out a tree from the CVS-repository.<br />
* [[ cvs version | ''' CVS [ Version ] ''' ]]<br/> Get the CVS-commands version string.<br />
<br />
== OS ==<br />
<br />
* [[ os cputype | ''' OS [ CPUType ] ''' ]] <br/> Retrieve the CPU family type (i386, sparc,...).<br />
* [[ os domainname | ''' OS [ DomainName ] ''' ]] <br/> Retrieve the machine's (network-) domain name (could be empty or nil).<br />
* [[ os hostname | ''' OS [ HostName ] ''' ]] <br/> Retrieve the machine's host name.<br />
* [[ os language | ''' OS [ Language ] ''' ]] <br/> Retrieve the machine's language setting.<br />
* [[ os macadresses | ''' OS [ MACAddresses ] ''' ]] <br/> Retrieve the machine's MAC (network-adapter/ethernet) addresses.<br />
* [[ os type | ''' OS [ Type ] ''' ]] <br/> Get the type of OperatingSystem (win32, linux, etc.) we are running on.<br />
* [[ os is windows | ''' OS [ Is Windows ] ''' ]] <br/> Check if running on Windows (1.8.3).<br />
* [[ os is unix | ''' OS [ Is Unix ] ''' ]] <br/> Check if running on Unix (1.8.3).<br />
* [[ os systeminfo | ''' OS [ SystemInfo ] ''' ]] <br/> Get info about the OS and hardware we are running on.<br />
* [[ os drivelist | ''' OS [ DriveList ] ''' ]] <br/> Retrieve the list of drives in the machine (C:, D:, ...)<br />
* [[ os loginname | ''' OS [ LoginName ] ''' ]] <br/> Retrieve the user's login name.<br />
* [[ os fullusername | ''' OS [ FullUserName ] ''' ]] <br/> Retrieve the user's full name.<br />
* [[ os defaultsystempath | ''' OS [ DefaultSystemPath ] ''' ]] <br/> Retrieve the default system path.<br />
<br />
== String Processing ==<br />
<br />
* [[string concatenation | ''' String [ Concatenation ] ''' ]] <br/> Concatenate the string input values.<br />
* [[string collectionofstrings to string | ''' String [ CollectionOfStrings To String ] ''' ]] <br/> Generate a concatenated string from the input string collection; individual strings are joined using the optional separator.<br />
* [[string collectionoflines to string | ''' String [ CollectionOfLines To String ] ''' ]] <br/> Generate a concatenated string from the input string collection without an optional seperator.<br />
* [[string ascollectionofwords | ''' String [ AsCollectionOfWords ] ''' ]] <br/> Returns a collection of words.<br />
* [[string ascollectionoflines | ''' String [ AsCollectionOfLines ] ''' ]] <br/> Returns a collection of lines.<br />
* [[string ascollectionofsubstrings | ''' String [ AsCollectionOfSubstrings ] ''' ]] <br/> Returns a collection of substrings.<br />
<br />
=== Comparing & Matching ===<br />
* [[string caseless compare | ''' String [ Caseless Compare? ] ''' ]] <br/> Do a caseless string compare.<br />
* [[string simple_patternmatch | ''' String [ Simple PatternMatch? ] ''' ]] <br/> Do a pattern match similar to that used in the unix filename match algorithm.<br />
* [[string regular expression match | ''' String [ Regular Expression Match? ] ''' ]] <br/> Do a regular expression pattern match.<br />
* [[string regular expression match for subexpressions | ''' String [ Regular Expression Match for Subexpressions? ] ''' ]] <br/> Do a regular expression pattern match, provide matched subexpressions (1.8.3).<br />
<br />
* [[string Extract All Regex Matches| ''' String [ Extract All Regex Matches] ''' ]] <br/> Given a string and a regex pattern, provide a collection of ALL matching elements.<br />
* [[string Extract ONE Regex Match| ''' String [ Extract ONE Regex Matches] ''' ]] <br/> Given a string and a regex pattern, provide the first matching elements.<br />
* [[string compare switch | ''' String [ Compare Switch ] ''' ]] <br/> Compares a string with six other strings and triggers the first corresponding output-pin.<br />
* [[string includesstring | ''' String [ IncludesString? ] ''' ]] <br/> If the given string is contained in another string (substring) send the original string to the triggerYES output. Otherwise send it to the triggerNO output.<br />
* [[string IndexOfSubstrings | ''' String [ IndexOfSubstrings? ] ''' ]] <br/> Find a substring in a string starting at startIndex.<br />
* [[string startswith | ''' String [ StartsWith? ] ''' ]] <br/> If the given string starts with another string (prefix string) send the original string to the triggerYES output. Otherwise send it to the triggerNO output.<br />
* [[string endswith | ''' String [ EndsWith? ] ''' ]] <br/> If the given string ends with another string (suffix string) send the original string to the triggerYES output. Otherwise send it to the triggerNO output.<br />
* [[string Soundex | ''' String [ Soundex ] ''' ]] <br/> Generates a soundex string (see Knuth, for example)<br />
* [[string MySQLSoundex | ''' String [ MySQLSoundex ] ''' ]] <br/> Generates a MySQL soundex string (see Knuth, for example)<br />
* [[string KoelnerPhonetic | ''' String [ KölnerPhonetic ] ''' ]] <br/> Generates a kölnerPhonetic code string.<br />
* [[string EditDistance | ''' String [ EditDistance ] ''' ]] <br/> Generates a value for the edit distance (actually Levenshtein), which is a measure for how many edit operations are needed to get from string1 to string2.<br />
<br />
=== Copying ===<br />
* [[string substring copy 0-based | ''' String [ Substring Copy 0-based ] ''' ]] <br/> Return a substring starting at the 0-based index startIndex up to (and including) the 0 based index endIndex.<br />
* [[string substring copy 1-based | ''' String [ Substring Copy 1-based ] ''' ]] <br/> Return a substring starting at the 0-based index startIndex up to (and including) the 1 based index endIndex.<br />
* [[string copyfrom 0-based | ''' String [ CopyFrom 0-based ] ''' ]] <br/> Return a substring starting at the 0-based index startIndex up to the end of the string.<br />
* [[string copyfrom 1-based | ''' String [ CopyFrom 1-based ] ''' ]] <br/> Return a substring starting at the 1-based index startIndex up to the end of the string.<br />
* [[string copyto 0-based | ''' String [ CopyTo 0-based ] ''' ]] <br/> Return a substring ending at the 0-based index endIndex.<br />
* [[string copyto 1-based | ''' String [ CopyTo 1-based ] ''' ]] <br/> Return a substring ending at the 1-based index endIndex.<br />
* [[string removefromto 0-based | ''' String [ RemoveFromTo 0-based ] ''' ]] <br/> Return a new string, where the substring starting at the 0-based index startIndex up to (and including) the 0-based index endIndex has been removed.<br />
* [[string removefromto 1-based | ''' String [ RemoveFromTo 1-based ] ''' ]] <br/> Return a new string, where the substring starting at the 1-based index startIndex up to (and including) the 1-based index endIndex has been removed.<br />
* [[string replacefromto 0-based | ''' String [ ReplaceFromTo 0-based ] ''' ]] <br/> Return a new string, where the substring starting at the 0-based index startIndex up to (and including) the 0-based index endIndex has been replaced by another string.<br />
* [[string replacefromto 1-based | ''' String [ ReplaceFromTo 1-based ] ''' ]] <br/> Return a new string, where the substring starting at the 1-based index startIndex up to (and including) the 1-based index endIndex has been replaced by another string.<br />
<br />
=== Encoding ===<br />
* [[base64| ''' Base 64 Encode [ String to Base64String ] ''' ]] <br/> Converts a string to its base64 encoding.<br />
* [[base64| ''' Base 64 Encode [ Base64String to String ] ''' ]] <br/> Decodes a base64 encoded string.<br />
* [[Rot13 | ''' Rot13 [ String to String ] ''' ]] <br/> Apply a simple Caesar rot13 cypher.<br />
* [[UTF8| ''' UTF8 Encode [ String to UTF8String ] ''' ]] <br/> Converts a string to its UTF-8 encoding.<br />
* [[UTF8| ''' UTF8 Decode [ UTF8String to String ] ''' ]] <br/> Decodes a UTF-8 encoded string.<br />
* [[asciistring convert to hexstring | ''' ASCIIString[ Convert to HexString] ''' ]] <br/> Converts a String to a string containing the original strings characters as hex-encoded pairs.<br />
* [[hexstring convert to asciistring | ''' HexString [ Convert to ASCIIString ] ''' ]] <br/> Converts a twoByte HexString to its ASCII representation.<br />
<br />
=== Padding & Formatting ===<br />
* [[string formatting | ''' String [ Formatting ] ''' ]] <br/> generate a formatted string for printing.<br />
* [[string leftcontracted | ''' String [ LeftContracted ] ''' ]] <br/> Do a string contraction (at the left).<br />
* [[string rightcontracted | ''' String [ RightContracted ] ''' ]] <br/> Do a string contraction (at the right).<br />
* [[string contracted | ''' String [ Contracted ] ''' ]] <br/> Do a string contraction (in the middle).<br />
* [[string leftpadded | ''' String [ LeftPadded ] ''' ]] <br/> Do a string padding.<br />
* [[string rightpadded | ''' String [ RightPadded ] ''' ]] <br/> Do a string padding (on the right).<br />
* [[string without leading whitespace | ''' String [ Without Leading Whitespace ] ''' ]] <br/> Return a copy of a string with leading whitespace (space, tab and newlines) removed.<br />
* [[string without trailing whitespace | ''' String [ Without Trailing Whitespace ] ''' ]] <br/> Return a copy of a string with trailing whitespace (space, tab and newlines) removed.<br />
* [[string without surrounding whitespace | ''' String [ Without Surrounding Whitespace ] ''' ]] <br/> Return a copy of a string with leading and trailing whitespace (space, tab and newlines) removed.<br />
* [[string asuppercase | ''' String [ AsUppercase ] ''' ]] <br/> Return the string converted to uppercase.<br />
* [[string aslowercase | ''' String [ AsLowercase ] ''' ]] <br/> Return the string converted to lowercase.<br />
* [[string asuppercasefirst | ''' String [ AsUppercaseFirst ] ''' ]] <br/> Return a new string with the first character converted to uppercase.<br />
<br />
=== Queries ===<br />
* [[string length | ''' String [ Length ] ''' ]] <br/> Count the number of characters in a string.<br />
* [[string BitsPerCharacters | ''' String [ BitsPerCharacters ] ''' ]] <br/> Return the number of bits in a character.<br />
* [[string IsSingleByteString | ''' String [ IsSingleByteString? ] ''' ]] <br/> Return true, if the number of bits in the strings characters are 8.<br />
<br/><br />
<br />
== Stream Input/Output ==<br />
* [[stream close | '''Stream [ Close ] ''' ]] <br/> Close a stream-handle. No further read operations are possible.<br />
* [[stream EOF | '''Stream [ EOF?] ''' ]] <br/> Check if end-of-file has been reached. (1.7.2)<br />
<br />
=== File Streams ===<br />
* [[filestream open for reading | '''FileStream [ Open for Reading ]''' ]] <br/> Open a file for reading. Provide a stream-handle for further read operations.<br />
* [[filestream open for reading error at EOF | ''' FileStream [ Open for Reading Error at EOF ] ''' ]] <br/> Open a file for reading. The stream will report an error if a read after EOF is attempted.<br />
* [[filestream open for writing | '''FileStream [ Open for Writing ]''' ]] <br/> Open a file for writing. Provide a stream-handle for further write operations.<br />
* [[fileStream open for appending | '''FileStream [ Open for Appending ]''' ]] <br/> Open a file for append-writing. Provide a stream-handle for further write operations. (1.7.1)<br />
* [[Stream Create TempFile | '''FileStream [ Create TempFile ]''' ]] <br/> Create a new temporary file.<br />
<br />
=== Stream Reading ===<br />
* [[stream readline | '''Stream [ ReadLine ]''' ]] <br/> Read a line from a read-stream (up to CR or NL).<br />
* [[stream contents | '''Stream [ Contents ]''' ]] <br/> Read the whole content from a stream and return the content as string-collection. <br />
* [[stream readbyte | '''Stream [ ReadByte ]''' ]] <br/> Read a single byte from a read-stream.<br />
* [[stream readbytes | '''Stream [ ReadBytes ]''' ]] <br/> Read a number of bytes from a read-stream.<br />
* [[stream readcharacters | '''Stream [ ReadCharacters ]''' ]] <br/> Read a number of characters from a read-stream.<br />
* [[stream readalphanumericword | '''Stream [ ReadAlphaNumericWord ]''' ]] <br/> Read an alphanumeric word from a read-stream.<br />
* [[Stream ReadThrough | '''Stream [ ReadThrough ]''' ]] <br/> Read characters up to and including a delimiting string. (1.7.2)<br />
* [[Stream ReadUpTo | '''Stream [ ReadUpTo ]''' ]] <br/> Read characters up to a delimiting string. (1.7.2)<br />
* [[stream readint16 | '''Stream [ ReadInt16 ]''' ]] <br/> Read a two-byte (16bit) signed integer from a read-stream.<br />
* [[stream readint32 | '''Stream [ ReadInt32 ]''' ]] <br/> Read a four-byte (32bit) signed integer from a read-stream.<br />
* [[stream readint64 | '''Stream [ ReadInt64 ]''' ]] <br/> Read an eight-byte (64bit) unsigned integer from a read-stream.<br />
* [[stream readuint16 | '''Stream [ ReadUInt16 ]''' ]] <br/> Read a two-byte (16bit) unsigned integer from a read-stream.<br />
* [[stream readuint32 | '''Stream [ ReadUInt32 ]''' ]] <br/> Read a four-byte (32bit) unsigned integer from a read-stream.<br />
* [[stream readuint64 | '''Stream [ ReadUInt64 ]''' ]] <br/> Read an eight-byte (64bit) unsigned integer from a read-stream.<br />
* [[Stream Skip | '''Stream [ Skip ]''' ]] <br/> Skip a number of bytes. (1.7.2)<br />
* [[stream skipwhitespace | '''Stream [ SkipWhitespace ]''' ]] <br/> Skip all whiteSpace (blanks, tabs and linebreaks).<br />
<br />
=== Socket Streams ===<br />
* [[ Socket Connect | '''Socket [ Connect ]''' ]] <br/> Create a new TCP connection to a port on a host. (1.7.1)<br />
* [[ Socket Wait For Connection | '''Socket [ Wait For Connection ]''' ]] <br/> Listen on a TCP socket identified by its port number. (1.7.1)<br />
<br />
===Internal Streams ===<br />
* [[ Stream reading from string | '''Stream [ Reading from String ] ''' ]] <br/> Create a stream for reading characters from a String. (1.8.1)<br />
* [[ Stream writing into string | '''Stream [ Writing into String ] ''' ]] <br/> Create a stream for writing characters. (1.8.1)<br />
* [[ Stream collected contents | '''Stream [ Collected Contents ]''' ]] <br/> Get a writeStream's collected contents.(1.8.1)<br />
<br />
=== Stream Writing===<br />
* [[stream writeline | '''Stream [ WriteLine ]''' ]] <br/> Write a text-line to a write-stream.<br />
* [[stream writestring | '''Stream [ WriteString ]''' ]] <br/> Write a string to a write-stream.<br />
* [[stream writebytes | '''Stream [ WriteBytes ]''' ]] <br/> Write a number of bytes to a write-stream.<br />
* [[stream writebyte | '''Stream [ WriteByte ]''' ]] <br/> Write a single byte to a write-stream.<br />
* [[stream writeint16 | '''Stream [ WriteInt16 ]''' ]] <br/> Write an int16 to a write-stream.<br />
* [[stream writeint32 | '''Stream [ WriteInt32 ]''' ]] <br/> Write an int32 to a write-stream.<br />
* [[stream writeint64 | '''Stream [ WriteInt64 ]''' ]] <br/> Write an int64 to a write-stream.<br />
* [[stream nl | '''Stream [ NL ]''' ]] <br/> Write a newline character to the writeStream.<br />
* [[stream cr | '''Stream [ CR ]''' ]] <br/> Write a return character to the writeStream.<br />
* [[stream crnl | '''Stream [ CRNL ]''' ]] <br/> Write a cr-lf sequence to the writeStream.<br />
* [[stream tab | '''Stream [ TAB ]''' ]] <br/> Write a tabulator character to the writeStream.<br />
<br />
== Time & Date ==<br />
<br />
* [[delay seconds | ''' Delay [ Seconds ] ''' ]] <br/> Sleeps for a while (delay).<br />
<br />
* [[delay signal | ''' Delay [ Signal ] ''' ]] <br/> Send in-value to the out pin after a delay.<br />
<br />
* [[delay duration | ''' Delay [ Duration ] ''' ]] <br/> The delay time is given as a timeDuration object.<br />
<br />
* [[delay with dialog | ''' Delay [ with Dialog ] ''' ]] <br/> Send the value of inValue to outValue after delayMilliseconds milliseconds.<br />
<br />
* [[delay basic | ''' Delay [ Basic ] ''' ]] <br/> A private helper for the Delay Action.<br />
<br />
* [[time gettimestamp | ''' Time [ GetTimestamp ] ''' ]] <br/> Get the current time and date (a timeStamp).<br />
<br />
* [[time gettime | ''' Time [ GetTime ] ''' ]] <br/> Get the current time of day.<br />
<br />
* [[time deltatime | ''' Time [ DeltaTime ] ''' ]] <br/> Returns the duration between two timestamps as a TimeDuration.<br />
<br />
* [[time add seconds | ''' Time [ Add seconds] ''' ]] <br/> Add some seconds to a DateTime (timeStamp).<br />
<br />
* [[time add minutes | ''' Time [ Add minutes ] ''' ]] <br/> Add some minutes to a DateTime (timeStamp).<br />
<br />
* [[time add hours | ''' Time [ Add hours ] ''' ]] <br/> Add some hours to a DateTime (timeStamp).<br />
<br />
* [[time add duration | ''' Time [ Add Duration ] ''' ]] <br/> Add some timeDuration to a DateTime (timeStamp).<br />
<br />
* [[time substracttime | ''' Time [ Substract Time ] ''' ]] <br/> Substract two TimeStamps and returns an integer-value in seconds.<br />
<br />
* [[time substracttime-delta | ''' Time [ Substract Time Delta in MS ] ''' ]] <br/> Substract two TimeStamps and returns an integer-value in milliseconds.<br />
<br />
* [[time substractduration | ''' Time [ Substract Duration ] ''' ]] <br/> Substract a predefined timeduration in seconds from a DateTime.<br />
<br />
* [[time computeduration | ''' Time [ Compute Duration ] ''' ]] <br/> Returns delta of two DateTimes in TimeDuration.<br />
<br />
* [[time tostring | ''' Time [ ToString ] ''' ]] <br/> Convert to String using an optional format string.<br />
<br />
* [[time to iso8601 format string | ''' Time [ To ISO8601 Format String] ''' ]] <br/> Convert to String to the ISO8601 format<br />
<br />
* [[time to rfc1123 format string | ''' Time [ To RFC1123 Format String] ''' ]] <br/> Convert to String to the RFC1123 format<br />
<br />
* [[time to generalized format string | ''' Time [ To Generalized Format String ] ''' ]] <br/> Convert to String to the universal generalized format (includes timezone information)<br />
<br />
* [[time from iso8601 format string | ''' Time [ From ISO8601 Format String] ''' ]] <br/> Convert a String in ISO8601 format into a TimeAndDate<br />
<br />
* [[time from generalized format string | ''' Time [ From Generalized Format String ] ''' ]] <br/> Convert a String in universal generalized format into a TimeAndDate<br />
<br />
* [[time gethour | ''' Time [ GetHour ] ''' ]] <br/> Get a timestamp's hour (0..23)<br />
<br />
* [[time getminute | ''' Time [ GetMinute ] ''' ]] <br/> Get a timestamp's minute (0..59)<br />
<br />
* [[time getsecond | ''' Time [ GetSecond ] ''' ]] <br/> Get a timestamp's second (0..59)<br />
<br />
* [[time today | ''' Time [ Today ] ''' ]] <br/> Get the current timestamp.<br />
<br />
* [[date getyear | ''' Date [ GetYear ] ''' ]] <br/> Get a timestamp's year (2007, 2008,...).<br />
<br />
* [[date getmonth | ''' Date [ GetMonth ] ''' ]] <br/> Get a timestamp's month (1..12).<br />
<br />
* [[date getday | ''' Date [ GetDay ] ''' ]] <br/> Get a timestamp's day (1..31).<br />
<br />
* [[date getweekday | ''' Date [ GetWeekDay ] ''' ]] <br/> Get a timestamp's weekday (1..7) 1==monday; 7==sunday<br />
<br />
* [[date getdayinyear | ''' Date [ GetDayInYear ] ''' ]] <br/> Get a timestamp's day in year (1..365/366)<br />
<br />
* [[date getnameofday | ''' Date [ GetNameOfDay] ''' ]] <br/> Get a timestamp's weekday name in the system language as a string.<br />
<br />
* [[date getdaysinmonth | ''' Date [ GetDaysInMonth] ''' ]] <br/> Get the number of days in the month which is represented by the given timestamp (29, 30 or 31).<br />
<br />
* [[date getdaysinyear | ''' Date [ GetDaysInYear] ''' ]] <br/> Get the number of days in the year which is represented by the given timestamp (365 or 366).<br />
<br />
* [[date getdaysleftinmonth | ''' Date [ GetDaysLeftInMonth] ''' ]] <br/> Get the number of days which are left in the month which is represented by the given timestamp.<br />
<br />
* [[date getdaysleftinyear | ''' Date [ GetDaysLeftInYear] ''' ]] <br/> Get the number of days which are left in the year which is represented by the given timestamp.<br />
<br />
* [[ timeduration| ''' Timeduration [ Sum ] ''' ]] <br/> Add two timeDurations.<br />
<br />
* [[ timeduration| ''' Timeduration [ Difference ] ''' ]] <br/> Substract two timeDurations.<br />
<br />
* [[ timeduration| ''' Timeduration [ Scale ] ''' ]] <br/> Scale a timeDuration. <br />
<br />
* [[ timeduration| ''' Timeduration [ To Seconds ] ''' ]] <br/> Scale a timeDuration.<br />
<br />
== Tools ==<br />
<br />
* [[ windows open document | ''' Windows [ Open Document ] ''' ]] <br/>Ask the Windows shell to open a document. Will start the application that is associated with the file type (1.9.1).<br />
<br />
== Type Conversion ==<br />
<br />
* [[ convert any-to-printed-string | ''' Convert [ Any To PrintedString ] ''' ]] <br/> Convert the value of the inputString to its printed string-representation.<br />
<br />
* [[ convert any-to-string | ''' Convert [ Any To String ] ''' ]] <br/> Convert the value of the inputString to its string-representation<br />
<br />
* [[ convert any-to-paddedstring | ''' Convert [ Any To PaddedString ] ''' ]] <br/> Convert the value of the input to a right-padded string-representation<br />
<br />
* [[ convert any-to-leftpadded-string | ''' Convert [ Any To LeftPaddedString ] ''' ]] <br/> Convert the value of the input to a left-padded string-representation<br />
<br />
* [[ convert integer-to-radix-string | ''' Convert [ Integer To RadixString ] ''' ]] <br/> Convert the value of a number to a radix-string (i.e. hex, octal, binary etc.)<br />
<br />
* [[ convert number-to-float | ''' Convert [ Number To Float ] ''' ]] <br/> Convert the value of a number to a float.<br />
<br />
* [[ convert collection-to-orderedcollection | ''' Convert [ Collection To OrderedCollection ] ''' ]] <br> Convert a string to a string-collection.<br />
<br />
* [[ convert stringcollection-to-strings | ''' Convert [ StringCollection to Strings ] ''' ]] <br> Read a string-collection from the input and write each line separately to the output. <br />
<br />
* [[ convert stringcollection-to-strings | ''' Convert [ StringCollection to String ] ''' ]] <br> Convert a collection of strings to a string.<br />
<br />
* [[ convert string-to-url | ''' Convert [ String To URL ] ''' ]] <br/> Convert a string to an URL-Object<br />
<br />
* [[ convert string-to-uuid | ''' Convert [ String To UUID ] ''' ]] <br/> Convert a string to a UUID-Object (1.7.1)<br />
<br />
* [[ convert string-to-timeduration | ''' Convert [ String To TimeDuration] ''' ]] <br/> Convert a string to a TimeDuration-Object (1.7.1)<br />
<br />
* [[ convert string-to-filename | ''' Convert [String To Filename ] ''' ]] <br> Convert the value of a string to a filename.<br />
<br />
* [[ convert string-to-string-collection | ''' Convert [ String To StringCollection ] ''' ]] <br> Convert a string to a collection of strings.<br />
<br />
* [[ convert string-to-number | ''' Convert [ String To Number ] ''' ]] <br/> Convert a string to a number<br />
<br />
* [[ convert string-to-bytearray | ''' Convert [ String To ByteArray ] ''' ]] <br/> Convert a string to a byteArray (1.7.2)<br />
<br />
* [[ convert bytearray-to-string | ''' Convert [ ByteArray To String ] ''' ]] <br/> Convert a bytearray to a string (1.7.2)<br />
<br />
* [[ convert radixstring-to-integer | ''' Convert [ RadixString To Integer ] ''' ]] <br/> Convert the value of the inputString to a number. The input may be in any base (i.e. hex, octal, binary etc.)<br />
<br />
* [[ cast any-to-any | ''' Cast [ Any To Any ] ''' ]] <br/> Can be inserted between type-incompatible pins. Does no real conversion.<br />
<br />
* [[ cast any-to-any | ''' Cast [ Any To Any with Check ] ''' ]] <br/> Can be inserted between type-incompatible pins. This block reports an error, if the values are incompatible.<br />
<br />
* [[ cast string-to-any | ''' Cast [ String To Any ] ''' ]] <br/> Convert a string-input to an any-output. Actually, no conversion is done here, this is a simple type cast.<br />
<br />
== Variables ==<br />
<br />
* [[ environment get-by-name | ''' Environment [ Get by Name ]''' ]] <br/> Get a value from a surrounding expecco environment.<br />
<br />
* [[ environment set-by-name | ''' Environment [ Set by Name ]''' ]] <br/> Set an Environment-variable.<br />
<br />
* [[ environment clear_by_name | ''' Environment [ Clear by Name ]''' ]] <br/> Clear (unset) an environment variable.<br />
<br />
* [[ environment set variable | ''' Environment [ Set Variable ]''' ]]<br/> Set an Environment-variable (1.7.1).<br />
<br />
* [[ environment create-with-name | ''' Environment [ Create with Name ]''' ]]<br/> Create a new environment variable in the containing block's environment (1.7.1).<br />
<br />
* [[ environment create-with-name-and-value | ''' Environment [ Create with Name and Value ]''' ]]<br/> Create a new environment variable in the containing block's environment (1.8.0).<br />
<br />
* [[ environment create-in-executor-environment | ''' Environment [ Create in Executor Environment ]''' ]]<br/> Create a new environment variable in the executor's environment (1.8.0).<br />
<br />
* [[ environment remove-by-name | ''' Environment [ Remove by Name ]''' ]]<br/> Remove an environment variable from the containing block's environment (1.7.1).<br />
<br />
* [[ Environment_watch_by_name_for_changes | ''' Environment [ Watch by Name for Changes ]''' ]]<br/> Watch a variable (1.7.1).<br />
<br />
* [[ Environment_wait_by_name_for_changes | ''' Environment [ Wait by Name for Changes ]''' ]]<br/> Wait for a variable to change (1.7.1).<br />
<br />
* [[ Environment_watch_variable_for_changes | ''' Environment [ Watch Variable for Changes ]''' ]]<br/> Watch the variable from which my input is frozen. (1.7.1).<br />
<br />
* [[ Environment_wait_for_variable_to_change | ''' Environment [ Wait for Variable to Change ]''' ]]<br/> Wait for the variable from which my input is frozen, to change (1.7.1).<br />
<br />
* [[ environment Initialize Project Environment | ''' Environment [ Initialize Project Environment ]''' ]]<br/> Reinitialize all project variables (1.7.2).<br />
<br />
<br />
<br />
{{noprint| 1=<br />
<br />
Back to [[Online Documentation#Library_and_Plugin_Overview|Online Documentation]]<br />
<br />
Go to [[Release Notes expecco|Release Notes]]<br />
}}</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Hauptseite&diff=10540Hauptseite2018-02-12T17:41:17Z<p>Mawalch: </p>
<hr />
<div><h2>expecco</h2><br />
<div style="display:flex; flex-wrap:wrap; padding:0; white-space:nowrap"><br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Icon_Landingpage.png|30px]]</span><span style="padding:0 1em">Für Einsteiger</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[Was ist expecco?]]</li><br />
<li>[[Glossary|Begriffserklärung]]</li><br />
<li>[[Einsteiger Tutorials]]</li><br />
<li>[[expecco UI]]</li><br />
<li>[[FAQ]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Icon_Landingpage5.png|30px]]</span><span style="padding:0 1em">Installation</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[Installation]]</li><br />
<li>[[Personal Settings|Persönliche&nbsp;Einstellungen]]</li><br />
<li>[[Configuration & Setup|Konfiguration]]</li><br />
<li>[[Anbindung expecco ALM]]</li><br />
<li>[[Spezifische Anpassung]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Icon_Landingpage4.png|30px]]</span><span style="padding:0 1em">Werkzeuge</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[Debugger]]</li><br />
<li>[[Editoren]]</li><br />
<li>[[API von Elementaraktionen]]</li><br />
<li>[[Standard Libraries/Bibliotheken]]</li><br />
<li>[[Weitere Werkzeuge]]</li><br />
<li>[[Weitere Funktionen]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Icon_Landingpage6.png|30px]]</span><span style="padding:0 1em">Reportgenerierung</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[Report Generation|Reportgenerierung]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Erweiterung_plugin.png|30px]]</span><span style="padding:0 1em">Erweiterungen (Plugins)</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[Schnittstellen zum SUT]]</li><br />
<li>[[GUI Testing]]</li><br />
<li>[[Code Ausführung]]</li><br />
<li>[[Daten/Nachrichten/Dokument Formate]]</li><br />
<li>[[Unterstützung der Tests]]</li><br />
<li>[[QM Schnittstellen]]</li><br />
<li>[[Import/Export von Spezifikationen]]</li><br />
<li>[[Databases]]</li><br />
<li>[[API]]</li><br />
<li>[[NoSQL]]</li><br />
<li>[[Sonstige Plugins]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Icon_Landingpage3.png|30px]]</span><span style="padding:0 1em">Elemente der Testsuite</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[Tree Elements|Tree Elemente]]</li><br />
<li>[[Folder Element|Ordner]]</li><br />
<li>[[Testplan Element]]</li><br />
<li>[[Aktionen/Aktionsblöcke]]</li><br />
<li>[[Datatype Element|Datentyp Element]]</li><br />
<li>[[Inventory Element]]</li><br />
<li>[[Skill Element]]</li><br />
<li>[[Resource Element|Ressource Element]]</li><br />
<li>[[Attachment Element|Anhänge]]</li><br />
<li>[[ReportTemplate Element|Report Templates]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Diagramm.png|30px]]</span><span style="padding:0 1em">Diagramm - Elemente</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[DiagramElements-Step|Schritt]]</li><br />
<li>[[Pins (Ein - Ausgänge)]]</li><br />
<li>[[Code Ausführung]]</li><br />
<li>[[DiagramElements-Connection|Verbindung]]</li><br />
<li>[[DiagramElements-Pin|Pin Beschreibung]]</li><br />
<li>[[DiagramElements-Annotation|Notiz]]</li><br />
<li>[[DiagramElements-Probe|Messfühler]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Refresh.png|30px]]</span><span style="padding:0 1em">Sonstiges</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[expecco Mobile Remote App]]</li><br />
<li>[[Release Notes 2.x]]</li><br />
<li>[[Release Notes 1.x]]</li><br />
<li>[[Future releases expecco|Zukünftige Releases]]</li><br />
<li>[[Smalltalk]]</li><br />
</ul><br />
</div><br />
</div><br />
<br />
<br />
<h2 style="clear:left">expecco ALM</h2><br />
<br />
<div style="display:flex; flex-wrap:wrap; padding:0; white-space:nowrap"><br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Sonstiges-Info.png|30px]]</span><span style="padding:0 1em">Allgemein</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[Was ist expecco ALM?]]</li><br />
<li>[[Anbindung expecco ALM]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Icon_Landingpage5.png|30px]]</span><span style="padding:0 1em">Installation/Einrichten</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[expecco ALM Installation|Installation]]</li><br />
<li>[[expecco ALM Einrichten Vorgehensweise|expecco ALM Einrichten]]</li><br />
<li>[[... |Benutzer Einrichten (*empty)]]</li><br />
<li>[[... |Projekt Einrichten (*empty)]]</li><br />
<li>[[... |Workflow Einrichten (*empty)]]</li><br />
<li>[[Einstellungen|Einstellungen (*empty)]]</li><br />
</ul><br />
</div><br />
<br />
<div style="background-color:#ecf0fe; margin:12px 8px 0 0; flex:1 0 auto"><br />
<br />
<span style="padding-left:0.6em">[[Datei:Refresh.png|30px]]</span><span style="padding:0 1em">Sonstiges</span><hr><br />
<br />
<ul style="font-size:0.8em; padding:0.7em 1em 1em 2.4em"><br />
<li>[[expecco ALM App]]</li><br />
<li>[[Lizenzserver expecco ALM]]</li><br />
<li>[[Tutorials expecco ALM|Tutorials (*empty)]]</li><br />
<li>[[expecco ALM Release Notes|Release Notes]]</li><br />
<li>[[FAQ]]</li><br />
</ul><br />
</div><br />
</div></div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Settings_WindowsAutomationGUITestPluginSettings&diff=10539Settings WindowsAutomationGUITestPluginSettings2018-02-12T17:06:36Z<p>Mawalch: Weiterleitung nach Settings WindowsAutomationSettings/en erstellt</p>
<hr />
<div>#REDIRECT[[Settings WindowsAutomationSettings/en]]<br />
<br />
[[Category:Temporary Short Redirect]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Settings_WindowsAutomationGUITestPluginSettings/en&diff=10538Settings WindowsAutomationGUITestPluginSettings/en2018-02-12T17:05:37Z<p>Mawalch: Weiterleitung nach Settings WindowsAutomationSettings/en erstellt</p>
<hr />
<div>#REDIRECT[[Settings WindowsAutomationSettings/en]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Settings_PluginSettings/en&diff=10537Settings PluginSettings/en2018-02-12T17:05:11Z<p>Mawalch: </p>
<hr />
<div>== Plugin Settings ==<br />
Expecco supports extensions called plugins.<br />
These can be loaded and unloaded dynamically using this plugin settings dialog.<br />
Plugins are provided by eXept or third party sources.<br />
For more information, please refer to the<br />
[[:Category:Plugins|"Plugins Documentation"]] or the documentation as provided with the plugin.<br />
<br />
=== Available Plugins and Extensions ===<br />
At the time of writing of this document, the following plugins and extensions<br />
are available or being developed by eXept:<br />
<br />
* [[Settings BPELImportPluginSettings/en|Settings BPELImportPluginSettings]]<br />
* [[Settings DLLCallGeneratorPluginSettings/en|Settings DLLCallGeneratorPluginSettings]]<br />
* [[Settings DotNETBridgeSettings/en|Settings DotNETBridgePluginSettings]]<br />
* [[Settings FreemindImportPluginSettings/en|Settings FreemindImportPluginSettings]]<br />
* [[Settings GUITestPlatformSettings/en|Settings GUITestPlatformSettings]]<br />
* [[Settings GembirdPluginSettings/en|Settings GembirdPluginSettings]]<br />
* [[Settings JavaBridgePluginSettings/en|Settings JavaBridgePluginSettings]]<br />
* [[Settings JavaJarImportPluginSettings/en|Settings JavaJarImportPluginSettings]]<br />
* [[Settings JavaSwingSettings/en|Settings JavaSwingSettings]]<br />
* [[Settings JiraInterfacePluginSettings/en|Settings JiraInterfacePluginSettings]]<br />
* [[Settings ManualTestImport1PluginSettings/en|Settings ManualTestImport1PluginSettings]]<br />
* [[Settings ManualTestImport2PluginSettings/en|Settings ManualTestImport2PluginSettings]]<br />
* [[Settings MobileTestingSettings/en|Settings MobileTestingPluginSettings]]<br />
* [[Settings PolarionInterfacePluginSettings/en|Settings PolarionInterfacePluginSettings]]<br />
* [[Settings PoloniumGUITestPluginSettings/en|Settings PoloniumGUITestPluginSettings]]<br />
* [[Settings QCInterfacePluginSettings/en|Settings QCInterfacePluginSettings]]<br />
* [[Settings QtGUITestPluginSettings/en|Settings QtGUITestPluginSettings]]<br />
* [[Settings SeleniumSettings/en|Settings SeleniumSettings]]<br />
* [[Settings WindowsAutomationSettings/en|Settings WindowsAutomationSettings]]<br />
* [[Settings WSDLImportPluginSettings/en|Settings WSDLImportPluginSettings]]<br />
* [[Settings XMIImportPluginSettings/en|Settings XMIImportPluginSettings]]<br />
* [[Settings XPDLImportPluginSettings/en|Settings XPDLImportPluginSettings]]<br />
<br />
=== Plugin Overview ===<br />
;[[Settings BPELImportPluginSettings/en|BPEL Import Extension]]<br />
: Imports BPEL diagrams<br />
<br />
;[[Settings DLLCallGeneratorPluginSettings/en|DLL Callgenerator Extension]]<br />
: Generates function blocks for entries in a dynamic link library.<br />
<br />
;[[Settings DotNETBridgeSettings/en|DotNET Bridge Extension]]<br />
:The dotNET bridge extension allows for a dotNET (CLR) program to be executed as a slave under the control of expecco. You can access globals, classes, instantiated objects, threads and GUI components of the program, and define arbitrary elementary blocks to manipulate them. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings FreemindImportPluginSettings/en|Freemind-MM Import Extension]]<br />
: Imports FreeMind Mindmap diagrams<br />
<br />
;[[Settings GembirdPluginSettings/en|Gembird Power Manager Control Plugin]]<br />
: This plugin controls a set of lamps (red, green, yellow) via a LAN-controlled power control unit (gembird). This can be used as an optical indicator for running tests (yellow), and the tests outcome (red or green).<br />
<br />
;[[Settings JavaBridgePluginSettings/en|Java Bridge Extension]]<br />
: Similar in function to the dotNET bridge, this extension allows for a Java program to be executed as a slave under the control of expecco. You can access globals, classes, instantiated objects, threads and GUI components of the program, and define arbitrary elementary blocks to manipulate them. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings JavaJARImportPluginSettings/en|Java JAR Import Extension]]<br />
: Similar in function to the DLL call generator plugin, this extension allows for a JAR file containing Java classes to be scanned and elementary blocks to be generated which call static or member functions.<br />
<br />
;[[Settings JavaSwingSettings/en|JavaSwing GUI Test Extension]]<br />
: Provides a visualization of the widget hierarchy of a Java+Swing application. GUI elements can be searched, inspected and validation actions can be added interactively to a test suite's activity diagram. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings JavaSWTGUITestPluginSettings/en|JavaSWT GUI Test Extension]]<br />
: Provides a visualization of the widget hierarchy of a Java+SWT application. GUI elements can be searched, inspected and validation actions can be added interactively to a test suite's activity diagram. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings JiraInterfacePluginSettings/en|JIRA Testresult Reporting]]<br />
: This plugin creates a link between an expecco test case and an issue in a JIRA database. The issue can be automatically closed/reopened, whenever the test case is executed.<br />
<br />
;[[Settings ManualTestImport1PluginSettings/en|Manual Test Import]]<br />
: This plugin imports test specifications for manual tests. These must be present as word (OpenOffice) document with a particular (tabular) format. After the import, a manual test GUI can be used to guide the tester through the test cases, or the resulting test plan can be used as a template for partial or full automation.<br />
<br />
;[[Settings MobileTestingSettings/en|Mobile Testing]]<br />
: Similar to the other GUI Test extensions, this allows for an Android or iOS application's widget hierarchy to be inspected, manipulated and checked. The application may run both on real or emulated hardware. Multiple devices and their interaction may be handled and controlled in a single test suite.<br />
<br />
;[[Settings PolarionInterfacePluginSettings/en|Polarion Interface]]<br />
: This plugin allows for test-suites to be up-/downloaded to/from a Polarion QM server, to fetch and execute Polarion test runs, and to update a tests state to PASS/FAIL, whenever the test case is executed. Also, Polarion itself is extended for the definition and execution of expecco tests.<br />
<br />
;[[Settings PoloniumGUITestPluginSettings/en|Polonium ST/X Application''' Test Plugin]]<br />
: The Polonium plugin adds an interface to the Polonium ST/X GUI test framework. Polonium does for an ST/X fat-client application what Selenium does for a browser based web application. It allows for capture/replay of ST/X GUI application sessions and the validation of a GUI's window contents.<br />
<br />
;[[Settings QtGUITestPluginSettings/en|Qt GUI Test Extension]]<br />
: Similar to the JavaSwing GUI Test extension, this allows for a Qt (-> Trolltech) application's widget hierarchy to be inspected, manipulated and checked. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings QCInterfacePluginSettings/en|Quality Center (QC) Interface]]<br />
: This plugin allows for test-suites to be up-/downloaded to/from a Quality-Center server, to fetch and execute QC test sets, and to update a tests state to PASS/FAIL, whenever the test case is executed.<br />
<br />
;[[Settings SeleniumSettings/en|Webtest Plugin (Selenium Interface)]]<br />
: The Webtest plugin adds an interface to the Selenium Webtest framework. Selenium allows for capture/replay of web sessions and the validation of a web pages' contents. This plugin contains an import feature, which converts captured selenium sessions into an activity diagram. Also, a library consisting of web-page activities is included. Together, they allow for a recorded web session to be enhanced, refactored, reused or parametrized like any ordinary expecco activity diagram.<br />
<br />
:Beside many other possible uses, two extra functionalities of this plugin add much to the value of the expecco product:<br />
:* recorded web sessions can be augmented by semantic checks in the system under test. Especially the real effect of a web-transaction can be checked against the back-end of a web application.<br />
:* by feeding a recorded session's parameters through either a generator-block, or by reading a CSV-file or a database, web-sessions can be parametrized. This can even be done dynamically on the fly, depending upon previous response data. For example, a set of boundary values can be read from a file and fed as input parameter sets to a prerecorded web session, or the output of a web page can be analyzed, transformed and used as input to another session or for a follow up test case.<br />
<br />
;[[Settings WindowsAutomationSettings/en|Windows Automation Extension]]<br />
: Similar to the other GUI Test extensions, this allows for Microsoft MFC/Forms application's widget hierarchies to be inspected, manipulated and checked. Multiple applications and their interaction may be handled and controlled in a single test suite. The target applications may execute both on the local or on remote hosts.<br />
<br />
;[[Settings WSDLImportPluginSettings/en|WSDL Import Extension]]<br />
: Imports WSDL service description and automatically generates libraries containing types and actions to access these operations.<br />
<br />
;[[Settings XMIImportPluginSettings/en|XMI Import / Export Extension]]<br />
: Import/Export of XMI UML diagrams<br />
<br />
;[[Settings XPDLImportPluginSettings/en|XPDL Import Extension]]<br />
: Imports XPDL diagrams<br />
<br />
[[Category:Settings]]</div>Mawalchhttps://doc.expecco.de/w2.x/index.php?title=Kategorie:Tree_Elements/en&diff=10536Kategorie:Tree Elements/en2018-02-12T16:59:20Z<p>Mawalch: </p>
<hr />
<div>== Introduction ==<br />
All elements of a testsuite are organized as a hierarchical tree and are referred to as<br />
"Tree Elements" of a [[TestSuite Element|test suite]]. They are displayed and managed in the so-called project- or [[Navigation Tree/en|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.<br />
[[Bild:Tree_Elements.png|thumb|164px|All tree elements]]<br />
<br />
For traditional reasons, the "Test Suite" is also sometimes referred to as "Test Project" or "Project" in this document.<br />
<br />
== Common Attributes of all Tree Items ==<br />
<br />
==== Name ====<br />
<br />
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.<br />
<br />
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.<br />
Both are set via the [[Settings_LanguageSettings | "Settings" dialog]] and are stored in your personal settings file.<br />
<br />
==== IDs ====<br />
<br />
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.<br />
<br />
The "''Version-ID''" is used to quickly detect identical elements (for example, when merging projects from different files).<br />
<br />
The "''Functional-ID''" is used when reimporting libraries; i.e. to identify which blocks should be automatically replaced by newer versions.<br />
<br />
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.<br />
<br />
===== WARNING =====<br />
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).<br />
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.<br />
<br />
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.<br />
<br />
However:<br />
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.<br />
<br />
==== Tags ====<br />
<br />
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).<br />
<br />
Some tags affect the behaviour of the editor. E.g. elements tagged as "obsolete" will not be presented in dialogs to insert new steps.<br />
<br />
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.<br />
<br />
==== Tagged Values ====<br />
<br />
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).<br />
<br />
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.<br />
<br />
== Test Items ==<br />
<br />
==== [[Testplan Element|Testplan]] ====<br />
<br />
A testplan contains a list if test cases, also called "test case items" or "test items" for short.<br />
A test case item can be either an action (i.e. a block), or another testplan.<br />
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.<br />
<br />
Please navigate to "[[Testplan Element|Testplan]]" for more detail on elementary blocks.<br />
<br />
==== [[Performance Test Element|Performancetest]] ====<br />
A performance test consists of three types of items:<br />
* load generators<br />
* measuring blocks<br />
* test actions<br />
Together, these generate load on the system under test and measure its behavior during the test action execution.<br />
Support for performance tests is being developed and an as-yet unpublished feature of expecco.<br />
<br />
== Libraries ==<br />
<br />
Libraries are collections of blocks. They are nested in the "Imports" node.<br />
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.<br />
However, you can also create your own project-specific libraries. Or provide them as a supplier<br />
to a third party, or acquire them from a third party.<br />
<br />
Libraries can contain any type of element, including datatypes, attachments, elementary and compound blocks. Libraries can also use and import additional libraries.<br />
<br />
Already included in all releases of expecco are the following libraries:<br />
* [[Standard Library]]<br />
* [[Selenium Library]]<br />
<br />
Upon request, other libraries are available. For example:<br />
* Interfaces to specific rich-client GUIs (Qt, Java SWT, Java Swing, Java FX, Android, Windows Mobile, iOS, ST/X, Ranorex)<br />
* Interfaces to specific applications like SAP, Siebel,...<br />
* Interfaces to QM systems, like expecco ALM, Polarion, HP-Quality Center<br />
* Interfaces to Bugtracking systems like JIRA<br />
* Bridges to manipulate and access internals of the System Under Test, if written in Java or a .NET language.<br />
* Databases<br />
* Webservices<br />
* CAN/MOST<br />
* GPIB, VISA, OPC<br />
* Importers for test-description/activity diagrams in various formats (Excel, Word, Enterprise Architect, MindMap)<br />
* Various Document and EDI formats (EDIFACT, IDoc, PDF, XML, IDL, etc)<br />
<!--<br />
==== [[Library-Create|Create a library]] ====<br />
<br />
==== [[Library-Import|Import a library]] ====--><br />
<br />
==== [[Library-ReImport|Reimporting a Library]] ====<br />
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.<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== [[Virtual Library]] ====<br />
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).<br />
<br />
== Action Blocks ==<br />
<br />
==== [[ElementaryBlock_Element|Elementary Block]] ====<br />
[[ElementaryBlock_Element|Elementary blocks]] describe actions which are implemented as low-level primitives. These are either implemented in a builtin scripting programming language (such as JavaScript, Smalltalk), a scripting language running in the System Under Test or on a third machine (Groovy for Java, C# and Python for DotNET), or an external script engine (for example, Shell, Batch, Perl or Ruby) or by calling an existing function written in any language either in a DLL (shared library) or via a remote procedure call (SOAP, XML-RPC, REST etc.).<br />
<br />
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.<br />
<br />
Please navigate to "[[ElementaryBlock_Element|Elementary Block]]" for more detail on elementary blocks.<br />
<br />
==== [[CompoundBlock_Element|Compound Block]] ====<br />
<br />
A [[CompoundBlock_Element|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.<br />
<br />
Please navigate to "[[CompoundBlock_Element | Compound Block]]" for more detail.<br />
<br />
==== [[KeywordBlock Element/en | Keyword Action Blocks]] ====<br />
<br />
Simple sequential actions can also be defined in a tabular keyword-action representation.<br />
This presents actions to be performed as a table with input/output values.<br />
Of course, sequential execution is a subset of the more general execution structure in a compound action,<br />
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.<br />
Although they cannot represent parallel execution, branches and loops, many beginners prefer the simpler user interface provided by keyword actions.<br />
<br />
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.<br />
<br />
Please navigate to "[[KeywordBlock Element/en | Keyword Action Blocks]]" for more detail.<br />
<br />
==== [[VirtualBlock_Element|Virtual Block]] ====<br />
<br />
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.<br />
<br />
The determination of which concrete block to use can be done via two mechanisms:<br />
* by importing a concrete library for a virtual library<br />
* by specifying explicitly which concrete action to use<br />
<br />
With the first strategy, you have to import a concrete library, which contains concrete implementations for all virtual blocks in the virtual library.<br />
<br />
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.<br />
<br />
Please navigate to "[[VirtualBlock_Element|Virtual Block]]" for more detail.<br />
<br />
==== [[TestDataGeneratorBlock_Element|Test Data Generator Block]] ====<br />
<br />
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.<br />
<br />
Please navigate to "[[TestDataGeneratorBlock_Element|Test Data Generator Block]]" for more detail.<br />
<br />
==== [[GUIBlock Element]] ====<br />
<br />
A compound GUI block is used to model non-modal user interfaces.<br />
The action blocks contain a UI and a compound network, to implement more complex, stateful user interfaces.<br />
Their use is described in a separate document.<br />
<br />
Please navigate to "[[GUIBlock Element]]" for more detail.<br />
<br />
==== [[Elementary GUI Block]] ====<br />
<br />
An elementary GUI block is used to model modal (blocking) user interfaces.<br />
This is an action block which - when executed - opens a GUI in a modal dialog.<br />
The GUI can be edited to contain arbitrary components (Check boxes, Input fields, Buttons etc.).<br />
When close, the entered values are send to the UI-block's output pins.<br />
<br />
Such elementary GUI blocks are perfect to let the tester enter complex data during execution time.<br />
Notice, that for simple values (strings, numbers, filenames, yes-no questions, etc.), the standard library already contains a number of existing blocks.<br />
<br />
== Management==<br />
<br />
==== [[Datatype Element/en|Datatype]] ====<br />
<br />
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.)<br />
<br />
Please navigate to "[[Datatype Element/en|Datatype]]" for more detail.<br />
<br />
==== [[Resource Element/en|Resource]] ====<br />
<br />
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.<br />
<br />
Please navigate to "[[Resource Element/en|Resource]]" for more detail.<br />
<br>The relation between Skill, Resource and Inventory is demonstrated in an example in the [[Skill Element/en|Skill documentation]].<br />
<br />
==== [[Skill Element/en|Skill]] ====<br />
<br />
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.<br />
<br />
Please navigate to "[[Skill Element/en|Skil]]" for more detail.<br />
<br>The relation between Skill, Resource and Inventory is demonstrated in an example in the [[Skill Element/en|Skill documentation]].<br />
<br />
==== [[Inventory Element/en|Inventory]] ====<br />
<br />
An inventory is a collection of resources.<br />
<br />
Please navigate to "[[Inventory Element/en|Inventory]]" for more detail.<br />
<br>The relation between Skill, Resource and Inventory is demonstrated in an example in the [[Skill Element/en|Skill documentation]].<br />
<br />
== Miscellaneous==<br />
<br />
==== [[Folder_Element | Folder]] ====<br />
<br />
Folder elements are containers for grouping of other elements.<br />
<br />
Please navigate to "[[Folder_Element | Folder]]" for more detail.<br />
<br />
==== [[Attachment Element|Attachment]] ====<br />
<br />
An attachment is used to manage any file together with a test suite.<br />
<br />
Please navigate to "[[Attachment Element|Attachment]]" for more detail.<br />
<br />
==== [[Documentation Element|Documentation]] ====<br />
<br />
Documentation elements can be used to add additional documentation to the test suite.<br />
They are simple text-holding elements, and typically contain instructions from the test developer to the test operator.<br />
<br />
Please navigate to "[[Documentation Element|Documentation]]" for more detail.<br />
<br />
==== [[ReportTemplate Element|Report Template]] ====<br />
<br />
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).<br />
<br />
Please navigate to "[[ReportTemplate Element|Report Template]]" for more detail.</div>Mawalch