Presentation of visual program test coverage information

Details Presentation of visual program test coverage information Presentation of visual program test coverage information

1998-09-16

2001-04-03

Chaki, Kakali (Department: 2762)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C717S152000, C717S152000, C714S038110, C714S039000, C714S045000, C714S046000, C345S215000, C345S215000, C345S215000, C345S960000

Reexamination Certificate

active

06212675

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer software, and deals more particularly with a method, system, and computer program for presenting visual program test coverage information. The information is presented in the same general visual manner in which a visual programmer creates a visual program. A number of alternative presentation styles are defined.
2. Description of the Related Art
Testing is an important part of the software development cycle. The motivation for testing software is to raise the quality and reliability of the program, and to establish confidence that the program does what it is supposed to do. Assuming that programs contain errors, the purpose of testing is to find as many of the errors as possible. Thus, testing may be considered as the process of executing a program with the intent of finding errors.
Testing is a costly and time-consuming activity. Finding all the errors in a program is virtually impossible, because to do this, one must test the program for all possible inputs in all possible states-which, except for the most trivial of programs, is a prohibitively large number. The more tests that are executed, the higher the confidence level in the quality of the program code, but with a corresponding increase in time and money invested in the testing process. Since there can be no proof that, at a point in time, the program has no more bugs, the question arises: how much testing is sufficient? Techniques and tools have been developed to assist in evaluating the sufficiency of the testing. The main technique for demonstrating that testing has been thorough is called test coverage analysis.
Test coverage analysis is discussed in detail in “Software Testing Techniques”, 2nd edition, by Boris Beizer, published by International Thomson Computer Press (1990). Simply stated, the idea of test coverage analysis is to create, in some systematic fashion, a large and comprehensive list of tasks corresponding to the program under test. This list of tasks is then compared to the tasks covered in the actual test, from which various metrics can be determined. The most widely practiced coverage technique is code coverage, where the list of tasks to be covered is derived statically from analysis of the syntactic properties of the program code. For example, statement coverage and branch coverage are typical code coverage metrics. Statement coverage is concerned with counting the number of statements of program code that are executed during a test, and comparing this number to the total number of statements in the program. Branch testing, or branch coverage, is concerned with testing each branching statement (e.g. an IF . . . THEN . . . ELSE statement, or a SELECT statement) under conditions that will cause specific branches to be taken. The branch coverage metric then indicates how many of the possible branches in the code have been exercised during the test.
Component-based visual programs introduce a new challenge to measuring code coverage. (The term “visual program” is used herein as a shorthand for “component-based visual program”.) Visual programs are different from conventional programs in several important ways. Because of these differences, known test coverage techniques cannot be applied to this new programming domain in a way that provides meaningful results-and without the ability to define test coverage metrics for visual programs, it is difficult to assess program quality and reliability, which may negatively affect the acceptance of such programs by end-users.
A first difference between visual programs and conventional programs relates to the types of building blocks used by a programmer in creating a program, and a second difference lies in the source of those building blocks. Visual programs are graphically constructed primarily from pre-built components, equivalently referred to as “parts”, which are typically supplied (along with the code which implements those components) by the vendor of the visual programming environment (or by a third-party vendor of such parts). Examples of visual programming environments are VisualAge for Java and VisualAge Smalltalk, from the International Business Machines Corporation (“IBM”). VisualAge is a registered trademark of IBM, and Java is a trademark of Sun Microsystems, Inc. A conventional programmer, on the other hand, typically writes program code himself using textual source-code statements of a programming language such as the C language. The source code statements specify data definition, as well as all operations on the data that are required in order to achieve the desired end result. Alternatively, in an object-oriented programming environment, the object-oriented programmer writes programs in a programming language such as Smalltalk, by creating or re-using objects and methods. Because the object-oriented programmer writes programs using source language coding statements, object-oriented programming will be considered as a “conventional” programming environment for purposes of the present invention. The visual programmer writes a program by selecting from the pre-built components (often by selecting visual representations of these components), and specifying how, and in what sequence, the selected components will interact. The visual programming environment software then generates executable code that will implement the specified interactions.
This generated code is constructed by the visual programming environment, and thus it can be expected that it correctly implements the components and interactions specified visually by the visual programmer. Testing this generated code during testing of the visual program is therefore likely to be a redundant effort, wasting time and resources that could be better spent in testing the program elements created by the visual programmer. Further, if this generated code is included in existing test coverage metrics (i.e. measurements computed in terms of statements executed, or branches taken), the resulting statistics will obscure information related to how much of the visual program written by the visual programmer has been covered. In addition, because visual programs are written using components and interactions, metrics expressed in terms of statements and branches do not provide a useful coverage measure for testing this type of program. And, if coverage expressed in these metrics indicates insufficient testing, there is no correlation to the components and/or interactions which are the ones needing more testing. Finally, showing the visual programmer which source code statements were (or were not) covered requires him to work at a different level (i.e. generated text, using source code in a programming language such as C or Smalltalk) during testing than that in which he worked while programming (i.e. visually, using parts and interactions), which may be confusing, error prone, and inefficient.
Accordingly, what is needed is a technique for measuring test coverage of visual programs, and presenting the coverage metrics in a manner that is useful to the visual programmer. The technique for measuring test coverage is the subject of the related invention having Ser. No. 09/154,127, titled “A Technique for Test Coverage of Visual Programs”, which is incorporated herein by reference. This technique accounts for the specialized nature of visual programs, which are typically created by graphically specifying interactions between prebuilt components. The metrics provide information that is useful to the programmer working in this environment, indicating test coverage in terms of elements that correspond to a visual program. There is a need to present these metrics in the same general visual manner in which the visual program was created, so that the visual programmer can analyze the coverage information conveniently, seeing the coverage metrics in a program view with which he is already familiar.
SUMMARY OF THE INVENTION
An object of the present invention is to provide a technique for presenting test coverage me

Affiliated with

Also associated with

Rating

Presentation of visual program test coverage information does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Presentation of visual program test coverage information, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Presentation of visual program test coverage information will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2456462