第一次做性能测试

        第一次接触性能测试的时候，真的是一脸懵。当时测试经理和我讲说，你们到时候要去xx科技出差，去到那边后要在客户环境上做下压力测试，你先去SVN上把压力工具和一些脚本下下来，然后再来找我，再把这个性能测试的文档按照实际效果改改…
        工作就是这样，总会驱使你去做你不会的东西，但是当时的心态很着急，因为不知道啥是压力测试，也不会压测工具，有种临危受命的感觉。默默安装好压测工具后，测试经理又说，你去远程环境上直接操作算了，上面的环境我已经搭建的差不多了，一个中间件，两个服务器，你把这些脚本都改改，搞100条数据，然后跑两种场景，一个用户和100个用户，看看结果，分析分析…
        每每听到这种不清不楚的要求，我就非常的炸毛，其实现在想想，这不是一个正确的对待工作和处理事情的心态。首先，在工作上能够接触自己不会的东西，那这就是一个学习和提升的机会；其次，如果对待工作的态度是愤懑，不爽的话，不仅影响自己的生活状态，而且还会原地踏步，最终能力退化。
        不过以上只是闲聊，每个人都有自己的想法，或者说，每个人都有自己的路，是想成长还是想就这样随波逐流都靠自己的行动。
—————————————————————分割线—————————————————————
————————————下面的话，就是简单理清一下当时做的事情——————————————
        当时的具体测试目的，虽然没有直接说，但是从那个性能测试的文档中来看，就是，1个用户一次发送100个请求，并设置100个用户同时并发，TPS要超过300才行。
        测试环境：当时也是准备好了的。
        测试场景：的话就是基于交易的业务，来模拟下指令和委托业务。
也就是说，我当时做的就是狭义的性能测试，这种是指对系统性能有了解的前提下，明确需求目标，然后在确定的环境下进行的测试，然后输出一个测试报告给客户。

那广义的性能测试还有哪些呢：

负载测试

通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或某种资源已经达到饱和的状态
特点：

1. 这种性能测试方法的主要目的是找到系统处理能力的极限
2. 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景
3. 这种性能测试方法一般用来了解系统的性能容量，或者是配合性能调优来使用

压力测试（强度测试）

系统在一定的饱和状态下，例如CPU、内存使用饱和的情况下，系统能够处理请求的能力，以及系统是否会出现错误。
特点：

1. 这种性能测试方法的主要目的是找到系统处于压力下的性能表现
2. 这种性能测试方法一般通过模拟负载等方法，持续加压，是系统资源达到较高水平
3. 这种性能测试方法一般用来测试系统的稳定性

并发测试

并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其他性能问题。
特点：

1. 这种性能测试方法的主要目的是找到系统可能隐藏的并发访问时的问题，例如系统内存泄露、线程锁、资源争用方面的问题。
2. 这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持

配置测试

通过对系统的软\硬件环境的调整，了解对系统性能的影响程度，从而找到系统各项资源的最优分配原则
特点：

1. 这种性能测试方法的主要目的是了解不同因素对系统性能的影响程度，从而判断出最值得进行的调优操作
2. 这种性能测试方法是在对系统性能有了初步了解之后进行的
3. 这种性能测试方法一般用于性能调优和规划能力

可靠性测试

给系统一定业务压力的情况下，是系统运行一段时间，检测系统是否稳定
特点：

1. 这种性能测试方法的主要目的是验证是否支持长期稳定的运行
2. 这种性能测试方法需要在压力下持续一段时间运行，甚至是几天
3. 这种性能测试过程中需要关注系统的运行状况

总结一遍后，感觉自己做的性能测试并不是单纯的某一类，好像都有涉及到一点点，比如我第二次做性能测试的时候，还要根据测试过程中服务器的表现，CPU和内存的使用率来调整中间件的参数和服务器需要的一下参数配置。所以真正做性能测试的时候，肯定也不会只局限于某一个方向上。