TABLE OF CONTENTS The study of software testing provides a way to deal with problems of disparate and extensive input domains: divide and conquer, So-called subdomain testing divides the input domain D into a manageable number of subsets (subdomains), often but not always disjoint, and treats each in isolation. Thus the primary practical method of system testing is functional (or black-box) testing, in which system functions are gleaned from the requirements document and each such function is tested separately on its subdomain. This subdomain is all the system inputs that should result in a particular function being performed. Similarly, structural-testing methods have subdomains defined by grouping those inputs that execute some particular program element. For example, a statement-testing subdomain for one statement comprises all those inputs that cause that statement to be executed.
Once a subdomain breakdown of the input space D has been chosen, subdomain testing proceeds by insisting that tests be selected in each subdomain. Hence all the functions, statements, etc., will necessarily be tried by such a test. There is a substantial literature on subdomain testing, [3] beginning with the work of Howden [Howden (1975); Howden (1976)] and continuing to this day [Hamlet (2000)].
In software reliability engineering (SRE), subdomains are used in a way that is close to the present purpose. In SRE, functional subdomains are assigned empirical usage probabilities, thus defining a crude kind of usage profile for a system. John Musa has been a primary advocate of obtaining...
