Studio:Deploying STRIDE on the Target: Difference between revisions
No edit summary |
m (Text replace - 'Category:Installation' to 'Category:Studio:Installation') |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
= | =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. | 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== | ==STRIDE Runtime & PAL== | ||
| Line 8: | Line 8: | ||
==IM & Target Test Code== | ==IM & Target Test Code== | ||
The second category is more dynamic in nature and | The second category is more dynamic in nature and is referred to as an ''Intercept Module'' (IM). This code takes the form of c or c++ source code that is generated by STRIDE Studio from the SCL instrumentation you have applied to your target source header files. | ||
It's important to understand the way that the IM is used in your specific testing scenario, since this controls the ways in which the overall STRIDE code can be deployed on your target system. | |||
===IM Composition=== | |||
* If your SCL includes specific interface instrumentation (e.g. the <code>scl_function()</code> or <code>scl_msg()</code> pragmas are used), the IM code will include some combination of sutbs, proxies, and delegates to enable the remoting of the interfaces you have instrumented. This type of instrumentation is typically used with ''host-based'' testing, where scripts running on the host call C functions running on the host. | |||
* If your SCL includes instrumentation for ''target-based'' testing utilizing one or more C++ ''test classes'' (e.g. the <code>scl_test_class()</code> pragma), the IM code will include a synthesized function to run each test class (which includes a stub that enables the function to be called from the remote host), and the C++ test class code that you write. | |||
=Target Deployment Models= | =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. | 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== | ==The TestAgent Configuration== | ||
[[Image:TestAgentConfiguration.jpg|frame]] | [[Image:TestAgentConfiguration.jpg|frame]] | ||
| Line 38: | Line 34: | ||
==The TestApp Configuration== | ==The TestApp Configuration== | ||
[[Image:TestAppConfiguration.jpg|frame]] | [[Image:TestAppConfiguration.jpg|frame]] | ||
[[Category:Studio:Installation]] | |||
Latest revision as of 22:37, 20 August 2009
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 is referred to as an Intercept Module (IM). This code takes the form of c or c++ source code that is generated by STRIDE Studio from the SCL instrumentation you have applied to your target source header files.
It's important to understand the way that the IM is used in your specific testing scenario, since this controls the ways in which the overall STRIDE code can be deployed on your target system.
IM Composition
- If your SCL includes specific interface instrumentation (e.g. the
scl_function()orscl_msg()pragmas are used), the IM code will include some combination of sutbs, proxies, and delegates to enable the remoting of the interfaces you have instrumented. This type of instrumentation is typically used with host-based testing, where scripts running on the host call C functions running on the host.
- If your SCL includes instrumentation for target-based testing utilizing one or more C++ test classes (e.g. the
scl_test_class()pragma), the IM code will include a synthesized function to run each test class (which includes a stub that enables the function to be called from the remote host), and the C++ test class code that you write.
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
