最近，在做API的压力测试，趟了不少坑，然后呢，简要记录一下。
压测前需要准备的一些事
拿到API文档不要立马上手，先基准测试，就是执行一次接口测试，至少要压这个接口，要先熟悉一下他的参数，参数的含义，读写哪张表，修改了哪些字段，接口和接口是否有关联（如上课和下课的接口，必须先上课，再下课），还有接口使用的数据能否复用（如获取个人信息的接口及参数，可以获取上万次，但是删除文件的接口，接口实现的功能删除A文件，即使压10000次，他都只删了一个文件）等等。
与开发和产品过一遍接口，最好挨个分析一次。开发提供的接口文档不一定所有的都能进行压，所以先分析，并且可以把上一步发现的问题抛出来，大家一起研究研究，这个接口压不压，怎么压，还有尽可能地让写数据库的同事或者开发同事简单地讲一下接口和涉及到的数据库（如接口的功能是把status由1改为0，如果想复用刚才的参数接着压，需要再把这个的status由0改为1，方便再用）。
压力源服务器、被压服务器、以及数据库的权限提前都准备好。
压力源服务器的账户和密码肯定要有，要不然怎么压，除非在本地执行；
被压服务器，登录看一下CPU、内存、执行日志、安装一些Agent工具等，都是很有必要的；
数据库的权限一定要有，这个和熟悉接口有关系，接口报错的时候也可以排查错误，还有很重要的一点就是造数据。再举个例子，比如要执行一个结束课程的接口，结束后修改了很多的字段，尤其是自动填入日期这种的，在数据库无法直接操作，人为无法干预的，也没有别的接口可以修改（除非让开发专门为了压测再写一个还原状态的接口，跑一次压测），结束课了就是结束了，这节课就作废了，不能复用，这类型的接口，就要提前用别的创建课程、再开始课程的接口去制造大量未结束的课程，或者在数据库直接插入大量的未结束课程的数据，然后在测。
压力执行参数也要准备、压力数据也要准备
压力执行参数，就是这个接口用多少个线程、多大的连接数、持续多久、延迟多久等等。
压力数据要准备，比如压测1000个用户的登录，至少要准备1000个账号和密码吧（当然有缓存的那种接口要这样做，没有缓存的那种，可以视情况，把一个学生登录1000次也可以）。
一些小技能
把压力源和被压服务器的时间设置为一致的，我指的是测试环境的，不是去改线上环境的。
压测的日志、或者产生的文件不要删除，可以做什么呢，分析结果肯定是很重要的、要看QPS这些的。还要更重要的是，可以看CPU或者带宽占用的一些信息。在压的同时在被压服务器的Linux机器上执行top命令是可以看，但是要是看曲线呢，难道边压测，边记录数据，这多费事。（举个例子，我用JMeter压阿里云的Linux机器，可以将产生的jtl文件规范命名，不要随便写，否则后面会麻烦，最好命名包含的越详细越好，接口名、并发量、持续时间、第几次执行，不建议加中文，谁知道会出现什么问题，当压测完后，想知道某一个接口的cpu占用及带宽，在这个日志里看一下开始时间和结束的大概时间，然后登录阿里云的后台，寻找对应的时间点不就一目了然了）。
区分好关联接口的关系，排好顺序，不要逆序走，吃亏的时候就当长一次教训了。
投机取巧的方法，有些操作数据库力度不大的，没有多大影响的，可以把数据库中已有的数据导出来，筛选筛选，过滤过滤，没准还能用，就看运气好不好。
常见需要斟酌的接口类型
单场景的：就执行这一个接口，不与其他接口或者数据有关联；
复合场景的，举个例子，A站在门口，门是关着的，要想进入室内，首先要执行打开门的这个操作，然后才能进入室内，这种是有关联关系的接口；
不操作数据库的，只是服务端程序返回的一个状态，不查询或者操作数据库；
操作数据库，这个真的是涵盖了增删改查，注册1000个用户，这叫增，需要准备好1000个账号和密码，要不然没法压测。删除也是这个道理，要删除1000个用户，首先数据库里要准备好1000个用户可以让你删除。当然也不是没有捷径可以走，要注册1000个用户，可以注册完一个，然后删掉，再注册，涉及到的数据表少还可以，要是注册一个学生，写了很多表，用接口删数据，那就很费事了；
有关联关系的接口要注意，比如，要执行发送消息的接口，但是这个接口的前提是判断是否登录，所在执行发送消息之前，要先执行登录的接口；
修改同一个字段的接口要排好顺序，打个比方（词穷了），就比如向“进门”和“出门”改的是同一个字段，没有进门前status=0，进门了status=1，出门了status=2，只能从0>1>2，不能逆序，从2无法到1，这种情况如果代码逻辑不严谨，先执行了“出门”操作，直接把状态从0转到了2，如果要再执行“进门”操作，又要准备一大堆的数据，像这种有关系的接口，代码逻辑严不严谨先不考虑，先执行从0到1，执行从1到2；
上传文件的接口，这个接口写出来是提醒要注意的，觉得不用压，运气好一点就遇上“墨菲定律”了；
发送验证码、输入验证码、校验验证码，这种我到目前还没辙；
几个数据库关联的那种，一定要慎之又慎，之前遇到一个关联数据库的，压测的账号是别的数据库提供的，这次压测还和那个数据库的产品没有任何关系，那个造数据和使用数据库权限还要走流程，这个时候那就走流程吧，保佑压测不会影响到别的业务，当然也不是没有办法，把以前的数据导出来，研究一下，找到一个能用的，然后把和它特点一样的拿出来用。