Studio:Scripting Overview

The Role of Scripting in STRIDE Studio

Scripting (running programs implemented in a supported scripting language) is fundamental to performing tests within STRIDE Studio.

STRIDE makes it possible to use scripts written in either , to test your software units regardless of whether they are located on the target, the host, or both.

Typically, scripts are used for the following tasks:

• Manipulating/controlling STRIDE Studio
• Driving tests
• Simulating missing software units
• Controlling the content of reports and their generation

STRIDE extends the intrinsic capabilities of a scripting language by providing a set of COM Automation compatible objects and injecting an instance of each into your running script.

Object instances that are injected into STRIDE Studio scripts

Injected Object	Perl Variable Name	JScript Variable Name
studio	$main::studio	studio
ascript	$main::ascript	ascript
testSuite	$main::testSuite	testSuite

Each object presents an object model through which you can perform needed operations and get/set desired properties. For details of each object model, see Online Help installed with STRIDE Studio.

Controling STRIDE Studio from a Script

The studio instance injected into each script has been initialized to reflect the current settings and properties applied to the currently loaded workspace.

Note: You can also instantiate a studio object from an external script running outside of STRIDE Studio. In this case, the initial state does not reflect a workspace until one is explicity loaded or created.

The types of things controlled in Studio

• Workspace-related
  • Control the composition of a workspace
    • Add/remove files and folders
  • Control workspace settings
    • Set folder/file properties
    • Set compiler properties

• Compiler-related
  • Compile the workspace
  • Control intercept module settings and generation

• Test-run related
  • Run scripts
  • Control optional trace views

Calling Target C Functions from a Script

The set of captured interfaces is accessed via the injected ascript object. `This object connects scripts to the workspace's database and to the STRIDE runtime. The injected ascript instance has been initialized to reflect the current state of the currently loaded workspace's database.

Note: You can also instantiate an ascript object from an external script running outside of STRIDE Studio. In this case you must provide information by calling the new instance's Initialize() method with the required parameters.

the ascript object provides the means by which:

• on-target C functions can be called and executed
• on-target functions can be mocked (simulated) by script code running on the host

In either case, function parameter values can be set by the function's caller (known as the User) and read by the function implementation (known as the Owner). Similarly, function return values can be set by the function implementation (Owner) and read by the function's caller (User) upon return from the called function.

A Typical Scenario

In a typical testing scenario, the target system we are testing is up and running and the communication link between the host PC system and the target is operational. By default, the registered Owner of each function is the target implementation, therefore any calls we make to the function will be routed to the target by the host runtime.

The steps we would take in a script to call the remote function are:

1. Get the desired Function User object instance from the ascript Functions collection
2. Set the function's input parameter values
3. Call the function (can be done synchronously or asynchronously)
4. Upon the function's return, compare the return value against an expected value

In most scripts, the first step would be done once, and the remaining steps would be performed in a loop, presenting a different set of input parameter values each iteration.

Script syntax is available for navigating complex payloads comprising structures, unions, arrays and pointers.

Reporting from a Script

Reporting is performed using the injected testSuite object (the injected reporter object is also used occasionally).

STRIDE Studio, automatically creates a hierarchy of test suites that mirrors the hierarchy of folders under the workspace Script Files folder. The injected testSuite object is the instantiated Suite object in the reporter hierarchy that corresponds to the parent folder of the running script.

A script creates a test report entry by creating one a TestCase object as a child of the