A test project corresponds to the Natural application you want to test. It consists of one or more test cases. This document covers the following topics:
See Test Project Configuration Parameters in the Natural Screen Tester Reference Guide for further details regarding all the test project parameters.
In this task, you will create a new Natural Screen Tester test project. Every Natural Screen Tester test project is connected to a host and has a repository containing all the Natural Screen Tester entities. The steps detailed in this task include the basic steps required to create a test project. Advanced configuration is explained under Test Project Configuration Parameters in the Natural Screen Tester Reference Guide.
To create a Natural Screen Tester test project
Before creating a new test project, ensure that Natural Screen Tester server is available and running, and start the Designer. Login to the relevant server or add an additional server as required. See also Natural Screen Tester Designer (Software AG Designer) in the Getting Started documentation.
In the Natural Screen Tester Explorer, right-click on the Natural Screen Tester Server and choose .
Or:
Choose the menu item. The New Project wizard window is
displayed.
Expand the Software AG node and choose test project then click to display the New Natural Screen Tester test project wizard:
Create a New test project wizard is displayed.
Enter a name for the test project and a suitable description.
Select the Initialization mode:
- Automatic
Automatically loaded when the server is started.
- When first accessed
Loaded when first accessed, in other words, when the code that initializes startup is first called (default).
Click . The Select Host screen is displayed. Choose whether to use an existing host or create a new one.
If you choose to define a new host, enter a name for the host and select the relevant type of host. Click . The host connection and conversion parameters are displayed.
It is mandatory to enter the host's name/IP address (IPv4 and IPv6 address formats are supported). Configure the other parameters as required. For details see Host Configuration: Connectivity in the Natural Screen Tester Reference Guide.
Click . The test project is displayed in the Natural Screen Tester Explorer. It is possible to further configure the test project properties by right-clicking on the test project name and selecting . See also Test Project Configuration Parameters in the Natural Screen Tester Reference Guide.
The Test Project Properties dialog box contains additional parameters that can be configured such as the language, process tracing, screen content definitions etc. For details of each node see Test Project Configuration Parameters. To edit a test project's configuration, right-click on the test project's node (in the Natural Screen Tester Explorer) and choose .
Note:
Notice that in the Host name field (in the Host
tab), only hosts of the same type as the configured host are listed.
To delete a test project
Right-click on the test project's node and choose . In addition to deleting the test project it is also possible to determine whether when the host used in this test project is not used in any other test project, you would like to delete the host and also whether you would like to delete the entire test project from the file system.
Reload a test project when there is new data that the test project requires, such as when repository definitions change or when the database file is replaced. Reloading the test project will reload the repository, close all connection pools, stop running connection pools and if the database is synchronized at the end of the reload process will automatically restart the connection pools.
To reload a test project
Right-click on the test project's node and choose Reload Test Project.
It is possible to import:
a complete test project - including the configuration, the test project entities and a trace file - contained in a gxar file
a test project's entities in a gxz file
It is not possible to import entities exported from a higher server version than the current version that you are using.
Important:
As the import process may consume a lot of memory, it is
recommended to restart Natural Screen Tester server after completing the
process.
This section covers the following topics:
When importing a complete Natural Screen Tester test project, you will require a gxar (Natural Screen Tester test project archive) file. This file includes the test project configuration, Natural Screen Tester entities (as a read only gxz file) and a trace file. The gxar file can be imported into Natural Screen Tester in two different methods:
Using the "Hot Deploy" method, the gxar file is simply located and placed in the host-applications directory as the file to be imported.
To import a test project in the "Hot Deploy" method
Open your Windows Explorer.
Locate the relevant gxar file and place it in the host-applications directory of your Natural Screen Tester installation.
In Natural Screen Tester Designer, right-click on the server and choose
In the General tab, determine to load Natural Screen Tester archive test projects. Set the interval to look for updates. This determines how often the Natural Screen Tester server should check to see if the gxar file to use has changed. Once a different gxar file is detected, it will be used.
It is also possible to use the gxar file by reloading the server (right-click on the server and choose Reload).
To import a test project
Right-click on the test project's node and choose . The Import/Replace Test Project wizard is displayed.
Enter a file name, or browse and select the file to import.
Select whether to replace an existing test project (selected by default), or to create a new test project. Enter a name accordingly.
Click . Wait a few minutes while the test project is imported.
To import entities
Right-click on the test project's Root node and choose . The Import Entities wizard is displayed.
Enter a file name, or browse and select the file to import.
Check Do not overwrite existing entities to determine not to overwrite an existing entity with an imported entity of the same name.
Check Do not overwrite existing Connection Information Sets to determine not to overwrite an existing connection information set with a set of the same name.
Notes:
Click . The entities are imported into the test project.
Note:
Clicking Cancel on the Progress Bar dialog box will cause the
process to be stopped and the entities will not be imported.
The Export Wizard allows you to export a test project configuration and its repository residing on various database systems into a standard zip file. This wizard guides you through the steps of exporting data.
Note:
When exporting entities, the
Session Data entity
will always be exported.
To export a test project configuration with/without its entities
Right-click on the test project's node and choose . The Export test project wizard is displayed.
Select whether to export just the test project configuration or the test project configuration together with the entities.
Enter a folder name, or browse and select the target folder.
Check the Export trace file check box to export a trace file. A list of replay (gct) files that are on the server are displayed. Select a file or click to select a local file to copy to the server.
Click . The test project will be exported to the defined folder.
To export entities only
Right-click on the test project's Repository node and choose . The Export Entities wizard is displayed.
Browse and select the target folder and file name where the exported entities are to be placed.
Click . The export process will commence and the entities will be exported to the selected folder.
Note:
The Session
Data entity will always be exported, regardless of the entities
selected to export.
The Trace File feature enables recording a file, which traces the connection communication between the Natural Screen Tester server and the host, for each connection. It is possible to define whether a single trace file will be created, replacing the previously saved file or whether the data will be saved to a new file for every new user session. Identifying the separately saved files is possible by inserting identifying parameters in the file name (the session ID, creation time and/or connection ID). It is highly recommended to create a separate file for each session/connection or creation time. Note that trace files can be created from within the session definition overriding the test project definition. This is recommended as it prevents conflict with other existing sessions.
Note:
Log and trace files can contain sensitive personal data (for example user ID, IP address, etc.).
We recommend you check the different trace opportunities provided by Natural Screen Tester and delete log and trace files
if they are no longer needed.
Natural Screen Tester will not delete these files automatically; this is your responsibility as user. Use the appropriate
tools of the respective operating system.
The trace files can be also defined to be created in folders per Day Month and Year. This is recommended as it prevents conflict with other existing sessions.
The trace files can be compressed to save space on the disc. This is particularly suitable when tracing a large number of files on a regular basis.
When required, you can select to encrypt the trace files.
To record a trace connection file
In the Natural Screen Tester Explorer, right-click on the relevant test project and choose .
Click on the Host>Recording node. See Host Parameters: RecordingconfigParms_host_recording
Check Record terminal sessions (trace files).
Check the Compress (create files in zip format) check box to compress the file. Compressed files will have the suffix .zip.
Check the Encrypt (using server private key) check box to encypt the file. In order to encrypt files, you must first define the encryption key (In the Server properties, General tab). Encrypted files will have the suffix .gctx. A file which is both compressed and encrypted will have the suffix .gctx.zip.
Choose Suppress hidden fields to conceal passwords and hidden fields.
Note:
The "Suppress hidden fields" option is not supported when
recording using Terminal Emulation Proxy.
Provide a name for the file.
Check the relevant check box to determine that a new file will be created for each session/creation time or connection ID. It is possible to add the following parameters to the file name instead of using the check boxes: %u will insert the session ID. %t will insert the creation time stamp of the connection. %c will insert the connection ID.
Browse and select the location of the folder where the files will be stored. Determine whether sub folders will be created for each year/month/day.
Click to save your changes.
See also Test Project Configuration Parameters.
In order to develop, debug and reconstruct specific scenarios, it is possible to replay (GCT) files that have traced the emulation protocol for each user. See Recording Trace Files. In order to replay such files, the test project configuration definitions must indicate that instead of working online with the host, Natural Screen Tester must, when connecting, access and replay the specific file. Note that replay file can be defined from within the session definition overriding the test project definition. This is recommended as it does not conflict with activities of other users.
Note:
Offline sessions support replaying encrypted and/or compressed files.
Refer to Recording Trace Files
for additional details
To define working with offline replay files
In the Natural Screen Tester Explorer, right-click on the relevant test project and choose .
Expand the Host node and select the Offline node.
Check the Work offline check box.
Either enter or browse to select the file name including the full path.
Natural Screen Tester enables a session replayed by a GCT to simulate the host's communication delay or to predefine a time delay to wait before showing the information (this is because generally, the test project is faster when replayed). This is determined in the Simulate host delay field. Available values: No delay, Simulate host, 500- 10000 ms (by default No delay is selected).
Click to save your changes.
See also Test Project Configuration Parameters.
To change the initialization mode of a test project
In the Natural Screen Tester Explorer, right-click on the relevant test project and choose .
Ensure that the General node is selected.
In the Initialization mode field, select the relevant initialization mode:
- When first accessed
Loaded when the code that initializes startup is called.
- Automatic
Loaded when the server is started.
Click to save your changes.
See also Test Project Configuration Parameters.
To set the timeout for idle users
In the Natural Screen Tester Explorer, right-click on the relevant test project and choose .
Select the Host node.
Select whether the session timeout will be unlimited or disconnected after a specific number of seconds.
Click to save your changes.
See also Test Project Configuration Parameters.
It is necessary to use the Flickering of Host Sessions feature when one of the following happens:
In the browser, a blank screen is displayed when navigating between two host screens.
Note:
Refer to Blank Screen Timeout in General Host Parameters for additional information on handling blank screens.
In the browser you are required to submit the Enter key (or any other key) twice in order to navigate to the next host screen.
The initial need for Flicker arises when specific host screens are received 'split' between several buffers of data. Thus Natural Screen Tester Server needs to be informed to wait an additional amount of time for the complete screen to arrive. This additional amount of time is defined (in milliseconds) in the Flicker parameter in the Host node of the test project Properties dialog box. The flicker setting applies to the entire Natural Screen Tester test project, meaning that if the flicker is set to 500ms, after each host transaction the flicker time will be added to the communication time. In other words, the entire test project will be 'slowed down' by the flicker time. Therefore this value should only be set for the entire test project according to the following guidelines:
As a rule of thumb, there is no reason to use the flicker setting in the test project configuration for block mode hosts. Specific 'problematic' screens should be handled using wait conditions, both in navigation paths and in Web test projects. For less specific cases (when a wait condition for a specific screen cannot be used), it is possible to set the flicker setting only for certain actions (using either the path dialog or the Base Object API in Web test projects).
To define the flicker time
Click the relevant test project in the Natural Screen Tester Explorer.
Right-click a test project and choose Open. The test project dialog box is displayed.
In the Host tab enter a value in the Flicker field. Possible values are from 0 to 10000 ms.
Click Apply to save all changes, without closing the dialog box. Click OK to save changes and close the dialog box. You will be required to confirm the change.
See also Test Project Configuration Parameters.
The RPC connections pool is used for holding pre-connected RPC connections. When an RPC connection is required to execute a program, a connection from the pool is used, saving the connection time and executing the program immediately. This feature is available for AS/400 hosts only. This feature is available in SOA test projects only.
To set the RPC pool connections settings
Open the test project Properties dialog box and click on the Host>RPC node.
Choose Use Connections Pool.
Configure the RPC connection parameters. Refer to Test Configuration Host Parameters: RPC for further details regarding the fields in this dialog box.
When required, configure the username and password needed to connect to the AS/400 programs. See also Host Configuration Parameters: RPC.
It is possible to map specific keyboard keys to the Keyboard Mapping tab in the test project Properties dialog box.
To define Keyboard Mappings
Right-click on the relevant test project and choose .
Focus on the Keyboard Mapping tab.
To map one of the existing mappings, locate it in the list of keyboard mappings and ensure that it is marked as Enabled. If it is not enabled, click on the Enable Key hyperlink.
To add a new keyboard mapping, click on the Add Keyboard Mapping hyperlink.
Enter the key combination in the Keyboard field.
Either select the host key from the standard list of host keys or enter a host key in the Host key field. Ensure you place square brackets around the key.
Note:
When using the keyboard keys within the web test project, the
CTRL+N and CTRL+K keys are blocked by default as they cause multiple browser
windows to use the same session (this can be manually set in the
config/gx_keyboardMappings.xml file).
Key combinations defined here may conflict with Eclipse key bindings. When such a conflict occurs, the key combination defined here will be ignored during runtime. To see the list of Eclipse key bindings, open the menu, expand the tab and choose . A key binding which appears in this list, and whose When field is set to "In Windows" or "In Dialogs and Windows" will cause a conflict.
When such a conflict occurs, either redefine the keyboard mapping in Natural Screen Tester, or change the Eclipse key binding. The Eclipse key binding can be changed either by choosing a different option in the When field (the key binding will be disabled and it will not be possible to enable it), or by editing the plugin.xml file of the Natural Screen Tester plug-in (add the new key binding in the org.eclipse.ui.bindings extension point with Natural Screen Tester scheme ID and empty commandId. This way, whenever the Natural Screen Tester key binding scheme is activated, the problematic key bindings will be disabled, but in other schemes the key bindings will be enabled.)
The test project Configuration>Language node enables you to define the language used in the test project as well as direction settings, relevant mainly for right-to-left languages.
To configure RTL language settings
In the Natural Screen Tester Explorer, right-click on the relevant test project and choose .
Select the Language node.
Select the test project's language.
Note:
The following settings are relevant for right-to-left languages.
The option you select is the default setting for all the screens, but can be
changed for a specific screen in the relevant screen, in the Screen Direction
tab.
Set the Screen direction. Relevant for mainframe hosts only. The screen direction of right-to-left languages differs according to the original host settings, and when incorrectly set, can cause the screen to be illegible. In order to correct this, define the suitable screen direction.
Set the Typing direction. Right-to-left languages may display typed-in text in the Display Session View and HTML fields, aligned to the left of the field. In order to display the text aligned to the right, select the right-to-left option.
Set the Tab direction. When pressing the TAB button the cursor moves to the next consecutive field. The direction the cursor moves (moving to the next field to the left or moving to the next field to the right) must be correctly defined in order to preserve the screen logic.
The test project Map view enables viewing a navigation map between screens. Once the navigation option is selected, in the test project Properties, Navigation tab, the test project map will record the navigation steps between the screens. See also Navigation Parameters and Test Project Map.
The Natural Screen Tester repository is an internal database used to hold Natural Screen Tester entities (metadata) such as the Screens, Paths, Connection Pools, Programs and Procedures.
As a Natural Screen Tester user, you may like to divide test projects into folders within your repository, according to the specified interests and needs, such as development teams, sub-test projects etc. The same folder contains different types of entities and sub-folders varying according to each test project. This allows you greater flexibility organizing your entities.
The repository can be read only. It is recommended to use a read-only repository for production.
To set up a read-only repository
Open the test project.
Right-click on the repository node.
Choose Lock Repository (read only)
The Windows definitions are used to correctly identify screens and to open host windows as separate pop-up windows. In the test project Properties it is possible to define the Host Windows per the test project.
When adding a window you are required to select the type of modal windows the host sends. There are two types: Reversed Video or Frame. For test projects that have more than one level of windows (a window within a window), where each level is defined with a different Window Type, be sure to define the windows in the correct order.
Note:
When the host is a Natural UNIX host, this tab is disabled, as the
windows' definitions are included in the Natural-UNIX protocol and do not
require being defined via Natural Screen Tester.
To define windows
Right-click on the relevant test project and choose Properties.
Add a Frame or Reversed Video
Configure the parameters as detailed in Test Project Configuration Parameters: Windows.
Natural Screen Tester test projects are typically developed by more than one user. This can sometimes cause conflicts on the Natural Screen Tester server. Working methodologically and investing time and effort in planning the development and design of the project can help prevent such conflicts. We recommend you divide responsibilities between the developers (such as developers working on specific entity types, or workflows).
Typical conflicting scenarios and outcomes:
More than one developer editing the Test Project Properties: Natural Screen Tester will save the changes of the first developer who saves the changes.
More than one developer editing an entity:
When more than one developer edits the same entity, and one of the developers saves the entity, the other developers receive a message indicating that this entity has been saved by another developer. You are required to determine whether you would like to work on the newly saved entity (and update your editor to reflect the newly saved entity) or to continue working on the outdated editor.
If you choose to continue working on the outdated editor then when trying to save the entity, you will be informed of the name of the user who made the changes and you will be able to decide whether to either:
Overwrite the changes that the other developer has made.
Save the entity with a different name. Note that references that pointed to the original entity will not point to this entity and need to be added manually. References that this entity referred to will be maintained.
Discard the changes that you made.