in reply to reverse engineering the input needed for full coverage of the program
This is a specific example of code coverage analysis, or “test coverage analysis,” and it is, as you will see, a relatively big topic.
Most commonly, the approach that is taken is to start with test-cases and to seek to analyze in an automatic or computer-assisted fashion which portions of the code are, and are not, covered by those cases. While this is more or less the reverse of the approach that you are looking for, it is also a much more solveable problem in the general case. Also, it tends to be more useful. A system of conditional-tests is in effect a (not-necessarily binary) tree, which of course can produce a frighteningly-large number of unique possibilities, not all of which will be meaningful. (It also cannot mechanically consider the overall context in which the piece of source-code under test might be encountered ... a critical factor which might be an NP-complete [unsolvable ...] problem or nearly so.) Understanding of a real-world program ordinarily involves a level of semantic (i.e. “human”) understanding and guidance that cannot be truly eliminated, hence the approach that starts with tests and then evaluates those tests. But testing-gap analysis can be done, and in a critical software system must be done.