Cloud service and infrastructure testing would logically focus on the connection between the delivery network and the server resource pool, then on the connection from the server pool to the storage pool.
For each, the cloud testing process requires first that there be a service-level goal established at the test point, then that there be an organized procedure to test against that goal.
The biggest testing issue operators report for the network/server boundary is managing the variations in connection performance that occur because of the relative location of the user and the server resources assigned to support the user's applications.
The design goal for cloud network connectivity is to keep these variations small by reducing the number of hops between possible user locations and possible resource locations to reduce packet loss and delay on as many combinations as possible.
Large differences would require that assigning server resources to a user take the communications impact of the server's location into account, which complicates the problem of making optimum use of server resources.
Since testing the network's ability to deliver consistent services to users anywhere within the target geography is critical, cloud testing will require comparing network delivery performance between various geographic points and the server resource pool.
If the pool is widely distributed, it will be important to test the delivery variations across a combination of server and user locations. This can be done with traditional test equipment or with load generators and network monitoring tools.
The "service" that the server layer – the second boundary point - delivers is that of assigning and sustaining a server on demand. In most cases, the issue here will be the delay between an application request for service and the delivery of the needed resources, which is a test of the resource pool's management process.
While it may be possible to generate test simulators for the management protocols, most operators prefer to test the responses using load generators or live requests entered for test purposes. What's critical here is to be able to correlate the request and the response, which is most easily done if you start by measuring the application response time at the point of request.
Testing server/storage boundary points is normally easier than network/server pool boundaries because most operators rely on storage located in the same data center as the servers. The performance variations are therefore limited to those that occur due to data center network structure, notably the use of "deep" (i.e. multi-layer) storage networks that introduce variable latencies due to variations in the number of switches that need to be transited between server and storage device.