性能测试技巧:用户思考时间的设计


未经声明皆为本站原创,未经许可不得用于商业用途,转载请保持完整性并注明来源链接


得到一个性能测试结果很容易,得到一个真实有效的性能测试结果很难。

举个简单例子,我们有个网站要上线了,要买主机,要买带宽,究竟花多少钱合适,取决于我们预期要同时为多少并发用户服务。在最大并发用户情况下,需要什么处理能力的cpu,需要多少内存、多少网络带宽等,不经过严格的性能评估测试,我们是很难得出较为准确的结果进行购买决策的。但是做了性能测试,如果测试过程不严谨,测试压力比实际大了,意味着多花了钱,还造成资源浪费;测试压力比实际小了,造成网站使用过程中用户体验下降,导致用户流失。所以不准确的性能测试,还不如不做,拍脑袋决策来的更潇洒。

任何一个性能测试免不了有误差,但是追求较高的精确度任何情况下都不为过。

为了得到性能测试的准确结果,创建一个精确模仿用户预期行为的场景就变得很重要了。用户行为有很多种模式,但是思考时间是几乎公有的属性。

当一个用户在应用程序中思考他们的下一步行动而停止操作的时候,这在测试脚本中就转化为“客户端睡眠时间”——统称为思考时间。

思考时间设计

编写性能测试脚本的时候,一定要考虑用户如何与应用程序交互。

比如有时候用户需要停下来阅读指南、描述或是文档,或者喝口水(人毕竟不是机器),或者我们希望他们停下来欣赏一下界面设计。

不管是哪种情况,当几个用户在同时操作的时候把思考时间的因素加入到测试中是必要的。

思考时间的设计有多种方式,可以通过观察用户的操作过程,记录用户的实际思考时间;如果系统有用户行为跟踪,也可以通过分析用户操作行为日志获取;如果前两者都不可取,测试者可以通过熟悉系统业务,以自己作为基准模拟实际用户来获取思考时间。

举个简单例子,我们希望用户在看技巧秘籍页面之前平均花费30秒的时间来阅读主页的内容,我们增加了用户在从我们的主页到技巧秘籍页面的思考时间。

web_url_get("main")

thinktime(math.random(20, 40))

web_url_get("performance testing tips")

不会有哪两个用户的行为是完全相同的,在上面的例子中,我们希望虚拟用户在主页停留的时间是20s到40s之间随机。

“随机”是性能测试脚本准备中模拟用户行为差异的非常典型的方式。

HyperPacer用户思考时间

HyperPacer思考时间

HyperPacer在录制脚本时就考虑了思考时间因素,并提供了固定和动态两种方式。

选择固定,会按照录制脚本时实际操作间的空闲时间记录;

选择动态,会按照设定的基准时间和最大偏差生成动态变化的思考时间。

当然也可以在脚本录制完成后,通过手动添加定时器来进行用户思考时间的设计。

总结

性能测试中,没有特殊的需求时,一定要考虑思考时间的设计。切记:差之毫厘失之千里。

 

Top