背景
不知道各位大佬有没遇到上面的情况，性能这个东西到底是什么，还是以前的358原则吗？明显并不是适用于现在了。多次想踏入性能测试门槛都以失败告终，这次就以系列的方式来督促自己真正踏进性能测试的门槛。
什么是性能测试
通过一定的手段（工具、代码等在并发情况下获取系统的各项性能指标，验证被测系统在高并发下的处理能力、稳定性等是否可以满足我们对系统的预期。
什么样的系统才需要做性能测试
毕竟我也没真做过，在网上搜集了一下，总结如下：
-
用户量大，日活很高的系统
-
系统核心模块/核心接口
-
业务逻辑复杂的模块
-
新的技术选型
-
电商类项目促销和活动
-
性能容量评估及规划
-
日常性能回归
性能测试重要指标TPS
「什么是TPS？」
❝其实就是每秒服务器能处理的事务数。自然是单位时间内处理的越多越好。
❞
「那事务又是什么呢？（曾经一次面试就被问过，当时一脸懵逼）」
❝事务可以是一个业务操作，也可以是多个业务操作的集合，这取决于你想怎么定义。
❞
❝这里举一个曾经在组里说过的例子，就用吃饭来说吧。吃饭这个动作可以是一个事务。从办公室走出去，再到食堂、打饭、坐下、拿筷子、吃饭，这一连串的动作也可以认为是一个事务。每一个动作都可以当成是系统的一个接口，组合在一起就是一个大的事务。
❞
时间
性能测试中时间肯定就是金钱啊，这个时候就需要你越快越好了。这里常用的指标有响应时间、平均响应时间和top时间。在解释这些时间前，我们先看一下系统的流程是什么样的。
「响应时间」就是 网络传输的时间 + 各个环节业务处理时间
「平均响应时间」 就是整个过程中所有请求消耗时间的平均值
「top时间」分为90% 95% 99%，这些可以在聚合报告中看到。
那这三个时间就是响应时间*90%吗？并不是的。实际的意义是90%的请求耗时都低于的一个时间，一般用的最多的就是95%。
「为什么不采用平均时间，而要再弄个95%响应时间呢？」
因为平均响应时间在性能测试中并不完全可靠，如果有10个请求，最快的一个耗时100ms，最慢的一个耗时500ms，其他8个都在300ms左右，那么平均响应时间为300ms左右，你会觉得有什么大问题吗？如果只看平均响应时间，这个500ms耗时的接口你就会无法关注到，也就错失了性能测试发现的问题。
其他的一些指标
并发数：简单理解就是工具中设置的线程或者进程数量。
PV：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。可以统计服务一天的访问日志得到。
UV: 独立访客，也可以称之为日活，统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到。
成功率及失败率：就是整个测试过程中接口请求成功的数量/失败的数量 除以 总请求数
「吞吐量」：吞吐量是指系统在单位时间内处理请求的数量，TPS是吞吐量的常用量化指标。TPS越高，吞吐量越大。
对于并发数、TPS、响应时间的关系，我决定自绘一幅灵魂画作。
「由图可以得知」：在系统到达瓶颈前，并发数和TPS是成正比关系，吞吐量也随着TPS的增大，越来越大。
TPS = 并发数 / 响应时间(s) 「该公式在任何情况都可以计算TPS，面试可能会问」
看完这个是不是还是不明白，不明白就对了。
举个例子来说吧。假设要测试的是一个工厂，原本有10个工人，现在我们增加产线工人（也就是并发数），刚开始一段时间，每条生产线的产量都是越来越高。但是当工人达到一定数量时（瓶颈），一条产线就能挤得下那么多人，给你10000个人也只能在那排队等干货，所以产量不会再继续增大了。图上的这个曲线拐点就是我们想要寻找的结果。
TPS（工厂的每秒生产数量） = 并发数(工人数) / 响应时间(工人生产一件商品的时间)
这样看起来是不是就好理解多了。TPS和响应时间是反比的关系，工人数不变，工人生产的效率高了，时间短了，TPS就越高。
总结
其实上面这些百度都能找到，但是性能这些概念太多太杂，真的要好好过滤一下才行。下一篇水一下性能测试的流程吧。
绵薄之力【资源分享】
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】
这些资料，对于想进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助……基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等配套学习资源免费分享~
