基本流程
性能测试方法
判断是否进行性能测试可以从以下几个方面进行思考
a、从业务角度来分析，如果一个项目上去后使用的人数比较多，量比较大，就有做性能测试的必要，反之，如果一个项目上线后，没有几个人在用，无论系统多大，设计如何复杂，并发性的性能测试是没有必要做的，前期可以否决。
b、从系统架构角度来分析，如果一个系统采用的框架是老的系统框架，只是在此框架上增加一些应用，其实是没有必要做性能测试。如果一个系统采用的是一种新的框架，可以考虑做负载测试。
c、从实时性角度来分析，如果一个项目要求某个功能的响应时间，这个有作并发测试的可能性，在大并发量的场景下，查看这个功能的响应时间。
d、从数据库角度分析，很多情况下，性能测试是大数据量的并发访问、修改数据库，而瓶颈在于连接数据库池的数量，而非数据库本身的负载、吞吐能力。这时，可以结合DBA的建议，来决定是否来做性能测试。
如果要进行性能测试，接下来需要确定相应的性能点
主要从以下 4 个维度进行确定：
1. 关键业务。
首要维度，是确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如快捷签约、交易等接口。如果项目（或功能点）不属于关键业务（或关键业务点），则可转入第二、三、四个维度。
2. 日请求量。
第二个维度，是界定被测项目各功能点的日请求量。如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试；而且其关键业务点，可以被确定为性能点。
3. 逻辑复杂度。
第三个维度，是判定被测项目各功能点的逻辑复杂度。如果一个主要业务的日请求量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式方式的调用中，当某一个环节响应较慢，就会影响到其它环节，造成雪崩效应。
4. 运营推广计划。
第四个维度，是根据运营的推广计划来判定待测系统未来的压力。未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用。
例如，运营计划做活动，要求系统每天能支撑多少 PV、多少 UV，或者一个季度后，需要能支撑多大的访问量等等数据。
当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要做性能测试。
5.其它
以上 4 个评估维护，是相辅相成、环环相扣的，它们合成一个维度集。在实际工作中应该具体问题具体分析。例如，当一个功能点不满足以上 4 个维度，但又属于内存高消耗、CPU高消耗时，也可列入性能测试点行列。
确定性能测试指标
如何获得性能需求指标
如何进行性能测试
测试环境
根据实际线上部署架构、服务器配置、用户请求量，一般同比缩小部署性能测试专属环境。
也可制定线上A B性能测试方案。
性能测试工具选型
开源
根据性能测试场景、测试目标特性，选择测试工具，可参考：选择自动化工具是一个关键的决策过程-CSDN博客
自研
自研最大的优点就是可定制化，包括测试入口、测试过程、测试结果收集、指标计算和报告展示。对团队成员要求较高。