一.测试说明
测试的目的在于知道机器最大可以抗压多少流量，并找出薄弱环节进行优化。
在测试后要进行容量规划，目的在于让每一个业务系统能够清晰地知道：什么时候应该加机器、什么时候应该减机器。当节日时候业务增长，准确的预估将节省很多资金，并让业务不会被流量击倒。
容量规划分为几个阶段：
- 业务流量预估阶段：通过历史数据分析未来某一个时间点业务的访问量会有多大；
- 系统容量评估阶段：初步计算每一个系统需要分配多少机器；
- 容量的精调阶段：通过全链路压测来模拟大促时刻的用户行为，在验证站点能力的同时对整个站点的容量水位进行精细调整；
- 流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务。
二.测试分类
单链路： 对单台机器进行测试，通过ab等测试工具进行单台机器的不同页面并发量测试。观察web服务器的压力和负载情况
如何测试单台机器：
- 模拟请求：通过对生产环境的一台机器发起模拟请求调用来达到压力测试的目的，模拟请求和真实业务请求之间存在的差异，会对压力测试的结构造成影响。同时模拟进行购买等操作，会对数据库造成污染，毕竟是虚假数据。
- 复制请求：通过将一台机器的请求复制多份发送到指定的压测机器，这样准确性更高，但同样面临数据污染的问题。
- 请求转发：将分布式环境中多台机器的请求转发到一台机器上，也可以调节负载均衡的权重，让测试机器承担更多压力，这样因为都是正常请求不会对数据库进行污染。
全链路： 基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，比如购物平台是nginx反向代理，后端为java程序，在测试中，模拟用户登录账号，选购商品，加入购物车，付费。这样对整个链路进行测试，在观察中，要对每个环节都进行观察，找出薄弱和反应慢的节点。
为何要进行全链路测试？因为单台测试再好，在一个业务的链路上，有一个下游系统出现了问题，响应时间变得很长。这个问题在链路上会被放大，甚至导致整个链路不可用。所以也要进行流控，当一个应用响应的时间超过阈值，我们可以认为这个应用不可控，应该迅速将它降级。
如何测试全链路： 全完模拟用户对网站或者app发起请求，登陆–选购–购买。对于模拟请求的方式，需要考虑脏数据的处理方式。全链路压测的所有数据都在生产环境做了数据隔离，包含存储、缓存、消息、日志等一系列的状态数据。在压测请求上会打上特殊的标记，这个标记会随着请求的依赖调用一直传递下去，任何需要对外写数据的地方都会根据这个标记的判断写到隔离的区域。
三.压力测试指标
- TPS：每秒钟完成的web请求响应数量
- 并发数：时间段内，系统同时处理的web请求响应数量
- 响应时间：所有web请求处理完毕的时间
- 页面状态：返回状态码是否都是正常200
- 数据传输量：每秒从服务器获取多少数据
四.压力测试技巧
- 压力测试工作应该放到产品上线之前，而不是上线以后；
- 测试时并发应当由小逐渐加大，比如并发100时观察一下网站负载是多少、打开页面是否流畅，并发200时又是多少、网站打开缓慢时并发是多少、网站打不开时并发又是多少；
- 更详细的进行某个页面测试，如电商网站可以着重测试购物车、推广页面等，因为这些页面占整个网站访问量比重较大。
- 确定下web应用的协议，如果只是web服务器的话一般用http或者https协议，如果有APP客户端的话还要确定下其采用的协议。
- 采用压测工具启动机器人对服务器进行施压，观察一些重点指标（TPS，响应时间，带宽流量，CPU，内存，DB）等。
- 如果硬件性能都还OK的话，可以逐步增加压力。如果测试过程中发下某个或者多个指标飙升（CPU达到90%以上，内存占用很高等），可能触及瓶颈了。
- 对于一些IO较大的请求也要观察下带宽的占用情况（可能逻辑服务器毫无压力，但是带宽已经早就满了）。对于压测过程也需要时刻关注db的性能，慢查询是否变多。
- 在测试后需要对整体进行分析，查看哪个页面或者业务访问量最大，还有数据库负载慢查询等等。
