从用户感知谈软件性能测试

虽然，有一段时间没关注性能测试，但时常还能看到有同学讨论性能，对于一些概念的理解很想深入讨论，但三言两语说不清，于是，还是花点时间写写吧！

　　今天有一个同学问：“一个小的系统，用户并发数为20个，那事务平均响应时间大概在什么范围内？” 怕麻烦直接告诉他2/5/8原则，钻牛角尖的话，需要进一步确认什么样的小系统？提供的什么类型的业务？用户行为是什么样的？用户对系统的使用频率？就算同响应时时间一样，前端通过不同展现方法，用户的感知可能完全不一样。下面就真对这个问题延伸讨论一下从用户感知的角度看软件性能测试。

 

2/5/8原则 

 

　　2/5/8原则是上个世纪80年代某公司真对自己公司的应用做的一个调查，调查的结果就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开或者发起第二次请求。

　　到90年代的时候英国真对零售业的网站又做了一次调查， 它的调查结果是一个用户真对一个页面的响应的最长忍耐时间是4s，超过4s 大量的用户会选择放弃页面的响应。

　　我在《性能测试知多少---响应时间》中已经对用户的响应时间做过分析；就是从用户按下键盘或鼠标按键到整个页面在浏览器中的展示的过程分程可以分三个部分：

呈现时间：浏览器接收到数据，解析渲染的时间。

数据传输时间：发送与接收的数据在网络中传输的时间。

系统处理时间：系统真对请求的处理并返回的时间。

　　我们在通过测试工具做性能测试的时候，第一个时间直接去掉，第二个时间进行阉割（因为一般的性能测试在局域网中进行，所以，数据传输时间基本可忽略），唯一保留的就是系统的处理时间。

你能用2/5/8原则么？你用性能测试工具得到的2秒，真实的用户感知恐怕要远远大于这个时间吧！？

 

 

不同业务的不同用户感知

 

　　真对不同业务类型的软件，用户的容忍度也是不一样的。百度和淘宝网都有搜索功能，而且都具有海量的数据，淘宝的搜索速度要慢于百度，不考虑技术层面，百度的搜索结果是纯文字信息；而淘宝搜索的商品会有大量图片，所以用户对淘宝的响应速度要“宽容”些。

　　从用户的心理分析，在使用百度的时候，对结果的显示显然更迫切；而我们平时在使用淘宝时叫“逛”淘宝，所以对结果的迫切性不强。

　　当然，如果是相同的业务，拿百度和到谷歌比，百度搜索结果1秒，谷歌需要10秒，相信谷歌再也不会被爱了。

 

 

不同使用频率的用户感知

 

　　装操作系统绝对是个耗时的事儿，少则也需要10分钟以上，但不少用户一年半载才装一次系统，所以，用户也基本可以接受这个事儿的耗时。如果是你每天早上开机需要10分钟以上，估计大多用户就要叫苦了。

　　所以，在一个系统中，用户频繁使用的功能上响应很慢的话，用户将很难忍受；相反，如果使用频率很低的功能，响应很慢用户也可接受。

 

 

减少用户等待感

 

　　最早是Robert B miller 在1968 年的《resopnse time in man-computer conversational transactions》报告中描述了3个层次的响应时间，

0.1～0.2s：用户认为得到的是即时响应。

1～5s ：用户感觉到基本信息的交互是基本流畅的。用户明显注意到了延迟，感受到计算机的“工作”过程。

8s 以上：用户会关注对话框。需要提示信息或进度条来确认系统仍然是处于处理过程的。

　　Peter Bickford 在调查用户反应时发现：在连续27次的连续反馈后，第28次操作时，计算机让用户等待2分钟，结果半数人每8.5秒左右就离开或按下重启键，使用鼠标指针的漏斗提示的界面会把用户的等待时间延长到20秒左右，使用动画的鼠标指针漏斗提示界面则会让用户的等待时间超过1分钟，而进度条可以让用户等待到最后。

Peter Bickford 的调查结果被广泛用到web软件系统的性有需求的响应时间定义中。

 

从上面的结果发现，增加用户感知远比性能的提升更能延长用户等待，这个非常有意思。也就是说在同样的响应时间下，用户感知将非常重要。

无loading：如果响应非常短暂，最好不要用loading ,用户无法看清loading ，反而影响体验

Loading：如果响应时间大于1s 的话可以加loading 效果，增加用户感知。

进度条：如果需要更长时度测需要使用进度条来增加用户感知。

时度条+倒计时：在一些需要长时间等待的处理过程中，时度条+倒计时是个不错的选择，倒计时可以让用户预计完成时间，以便用这个空闲去处理其它业。

 

 

最快给用户看到

 

有时候增加loading 可以增加用户等待，但他不是最好用户体验，还记得一张很大的图片是怎么显示的么？

自顶向下显示，自顶向下逐行的来显示，直到整个完整的图片

切成若干小图，得到一个小图展示一个小图，终使用户看到完整的图片。

由模糊到清晰，一张图片有规律的先抽取上面一部分像素显示，使一张图片由模糊到清晰。

分页显示：

当用户请求一批数据时，只给用户最先看到的一页的数据，翻页时再来加载展示第二页的数据。

边展示边加载：

你一定访问过花瓣网吧！滚动条永远也拖不到底部，因为屏幕的大小总是有限的，所以有可以采用边显示边处理加载。

 

　　性能测试分前端性能与后端性能，一般的性能测试更关心后端，但不管什么样的产品最终是要给用户用的。以用户感知为导向的性能测试才更有意义。