Abstract Parallelism has become a way of life for many scientific programmers. A significant challenge in bringing the power of parallel machines to these programmers is providing them with a suite of software tools similar to the tools that sequential programmers currently utilize. Unfortunately, writing correct parallel programs remains a challenging task.In particular, automatic or semi‐automatic testing tools for parallel programs are lacking. This paper takes a first step in developing an approach to providing all‐uses coverage for parallel programs. A testing framework and theoretical foundations for structural testing are presented, including test data adequacy criteria and hierarchy, formulation and illustration of all‐uses testing problems, classification of all‐uses test cases for parallel programs, and both theoretical and empirical results with regard to what can be achieved with all‐uses coverage for parallel programs. Copyright © 2003 John Wiley & Sons, Ltd.

One significant challenge in bringing the power of parallel machines to application programmers is providing them with a suite of software tools similar to the tools that sequential programmers currently utilize. In particular, automatic or semi-automatic testing tools for parallel programs are lacking. This paper describes our work in automatic generation of all-du-paths for testing parallel programs. Our goal is to demonstrate that, with some extension, sequential test data adequacy criteria are still applicable to parallel program testing. The concepts and algorithms in this paper have been incorporated as the foundation of our DELaware PArallel Software Testing Aid, della pasta.

Little attention has focused on applying traditional testing methodology to parallel programs. This paper discusses issues involved in providing all-du-path coverage in shared memory parallel programs, and describes an algorithm for finding a set of paths covering all define-use pairs. To our knowledge, this is the first effort of this kind.

Load sensitive faults cause a program to fail when it is executed under a heavy load or over a long period of time, but may have no detrimental effect under small loads or short executions. In addition to testing the functionality of these programs, testing how well they perform under stress is very important. Current approaches to stress, or load, testing treat the system as a black box, generating test data based on parameters specified by the tester within an operational profile. In this paper, we advocate a structural approach to load testing. There exist many structural testing methods; however, their main goal is generating test data for executing all statements, branches, definition-use pairs, or paths of a program at least once, without consideration for executing any particular path extensively.Our initial work has focused on the identification of potentially load sensitive modules based on a static analysis of the module's code, and then limiting the stress testing to the regions of the modules that could be the potential causes of the load sensitivity. This analysis will be incorporated into a testing tool for structural load testing which takes a program as input, and automatically determines whether that program needs to be load tested, and if so, automatically generates test data for structural load testing of the program.