It is true that each SQL Agent Job is limited to sequential execution, that is why you have to make multiple different Jobs. Each job would contain exactly the same definition, only the Job Name would be different. Then if you create 5 different Jobs (called, say "Test Job 1" through "Test Job 5") you can have up to 5 simultaneous executions. This may not sound like a lot, but automated procedures in a loop are much faster than real users (who are human and have pauses/waits in-between server requests) so this would easily simulate the intensity of 20 to 100 users.

If you are unfamiliar with the Job system and need a walkthrough of how to create these Jobs, let us know.

Whether you are going to test or your are going to use the Job system, you want stored procedures. Bare commands, no matter how simple, are way to much trouble to manage in these more abstract situations. Plus a stored procedure can be as simple or as complex as you need it to be.

In this case you need not just you SQL query statement, but a way to loop also: that means at least two SQL commands, so you definitely want a stored procedure. If you are unfamiliar with how to setup or use stored procedures, let us know and we can help you with that too.

There are a number of ways to do this, but that starts to get more complicated. I have go earn a living right now (:)) so hopefully someone else can chime in (I'll be back later today). What would help is if you could give us some example commands and table defintions to start working with. See this link for details on how to provide us with this information: http://www.sqlservercentral.com/articles/Best+Practices/61537/

It depends, if they are all hitting the same data, then they will either be unrealistically fast (for Selects) or unrealistically slow (for modifications). One of the reasons that we need to see your actual commands is so that we can show you how to randomize this somewhat.