Validating converted java code via symbolic execution

The testing approach described here has grown out of migration projects aimed at converting procedural programs in COBOL or PL/1 to object-oriented Java code. The code conversion itself is now automated but not completely. The human reengineer still has to make some adjustments to the automatically generated code and that can lead to errors. These may also be subtle errors in the automated transformation. Therefore, converted code must be tested to prove that it is functionally equivalent to the original code. Up until now converted programs have been tested manually and their results compared, but that is a very labor intensive approach. Besides, it only shows which results differ and not where the code differs. It can be extremely difficult to trace differences in the results back to differences in the code. Such regression testing drives up the costs of migration, causing users to disregard this alternative. If they have to spend so much on testing a conversion they might as well redevelop the software. This paper describes how converted code can be validated at a much lower cost by symbolically executing it and comparting the execution paths. The theory behind this approach is that no matter how statements are statically reordered, dynamically they must still execute in the same sequence to produce the same result