刚进入性能领域时，测试工作复杂，分析工作复杂，优化工作也复杂，这些可能会让工程师晕头转向，不知道该从哪里开始着手，实际上，只要抓住关键指标，再抓住方法，就能把思路理顺。
性能领域的困惑
刚进入性能领域的工程师，常常感觉不知道该从哪里开始着手。性能测试包含多个方面，覆盖了多种概念和指标。比如说并发用户数，虽然经常被用来衡量系统的并发处理能力，但是它的细分概念很容易让人产生混淆。许多新手对这些概念没有深入的理解，所以在实际操作的时候困难重重。他们需要花费时间，积累经验，才能适应这个复杂的领域。
并发用户数的误区
笼统地把并发用户数当作衡量系统并发处理能力的指标，这种做法是不科学的。并发用户包含在线用户数和严格并发用户这两类。哪怕严格并发用户数比较少，也有可能给系统带来很大压力。对于那些没有经过性能测试和调优的应用系统，5至10个严格并发用户就可能致使性能出现问题。在实际测试的时候，我们不能仅仅关注并发用户数的表面数值。
业务处理能力描述
对于日交易量比较大的系统，测试报告通常会用每秒完成多少万笔交易来描述业务处理能力，或者用8/12/24小时完成多少万笔交易来描述业务处理能力。这种方式更加直观，能够让相关人员迅速了解系统业务处理规模。比如说一些电商系统，在促销活动期间，这种描述可以清晰地展示系统应对交易的能力。
不同应用的性能指标
在交互式应用里，用户体验直观地体现为响应时间，根据并发用户数和响应时间能够确定系统性能规划。对于非交互式应用来说，用“吞吐量”来描述系统性能更为合理。像文件传输系统这类属于非交互式的应用，吞吐量能够更准确地反映其性能。
吞吐量的重要作用
在容量规划测试里，吞吐量是重点关注的指标，它能够体现系统级的负载能力。在web系统性能测试中，吞吐量通过请求数/秒来体现。吞吐量有两个重要作用，其一，它能协助分析性能瓶颈，吞吐量受限是性能瓶颈的重要表现；其二，它能帮助确定系统性能上限。
性能瓶颈分析方法
RBI方法会先去访问服务器小页面以及简单应用，借此从基础层面了解系统吞吐量的表现，然后按“自下而上”的方式来分析，确定性能瓶颈，先判断是并发还是吞吐量引发了问题，接着再从网络、数据库、应用服务器以及代码本身去寻找具体的瓶颈，技术支撑人员在产品环境部署新服务器或应用的时候，会运用这种方法来检查常见问题。
系统问题处理清单
技术支撑人员在部署新服务器或者应用的时候，会制定检查清单，用来处理常见问题。这类清单大多处理的是修复方法容易记录的问题，像是设置可调参数，而不是针对源代码或者环境进行定制修复。这样做能够提高问题处理的效率，可以保障系统在真实压力下稳定运行。
USE方法的优势
USE方法可将分析引导到关键指标上，能尽快核实所有系统资源，在性能测试和分析里，快速定位问题相当重要，它助力工程师高效排查系统问题，还能减少问题定位时间。
测试用例时间分配
软件测试执行的时候，应该把时间偏向重要模块的测试用例，这样能让测试更有效果，能够及时发现程序错误。合理分配测试时间，可以让资源利用得更充分，能把精力集中在容易出现问题的模块上，进而提高测试的质量。
调优后的测试分析
每次进行调优之后，需要在相同的测试场景下进行测试，还要在尽可能一致的后台数据环境中测试，之后将测试结果与基线进行对比分析。通过这样做能够确认解决方案是不是有效，同时关注是否会带来其他问题。要确保调优不会引发新的性能问题，从而让系统性能逐步得到提升。
你在进行性能测试以及优化的时候，碰到过哪些困难的问题？可以在评论区进行分享，与此同时，也不要忘记为本文点赞以及分享。
