性能测试分层模型

以下内容选自《小强软件测试疯狂讲义》一书

这里我特别提前说一句：任何东西都有一定的受众群体，世界上也没有任何东西可以让所有人100%满意。So，本书也是。只要本书中有一个篇章的内容给你带来了影响那就是这本书的价值！感谢大家的支持。

引子

我为什么会把这个话题放到最开始呢？就是因为这些年在企业工作中、在教育领域培训中接触过不少朋友，在这个过程中我发现居然有95%以上的朋友不明白什么是性能测试，什么是自动化测试，这都不要紧，但更可怕的是还对这些概念有巨大的误解，从而导致学习的时候走了很多弯路，看的我也是万般无奈，所以我们就先来好好聊聊性能测试和自动化测试到底是什么，希望能帮助大家更加全面、深刻的理解它们。千万不要小瞧这些，如果你的认知都是错的，你怎么可能学的对呢？

另外，我也必须在开篇中指出一点：所有人的学习都需要一个过程，也许你身边有同事已经经历了A阶段到达了B阶段，他或许会从技术层面鄙视你或者批判你，但是你不要气馁，谁都不是从娘胎里出来就会说话、就会跑步的，都需要经历这个特别“低级”的阶段，这是必然。我们会一直坚持正能量带领“新人”成长，帮助你完成阶段性的蜕变。

性能测试到底是什么

这个看似简单的问题我相信很多朋友都无法全面地回答上来。可能知道的朋友会说性能测试就是用LoadRunner或者Jmeter工具搞个并发来压测系统，也可能会说性能测试就是同时让很多人访问系统看系统能否扛得住。这些回答我只能说对，但不够全面，也不够深刻，只是把表象描述了一下而已。其实真正的性能测试无法用一两句话来简单概括，因为它涉及的东西太多了。

大部分小白朋友一说性能测试理解的就是压测服务器，看服务器能不能扛得住，但这只是其中一方面而已，其实性能测试可以分为多个层级，每个层级的关注点以及测试方法等都不太一样，我们常认为的是服务器端侧的性能测试。至于性能测试的分层我们会在后面的章节中给大家讲解。

那性能测试到底应该怎么去理解呢？我们不妨换个角度来看看，不论是大家理解的通过工具来压测系统还是号召100个人同时去访问系统，都不过是实现的手段或者方法而已，我们更应该关注性能测试的目的是什么，因为目的不一样那么实现的手段或者方法就有可能不一样。所以我们倒着来看看性能测试，不外乎就是这么几个目的：

1) 压测系统看系统的前端以及后端是否满足预期（类似功能测试用例中的预期结果和实际结果的概念）；

2) 压测系统看系统可以承受的最佳压力和最大压力，来判断系统的承受极限；

3) 压测系统看系统在长时间运行下是否可以正常处理请求（类似疲劳测试）

4) 容量规划，当系统越来越稳定的时候，我们要提前考虑它的远景规划，或者更通俗的解释就是“人无远虑，必有近忧”，这里的“远虑”就是容量规划。

这样看来我们应该就能明白性能测试其实更多的是一个过程的统称，并不是一个具体的定义，同时在学习性能测试的时候要暂时抛开功能测试的思想，否则很容易掉进陷阱，这也是大部分小白朋友最容易犯的错误。

性能测试分层模型

性能测试分层模型是为了让大家更容易理解和学习性能测试而总结出来的，即使对于有一些经验的朋友，我觉得这个分层模型也会对你在认知上有所帮助的。该分层模型并不高大上，也有可能不够完善，只是对杂乱的知识做了总结提炼，但对于小白朋友来说是非常好的良药，可以帮助大家快速、全面地理解性能测试。分层模型如图1.1所示。

下面我们就来看看这个性能测试分层模型中每层所代表的含义。

前端层

前端层主要是指用户看到的页面。比如，电商网站的首页、移动APP的各个页面，这些是用户最关心的。对于用户而言，你一个系统的快慢他们只会通过页面的展现速度来判断，并不会在意你后端处理的速度，所以我经常说即使你后端优化得很牛逼，但前端页面性能却非常差，那也是无用功。

