Studio:Deploying STRIDE on the Target

STRIDE Code on the Target

In order for STRIDE Studio to interoperate with your target system, some STRIDE-specific code must be part of the binary running on your target.

STRIDE Runtime & PAL

The first category of STRIDE code is the combination of STRIDE Runtime and PAL, which together provide standard STRIDE runtime services customized for the target hardware and operating system.

The runtime + PAL combination is typically created as part of a STRIDE platform integration. This code is static in nature; once produced, it is usually packaged as a linkable library for use with the dynamic portions of the test code.

IM & Target Test Code

The second category is more dynamic in nature and its composition depends on your SCL instrumentation:

• If your SCL includes instrumentation for host-based testing (e.g. scl_function() or scl_msg()), this category will include IM code

• If your SCL includes instrumentation for target-based testing (e.g. scl_test_class()), this category will include IM code (generated to run your test classes) and the c++ test class code that you write.

• An Intercept Module (IM), which is dynamically created from your SCL-instrumented source code (and additional specification through either the IM Wizard or scripting of the studio object model).

A last category is test classes that you create for target-based testing.

All of this code

The IM, however, is often a dynamically-changing module, especially as source code is incrementally SCL-instrumented as tests are being developed.

Target Deployment Models

It is not always known what the ultimate IM setup will be when starting to create tests for a platform, but it's important to consider your needs up front, since the STRIDE deployment model you choose will affect project workflow.

The TestAgent Configuration

By default, we recommend that you consider the light-weight "TestAgent" configuration. This deployment model imposes several limitations, but this model minimizes the impact on your target system and workflow, and in many testing scenarios, the limitations are not ***.

Requirements:

• IM can contain only stubs
• No target c/cpp files may be used to build the executable image
  • For target-based testing, test class implementations are in header file(s)

The TestApp Configuration