How do Scrum/Agile teams use metrics to estimate testing efforts.
Agile teams are cross-functional teams. They estimate the work from design to delivery often on a story based level. This includes the testing work, since testing should be part of the definition of done.
I as a tester part of an Agile team always sit in with the planning poker sessions and estimate just with the team, keeping in mind the complexity and size of the testing efforts needed to complete the story to done. If I know the area we are working on lacks a lot of automated test coverage I will give the story a higher estimate then the programmers in our team, often we average out the points in these cases.
I would use story points to estimate the relative size of the complexity of the task at hand. Read more about estimating with relative sizes in this blog.
Now you can use the velocity metric for the whole team effort, including testing.
I would give the testers in your teams the following book to read: http://agiletester.ca/
I would recommend using "Development Poker" (Planning Poker) for testing efforts - it's effective, and there is no real reason why you can't use relative sizing to estimate testing.
But generally, I've always found it better to have testing as part of the whole estimation of a User Story. When it comes down to taking the user story off the prioritised product backlog and into the sprint backlog that's where you can start breaking down the story into tasks and get a better idea of actual time estimates for the sprint.
When implementing Scrum the emphasis is on the team, so as a team testing is an integral part and not something bolted on.