1. Do tests look for exceptional cases or functionality of the class?
Unit tests are meant to tests the core functionality of the object. I go by the mantra of writing tests to cover parameters going in and return values going out. By that I mean for every parameter going in I'm testing a valid value and an invalid value. I'll also make sure I have tests that cover all valid return values. Should end up being around 1-5 tests per method depending on the number of parameters and return values.
Things like corner test cases would be left for a formal test pass if you have a test team. Like most of us you probably don't :). In that case I do try and add such cases to my unit tests if they pop into my mind or when I come across a related bug. Generally any time I find a bug in a class I try to figure out why my unit tests didn't catch it and then write a new test that will catch it. Once again this may seem useless since I've already found the bug but refactoring can bring bugs back from the dead. I want a test there to catch it if it does.
2. Do you create tests for every method on very class?
Yes. This is the essence of unit testing. The goal is to have a list of objects that you can really trust. The only way to do that is to test everything. This can be a daunting task with older code so I suggest starting out writing unit tests whenever you create a new class and then slowly go back and write tests for your old code. Odds are you are never going to get 100% coverage on your old code but you'll find that a lot of old code disappears anyways.
If you have classes that have 100+ methods then most likely it's time to do some refactoring. One of the things about OO design is that it's easy to end up with bloated base classes that need to be split out. It's an evil that hits us all. I target a major refactoring pass after every major project to see what's worked and what hasn't. This refactoring is the very reason why you want the unit tests around. Saves you a lot of pain.