例如,当测试前已经获知在线人数为10000,可以设定性能测试的目的是检测软件典型交易的平均响应时间是否符合小于5秒的指标值。
例如,当测试前不知道在线人数是多少,但是已经获知该软件在一定的时间周期内(t)必须处理N笔交易,可以设定性能测试的目的是检测软件典型交易的吞吐量是否符合大于25笔交易/秒的指标值。
但是,在第二种情况出现时,还应该考虑若软件的吞吐量符合指定的指标值时,软件典型交易的平均响应时间是否符合小于5秒的指标值。
为什么呢?
我们可以利用“门”的概念来理解这里面的偏差!
首先,我们假设如下的情况:
共有5个人;
有1扇门;
一个人通过这扇门需要花费1秒的时间;
此时,这扇门的吞吐量为1人/秒。5个人通过这扇门的平均响应时间为(1+2+3+4+5)/5=3秒。
如何才能提高人的通过效率呢?即,如何才能提高门的吞吐量呢?
有两种方法:
(1)减小通过门的时间;
(2)增加门的数量
例如,
(1)将一个人通过门的时间减小为0.5秒,门的吞吐量变成了2人/秒;
(2)增加一个门,门的吞吐量也变成了2人/秒
结果是:
(1)5个人通过改善通过时间的门的平均响应时间为(0.5+1+1.5+2+2.5)/5=1.5秒;
(2)5个人通过两扇门的平均响应时间为(1+1+2+2+3)/5=1.8秒
此时,你可以发现,软件开发员改进软件处理并发交易请求的方法有两个,第一种是提高单个请求的处理速率,第二种是增加处理请求的线程的数量;或者是两种方法的组合。但是,不同方法的使用并不代表吞吐量得到了提高,而同时软件典型交易的平均响应时间也获得了相同值的改善。
因此,在性能测试以吞吐量为检测指标的时候,不光要评估吞吐量是否符合了性能指标的要求,同时也必须考虑响应时间是否符合性能指标的要求。
假设,在测试前,规定了吞吐量为大于25笔交易/秒,平均响应时间为小于5秒,在测试后,若实际吞吐量等于27笔交易/秒,不能仅凭这个27笔交易/秒就确定该软件的性能符合要求了,还要看平均响应时间是否符合要求。这时的平均响应时间可能大于5秒。
而,如果测试前,规定了在线人数为10000,平均响应时间为小于5秒,在测试后,仅凭实际平均响应时间等于4秒就可以判断该软件的性能符合要求。