软件性能测试

1. 前言 上周，对性能测试系列专题，在公号内发表了第一篇介绍： 【性能系列连载一】开篇：性能测试不可不知的“干货” ，但反响貌似并不太好，但既然此前已答应了部分读者要连载分享性能这块的知识，含着泪也得继续写。 性能测试的基础： 就是在确保功能实现正确的前提下，通过合适的性能测试加压方式和策略，并收集考察服务端应用程序的各项性能指标，以及服务器硬件资源的使用情况，来评估是否存在性能问题隐患。 那今天作为性能测试系列的第二篇，主要会为大家介绍在 服务端性能测试 中，常见的性能指标有哪些。 2. 性能指标分类 从性能测试分析度量的度角来看，可以从如下几个维度来收集考察各项性能指标： 系统性能指标 资源性能指标 中间件指标 数据库指标 稳定性指标 可扩展性指标 可靠性指标 下面将从如上这几个维度，分别从各自维度常见指标，以及指标含义、指标行业参考标准等方面进行介绍。 3. 系统性能指标 系统性能指标，常见的可从如下几类进行参考： 响应时间 系统处理能力 吞吐量 并发用户数 错误率 3.1 响应时间 定义和解释： 响应时间，简称RT。是指系统对请求作出响应的时间，可以理解为是指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。

一、性能测试指标 1.并发 幵发分为狭义和广义两类。 狭义的幵发，即所有的用户在同一时间做同一件事情，这种操作一般针对同一类 型的业务或者所有用户进行完全一样的操作，目的是测试数据库和程序对幵发操 作的处理。狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测试； 广义的幵发，即多个用户对系统发出了请求或进行了操作，但这些请求和操作是 丌同的。对整个系统而言，仍然有很多用户同时进行操作。 广义并发丌限制对系统的请求操作，多适用于混合场景、稳定性测试场景。 2.并发用户数 幵发是指在某一给定时间内，某个特定点上进行会话操作的用户数。 3.响应时间 响应时间指的是宠户端发出请求到得到响应的整个过程所经历的。 指从宠户端发一个请求开始时，到宠户端接收到从服务器端返回的响应 结果线束经历的时间，响应时间由请求发送时间、网络传输时间和服务 器处理时间三部分组成。 4.吞吐量 吞吐量是指单位时间内系统处理的宠户请求的数量，直接体现软件系统 的性能承载能力。 一般来说，吞吐量用请求数/秒或页面数/秒来衡量，从业务的角度，吞 吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。从网络 的角度来说，也可以用字节数/天等单位来考察网络流量。 5.资源利用率 资源利用率是指系统资源的使用程度，比如服务器（网络以及数据库） 的CPU利用率、内存利用率、磁盘利用率

在线用户数：用户同时在一定时间段的在线数量 并发用户数：某一时刻同时向服务器发送请求的用户数 一般而言，我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即，并发与在线的比例约为5%-20% 比如，某网站存在注册用户数为10W人，但同时在线最多1W人，但这1W个人，可能只有500人会浏览帖子，500人会进行发帖，只有这1000个人对服务器才有交易，那我们计算并发量的时候，就可以以1000为标准！ ----------------------------------------------------------------------------------------------------------------------------- 昨天读完了段念写的《软件性能测试过程详解与案例剖析》一书的第一章，感觉学到了不少东西，以下将该书中的我认为是精华的一篇过来给大家一起看看： 在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。 假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到

