Which VM(s) (ie qemu, xen, VMware, VirtualPC, etc) have you tried already? Another option for you, depending upon what you're trying to run, might be for you to 1) install Linux or BSD in your VM, and 2) install WINE in your VM. Assuming that your application(s) will run in WINE.

Basically, you can think of performance testing as a way to test how an application (or group of applications) will perform under normal running conditions. Load testing is a way to test how an application (or group of applications) perform under various loads. For example, if you were load testing a multiuser, network application, then you'll want to test it multiple times with different numbers of users simulating several different patterns of network traffic. Think of stress testing as running tests to overload the application (or group of applications) in order to observe what happens. The goal here is to try to break the running application hoping to discover things like potential buffer-overflow bugs, various resource contention issues (like deadlocks), dangling pointers, data validation bugs, etc. In a way, stress testing can also be thought of as load and performance testing on steroids. :) Again, my descriptions are brief, and hopefully my analogies are enough to help you get started. Nevertheless, you'll probably want to spend some time researching various testing methodologies, because this is a very rich topic.

Actually, all you really should have needed to do was run the script in the background (ie ~admin/path/to/my/script &). Yet, you'll probably find that if you were to try to run any binaries (or scripts) which read from/write to a terminal (like one of the /dev/tty* devices) or pseudo-terminal (like one of the /dev/pts/* devices) via that script, then those binaries will probably behave a little differently than you might expect. In that case, you have a couple options: force the binaries in question to run interactively, handle the respective SIGTTIN and/or SIGTTOU signals for those binaries.