Revision as of 17:07, 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:

Typical resource usage
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.

How will STRIDE affect my real-time constraints

Size of runtime / intercept module

Typical RAM usage

Processing Impact

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? *

A typical environment using a common embedded RTOS can be up and running in a week or less. Custom RTOSes or environments using messaging or host-based simulators will require more time to integrate the necessary support. During this period, S2 typically works with a customer’s developer who is knowledgeable about their software architecture, RTOS primitives, and software build environment.

What does it take to train developers in using STRIDE? *

How does STRIDE support continuous integration? *

The principle in continuous integration is to continually test your software, ideally through automation. The STRIDE test scripts created by developers are reusable and automated. Over time, these scripts accumulate, providing more and more comprehensive coverage. By integrating STRIDE to the build environment and automating the execution of scripts 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.

@@ Line 62: / Line 62: @@
 = Installation and Deployment =
-== What up-front integration is required to begin using STRIDE? * ==
+== What up-front integration is required to begin using STRIDE? ==
-Build system
-Target Integration
+;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.
-To support remotely accessing function calls, the STRIDE Runtime and Platform Abstraction Layer (PAL) components must be integrated into the target environment, including support for the available transport. S2 already has pre-ported or reference PALs available for many popular embedded RTOSes. In this case, there is only a few days of integration and verification work.
+;Build System Integration
+To automatically generate harnessing code and test metadata, several STRIDE-related executables are added to your software build process.
-For custom or new OSes, implementing a PAL takes only a few extra days. A new PAL involves implementing 10 – 12 well-defined primitive interfaces, based on common OS services. In either case, S2 is generally involved with this process in order to ensure proper integration.
-If the software architecture includes a messaging subsystem, then a custom remote message server (RMS) component is also required. S2 generally undertakes this work and delivers, integrates, and verifies the RMS with the customer. The scope of the RMS varies depending on the complexity of the messaging subsystem.
 == How will STRIDE affect my real-time constraints  ==

Difference between revisions of "Frequently Asked Questions About STRIDE"