一、JMeter 介绍 Apache JMeter是100%纯JAVA桌面应用程序，被设计为用于测试客户端/服务端结构的软件(例如web应用程序)。它可以用来测试静态和动态资源的性能，例如：静态文件，Java Servlet,CGI Scripts,Java Object,数据库和FTP服务器等等。JMeter可用于模拟大量负载来测试一台服务器，网络或者对象的健壮性或者分析不同负载下的整体性能。 同时，JMeter可以帮助你对你的应用程序进行回归测试。通过你创建的测试脚本和assertions来验证你的程序返回了所期待的值。为了更高的适应性，JMeter允许你使用正则表达式来创建这些assertions. JMeter与LoadRunner比较 JMeter 是一款开源(有着典型开源工具特点： 界面不美观 )测试工具，虽然与LoadRunner相比有很多不足，比如：它结果分析能力没有LoadRunner详细；很它的优点也有很多： 开源，他是一款开源的免费软件，使用它你不需要支付任何费用， 小巧，相比LR的庞大（最新LR11将近4GB），它非常小巧，不需要安装，但需要JDK环境，因为它是使用java开发的工具。 功能强大，jmeter设计之初只是一个简单的web性能测试工具，但经过不段的更新扩展，现在可以完成数据库、FTP、LDAP、WebService等方面的测试。因为它的开源性

系统性能指标 1.1 交易响应时间 1.1.1 定义及解释 响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒或毫秒,如果利用PTS发起侧优势+生产环境则无限接近于真实环境的用户体验时间了。平均响应时间：指系统稳定运行时间段内，同一交易的平均响应时间。一般而言，交易响应时间均指平均响应时间。平均响应时间指标值应根据不同的交易分别设定，一般情况下，分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中，特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。 1.1.2 简称 Response Time: RT 1.1.3 参考标准 不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易： 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。 金融企业：1秒以下为佳，部分复杂业务3秒以下。 保险企业：3秒以下为佳。 制造业：5秒以下为佳。 对于批量交易： 时间窗口：不同数据量结果是不一样的，大数据量的情况下，2小时内完成。 1.2 系统处理能力 1.2.1 定义及解释 系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解

一. 什么是（软件）性能测试 性能 ：事务、物品的某些特性的评价值 软件性能测试 ：是用一定的技术，找出或验证某个性能指标值的测试，如：你跑100米，用时多少？ 举例： “看看你有几斤几两”： 　　逐步增加系统负载，测试系统性能变化，并最终确定系统所能承受的最大负载量 “鸭梨好大哦！”： 　　在较大的性能压力下，持续运行一个比较长的时间，看系统服务及各项资源利用情况 　　关键词：较大压力 + 较长时间 一般测试中，找出最大的负载量，比如100，然后选择一个比100稍微小点的做7 x 24小时压力测试。一般开始前，先做一个较低的比如10或者20的压力测试，测试通过说明系统的可靠性有一定的保障，再在性能瓶颈90的时候做压力测试 可靠性测试 ：在给定的一定的业务压力下，持续运行一段时间，查看系统是否稳定 　　关键词：是否“稳定”，一定业务压力 容量测试 ：在一定的软、硬件条件下，在数据库不同数量级数据量的情况下，对系统中读写比较多的业务进行测试，从而获得不同数据量级下的性能指标值 　　关键词：不同数据量级 举例： 可靠性测试：一定的压力并不要求较高，比较低的压力测试，比如最大负载量为100的时候，选择10或者20 容量测试：比如查询1个用户数据和10000个用户数据，数据库查询的响应时间 二. 性能测试的目的 目的：寻找或证明系统的某些关键性性能指标 　　1. 全新系统，从未做性能测试

在应用程序上线之前，有多少人做过性能测试？ 估计大部分开发者更多地关注功能测试，并且会提供一些单元测试和集成测试的用例。然而，有时候性能漏洞导致的影响比未发现的业务漏洞更严重，因为性能漏洞影响的是整个系统，而不仅仅是一个业务进程。 可能你们很多人听过 JMeter ，但是今天将介绍有竞争力的解决方案 —— Gatling 。它能生成丰富多彩的报告，包含测试案例中收集的所有指标。该功能似乎比 JMeter 更好。 在讨论 Gatling 之前，先了解下理论知识，性能测试的两种类型，负载测试和压力测试： 负载测试（Load Testing）：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。 压力测试（Stress Testing）：压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。 Gatling 简介 Gatling 是一个功能强大的负载测试工具。它是为易用性、可维护性和高性能而设计的。 开箱即用，Gatling 带有对 HTTP 协议的出色支持，使其成为负载测试任何 HTTP 服务器的首选工具。由于核心引擎实际上是协议不可知的

