在之前两篇文章性能测试误差分析文字版-上、性能测试误差分析文字版-下中，我从纯文字的角度分析了误差产生的原因和来源。接下来就是需要定量分析了。但是在这之前需要做一些准备工作，就是要在测试框架中支持这种误差的统计。
前文讲到过的两种计算公式：
QPS = 总请求量除以总时间，以下：
QPS = count(r)/T
QPS = 线程数除以平均响应时间
QPS = thread/rt
第二种方式是我一贯采取的公式，所以现在要实现第一种统计方式。
统计对象支持
在性能测试数据统计对象类PerformanceResultBean中我增加了两个属性：
/**
* 通过QPS=count(r)/T公式计算得到的QPS,在固定QPS模式中,这个值来源于预设QPS
*/
double qps2
/**
* 理论误差,两种统计模式
*/
String deviation
在构造方法中我增加了赋值过程：
this.qps2 = qps2
this.deviation = com.funtester.frame.SourceCode.getPercent(Math.abs(qps - qps2) * 100 / Math.max(qps, qps2))
基本工作已经做完了，下面是在两个性能测试模型固定线程模型和固定QPS模型中的实现。
固定线程模型中实现
主要思路就是获取两个值：请求总数和请求总时间。我在ThreadBase类中用了一个属性
/**
* 执行数,一般与响应时间记录数量相同
*/
public int executeNum;
然后在最近测试结束的时候，将各个线程的统计在一起。
threads.forEach(x -> {
if (x.status()) failTotal++;
errorTotal += x.errorNum;
executeTotal += x.executeNum;
});
最后计算QPS2的值double qps2 = (executeTotal + errorTotal) * 1000.0 / (endTime - startTime);。
固定QPS模型中实现
由于模型的特殊性，总请求次数已经在FixedQpsConcurrent统计了：public static AtomicInteger executeTimes = new AtomicInteger(0);，然后在子类中的使用场景如下：
@Override
public void run() {
try {
before();
threadmark = this.mark == null ? EMPTY : this.mark.mark(this);
long s = Time.getTimeStamp();
doing();
long e = Time.getTimeStamp();
//计数器加一
FixedQpsConcurrent.executeTimes.getAndIncrement();
int diff = (int) (e - s);
FixedQpsConcurrent.allTimes.add(diff);
if (diff > HttpClientConstant.MAX_ACCEPT_TIME)
FixedQpsConcurrent.marks.add(diff + CONNECTOR + threadmark + CONNECTOR + Time.getNow());
} catch (Exception e) {
FixedQpsConcurrent.errorTimes.getAndIncrement();
logger.warn("执行任务失败！,标记:{}", threadmark, e);
} finally {
after();
}
}
接下来是计算统计方式的代码int qps2 = baseThread.qps;，这里由于第二种统计公式并不成立，所以用了预期QPS代替了qps2的值。
- 基本工作终于做完了，接下来我会定量进行在不同场景下的误差对比分析。敬请期待！！！