STRIDE Overview: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 11: Line 11:




STRIDE supports three general [[Types_of_Testing_Supported_by_STRIDE | '''types of testing''']]:
* Unit Testing,
* API Testing, and
* Integration Testing.


 
==STRIDE Framework ==
==The STRIDE Framework ==


[[image:STRIDE 4.2 Framework-a.jpg |right|400px|border ]]
[[image:STRIDE 4.2 Framework-a.jpg |right|400px|border ]]
Line 26: Line 21:
=== Runner ===
=== Runner ===
The '' '''Framework''' '' also contains a lightweight [[Stride_Runner | '''Runner''']] application that is a host-based command-line utility for interactive and automated test execution. It also provides services for result publishing to our [[STRIDE_Test_Space | '''hosted web application''']].
The '' '''Framework''' '' also contains a lightweight [[Stride_Runner | '''Runner''']] application that is a host-based command-line utility for interactive and automated test execution. It also provides services for result publishing to our [[STRIDE_Test_Space | '''hosted web application''']].
<br>


===Build Tools===
===Build Tools===
Line 31: Line 28:


The [[STRIDE_Build_Tools | '''STRIDE Build Tools''']] are a set of command-line utilities that integrate with your target software build process. They preprocess standard C/C++ header files that contain STRIDE test declarations to  auto-generate source code comprising a custom [[Intercept_Module | '''Intercept Module''']]. The intercept module code is then built with the Runtime to provide ''fixturing'' and ''harnessing'' test logic as part of your build image.
The [[STRIDE_Build_Tools | '''STRIDE Build Tools''']] are a set of command-line utilities that integrate with your target software build process. They preprocess standard C/C++ header files that contain STRIDE test declarations to  auto-generate source code comprising a custom [[Intercept_Module | '''Intercept Module''']]. The intercept module code is then built with the Runtime to provide ''fixturing'' and ''harnessing'' test logic as part of your build image.
== Testing Features ==
STRIDE has been designed to deliver a broad spectrum of [[What_is_Unique_About_STRIDE#Offers_testing_techniques_for_deeper_coverage | '''testing capabilities''']] that enable teams to '''''test earlier and more effectively'''''. Unique features such as [[Test_Macros | '''test macros''']], [[File_Transfer_Services | '''file fixturing''']], and [[Using_Test_Doubles | '''function doubling''']] facilitate deeper test coverage of your software components.
STRIDE also provides [[Expectations |'''Expectations''']] as an added validation technique. Expectation testing is unique in that it ''does not'' focus on calling functions and validating return values. The technique rather validates the '''''expected sequencing of the software, along with state data,''''' executing under normal operating conditions. This can span threads and process boundaries, and even multiple targets, as the application(s) is running. Developers insert simple instrumentation macros called [[Test_Point | '''Test Points''']] to enable this approach, making it especially effective for testing legacy code.
This kind of ''validation'' technique can be used to test broadly scoped scenarios that span your entire system; For example:
* Complete data flow through system components
* Communication between threads, processes, and targets
* Behavior of stacks, state machines, and drivers
* … and much more
The tests can be implemented in both [[Test_Units_Overview | '''native code''']] on the target and [[Test_Modules_Overview | '''script''']] on the host.


==STRIDE Test Space==
==STRIDE Test Space==
Line 56: Line 38:
<br>
<br>
<br>
<br>
== STRIDE Testing Features ==
STRIDE supports three general [[Types_of_Testing_Supported_by_STRIDE | '''types of testing''']]:
* Unit Testing,
* API Testing, and
* Integration Testing.
STRIDE has been designed to deliver a broad spectrum of [[What_is_Unique_About_STRIDE#Offers_testing_techniques_for_deeper_coverage | '''testing capabilities''']] that enable teams to '''''test earlier and more effectively'''''. Unique features such as [[What_is_Unique_About_STRIDE#Test_Macros | '''assertion macros''']], [[What_is_Unique_About_STRIDE#Fixturing | '''fixturing''']], and [[What_is_Unique_About_STRIDE#Test_Doubles | '''function doubling''']] facilitate deeper test coverage of your software components. STRIDE also provides [[What_is_Unique_About_STRIDE#Expectations |'''Expectations''']] as an added validation technique. Expectation testing is unique in that it ''does not'' focus on calling functions and validating return values. The technique rather validates the expected sequencing of the software, along with state data, executing under normal operating conditions.
Tests can be implemented in both [[What_is_Unique_About_STRIDE=#C.2FC.2B.2B | '''native code''']] on the target and [[What_is_Unique_About_STRIDE#Script | '''script''']] on the host.
<br>
<br>
<br>
<hr/>
<hr/>



Revision as of 22:40, 4 November 2010

Welcome to the STRIDE™ Wiki

STRIDE™ is a test infrastructure used by engineers to implement and execute tests for validating embedded software executing On-Target. STRIDE has been designed specifically for On-Target White-box Testing.

The STRIDE system consists of:

A software Framework
enabling the creation of fully automated Test Assets that repeatably verify the internal design of your software
A hosted Web Application - Test Space
for storing and analyzing test results, thus providing on-demand availability of timely, accurate, and meaningful test results data


STRIDE Framework

STRIDE 4.2 Framework-a.jpg

Runtime

The STRIDE Framework includes a Runtime software source package that supports connectivity with the host system. It is integrated with embedded application software to enable testability to be compiled into the software with minimal impact on performance or the size of the application. The software is agnostic to the RTOS, CPU, and transport. It can be configured to support multi-processes, multi-threads, user/kernel spaces, or a simpler single application process. Typically the runtime is configured as a background thread and only executes when running tests. It provides services for testing and source instrumentation.

Runner

The Framework also contains a lightweight Runner application that is a host-based command-line utility for interactive and automated test execution. It also provides services for result publishing to our hosted web application.


Build Tools

STRIDE 4.2 Framework-b.jpg

The STRIDE Build Tools are a set of command-line utilities that integrate with your target software build process. They preprocess standard C/C++ header files that contain STRIDE test declarations to auto-generate source code comprising a custom Intercept Module. The intercept module code is then built with the Runtime to provide fixturing and harnessing test logic as part of your build image.

STRIDE Test Space

STRIDE 4.2 Test Space.jpg

Once tests have been implemented, they are executed using the host-based Runner application. Resulting test reports can be automatically uploaded to our web application - STRIDE Test Space. This application allows both local and distributed team members to track and collaborate on results.

Failure resolution is optimized by centralizing results and providing specific source information related to failures. Test Space also has built-in collaboration features in the form of email notification for new results and regression against a baseline as well as messaging.




STRIDE Testing Features

STRIDE supports three general types of testing:

  • Unit Testing,
  • API Testing, and
  • Integration Testing.

STRIDE has been designed to deliver a broad spectrum of testing capabilities that enable teams to test earlier and more effectively. Unique features such as assertion macros, fixturing, and function doubling facilitate deeper test coverage of your software components. STRIDE also provides Expectations as an added validation technique. Expectation testing is unique in that it does not focus on calling functions and validating return values. The technique rather validates the expected sequencing of the software, along with state data, executing under normal operating conditions.

Tests can be implemented in both native code on the target and script on the host.


For more details refer to the following: