1. 性能测试思维

功能测试、自动化测试的结果： 发现预期结果 与 实际结果 不一致的地方 ===bug。 bug 的修复，就交给开发人员。

• 模拟的是一个人，或一个人循环使用。

性能测试

• 性能指标值，资源监控数据…… 通过对这些数据的分析与判断，识别是否存在性能问题。
• 性能问题的处理： 有的需要自己调优、有的是开发人员调优、有的架构调优、有的是 DBA 调优…… 调优的人会有很多类型岗位的人参与。…… 性能问题的解决人，是一个团队，不是个人。
• 性能测试：模拟多个人 同时使用 某个功能。
• 性能分析的思维是，抓主要问题，从简单入手。性能调优，可能是一个调优一个问题，可能会衍生更多问题。（摁下葫芦浮上瓢）

不要害怕性能调优，能力欠缺，我去分析了，分析的浅一点，分析次数多了，经验丰富了，分析的深度就会越深，次数多了，我就成了专家。

2. 性能测试分类

• 服务端性能测试。 即，通过对接口进行性能测试，分析被测的项目的服务端的性能问题。 …… 后端性能测试
• 用户端的性能测试。

jmeter 是做不了前端性能测试的。

• web 页面
• pc 端
• app 端
• 小程序端

 前端 有渲染时间的： 渲染依赖宿主： …… 前端的性能差异性非常大，做性能测试，效益非常低，技术门槛又很高。所以，当下，中 小微企业，不大适合做前端性能测试。

后端性能测试

• 后端通过 接口，暴露自己的能力给前端。 只要把接口的性能测试做好了， 任何一个前端的性能，都可以得到提升。
• 后端的维护，一般，都是 企业自己维护， 与使用者 没有关系。 …… 企业自己维护， 就能够监控，获得自己想要的任何数据。
  • 有了这些数据， 就可以为 性能分析提供数据支撑…… 更快的 找到性能问题的根源，从而优化。
  • 这个是企业中， 最容易实现的性能测试， …… 效益是比较理想。

3. 并发测试

就是用 多个人 同时请求。

• 并发：同一时间发起相同的请求
• 并行：同一时间发起的请求可以相同、也可以不同

侠义并发测试：同一个时间有大量的并发请求同一个接口。 ------ 有集合点性能测试。

广义并发测试：同一个时间有大量的并发请求（可以相同、也可以不同） ------ 性能测试，更多时候用这种。

4. 基准测试

进行第一次性能测试，得到性能指标数据。

就是我们以后，进行性能判断的基准。参考值

5. 负载测试

通过逐步增加并发用户数，持续调用接口、发起请求，实时观察性能指标数据（如响应时间、错误率、资源利用率等 ），以此判断系统是否达到服务瓶颈。

指标判断标准

通常遵循以下规则判定系统负载能力：

• 平均响应时间＜1.5s
• 错误率＜0.1%
• 资源利用率＜80%

测试流程与目标

• 初步区间测试：

  先在较大用户数区间（如从 10、20… 逐步到 100 ）缩小步长测试，观察性能指标。

  举例：

  • 并发 90 人时，平均响应时间＜1.5s、错误率＜0.1%、资源利用率＜80%，全部达标；
  • 并发 100 人时，至少有一个指标超出标准（如响应时间变长、错误率上升 ）。
    由此可初步确定可接受并发区间为 [90,100) 。

• 精细步长测试：

  针对 [90,100) 区间进一步细化，以 1 为步长（如 90→91→92…→100 ）再次测试。

  举例：

  • 并发 96 人时，所有指标达标；
  • 并发 97 人时，出现至少一个指标超标。
    则该接口最大可接受并发用户数为 96 。

测试结果应用

将 “96 并发用户数” 作为基准，执行性能测试并记录结果，后续可基于此基准，对比系统优化、版本迭代后的性能变化，判断系统性能是否提升或衰退 。

6. 压力测试、压测、稳定测试、容量测试、配置测试

（1）口语中的压测：先做负载测试，得到最大可接受的并发用户数。然后，用这个最大可接受的并发用户数，做性能测试，得到性能指标数据，根据这些指标数据，判断是否有性能问题，问题可能在哪里。

（2）压力测试： 长时间的性能测试。 通过长时间，来发现服务器是否存在不稳定性的问题。
长时间：现在一般，用小时为单位。以前是 7*24.

这种测试的并发用户数，应该设置多少呢？这个问题，就要 压力测试 & 稳定性能 区分。

不稳定： 动不动就重启、宕机、报错 ------- 就会说服务不稳定。 瞬间压力大，就很容易导致不稳定。

（3）瞬间压力： 比较短的时间，有非常大的请求。----- 稳定性能测试，一般就是并发用户数比较高。一般会加集合点。

压力测试，相对稳定测试而已，就会是并发用户数较低。压力测试的并发用户数，我们就会选择最大可接受并发用户数的 [20%,80] 区间的中的值。

稳定性能测试，就会取最大可接受并发用户数的 [80%, 无穷大]

（4） 容量测试

核心目标：看数据库里 “数据量大小不同时，系统性能咋变”。
比如：

• 数据库存 1 万条数据时，查询、新增功能快不快；
• 存 100 万条、1000 万条数据时，同样的功能会不会变慢、卡崩。
  作用：找出系统 “能扛住多少数据量”，提前规划扩容、优化，避免用户多了、数据堆了，系统直接崩掉。

（5）造数据（常配合容量测试等场景）

问题本质：测试时，需不需要把数据造得 “完全正确、和真实业务一模一样”？
答案：不用！

• 造数据是为了模拟 “数据量级”，重点在数量（比如凑够 100 万条），不是质量（不用每条数据都严格符合真实业务逻辑）。
• 只要数据格式、类型和真实场景匹配（比如手机号字段填 11 位数字），能让系统 “以为在处理真实数据”，测出性能变化就行。

（6） 配置测试

别被名字骗了：不是只换服务器、硬盘这些硬件！
真实含义：改改系统里的关键参数（比如程序里的缓存大小、数据库连接池数量、接口超时时间 ），再测性能。
举个栗子：

• 原本系统设置 “最多同时连 10 个数据库”，改成 “最多连 50 个”，看看性能会不会变好 / 变差；
• 把 “接口超时时间” 从 3 秒改到 5 秒，测测用户请求会不会更少报错。
  作用：找到系统参数的 “最优配置”，不靠换硬件，也能让系统跑得更顺、更快。

简单总结：

• 容量测试 → 玩 “数据量”，看系统扛不扛得住；
• 造数据 → 凑数就行，不用死磕数据对不对；
• 配置测试 → 调参数，不靠换硬件也能优化性能。
  实际测试里，它们常配合其他测试（比如性能测试、压力测试），一起找出系统的 “弱点” 和 “优化点”~

7.性能指标

1. 并发用户数

• 定义：同时发起请求的 “用户数量” ，是性能测试要模拟的核心场景（比如模拟 100 人同时下单）。
• 关键区别：这里的 “人” 是指发起请求的角色，不是账号数量 。比如 1 个用户（人）开 5 个浏览器窗口发请求，也算 1 个并发用户（关注行为，不是账号）。

2. 响应时间

• 定义：从 “发请求” 到 “收到服务器回复” 的总耗时，由 网络传输时间 + 服务器处理时间 组成，不含前端页面渲染时间（比如网页加载后，浏览器把数据变成界面的时间不算）。
• 细节补充：
  • 网络越稳定（比如用局域网、插网线），网络传输时间越接近 0，响应时间就越能体现 服务器真实处理能力 。所以性能测试尽量别用 WiFi（容易波动），优先选独立、稳定的网络环境。
  • 平均响应时间（ART）：最常用的指标，代表一批请求的平均耗时，能直观反映整体速度。
  • 90%、95%、99% 响应时间：把所有请求的响应时间从小到大排序，取排在 90%、95%、99% 位置的耗时。
    • 举例：100 个请求，按响应时间排序后，第 90 个的耗时是 “90% 响应时间”，代表 90% 的请求都比它快 。
    • 企业选 90% 这类指标当标准，会比平均更严格（因为要保证绝大多数请求都达标），也说明接口越稳定（波动小，慢请求少）。

 3.吞吐量

一、核心概念：吞吐量

• 定义：网络中 每秒能传输的 “事务数” ，体现系统 “数据处理 & 传输的效率”。
• 关键关联：和 “事务” 强绑定，得先懂 “事务” 是啥👇

二、事务（Transaction）：理解吞吐量的基础

简单说，“事务” 就是一次完整的 “请求 + 响应” 过程 ，分 2 种常见情况：

1. 单接口事务（Jmeter 默认逻辑）：
   一个并发用户发 1 个 HTTP 请求，必须等服务器返回响应后，才会发下一个请求。
   → 比如模拟 “用户下单”，发请求→等服务器确认订单→再发下一个请求（像查询订单）。

2. 多接口组合事务（用 “事务控制器” 实现）：
   把多个接口的 “请求 + 响应” 打包成 1 个大事务 。
   → 比如 “购物流程”：选商品接口 + 下单接口 + 支付接口，一起算 1 个事务，测完整流程的吞吐量。

三、吞吐量的 “坑”：网络瓶颈影响

• 理想情况（无网络瓶颈）：
  发 1 个请求→服务器处理→返回响应→发下一个请求 ，此时 “吞吐量 = 服务器实际处理的事务数” ，数据是准的。

• 现实情况（有网络瓶颈）：
  网络卡了（阻塞、丢包），服务器明明处理完了，响应却传不回来… 这时 吞吐量数值会 “虚高” 或 “不准” ，不能直接当 TPS（每秒事务数）用 ！

四、吞吐量的 “特殊注意”：负载测试场景

做 负载测试 时（逐步加并发用户数，找系统瓶颈），因为 并发用户数一直在变 ，吞吐量显示的是 “平均值”，体现不出不同并发下的真实性能 。
→ 所以负载测试时，别只看吞吐量 ，得结合响应时间、错误率等指标一起分析！

4. TPS（Transactions Per Second）

• 直译：每秒事务数
• 含义：服务器每秒能处理的 “完整事务” 数量 ，是衡量服务器 “处理能力” 最核心的指标！
  • 事务 = 一次完整的 “请求 + 处理 + 响应”（比如用户下单，从发请求到服务器确认订单完成，算 1 个事务）。
  • 体现服务器 “实实在在处理业务的效率”，数值越高，处理能力越强。

5. QPS（Queries Per Second）

• 直译：每秒查询率
• 含义：服务器每秒能处理的 “查询操作” 数量 （比如数据库查询、接口查询），一般从服务器监控数据里看。
• 和 TPS 的关系：
  • 1 个事务里，可能包含 多个查询操作 （比如下单时，要查库存、查用户信息…）。
  • 所以对单个接口 / 业务来说，请求次数越多（对应 TPS），查询次数（QPS）也会越多 ，二者 “正相关”。
  • 企业里常 “简化用 QPS 代替 TPS” ，因为测 QPS 更方便，且能反映服务器性能趋势。

6. RPS（Requests Per Second）

• 直译：每秒请求数
• 含义：客户端（用户侧）每秒发出去的请求数量 。
  • 比如 100 个用户同时点 “下单”，客户端 1 秒发了 200 个请求（可能包含重复、重试请求），RPS 就是 200。
  • 体现 “用户侧的压力大小”，但不代表服务器真的处理了这么多（因为可能有重复、失败请求）。

7. HPS（Hits Per Second）

• 直译：每秒点击次数
• 含义：客户端（用户侧）每秒的 “点击行为” 数量 。
  • 注意：1 次点击可能触发 多个请求 （比如点 “下单”，可能同时发 “校验库存”“扣减余额”“生成订单” 等多个请求）。
  • 更贴近 “用户实际操作频率”，但因为和真实请求对应关系复杂，实际性能测试里用得少，一般看 RPS 或 TPS 。

一句话总结：

• TPS 看服务器 “真本事”（处理完整业务的能力）；
• QPS 看服务器 “查询效率”（常代替 TPS 简化用）；
• RPS 看客户端 “发请求的压力”；
• HPS 看客户端 “用户点击的频率”。
  实际性能测试里，重点关注 TPS（或 QPS）+ 响应时间 + 错误率 ，就能判断系统扛不扛得住啦～

8. 吞吐率

一、核心概念：吞吐率

定义：网络中 每秒传输的字节数量 （单位一般是 KB/S ），性能测试时能在监控里看到。
→ 简单说：就是 “每秒能传多少数据”，体现网络传输的 “实际效率”。

二、关键关联：吞吐率 vs 带宽

带宽：网络 “理论最大传输能力”，单位是 Mbps（兆比特每秒 ）。

