It is a common agile practice to reason in terms of story points instead of hours. You can learn more about why we do so here.
The velocity concept, instead, is well explained in this blog post.
I don't want to complicate things, so I will answer to your question speaking in terms of hours.
Let's imagine that you are on the first iteration with a brand new team.
In such a case, you can assume that the team will be "really" working for about 70% of their available time. You are considering the fact that the remaining 30% will be taken up by other tasks not related with development (paperwork, e-mails, phone calls, etc.).
It is wise to start with a conservative estimate. The idea is to adjust your estimation in the next iteration and use it to determine how many hours of work can go in the next sprint.
Let's give a look at your example (a team with 3 developers, working 5 days per week, at 8 hours a day):
3 (number of developers) * 5 (days) * 8 (available working hours per day) * 0.7 (initial estimation) = 84 ("real" working hours that your team can handle in one week)
Based on your question, I think that it could be good for you to search more information about the concept of Definition of Done (DoD) as well. You can start from here.
I understand that in your organization testing is separate from development. This is not the best agile approach, but it is (sigh!) common. You can find some interesting information in this answer to the question "How to fit testing in Scrum sprints and how to write user stories in Scrum" on Programmers Stack Exchange. Give a look also at this blog post about testers working in an agile team.
It is complicated to tell you what is best for your team and organization based only on the information provided. My understanding is that you are working with one-week sprints. You wrote that, according to your experience, it is better to leave the last day for testers to do their job. In this case, if I were you, I would probably continue to consider 5 working days. The team needs to speak with the Product Owner and organize the Sprint Backlog to have user stories that fit into 4 working days to be done (so that they can be sent to the testers team in the same iteration) plus another story (or more) that can be done in the last day (to be sent to testers in the next iteration).