Making Sense Out of SOUP (Software of Unknown Pedigree)

4. Dealing With Compromised Modularity

In some SOUP applications, structure and modularity may have suffered, challenging the notion of testing functional or structural subsections of that code. However, unit test tools can be very flexible, and the harness code which is constructed to drive test cases can include as much of the source code base as necessary. The ability to do that may be sufficient to suit a purpose. If a longer term goal exists to improve overall software quality, then using instrumented code can help to understand which execution paths are taken when different input parameters are passed into a procedure — either in isolation or in the broader context of its calling tree.

5. Ensuring Correct Functionality

Perhaps the most important aspect of SOUP-based development is ensuring that all aspects of the software function as expected, despite changes to the code, the compiler, the target hardware, or to the data handled by the application. Even with the aid of test tools, generating unit tests for the whole code base may involve more work than the budget will accommodate. However, the primary aim here is not to check that each procedure behaves in a particular way; it is to ensure that there have been no inadvertent changes to functionality.

By statically analyzing the code, test tools can automatically generate test cases to exercise a high percentage of the paths through it. Input and output data to exercise the procedures is generated automatically, and then retained for future use.

They can then be used to perform batch regression testing to ensure that when those same tests are run on the code under development, there are no unexpected changes. These regression tests provide the cross reference back to the functionality of the original source code.

Conclusion

In an ideal world, test tools should be applied from the beginning of a structured and formal development process. However, sometimes commercial realities mean that legacy SOUP code is used as a basis for further development — maybe to DO-178B standards. By using those same test tools in a pragmatic way in these circumstances, it is possible to develop legacy SOUP code into a sound set of sources which are proven to be fit for purpose, all in an efficient and cost-effective manner.

This article was written by Mark Pitchford, Field Applications Engineer, LDRA (San Bruno, CA). For more information, contact Mr. Pitchford at This e-mail address is being protected from spambots. You need JavaScript enabled to view it , or visit http://info.hotims.com/28051-400.