性能需求评估
系统特殊要求：从实时性角度来分析，某些系统对响应时间要求比较，比如餐饮系统，系统的快慢直接影响客户的感受，这种情况就有作并发测试的必要，在大并发量的场景下，查看这个功能的响应时间
性能需求分析方法
1.确定性能测试点
关键业务：确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如结算，扣款等接口
确定性能测试点
日请求量：确定被测项目各功能点的日请求量(可以统计不同时间粒度下的请求量如：小时，日，周，月)。如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试，而且关键业务点，可以被确定为性能点
逻辑复杂度：判定被测项目各功能点的逻辑复杂度。如果一个主要业务的日请求量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式方式的调用中，当某一个环节响应较慢，就会影响到其他环节，造成雪崩效应
运营推广活动：根据运营的推广计划来判定待测系统未来的压力。未雨绸缪，防患于未然，降低运营风险是性能测试的主要目标
被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用
性能测试准备
1，测试环境准备
系统运行环境：测试环境，有些时候需求比较多，做性能测试担心把环境搞垮了影响其他的功能测试，可能需要重新搭建一套专门用来做性能测试的环境
执行机环境：这个就是用来生成负载的执行机，有时候甚至需要一套执行机集群
2，测试场景设计
根据性能需求来分析来设计符合用户使用习惯的场景，场景设计的好不好直接影响到性能测试的结果
3，性能工具准备
负载工具：根据需求分析和系统特点选择合适的负载工具，比如LR，Jmeter等
监控工具：准备性能测试时的服务器资源，JVM，数据库监控工具，以便进行后续的性能测试分析与调优
4，测试脚本准备
如果性能测试工具不能满足被测系统的要求或只能满足部分需求时，需要我们自己开发脚本配合工具进行性能测试
5，测试数据准备
负载测试数据：并发测试时需要多少数据？
DB数据量大小：为了尽量符合生产场景，需要模拟线上大量数据情况，那么要往数据库里提前插入一定的数据量。这可能需要花费一些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表
性能测试执行
1，人工边执行边分析
通常我们做性能测试都是人工执行并随时观察系统运行的情况，资源的使用率等指标。这个过程可能会很漫长，需要不断的调整系统配置或程序代码来定位问题
2，无人值守执行性能测试
无人值守是最理想化的目标
无人值守不是说没有人力介入，而是把人为的分析和执行过程分离，执行过程只是机器服从指令的运行而已
通常测试环境在白天比较繁忙，出现性能问题及定位难度较大且会影响功能测试
所以一般性能测试最好在晚上或周末进行，在相对较安静的条件有利于测试结果的稳定性
性能测试报告与总结
性能测试报告是性能测试的里程碑，通过报告能展示出性能测试的最终成果，展示系统性能是否符合需求，是否有性能隐患
性能测试报告中需要阐明性能测试目标，性能测试环境，性能测试数据构造规则，性能测试策略，性能测试结果，性能测试调优说明，性能测试过程中遇到的问题和解决办法等
性能测试工程师完成该次性能测试后，需要将测试结果进行备案，并作为下次性能测试的基线标准，具体包括性能测试结果数据，性能测试瓶颈和调优方案等。
同时需要将测试过程中遇到的问题，包括代码瓶颈，配置项问题，数据问题和沟通问题，以及解决办法或解决方案，进行知识沉淀