百度搜索：小强测试品牌

新书推荐

本书终于在前段时间出版了，现在已经可以在各大 店购买了，搜索书名即可。书籍购买地址：https://detail.tmall.com/item.htm=547310727717

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

引子

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

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

性能测试到底是什么

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

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

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

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

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

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

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

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

性能测试分层模型

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

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

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

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

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

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

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