以前这个层级是很多企业和测试工程师并不关注的，但近几年对于前端性能的要求也越来越高，也是大家应该了解的知识。本书将在后面的章节中详细讲解前端性能方面的知识和实践经验。

另外，APP的测试也是大家经常问到的问题，我有时候特别无奈，大家张口就问：“APP性能测试怎么做啊？”，这样的问题真的没法回答。APP的性能测试至少包括两个方面：APP的前端，也是现在业界里常说的APP专项测试；APP的后端，本质上和Web

侧性能测试一样。所以，在问之前一定要明白这些知识别人才能有针对地回答你。

网络层

任何系统都可以粗略地分成客户端、网络和服务器端，其中网络是连接前后端的命脉，网络质量的好坏也有很大的影响。在性能测试中可能遇到的情况大致分为两种，一种是测试不同网络状况下的大流量的表现（一般接触的比较少），另一种则是压力机和服务器最好在同一网段，不然压力无法完整的到达后端，会在网络层拖垮，这样就没法较为准确地评测服务器端的性能情况了。如果你测试的是移动端APP，那么你可能还要考虑在不同网络状态下的测试。对于网络层的性能测试我接触的非常少，为了不误人子弟这里就不班门弄斧了。大家的重点是了解这个分层模型，对于理解性能测试很重要。

后端层

这里我分成了三种情况，也是绝大多数企业中应用的方向，是大家必须了解和掌握的。同时大家也要明白，不论是Web端还是移动APP端，在后端层性能测试的方法都是类似的。

第一，业务级：通俗点解释就是从页面录制你的场景脚本。比如，现在有一个小强电商网站，你要通过页面录制脚本完成登录、浏览单品页、下单的流程。这个层级我想大家是最熟悉的，因为LoadRunner这个工具就是用来完成这样的流程的，也是大部分小白同学必学的。至于怎么去完成我们在后面的章节中会详细讲解到。

这种性能测试方式有个致命的缺点就是依赖于页面，如果页面没有开发完毕测试就无法提前进行，而现实中测试时间往往被一味压缩，因此我们有时候也很无奈，所以如何把测试的切入点尽可能的提前就显得比较重要了。而接口级恰恰就解决了这个问题。

第二，接口级：这个层级是大部分公司做性能测试的首选，也是最有效率的方式之一。比如，现在有一个登录接口，你只需要知道入参、出参以及规则等即可编写测试接口的代码，不需要等待页面的开发，大大提前了测试的切入点，但它要求测试工程师有一定的编码能力。除此之外，接口级测试的扩展性强，可以通过完成接口的性能测试和功能自动化测试框架来提升效率，性价比较高。具体如何去完成将在后面的章节中详细讲解。

第三，单元级：这个层级恰恰和接口级相反，很多公司想做，但有心无力。单元级大家理解为类似“单元测试”即可，比如，有一个PHP代码块，我们可能需要测试一下核心算法函数的性能，可以通过插桩或引入单元测试框架来完成，从而获得它的执行时间、CPU消耗以及内存占用率等信息来优化代码性能，如图1.2所示。

那为什么很多公司做不起来单元级的测试呢？可能有几个原因：

1) 业务变化太快，涉及的代码逻辑修改也比较大，这样做单元级测试就得不偿失了。

2) 开发朋友们确实没有太多的时间写单元测试代码，毕竟业务逻辑代码写起来也很费时，没有太多时间搞其他了。

3) 测试工程师编码能力相对来说较弱，能独当一面完成单元测试的人少之又少，在加上时间紧迫就更无法做单元级的测试了。

我们聊完这些分层后，也许有的朋友会感觉其中有些技术很厉害，感觉很高大上。可是我个人觉得不是你用多么厉害的技术就牛逼，只有用合适的技术带来较高的性价比才是王道，有句话说的好：“最好的不一定是合适的，只有合适的才能发挥最好的效果”。

看完这些不知道大家是不是对性能测试有了不一样的了解。当然，这个模型不见得是最好的，只是根据经验总结而来，也有很大的改进空间，我希望的是能和大家一起交流来完善，并不希望来争论对与错，世间本身没有绝对的对与错，只有更多的交流你才能吸收更多的知识来武装提升自己，俗话说的好：“你一个想法，我一个想法，我们交流一下就彼此拥有了两个想法”，何乐而不为呢。