The command line tool

With TestArchitect's command line tool, tests can be launched from a command shell. When incorporated into batch files, the tool greatly extends the flexibility of test execution, especially from the standpoint of scheduling.

You are probably already familiar with the typical means by which automated tests are invoked, a method we call online execution. You create a test, or set of tests, open the Execute Test dialog box to configure any options, then run the tests from there.

The command line tool allows you to instead execute tests from your host operating system's command line interface. By itself, this capability may not be very useful. But TestArchitect also exploits this feature by enabling you to generate batch files that run the command line tool, configured to execute your tests. These batch files may in turn be launched automatically from other programs, for example as part of a nightly build process.

Using the command line tool

The TestArchitect command line tool is a Java program, TACommandLine.jar. It can be found in the following locations:
Windows TA_INSTALL_DIR\binclient
Linux /usr/local/logigear/testarchitect/binclient
macOS /Applications/TestArchitect/binclient
When executed, TACommandLine.jar must be followed by a set of arguments, some of which are required, while others are optional.

Note that, in most contexts, you will want to use a batch file to invoke the command line tool. Moreover, you will use the Execute Test dialog box of TestArchitect Client to automatically generate the batch file for you, along with all the arguments. Hence the information in this topic is, for the most part, for reference only, such as when you need to read an existing batch file. However, there also may be times when you will want to edit a batch file by hand.

TACommandLine

A typical TACommandLine.jar command line to invoke the execution of a single TestArchitect test module might appear as follows:
"C:\Program Files\LogiGear\TestArchitect\jre\bin\java.exe" -jar -Xmx512m
  "C:\Program Files\LogiGear\TestArchitect\binclient\TACommandLine.jar"
  /exechost localhost /execport 53600 /rshost lgvn14150.logigear.com /rsport 53400 
  /lsaddr  "lgvn11242" /lsport  "14101" /lsusr  "" /dbtype  "javadb" /dbname "SampleRepository"
  /uid "administrator" /pwd "04848565154" /proid 10jqmmcsw8 /proname "Car Rental" 10jqmmcsw8 /srvid 2zyo9u65cd 
  /sessionid  "1b1c96f6-a314-4013-a047-275a4af8755d" /var /resultname  "batch run 20140930"
  /comment "Test run for version 9.1.10 of app" 
  /mod "\Car Rental Orders	initial{#@}TC 01{#@}TC 04{#@}final	10kkm3qfs1"
  /openresult "no" /toolname "TestArchitect Automation Playback" 
  /toolscript "{INSTALL_DIR}/binclient/taplayback.exe" /toolpath "{INSTALL_DIR}/binclient/taplayback.exe"
  /toolcmd "" /versions "" /delay "0" /redunlsaddr  "192.168.167.92" /redunlsport  "14101" 
  /xupath  "" /exporthtmlpath  "" /exportxmlpath  "" /startupsettings  "" /uploadresulttorepos  "" 
  /tfsquery "" /testsetid /timetraveling  "04/01/2015 22:04:36.306+0700" /udf "build number" 
  /capturecond  "" /numofinteraction  "" /exportscreenshotcond  "0"
As evident, it involves calling the Java executable, informing it (-jar) that you are passing it a Java archive file for execution, specifying some Java options (-Xmx512m), then providing the path to jar file TACommandLine.jar, followed by the list of command options used by TACommandLine.

Command options

Note in particular the /mod option. This argument, comprised of three tab-delimited segments, specifies not only the test module that is to run, but also which sections of it are to be included in the execution (in this case, the INITIAL and FINAL sections, and test cases TC 01 and TC 04).
Note: The /mod option may also be used to specify an entire test suite, as opposed to just a single test module.

The list that follows comprises the set of arguments for TACommandLine.jar. Some are required, while others are optional. When generating a batch file from TestArchitect, most of the arguments get their values from the fields of the Execute Test dialog box, as the following figures illustrate:



Test Modules panel



General tab



Advanced tab



Startup Settings tab