• 换算关系（重点！）：
  1Mbps = 1024Kbps（千比特每秒）
  因为 1 字节（B）= 8 比特（b） ，所以 1Mbps = 1024/8 = 128KB/s（理论最大传输字节数）。
  → 比如 “带宽 1M”（1Mbps），理论上每秒最多传 128KB 数据。

• 实际带宽：分 “上行（上传）” 和 “下行（下载）” ，运营商说的 “带宽” 一般指单方向的理论最大值（比如下行 100M）。

三、性能测试的 “带宽坑”：别用民用宽带！

民用宽带（家里 / 办公室 WiFi）的带宽是 “共享、不稳定” 的：

• 多人用会抢占资源，导致网络波动大；
• 运营商可能限制 “上行带宽”（比如你办的 100M 宽带，上传可能只有 10M ）。
  → 性能测试要模拟 “稳定压力”，得用 独立、带宽可控的网络（比如企业专线、局域网）。

四、用吞吐率分析 “带宽是否拖后腿”

核心逻辑：对比 “实际吞吐率” 和 “服务器带宽上限”，判断网络是不是瓶颈。

• 步骤 1：看监控里的 “吞吐率最大值”（比如测出 267KB/s ）。
• 步骤 2：换算成带宽（267KB/s × 8 ≈ 2136Kbps ≈ 2.1M ）。
• 步骤 3：和服务器实际带宽对比：
  • 如果 “换算后的带宽” 接近服务器带宽上限 → 网络是瓶颈（数据传不动，拖慢系统）；
  • 如果 “换算后的带宽” 远小于服务器带宽上限 → 网络不是瓶颈（性能问题出在服务器处理能力，而非网络）。

一句话总结：
吞吐率是 “实际每秒传多少数据”，结合带宽换算，能快速判断 “网络会不会拖性能后腿”，性能测试时别用民用宽带，否则结果不准！

9.资源利用率

一、核心规则：资源利用率 “不超 80%”

这是行业常见的经验阈值 ，意思是：不管硬件还是服务，资源用到 80% 以内，算 “有冗余、能稳定运行”；超过 80% ，可能出现卡顿、崩溃，需要优化。

二、两类 “资源利用率” 细分

1. 硬件资源利用率（服务器物理层面）

关注 CPU、内存、磁盘、IO（输入输出） 的使用比例：

• CPU 利用率：CPU 忙不忙，越高越容易 “卡”；
• 内存利用率：服务器 “内存够不够用”，高了可能频繁读写硬盘，拖慢速度；
• 磁盘利用率：硬盘读写数据的压力，高了会让文件存储 / 读取变慢；
• IO 利用率：数据在 “内存 ↔ 磁盘”“网络 ↔ 服务器” 传输的压力，高了会让数据交互变卡。

2. 服务资源利用率（软件 / 架构层面）

关注 容器、集群、资源分配 的使用效率：

• 容器（比如 Docker）：每个容器分配的 CPU、内存够不够，会不会互相抢资源；
• 集群（多台服务器一起干活）：任务分配均不均匀，有没有某台服务器累垮、其他闲着；
• 资源：服务依赖的中间件（比如数据库连接池、缓存）用得满不满，会不会成为瓶颈。

三、关键误区：“并发增加 ≠ CPU 一定升高”

性能测试时，就算 “并发用户变多、请求数变多”，CPU 利用率也不一定暴涨，因为：

• 可能请求是 “IO 密集型”（比如频繁读写硬盘、网络传输），主要压内存、磁盘、网络，CPU 压力不大；
• 可能服务有 “缓存优化”（比如热点数据存在内存里，不用每次查数据库），CPU 不用反复计算；
• 可能服务器是 “多核心、分布式” 架构，压力被分摊了。

一句话总结：
资源利用率看 “硬件（CPU / 内存等）+ 服务（容器 / 集群等）”，别光盯着 CPU ，且并发增加不一定只涨 CPU ，得综合判断系统瓶颈～

 8. 性能测试条件

1. 独立测试环境

• 要求：测试用的硬件配置（如服务器的 CPU、内存、硬盘型号等 ）要和生产环境（实际用户使用的环境）一致，但硬件数量可以不同。
• 原因：保证测试结果能反映生产环境的性能情况。比如生产用的是特定型号 CPU，测试环境用同款，才能准确测 CPU 对性能的影响；数量可不同是因为测试环境不需要和生产一样多的服务器，但配置得一致，避免因硬件差异导致测试白做。

