This topic is a general migration guide for users of WebKing or of SOAtest version 5.x and earlier. Sections include:
This guide is designed to help users of WebKing or of SOAtest version 5.x and earlier get up and running in the latest version of SOAtest as rapidly as possible.
This Migration Guide is meant to be used by users already familiar with SOAtest or WebKing. New users should review the SOAtest Tutorial first.
Since the SOAtest interface has been integrated into the Eclipse framework since version 6.0, it now follows the Eclipse framework hierarchy for managing your test assets. You no longer need to open .tst files one at a time. Instead, you can manage all your .tst files in projects within a workspace.
A workspace corresponds to a directory on the local machine. SOAtest will ask you for the desired location of workspace at startup and will remember that location in future runs. When you start the SOAtest 9.x and later, an Eclipse workspace is automatically created in <user_home_dir>/parasoft/workspace. For instance: /home/username/parasoft/workspace (Linux), C:\Users\username\parasoft\workspace (Windows).
In the following sections, we will go through several ways of creating new projects that may be useful to existing SOAtest or WebKing users. Other ways of creating new projects, (e.g. from a WSDL), can be found in the SOAtest Tutorial.
To ensure that tests can easily be shared across your organization, a designated team member—usually a team lead or manager—must decide which project setup strategy to use. The entire team should then adopt the same strategy.
| In these situations | Use this strategy |
|---|---|
| Your tests are stored in a source control system | Creating Projects from Tests Under Source Control |
| Your tests are NOT stored in a source control system and you want to copy your old tests into a new location on your file system | Copying Tests to a New Location |
| Your tests are NOT stored in a source control system and you want the existing files to remain in the same location on your file system | Leaving Tests in the Original Location |
Once a file is opened within SOAtest 6.0 or later, it is automatically saved in a new format that cannot be opened in earlier versions of SOAtest or WebKing. |
By default, SOAtest 9.x ships with CVS source control support. Support for additional source controls can be added by providing appropriate plugins to Eclipse.
To create a project consisting of test suites that are checked into source control:
.project and .parasoft files into source control. They will be visible in the Navigator view and should be shared by the entire team..metadata folder into source control.We strongly recommend copying the old tests into your new workspace. Doing so will preserve your old tests in a manner analogous to backing up your hard drive. This procedure is explained in Copying Tests to a New Location.
As a second option, you can use the Project from Existing SOAtest or WebKing Test Suites wizard for tests not stored in a source control system. This will cause the original files to appear within your workspace—but it will allow them to remain in the same location on your file system. This procedure is explained in Leaving Tests in the Original Location.
To create a project that copies existing test suites to a new location on the file system:
.project folder, and the .parasoft files into source control. They will be visible in the Navigator view and should be shared by the entire team..metadata folder into source control.To create a project that leaves existing test suites at the same location on the file system:
Once a team member creates a project, that team member can create a Team Project Set File (.psf) that can then be shared with other members of the team. This allows every team member to create their Eclipse Projects in the same uniform way. This is a necessary step for importing tasks from the automated nightly test process.
To create a Team Project Set File for a project created from CVS, complete the following:
To create a Project from the Team Project Set File, complete the following:
Existing SOAtest or WebKing users can import preferences from previous versions of SOAtest or WebKing. Preferences hold settings such as previously-used WSDL URLs, Report Center preferences, System Properties for including additional jar files in a classpath, etc. Preferences in previous versions of SOAtest or WebKing were saved in a binary file with .xtp or .wkp extensions in the installation directory of SOAtest or WebKing.
To import existing preferences, complete the following:
Parasoft SOAtest is based on the Eclipse IDE and has a different look and feel than older versions. Except for the changes outlined below, however, the user interface design layout, forms and settings have largely remained unchanged and should remain familiar to existing users.
The Test Case Explorer can have multiple Eclipse projects open at the same time. Each project can have multiple Test Suites open at the same time. In previous versions of SOAtest, only one Test Suite could be open at any given time.
At the top right corner of the Test Case Explorer are the following menu buttons:
In previous versions, if you wanted to open the configuration panel for a test node (e.g., an "Editor"), you would select that node in the Tests tab. With SOAtest 9.x, you double-click on an item’s Test Case Explorer node to display its Editor.
If you want to change the default double-click behavior to single-click, complete the following:
You will now be able to open editors based on a single click.
In previous versions of SOAtest and WebKing, only one Editor could be open at once. In SOAtest 9.x, multiple Editors can be open simultaneously.
When an Editor is modified in SOAtest 9.x and later, an asterisk “*” displays on the Editor tab denoting that the Editor is now “dirty.” Modifications to the Editor must be explicitly saved using the Save toolbar button or the Ctrl-S keyboard shortcut.
In previous versions of SOAtest (5.x and earlier), environments were displayed in a separate tab below the Tests tab. Environments are now part of the tree view in the Test Case Explorer.
To run a test, you can right-click on the test’s node and select Test Using ‘Example Configuration’ from the shortcut menu.’ Alternatively, you can press F9 on your keyboard, or click the Test toolbar button.
In previous versions of SOAtest and WebKing, you had to explicitly save test suite (.tst) files. In SOAtest 6.x and later, user actions in the Test Case Explorer are automatically saved. For instance, adding new Test to the Test Case Explorer will be automatically saved.
Once tests are saved in the latest version of SOAtest, they cannot be opened in older versions of SOAtest.
Failures that occur during the test execution now display in the Quality Tasks view. What was previously displayed in the Messages Log now displays in the Console view.
If you have the appropriate source control plugins installed into the Eclipse environment, your Test Suites can now be checked into source control directly as follows:
To check in new projects, complete the following:
To set up an automated nightly build from the Command Line, complete the following:
soatestcli.exe -data "c:\mySOAtestWorkspace" -showdetails -config "user://Example Configuration" -report "c:\mySOAtestReports" -publish -localsettings c:\mySOAtestWorkspace\mylocalsettings.properties" The -publish argument will add reports to DTP so that test and analysis data can be merged, correlated, and analyzed to expose deeply hidden defect patterns. As the DTP processes data, it creates actionable findings that can be downloaded and imported into your IDE (requires DTP 5.3.x or later).
You can also use the -publishteamserver option to publish reports to Team Server, which provides backwards compatibility with Concerto and older versions of DTP.
For a detailed list of changes, see the topic on Command Line Interface Migration.
There have been upgrades to the HP QC Integration from 6.2 to 9.x. The steps to connect the two products must be redone in order to ensure that the correct behavior is continuing.