软通动力测试一面（社招）：Web 与 App 测试差异、抓包与机器人指令定位

《面试题目》

1. 你现在在哪个城市、在哪个区？
2. 你觉得 Web 端和 App 端的测试有什么区别？
3. 除了更新，有做过来电、切换、中断、网络、消息推送以及兼容性这类测试吗？
4. 平时在日常工作中怎么判断问题是前端还是后端？
5. 前端和后端问题是通过什么工具去判断？
6. 你抓包用的什么工具？怎么抓取 HTTPS 的请求？
7. 接口工具有用过哪些？
8. JMeter 的使用说一下，在使用过程中需要添加哪些元件？
9. Selenium 这个工具聊一下，UI 定位元素的方式有哪几种？
10. 页面自动化测试用的什么驱动？
11. Linux 常用命令有哪些？你在什么场景下会用 Linux？
12. 查看 IP 的命令是什么？编辑文件的指令？打包和解压指令记得吗？
13. 你这家公司是做机器人的，这个项目是用的哪个协议？
14. 举一个场景：给机器人下发一个挥手动作的指令，这个机器人并没有挥手，你怎么去定位在哪个环节出现了问题？
15. 反问（对面试提建议）。

《参考解析》

Web 与 App 测试的差异：从六个维度答

这题如果只答「更新和下载方式不同」就太单薄了，面试官当场也提示了要补充。按维度展开：一是设备与环境碎片化，App 要覆盖机型、系统版本、分辨率、厂商定制 ROM，Web 主要在浏览器与分辨率上做兼容；二是安装与升级，App 有安装/卸载/覆盖安装/增量升级/降级、以及升级后数据迁移，Web 只需处理缓存与强制刷新；三是移动端专有场景，来电、短信、闹钟等中断，前后台切换与进程被回收，横竖屏与多窗口，弱网与断网重连、网络切换（WiFi/4G/5G），以及推送的到达与点击跳转；四是权限与安全，App 涉及相机、存储、定位、通讯录等运行时权限，还有越权访问本地数据、证书校验与加固；五是性能指标不同，App 关注启动耗时、内存占用、CPU、流量、耗电、卡顿与崩溃率，Web 关注首屏时间、资源加载、渲染性能与 LCP/CLS 这类指标；六是发布与回滚，App 要靠应用市场审核、灰度与强制升级策略，Web 可以随时发布与回滚。答完可以补一句测试策略的差异：App 更依赖真机与兼容性矩阵、自动化成本更高（要处理设备农场），Web 更容易做自动化和多浏览器并行。

前后端问题的判断与工具

判断思路是「先看请求与服务端返回，再看渲染与本地状态」。具体动作：打开浏览器开发者工具的 Network，看请求是否发出、状态码与响应体是否符合预期——响应正确但页面不对，问题在前端（渲染、数据绑定、缓存）；请求根本没发出，问题在前端（逻辑、事件、参数校验）；返回 4xx/5xx 或响应体不符合接口契约，问题在后端。App 端用 Charles/Fiddler/mitmproxy 抓包做同样判断，iOS 还要处理证书信任，Android 7 以上要注意应用不信任用户证书的问题（需在 debug 包或把证书装到系统区）。工具之外还要有非工具手段：看服务端日志与链路追踪（按请求 ID 串起来）、看监控指标（错误率与耗时的变化）、以及用 curl/Postman 直接复现接口——能绕过前端直接复现就说明后端有问题，反之请求本身有问题。HTTPS 抓包的原理要能讲清：抓包工具作为中间人，客户端信任工具的根证书后，工具与客户端建立 TLS、与服务端另建一条 TLS，从而解密内容；这就是为什么必须先在设备上安装并信任抓包工具的证书。

JMeter、Selenium 与 Linux 基础命令

JMeter 的元件按「脚本结构」回答：测试计划（全局配置），线程组（并发用户数、Ramp-up、循环次数），配置元件（HTTP 请求默认值、CSV 数据文件设置做参数化、HTTP Cookie 管理器、HTTP 信息头管理器），取样器（HTTP 请求、JDBC 请求、调试取样器），前置/后置处理器（正则表达式提取器或 JSON 提取器做关联、BeanShell/JSR223 脚本），断言（响应断言、JSON 断言、持续时间断言），定时器（固定/随机/同步定时器做集合点），逻辑控制器（事务控制器、循环、条件），监听器（聚合报告、查看结果树、用命令行模式生成 HTML 报告）。实践中要强调两点：正式压测用非 GUI 模式（jmeter -n -t x.jmx -l result.jtl）并把监听器关掉，否则压测机自己先成为瓶颈；分布式压测用 master-slave，注意参数化文件要分发到各 slave。

Selenium 的元素定位方式有八种：id、name、class name、tag name、link text、partial link text、css selector、xpath，其中 id 与 CSS 最稳定高效，XPath 灵活但易受结构变化影响。页面自动化用的驱动要与浏览器版本匹配（ChromeDriver/GeckoDriver），现代做法是用 Selenium Manager 或 WebDriver 协议封装（Playwright、Cypress 也是同一层能力）。要提稳定性实践：显式等待（WebDriverWait + 期望条件）代替 sleep、给元素定位封装重试、用 Page Object 模式隔离页面变化、在 CI 里用无头模式与截图录像做失败取证。

Linux 常用命令按用途分组：文件与目录（ls、cd、cp、mv、rm、find）、查看内容（cat、less、tail -f、head）、搜索（grep、awk、sed）、权限（chmod、chown）、进程与端口（ps -ef、top、kill、netstat/ss、lsof -i）、磁盘与内存（df -h、du -sh、free -m）、网络（ping、curl、traceroute）、查看 IP（ip addr 或 ifconfig）、编辑文件（vi/vim 或 nano，会 i 进入插入、Esc 后 :wq 保存退出）、打包解压（tar -czvf x.tar.gz dir、tar -xzvf x.tar.gz、zip/unzip）、以及日志排查（grep -C 看上下文、awk 聚合、wc -l 计数）。使用场景要举真实例子：登录服务器看应用日志定位报错、清理磁盘、查端口占用、用 scp/rsync 传文件、写定时脚本。

机器人指令场景：端到端逐段定位

这题的答法是先把链路拆开，再逐段验证——下发指令到机器人挥手，中间至少经过：操作端（App/网页/语音）→ 网络传输 → 云平台或网关（鉴权、协议解析、指令下发）→ 通信链路（WiFi/蓝牙/串口/CAN，取决于形态）→ 机器人本体的控制程序 → 执行机构（舵机/电机）。定位方法是从两端往中间夹：先确认操作端是否真的发出了指令（抓包或看客户端日志，请求参数是否合法），再看云平台是否收到并成功下发（服务端日志、消息网关与设备在线状态、指令状态机是否停在「已发送未确认」），然后看机器人端是否收到（设备侧日志、串口/总线抓包），最后看执行层是否响应（舵机供电、驱动板状态、限位与安全保护是否触发）。要能指出常见分界特征：请求合法且服务端返回成功但设备无动作，大概率在通信或执行层；服务端根本没收到，问题在客户端或网络；设备收到指令但没动作，查协议解析与硬件。同时给出复现与隔离手段：换一台设备/换一个网络/换一条指令（用一个已确认可用的动作做对照），能快速把范围切一半。面试官最后的建议很实在——场景题不要只说思路，要把「具体怎么测、用哪个工具、看哪条日志」说出来，这正是评分点。