Partager via


Modular Stress Test Harness

The harness for the Modular Stress Test is a single application that you run on the target device. The harness runs the test modules, manages the lifespan of the test modules, and records the results of tests. The harness also monitors statistics of the target device such as memory usage. The harness reports the state of the target device and provides you with cumulative test results.

The harness has following features:

  • The harness manages test modules that perform the actual testing.
  • The harness runs a specified number of modules at all times. The harness selects test modules from an .ini file that you can configure.
  • The harness tracks memory and object store usage over time, records whether each test module passes or fails, and detects when a test hangs. The harness records the state of the system in the results for the test.
  • The harness provides the ability to set the level of logging verbosity for the test modules. With verbosity levels, you can filter the information displayed in the Output window for Microsoft® Platform Builder.
  • The harness can run in a client-only configuration when a development workstation is not required. If a connection to a development workstation is available, the harness can create files for the test results and test history on the development workstation. If the target device is connected to a network, the harness can create files for the test results and test history on a network share.
  • The harness can be configured from the command line. For information about the command-line options for the harness, see Modular Stress Test Command-Line Options.

The harness governs the nature and intensity of the stress environment by controlling the following four parameters:

  • The mix of test modules. By default, the Modular Stress Test runs the largest subset of test modules corresponding to the configuration of your platform. You can modify this mix to test individual components. You can also create and add your own test modules. For information about creating a test module, see Custom Module Creation for the Modular Stress Test.
  • The number of concurrently running test modules. The harness keeps a specified number of modules running concurrently at all times. When an instance of a test module exits, the instance is replaced by a new instance of a test module that is selected at random from the module mix. When the harness runs a number of modules concurrently, it may provide information about the interoperability of the parts of the OS being tested.
  • The length of time over which each test module runs. The harness can request that test modules run for any given length of time. A short runtime tends to provide creation, destruction, connection, disconnection, initialization, and cleanup scenarios. A long runtime tends to provide information about the accumulation of resources. By default, the harness runs each test module for 10 minutes, which provides a reasonable mix of both types of stress testing.
  • Overall duration of the test. The Modular Stress Test by nature of its design introduces varied testing combinations over the course of a testing run. You are more likely to uncover bugs or confirm that your platform is robust when you increase the overall duration of the test. The default duration is 900 minutes.

See Also

Modular Stress Test | Running the Modular Stress Test

 Last updated on Friday, October 08, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.