Changes to the tests should be part of the same review as changes to the system under test. If they can't be, for organisational reasons (e.g. you're using a tool that works on only one repository at a time, and your tests are not in the same repository as your functional code), then the two reviews should be linked in some way. This might be as simple as an email or a conversation saying which reviews belong together.
In the event that some of your tests are not automated, the review should include at least a statement of the tests conducted.
In all cases, an important part of the review is to identify gaps in the testing, and I always look for edge cases that have been missed and might cause problems for the code.
When reviewing, I don't normally repeat the tests, but would consider doing so if the author asked (e.g. if we're compiling for different platforms, or to confirm that the diff is complete - though usually, the build server will tell us that). It is not a good use of my time to duplicate someone else's actions without good reason.