很早就想写写近几年的性能测试总结，最近终于可以开动了！
很多书和文章把性能测试写的复杂，分为性能测试、压力测试、负载测试、并发测试、可靠性测试……
其实与功能测试是一样的，需要考虑需求、运行条件、执行步骤（脚本）、工具、结果分析
首先要从需求开始了解，目前接触到的性能测试需求有以下4类
1）明确指标：要求系统满足100个用户同时登陆使用，平均每个用户操作（登录、访问首页）响应不超过5秒（只要结果，不关心达不到指标的解决方案）——指标明确，但往往提不出这么明确的需求
2）想知道目前系统性能（摸底测试）：摸底获得系统的可以承受的最大用户数——当没有明确性能需求时
3）找出系统瓶颈：系统根据性能测试结果分析造成瓶颈的逻辑业务、接口、函数，进行调优——需要寻找到合适的场景，制定测试方案，多次执行
4）压力测试（稳定性测试）：需要测试较长时间，系统长时间处于压力环境下，系统的稳定性情况——一般是第三类调优结束后
在性能测试需求中常遇到的是并发数和TPS、响应时间
TPS：每秒事务数
响应时间：从发送请求到接收到回复的时间，一般不包含网络传输+界面渲染时间
并发数：满足某个条件（服务器没有崩溃）,可以同时使用的用户数是最大并发数，与最佳并发数比较容易混淆（很多系统都是需要测试最佳并发数），这两个并发数导致测试的结束条件不一样，所以一定要在明确需求时确认清楚。
举个例子：我们的12306网站在建设初期，当遇到春运抢票期间，如果同时在线人数达到一定数量，服务器就崩溃，大家都没法使用，这就是达到了最大用户数；后来优化后再抢票，当同时抢票的人数到了一定数量（最佳用户数），仅保障在线的用户抢票，除非有人掉线，再想登录的人让你再等等，这样服务器就不会崩溃了，往往这时我们就需要知道12306的最佳用户数是多少，做到提前防护机制。
最大并发数和最佳并发数有个经典的讲解：理发店模式
总结：性能测试是有前提条件的，根据这些条件来明确测试方案和工具
• 硬件环境：服务器配置（例如：4CPU8G、windows or linux)
• 软件环境：协议。前后端架构，数据库等服务器部署图
• 网络环境：特别时被测系统与测试施压之间的网络带宽，性能测试一般在局域网内进行
•系统的压力点：哪个页面或业务需要进行性能测试（初步明确业务，后续还可能会改）
•测试的指标：并发数、TPS、响应时间（形成一个概念，经过测试执行会逐步明晰）
