There really isn't any way to make sure your test cases are correct, except by concentrating really well when creating them - understanding the requirement, understanding the code, and making sure that they agree. The point of having a test suite is that you only have to do this once, and from then on you can just re-execute the tests and check that they pass, whereas without a test suite you would have to concentrate really hard all the time, i.e. whenever you do anything to your code base. But the fundamental problem of having to make sure that you were doing the right thing in the first place remains - computers simply are not intelligent enough to relieve us of that task.
Therefore, (1) if your test suite is incomplete, there is no simple way of seeing that. Code coverage analysis can prove that some lines of code are never executed, i.e. that the suite is deficient in some way, but not how severe that deficiency is, and it can never prove that it is sufficient. Even with 100% code coverage you have no guarantee that all relevant states of the system are exercised, and complete state coverage is inachievable for any realistic system because of the combinatorial number of states that could exist. One good technique of making sure that you test case is at least correct for checking the thing you want checked is to write the test, verify that it does indeed fail, write/change the code, and then verify that it now passes. Hence the enthusiasm for test-driven development: it allows you to be quite sure that an individual test does the right thing, and if you create your entire code base that way, you can get a similar level of confidence even in a large system.
(2) A test suite normally becomes insufficient whenever requirements change - you don't have to guess. If the customer wants some particular behaviour changed, and your tests would succeed both before and after the change, then clearly they weren't exercising that particular input/output relationship.
As for legacy systems that don't have test coverage, or where you don't know what the coverage is, there is no formal proof, but (parental advisory: personal opinion follows!) speaking from experience it is overwhelmingly likely that the tests are not adequate. When testing is viewed as an after-the-fact, optional, quality-enhancing-but-not-really-necessary activity, it tends to be incomplete and unsystematic because the incentive for making sure the tests keep up with the code base just isn't there.