Well, the test environment is supposed to be an independent "real estate" for QA purpose.
A developer will develop his code on dev. env. Other than his piece of code, the developer might have touched few other entities on the dev environment. Now when the code is "completed" and is to be pushed for QA/testing, it should be moved onto a totally independent environment - the Test Env.
Along with just the code, the other entities - whatever has been modified should also be moved.
The developer will bundle his changes and this bunch of changes will be applied to the test env. - This way you have all the changes, in one bunch, that will finally go to production.
Benefit of having an independent test env is that the code is rolled out on a plot that has been untouched by the developer.
The following is from Tom Kyte's new book EFFECTIVE ORACLE BY DESIGN
You should use your test environment to do the following:
1. Benchmark your application. Test that it scales to the required load(number of users). Test it for performance (that it can handle the load within required response time). This is key.
2. Verify that your fix actually work, especially in conjunction with the rest of the system, and that they do not cause more harm than good.
3. Assure yourself that the upgrade script you worked on in development actually works. Make sure that you can, in fact, upgrade production with your latest releases.
4. Make sure that major things like patch upgrades, major version releases, and operating system patches don't knock out your system.