Introduction Interprocedural Data Flow Testing
Although a number of stream test methodologies have been developed and has studied in recent years, [8, 11, 14, 15, 18 and 19] their usefulness was limited to testing data dependencies that exist within a procedure. Testing of data dependencies that exist between the procedures requires information on the flow of data across the boundaries of the procedure, including two calls and returns. Data dependencies that exist between the procedures both directly above returns and unique calls and multiple calls indirectly and returns are required.
The current data flow testing tools either use data interprocedural flow analysis generally used in compiler optimization to determine data dependencies or determine pairs of definition-use of the source code and then the graphical search of def-use of the program. Although data inter-procedural flow analysis algorithms exist, [2-7, 9, 17] they do not provide detailed information (i.e., the locations of definitions and uses that scope through the two procedure calls and returns) necessary for data inter-procedural flow testing. Also methods to guide the actual data rate tests do not currently handle renaming of variables is required then for the execution of the inter-procedural tests.
Inter-Procedural data flow testing
After data inter-procedural flow information are calculated and the pairs of definition-use required are determined, Tester guides the selection and execution of the module with cases of test as input. This is by selecting pairs of definition-use required as the desired test test and treat the test until the required pairs are met. The pairs of definition-use required depend on the desired test test. For example, if the test is "all-p-uses/certains-c-uses", the tester runs the acceptor with all pairs of definition-p-use. If, for a definition, not p-use exists, then a few pairs of definition-c-use must be accepted.
A case of test of treatment consists of (1) the execution of the module with the test as input data for the path of test and (2) the execution of the acceptor of test scenario with the path of the test and a pair of definition-use as input. Our tester instruments of the module at the level of the intermediate code. Intermediate code instructions are inserted that the number of each basic block is crossed during the execution of the module output to a file. However, the execution path must also contain information signals of procedure calls and returns so that the renaming of reference actual and formal parameters can be manipulated. We have to do this, the intermediate code instrument to indicate procedure calls and returns. It saves the file containing the execution path (file) block numbers with information about the definition of use pair which must be checked (VAR, DBLK, UBLKl, UBLK2, TY).
VAR represents the proposed variable and DBLK is the number of block containing the desired definition. TY is c-use or pulses. If TY is c-to-use, and then UBLKl contains the number of the desired use block and UBLK2 is not used; If TY is p-to-use, and then (UBLKl, UBLK2) represents the border you want. Since we also have access to the data stream information which was calculated in the first phase, it is used to determine the set of blocks containing definitions, DEFSET, of the real parameter to returns procedures and the formal parameter in the entries to the proceedings. The entry in a procedure causes the DEFSET be amended to reflect the change of name of the formal parameter that is bound to the definition of the test. The output of a procedure causes the DEFSET return to its value in the appeal procedure.
To illustrate, consider the case of test with 4 892 input where the pair definition-use processing is the definition of k in B12 procedure pair-Max and the use is the edge (BlO, Bll). This definition of k reached the use of the other side (10 B, 11 B) since it reached on the return to the Get - Max procedure, return to the Get - Max through the recursive call, in the call to Get - Max once again and finally the call to the Max pair where the variable is bound to others. The steps involved in the path of the test of treatment are presented below. The DEFSET is initialized to all of the definitions of the variable corresponding to the definition that is being tested. Each call to and return from a procedure, the DEFSET is amended to reflect the new name of the actual or formal parameter. Since there are no definitions of the corresponding variable MX in Get - Max inter-procedural, the DEFSET is empty during the processing of the blocks in this procedure.
Conclusions
In this article, we have extended the data flow test to include testing of the definitions which reach and uses that can be achieved through procedure calls and returns. To this end, it took the development of a technique of analysis of interprocedural data flow that calculates the locations of the definitions up inter-procedural and use the pairing and the development of a testing methodology that associates the actual and formal parameters in calls and returns. The advantage of the test system resulting is that data flow testing can be applied uniformly in the individual procedures for integration procedures in a module and interfaces of the procedures.
