1、须通过功能测试

性能测试是基于现状的调优，未通过功能测试情况下，没有参考意义。每一次开始性能测试都应该先进行功能测试。

2、围绕问题做简单建模

了解问题的流程上的大致节点，根据设计文档 (需求文档/开发文档) 或是代码估算每个节点的时间复杂度，在实际测试中，可以以此来参考，发现问题节点。如果遇到问题节点，才去对问题节点做进一步解析。

3、得出测试链路测试

一般而言性能测试都有业务导向，他们都会基于简单的目的，功能在压力下使用依旧流畅或者是可用。如支持10万人同时下单，可能你无法从产品口中得到10w这种准确的指标，但是你可以很容易的得出下单的这个需求，而具体合适的性能指标，可以通过同行经验，或是已有的数据，进行数据分析得出。如果是全新的体系，则需要摸索中得出了 (就好像传统的接口会以响应时间作为指标，如今文本类的大模型，可以将每秒生成多少 token 作为自己的指标一样)

但是你可能会遇到异常业务流程比正常业务流程的耗时更长的问题。如果你没有线上数据 (埋点和记录明细) 支持，我建议你都进行测试，避免意外。如果不是的情况下，完成正常业务流程的测试即可。

在上面的举例中，浏览 -> 详情 -> 选sku -> 浏览的流程，比直接下单的时间复杂度要高。这也和我们的实操很相符，花时间去选购商品，或者对常购商品的直接购买。于是在上面的估算中得出了两条链路。

4、进行梯度压力测试

不同的压力对应不同的能力，在实测中记录表现。得出性能拐点。

5、性能优化

引起这个问题一般有两个原因，未达到明确的性能要求，未达到行业要求。优化时要先检验设计和实际实施是否有出入 (索引没建、索引失效、缓存失效)，如有出入则修改后二次测试，直至实施达到设计。如无出入，考虑优化方案，提高能力。

6、设计余量

为抵抗流量激增带来的风险，设计余量有助于我们抵抗一些特殊场景。如实际测试为 10tps。7tps 则是合适的值。同时也可以为监控提供参考，预防突然死亡

7、扩展方案设计

系统支持横向或纵向扩展，以应对余量不足时，可直接通过扩展解决问题，如直接新增服务器，磁盘更换 (提高 IO)， 新增硬盘 (摊分 IO)。而此类扩展本身在正常情况下，能多支持 90% 或以上的压力