学习软件测试的第八天

三十六.JMeter 中的处理器类型有哪些？

1. 什么是 JMeter？

JMeter 是一个开源的性能测试工具。（压力测试）
它就像一个“虚拟用户模拟器”，能帮助你测试网站、接口或者系统在多个用户同时访问时是否会“卡住”或者“崩掉”。简单理解就是：JMeter 就像一批自动化的小机器人在不停访问你的网站，帮你发现性能瓶颈。

2.JMeter 中的“处理器”是干嘛的？

在 JMeter 里，处理器就像“工具助手”，帮你在请求前后做一些额外的工作。

处理器分两种：

1. 前置处理器（Pre-Processor）

   • 干嘛的？：在请求发出之前，先做点准备工作。

   • 举例：

     • 动态生成请求参数

     • 从前一步提取 Token，拼接进 URL

2. 后置处理器（Post-Processor）

   • 干嘛的？：在收到响应之后，提取重要数据或者记录结果。

   • 举例：

     • 从返回结果中提取用户名、token、订单号等

     • 处理 JSON、XML 响应数据

简单比喻一下：
请求好比“点外卖”，前置处理器是你点单前写备注，后置处理器是你吃完饭之后查账单或写评论。

3.面试术语

（1）什么是 JMeter？

Apache JMeter 是一款基于 Java 的开源性能测试工具，广泛用于对 Web 应用、API 接口、数据库服务等系统进行压力测试和负载测试。它支持模拟多个并发用户访问，提供图形化界面以及丰富的插件和扩展脚本能力，常用于系统性能评估和接口稳定性验证。

（2）JMeter 中的处理器类型有哪些？

在 JMeter 中，处理器（Processor）用于在采样器（Sampler）请求的前后执行额外逻辑，分为两类：

• 前置处理器（Pre-Processor）：在请求发送前执行，常用于参数初始化、变量设置、动态 URL 构造等操作。

• 后置处理器（Post-Processor）：在请求响应后执行，主要用于提取响应内容（如正则提取器、JSON 提取器、XPath 提取器）以供后续请求使用。

这两类处理器在构建复杂测试流程和实现参数关联方面具有关键作用。

三十七.服务器CPU指标异常怎么办？

1.什么是“服务器 CPU 指标异常”？

就是服务器的“处理器太累了”，忙不过来，表现为：

• CPU 占用率持续飙高（比如 80%、90%、甚至 100%）

• 响应慢、卡顿、甚至服务崩溃

• 系统风扇狂转，后台日志刷不停

这就像你连续处理很多任务没休息，容易“过载罢工”。

2.回答要点

维度	建议体现内容
意识	能识别性能问题，能监控系统资源指标
定位能力	能结合测试行为与资源异常进行分析
协作	能与开发、运维沟通定位高 CPU 问题
预防	能从压测设计、接口限流、代码建议等提出优化方案
总结能力	出问题后会记录、汇报并跟进闭环

3.面试术语

当服务器 CPU 指标异常时，我会从以下几个方面配合定位和处理问题：

1. 及时识别异常：
我会首先通过监控系统（如 Prometheus、Zabbix、阿里云监控等）接收到告警，发现 CPU 使用率异常升高，例如持续超过 80% 或瞬时达到 100%。也可以通过压测过程中观察到响应时间变长、超时或接口失败率上升。

2. 初步排查：
我会查看异常发生的时间点与最近的测试活动是否有关，比如是否执行了大并发接口测试、压力测试，或者是否刚部署了新版本。

3. 协助定位问题：
我会配合开发或运维团队，通过如下手段进一步定位原因：

• 让运维使用 top、ps、pidstat 等工具分析哪个进程占用高

• 查看是否存在接口死循环、频繁调用、或资源释放不及时等问题

• 查看系统、应用或中间件日志是否有异常堆栈信息

4. 提出优化建议或规避方案：
如果是由于测试触发的高并发压力引起，我会及时调整压测策略或限流配置，并建议：

• 对 CPU 密集型代码进行优化或异步处理

• 加入缓存，减少重复计算

• 设置告警阈值，提前预警资源占用情况

5. 后续跟进与总结：
异常处理完成后，我会参与问题总结，包括记录事件、协助开发复现、验证修复效果，并在测试报告中体现系统的性能瓶颈及优化建议。

三十八.项目上线后发现的bug，怎么处理？

1.通俗理解

项目上线后发现了 Bug，说明之前测试环节漏掉了一个问题，这时候不能慌，需要有条不紊地止血、查因、修复、预防。

你需要做到：

1. 第一时间响应，判断严重性（是页面错位还是功能不可用？）

2. 收集日志和复现路径

3. 通知开发，协同修复

4. 补充测试，验证修复无误

5. 推动回溯分析，防止类似问题再次出现

2.简洁版思维导图式回答

• 确认问题严重性（主流程/核心功能优先）

• 记录缺陷、通知开发

• 收集日志、协助复现

• 跟进修复、回归验证

• 参与复盘、补充用例

• 优化测试策略和发布流程

补充：

• “对于高频线上问题，我会推动构建线上自动化监控、埋点、A/B 验证机制，提升问题发现与隔离能力。”

• “我也会定期与开发团队做上线 bug 的分析总结，归因于需求变更、用例缺失还是测试盲区，并持续优化测试覆盖。”

三十九. 如果开发认为不是bug你怎么办

• 先冷静分析：是不是需求没对齐？

• 有没有依据：设计文档、原型图、会议记录能不能作为判定标准？

• 必要时提出来评估：拉上产品或测试 leader 一起 review

关键不是“赢了吵架”，而是“把问题解决”。

面试术语

遇到开发认为不是 bug 的情况，我会：

1. 回溯需求，判断是否符合文档预期；

2. 从用户角度说明潜在风险或影响；

3. 需要时拉产品或 leader 一起评估；

4. 无争议则归为建议项记录并跟踪。

 四十.APP测试和Web测试有什么区别

一句话总结：Web 测试更注重浏览器兼容性与响应逻辑，APP 测试更多涉及设备适配、网络变化与系统权限。

Web 看“浏览器”，APP 看“设备+权限”；
Web 靠“刷新”，APP 靠“安装”；
工具不一样，测试点更复杂。

面试术语

Web端测试和移动端类型基本相似，都需要功能测试、性能测试、安全性测试，他们主要区别于web端一般都是B/S架构，基于浏览器的，app是C/S架构，基于客户端的。

（1）从系统架构来说，web测试只更新服务器端，客户端就会同步更新，而如果app端修改了服务器，就意味着客户端用户所使用的核心版本都要进行回归测试一遍。

（2）客户端性能方面，web可能只关心响应时间，app端则需要关心流量、电量、cpu等

（3）兼容方面，web基于浏览器和电脑硬件、电脑系统的兼容；app则依赖手机或者iPad，不仅要看分辨率、屏幕尺寸还要看设备。