10 citations found. Retrieving documents...
Howden WE (1980) Functional program testing. IEEE Trans Software Eng SE-6:162--169

 Home/Search   Document Not in Database   Summary   Related Articles   Check  

This paper is cited in the following contexts:
A Tool for Estimating Software Testing Requirements - Bieman (1990)   (Correct)

....paths criteria. The all statements criterion requires that all program statements be executed during testing, and the all branches criterion requires that all control flow branches be tested. Branch testing is considered a minimum control flow coverage requirement and is described in [GG75, How75, How80] Other criteria are based on the flow of data through a program [Her76, LK83, Nta84, RW85] These data flow criteria suggest the testing of specific sets of paths that follow the flow of data from expressions through assignments to other expressions. In general, data flow criteria tend to be ....

W. E. Howden. Functional program testing. IEEE Trans. Software Engineering, SE6 (2):162--169, March 1980.


User's Manual as a Requirements Specification - Berry, Daudjee, Dong, Nelson.. (2001)   (Correct)

....A little thought shows a fundamental equivalence between scenarios and test cases. Both must cover all possible inputs and uses of the CBS under consideration, i.e. the CBS under design or test. Obtaining this full coverage is hard. The literature on testing abounds with proof of this difficulty [3, 13, 15]. Indeed, after flo had been used about a year with no problems, an input was given that flo drew incorrectly, collapsing two boxes into one, with their interior texts overwriting each other. Without going into too many details, the input involved nested conditionals. It turned out that Wolfman ....

Howden, W.E., "Functional Program Testing," IEEE Transactions on Software Engineering SE-6(2), p.162--169 (March 1980).


Software Design, Automated Testing, and Maintenance A.. - Daniel Hoffman And   (Correct)

....and the environment. Environment variables are divided into two groups: input variables which the system may read, but not modify and output variables which may be written but not read. For example, the ISHAM screen can be modeled with the output environment variable scn: scn : sequence [24][80] of char scn[r] c] is the character at screen row r and column c, with numbering zero relative and beginning at the upper left corner. According to the declaration, scn[23] 0] x is true if there is an x in the lowest, leftmost position of the terminal screen. The State machine section is ....

....formatted screen output, 2) a detailed format for precisely describing screen updates, 3) a new execution phase FSM, and (4) several new expected changes. 5.4. 2 RS section: Environment variables Two new environment variables are needed: stdin : string UNIX standard input scn : sequence [24][80] of char scn[r] c] is the character at screen row r and column c, with numbering zero relative and beginning at the upper left corner. As shown in Figure 5.10, we divide scn into screen fields that are either fixed or varying. The fixed fields are written when ISHAM execution begins and remain ....

[Article contains additional citation context not shown here]

W. E. Howden. Functional program testing. IEEE Trans. Soft. Eng., 6(2):162--169, 1980.


Unit Operations for Automated Class Testing - Daley, Hoffman, Strooper (2000)   (3 citations)  (Correct)

....and has seen considerable practical application. Standard texts on software testing [26] include extensive discussion of boundary testing, and many practitioners today argue for its simplicity and effectiveness. The earliest careful analysis of boundary values testing was due to Howden [21]. Howden drew upon his own work on weak mutation testing [22] and also that of Foster [12, 13] a test practitioner, who had documented the error sensitivity of boundary values for testing arithmetic expressions. A recent study [32] on retrospective fault data from an industrial project compared ....

W.E. Howden. Functional program testing. IEEE Trans. Soft. Eng., SE-6(3):162--169, 1980.


Experience With The Cost Of Different Coverage Goals For Testing - Marick (1991)   (7 citations)  (Correct)

....for infeasibility, an argument was made that the code was correct as written. This was always trivial. The arguments were not written down. #################################### 2 The name was coined by Johnny Zweig. This stage is similar to Howden s functional testing: see [Howden80a] [Howden80b], or [Howden87] 3) For feasible conditions, a test condition was written down. It described the coverage condition in terms of the unit s input variables. After all test conditions were collected, they were combined into test cases in the usual way. 2.2.2.1. Feasibility Rules Weak mutation ....

W. E. Howden. "Functional Program Testing". IEEE Transactions on Software Engineering, vol. SE-6, No. 2, pp. 162-169, March, 1980.


Unknown - Ncsc-Tg- Version-   (Correct)

....of the program. The internal program parts correspond to the functional ideas used in building the program. Different forms of testing procedures are used depending upon different kinds of functional synthesis (e.g. control, algebraic, conditional, and iterative synthesis described in [1] and [7]) As pointed out in [9] only the control synthesis approach to functional testing is suitable for security testing. Page 18 In control synthesis, functions are represented as sequences of other functions. Each function in a sequence transforms an input state into an output state, which may be ....

....The assignment of program functions, procedures, and subroutines to the state transition functions of the graph is usually left to the individual programmer s judgment. Examples of how the control synthesis graphs are built during the program development and integration phase are given in [1] and [7]. The suitability of the control synthesis approach to TCB testing becomes apparent when one identifies the nodes of the control synthesis graph with the access checks within the TCB and the arcs with data states and outcomes of previous access checks. This representation, which is the dual of the ....

Howden, W.E., "Functional Program Testing," IEEE Transactions on Software Engineering, Vol. SE-6, No. 3, May 1980, pp. 162-169.


Original Article - Berry Daudjee Dong   (Correct)

No context found.

Howden WE (1980) Functional program testing. IEEE Trans Software Eng SE-6:162--169


Estimation of Software Reliability by Stratified Sampling - Podgurski, Masri.. (1999)   (1 citation)  (Correct)

No context found.

HOWDEN, W. E. 1980. Functional program testing. IEEE Trans. Softw. Eng. SE-6, 2 (Mar.), 162--169.


Testing of Object-Oriented Programming Systems (Oops): A.. - Hayes (1994)   (Correct)

No context found.

Howden, W. E., "Functional Program Testing," IEEE Transactions on Software Engineering, SE-6(2): March 1980, 162-169.


SREPT: Software Reliability Estimation and Prediction Tool - Srinivasan Ramani Swapna (1998)   (Correct)

No context found.

W.E. Howden, "Functional Program Testing", IEEE Trans. on Software Engineering, Vol. 6, No. 2, pp.162-169, March 1980.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC