William Hetzel. The Complete Guide to Software Testing. QED Information Sciences, Inc., Massachusetts, 1984.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....cases, the tester is able to compare the behavior of test cases to the intended behavior of the source code. The two testing techniques are applicable during each of the three levels of testing commonly performed during software development: unit testing, system testing, and acceptance testing [5]. Unit testing (also known as module testing or element testing [4] is the exercising of a single program module, usually in an isolated environment (i.e. isolated from all other modules) 6] in various way so as to show that [it] does not satisfy its functional specification and or that its ....

....testing technique. System testing, a functional testing technique, attempts to uncover inconsistencies between a system as a whole and its requirements [6] Acceptance testing, another functional testing technique, assures the end user that the software is stable and ready for deployment [5]. The technique that discovers bugs earliest in the development cycle is unit testing. 1.1 The Problem with Unit Testing Unit testing often begins as soon as the core functionality of a program is implemented. After this first phase of coding, programmers have source code to test. The three main ....

William Hetzel. The Complete Guide to Software Testing. QED Information Sciences, Inc., Massachusetts, 1984.

....of expected output (program specification) Such a restricted view does not aid location and removal of specification errors, and cannot properly validate a product against customer needs, requirements, and expectations of quality. Our preferred definition of software testing is proposed by Hetzel [18], the process of establishing confidence that a program or system does what it is supposed to do. This implies that tests take into account user requirements, and the broad based remit of correctness. There have been some previous attempts to define testing as a life cycle activity, such ....

....with relevant stakeholder quality groups (see Figure 1) Validation viewpoints are also closely related to user interface development and evaluation. Other instances of validation viewpoints may arise during acceptance testing, front end life cycle, or operational development review. Hetzel [18] gives some key rules for software review. 1. Check for missing requirements. 2. Simplify, and eliminate requirements that are redundant or extraneous. 3. Check that the solution is the right choice. 4. Check that the solution fulfils requirements. Validation viewpoints may have scenarios ....

HETZEL, W. C.: "The Complete Guide To Software Testing" (QED Information Sciences, 1988) 2 edn.

....2,300,000 4,600,000 6,900,000 2.5. 2 Why is high testability a necessary quality There are many arguments for designing systems with high testability: The cost of verification and maintenance of software encompass typically more than half of the cost for a software project [6] 16] 30][40]. If we have a limited amount of resources we can achieve higher levels of reliability if we design for high testability rather than if we do not. Get more bang for the buck. More than 50 of all system failures can be traced back to the requirement specifications [20] 24] 67] 76] This has ....

....environment. That is, we would be able to make comparative analysis of the experienced input output domain and the domain of the new environment. For example, assume that we have designed and verified a component, c, that has an input domain I(c) corresponding to a range of integer inputs, I(c) [40,70], to a certain level of reliability, R(c) as illustrated in Figure 10 8. Consider now that we reuse this component in another system, where all things are equal except for the input domain, I 2 (c) 50,80] and that we by use and additional verification have achieved another level of ....

[Article contains additional citation context not shown here]

Hetzel B.. The Complete Guide to Software Testing. 2 edition. QED Information Sciences, 1988.

....the entire process will be compromised. Testing involves any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets the requirements [28] Software is not unlike other physical processes where inputs are received and outputs are produced [19]. Where software di#ers is in the manner in which it fails. Most physical systems fail in a fixed (and reasonably small) set of ways. By contrast, software can fail in many bizarre ways and detecting all of the di#erent failure modes for software is generally infeasible. An interesting analogy to ....

Hetzel and William C. The Complete Guide to Software Testing, 2nd ed. Wellesley, MA. : QED Information Sciences, 1988.

....structure to guide the development of test case [14] There are two main streams for structural test adequacy criteria: control ow criteria and data ow criteria. While control ow based structural testing criteria use a program s control ow structure to guide the selection of test cases [2, 8, 13], data ow based structural testing criteria use data ow relationships in a program to guide the selection of test cases [4, 9, 11] Structural testing can be performed at di erent levels, for instance, for an unit (method, or procedure) of a program or the whole program that consists of many ....

W. Hetzel, \The Complete Guide to Software Testing,", Collins, 1984.

.... (cf. 15] Testing is one of the most complex and time consuming activities within the development of real time systems [6] Typically, it consumes 50 of the overall development effort and budget since embedded systems are much more difficult to test than conventional software systems ( 2] [8], 1] 18] The examination of additional requirements like timeliness, simultaneity, and predictability make the test costly. In addition, testing is complicated by technical characteristics like the development in host target environments, the strong connection with the system environment, the ....

Hetzel, B.: The Complete Guide to Software Testing. Wellesley, MA: QED Information Sciences, 1988.

.... (cf. 19] Testing is one of the most complex and time consuming activities within the development of real time systems [7] It typically consumes 50 of the overall development effort and budget since embedded systems are much more difficult to test than conventional software systems ( 3] [9], 2] 22] The examination of additional requirements like timeliness, simultaneity, and predictability make the test costly. In addition, testing is complicated by technical characteristics like the development in host target environments, the strong connection with the system environment, the ....

Hetzel, B.: The Complete Guide to Software Testing. Wellesley, MA: QED Information Sciences, 1988.

....Testing There are many di erent classi cations of testing techniques. Functional (blackbox) testing and structural (white glass box) testing are two basic and useful testing 4 techniques. Functional testing is a process of testing to verify that the functions of a system are present as speci ed [20]. Functional testing can also be called black box testing since the source code is not evaluated or witnessed during testing. In this method, the tester constructs test cases from the program s speci cation or design documents, then executes the program and contrasts its actual behavior with that ....

B. Hetzel, The Complete Guide to Software Testing, Wellesley, Mass. : QED Information Sciences, 1988. 101

....use. Specific areas testing tools are also presented. We conclude with some suggestions for an improved ATG. More specifically the emphasis is on features that should make the tool widely acceptable to the 5 software engineering community. 2. 1 Preliminaries A number of books and articles [18, 19, 20, 21, 22, 23, 24] introduce the testing process and diverse tests generation techniques. While Myers book [18] is a classic book that shaped many of the current ideas on software testing, it needs to be supplemented with one of subsequent effort by Beizer [19] or Hetzel [22] for example, to get a more up to date ....

....and articles [18, 19, 20, 21, 22, 23, 24] introduce the testing process and diverse tests generation techniques. While Myers book [18] is a classic book that shaped many of the current ideas on software testing, it needs to be supplemented with one of subsequent effort by Beizer [19] or Hetzel [22] for example, to get a more up to date picture of software testing. Gelperin and Hetzel in [8] describe the evolution of views on the testing activity from its origin to the present time. The British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST) has recently released ....

[Article contains additional citation context not shown here]

W. Hetzel, The Complete Guide to Software Testing. QED Information Sciences Inc., 1984.

....in general, can be divided into two types: program based and functional. Most coverage tools in the market are program based. For example, VHDLcover [6] checks code coverage in VHDL, and Vericov [7] and Verisure [6] in Verilog. Such code coverage measures are similar to those in software testing [8, 9, 10]. The notions of statement coverage, branch coverage, and path coverage are extensively used in software testing. Path testing is a method often used to ensure that a particular path or a set of paths in the program is traversed. Cyclomatic Complexity is used to determine the minimum number of ....

B. Hetzel. The Complete Guide to Software Testing. Wellesley, QED Information Sciences, Inc., 1988.

....will help introduce state of the practice software testing technologies. To start with, Bill Hetzel s definition of testing is provided as follows: Testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results [HETZ88]. This definition advances the concept of testing as a process of executing a program or system with the intent of finding errors [MYER79] Hetzel suggests that there are many ways to evaluate (or test) a system without executing it. For example, you can test a requirements specification or ....

....test tools. This information is being used to help identify, evaluate, and select software test tools. The following books or articles have contributed to STSC s Test Tool Classification Scheme: Evaluation and Validation (E V) Reference Manual [CLAR91] A Complete Guide to Software Testing [HETZ88]. Testing Tools Reference Guide [DURA93] CAST Report [GRAH93] A Complete Toolkit for the Software Tester [POST92] Software Testing and Evaluation [DEMI87] An Examination of Selected Commercial Software Testing Tools: 1992 [IDA92] The STSC Test Tool Classification Scheme is primarily ....

[Article contains additional citation context not shown here]

Hetzel, Bill, A Complete Guide to Software Testing, QED Information Sciences, Inc., 1988.

....this would put too much strain on the testing budget. Of course we can use a combination of the above techniques to gain a more accurate picture of the total errors contained in a piece of software. 1 Thousand Lines Of Code 25 Figure 13 shows the automatically generated defect tracking (Hetzel, 84; McConnell, 97) information created by the tool for a sample test process. This information can be used to calculate testing status. The graph indicates the cumulative plot of defects found against testing effort (from the start of testing) Hetzel, 84) and is indicated on the top line (drawn in ....

....the automatically generated defect tracking (Hetzel, 84; McConnell, 97) information created by the tool for a sample test process. This information can be used to calculate testing status. The graph indicates the cumulative plot of defects found against testing effort (from the start of testing) Hetzel, 84) and is indicated on the top line (drawn in blue) in Figure 13. Such defect tracking plots usually take on an exponential shape, therefore they can be used as a rough estimate of the amount of testing time remaining on the project. For such estimates to be useful defect estimation metrics need ....

[Article contains additional citation context not shown here]

HETZEL, W.: "The Complete Guide To Software Testing" (QED Information Sciences, 1984)

....the quality of the test sets generated using our technique. 4 Chapter 2 Previous Work in Automatic Test Generation In this chapter we introduce the many aspects of automated tests generation by examining theoretical results as well as existent testing tools. A number of books and articles [16, 17, 18, 19, 20, 21] introduce the testing process and try to define it. Gelperin and Hetzel in [7] describe the evolution of views on the testing activity from its origin to the present time. Dynamic testing requires the execution of the program under test with data, as opposed to static testing. Static testing (see ....

....strategies 17 structural strategies are the most intuitive means to test a program. It is also an area where automation is well advanced. There is a wide range of white box strategies. Most structural ATGs are pathwise generators with the exception of CBT generators which will be examined last. [16, 17, 18, 19] are introductions to pathwise generators: they only differ by the means they overcome the path revelation problem and by the criteria they apply to generate tests. Symbolic execution is the most widely used means of generating path traversal conditions. Structural ATGs: Description In [50] ....

W. Hetzel, The Complete Guide to Software Testing. QED Information Sciences Inc., 1984.

....is easily testable is important to the test planning and budgeting process: a program that is not easily testable may have to go through several iterations of test redesign. Software engineering design methodologies have informally stated some properties of easily testable software components [3, 5, 6, 7, 14, 25, 27]. Some properties of easily testable hardware components have been also identified in [8,23] Intuitively, a software component that is testable has the following desirable properties: Test sets are small and easily generated. Exhaustive tests are infeasible. Testing pragmatics dictate finite ....

....because of a dependency on unidentified states. Programs with input output inconsistencies are not easily testable. In some sense, input output inconsistencies are a consequence of using von Neumann programming languages [1] Input Output inconsistencies can provide evidence for program errors [3, 14, 25] , but do not imply that the program has faults: a program containing unreachable statements or an infinite loop may not be easily testable but may be correct. In this paper, we formally define a property called domain testability as an extensional property of programs. Programs that are domain ....

B. Hetzel, The Complete Guide to Software Testing, 2nd ed. Wellesley: QED Information Sciences, 1988.

....accurate for use in testing. CHAPTER 1. INTRODUCTION 3 In random testing [16] program inputs are generated randomly from the input domain. Duran and Ntafos [11] present an analysis of random testing that demonstrates good code coverage and error detection, although other studies (for example, [20]) find that random data typically gives poor code coverage. The effectiveness of random testing can vary depending on the application being tested and the distribution from which test cases are selected. And, although any partition testing strategy can be made at least as effective as random ....

....is often difficult to determine the cause of an error found during integration testing, or even whether it was introduced during design or coding. While white box testing is widely used at the level of individual source modules, most integration testing is done entirely using black box techniques [20], such as equivalence partitioning and boundary value analysis [49] Also, given that design documentation often contains specifications for individual modules, even the whitebox module interface testing strategy can also be viewed as black box design testing. Many software developers tend to ....

Hetzel, W. C. The Complete Guide to Software Testing. QED Information Sciences, Wellesley, MA, 1984, ch. 6.

....auditing of the testing process, and developing tests concurrently with design and implementation. This latter is also useful for breaking code now test later practices in software engineering, and helping develop a parallel testing activity for all software life cycle phases as advocated in [Het88]. Our rather general interest in using formal methods to assist software testing leads us towards developing a framework in which to conduct specification based testing, which includes a formal model of test suites. The framework directly addresses some particular aspects of specification based ....

B. Hetzel. The Complete Guide to Software Testing. QED Information Sciences, Wellesley, Massachusetts, second edition, 1988.

No context found.

Hetzel B.. The Complete Guide to Software Testing. 2 nd edition. QED Information Sciences, 1988. 30

No context found.

William Hetzel. The Complete Guide to Software Testing. QED Information Sciences, 1984.

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