Difference between revisions of "Types of Testing Supported by STRIDE"
(→API Testing) |
(→Behavior Testing) |
||
| Line 20: | Line 20: | ||
== Behavior Testing == | == 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 | + | STRIDE also 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 and state of the software'' executing under normal operating conditions. To learn more about the uniqueness of Behavior Testing [[What_is_Unique_About_STRIDE#STRIDE_includes_behavior-based_testing_techniques | '''read 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''' are: |
| − | * | + | * Tests are performed with fully functional software builds -- there are no code isolation issues challenges |
| − | * | + | * The technique is easy to grasp and is applicable to a large percentage of code bases |
* Can execute with functional and black-box testing | * Can execute with functional and black-box testing | ||
| − | * | + | * It's aasy to add [[Test Point | Test Points]] to provide coverage |
* Others can easily participate in test implementation | * Others can easily participate in test implementation | ||
* Tests can be written using [[Perl_Script_APIs#STRIDE::Test | scripting on the host]] and [[Expectation_Tests_in_C/C%2B%2B | native target code]] | * Tests 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 | + | * Validation is fully automated and thus does not rely on manual interpretation by domain experts |
* Design knowledge is extracted and made available to other team members via [[Source Instrumentation Overview | instrumentation]] | * 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 | ||
Revision as of 16:36, 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, then 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 model found in typical xUnit-style testing frameworks. STRIDE also offers a number of additional features optimized for testing embedded software. Traditional Unit Testing presents a number of challenges in testing embedded software:
- Testing functions/classes in isolation requires a lot of extra work, especially if your software was not designed upfront for testability
- Testing legacy software might have limited value, particularly if the software is stable with respect to defects
- The software is often not well suited for others to participate in the test implementation, since there is too much internal knowledge required to be productive
- It can be difficult to automate execution of the full set of tests on the real target device
API Testing
STRIDE supports API Testing by leveraging the same techniques available for Unit Testing. API Testing differs from unit testing in that the tests focus on direct testing of a well-defined interface. This kind of testing is typically easy to scope depends on the size of the interface and often has a better return-on-effort. The design of public interfaces often lends itself to testing in isolation without implementing special test logic (i.e. no stubbing required), which make the test implementation simpler. What's more, public APIs are most likely documented. As a result, non domain experts 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 also 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 and state of the software executing under normal operating conditions. To learn more about the uniqueness of Behavior Testing read 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 are:
- Tests are performed with fully functional software builds -- there are no code isolation issues challenges
- The technique is easy to grasp and is applicable to a large percentage of code bases
- Can execute with functional and black-box testing
- It's aasy to add Test Points to provide coverage
- Others can easily participate in test implementation
- Tests can be written using scripting on the host and native target code
- Validation is fully automated and thus does not rely on manual interpretation by domain experts
- Design knowledge is extracted and made available to other team members via instrumentation
- Very useful for continuous integration
