Frequently Asked Questions About STRIDE: Difference between revisions
| Line 69: | Line 69: | ||
;Build System Integration | ;Build System Integration | ||
:To automatically generate harnessing code and test metadata, several STRIDE-related executables are added to your software build process. | :To automatically generate harnessing code and test metadata, several STRIDE-related executables are added to your software build process. | ||
== What process changes are required to adopt STRIDE == | == What process changes are required to adopt STRIDE == | ||
Revision as of 23:19, 4 June 2010
Frequently Asked Questions about STRIDE™
The following is a list of high level questions often asked by customers.
Testing
What specific testing techniques are enabled by STRIDE?
Unit Testing
API Testing
Behavior Testing
Scenario-based white box testing.
What about source instrumentation bloat?
Using Test Points / Logs
Should I leave the testability in?
Are all Test Points active?
Can developers really enable QA to create effective white-box tests?
Yes if you do the following
No if you don't do anything different
Maybe
What do you mean by behavior testing?
How are test cases managed?
Individual test cases are organized into test units (on-target c/c++ tests) and test modules (host-based script tests) which typically target the verification of a specific subsystem or component.
Test units and test modules are runnable individually or in sequence with other test units/mocules.
Test unit/module results may also be further organized into named test suites, which provide convenient results roll-ups to groups of test units/modules.
Can I use STRIDE together with test equipment?
External test equipment can further leverage STRIDE's value by providing sophisticated test harnessing.
The operation of computer-controlled test equipment can be automatically synchronized with STRIDE test unit/module execution for repeatable execution of complicated scenarios.
Can I use STRIDE if my embedded code has real-time constraints?
The STRIDE components and architecture are tailored specifically to embedded applications; overhead is minimal.
Resource usage is configurable for extremely sensitive applications, but typical resource usage is shown below:
| Aspect | Resources |
|---|---|
| STRIDE Runtime Code Space | TBD |
| STRIDE Runtime Memory | TBD |
| STRIDE Threads | 2 Threads; configurable priority; blocked when inactive |
Installation and Deployment
What up-front integration is required to begin using STRIDE?
- PAL and Runtime Integration
- To support STRIDE remoting, the common STRIDE Runtime and OS-specific Platform Abstraction Layer (PAL) must be integrated into the target environment. PAL implementations exist for many popular embedded operating systems.
- Build System Integration
- To automatically generate harnessing code and test metadata, several STRIDE-related executables are added to your software build process.
What process changes are required to adopt STRIDE
Testable Build
Creating and maintaining Test Assets
Etc.
How much time and resources are required to get STRIDE running in a typical embedded environment? *
What does it take to train developers in using STRIDE? *
How does STRIDE support continuous integration?
The key principle of continuous integration is regular testing of your software--ideally done in an automated fashion. STRIDE tests are reusable and automated. Over time, these tests accumulate, providing more and more comprehensive coverage.
By automating the execution of tests and results publication via Test Space with every software build, development teams gain immediate feedback on defects and the health of their software. By detecting and repairing defects immediately, the expense and time involved with correcting bugs is minimized.