Studio:Scripting Overview

From STRIDE Wiki
Revision as of 19:06, 28 February 2008 by Root (talk | contribs) (New page: STRIDE affords you a number of different options for automating your testing, including datasets and scripts. Each option provides a unique set of testing capabilities. When conditional...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

STRIDE affords you a number of different options for automating your

testing, including datasets and scripts. Each option provides a unique

set of testing capabilities. When conditional logic, event processing,

user intervention, or other complex operations are required, scripts may

be the most appropriate option.

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. Because of these difficulties,

developers rarely use scripts for testing and integration, despite the

potential benefits.

STRIDE makes it possible to use scripts written in any scripting language

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 calling functions

and/or sending commands and receiving messages.

  • To 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.