Introduction: Evaluation of software solutions prior to its deployment and integration is a widespread industry practice. There exist numerous software testing paradigms, strategies with specific objectives. Often test management plans are fabricated in order to prioritize the tests for optimal utilization of resources. Issues that arise with scalability such as the ones pertaining to garbage collection, memory leaks, throughput, bottlenecks, latency, Error rates are detected in performance testing. One of the critical steps in performance testing is that of test design creation. Tailored tests scripts are written for Load testing, Stress testing (Soak testing, Spike testing), scalability testing, capacity testing, volume testing. Each of the aforementioned tests have their unique set of objectives.
The monitoring process can be classified into two distinct classes: Real User Monitoring (RUM) and Synthetic Monitoring. Synthetic monitoring is a performance monitoring practice that emulates user’s path when engaging with an application. It uses scripts to generate simulated user behaviour for different scenarios, geographic locations, device types, and other variables. A performance monitoring technique called "real user monitoring" (RUM) gathers comprehensive information about how users interact with an application. RUM gathers information on a variety of performance metrics.
The monitoring phase is preceded by the performance testing phase, iterating this process by obtaining valuable information from the monitored data in order to evaluate the choice of Test Script may prove to be beneficial in the long. The distribution of the metrics is under examination in this article. Development process:
The use of an inverse dynamic approach would imply changes to the design process as it has to include a feedback loop to enhance the testing process and to improve the outcomes of the testing phase. Inclusion of such a feedback loop would also imply human inputs at certain stages similar to beta testing prior to full scale deployment.
Divergence:
For the sake of discussion, the factor of processor utilization is taken into consideration. The software solution is tested against the original script and the metric data is obtained. The time domain is then converted into frequency-domain. The obtained distribution is considered as a probability distribution Pscript. The monitoring process is then initiated and the distribution is obtained in a similar fashion. This script is denoted by Pmon. Each of the distribution is said to be on the same sample space.
The Kullback–Leibler divergence DKL(Pscript||Pmon) is given by DKL(Pscript||Pmon)=xϵχPscriptx logPscriptxPmonx Since the readings are discrete the discrete version of the KL-Divergence is used. The ideal value DKL=0 would mean that the test script was able to mimic the real-life use case and the script can be reused upon expansion or scaling of resources. The variation in distribution will be evident based on the relative entropy.