Studio:Scripting Overview

From STRIDE Wiki
Revision as of 17:38, 3 March 2008 by Timd (talk | contribs)
Jump to navigation Jump to search

The Role of Scripting in STRIDE

Using scripts to drive test scenarios or to simulate missing components has traditionally been difficult, if not impossible, when the unit under test is located on the target platform. Moreover, scripting languages and the C language do not necessarily mix well. There are data type mismatches, etc. *** Because of these difficulties, developers rarely use scripts for testing and integration, despite the potential benefits.

  • You don't have to recompile your target when test changes are made in the script
  • Scripting is very flexible
  • Wide spectrum of personnel are able to write scripts

Template:Ref

STRIDE makes it possible to use scripts written in either JScript or Perl Template:Note to test your software units regardless of whether they are located on the host, target, or both. There are two common use cases for using scripts to integrate and test:

  • To drive the testing of a unit or units by setting parameter values, calling functions, and receiving return values (or sending/receiving messages)
  • To mock (simulate) a missing function or other component so an interdependent unit can be tested.

To illustrate these two use cases, consider a hypothetical embedded

application containing three functions: A, B, and C. A calls B and B calls

C as shown on the left in the diagram below. Suppose that you developed

function B and you are ready to test it, but function C is not yet completed.

One solution, which would allow you to continue testing regardless of

the availability of function C, is to use scripts as shown on the right

in the diagram below. One script simulates the missing function C (Use

Case #2) while the other drives the testing of function B (Use Case #1).


File:Overview Scripting.png

As implied in the diagram, the fact that scripts replace functions A

and C does not change the interfaces with function B; via STRIDE, interfaces

defined in your embedded application are available at the source level

in your favorite scripting language. In addition, function B could be

on the target application, whereas the scripts replacing functions A and

C are running on the host.