软件性能测试

在测试性能的时候，我们需要对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做如下了解： 1、响应时间RT（response time） 　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。 　　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。 2、吞吐量(Throughput) 　　吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言

最近在做性能测试的东西，顺便做一些整理总结。 首先，什么是性能测试？ 谈到性能测试，我们经常会听到三个概念：性能测试、压力测试、负载测试，这三个名词的含义，我们先了解一下。 性能测试 ：指通过模拟真实的并发用户操作，来判断产品是否能够满足用户的需求；也是为了获得系统在某种特定的条件下（特定的负载条件下）的性能指标数据。比如：微信需要同时支持4亿个用户的接入为一个真实的用户需求，但是我们不可能真实的去接入4亿个用户，只能够通过模拟4亿个真实用户去接入，如果我们通过模拟的方式达到该目标了，就说明满足了这个需求。 压力测试： 指在一定的负载情况（资源占用、接入用户量等）下，验证产品的功能是否还能够正常运行以及系统本身是否正常。也指在什么极限情况下系统会崩溃，系统崩溃后是否具有自我恢复性。通过强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。 压力测试分为 高负载下的长时间 （如24小时以上）的稳定性压力测试和 极限负载情况 下导致系统崩溃的破坏性压力测试。 负载测试： 系统正常工作时所能承受的最大负载，也可称为“容量测试”。模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源

本文收集了学习jmeter过程中讲述比较详细的几篇文章，以备后续查看学习。 Jmeter软件安装： jmeter安装和环境配置 Jmeter入门使用指南： 详细的软件使用教程 官网文档地址: 官网说明文档 来源： CSDN 作者： workingman_li 链接： https://blog.csdn.net/workingman_li/article/details/104769521

在应用程序的生命周期中，应尽早建立性能测试意识。 确保应用一切就绪 需要考虑的问题： 应用程序部署后需要支持多少最终用户？6个月后？1年后？3年后呢？ 这些用户分布在哪里？他们是如何与系统建立连接的？ 部署后有多少在线用户、并发用户？6个月后？1年后？3年后呢？ 引申出的问题： 对于每个应用程序，需要多少台服务器？这些服务器的配置是怎么样？是否需要集群？ 我需要提供什么类型的网络基础设施？ 性能测试重点关注的方面： 选择合适的性能测试工具； 设计一个合适的性能测试环境； 设置切合实际的性能测试目标； 确保被测应用程序足够稳定； 安排有足够的时间进行有效的性能测试； 做到代码冻结； 确定和编写关键业务脚本； 提供高质量、足够的测试数据； 确保准确的性能测试设计； 确定监控服务器和网络的关键性指标（KPI）； 安排有足够的时间进行有效的性能测试。 性能测试工具 性能测试工具要求： 协议支持（通信协议）； 认证模式（License）； 概念验证（Proof of concept，简称POC，证明其可行性，示范其原理）； 脚本效果（生成脚本的编辑程度）； 解决方案与负载测试工具（提供解决方案）； 外包性能测试or内部执行。 注意：制定替代方案。 预留足够时间 安排足够的时间确保有效的性能测试。 需要考虑的几个方面： 准备测试环境的时间 准备负载生成器环境 确定及描述业务事务的时间

市面上流行的压力/负载/性能测试工具多是来自国外，近年来国内的性能测试工具也如雨后春笋崛起。同时由于开发的目的和侧重点不同，其功能也有很大差异，下面就为您简单介绍10款目前最常见的测试产品。 1、kylinTOP测试与监控平台（商用版） kylinTOP测试与监控平台是一款B/S架构的跨平台的集性能测试、自动化测试、业务监控于一体的测试平台，它是深圳是奇林软件有限公司旗下的一款产品，该工具开放10个免费虚拟用户可供学习和使用。在易用性上较好，录制脚本支持最新版本的浏览器，对谷歌和火狐都支持非常好。对一些https.的网站证书问题，都为用户自动处理好了，可以轻松录制。录制过程高效便捷这是其它性能工具无法比拟的。仿真能力上是目前业界做的最好的性能工具，可以做到完全仿真浏览器行为，也就是单用户的HTTP请求瀑布图可以和浏览器器完全一样。总之它是目前国内一款非常难得好用的性能测试工具，可以完全替代国外的同类产品。目前在军工领域、测评检测机构、国有企业、银行体系、大型企业有着广泛的应用。支持的协议较多，尤其在视频领域支持的协议非常多，具有独特的优势。官网地址： http://www.70testing.com 2、LoadRunner（商用版） 是一款C/S架构的商业版性能测试工具，在国内存在的时间较早，在国内在使用较广泛，知名度较高。该工具免费开放了50个虚拟用户，可供学习和使用

序言 对软件系统而言，性能测试通常包括两部分，一是制造合适的负载，二是在负载条件下进行合理的观测。 定义观测对象 任何系统都是有性能边界的，保证性能需要成本、人力、时间，不可能无休止地亦或是全方位地要求性能指标。 开发软件系统的目的是为了更好的服务用户，用户对系统有品质要求。 影响到用户品质要求的性能指标 是主要的、核心的指标，其它的是次要的指标（比如程序员拍脑袋想的指标）。因此，在进行性能测试之前，定义哪些指标会影响到用户品质要求是必须的工作，哪怕定义的指标不全面。盲目进行性能测试得到的通常是毫无意义的结果。 通常云厂商使用SLA(服务等级协议)来概括用户对系统的品质要求。遗憾的是，由于Kubernetes的复杂性，截止至2019.5.18，各大云厂商都没有提供可以最终公布的SLA。 Kubernetes社区提供了一些SLI(服务等级指标)和SLO(服务等级目标)指导系统性能测试、分析，详见 跳转地址 。这些指标间接地描述了Kubernetes系统服务品质，是性能测试重点关注的指标。 除此之外，Master机器的CPU、Memory等指标，以及ETCD的ioutil等指标也会对Kubernetes服务造成明显影响，因此同样应当纳入性能测试的观测范围。 制造集群负载 便宜的负载 社区资料 表明Kubernetes可以支持5000台Node、15万Pod的集群良好运行。这意味着