2. 独立的网络

• 要求：测试时要用独立的网络环境，不能和其他业务（如日常办公网络、其他系统测试网络 ）混用。
• 原因：网络环境会影响性能测试结果。如果和其他业务共用网络，别人占用带宽、出现网络波动，会干扰性能测试中对网络相关指标（如响应时间里的网络传输时间 ）的判断，让测试结果不准确。

3. 需求要完成必要性研究 - 确定有必要做性能测试

• 要有侧重，不是什么都做性能测试：性能测试耗时耗力，得挑关键的来做，不是所有功能、所有系统都需要。比如一个简单的内部小工具，用户少、功能单一，可能就没必要大费周章做性能测试。
• 有监管、验收、明确性能测试要求：如果是要给监管部门看、要通过验收的项目，或者项目本身明确规定了要做性能测试，那才做。比如金融行业的系统，监管可能要求必须做性能测试保障稳定性。
• 涉及生命财产安全、涉及民生：像医疗系统（关乎生命安全 ）、交通票务系统（关乎民生出行 ），这些系统性能出问题可能造成严重后果，必须做性能测试。
• 大型项目上线：大型项目用户多、业务复杂，上线后性能不好影响范围大，所以要做性能测试提前发现问题。
• 重大调整：系统做了大的架构变更、功能迭代，可能引入性能问题，需要做测试验证。比如把系统从单体架构改成微服务架构，得测性能是否符合要求。
• 预计可能会剧增的：如果预计用户量、业务量会大幅增长（比如电商大促前 ），要提前做性能测试，看系统能不能扛住。
• 产品核心功能：产品最关键、用户使用最频繁的功能，得保障性能，所以要做测试。比如打车软件的 “下单”“派单” 功能。

4. 需求的性能指标是明确，可以量化到具体的数值

• 要求：得清楚知道性能要达到什么标准，且能用具体数字衡量。比如明确规定 “平均响应时间 < 1.5 秒”“每秒处理事务数（TPS）≥ 500” 。
• 原因：这样测试完才有判断依据，知道系统性能是否达标。要是指标不明确，测试后都不知道算合格还是不合格，性能测试就失去了意义 。

9.性能测试流程 

1. 性能需求分析（测试的 “指南针”）

核心任务：搞清楚 “要测什么、达到什么标准”，具体要做这些事：

• 明确性能指标：比如 “响应时间 < 1.5 秒”“TPS ≥ 500”；
• 熟悉业务：懂系统是干啥的（比如电商系统的 “下单”“支付” 流程）；
• 梳理接口 & 数据流：弄清楚系统怎么交互（哪个接口对应哪个功能，数据咋传的）；
• 写测试文档：把需求、方案写成文档，方便后续执行。

2. 性能测试环境（测试的 “试验场”）

核心任务：搭一个能模拟真实场景的环境，具体要做：

• 自己 / 找人搭环境：尽量自己掌控（比如用 Docker、虚拟机搭），实在不行找运维帮忙，但必须清楚环境参数（比如服务器配置、网络带宽）；
• 监控环境：提前准备好 “看性能数据” 的工具（比如监控 CPU、内存、网络的软件），否则测试时看不到问题。

3. 编写调试性能脚本（测试的 “武器”）

核心任务：用工具（比如 JMeter、LoadRunner ）写 “模拟用户请求” 的脚本，然后验证：

• 工具：选适合的性能测试工具（开源的 JMeter 常用，商业的 LoadRunner 功能全）；
• 验证：跑一下脚本，确保能正常发请求、收到响应，别脚本写错了白忙活。

4. 性能场景的执行（测试的 “实战”）

核心任务：设计真实用户场景，跑测试、记数据：

• 场景设计：模拟用户怎么用系统（比如 “1000 人同时下单”“早晚高峰打车请求” ）；
• 执行 & 记录：跑测试时，盯着监控工具，记录响应时间、TPS、错误率这些数据。

5. 性能问题跟踪与分析、调优（测试的 “价值所在”）

核心任务：找出性能瓶颈，想办法优化，注意这几点：

