Studio:Deploying STRIDE on the Target - Revision history

Timd: Text replace - 'Category:Installation' to 'Category:Studio:Installation'

2009-08-20T22:37:50Z

Text replace - 'Category:Installation' to 'Category:Studio:Installation'

← Older revision		Revision as of 22:37, 20 August 2009
Line 35:		Line 35:
	[[Image:TestAppConfiguration.jpg\|frame]]		[[Image:TestAppConfiguration.jpg\|frame]]

	[[Category:Installation]]		[[Category:Studio:Installation]]

Timd: Deploying STRIDE on the Target moved to Studio:Deploying STRIDE on the Target

2009-08-18T21:46:40Z

Deploying STRIDE on the Target moved to Studio:Deploying STRIDE on the Target

← Older revision	Revision as of 21:46, 18 August 2009
(No difference)

Ivailop: /* The TestApp Configuration */

2009-06-05T16:53:36Z

The TestApp Configuration

← Older revision		Revision as of 16:53, 5 June 2009
Line 36:		Line 36:

	[[Category:Installation]]		[[Category:Installation]]
	~~[[Category:Practice]]~~

Ivailop: /* STRIDE Code on the Target */

2009-02-12T17:54:43Z

STRIDE Code on the Target

← Older revision		Revision as of 17:54, 12 February 2009
Line 1:		Line 1:
	=STRIDE Code 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.		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 17:		Line 17:

	* 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.		* 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=

Ivailop: /* The TestApp Configuration */

2008-09-24T19:47:20Z

The TestApp Configuration

← Older revision		Revision as of 19:47, 24 September 2008
Line 38:		Line 38:

	[[Category:Installation]]		[[Category:Installation]]
			[[Category:Practice]]

Ivailop: /* The TestApp Configuration */

2008-09-24T19:46:42Z

The TestApp Configuration

← Older revision		Revision as of 19:46, 24 September 2008
Line 36:		Line 36:
	==The TestApp Configuration==		==The TestApp Configuration==
	[[Image:TestAppConfiguration.jpg\|frame]]		[[Image:TestAppConfiguration.jpg\|frame]]

			[[Category:Installation]]

Timd at 23:35, 18 April 2008

2008-04-18T23:35:47Z

← Older revision		Revision as of 23:35, 18 April 2008
Line 8:		Line 8:

	==IM & Target Test Code==		==IM & Target Test Code==
	The second category is more dynamic in nature and ~~its composition depends on your~~ SCL instrumentation:		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.

	* 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		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.

	* 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.~~		===IM Composition===

	* 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.		* 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.

	~~All of this~~ code		* 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.


	~~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.		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]]

Timd: /* IM & Target Test Code */

2008-04-18T23:15:04Z

IM & Target Test Code

← Older revision		Revision as of 23:15, 18 April 2008
Line 10:		Line 10:
	The second category is more dynamic in nature and its composition depends on your SCL instrumentation:		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. <code>scl_function()</code> or <code>scl_msg()</code>), this category will include IM code		* 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.		* 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).		* 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).

Timd: /* Components on the Target */

2008-04-18T23:14:18Z

Components on the Target

← Older revision		Revision as of 23:14, 18 April 2008
Line 1:		Line 1:
	=~~Components~~ 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.		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.

Timd at 23:13, 18 April 2008

2008-04-18T23:13:24Z

← Older revision		Revision as of 23:13, 18 April 2008
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 ~~artifacts~~ 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.

	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 ~~second~~ is ~~the 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~~.		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 ~~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 follow-~~on ~~test code.~~		==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. 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.		* 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]]