性能测试的基本概念：
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
性能测试一般分为应用在客户端性能的测试、应用在网络上性能的测试以及应用在服务器性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
性能测试一般包含有基准测试、负载测试、压力测试、并发测试和稳定性测试。
性能测试的准备：
性能测试第一步要做的就是确定测试目标：
一般来说，做性能测试确定的目标的时候会普遍的碰到在线用户数、每天有多少ip访问等一些类似的答案。实际上这种答案没有一点参考价值，因为我们不明白，这些在线用户在干什么，在访问和使用哪些功能吗还是纯粹的待在系统上什么都没有做；每天这么多ip访问具体是在哪些时间段集中的来访问了还是只是在一天24小时内平均分布开来访问的。所以说我要确定的测试目标是通过和运维沟通查看生产日志或者和业务部市场部沟通确认，哪些功能会用的比较多，系统的一个最高同时在线用户是多少，在哪些时刻，系统会对哪些事务有多少的同时使用量。还有两个要关注的地方就在数据库读写方面和缓存的使用方面。根据这个去设计测试场景的不同业务比例，和他们的目标都是什么。
而一般来说，性能测试的目标从两个方面来考虑，一个是Transaction processing systems（每秒处理多少事务），一个是response time（响应时间），还有一个就是性能测试的TPS的曲线图。
对于做性能测试最好是通过分布式进行测试，就是有一台主机，然后所有从机一起跑场景，防止压力机压力太大(一个CPU最高并发线程数或者进程数有限制)影响测试结果，如果主机虚拟用户不够，那么久多用几台压力机，然后分析access.log日志。
性能测试第二步就是测试环境的搭建：
一般来讲，一个大型的互联网系统服务器分布应该是分四层：
1、 负载均衡服务器（一般一台或多台）；
2、 应用服务器；
3、 缓存层；
4、 数据服务器层。
要注意的是包括数据库，中间件，内核等设置和线上保持一致。
按照线上的每层服务器的分布然后同比例缩减来搭建测试环境，最好能保证除了负载均衡服务器以外其他的服务器层都要有两台以上，如果实在不能满足的话就要在一台服务器上尽可能的模拟真实的线上的比例然后多建立几个实例。在你的测试环境中，要保证客户端和服务器都是在同一个百m或者千m网络的网段内，这样可以让系统最大化的排除网络引起的问题。
我们这样搭建测试环境的目的就是让测试环境尽可能的接近线上环境。
性能测试第三步要做的就是测试数据的创造：
数据的创造一般来说有三种方法：
1、 通过了解数据库表结构和数据库的表之间的业务关系然后写存储过程（缺点是业务结构复杂的话容易写入错误数据，优点是执行简单并且效率快）；
2、 通过写程序调用接口的方法插入数据好处（缺点是有些数据的生成没有通过机构，优点是数据生成的效率相对来说比较快）；
3、 基于ui层面通过性能测试工具模拟业务场景来进行造数据（缺点是速率相对来说比较慢，优点是数据生成的正确率比较高）。
但是我需要创造多少的数据呢？这个可以从下面几个方面去获取：
1、 和业务部市场部进行沟通，确认咱们的一个预期的目标可能会有多少数据量；
2、 通过看同行同类型的系统现在存在有多少数据；
3、 通过生产环境上数据的数据增长率，然后预估一下一年后会有多少的数据量。
性能测试第四步要做的就是准备性能测试脚本：
在准备测试脚本的过程中最重要的就是选择性能测试工具：
1、 apache bench：apache自带的一个工具，主要是用来比较性能优化前后的系统性能。但是不能访问多个url，不能参数化。
2、 Siege：和bench比起来的优点就是可以访问多个url。
3、 Httpload：
4、 Jemeter：缺点就是用起来比较麻烦，测试结果不是很准确，优点就是基本上的性能测试所需要的功能大致都能满足并且是开源性的。
5、 Loadrunner：优点就是用起来比较方便，测试结果比较准确，支持的协议比较多；缺点就是成本高。
脚本的准备：
根据测试方案制定的内容来把需要的场景所对应的脚本进行编写或者录制，然后对需要的参数进行参数化和根据测试要求加检查点和集合点。
对于性能测试工具是怎么样来模拟虚拟用户对服务器造成压力的，主要它是在应用层模拟请求对服务器造成压力。
对于脚本的修改方面需要用到参数化、检查点、关联、集合点等函数，参考我的LR使用总结。
为什么要加断言，要明白这个原因（服务器返回200不一定代表是你想要的结果）举个例子，你使用正确的用户名密码登录，服务给的响应是登录失败，实际服务是响应成功的。