STRIDE Runner
Overview
The stride executable (a.k.a. STRIDE Runner) runs target-based tests from a host computer and optionally uploads results to STRIDE Test Space. The program also can be used to list the names of all Test Units that exist in a STRIDE database file.
The stride executable is available to run on Windows and on Linux x86.
Running Tests
You may specify either built-in diagnostics or user tests to be run.
The built-in diagnostics are useful to validate a new installation. See Running Diagnostics for details.
User tests comprise either sample tests provided by S2 Technologies or tests that you create.
Input
In order to run tests, you must provide the following information to stride.exe:
- database file
- This is the .sidb file that is created by the Build Tools during the target build process. This file contains meta-information used to run tests.
- device parameters
- This tells stride.exe how to connect to the target.
- tests to run
- Unless you are running the diagnostic tests (using the <tty>--diagnostics</tty> option), you must specify the Test Units that you want to run. You may also optionally specify named hierarchical suites in which to put the results of the Test Units you designate.
Default Behavior
By default, all Test Units in the specified database are run, and the all results are put into the root suite. It is not necessary to explicitly specify Test Units unless you want to override the default behavior.
Test Unit Run Order
If implicitly specified by a wildcard, Test Units are run in the order in which their corresponding SCL pragmas were seen by the STRIDE compiler.
If explicitly specified, Test Units are run in the order in which they are given on the command line.
Test Unit Specification Rules
- Test Units are specified by name or wildcard and grouped together within parentheses, i.e. "(" and ")"
- When specifying more than one Test Unit in a group, each Test Unit name (or wildcard) must be delimited by a comma.
- The output of each Test Unit group is placed within a hierarchy of named suites. (The root suite does not have a name.)
- The suite into which a Test Unit group is placed is specified immediately before the group, e.g. suitepath(testunitgroup)
- Hierarchical suite paths are delimited by "/" (forward slash) and are always specified starting from the root.
- If the same Test Unit is specified to be run more than once, and one or more results are to be written to the same suite, the each conflicting Test Unit name is appended with an incrementing count in the form of "(n)". For example: Results from three runs of TestUnit "myTU" are all written to the root suite. The Test Units will be reported with the names "myTU" "myTU(1)" and "myTU(2)".
Wildcard Matching
The following wildcard characters are recognized in Test Unit specifications:
*(asterisk) matches all Test Units-(hyphen) matches all remaining Test Units (useful when putting Test Units into suites)
Test Unit Specifiecation Examples
<-r omitted>- Default behavior: run all Test Units and put results into the root-level suite.
-r /(*)- Same as above: run all Test Units and put results into the root-level suite.
-r /Suite(*)- Run all tests and put results into a suite named "Suite" that is a child of the root suite.
-r /(TU1,TU2,TU3)- Run the Test Units named "TU1", "TU2", and "TU3" in the designated order; put results into the root suite.
-r /(TU1,TU2,TU3) -r /SecondPass(TU1)- Run the Test Units named "TU1", "TU2", and "TU3" in the designated order; put results into the root suite. Then run the Test Unit named "TU1" again and put the results into a suite named "SecondPass".
-r /(TU1,TU2,TU3) -r /Remaining(-)- Run the Test Units named "TU1", "TU2", and "TU3" in the designated order; put results into the root suite. Then run all remaining Test Units and put the results into a suite named "Remaining".
-r "/Suite1/Suite2(TUa, TUb)"- Run the Test Units named "TUa" and "TUb", and put the results into a suite named "Suite2" that is a child of a suite named "Suite1" that is a child of the root. Note that we must enclose the specification in quotes since the specification contains a space.
-r "TUx TUy TUz"- This is a special convenience syntax. If the suite and grouping parentheses are omitted, the app runs the the named Test Units and puts their results put into the root suite.
Output
Upon test completion, test output is always written as follows:
- console output
- A quick summary of results is written to standard output. Test counts are shown for the categories of passed, failed, in progress, and not in use
- local xml file
- Detailed results are written to a local xml file. By default, this file is written to the directory where the input STRIDE database file is located and given the same name as the database file with an extension of ".xml". If you open this file in a web browser, an xsl transform is automatically downloaded and applied before rendering.
Optionally, you may also publish the results to your STRIDE Test Space upon test completion.
- Test Space
- Results are uploaded using your Test Space URL and login credentials. You must specify the testspace name and project name when using this option.
Syntax
stride [options]
Each command line option that accepts an argument should be entered with a space between the option and its corresponding arguement; i.e.
stride -o argument --option1 argument1
Any warnings or errors that occur during execution are written to the standard output device.
Options
| Option | Description |
|---|---|
| --version | Prints version information to the console. |
| --database arg | Specifies the name of an existing STRIDE database (.sidb) file that will be used for test execution. This can be a relative or absolute path. If the path contains one or more spaces, it must be enclosed in quotes. |
| --device arg | Specifies the parameters to be used to connect to the target device (i.e. TCP:host:port or COMport:rate:mode). For example:
|
| --timeout arg (=0) | Specifies a watchdog timeout (in seconds) per single test execution step.
Default value is 0. (0 = infinite timeout) |
| -r [ --run ] arg (=/(*)) | Specifies a list of Test Units to execute and their order of execution with optional report grouping by suite. You may specify this option many times on the command line to include multiple groupings in a single test. A named Test Suite may be specifed more than once to run it multiple times. See Input section above for more details.
Default value is all Test Units. |
| -u [ --upload ] arg (=all)] | Specifies if and how to upload the results to STRIDE Test Space. Arg specifies type of upload; The following types of uploads are supported:
Default value is "all". |
| --testspace arg | Specifies the root STRIDE Test Space URL and credentials. (i.e. https://mycompany.stridetestspace.com@user:pwd) |
| --project arg | Specifies the name of the STRIDE Test Space project to which the results will be uploaded |
| --space arg | Specifies the name of the STRIDE Test Space project's test space. |
| --name arg | Specifies the name to be given to the result set uploaded to STRIDE Test Space. If this option is omitted, a default name of "Sequence_n" is used where n is an auto-incremented integer. |
| --list | Lists all Test Units in the specified STRIDE database to standard out. |
| --diagnostics | Performs a set of built-in diagnostic tests on the target. See Sandbox Evaluation for test details. |
| -o [ --output ] arg | Specifies the local file to which results will be written. |
| -O [--options_file] arg | Specifies a file from which the program reads command line options. The format is the same as the command line except that options may be split across multiple lines. |
Environment Variables
The following environment variables are recognized by the application and their values used as shown if set. [1] Any value specifed by an environment variable will be overridden if the corresponding value is specified on the command line.
- STRIDE_DEVICE
- specifies the --device argument
- STRIDE_TESTSPACE_URL
- specifies the --testspace argument
- STRIDE_TESTSPACE_PROJECT
- specifies the --project argument
- STRIDE_TESTSPACE_SPACE
- specifies the --space argument
Setting up environment variable for static options will streamline the use of stride.
Using a Proxy
If you access the Internet via an HTTP proxy, you must set the environment variables HTTP_PROXY and HTTPS_PROXY to specify the name and port of the proxy server.
Symptoms of needing to specify a proxy is the following errors:
Activation error: 132 Unable to connect to http://activation.s2technologies.com Cannot connect to specified URL (-132)
Unable to proceed. Failed performing request: [6] Couldn’t resolve host name
The environment variables are set with the value name:port corresponding to your proxy server. For example, on Windows:
> set HTTP_PROXY=myproxy:8765
would instruct the stride runner to use the proxy named myproxy on port 8765 to communicate via HTTP protocol.
License Activation
The stride executable requires a valid license to run. The first time you execute stride (and any other time a valid license is not found), you will be prompted to accept the Stride Framework License Agreement (distributed in the host tools package). If you accept the agreement, you will then be prompted to enter a license activation code.
At this point, enter the activation code supplied by S2 Technologies to perform Internet activation and download of your license. You must be connected to the Internet for this to succeed. Once you have a valid license on your computer, the Internet connection is no longer necessary.
Examples
Refer to Running Test Units for additional examples.