/compileonly
(Optional) Change the generated batch file to only compile tests and not run the tests when the batch file executes.
Note: /compileonly cannot be specified from the Execute Test dialog box. You may find it useful to add this flag to the TACommandLine line within an existing batch file, to switch the command from execution to compilation.
/exechost "<Controller IP>"*
IP address of the TestArchitect controller that is to run the test.
Specified in the Controllers/Devices panel of the Execute Test dialog box (Select Controllers and Devices button).
/execport "<Controller Port>"*
TCP/IP port number on which the TestArchitectcontroller listens for execution requests.
Specified in the Controllers/Devices panel of the Execute Test dialog box (Select Controllers and Devices button).
/rshost "<Repository Host Name>"
Host name of the repository server containing the repository holding the test module to be executed.
/rsport "<Repository Port>"
TCP/IP port number of the repository server.
/lsaddr "<License Server Name>"
Host name of license server.
/lsport "<License Server Port>"
TCP/IP port number of the license server.
/lsusr "<License User>"
(Optional) User name of license server account. (The default value is empty, as it is generally not required.)
/dbtype "javadb"
Database type of the repository. At present, this argument accepts only the value javadb. (Default: javadb.)
/dbname "<Repository Name>"
Name of the repository hosting the project.
Note: If both /dbname and /srvid have defined values, /dbname takes precedence.
/srvid "<Repository ID>"
Repository ID of the repository hosting the project. (This ID is one that TestArchitect generates for repositories. It can be viewed in the Repository Properties dialog box of the repository, available from the context menu in the TestArchitect explorer tree.)
Note: If both /dbname and /srvid have defined values, /dbname takes precedence.
/uid "<User Name>"
User name to log in to the repository.
/pwd "<Password>"
Password (encrypted) associated with the /uid.
/proid "<Project ID>"
Test project ID. (This ID is generated by TestArchitect. It can be viewed in the Project Properties dialog box of the project, available from the context menu in the TestArchitect explorer tree.)
Note: If both /proname and /proid have defined values, /proname takes precedence.
/proname "<Project Name>"
Name of the project
Note: If both /proname and /proid have defined values, /proname takes precedence.
/sessionid "<Session ID>"
(Optional) Session ID. A unique value when generated by TestArchitect. However, the value may be modified or omitted for your own purposes in the batch file.
/var "<Keyword>"*
(Optional) Keyword variation(s) to apply to the test module execution.
Specified within the Keyword box in the Execute Test dialog box.
Tip: Refer to Creating keyword variations for details.
/resultname "<Result Name>"*
Name for the test result.
Specified within the Settings panel of the Execute Test dialog box.
/comment "<Comment>"*
(Optional) Comment related to the test.
Specified within the Settings panel of the Execute Test dialog box.
/mod "<Test Item Path> <Test Module Sections> <Test Item ID>” *
<Test Item Path>: Name of test module or test suite to be executed.
<Test Module Sections>: (provided only when a test module is specified) Test module sections to be executed: that is, initial, final, and specified test case names. Specified sections are delimited by {#@}.
<Test Item ID>: ID of the test module or test suite.
Note:
  • The three segments of the /mod parameter are delimited by tab characters.
  • A single TACommandLine command can specify a single test module or a test suite. When a test suite is specified, the <Test Module Sections> segment is ignored. (Batch files generated by TestArchitect leave this segment blank for test suite lines.)
  • <Test Item ID> is optional but strongly recommended. The TestArchitect interpreter first attempts to locate the test module/test suite via <Test Item Path>. If unsuccessful, it then resorts to the <Test Item ID>.
/openresult "<yes/no>"
(Optional) Specifies whether TestArchitect opens the test result after batch file execution completes. (Default = "no".)
/toolname "<Test Tool Name>"*
Name of the test playback tool.
Specified in the Automation Tools dialog box.
/toolscript "<Script>"*
Script's path for the test playback tool.
Specified in the Automation Tools dialog box.
/toolpath "<Path to Executable Tool>"*
The executable application's path to run the test.
Specified in the Automation Tools dialog box.
/toolcmd "<Command Line>"*
(Optional) Execution command line.
Specified in the Automation Tools dialog box.
/versions "<AUT Version>"*
(Optional) Linked variation to apply to the test module execution.
Specified in the Variation Specification panel in the Execute Test dialog box.
Tip: See Creating linked variations for further information.
/delay "<Delay Time>"
(Optional) Delay time between actions. (Generally not required.)
/redunlsaddr "<IP Address>"
(Optional) IP address of redundant license server, if any.
/redunlsport "<Port>"
(Optional) TCP/IP port of redundant license server, if any.
/xupath "<xUnit Filepath>"*
(Optional) Location and filename to which to store the test result report in xUnit form.
Specified within the Export result(s) to xUnit panel under the Advanced Settings tab of the Execute Test dialog box.
Tip: For detailed information on how to have TestArchitect export test results to XUnit, see Exporting test results to xUnit file.
/exporthtmlpath "<HTML Filepath>"*
(Optional) Location and filename to which to store the test result report in HTML form.
Specified within the Export result(s) to HTML panel under the Advanced Settings tab of the Execute Test dialog box.
Tip: For detailed information on how to have TestArchitect export test results to HTML, refer to Exporting test results to HTML file.
/exportxmlpath "<XML Filepath>"*
(Optional) Location and filename to which to store the test result report in XML form.
Specified within the Export result(s) to XML detail panel under the Advanced Settings tab of the Execute Test dialog box.
Tip: For detailed information on how to have TestArchitect export test results to XML, refer to Exporting test results to XML.
/startupsettings "<Setting Name>=<Setting Type>=<Setting Value>"
(Optional) Define the list of user-defined settings or reconfigured built-in settings. (Separate multiple settings with semi-colons.)
Allowable values of Setting Type:
  • bis: built-in setting
  • uds: user-defined setting
/uploadresultcond "<Filter Condition>"*
(Optional) Specify which types of test results are to be automatically stored to the repository after execution completes.
Allowable values (separate multiple conditions with commas, terminate the string with a semicolon):
  • Passed
  • Failed
  • Passed with Warnings/Errors
  • Passed with known bug
Note: The TestArchitect batch generation process omits this flag from the batch file if no destination is specified in uploadresulttorepos.
Tip: For detailed information on how to have TestArchitect store test results automatically based on pre-defined conditions, refer to Adding test results automatically.
/uploadresulttorepos "<Repository Destination>"*
(Optional) Path to the repository result folder to which the test result is to be stored.
/testsetid
(Optional) Consists of a destination path plus other configuration options for the currently configured external test tool, if any, such as, Team Foundation Server-Microsoft Team Manger (TFS-MTM), HP Quality Center, or Zephyr.
Note:
  • Please contact LogiGear Support if you need details of how to configure this parameter by hand.
  • When running a batch file that uploads to a given external tool, you must ensure that the host repository is currently configured for that same tool.
  • If both /testsetid and /tfsquery have defined values to upload TestArchitect test results to Team Foundation Server, /tfsquery takes precedence.
/tfsquery
(Optional) Specify either the destination path to upload TA test results to TFS, or a Work Item Query Language (WIQL) used to query for test points.
Note: If both /testsetid and /tfsquery have defined values to upload TestArchitect test results to Team Foundation Server, /tfsquery takes precedence.
/uploadattachmentcond "<Filter Condition>"*
(Optional) Specify which associated Team Foundation Server (TFS) test cases are to receive links to the attached test result. This determination is based, for each given test case, on its result in terms of its TFS outcome.
Allowable values (separate multiple conditions with commas):
  • Passed: Attach the TA test result file if the test case's TFS outcome is Passed.
  • Inconclusive: Attach the TA test result file if the test case's TFS outcome is Inconclusive.
  • Failed: Attach the TA test result file if the test case's TFS outcome is Failed.
Note: This parameter only takes effect with Team Foundation Server-Microsoft Test Manager integration. (Learn more.)
/uploadedfiletype
(Optional) The format of the test results uploaded to the external test tool, when the automated tests are run through TestArchitect.
Allowable values:
  • html
  • zip
  • <max html file size>: TestArchitect uploads the result as an HTML file if the file's size does not exceed the specified limit. If the limit is exceeded, it is compressed and uploaded as a ZIP file.
    Note: This parameter only takes effect with Team Foundation Server-Microsoft Test Manager integration. (Learn more.)
/timetraveling
(Optional) The specific historical snapshot, based on a given revision timestamp, of the project items invoked by the test run. (See Time-traveling execution.)
/udf "<Field Name1> <Value1> <Field Name2> <Value2>..."*
(Optional) Field-value pairs for any user-defined fields assigned to the Result item type, as well as the Build Number built-in field. Tab-delimited.
Note: The Build Number value is specified within the Settings panel of the Execute Test dialog box.
/capturecond "<Filter Condition>"*
(Optional) Specifies which types of test outcome events are to have associated screenshots captured and logged during the automated test.
Allowable values (separate multiple conditions with semicolons):
  • Passed
  • Failed
  • Warning/Error
Specified within the Screenshot Recording panel of the Execute Test dialog box. (For details, refer to Capturing screenshots during test execution.)
/numofinteraction "<Value>"*
(Optional) Specifies the number of UI-interacting actions preceding each event specified in capturecond for which the screenshots are to be retained and logged to the results. (Default: screenshots of all UI-interacting actions are captured and logged. For details, refer to Capturing screenshots during test execution.) Specified within the Screenshot Recording panel of the Execute Test dialog box.
/exportscreenshotcond "<Value>"
(Optional) Keep captured screenshots when exporting local test results to HTML.
Allowable values:
  • 0: Do not export captured screenshots.
  • 1: To save space in the exported HTML test results, the screenshots are exported as thumbnail images.
  • 2: Screenshots are exported in their original, full size resolution.
Note: In the Execute Test dialog box, this parameter corresponds to the Export Result(s) to HTML panel of the Advanced Settings tab. (For details, refer to Exporting test results to an HTML file.)
/devices "<Device Name 1>;<Device Name 2>; ..."*
(Optional) Specifies the device(s) (e.g., Android or IOS) upon which the test is to be executed (semicolon-delimited).
Note: Specified in the Controllers/Devices panel of the Execute Test dialog box (Select Controllers and Devices button).

* Value is wholly or partially modifiable from the Execute Test dialog box or a sub-dialog box.