浅谈应用性能测试 PTS-CSDN博客

我们为什么要进行性能测试？

1. 评估系统的能力。

当应用上线有大量用户当问的时候，页面的打开速度直接影响用户体验，进而影响用户的留存。了解用户的真实使用体验，对应用做出针对性的性能评估，有效提升用户体验。

2. 验证系统的稳定性和可靠性。

在整个的网站应用架构体系中，会有一些接口基础服务，它的职责是对外输出一些稳定的查询，一些服务能力，这个时候系统需要有较高的稳定性，比如访问量很多，数据量很大，这个时候就需要关注性能。另外对于一些核心系统，可用性很高，对于性能系统也是非常关键的。

3. 改动了核心应用，担心对链路有影响。

当网站应用比较复杂的时候，比如核心应用被改造了，改造之后我们会担心这对整条核心链路有影响，这个时候也会考虑做性能评估。

性能测试关键指标

性能测试指标通常分为资源指标和系统指标。其中资源指标是指：CPU 使用率、内存使用率、磁盘I/O, 网络带宽等，系统指标是指：并发用户数、在线用户数、平均响应时间和事务成功率等。我们可以从业务方、研发和测试三个角度去看。

通常来说，业务方提出性能指标，比如某段时间内网站可能会带来100万UV， 1000万PV，然后研发将这些指标转化成实际性能指标，比如要实现多少的成交额、交易量等，再根据目标来设定合理的架构策略，最后测试保障这些性能指标。

大家可能会有疑问，业务方给出一个指标，怎么换算成研发可以实现的指标？比如在对接阿里巴巴广告类业务时，业务方说：“这个广告发布以后，会给网站带来100万的UV”，那这个怎么换算成研发需要实现的性能指标？这中间其实存在关联。例如阿里巴巴线上监控会统计通常UV和PV的比例，然后根据放大三倍或者五倍的比例，计算出100个UV对应的PV数，这是一种方式。

另外一种方式就是对业务进行合理的预估。比如像一些平台首页发布的秒杀页面，可能秒杀产品只有100多个，但是引流来的人有100万，这个时候假设这100万用户都会去查看这个页面，再做一些比例放大，然后得出一个相应的PV关系，也可以帮我们做一个推导。当PV数据有了以后，QPS、TPS、RT也是可以换算得出的。

常见的性能测试方法

1. 基准测试法

当我们拿到一个性能测试项目的时候，我们会对这个系统架构做个了解，了解最好的方式是做一个基准测试，先谈谈它的基本情况。所以会去定一个小并发，比如5-10个人的并发，先去测一测，看它的响应时间，然后将此作为我们的基准。

2. 压力测试

如果我们需要快速了解这个系统性能到底是什么情况？我们可以先做一个压力测试，压力测试是为了获取极限性能指标。比如可以设置一个3小时压测场景，每10分钟加10个用户，那到3小时后，可能就是180个用户了。这个时候观察，在压力不断增大过程中系统的表现。

3. 负载测试

这是是为了获取性能拐点，我们叫最佳性能。当达到这个点的时候，系统能力、极限能力是多少？这个通常用来做线上流量评估。

4. 稳定性测试

我们会把用户真实会发生的场景放大3-5倍，然后在线上运行24小时，在这个阶段会发现很多稳定性问题， list回收，java list回收，一旦回收出现问题，可能会出现内存溢出，这个在日常测试过程中，是很难测出来的，所以用稳定性测试查出这些问题。

5. 容量测试

当我们业务越来越复杂的时候，比如一场大促，应该怎么评估线上的性能？如何去做合理的扩容？这个就属于容量测试范畴。

性能测试工具选择

工欲善其事必先利其器，性能测试时模拟大量负载需要工具帮忙，市面上可供使用的负载工具繁多，如何选择呢？首先我们要明白负载工具是帮助我们来模拟负载的，对于性能测试来说，工具并不是核心，分析、评估、找出性能问题才是核心，这些是主观因素；工具是客户因素，自然要降低其对结果的影响，所以工具选择时我们有几个方面要考虑。

（1）专业、稳定、高效，工业级性能负载工具。

（2）简单易上手，在测试脚本上不用花太多时间。

（3）有技术支持，文档完善，不用在疑难问题上花费时间，集中精力在性能分析上。

（4）要考虑投入产出比。自研或者使用开源不一定比商业工具更省钱，因为要做技术上的投资，时间上的投资。