海康威视一面（测试）：自动化框架、用例设计与压测场景

《面试题目》

1. 自我介绍。
2. 根据简历考察逻辑能力。
3. 自动化测试框架。
4. 测试用例设计。
5. 压测场景设计。
6. 仿真工具提效详情。
7. IoT 原理。
8. 职业规划。
9. 离职原因。
10. 反问。

《参考解析》

自动化测试框架：结构、选型与落地效果

按「分层 + 组成 + 效果」来答。分层通常是：用例层（业务语义的测试步骤与断言）、页面/接口对象层（把 UI 元素或接口封起来，页面变了只改一处）、驱动层（Selenium/Playwright/Appium、HTTP 客户端）、数据层（测试数据与期望结果分离，支持多环境配置）、报告与通知层（结果汇总、失败归因、推送）。选型要讲判据：Web UI 用 Playwright/Selenium，App 用 Appium，接口用 pytest/TestNG + requests/RestAssured，接口自动化在投入产出比上通常优先于 UI（稳定、快、易维护）。落地效果用数字说话：覆盖了多少核心流程、执行时长、稳定性（同一版本重复跑的抖动率）、发现的缺陷数、以及回归从几天压到多久。追问一般会落在「用例不稳定怎么治」——显式等待代替 sleep、隔离数据、失败自动重试并分类（环境问题/数据问题/真 bug）、把不稳定用例单独打标而不是让所有人都不信任报告。

测试用例设计：先讲方法，再给这个业务的用例

答题模板是「等价类划分 + 边界值 + 判定表/因果图 + 场景法 + 错误推测」。等价类划分把输入分成有效与无效类，每类取代表；边界值取上点、离点、内点（比如范围 1~100 要测 0、1、2、99、100、101）；判定表适合多条件组合的业务规则（比如「会员等级 × 支付方式 × 优惠券」的叠加）；场景法按业务流程串起来（正常流、备选流、异常流）；错误推测靠经验补那些容易被忽略的点（并发、重复提交、越权、超时、断网）。落地时要先明确测试对象与验收标准，再列出功能点清单，逐条设计正向与反向用例，并给出优先级（P0 主流程、P1 重要异常、P2 边界与兼容）。如果面试官给一个具体功能（比如「文件上传」或「登录」），就直接把上面这套方法应用到它上面，列十条左右有代表性的用例，比只讲方法论更有说服力。

压测场景设计与仿真工具提效

压测要回答四个问题：压什么（核心接口与关键链路，先单接口后全链路）、用什么模型（并发用户数、RPS/TPS 目标、读写比例、数据分布——比如 80% 的请求集中在 20% 的热点商品）、怎么施压（JMeter/Locust/wrk，分布式压测机，注意压测机自身不能成为瓶颈）、看什么指标（吞吐、响应时间的 P50/P95/P99、错误率、以及服务端指标：CPU、内存、GC、连接池、数据库 QPS 与慢查询）。场景设计要包含：基准测试（单接口摸容量）、负载测试（逐步加压找拐点）、稳定性测试（长时间 70%~80% 负载跑数小时看内存泄漏与 GC）、峰值/脉冲测试（秒杀式的瞬时突增）、以及异常场景（依赖降级、节点宕机时的表现）。结论要能给出容量结论与优化建议，而不是只报一个数字。

「仿真工具提效」通常是硬件/设备类业务里的自研工具（用软件模拟设备上报数据、模拟协议交互），答题落点是：原来需要多少台真机/多少人手动操作、模拟后能覆盖多少设备与并发、把测试周期从多久压到多久、以及能复现哪些真机难造的异常（弱网、丢包、数据异常、大批量并发）。要强调工具本身的验证——仿真出来的行为必须与真机对齐（用少量真机做交叉验证），否则测出来的结论不可信。

IoT 原理与岗位相关问题

IoT 的架构按四层讲：感知层（传感器、摄像头、控制器等设备，负责采集与执行）、网络层（WiFi、蓝牙、Zigbee、4G/5G、NB-IoT、有线，负责把数据传出去）、平台层（设备接入与鉴权、协议解析、消息路由、设备影子/物模型、数据存储与规则引擎）、应用层（业务系统与用户界面，做监控、告警、控制与分析）。要能点出几个关键技术点：通信协议常用 MQTT（发布订阅、轻量、支持 QoS 0/1/2 与遗嘱消息）与 CoAP/HTTP，设备鉴权用证书或一机一密，离线消息与设备影子解决「设备不可达时怎么下发指令」，以及边缘计算把部分处理下放到网关以降低延迟与带宽。测试岗位在 IoT 里要特别关注：弱网与断连重连、大量设备并发接入、指令的时序与幂等、固件 OTA 升级与回滚、以及安全（越权控制他人设备、重放攻击）。「职业规划」与「离职原因」如实回答，规划要与岗位方向一致（比如往自动化与性能测试深入，或者往物联网平台的质量保障方向走），离职原因讲客观与主动判断，不做人格评价。