Frequently Asked Questions About STRIDE

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?

Behavior Testing

Scenario-based white box 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.

STRIDE’s target components consume very little memory and can be configured to run at low priorities. Similarly, tracing overhead is minimized by collecting raw data on the target, and uploading tracing information at a low priority task to the host for processing.

If tight real-time constraints are a concern, STRIDE also supports target-resident test code, which minimizes transactions or overhead over the transport. In this case, STRIDE provides a framework for automating and managing the execution of the on-target test code, and publishing the test results.

Installation and Deployment

What up-front integration is required to begin using STRIDE? *

Build system

Target Integration

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.

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 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.

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.