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

本文涉及的产品
性能测试 PTS,5000VUM额度
简介:

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

  今天有一个同学问:“一个小的系统,用户并发数为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.10.2s:用户认为得到的是即时响应。

15s :用户感觉到基本信息的交互是基本流畅的。用户明显注意到了延迟,感受到计算机的工作过程。

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

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

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

 

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

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

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

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

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

 

 

最快给用户看到

 

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

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

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

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

分页显示:

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

边展示边加载:

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

 

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

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
2月前
|
测试技术 开发者 Python
自动化测试之美:从零构建你的软件质量防线
【10月更文挑战第34天】在数字化时代的浪潮中,软件成为我们生活和工作不可或缺的一部分。然而,随着软件复杂性的增加,如何保证其质量和稳定性成为开发者面临的一大挑战。自动化测试,作为现代软件开发过程中的关键实践,不仅提高了测试效率,还确保了软件产品的质量。本文将深入浅出地介绍自动化测试的概念、重要性以及实施步骤,带领读者从零基础开始,一步步构建起属于自己的软件质量防线。通过具体实例,我们将探索如何有效地设计和执行自动化测试脚本,最终实现软件开发流程的优化和产品质量的提升。无论你是软件开发新手,还是希望提高项目质量的资深开发者,这篇文章都将为你提供宝贵的指导和启示。
|
3月前
|
机器学习/深度学习 人工智能 监控
提升软件质量的关键路径:高效测试策略与实践在软件开发的宇宙中,每一行代码都如同星辰般璀璨,而将这些星辰编织成星系的过程,则依赖于严谨而高效的测试策略。本文将引领读者探索软件测试的奥秘,揭示如何通过精心设计的测试方案,不仅提升软件的性能与稳定性,还能加速产品上市的步伐,最终实现质量与效率的双重飞跃。
在软件工程的浩瀚星海中,测试不仅是发现缺陷的放大镜,更是保障软件质量的坚固防线。本文旨在探讨一种高效且创新的软件测试策略框架,它融合了传统方法的精髓与现代技术的突破,旨在为软件开发团队提供一套系统化、可执行性强的测试指引。我们将从测试规划的起点出发,沿着测试设计、执行、反馈再到持续优化的轨迹,逐步展开论述。每一步都强调实用性与前瞻性相结合,确保测试活动能够紧跟软件开发的步伐,及时适应变化,有效应对各种挑战。
|
2月前
|
jenkins 测试技术 持续交付
自动化测试框架的构建与优化:提升软件交付效率的关键####
本文深入探讨了自动化测试框架的核心价值,通过对比传统手工测试方法的局限性,揭示了自动化测试在现代软件开发生命周期中的重要性。不同于常规摘要仅概述内容,本部分强调了自动化测试如何显著提高测试覆盖率、缩短测试周期、降低人力成本,并促进持续集成/持续部署(CI/CD)流程的实施,最终实现软件质量和开发效率的双重飞跃。通过具体案例分析,展示了从零开始构建自动化测试框架的策略与最佳实践,包括选择合适的工具、设计高效的测试用例结构、以及如何进行性能调优等关键步骤。此外,还讨论了在实施过程中可能遇到的挑战及应对策略,为读者提供了一套可操作的优化指南。 ####
|
2月前
|
机器学习/深度学习 人工智能 自然语言处理
自动化测试的新篇章:利用AI提升软件质量
【10月更文挑战第35天】在软件开发的海洋中,自动化测试犹如一艘救生艇,它帮助团队确保产品质量,同时减少人为错误。本文将探索如何通过集成人工智能(AI)技术,使自动化测试更加智能化,从而提升软件测试的效率和准确性。我们将从AI在测试用例生成、测试执行和结果分析中的应用出发,深入讨论AI如何重塑软件测试领域,并配以实际代码示例来说明这些概念。
97 3
|
3月前
|
测试技术
软件质量保护与测试(第2版)学习总结第十三章 集成测试
本文是《软件质量保护与测试》(第2版)第十三章的学习总结,介绍了集成测试的概念、主要任务、测试层次与原则,以及集成测试的不同策略,包括非渐增式集成和渐增式集成(自顶向下和自底向上),并通过图示详细解释了集成测试的过程。
95 1
软件质量保护与测试(第2版)学习总结第十三章 集成测试
|
3月前
|
测试技术
软件质量保护与测试(第2版)学习总结第十章 黑盒测试
本文是《软件质量保护与测试》(第2版)第十章的学习总结,介绍了黑盒测试的基本概念和方法,包括等价类划分、边界值分析和因果图法,并通过具体例子展示了如何设计测试用例来验证软件的功能性需求。
88 1
软件质量保护与测试(第2版)学习总结第十章 黑盒测试
|
3月前
|
人工智能 人机交互 数据库
软件质量保护与测试(第2版)学习总结第一章
本文是《软件质量保护与测试》(第2版)第一章的学习总结,概述了软件的特征、分类、软件工程的层次化技术、现代软件开发的变化,以及软件质量的概念和评价体系,包括黑盒、白盒和灰盒测试方法。
46 1
软件质量保护与测试(第2版)学习总结第一章
|
3月前
|
敏捷开发 监控 jenkins
自动化测试之美:打造高效的软件质量保障体系
【10月更文挑战第20天】在软件开发的海洋中,自动化测试如同一艘精准的导航船,引领项目避开错误的礁石,驶向质量的彼岸。本文将扬帆起航,探索如何构建和实施一个高效的自动化测试体系,确保软件产品的稳定性和可靠性。我们将从测试策略的制定、工具的选择、脚本的编写,到持续集成的实施,一步步描绘出自动化测试的蓝图,让读者能够掌握这一技术的关键要素,并在自己的项目中加以应用。
45 5
|
3月前
|
Java 测试技术 持续交付
探索自动化测试的奥秘:提升软件质量的关键
【10月更文挑战第20天】 在当今快速发展的软件行业中,自动化测试已成为确保产品质量和加速开发周期的重要工具。本文将深入探讨自动化测试的核心概念、实施策略及其对软件开发生命周期的影响,旨在为读者提供一种全面理解自动化测试的视角,并展示如何有效地将其应用于实际项目中以提高软件质量和效率。
36 2
|
3月前
|
测试技术
软件质量保护与测试(第2版)学习总结第十一章 白盒测试
本文是《软件质量保护与测试》(第2版)第十一章的学习总结,详细讲解了白盒测试中的控制流测试技术,包括语句覆盖、判断覆盖、条件覆盖、判定-条件覆盖和路径覆盖等方法,并通过具体代码示例展示了如何设计测试用例来验证程序中的不同执行路径。
86 2

热门文章

最新文章