• 不是测试人员全能调优：测试人员发现问题，开发、运维、DBA（数据库管理员） 得一起配合改代码、调配置；
• 分析思路（按优先级排查）：
  1. 先看 “自己脚本有没有问题”（比如脚本写错了，发请求逻辑不对）；
  2. 再查 “网络瓶颈”（是不是网太卡，数据传不动）；
  3. 接着看 “服务器硬件”（CPU、内存是不是跑满了）；
  4. 然后调 “应用服务 + 参数”（比如 Tomcat 线程数设少了，处理不过来）；
  5. 最后查 “数据库”（慢 SQL、索引没建好）。
• 记录遗留问题：有些问题当前版本解决不了（比如要改架构），记下来跟踪后续版本优化。

10.性能测试文档 

一、性能测试方案（测试的 “规划蓝图”）

作用：回答 “为啥测、谁来测、怎么测、测完输出啥”，包含这些内容（不是必须全有，按需调整）：

• 测试背景：为啥要做性能测试？（比如 “系统上线后用户量会暴涨，怕扛不住” ）
• 性能测试目标：要达到啥标准？（比如 “响应时间 < 2 秒，TPS ≥ 1000” ）
• 性能测试人员（团队）：谁负责？（测试工程师、开发、运维、DBA 要不要参与 ）
• 环境架构：测试环境啥样？（服务器配置、网络拓扑、用了哪些中间件 ）
• 测试策略：用啥方法测？（负载测试、压力测试… 选哪种或组合用 ）
• 场景：模拟啥用户行为？（比如 “1000 人同时下单”“早晚高峰打车” ）
• 测试监控：用啥工具看性能数据？（监控 CPU、内存、TPS 的工具 ）
• 测试输出：测完要交付啥？（报告、优化建议… ）
• 风险：可能遇到啥问题？（比如测试环境和生产不一致，结果不准 ）

二、测试用例（测试的 “执行清单”）

作用：明确 “具体测哪些接口、怎么测、预期结果是啥”，包含：

• 测试接口、参数：测哪个接口（比如 “/api/order/create” ），传啥参数（比如订单金额、用户 ID ）；
• 性能场景（策略）：怎么模拟用户压力？（比如 “并发 500 人持续 10 分钟” ）；
• 测试预期指标：要达到啥数值？（并发用户数、TPS、响应时间… ）

三、测试记录（测试的 “过程台账”）

作用：详细记 “测试时干了啥、得到啥数据”，包含：

• 记录测试的过程：啥时候测的、谁测的、遇到啥问题；
• 脚本（接口脚本、场景运行脚本）：用的性能测试脚本（比如 JMeter 写的 .jmx 文件 ）；
• 执行命令：跑测试时敲了啥命令（比如 “jmeter -n -t test.jmx -l result.jtl” ）；
• 测试结果：响应时间、TPS、错误率这些数据；
• 监控数据（截图）：CPU 利用率、内存占用的监控图；
• 分析与结论：初步分析 “哪里有问题、可能啥原因”。

四、测试报告（测试的 “最终结论”）

作用：把测试过程、结果、问题、建议整理成文档，给团队、领导看，包含：

• 工具生成 / 手写：工具（比如 JMeter ）能自动生成简单报告，但重要项目一般要手写（详细、清晰）；
• 测试结论：系统性能达标吗？哪里有问题？
• 环境组网：测试环境咋搭的？（服务器、容器、集群咋部署 ）；
• 测试场景：实际跑了哪些用户行为？
• 测试记录：过程数据是啥样的？
• 问题记录：发现了哪些性能瓶颈？
• 调优的记录（代码、参数）：怎么优化的？改了哪些代码、调了哪些配置？

五、关键原则（这些 “不能” 和 “要注意”）

1. 性能测试，一般不用生产环境：
   生产环境是 “用户真实在用的”，搞性能测试会压垮系统，影响真实用户，所以用测试环境模拟。

2. 性能测试脚本，不能用接口功能测试脚本：
   功能测试脚本只验证 “对不对”，性能测试脚本要模拟 “多用户、高压力”，逻辑、参数、并发控制都不一样，得单独写。

3. 性能测试，不是为了数据，而是找问题：
   别光盯着 “响应时间 1.2 秒、TPS 999” 这些数字，要分析 “为啥慢、哪里 bottleneck（瓶颈）”，解决实际问题。

4. 不是所有接口都要测，优先测关键的：
   产品里的接口有重要性区别（比如 “下单” 比 “查看帮助文档” 重要 ），优先测 “用户常用、影响大” 的接口，别浪费时间测所有接口。