1.性能评估模型概述 我们的系统性能到底能不能够支撑线上真实大量的订单交易？ 我想，这是我们每一个互联网交易或者负责大并发项目的同学都很关心的问题，也是性能评估模型篇需要解答的最终问题。所以我们就带着这个问题来一步步深入性能测试。本问题的难度不在于一个简单的结果，而在于答案背后的一系列性能测试的评估数据和算法，以及如何建立一个良好可持续的“性能评估模型”。 通常来讲，性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。 而要回答“能否支撑线上真实 大量的订单交易 ”这样带有预测性的问题，实际上还需要用上另一种手段，即“ 性能预测 ”，而“在线性能评估模型”就是用来做性能预测的。 在预测之前，我们先来做一个数据分析，通过这个分析我们可以大概了解线上与线下的推算过程。 2013年11月11日，支付宝实现了当天交易总金额 350 亿元 ，订单总数 1.8 亿笔 （其中手机支付占24%），活跃用户 1.2 亿 。（来源：支付宝官方微博 http://weibo.com/1627897870/AiiAjEwHO ） 显然这是一个非常震惊的数字，它见证着电商的今天也预示着电商的未来。针对这个数字，下面我们就一起来剖析数字背后的性能情况。 双11当天，支付宝的订单数是1.8亿笔，意味着每小时订单数达到1.8亿 / 24 = 750万笔

性能测试曲线模型是一条随着测试时间不断变化的曲线，与服务器资源，用户数或其他的性能指标密切相关的曲线。如下图所示。 在图中，我们的曲线图主要分为3个区域，分别是：light load ：轻压力区；heavy load ：重压力区；和buckle load . 图中的3条曲线，分别表示资源的利用情况（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及响应时间（Response Time）。图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。 在进行性能测试的时候，我们需要对图的曲线进行分析。分开来看的时候，响应时间（RT）、吞吐量（TPS）和资源利用率的变化情况分别是： 　　响应时间：随着并发用户数的增加，在前两个区，响应时间基本平稳，小幅递增。在第三个区域：急剧递增。在第三个区的点为拐点。 　　吞吐量：随着并发用户数的增加，在前两个区，对于一个良好的系统来说，并发用户数的增加，请求增加，吞吐量增加，中间的区域，处理达到顶点。 　　在第三个区：资源利用率：呈直线，表示饱和。 分析结论： 　　当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续 工作 ，但是用户的等待时间延长

原文链接： http://www.cnblogs.com/longronglang/p/9879570.html 概念 首先来说说性能测试：性能是软件的一种非功能特性，他关注的不是软件是否完成了特定的功能，而是软件在完成特定功能是展示出来的及时性。 及时性从不同的视角代表不同的指标： 用户：响应时间 系统管理员：资源利用率，可扩展性，系统稳定性，系统容量 开发人员：系统架构，数据库设计，设计和代码实现 可见，系统稳定性对系统管理员的意义重大，稳定性的好坏也可以直接影响到最终用户所关心的“响应时间”，所以说稳定性测试时性能测试中非常重要的一环。 稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为7x24小时），检测系统是否能够稳定运行。 如何实施 一、识别并确认软件主要业务（是否需要稳定性测试） 将稳定性测试的重心放在软件最有Value的地方，比如说一个抢票系统，它最有value的地方是当有一定数量的用户同时进行买票操作是系统的相应时间，资源利用率等是否能够正常且稳定，而不是用户如何添加新的联系人，修改个人信息等 二、罗列主要用户场景及相应负载量 1、用户场景可以根据软件主要业务进行设定 2、对主要场景负载量需要有一个清晰的定义（或者通过负载测试验证了用户场景的负载量，这将作为一个标准的负载在稳定性测试中使用） 三、制定稳定性指标模型