一、软件性能描述
软件性能：指软件运行过程中的响应时间与系统资源消耗情况是否满足用户需求
二、性能测试相关术语
1．响应时间：客户端发出请求开始到客户端接收到所有数据所消耗的时间
（网络传输时间+应用服务器处理时间+数据库服务器处理时间）
2．并发用户数：同一时刻与服务器进行数据交互的所有用户数量
如何确定并发用户数：参考其他同类产品；分析历史数据；试上线运行
3．吞吐量：单位时间内服务器处理的数据量（服务器处理数据的效率）。
指在一次性能测试过程中网络上传输的数据量的总和
单位B/S，体现服务器承载能力
F = NVN*R / T
F:吞吐量；NVN：虚拟用户个数；R：在T时间内每个虚拟用户发出的请求字节数 T:性能测试所用时间
4．吞吐率：单位时间内服务器返回的的数据量 吞吐率=吞吐量/测试时间
5．TPS：服务器每秒处理的事务数
6．点击率:每秒用户向服务器提交的服务请求数量，点击率值越大，服务器承受压力越大
7．资源利用率:服务器系统中不同硬件资源被使用的程度
资源利用率=资源实际使用量/总可用资源量
8．性能计数器:描述服务器或操作系统性能的一些数据指标。主要通过添加计数器来观察系统资源的使用情况
9．思考时间:模拟用户在操作系统时，发送请求的时间间隔
思考时间函数 lr_think_times();
10．事务：就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程。这些我们都可以看作一个事务。
三、性能测试划分
1．负载测试:通过对系统不断的加压，直到超过预定的指标或者部分资源已达到饱和状态不能再加压为止
目的：找到系统最大的负载能力
2．压力测试:系统已经达到一定的饱和程度，此时系统的处理业务的能力，系统是否会出现错误
疲劳测试是压力测试的一种表现形式
3．配置测试:通过调整系统软硬件环境，了解不同环境对系统性能的影响，从而找到系统的最优配置
4．并发测试:模拟大量用户同时访问同一应用、模块或数据，观察系统是否存在死锁、系统处理速度是否明显下降等问题
5．可靠性测试:系统在一定的业务压力下，让系统持续运行一段时间，观察系统是否达到要求的稳定性
6．基准测试:在一定软硬件及网络环境下，模拟一定数量虚拟用户运行一种或多种业务，将测试结果作为基线数据，在系统调优或者系统测评过程中，通过运行相同的业务场景并比较测试结果确定调优是否达到效果或者为系统的选择提供决策数据
7．各测试执行阶段：
编码阶段（发现性能问题）：并发测试、压力测试、配置测试
测试阶段（测系统稳定性，对性能进行调优）：负载测试、基准测试、配置测试
四、性能测试应用领域
1．能力验证：验证系统是否实现所需功能
2．规划能力：系统的可扩展能力
3．性能调优：通过测试来调整系统的环境，最终使系统性能达到最优的状态
4．缺陷发现：通过各方面的性能测试来寻找系统在上线时可能出现的问题
并发的两种情况
一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，所有用户同一时刻做并发登陆，同一时刻做表单提交。
另外一种并发是广义范围的并发，多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。在同一时刻有用户在登录，有用户在提交表单。
从服务器的角度来看并发
如果考虑整个系统运行过程中服务器所承受的压力是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向服务端发送请求的客户数”，这个就是所谓的服务器所承受的最大并发访问数。
真正意义上的并发不存在
CPU在一个时间点上只能干一件事儿
那么我们的系统在接到用户的请求后也要调用CPU来完成某些处理，然后返回给用户。那么我们对系统有做并发测试是测什么呢？举个简单的例子。假如有一位神医，他的看病速度非常快，假设他的看病速度是不变的；然后有一群接待人员来接待看病的客人，有成千上万的病人来看病，接待人员要想各种办法来做好接待工作，使病人更快的看到病。比如，可以事先咨询病人得的什么病，然后将病人进行分类，比如可以扩大接待室，让更多的病人可以进到医院来看病等。
神医就是我们的CPU，接待人员就是我们的系统，病人就用户，我们做性能测试的目的就是了解接待人员哪个地方给医院看病造成了瓶颈。只来一个病人，医院的看病速度与服务很好。一下子来十万个病人各种问题就出来了。接待人员的服务态度下降，多余的人员跟本进不到医院去，医院的洗手间不够用，造成病人无法上则所而离开，这些都属于系统问题。所以，我们一般测试的目的是看医院的接待能力。
系统用户数与同时在线人数
在实际的性能测试中，经常接触到与并发用户相关的概念还有“系统用户数”与“同时在线人数”下面通过一个实例来描述他们之间的差别。
假设有一个网站，注册用户才能登录使用各种功能，如上传头像，阅读专家文章等。该系统有20万注册用户，这就是说有20万用户可以使用这个网站的所有功能，20万就是这个网站的“系统用户数”，网站有一个在线统计功能，从统计数据中可以看到，同时登录网站的人数的最高记录是2万，就是有2万人同时用浏览器打开着这个网站。2万就是“同时在线人数”
那么系统的并发用户数是多少呢?2万么？NO!这2万只表示在系统最高峰时有这么多用户登录了网站，并不表示实际服务器的承受压力。因为服务器承受压力还与具体的用户访问模式相关，在这2万用户中考察某一个时间点对用户发出请求数，可以会大大缩水。那么，该系统的服务端承受的最大并发访问数是多少呢？这个取决于业务并发用户数和业务场景，一般可以通过服务器日志的分析得到
合理的响应时间
在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。
也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。
这里我们还要考虑一个使用频率的概念。
我最早安装windows系统可能要1个小时，我们为什么觉得这很正常，因为我们要很久才装一次系统，如果系统使用得当，可能一个系统用几年不用重装，假如，我们在系统上装个任何小软件都要这么长时间，那我们一定是无法忍受的。对于软件控来说，他们会时常安装各种新鲜有趣的软件进行使用。
对于一个税务报账系统，该系统的用户每月使用一次，一次花费3小时进行数据的录入，当用户单击“提交”按钮后，即使系统在10分钟后才给出“处理成功”的消息，我们也觉得是可以接受的。
因此，在进行性能测试时，“合理的响应时间”取决于用户的需求，而不能依据测试人员自己设想来决定。