| Abstrakt: |
Finding flaws in a software product is the goal of the testing process. However, even after successfully completing the testing step for the majority of practical systems, it is impossible to ensure that the program is error-free. This is a result of the vast input data domain found in the majority of software applications. It is not realistic to test the software in every possible configuration that the input data might take. Even with this real-world constraint on the testing process, its significance shouldn't be understated. It must be kept in mind that testing does reveal numerous flaws in a software program. Testing thus offers a useful method of lowering system flaws and boosting users' confidence in a built system. A few flaws typically persist even after a program has undergone extensive testing. Usually, these remaining flaws are dispersed across the code. It has been noted that flaws in some areas of a program can lead to failures that are both more frequent and more severe than those in other areas. The statements, methods, and classes of an object-oriented program should thus be able to be arranged according to how likely they are to result in errors. After the program's components are arranged, the testing effort can be distributed so that the components that frequently fail are tested more. In this method, a program's intermediate graph representation is exploited. A forward slice of the graph is used to estimate a class's influence. Applications for our suggested program metric include coding, debugging, test case design, and maintenance, among others. [ABSTRACT FROM AUTHOR] |
