Microsoft Sharepoint Products and Technologies Resource Kit eBook

228 Part III: Planning and Deployment
What Does Not Need to Be Tested
This section focuses on the most widely used workload scenarios. Other scenarios—
such as administrative tasks, document uploads, adding Web Parts to a portal site,
and so on—do not occur as often as the scenarios just mentioned. If your organization
has other scenarios, such as document uploads, that are more prevalent than
the general case, you should modify your test plan accordingly.
Testing Methodology
Before running any tests, you should create a table in which you enter the number
of concurrent users that would hit the portal site. You should start with one user and
increment slowly with each subsequent test to see the impact on the portal site. You
do not want to start with a high number of concurrent users and flood your portal
site. That will not give you accurate test results, and you will most likely get frustrated
trying to interpret the error-ridden results you get. You can increase the number
of the concurrent user threads in the ACT tool in the properties of a test script
as shown in Figure 9-8.
F09XR08
Figure 9-8 Setting the load level
The test load level indicates the number of simultaneous browser connections
that the client will generate while performing the tests against the portal site. It is
important to note that you will need to have enough users in the users profile to be
able to concurrently hit the page. The load level should never be more than the number
of users. If it is, the test will fail. The more user connections you have, the more
load you will put on the server. You will also generate additional load on the client
running the test as you. Generating too much load on the client will result in incorrect
numbers, as the clients will not be able generate the expected load.