1、下载 　　 http://pan.baidu.com/s/1o7p18Ye 　　该软件不用安装，直接解压打开即可使用。 2、使用 　　这里就在win下进行，图形界面较为方便 　　在目录apache-jmeter-2.13\bin 下可以见到一个jmeter.bat文件，双击此文件，即看到JMeter控制面板。主界面如下： 3、创建线程组 　　测试计划-->右键——》添加——》hreads——》线程组 设置循环的次数和并发的线程数量 　　 3、添加http请求 　　创建你要测试的http请求的url信息 　　刚刚创建的线程租上右键——》添加——》Sampler——》HTTP请求 添加http请求相关信息和参数 4、添加查看结果的方式 　　这里有很多种查看结果的方式，结果数、表格、图像等，如下图所示： 　　这里我使用了查看结果树。 5、测试发送一个请求 6、动态参数 　　可以使用读取文件的方式，添加多个动态参数到测试中，jmeter会随机使用我们数据进行测试。 　　 注意，必须保存为csv文件，而不是简单的修改文件的后缀名 。 文件内容：username.cvs 　　password.cvs 　　添加CSV默认值来源文件和变量值 　　在http请求中使用${变量名} 获得文件中的值 　　假如你喜欢界面简单的话可以使用ab性能测试，可查看： http://www.cnblogs

我们先了解一下，为什么要做性能测试： 游戏行业：某游戏上线新功能，目标是全服游戏群体，结果上线后，先后出现了服务器崩溃，游戏功能图标加载缓慢等问题，导致玩家怨声载道，为此，游戏运营商不得不发放了许多奖励。具体损失不表，为赶进度而发布的功能，也因为生产事故导致延期更长的时间 这就是典型的没有进行性能测试，或者说性能测试不充分导致出现的生产事故。在游戏行业还比较好，毕竟损失的只是虚拟的货币和玩家的游戏热情，但是在传统行业呢？ 通过这个案例，我们知道，在一些极限的场景下，软/件和硬件会造成极大的破坏和损失，因此，我们需要进行性能测试，来验证软件在高压力下，高并发下，高负载下的实际工作情况。 什么是性能测试 性能测试就是模拟一些极端场景，对软/硬件性能进行测试，判断其极限性能和在极限性能边界上的运行状态。 设计性能测试场景,主要有以下场景： – 基准测试：了解系统在静置时的资源消耗，如cpu,io,网络带宽，网络连接的情况。如果有干扰，务必排除。 – 单次连续请求测试：1次连续请求情况下的tps（Transaction Per Second 每秒事务请求数），响应时间，服务器资源消耗情况，主要用于参考。 – 负载测试：逐渐增加并发请求数，查看tps，响应时间，错误率，服务器资源消耗情况，主要用于分析最大性能。 – 压力测试：在最大性能的临界点上保持压力进行测试

虽然，有一段时间没关注性能测试，但时常还能看到有同学讨论性能，对于一些概念的理解很想深入讨论，但三言两语说不清，于是，还是花点时间写写吧！ 　　今天有一个同学问：“一个小的系统，用户并发数为20个，那事务平均响应时间大概在什么范围内？” 怕麻烦直接告诉他2/5/8原则，钻牛角尖的话，需要进一步确认什么样的小系统？提供的什么类型的业务？用户行为是什么样的？用户对系统的使用频率？就算同响应时时间一样，前端通过不同展现方法，用户的感知可能完全不一样。下面就真对这个问题延伸讨论一下从用户感知的角度看软件性能测试。 2/5/8原则 　　2/5/8原则是上个世纪80年代某公司真对自己公司的应用做的一个调查，调查的结果就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开或者发起第二次请求。 　　到90年代的时候英国真对零售业的网站又做了一次调查， 它的调查结果是一个用户真对一个页面的响应的最长忍耐时间是4s，超过4s 大量的用户会选择放弃页面的响应。 　　我在《 性能测试知多少---响应时间 》中已经对用户的响应时间做过分析

　　 　　虽然，有一段时间没关注性能测试，但时常还能看到有同学讨论性能，对于一些概念的理解很想深入讨论，但三言两语说不清，于是，还是花点时间写写吧！ 　　今天有一个同学问：“一个小的系统，用户并发数为 20 个，那事务平均响应时间大概在什么范围内？” 怕麻烦直接告诉他 2/5/8 原则，钻牛角尖的话， 需要进一步确认什么样的小系统？提供的什么类型的业务？用户行为是什么样的？用户对系统的使用频率？就算同响应时时间一样，前端通过不同展现方法，用户的感知可能完全不一样。下面就真对这个问题延伸讨论一下从用户感知的角度看软件性能测试。 2/5/8原则 　　2/5/8 原则 是上个世纪 80 年代某公司真对自己公司的应用做的一个调查，调查的结果 就是当用户能够在 2 秒以内得到响应时，会感觉系统的响应很快；当用户在 2-5 秒之间得到响应时，会感觉系统的响应速度还可以；当用户在 5-8 秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过 8 秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开或者发起第二次请求。 　　到 90 年代的时候英国真对零售业的网站又做了一次调查， 它的调查结果是一个用户真对一个页面的响应的最长忍耐时间是 4s ，超过 4s 大量的用户会选择放弃页面的响应。 　　我在《 性能测试知多少 --- 响应时间