Difference between revisions of "Types of Testing Supported by STRIDE"
(→Behavior Testing) |
|||
| Line 1: | Line 1: | ||
= Overview = | = Overview = | ||
| + | |||
| + | One of the questions that should be asked is ''what is the '''value''' of the test?''. If the test does not discover any defects or does not provide ongoing regression than the value is questionable. Also ''what is the '''effort''' in implementing the test?''. STRIDE has been uniquely designed to support maximizing the '' '''value''' '' of the test while minimizing the '' '''effort''' '' to implement it. | ||
| + | |||
The STRIDE test system supports three general types of testing: | The STRIDE test system supports three general types of testing: | ||
* '''Unit Testing''' | * '''Unit Testing''' | ||
| Line 5: | Line 8: | ||
* '''Behavior Testing''' | * '''Behavior Testing''' | ||
| − | + | ||
| − | |||
= Unit Testing = | = Unit Testing = | ||
[[Test Units Overview | STRIDE Unit Testing]] supports the general model found in typical [http://en.wikipedia.org/wiki/XUnit xUnit-style] testing frameworks. STRIDE also offers a number of [[Test API | additional features]] optimized for testing embedded. But traditional '''Unit Testing''' does present a number of challenges for testing embedded software: | [[Test Units Overview | STRIDE Unit Testing]] supports the general model found in typical [http://en.wikipedia.org/wiki/XUnit xUnit-style] testing frameworks. STRIDE also offers a number of [[Test API | additional features]] optimized for testing embedded. But traditional '''Unit Testing''' does present a number of challenges for testing embedded software: | ||
| Line 14: | Line 16: | ||
* Typically not well suited for '''others''' to participate in the test implementation (too much internal knowledge required) | * Typically not well suited for '''others''' to participate in the test implementation (too much internal knowledge required) | ||
* Can be difficult to automate execution of the full set of tests on the real target device | * Can be difficult to automate execution of the full set of tests on the real target device | ||
| + | |||
= API Testing = | = API Testing = | ||
| − | STRIDE supports '''API Testing''' leveraging the same [[Test Units Overview | techniques]] available for Unit Testing. The difference is the focus of API Testing, which often has a better ''return-on-effort''. API Testing traditionally is about driving well-defined public interfaces. The design of ''public interfaces'' | + | STRIDE supports '''API Testing''' leveraging the same [[Test Units Overview | techniques]] available for Unit Testing. The difference is the focus of API Testing, which often has a better ''return-on-effort''. API Testing traditionally is about driving well-defined public interfaces. The design of ''public interfaces'' typically lends itself to testing in isolation ''without'' implementing special test logic (i.e. no stubbing required). Also public APIs are most likely documented. As a result, ''others'' can more easily participate in the test implementation. Although API Testing often represents a smaller percentage of the software being exercised, the '''value''' and '''effort''' required is well understood. |
| + | |||
= Behavior Testing = | = Behavior Testing = | ||
| − | STRIDE | + | STRIDE supports '''Behavior Testing''' which is different than Unit Testing or API Testing in that it does not focus on calling functions and validating return values. Behavior Testing, rather, validates the ''expected sequencing of the software'' executing under normal operating conditions. To learn more about the uniqueness of Behavior Testing click [[What_is_Unique_About_STRIDE#STRIDE_includes_behavior-based_testing_techniques | '''here''']]. We believe that Behavior Testing has a very high ''return-on-effort'' and can be easily deployed into legacy software systems. |
Some of the advantages of '''Behavior Testing''': | Some of the advantages of '''Behavior Testing''': | ||
| Line 28: | Line 32: | ||
* Others can easily participate in test implementation | * Others can easily participate in test implementation | ||
* Test can be written using [[Perl_Script_APIs#STRIDE::Test | scripting on the host]] and [[Expectation_Tests_in_C/C%2B%2B | native target code]] | * Test can be written using [[Perl_Script_APIs#STRIDE::Test | scripting on the host]] and [[Expectation_Tests_in_C/C%2B%2B | native target code]] | ||
| − | * Validation is fully automated (not done manually by | + | * Validation is fully automated (not done manually by tribal experts) |
| + | * Design knowledge is extracted and made available to other team members via [[Source Instrumentation Overview | instrumentation]] | ||
* Very useful for continuous integration | * Very useful for continuous integration | ||
| − | |||
[[Category: Overview]] | [[Category: Overview]] | ||
Revision as of 10:15, 11 June 2010
Overview
One of the questions that should be asked is what is the value of the test?. If the test does not discover any defects or does not provide ongoing regression than the value is questionable. Also what is the effort in implementing the test?. STRIDE has been uniquely designed to support maximizing the value of the test while minimizing the effort to implement it.
The STRIDE test system supports three general types of testing:
- Unit Testing
- API Testing
- Behavior Testing
Unit Testing
STRIDE Unit Testing supports the general model found in typical xUnit-style testing frameworks. STRIDE also offers a number of additional features optimized for testing embedded. But traditional Unit Testing does present a number of challenges for testing embedded software:
- Testing functions/class in isolation requires a lot of extra work, especially if not designed upfront
- Testing legacy software might have very limited value (i.e. can't find any defects)
- Typically not well suited for others to participate in the test implementation (too much internal knowledge required)
- Can be difficult to automate execution of the full set of tests on the real target device
API Testing
STRIDE supports API Testing leveraging the same techniques available for Unit Testing. The difference is the focus of API Testing, which often has a better return-on-effort. API Testing traditionally is about driving well-defined public interfaces. The design of public interfaces typically lends itself to testing in isolation without implementing special test logic (i.e. no stubbing required). Also public APIs are most likely documented. As a result, others can more easily participate in the test implementation. Although API Testing often represents a smaller percentage of the software being exercised, the value and effort required is well understood.
Behavior Testing
STRIDE supports Behavior Testing which is different than Unit Testing or API Testing in that it does not focus on calling functions and validating return values. Behavior Testing, rather, validates the expected sequencing of the software executing under normal operating conditions. To learn more about the uniqueness of Behavior Testing click here. We believe that Behavior Testing has a very high return-on-effort and can be easily deployed into legacy software systems.
Some of the advantages of Behavior Testing:
- Test with fully functional software builds (no isolation issues)
- Applies to a large percentage of the software
- Can execute with functional and black-box testing
- Easy to add Test Points to provide coverage
- Others can easily participate in test implementation
- Test can be written using scripting on the host and native target code
- Validation is fully automated (not done manually by tribal experts)
- Design knowledge is extracted and made available to other team members via instrumentation
- Very useful for continuous integration
