一、性能测试脚本研发
1、分析是否需要进行性能测试：
（1）使用频率高业务重要的功能必须进行压测，
（2）复杂的业务逻辑可以不进行压测，
（3）如果某一个接口因为接口间关联等无法进行独立的压测，可以协调开发抽出可以单独执行的接口进行压测，或者设置一个业务场景，设置集合点，压测这个功能
2、独立性能脚本：单点性能测试，一般是写完一个执行一个
3、业务性能脚本：将多个接口联调进行业务场景压测，分析核心功能，设置集合点进行压测
二、性能测试遇到的问题
（1）脚本跑不通，工具可以跑通
- 工具里有隐形的参数或设置：sessionID
- 工具自带的参数设置：fiddler抓包抓取到，分析参数。可能是抓到的参数和脚本参数个数不一致
（2）https协议设置，ajax参数等
原来的接口是http协议，后面为了安全，升级为https协议
- 将安全证书下载到本地，
- 在请求中，加入一个参数【verify=false】。使他的验证为假，跳过验证
- 有ajax技术，脚本会有变化。在header里加入【“X-Requested-With”:“XMLHTTPRequest”】，才能识别ajax页面
（3）脚本和工具都跑不通
开发确认：工具、脚本、需求内容
如果是需求变更，需要完善需求变更的管理流程
（4）业务场景复杂，脚本编写工作量大
如果过于复杂，无需进行脚本设计，或者协调开发，单独抽出可以独立测试的脚本
注意集合点的设置位置
（5）SQL脚本，批量构造复杂的测试数据
三、线上压测：
关键问题一：数据准备
（1）准备数据库
需要做完整数据库备份；新建一个测试数据库，修改相关的配置文件；数据库分布式
（2）准备测试数据
看系统现有功能里是否有导入导出，如果有导出功能，可以将数据直接导出使用
性能测试数据一般只使用正常数据，异常数据不会被提交到服务器造成影响，所以不使用异常数据
（3）测试执行
单点业务脚本：分等级逐步加压，如果提交功能目标人数是3000，可以分别对500,1000，2000,3000,4000,5000，10000进行逐步加压测试，在根据实际用户的使用需求分析加压间隔点是否符合预期要求。
业务场景压测：假如有2000人进行，500人正在查询，500人正在下载，1000人批阅，最后所有人设置集合点一起提交
四、故障分析
1、故障检测：
1、响应时间曲线图：找到最大响应时间、平均响应时间、响应时间趋势
例如，一个响应时间图标，随着用户数的增加，不断变化，经分析得出，最大响应时间是20秒，平均响应时间是15秒，整体趋势波动图很不稳定，又高有低，性能故障在于响应时间过长
但是下图，响应时间最大响应时间为4秒，出现一个偶然的峰值，但是大多数平均响应时间为2秒，较为平稳，性能响应时间满足预期标准
2、定位故障：
分析点CPU、内存、I/O、吞吐量
以上几个指标，如果是以下的情况
CPU比较空闲，占用率低在==20%==左右，没有太大的压力
内存比较慢，在80%~90%之间
I/O（输入输出）比较频繁
吞吐量也比较空闲，占用量不大
分析一下，内存比较慢，但是CPU没有做处理，IO处理比较频繁，考虑是数据库问题，是因为要加载数据库的数据。
吞吐量小，说明没有网络的输出，数据库本身在服务器上，不需要通过网络；IO处理比较频繁，所以是数据库问题，数据库访问出现问题，可能是数据量过大，没有及时提交给CPU进行处理，
3、数据库处理问题解决
（1）看数据库连接的等待，数据库连接等待的参数个数有多少，如果大量的数据库都在进行连接等待，可以适当增加连接池，或者增加数据库缓存。来减少等待时间
（2）如果数据库连接没有等待，IO又在频繁的输入输出，说明需要先把数据全部读取进来，然后呢才进行SQL语句的处理和提交。这时候考虑数据库的设计及数据库命令。
例子：
有一种情况，数据量特别大，提交试卷时，有10万张试卷，关联了5张表ABCDE（查询的时候需要用到笛卡尔积查询，数量计算为10万ABCD），造成数据量很大。
影响：
请求响应时间很慢20秒以上
原因：
数据关联太多，造成数据激增，导致响应时间很慢
解决方法：
- 可以通过过表合并的方式，解决这个问题。
- 合并表后，如果响应时间还是没有达到预期结果，这时候就需要分析表结构（例如增加索引）
- 先排序，再查询（先order by 再select）
==表结构中索引的介绍==
表结构里很重要的一个原因就是索引，一般查询哪个字段的频率高，就把索引加载哪个字段上。
索引可以提交查询效率，但是一个表的索引不能超过三个，多了并不会提高查询效率。
==如果加了索引，还存在一个问题，就是命中率不高：==
例如一个表里有10个字段，一般会在ID上建立索引，但是我们查询的时候，往往很少按照ID查询，而是按照name查询，name查询的比率比ID大，造成命中率不高。
这时候就需要把索引放到name这个字段上进行，提高了命中率
==索引后遗症：==
如果在一个字段上加了索引，就要保证这个字段被更新的频率低，索引的建立需要一定的时间，索引建立后，如果关键字更新，索引就会重新排序
五、故障分析
1、明确性能测试目标
例如一个性能测试任务：
（1）测试类型：压力测试
（2）测试内容：测试用户登录商城，搜索商品，加入购物车，提交订单。压力测试点为提交订单
（3）用户情况：并发用户量为10000
（4）预期性能：需要的目标响应时间是2-5秒
2、分析测试流程
（1）先分析功能：提交订单功能，是否关联其他不可分割的功能，例如必须先登录
（2）分析测试环境：已有测试环境，或者需要独立部署单独的测试环境，或者必须在生茶环境晚上进行测试（需要做数据库备份）
（3）脚本研发：单点的接口脚本研发，登录脚本、搜索商品、加入购物车、提交订单。
（4）研发好脚本在测试环境下运行做简单的压力测试，然后进行业务脚本联调
分析指标：请求响应时间、资源占用情况、吞吐量（较高时，上传下载网络问题存在）、错误率
六、难发觉的性能故障：内存泄漏
1、内存泄漏定义：
系统里申请了一个大的数组，占用着内存，没有释放。占用的多了，其他的资源就没有内存可以使用。
正常赢点是用完内存就释放掉，供其他地方使用
2、检测方式
内存泄漏较少时，比较不容易发现，快速检测内存泄漏的方式【负载测试】
3、负载测试，就是不断加压，检测系统的响应时间，查看内存是否泄漏
（1）查看设计文档，重点注意哪个功能有大数据的定义（比如大数组，几千几万的大数组，大文件需要处理，大的列表、链表，二叉树）
（2）查看哪个功能关联多张表，比如四张表以上，进行处理，也会占用很大的内存空间
（3）看是否有公共数据需要长期存储：比如静态数组、静态文件、外部链接的数据或文件。因为它在整个系统运行期间都是存在的
再将这些功能单独取出，进行测试，查看内存曲线，如果是一下情况（一直在向上增长），一定是内存泄漏
性能图示
