Studio:Deploying STRIDE on the Target: Difference between revisions
(New page: =Components on the Target= In order for STRIDE Studio to interoperate with your target system, some STRIDE code artifacts must be part of the binary running on your target. The first is t...) |
No edit summary |
||
| Line 1: | Line 1: | ||
=Components on the Target= | =Components on the Target= | ||
In order for STRIDE Studio to interoperate with your target system, some STRIDE code | 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. | ||
The first is the combination of STRIDE Runtime and PAL, which together provide standard STRIDE runtime services customized for the target hardware and operating system. | ==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 | 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. | ||
The | ==IM & Target Test Code== | ||
The second category is more dynamic in nature and its composition depends on your SCL instrumentation: | |||
The IM, however, is often a dynamically-changing module, especially as source code is incrementally SCL-instrumented as tests are being developed | * If your SCL includes instrumentation for host-based testing (e.g. <code>scl_function()</code> or <code>scl_msg()</code>), this category will include IM code | ||
* If your SCL includes instrumentation for target-based testing (e.g. <code>scl_test_class()</code>), 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= | =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== | ==The TestAgent Configuration== | ||
[[Image:TestAgentConfiguration.jpg|frame]] | |||
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 ***. | 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 ***. | ||
| Line 22: | Line 37: | ||
==The TestApp Configuration== | ==The TestApp Configuration== | ||
[[Image:TestAppConfiguration.jpg|frame]] | |||
Revision as of 23:13, 18 April 2008
Components 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()orscl_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
