Inspired by a recent exchange with ariaflame, software is often complex and difficult to comprehensively test in a single way. Much like good requirements modelling adopts views of the requirements that allow various aspects to be dealt with separately, a good test regime will test software in different ways for different reasons.
The theory is that one of these ways will pick up the critical defects somewhere along the way.
So here is a quick summary of ways of testing.
Unit testing: does this piece of code run successfully.
Function testing: does this function perform according to the requirements.
System integration: does this component of the system play nicely with the other children.
User acceptance: can I do my work using the system.
Performance: How long will I have to wait to do my work when N other users are also working.
Production Verification: Does the system still perform correctly under real conditions with real data.