In part 2, I talked about the performance baselining process. In this post, I will talk about the performance test environment data baseline which I alluded vaguely to in the performance baseline definition in part 2 of this series.

A performance environment baseline consists of a number of sub-baselines; one of which is the data baseline. But, some environments may not have a state. So, this particular baseline is not required for all environments. I will elaborate on this in the next section.

Data Baseline

Before starting a performance test, the performance test environment may have a state. An environment state is a set of data that is a characteristic of an environment. For example, the environment state may be a set of data persisted in a database. The performance test environment state should mimic the target (production) environment where the code being tested will eventually be running and processing some business transactions. If the performance test environment does not have a state similar to the production environment, the performance test results may not be reproducible in the production environment. Consequently, performance targets, primarily response times and throughputs, achieved in the performance test environment, may not be met in the production environment.

During performance testing, the code being tested may do any number of things such as reading, writing, updating or deleting some entities in the performance test environment. For example, the code may create, read, update, or delete (CRUD) database records. If the code creates or updates the environment state, a decision must be made whether to undo the state change. Undoing the state change may be required for the following primary reasons:

1. The next performance testing test cases will fail. Undoing the state change here may involve any number of things such as resetting certain fields in the database, re-creating the database with exactly the original set of data, etc.
2. The environment state has drifted so much that the performance testing results may not be trusted as the environment state looks very different from the production environment state. Undoing the state change here may involve any number of things such as re-creating the database with exactly the original set of data, or data purging, etc.

The point here is that the environment state before the performance test environment was conducted should be restored so that the next performance test can be conducted. If the performance test environment state is not restored, performance test cases may fail, or performance test results may not be trusted.

The flow of activities described previously are depicted in Figure 1.

Figure 1: Data baselining

Having said that, some environments may not have a state. So, for these environments, a data baseline is not applicable and performance testing tends to be less complicated.

In the next post, I will continue the topic of performance testing guidelines.