性能测试基本测试概念

一、性能测试的目的一、性能测试的目的 1、评估当前系统 2、寻找瓶颈 3、预测未来性能 二、性能测试的前提：二、性能测试的前提： 接口稳定/接口确定 三、性能术语与指标详解：三、性能术语与指标详解： 1. 并发： （1）一种为所有用户在同一时刻做同一操作，主要是为了验证程序或 数据库对并发处理能力 （2）另一种为多个用户对被测系统发起了多个请求，这些请求可以是 同一种操作，也可以是不同操作，类似于混合场景的概念 2. 响应时间：响应时间反应完成某个业务所需的时间 响应时间= 网络传输时间（请求）+服务器处理（一层或多层）时间+网络传输 时间（响应时间）+页面前端解析渲染时间 3.每秒通过事务数（TPS） ：指每秒通过的事务数，是直接反映系统性能的指标， 该值大时，系统性能比较好，当然每个系统都有他的上限，不可能无限大 将他以平均事务响应时间进行对比，可以分析事务数量对以响应时间的影响 4.事务：用户一个或一系列的操作，代表一定的功能，在程序上变现为一段代码 区块， 所有性能测试其实最终都是围绕着事务展开的，事务代表用户的使用方法 和结果，不同的操作组合成不同的事务，不同的事务又能组合成不同的场景 （LR必须至少有一个事务，LR 监控事务） （事务不能超过接口的上限） 事务 Transactions 5.事务请求时间：从这个事务发起到最终处理完毕的所有时间。 一个事物包括一个或多个事务，每个任务包含一个或多个请求。 6.每秒点击数：每秒点击数代表用户每秒向外部服务器提交的 http 请求，但这 里需要注意是提交一个登陆请求对于后端服务器来说， 也许是多个请求，所以点 击一次不代表就是一个请求。 7.吞吐量/吞吐率（I/O） （/Output） （反应服务器处理能力） 吞吐量：指单位时间内系统处理的请求数量 吞吐率： 一般指用户在给定的一秒内从服务器获取的数据量，简而言之就是服务 器返回的数据量 8.思考时间： 指用户进行操作时每个请求或操作之间的间隔时间，是为了更加真 实的模拟用户的操作场景。 9.资源利用率（服务器） CPU：一般分为系统 CPU 和用户 CPU 系统 CPU：是处理系统本身占用的资源 用户 CPU：是处理程序所占用的资源 Load Average：指一段时间内 CPU 正在处理和等待 CPU 处理的任务，也就是 CPU 使用队列的长度的统计信息 缓存（比 CPU 运行速度慢） ：他就像大脑的记忆区域，将各种信息收集起来存 放，数据从内存中读取要比硬盘上读取速度快，内存会有泄露和溢出现象。 队列：可以理解成地铁进站的排队现象，队列长，说明处理能力可能达到了 极限或者遇到的阻塞 I/O（硬盘） ：与磁盘的交互，重点关注交换频率和磁盘队列长度 网络：重点关注网络的流量，看是否存在网络带宽的瓶颈 四、性能测试分类四、性能测试分类 1.基准测试： 可以在制定的标准下通过测试建立一个性能基准，这样以后当系统 的环境参数发生变化后，在进行一次相同标准下的测试，即可看出变化对性能的 影响。系统进行基准测试可以在较早的阶段发现性能问题。 2.并发测试： 可以理解为很多的用户按照预定的场景并发请求某个业务或功能时 是否出现并发问题。 并发测试的算法： （1） 并发数=PV/PV Time*页面连接次数*HTTP 响应时间*因数/web 服务器 数量 解释：PV：即页面浏览量，一个用户可能创造十几个甚至更多的 PV。 他是目前判断网站访问流量最常用的计算方法，也是反映网站受欢迎 程度的重要指标。 PV Time：是 PV 的统计时间，换算成秒，一天就是 86400 秒 页面连接次数包括外部的 JS，CSS，图片等，一般为 10 HTTP 响应时间一般为 1 秒或更少 因数一般为 5 （2） C=nL/T (段念【软件性能测试过程详解与案例剖析】) 解释：C 是平均的并发用户数 n 是平均每天访问用户数 L 是一天内用户从登录到退出的平均时间（操作时间） T 是考察时间长度 C’≈C+3*√c 解释：C’ 是最大并发数 3.负载测试： 可以理解为确定所要测试的业务或系统的负载范围，然后对其进行 测试，他的主要目的验证业务或者系统在给定负载条件下的处理能力。此外，还 要关注响应时间、每秒通过事务数和其他相关指标。 负载测试是为了发现性能问题。而性能测试是为了获取性能指标。 4.压力测试： 可以理解为没有预期的性能指标， 不断加压， 看系统什么时候崩溃， 以此来确定系统的瓶颈不能接受的性能拐点，以获取系统的最佳并发数，最大并 发数 压力测试也可以看作负载测试的一种， 即高负载下的负载测试。负载测试 与压力测试的概念并非完全独立，在实际应用中一般二者都是相互结合，相互补 充的。 5.稳定性测试（小公司不测）：需要长时间运行，在这段时间内观察系统的出错 几率、性能变化趋势等。进而大大减少系统上线后的崩溃的现象。 一般都会进行所谓的 7*24 小时的稳定性测试 1）一般稳定性测试需要在系统成型后进行，并且没有严重的 BUG 存在 2）场景的设计以模拟真实用户的实际操作为最佳。 6.失效恢复测试（小公司不测）：重在关注系统出现问题后能否根据预先制定的 策略回恢复，且恢复后能否正常运行。 失效恢复测试一般是对其具有负载均衡的系统进行的， 主要是为了 测试当前系统发生故障时，是否会对全局产生大的影响，产生的影响在是否可以 接受的范围内，以及用户能否继续使用系统。 在实际应用过程中， 可以模拟一台或者几台负载均衡出现故障来进 行失效恢复测试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问 或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用 户，以及采用那些备选方案来响应。 7.现网性能测试（小公司不测） ：就是实际网络，实际环境中进行测试，完全和 真实用户一样，当然这样的测试有一定的风险，需要注意以下几点： （1）时间段的选择，非高峰时间段，选择都为半夜或者凌晨来进行 （2）垃圾数据处理。测试数据后期一定要清理，为了清理方便、前期数 据的设计要有规律可循 （3）网络限制，压力机需要和被测试服务器部署在同一个网段机房内， 这样可以避免网络限制，最后远程收集数据即可。 *如果没有特殊情况，尽量不要进行现网的性能测试，风险比较大，如果非要进 行，一定要事先充分评估风险以及应对的解决方案。 LRLR 的三大模块的三大模块 Virtual user Generator LR8（虚拟用户生成器） Create/Edit ScriptsLR11 创建/编辑脚本 LR 进行操作的第一步，制造基本性能脚本 性能测试前的准备 Controller（控制器） Run Load Tests 运行负载测试 在脚本写完的基础下，对其设置不同的场景，进行测试 性能测试执行 Analysis（分析） Analyze Load Tests 分析测试结果 参看性能测试的结果数据，并进行适当的分析 预期结果与实际结果的对比，并查找问题根源 模块间的关系模块间的关系 LR8 Virtual User Generator-Controller-Analysis LR11 Create/Edit Scripts