Studio:Test Scripts: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
Line 82: Line 82:
</source>
</source>


[[Category:Test Scripts]]
[[Category:Studio:Test Scripts]]

Revision as of 00:39, 21 August 2009

What are STRIDE Test Scripts?

STRIDE Test Scripts is a general term for host-based testing of target code by means of remoting selected target-based interfaces to the host system. The target interfaces are then programmable via a standard common scripting language.

Using a script, remoted function parameters can be set, functions can be called (which run in-place on the target) and return values can be received, inspected and compared--all on a Windows host computer.

STRIDE Test Script techniques are most commonly used in these testing scenarios:

  • Black-box system testing
  • Integration testing
  • Functional testing
  • Regression testing
  • Interactive testing

STRIDE Test Script-based test assets can also be combined with STRIDE Test Units for comprehensive coverage.


Test Script Features

STRIDE Test Scripts provide the following features:

  • Remote access to your target's APIs and messaging interfaces
  • On-target interface tracing with profiling
  • Dynamic interface interception to allow runtime-assignable faking, mocking, and doubling
  • Framework for record and playback of interface transactions to emulate field conditions

STRIDE Test Scripts are completely supported by the STRIDE Studio IDE, which provides a complete workspace-based environment for the development, debugging and deployment of tests.

Test Script Deployment

To take advantage of STRIDE Test Scripting, the following steps are involved:

  1. STRIDE build tools and library are added to the target make process
  2. Target source interfaces are instrumented by adding STRIDE Pragmas to target header source files
  3. Instrumented target is built to include STRIDE-generated source files that implement an Intercept Module
  4. Communication is established between the Windows host and the target (typically via TCP/IP or Serial port)
  5. Test scripts running on the host invoke and exercise your instrumented interfaces

Simple Test Script Example

Target Code Header File

This header file shows STRIDE instrumentation in place to capture and use a reverseString() function remotely. STRIDE #pragma statements will cause the STRIDE Build Tools to generate harnessing code as part of the target application build.

#define MAX_LEN 128

const char* reverseString(const char* szInput);

#ifdef _SCL
/* capture the function reverseString */
#pragma scl_function(reverseString)
/* declare szInput as a string with max length */
#pragma scl_string(reverseString.szInput, MAX_LEN)
/* declare return value as a string with max length */
#pragma scl_string(reverseString(), MAX_LEN)
#endif /* _SCL */

Simple Test Script

This perl script illustrates the steps to call the instrumented reverseString() function and verify normal behavior.

  • ascript is a COM object injected into the script that provides the remote interface
  • Upon Call(), function parameters are marshaled across the host/target boundary, the function is executed on the target, and the return value is marshaled back to the host.
use strict;
use Win32::OLE;
Win32::OLE->Option(Warn => 3);

# get the user side of the function call
my $reverseString = $main::ascript->Functions->Item("reverseString")->User;

# set the input parameter
$reverseString->ParameterList->{szInput} = "tpircS tseT";

# remotely call the function
$reverseString->Call();

# verify the function's return value
if ($reverseString->ReturnValue ne "Test Script") {
   # Test fails
}