Specifying operational profiles for modules

Abstract

We describe a technique for specifying operational profiles for modules. The technique is more general than those of the current literature and allows more accurate specification of module usage. We also outline an algorithm for automatically generating random test cases from any such operational profile specification for a module, such that the test cases correspond to a random sampling of the module's input in actual operation. Operational-based statistical estimations, such as operational reliability, may be more meaningful when our specification method and generation algorithm are used, because our method permits more precise specifications than do other methods in the current literature.

Test case generation for the task tree type of architecture

“…In particular the method proposed by Woit [9][10][11][12] has been recognized by the industry as a de facto standard in [14]. Of course, further research is always needed, but best practice and standards should be used and obeyed whenever possible.…”

“…Later on, much of the work was done by Woit in her Ph.D. thesis and related papers [9][10][11][12]. Although her early work was focused on individual software modules it was immediately clear that it could be used on system level, too.…”

“…Unfortunately, most of the techniques and methods developed for sequential and traditional concurrent software are not directly applicable to massively parallel software. For example, certifying declared operational reliability figure of the given sequential software product is a well-established process for the sequential type of software [9][10][11][12]14]. As defined by Woit in [11], the operational reliability r (in this paper also referred to simply as reliability) of a software product is the probability that a product execution, selected at random according to given operational profile, will not fail.…”

Software testing with an operational profile

“…For example, Bousquet et al [1998] embed a binary decision diagram, a tree, into the Markov structure to model specific software usage. On the other hand, Woit [1993] used a set-based approach and grouping of prefixes of various lengths with similar impact on the selection of the next input into sets. Runeson and Wohlin [1993] express N-conditionality between leaf nodes (each representing a profile in a profile hierarchy) and 1-conditionality using a Markov chain to represent transitions within a leaf node (modeling microbehaviors within a profile).…”

The incorporation of testing into formal verification: Direct, modular, and hierarchical correctness degrees

“…Woit [56] deals with the problem of specifying and using results about tested modules in a way quite closely related to our project. However, she also deviates from our paradigm by being primarily concerned with algorithms for deriving random test cases.…”