You needn't obsess about distinctions between different sorts of tests provided you mind one important guideline: Every test should have one reason to fail. The nature of that one reason will distinguish between unit tests, acceptance tests, integration tests, or whatever.
When I speak of collection tests, I call them a "test suite" and each element of the test suite is a "test case." In something like JUnit or NUnit, a test case is a single public function the framework executes in the course of running all the tests in a test suite.
Unit tests are generally very closely tied to the implementation code and their scope are generally very low level. Things are less cut-and-dried when the scope engages higher levels of functional testing. Use cases and scenarios are generally covered by functional testing. They are less cut-and-dried because it is difficult to avoid writing tests that can fail for multiple reasons (without ruthlessly applying mocks, stubs, and fakes).
If you can, try to keep your focus on the lowest level tests and make sure you not only have complete code coverage in your unit tests, but that every major off-happy-path situation you worry about has a specific test creating the bad situation and asserting the desired error-handling.