深度剖析性能测试（部分摘抄）
性能测试到底是什么
这个简单的问题很多朋友都无法完整的回答。可能知道的朋友会说性能测试就是用LoadRunner或者Jmeter工具来压测系统，也有人会说性能测试就是同时让很多人访问系统看系统能否扛得住。这些回答只能说对，但不够全面也不够深刻，只是把表象描述了一下而已。其实真正的性能测试无法用一两句话来简单概括，因为它涉及的东西太多。
大部分人一说到性能测试理解的就是压测服务器，看服务器能不能扛得住，但这只是其中一方面而已，其实性能测试可以分为多个层级，每个层级的关注点以及测试方法等都不太一样，我们通常认为的是服务器端的性能测试。
那性能测试到底应该怎么去理解呢？我们不妨换个角度来看看，不论是大家理解的通过工具来压测系统还是号召100个人同时去访问系统，都不过是实现的手段或者方法而已，我们更应该关注性能测试的目的是什么，因为目的不一样那么实现的手段或者方法就有可能不一样。所以我们倒着来看看性能测试，不外乎就是这么几个目的：
- 压测系统，看系统的前端以及后端性能是否满足预期（基准测试）；
- 压测系统，看系统可以承受的最佳压力和最大压力，来判断系统的承受极限（压力测试）
- 压测系统，看系统在长时间运行下是否可以正常处理请求（稳定性测试）
- 容量规划，当系统越来越稳定的时候，我们要提前考虑它的远景规划，或者更通俗的解释就是“人无远虑，必有近忧”，这里的“远虑”就是容量规划。
这样看来我们应该就能明白性能测试其实更多的是一个过程的统称，并不是一个具体的定义。
性能测试分层模型
性能测试分层模型是为了让大家更容易理解和学习性能测试而总结的，即使对于有一些经验的朋友，这个分层模型也会对你在认知上有所帮助。该分层模型并不高大上，也有可能不够完善，只是对杂乱的知识做了总结提炼，但对于小白朋友来说是非常好的良药，可以帮助大家快速、全面地理解性能测试。
性能测试分层模型中含义
前端层
前端层主要是指用户看到的页面。比如，电商网站的首页、移动APP的各个页面，这些才是用户最关心的。对于用户而言，一个系统的快慢只会通过页面的呈现速度来判断，并不会在意你后端处理的速度，所以我经常说即使你后端优化得很牛逼，但前端页面性能却非常差，那也是无用功。 另外，APP的测试也是大家经常问到的问题，APP的性能测试至少包括两个方面：APP的前端，也是现在业界里常说的APP专项测试；APP的后端，本质上和Web端性能测试一样。所以，在提问之前一定要明白这些概念，别人才能有针对地回答你。
网络层
任何系统都可以粗略地分成客户端、网络端和服务端，其中网络端是连接前后端的命脉，网络质量的好坏也有很大的影响。在性能测试中可能遇到的情况大致分为两种，一种是测试不同网络状况下的大流量的表现（一般接触的比较少），另一种则是压力机和服务器最好在同一网段，不然压力无法完整的到达后端，会在网络层拖垮，这样就没法较为准确地评测服务器端的性能情况了。如果你测试的是移动端APP，那么你可能还要考虑在不同网络状态下的测试。
后端层
这里分三种情况，也是绝大多数企业中应用的方向，不论是Web端还是移动APP端，在后端层性能测试的方法都是类似的。
业务级
通俗点解释就是从页面录制你的场景脚本。比如，现在有一个电商网站，要通过页面录制脚本完成登录、浏览单品页、下单的流程。这个层级我想大家是最熟悉的，因为jmeter这个工具就是用来完成这样的流程的，也是大部分小白同学必学的。
这种性能测试方式有个致命的缺点就是依赖于页面，如果页面没有开发完毕测试就无法提前进行，而现实中测试时间往往被一味压缩，因此我们有时候也很无奈，所以如何把测试的切入点尽可能的提前就显得比较重要了。而接口级恰恰就解决了这个问题。
接口级
这个层级是大部分公司做性能测试的首选，也是最有效率的方式之一。比如，现在有一个登录接口，你只需要知道入参、出参以及规则等即可编写测试接口的代码，不需要等待页面的开发，大大提前了测试的切入点，但它要求测试工程师有一定的编码能力。除此之外，接口级测试的扩展性强，可以通过完成接口的性能测试和功能自动化测试框架来提升效率，性价比较高。
单元级
这个层级恰恰和接口级相反，很多公司想做，但有心无力。单元级大家理解为类似“单元测试”即可，比如，有一个PHP代码块，我们可能需要测试一下核心算法函数的性能，可以通过插桩或引入单元测试框架来完成，从而获得它的执行时间、CPU消耗以及内存占用率等信息来优化代码性能。
那为什么很多公司做不起来单元级的测试？可能有以下几个原因
- 业务变化太快，涉及的代码逻辑修改也比较大，这样做单元级测试就得不偿失了。
- 开发朋友们确实没有太多的时间写单元测试代码，毕竟业务逻辑代码写起来也很费时，没有太多时间搞其他了。
- 测试工程师编码能力相对来说较弱，能独当一面完成单元测试的人少之又少，在加上时间紧迫就更无法做单元级的测试。