What is Unique About STRIDE - Revision history

Marku: /* Test Doubles */

2015-07-07T15:17:21Z

Test Doubles

← Older revision		Revision as of 15:17, 7 July 2015
Line 55:		Line 55:

	===Test Doubles===		===Test Doubles===
	For more advanced testing scenarios, dependencies can be [[~~Using_Test_Doubles~~ \| '''doubled''']]. This feature provides a means for intercepting C/C++ global functions on the target and substituting a stub, fake, or mock. The substitution is all controllable via the runtime, allowing the software to continue executing normally when not running a test.		For more advanced testing scenarios, dependencies can be [[Test_Double \| '''doubled''']]. This feature provides a means for intercepting C/C++ global functions on the target and substituting a stub, fake, or mock. The substitution is all controllable via the runtime, allowing the software to continue executing normally when not running a test.

	===Other Features===		===Other Features===

Ivailop: /* Fixturing */

2014-11-26T23:49:18Z

Fixturing

← Older revision		Revision as of 23:49, 26 November 2014
Line 35:		Line 35:
	Setting up your ''Software Under Test'' to be in the right state for a test is critical for repeatability. STRIDE supports a set of [http://en.wikipedia.org/wiki/Test_fixture '''Test fixture techniques'''] that include		Setting up your ''Software Under Test'' to be in the right state for a test is critical for repeatability. STRIDE supports a set of [http://en.wikipedia.org/wiki/Test_fixture '''Test fixture techniques'''] that include
	* [[Test_Fixturing_in_C/C%2B%2B#Specifying___Fixturing_Methods \| '''Setup/Teardown''']]		* [[Test_Fixturing_in_C/C%2B%2B#Specifying___Fixturing_Methods \| '''Setup/Teardown''']]
	* [[~~Scl_test_class#Notes~~ \| '''Parameter passing to tests''']]		* [[Parameterized_Test_Units \| '''Parameter passing to tests''']]
	* [[File_Transfer_Services \| '''Host/Target file transfer''']]		* [[File_Transfer_Services \| '''Host/Target file transfer''']]
	* [[Function_Capturing \| '''Function remoting''']]		* [[Function_Capturing \| '''Function remoting''']]

Ivailop: /* Supports Off-Target Testing */

2013-09-25T23:16:55Z

Supports Off-Target Testing

← Older revision		Revision as of 23:16, 25 September 2013
Line 13:		Line 13:

	===Supports Off-Target Testing ===		===Supports Off-Target Testing ===
	Testing can also be conducted using an [[Off-Target_Environment \| '''Off-Target Environment''']] which is provided for Windows ~~and~~ Linux host machines. The [[Posix SDK \| '''Posix''']] and [[Windows SDK \| '''Windows''']] ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.		Testing can also be conducted using an [[Off-Target_Environment \| '''Off-Target Environment''']] which is provided for desktop (Windows, Linux or FreeBSD) host machines. The [[Posix SDK \| '''Posix''']] and [[Windows SDK \| '''Windows''']] ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.

	== STRIDE provides built-in automation and reporting ==		== STRIDE provides built-in automation and reporting ==

Ivailop: /* Supports Off-Target Testing */

2011-06-09T17:33:02Z

Supports Off-Target Testing

← Older revision		Revision as of 17:33, 9 June 2011
Line 13:		Line 13:

	===Supports Off-Target Testing ===		===Supports Off-Target Testing ===
	Testing can also be conducted using an [[Off-Target_Environment \| '''Off-Target Environment''']] which is provided for Windows and Linux host machines. The [[~~Linux~~ SDK \| '''~~Linux~~''']] and [[Windows SDK \| '''Windows''']] ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.		Testing can also be conducted using an [[Off-Target_Environment \| '''Off-Target Environment''']] which is provided for Windows and Linux host machines. The [[Posix SDK \| '''Posix''']] and [[Windows SDK \| '''Windows''']] ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.

	== STRIDE provides built-in automation and reporting ==		== STRIDE provides built-in automation and reporting ==

Marku: /* Runtime written in standard C */

2010-11-05T22:15:47Z

Runtime written in standard C

← Older revision		Revision as of 22:15, 5 November 2010
Line 7:		Line 7:

	=== Runtime written in standard C ===		=== Runtime written in standard C ===
	The [[Runtime_Reference \| '''STRIDE Runtime''']] is written in standard C on top of a simple [[Platform_Abstraction_Layer \| '''platform abstraction layer''']] that enables it to work ~~accross~~ platforms. It can be configured for a single process multi-threading environment or multiple process environments (i.e. Linux, Windows, Embedded RTOS, etc.). It is delivered as source code to be included in the application's build system. The transport between the host and target is configurable and supports Serial and TCP/IP by default. Custom transports are also available. The runtime has also been tailored specifically to embedded applications, overhead is minimal. It consumes very little memory for table and control block storage. [[Frequently_Asked_Questions_About_STRIDE#What_is_the_size_of_the_STRIDE_Runtime.3F \| Resource usage]] is configurable and can be tailored to the limitations of the target platform.		The [[Runtime_Reference \| '''STRIDE Runtime''']] is written in standard C on top of a simple [[Platform_Abstraction_Layer \| '''platform abstraction layer''']] that enables it to work across platforms. It can be configured for a single process multi-threading environment or multiple process environments (i.e. Linux, Windows, Embedded RTOS, etc.). It is delivered as source code to be included in the application's build system. The transport between the host and target is configurable and supports Serial and TCP/IP by default. Custom transports are also available. The runtime has also been tailored specifically to embedded applications, overhead is minimal. It consumes very little memory for table and control block storage. [[Frequently_Asked_Questions_About_STRIDE#What_is_the_size_of_the_STRIDE_Runtime.3F \| Resource usage]] is configurable and can be tailored to the limitations of the target platform.

	===Integrates With Your Existing Build System ===		===Integrates With Your Existing Build System ===

Marku at 22:09, 5 November 2010

2010-11-05T22:09:31Z

← Older revision		Revision as of 22:09, 5 November 2010
Line 1:		Line 1:
	STRIDE was designed by embedded engineers to facilitate implementing and executing '''On-Target White-box Testing'''. The various ~~uniquenesses~~ describe here make it easy for both developers and testers to participate in validating the software during the development phase. The following is a high-level list of some of the unique features of STRIDE:		STRIDE was designed by embedded engineers to facilitate implementing and executing '''On-Target White-box Testing'''. The various distinctive features describe here make it easy for both developers and testers to participate in validating the software during the development phase. The following is a high-level list of some of the unique features of STRIDE:
	<br>		<br>
	<br>		<br>

Marku at 22:06, 5 November 2010

2010-11-05T22:06:46Z

← Older revision		Revision as of 22:06, 5 November 2010
Line 1:		Line 1:
	STRIDE was designed by embedded engineers to facilitate implementing and executing '''On-Target White-box Testing'''. The various uniquenesses describe here make it easy for both developers and testers to participate in validating the software during the development phase.		STRIDE was designed by embedded engineers to facilitate implementing and executing '''On-Target White-box Testing'''. The various uniquenesses describe here make it easy for both developers and testers to participate in validating the software during the development phase. The following is a high-level list of some of the unique features of STRIDE:
	<br>		<br>
	<br>		<br>

Marku: /* STRIDE supports test implementation in C/C++ and Script */

2010-11-05T21:41:26Z

STRIDE supports test implementation in C/C++ and Script

← Older revision		Revision as of 21:41, 5 November 2010
Line 68:		Line 68:
	The test validation can be implemented in both ''native code'' on the target and ''script'' on the host.		The test validation can be implemented in both ''native code'' on the target and ''script'' on the host.

	===C/C++===		===Tests in C/C++===
	Writing API/Unit tests in [[Test_Units_Overview \| '''native code''']] is the simplest way to begin validating the software. There is no new language to learn, no proprietary editor, and your normal programming workflow is not interrupted. Also there is no special APIs required to register tests, suites, etc. Just write your test in any combination of C/C++ and the auto-generated [[Intercept_Module \| '''intercept module''']] via the [[Build_Tools \| '''STRIDE build tools''']] takes care of everything. Tests from separate teams are automatically aggregated by the system -- no coordination is required.		Writing API/Unit tests in [[Test_Units_Overview \| '''native code''']] is the simplest way to begin validating the software. There is no new language to learn, no proprietary editor, and your normal programming workflow is not interrupted. Also there is no special APIs required to register tests, suites, etc. Just write your test in any combination of C/C++ and the auto-generated [[Intercept_Module \| '''intercept module''']] via the [[Build_Tools \| '''STRIDE build tools''']] takes care of everything. Tests from separate teams are automatically aggregated by the system -- no coordination is required.

Line 78:		Line 78:
	* Critical processing / timing		* Critical processing / timing
	* and much more...		* and much more...
	===Script===		===Tests in Script===
	STRIDE also supports writing tests in [[Test_Modules_Overview \| '''Perl script''']]. When writing test scripts there are minimal dependencies on the software build process. Tests can also validate global functions, setup conditions from the host, etc.		STRIDE also supports writing tests in [[Test_Modules_Overview \| '''Perl script''']]. When writing test scripts there are minimal dependencies on the software build process. Tests can also validate global functions, setup conditions from the host, etc.

Ivailop at 00:07, 5 November 2010

2010-11-05T00:07:51Z

← Older revision		Revision as of 00:07, 5 November 2010
Line 65:		Line 65:
	* and much [[Test_API \| ''' more ... ''']]		* and much [[Test_API \| ''' more ... ''']]

	= STRIDE supports test implementation in C/C++ and Script =		== STRIDE supports test implementation in C/C++ and Script ==
	The test validation can be implemented in both ''native code'' on the target and ''script'' on the host.		The test validation can be implemented in both ''native code'' on the target and ''script'' on the host.

Line 90:		Line 90:
	In either case, the validation is done without impacting the application's performance.		In either case, the validation is done without impacting the application's performance.

	= STRIDE includes Web-based test results management =		== STRIDE includes Web-based test results management ==
	When executing '''tests''', results can be uploaded to [[STRIDE_Test_Space \| '''STRIDE Test Space''']] for persistence and analysis. Test result data can be uploaded manually (using the web interface) or automatically using the [[Stride_Runner \| '''Runner''']].		When executing '''tests''', results can be uploaded to [[STRIDE_Test_Space \| '''STRIDE Test Space''']] for persistence and analysis. Test result data can be uploaded manually (using the web interface) or automatically using the [[Stride_Runner \| '''Runner''']].
	===Centralized Hosting===		===Centralized Hosting===

Marku at 22:42, 4 November 2010

2010-11-04T22:42:26Z

← Older revision		Revision as of 22:42, 4 November 2010
Line 1:		Line 1:
	= STRIDE works on virtually any target platform =		STRIDE was designed by embedded engineers to facilitate implementing and executing '''On-Target White-box Testing'''. The various uniquenesses describe here make it easy for both developers and testers to participate in validating the software during the development phase.
			<br>
			<br>

			== STRIDE works on virtually any target platform ==
	STRIDE's cross-platform framework facilitates a ''unified testing approach'' for all team members, enabling organizations to standardize on a test workflow that is independent of the target platform being used or what branch of software is being changed.		STRIDE's cross-platform framework facilitates a ''unified testing approach'' for all team members, enabling organizations to standardize on a test workflow that is independent of the target platform being used or what branch of software is being changed.

	=== Runtime written in standard C ===		=== Runtime written in standard C ===
	The [[Runtime_Reference \| '''STRIDE Runtime''']] is written in standard C on top of a simple [[Platform_Abstraction_Layer \| '''platform abstraction layer''']] that enables it to work accross platforms. It can be configured for a single process multi-threading environment or multiple process environments (i.e. Linux, Windows CE, Embedded RTOS, etc.). It is delivered as source code to be included in the application's build system. The transport between the host and target is configurable and supports ~~serial~~ and TCP/IP by default. Custom transports are also available. The runtime has also been tailored specifically to embedded applications, overhead is minimal. It consumes very little memory for table and control block storage. [[Frequently_Asked_Questions_About_STRIDE#What_is_the_size_of_the_STRIDE_Runtime.3F \| Resource usage]] is configurable and can be tailored to the limitations of the target platform.		The [[Runtime_Reference \| '''STRIDE Runtime''']] is written in standard C on top of a simple [[Platform_Abstraction_Layer \| '''platform abstraction layer''']] that enables it to work accross platforms. It can be configured for a single process multi-threading environment or multiple process environments (i.e. Linux, Windows, Embedded RTOS, etc.). It is delivered as source code to be included in the application's build system. The transport between the host and target is configurable and supports Serial and TCP/IP by default. Custom transports are also available. The runtime has also been tailored specifically to embedded applications, overhead is minimal. It consumes very little memory for table and control block storage. [[Frequently_Asked_Questions_About_STRIDE#What_is_the_size_of_the_STRIDE_Runtime.3F \| Resource usage]] is configurable and can be tailored to the limitations of the target platform.

	===Integrates With Your Existing Build System ===		===Integrates With Your Existing Build System ===
Line 11:		Line 15:
	Testing can also be conducted using an [[Off-Target_Environment \| '''Off-Target Environment''']] which is provided for Windows and Linux host machines. The [[Linux SDK \| '''Linux''']] and [[Windows SDK \| '''Windows''']] ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.		Testing can also be conducted using an [[Off-Target_Environment \| '''Off-Target Environment''']] which is provided for Windows and Linux host machines. The [[Linux SDK \| '''Linux''']] and [[Windows SDK \| '''Windows''']] ''SDKs'' allow for a seamless transition between the real target and an Off-Target host environment.

	= STRIDE provides built-in automation and reporting =		== STRIDE provides built-in automation and reporting ==
	STRIDE enables software builds to be both fully ''functional'' and ''testable'' at the same time. Built-in ''automation and reporting'' is similar in concept to a ''debug build'' except the focus is on testing.		STRIDE enables software builds to be both fully ''functional'' and ''testable'' at the same time. Built-in ''automation and reporting'' is similar in concept to a ''debug build'' except the focus is on testing.
	===Testable Builds===		===Testable Builds===
	The ''testable build'' leverages the existing software build process by integrating into the same ''make system'' used by the development team (no one-off or special builds). Automatically included in the build is test automation controllable from the host. When tests are executed, ~~a [[Reporting_Model \| '''test report''']]~~ is generated on the host (and optionally uploaded to Test Space) which includes detailed test results and timing analysis. Developers can easily pre-flight test their source code changes before ''committing'' them to a baseline. Builds can be [[Setting_up_your_CI_Environment \| '''automatically regression tested''']] as part of the daily build process.		The ''testable build'' leverages the existing software build process by integrating into the same ''make system'' used by the development team (no one-off or special builds). Automatically included in the build is test automation controllable from the host. When tests are executed, an xml is generated on the host (and optionally uploaded to Test Space) which includes detailed test results and timing analysis. This xml file uses a custom schema for representing the [[Reporting_Model \| '''hierarchy of results''']] (suites, cases, etc.). Also included is a stylsheet specification (which will be written to the same directory as the xml file) that allows the results to be viewed as HTML in a browser.

			Developers can easily pre-flight test their source code changes before ''committing'' them to a baseline. Builds can be [[Setting_up_your_CI_Environment \| '''automatically regression tested''']] as part of the daily build process.

	===Functional Builds===		===Functional Builds===
Line 21:		Line 27:
	The application can easily be switched back to a ''non-testable'' build by simply removing the [[Runtime_Integration#STRIDE_Feature_Control \| '''STRIDE_ENABLED''']] preprocessor directive and rebuilding. This flag controls all STRIDE related source code and macros; there are no changes required to the build process to enable or disable this functionality.		The application can easily be switched back to a ''non-testable'' build by simply removing the [[Runtime_Integration#STRIDE_Feature_Control \| '''STRIDE_ENABLED''']] preprocessor directive and rebuilding. This flag controls all STRIDE related source code and macros; there are no changes required to the build process to enable or disable this functionality.

	= STRIDE offers testing techniques for deeper coverage =		== STRIDE offers testing techniques for deeper coverage ==
	STRIDE offers numerous testing techniques that enable deeper and more effective testing with less effort.		STRIDE offers numerous testing techniques that enable deeper and more effective testing with less effort.
	===Test Macros===		===Test Macros===
	[[Test_Macros \| Test Macros in native code]] provide one-line shortcuts for validating assertions and automatic report annotation in the case of failures. Test Macros are supported in both C/C++ and [[Perl_Script_APIs#Assertions \| our scripting solution]].		[[Test_Macros \| Test Macros in native code]] provide one-line shortcuts for validating assertions and automatic report annotation in the case of failures. Test Macros are supported in both C/C++ and [[Perl_Script_APIs#Assertions \| our scripting solution]].

	===~~File~~ Fixturing===		===Fixturing===
	[[~~File_Transfer_Services~~ \| ''' ~~File fixturing~~''']] ~~is another technique that can be leveraged~~ to ~~drive better testing. Test code executing on the target platform can perform~~ file ~~operations on the host remotely. This enables opening, reading, writing,~~ etc. ~~files while executing target~~-~~based~~ test ~~logic. File fixturing allows bypassing external input into the system for more controlled~~ and ~~isolated testing~~.		Setting up your ''Software Under Test'' to be in the right state for a test is critical for repeatability. STRIDE supports a set of [http://en.wikipedia.org/wiki/Test_fixture '''Test fixture techniques'''] that include
			* [[Test_Fixturing_in_C/C%2B%2B#Specifying___Fixturing_Methods \| '''Setup/Teardown''']]
			* [[Scl_test_class#Notes \| '''Parameter passing to tests''']]
			* [[File_Transfer_Services \| '''Host/Target file transfer''']]
			* [[Function_Capturing \| '''Function remoting''']]
			* etc.

			These techniques encourage best-practices such as partitioning of fixturing code and actual test code, and--in addition--these same techniques can be leveraged to dynamically configure your tests at run-time.

	===Expectations===		===Expectations===
	STRIDE leverages [[Source_Instrumentation_Overview \| '''source instrumentation''']] to provide '' [[Expectations \| '''Expectations''']] ''as an additional validation technique that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions / methods but rather verifies ''code sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called [[Test_Point \| '''Test Points''']] -- developers strategically instrument the source under test.		STRIDE leverages [[Source_Instrumentation_Overview \| '''source instrumentation''']] to provide '' [[Expectations \| '''Expectations''']] ''as an additional validation technique that can be applied to the executing software application. The execution sequencing of the code, along with state data, can be automatically validated based on ''what is expected''. This validation technique does not focus on calling functions / methods but rather verifies ''code sequencing''. This can span threads, process boundaries, and even multiple targets, as the application(s) is running. Leveraging simple macros -- called [[Test_Point \| '''Test Points''']] -- developers strategically instrument the source under test.
Line 36:		Line 50:
	* Sequencing between threads		* Sequencing between threads
	* Drivers that don't return values		* Drivers that don't return values
	* and much more ..		* and much more ...

	''Software Quality Assurance (SQA)'' can also leverage [[Expectations \| '''Expectations''']] as part of their existing functional / system testing. Because the [[Stride_Runner \| '''runner''']] is a command line utility, it is easily controlled from existing test infrastructure. SQA can use the [[Source_Instrumentation_Overview \| '''instrumentation''']] to create their own [[Reporting_Model#Suites \| '''test suite''']] using scripting that executes in concert with existing test automation.		''Software Quality Assurance (SQA)'' can also leverage [[Expectations \| '''Expectations''']] as part of their existing functional / system testing. Because the [[Stride_Runner \| '''runner''']] is a command line utility, it is easily controlled from existing test infrastructure. SQA can use the [[Source_Instrumentation_Overview \| '''instrumentation''']] to create their own [[Reporting_Model#Suites \| '''test suite''']] using scripting that executes in concert with existing test automation.
Line 45:		Line 59:
	===Other Features===		===Other Features===
	There are numerous other features that can be leveraged to facilitate deeper test coverage:		There are numerous other features that can be leveraged to facilitate deeper test coverage:
	* Remoting ~~C/C++~~ global functions		* Remoting global functions for script based API testing
	* ~~Passing parameters to tests from the host~~		* Built-in logging on test execution
	* Dynamic test / suite creation		* Dynamic test / suite creation
	* Seamless publishing to [[STRIDE_Test_Space \| '''Test Space''']]		* Seamless publishing to [[STRIDE_Test_Space \| '''Test Space''']]

← Older revision		Revision as of 23:49, 26 November 2014
Line 35:		Line 35:
	Setting up your ''Software Under Test'' to be in the right state for a test is critical for repeatability. STRIDE supports a set of [http://en.wikipedia.org/wiki/Test_fixture '''Test fixture techniques'''] that include		Setting up your ''Software Under Test'' to be in the right state for a test is critical for repeatability. STRIDE supports a set of [http://en.wikipedia.org/wiki/Test_fixture '''Test fixture techniques'''] that include
	* [[Test_Fixturing_in_C/C%2B%2B#Specifying___Fixturing_Methods \| '''Setup/Teardown''']]		* [[Test_Fixturing_in_C/C%2B%2B#Specifying___Fixturing_Methods \| '''Setup/Teardown''']]
	* [[~~Scl_test_class#Notes~~ \| '''Parameter passing to tests''']]		* [[Parameterized_Test_Units \| '''Parameter passing to tests''']]
	* [[File_Transfer_Services \| '''Host/Target file transfer''']]		* [[File_Transfer_Services \| '''Host/Target file transfer''']]
	* [[Function_Capturing \| '''Function remoting''']]		* [[Function_Capturing \| '''Function remoting''']]