|Prints verbose output to stdout.||This prints the same type of output that would be shown in the console (if running from the GUI).|
|Specifies the location of the Eclipse workspace directory to use.||Defaults to the current user’s dependent directory. If the -data option is not used, then the default workspace found under [SOAtest_workspace]\parasoft\workspace (where "SOAtest_workspace" could be C:\Users\yourname) will be used.|
|Imports the specified Eclipse project(s) into the Eclipse workspace.|
If %ECLIPSE_PROJECT% is a .project file, the selected project will be imported
If needed, run
|Specifies the path to the test suite(s) to run.|
To run a single test suite, specify the path to <test suite name.tst> relative to the workspace.
To run all test suites within a directory, specify the directory path relative to the workspace.
Use multiple times to specify multiple resources. Use quotes when the resource path contains spaces or other non-alphanumeric characters.
Team Project Set File (PSF) files are supported for CVS, SVN, Star Team, and other source control systems (depending on the Eclipse plugin capabilities installed).
Paths (even absolute ones) are relative to the workspace specified by the
If you are specifying multiple tests from different projects, note that tests will be grouped project-by-project, in the order specified in the multiple -resource parameters or in the .lst file. All tests in the same project as the first resource will be run before any tests that are in a different project (e.g., if you specify resources in the order /ProjectA/A.tst, /ProjectB/B.tst, /ProjectA/C.tst, they will executed in the order /ProjectA/A.tst, /ProjectA/C.tst, /ProjectB/B.tst).
|Specifies that you want to run the Test Configuration available at |
This parameter is required.
|Reads the local setting file |
The local setting file is a properties file. These files can control reporting preferences (who should reports be sent to, how should those reports be labelled, what mail server and domain should be used, etc.) Team Server settings, Report Center settings, email settings, and more.
For details on creating local setting files, see Local Settings Files - Options.
|Publishes the reports to the DTP.|
In SOAtest 9.10.2 and later, this option sends report data to DTP (requires DTP 5.3.x or later). In older versions of SOAtest, this option sent reports to Team Server.
|Publishes the reports to the Team Server.||The Team Server location can be specified in the GUI or in the local setting file (described in the |
|Generates an XML report to the given file |
All of the following commands will produce an HTML report
If the specified path ends with an ".html"/".htm"/ ".xml" extension, it will be treated as a path to the report file to generate. Otherwise, it will be treated as a path to a directory where reports should be generated.
If the file name is explicitly specified in the command and a file with this name already exists in the specified location, the previous report will be overwritten. If your command doesn’t explicitly specify a file name, the existing report file will not be overwritten—the new file will be named repXXXX.html, where XXXX is a random number.
|Specifies search and replace arguments|
This option only applies for SOAP clients.
This feature is now deprecated. Please use Use Environments instead.
|Specifies test name patterns; test suite names are valid|
Allows you to specify the name of the test in the test suite to run. For example, if you want to run a test suite named WSDL Tests, you might use
To run multiple tests use
Note that you can surround the value with quotes in order to allow spaces in the name. For example,
To limit row usage for tests matching the specified name, you can use
|Runs all tests with the specified data source row(s)|
If you want to force all data source rows to be used—even if the data sources were saved to use only specific rows— use
|Specifies the active data source within a data group||This argument must be followed by the location of an XML file that specifies the active data source for each data group within each .tst file contained in the test run. The file should be formatted as shown in datagroupConfig XML File Format.|
|Specifies environment options||When running functional tests from the command line, you can override the active environment specified in a project with one specified from the command line. Note that if the specified environment is not found in the project, the default active environment will be used instead.|
|Specifies the active environment variables||This argument must be followed by the location of an XML file that specifies the environment variable values to use for each .tst file contained in the test run. The file should be formatted as shown in environmentConfig XML File Format.|
|Fails the build by returning a non-zero exit code if any violations are reported.|
The return code will be 2 for static analysis violations, 4 for functional test violations, 8 for code review violations, and 1 for any other problem.
Also see CLI Exit Codes.
|Report test results to HP Quality Center||Allows you to send results back to HP Quality Center. For details, see Using HP ALM and HP Quality Center with SOAtest.|
|Report test results to Microsoft Visual Studio Team System||Allows you to send results back to Microsoft VIsual Studio Team System. For details, see Using Microsoft with SOAtest.|
|Specifies files to be included/excluded during testing.|
You must specify a file name or path after this option.
Patterns specify file names, with the wildcards * and ? accepted, and the special wildcard ** used to specify one or more path name seg-ments. Syntax for the patterns is similar to that of Ant filesets.
Additionally if a pattern is a file with a .lst extension, it is treated as a file with a list of patterns.
For example, if you use -include c:/include.lst and include.lst contains the following (each line is treated as single pattern):
then it has same effect as specifying:
|For browser tests, opens the browser UI and plays back tests in the browser.||This gives you the option to view and capture the browser contents shown after each test step (e.g., for compliance purposes).|
|Pulls settings stored on the Concerto server (recommended for ease of maintenance—especially if you do not already have a locally-stored localsettings file)||For example:|
|Generates an encoded version of a given password.|
Prints the message 'Encrypted password: <encpass>' and terminates the cli app.
Must be used along with
|Prints detailed test progress information.||N/A|
|Specifies additional JVM options, which in turn get passed to the Eclipse executable via the -vmargs option.|
The Eclipse -vmargs argument is used to customize the operation of the Java VM to use to run Eclipse. If specified, this option must come at the end of the command line. Even if not specified on the executable command line, the executable will automatically add the relevant arguments (including the class being launched) to the command line passed into Java using the -vmargs argument. Java Main then stores this value in eclipse.vmargs.
We recommend that you delete non-applicable properties and keep only critical properties, such as the classpath property. We also recommend that you replace machine/user-specific locations with variables by using the
|Displays help information.||Does not run testing.|
|Displays version number.||Does not run testing.|
|Prints the machine ID.||The machine ID is used for licensing purposes.|