Considering the performance impact of your test data source

Most automated tests require some form of data to be used within the tests. These are your test data sources and the approach you take for utilizing this data will have an impact on your tests. The question is how much of an impact.

Determining the best approach for storing and accessing data to be used in an automated performance test can be tricky. In addition to the physical space required to store the data you need to consider the impact reading and/or writing data will have on your performance metrics and your end goal. Not just on the target server(s) but on your client(s) as well. Try and find a solution that has the least impact. 

For example, if the tests you are running do not consume a large amount of bandwidth then you might want to consider a network resource. Do not use the target server of the tests as a resource since that will not only impact the bandwidth of your client but also the server’s bandwidth and local resources. Also consider the time it takes to read or write the data to your network resource. You don’t want a delay here that will impact your tests.

Another option is a local resource on the client. The reading and writing will be much faster than a network resource. However, if the tool(s) you use to conduct the tests consume(s) a lot of local resources then this option may not work the best. You don’t want the operations pertaining to the test data to lock resources that your actual tests require to perform their operations.

The last option is to build the test data into the tests, if your tool will allow it. Some tools have their own objects for this purpose while others allow flexibility to create your own. These can be embedded files, arrays, tables, etc… whatever your tool allows. The biggest problem here is now you need to performance test your performance test. That is, ensure the code and objects you have written and utilized are not impacting the performance of the actual test code and objects.