网站建设主机,公众号里原文单发到dede网站上,新媒体seo培训,wordpress网站前台密码本篇文章探讨新的测试主题#xff1a;性能测试#xff0c;因为性能测试的专业性很强#xff0c;所以我会以从0到1的入门者视角#xff0c;系统性地阐述性能测试的方法以及应用领域#xff0c;用实例去诠释各种性能指标。 本篇文章站在全局的视角#xff0c;帮你梳理软件性… 本篇文章探讨新的测试主题性能测试因为性能测试的专业性很强所以我会以从0到1的入门者视角系统性地阐述性能测试的方法以及应用领域用实例去诠释各种性能指标。 本篇文章站在全局的视角帮你梳理软件性能、软件性能测试相关的知识点让你对那些你或许已经耳熟能详的性能指标有一个更清晰的理解为你完成后续的性能测试工作打好基础。 在开始下面的内容前请你先思考一个问题当我们谈及软件性能的时候我们到底谈的是什么 目前对软件性能最普遍的理解就是软件处理的及时性。但其实从不同的系统类型以及不同的视角去讨论软件性能都会有所区别。 对于不同类型的系统软件性能的关注点各不相同比如
Web类应用和手机端应用一般以终端用户感受到的端到端的响应时间来描述系统的性能非交互式的应用比如典型的电信和银行后台处理系统响应时间关注更多的是事件处理的速度以及单位时间的事件吞吐量。 这很容易理解。同样地对同一个系统来说不同的对象群体对软件性能的关注点和期望也不完全相同甚至很多时候是对立的。这里不同的对象群体可以分为四大类终端用户、系统运维人员、软件设计开发人员和性能测试人员。 图1 衡量软件性能的四个维度 终端用户是软件系统的最终使用者他们对软件性能的反馈直接决定了这个系统的应用前景而软件开发人员、运维人员、性能测试人员对性能测试的关注点则直接决定了一个系统交付到用户手中的性能。 只有全面了解各类群体对软件系统的不同需求才能保证这个系统具有真正高可靠的性能。所以接下来我会从这四类人的视角和维度去分享软件性能到底指的是什么。
终端用户眼中的软件性能 从终端用户也就是软件系统使用者的维度来讲软件性能表现为用户进行业务操作时的主观响应时间。具体来讲就是从用户在界面上完成一个操作开始到系统把本次操作的结果以用户能察觉的方式展现出来的全部时间。对终端用户来说这个时间越短体验越好。 这个响应时间是终端用户对系统性能的最直观印象包括了系统响应时间和前端展现时间。
系统响应时间反应的是系统能力又可以进一步细分为应用系统处理时间、数据库处理时间和网络传输时间等前端展现时间取决于用户端的处理能力。 从这个角度来看你就可以非常容易理解性能测试为什么会分为后端服务器端的性能测试和前端通常是浏览器端的性能测试了。
系统运维人员眼中的软件性能 从软件系统运维也就是系统运维人员的角度软件性能除了包括单个用户的响应时间外更要关注大量用户并发访问时的负载以及可能的更大负载情况下的系统健康状态、并发处理能力、当前部署的系统容量、可能的系统瓶颈、系统配置层面的调优、数据库的调优以及长时间运行稳定性和可扩展性。 大多数情况下系统运维人员和终端用户是站在同一条战线上的希望系统的响应速度尽可能地快。但某些情况下他们的意见是对立的最常见的情况就是系统运维人员必须在最大并发用户数和系统响应时间之间进行权衡取舍。比如当有两套系统配置方案可以提供以下系统能力的时
配置方案A可以提供100万并发访问用户的能力此时用户的登录响应时间是3秒配置方案B可以提供500万并发访问用户的能力此时用户的登录响应时间是8秒。 这时从全局利益最大化角度来看系统具有更大并发用户承载能力的价值会更大所以运维人员一般都会选择方案B。 目前有些系统为了能够承载更多的并发用户往往会牺牲等待时间而引入预期的等待机制。比如火车票购票网站就在处理极大并发用户时采用了排队机制以尽可能提高系统容量但却增加了用户实际感受到的响应时间。
软件设计开发人员眼中的软件性能 从软件系统开发也就是软件设计开发人员的角度来讲软件性能关注的是性能相关的设计和实现细节这几乎涵盖了软件设计和开发的全过程。 在大型传统软件企业中软件性能绝不仅仅是性能测试阶段要考虑的问题而是整个软件研发生命周期都要考虑的内容我们往往把围绕性能相关的活动称为“性能工程”Performance Engineering。我曾在惠普软件研发中心的性能测试卓越中心负责这方面的技术工作所以感受颇深。 在软件设计开发人员眼中软件性能通常会包含算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五大方面。其中每个方面关注的点也包括很多。
第一算法设计包含的点
核心算法的设计与实现是否高效必要时设计上是否采用buffer机制以提高性能降低I/O是否存在潜在的内存泄露是否存在并发环境下的线程安全问题是否存在不合理的线程同步方式是否存在不合理的资源竞争。
第二架构设计包含的内容
站在整体系统的角度是否可以方便地进行系统容量和性能扩展应用集群的可扩展性是否经过测试和验证缓存集群的可扩展性是否经过测试和验证数据库的可扩展性是否经过测试和验证。
第三性能最佳实践包含的点
代码实现是否遵守开发语言的性能最佳实践关键代码是否在白盒级别进行性能测试是否考虑前端性能的优化必要的时候是否采用数据压缩传输对于既要压缩又要加密的场景是否采用先压缩后加密的顺序。
第四数据库相关的点
数据库表设计是否高效是否引入必要的索引SQL语句的执行计划是否合理SQL语句除了功能是否要考虑性能要求数据库是否需要引入读写分离机制系统冷启动后缓存大量不命中的时候数据库承载的压力是否超负荷。
第五软件性能的可测试性包含的点
是否为性能分析Profiler提供必要的接口支持是否支持高并发场景下的性能打点是否支持全链路的性能分析。
需要注意的是软件开发人员一般不会关注系统部署级别的性能比如软件运行目标操作系统的调优、应用服务器的参数调优、数据库的参数调优、网络环境的调优等。 系统部署级别的性能测试目前一般是在系统性能测试阶段或者系统容量规划阶段由性能测试人员、系统架构师以及数据库管理员DBA协作完成。
性能测试人员眼中的软件性能 从性能工程的角度看性能测试工程师关注的是算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五大方面。 在系统架构师、DBA以及开发人员的协助下性能测试人员既要能够准确把握软件的性能需求又要能够准确定位引起“不好”性能表现的制约因素和根源并提出相应的解决方案。 一个优秀的性能测试工程师一般需要具有以下技能
性能需求的总结和抽象能力根据性能测试目标精准的性能测试场景设计和计算能力性能测试场景和性能测试脚本的开发和执行能力测试性能报告的分析解读能力性能瓶颈的快速排查和定位能力性能测试数据的设计和实现能力面对互联网产品全链路压测的设计与执行能力能够和系统架构师一起处理流量标记、影子数据库等的技术设计能力深入理解性能测试工具的内部实现原理当性能测试工具有限制时可以进行扩展二次开发极其宽广的知识面既要有“面”的知识比如系统架构、存储架构、网络架构等全局的知识还要有大量“点”的知识积累比如数据库SQL语句的执行计划调优、JVM垃圾回收GC机制、多线程常见问题等等。 看到如此多的技能要求你可能有点害怕的确性能测试的专业性比较强我经常把优秀的性能工程师比作是优秀的医生也是这个原因。你需要在实际项目中积累大量的实际案例才能慢慢培养所谓的“性能直觉”从我个人的学习路径来讲也是如此。 天下无难事只怕有心人所以抓住一切可以充实自己的机会吧我们终将会破茧成蝶。 这就是终端用户、系统运维工程师、软件开发工程师以及性能测试工程师眼中的性能测试了至此我们也就非常容易理解不同的群体对同一个系统的性能要求为什么会如此不同。 现在我再来和你说说衡量软件性能的三个最常用的指标并发用户数、响应时间以及系统吞吐量。只要你接触过性能测试或者你的团队开展过性能测试你都应该听说这三个指标。但其实很多人对它们的理解还都停留在表面并没有深入细致地考虑过其本质与内涵这也导致了性能测试很多时候并没有发挥应有的作用。 因此接下来我会和你深入地聊聊这三个指标的内涵和外延帮助你获得一个全新的认识。
并发用户数 并发用户数是性能需求与测试最常用也是最重要的指标之一。它包含了业务层面和后端服务器层面的两层含义。
业务层面的并发用户数指的是实际使用系统的用户总数。但是单靠这个指标并不能反映系统实际承载的压力我们还要结合用户行为模型才能得到系统实际承载的压力。后端服务器层面的并发用户数指的是“同时向服务器发送请求的数量”直接反映了系统实际承载的压力。 为了让你更好地理解这两层含义之间的区别我们先一起来看一个实例一个已经投入运行的ERP系统该系统所在企业共有5000名员工并都拥有账号也就是说这个系统有5000个潜在用户。 根据系统日志分析得知该系统最大在线用户数是2500人那么从宏观角度来看2500就是这个系统的最大并发用户数。但是2500这个数据仅仅是说在最高峰时段有2500个用户登录了系统而服务器所承受的压力取决于登录用户的行为所以它并不能准确表现服务器此时此刻正在承受的压力。 假设在某一时间点上这2500个用户中30%用户处于页面浏览状态对服务器没有发起请求20%用户在填写订单也没有对服务器发起请求5%用户在递交订单15%用户在查询订单而另外的30%用户没有进行任何操作。那么此时这2500个“并发用户”中真正对服务器产生压力的只有500个用户5%15%*2500500。 在这个例子中5000是最大的“系统潜在用户数”2500是最大的“业务并发用户数”500则是某个时间点上的“实际并发用户数”。而此时这500个用户同时执行业务操作所实际触发的服务器端的所有调用叫作“服务器并发请求数”。 从这个例子可以看出在系统运行期间的某个时间点上有一个指标叫作“同时向服务器发送请求的数量”这个“同时向服务器发送请求的数量”就是服务器层面的并发用户数这个指标同时取决于业务并发用户数和用户行为模式而且用户行为模式占的比重较大。 因此分析得到准确的用户行为模式是性能测试中的关键一环。但获得精准的用户行为模式是除了获取性能需求外最困难的工作。
目前获取用户行为模式的方法主要分为两种
对于已经上线的系统来说往往采用系统日志分析法获取用户行为统计和峰值并发量等重要信息而对于未上线的全新系统来说通常的做法是参考行业中类似系统的统计信息来建模然后分析。
响应时间 通俗来讲响应时间反映了完成某个操作所需要的时间其标准定义是“应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间”是用户视角软件性能的主要体现。 响应时间分为前端展现时间和系统响应时间两部分。其中前端时间又称呈现时间取决于客户端收到服务器返回的数据后渲染页面所消耗的时间而系统响应时间又可以进一步划分为Web服务器时间、应用服务器时间、数据库时间以及各服务器间通信的网络时间。 除非是针对前端的性能测试与调优软件的性能测试一般更关注服务器端。但是服务器端响应时间的概念非常清晰、直接就是指从发出请求起到处理完成的时间没有二义性而前端时间的定义在我看来存在些歧义。所以接下来我会和你详细聊聊前端时间这个话题。 虽然前端时间一定程度上取决于客户端的处理能力但是前端开发人员现在还会使用一些编程技巧在数据尚未完全接收完成时呈现数据以减少用户实际感受到的主观响应时间。也就是说我们现在会普遍采用提前渲染技术使得用户实际感受到的响应时间通常要小于标准定义的响应时间。 鉴于此我认为响应时间的标准定义就不尽合理了尤其是对于“接收到最后一个字节”。 我来举个实际案例吧。加载一个网页时如果10秒后还是白屏那你一定会感觉很慢、性能无法接受。但是回想一下你曾经上新浪网的经历当加载新浪首页时你应该不会感觉速度很慢吧。其实实际情况是新浪首页的加载时间要远大于10秒只是新浪采用了数据尚未完全接收完成时进行呈现的技术大大缩短了用户主观感受到的时间提升了用户体验。 所以严格来讲响应时间应该包含两层含义技术层面的标准定义和基于用户主观感受时间的定义。而在性能测试过程中我们应该使用哪个层面的含义将取决于性能测试的类型。显然对于软件服务器端的性能测试肯定要采用标准定义而对于前端性能评估则应该采用用户主观感受时间的定义。 当然我们在前端性能测试中会利用一些事件的触发比如DOM-Load、Page-load等来客观地衡量“主观的前端性能”。这部分内容我会在后面介绍前端性能测试时和你详细讨论。
系统吞吐量 系统吞吐量是最能直接体现软件系统负载承受能力的指标。 这里需要注意的是所有对吞吐量的讨论都必须以“单位时间”作为基本前提。其实我认为把“Throughput”翻译成吞吐率更贴切因为我们可以这样理解吞吐率吞吐量/单位时间。但既然国内很多资料已经翻译为了“吞吐量”所以通常情况下我们不会刻意去区分吞吐量和吞吐率统称为吞吐量。 对性能测试而言通常用“Requests/Second”“Pages/Second”“Bytes/Second”来衡量吞吐量。当然从业务的角度来讲吞吐量也可以用单位时间的业务处理数量来衡量。 以不同方式表达的吞吐量可以说明不同层次的问题。比如
“Bytes/Second”和“Pages/Second”表示的吞吐量主要受网络设置、服务器架构、应用服务器制约“Requests/Second”表示的吞吐量主要受应用服务器和应用本身实现的制约。
这里需要特别注意的是虽说吞吐量可以反映服务器承受负载的情况但在不同并发用户数的场景下即使系统具有相近的吞吐量但是得到的系统性能瓶颈也会相差甚远。 比如某个测试场景中采用100个并发用户每个用户每隔1秒发出一个Request另外一个测试场景采用1000个并发用户每个用户每隔10秒发出一个Request。显然这两个场景具有相同的吞吐量, 都是100 Requests/second但是两种场景下的系统性能拐点肯定不同。因为两个场景所占用的资源是不同的。 这就要求性能测试场景的指标必然不是单个需要根据实际情况组合并发用户数、响应时间这两个指标。
总结 本篇文章梳理了软件性能、软件性能测试相关的知识点旨在你对加深软件性能指标的理解为后续的性能测试实战打好基础。 首先我从终端用户、系统运维人员、软件设计开发人员和性能测试人员这四个维度介绍了软件系统的性能到底指的是什么
终端用户希望自己的业务操作越快越好系统运维人员追求系统整体的容量和稳定开发人员以“性能工程”的视角关注实现过程的性能性能测试人员需要全盘考量、各个击破。 然后我介绍了软件性能的三个最常用的指标并发用户数响应时间系统吞吐量
并发用户数包含不同层面的含义既可以指实际的并发用户数也可以指服务器端的并发数量响应时间也包含两层含义技术层面的标准定义和基于用户主观感受时间的定义系统吞吐量是最能直接体现软件系统承受负载能力的指标但也必须和其他指标一起使用才能更好地说明问题。
