快手测试开发实习一面：购物车高风险场景与 AI 用例治理

《面试题目》

1. 介绍一下你在上家公司的研发测试流程
2. 如果让你测试一个购物车 App，你会如何设计高风险测试场景？
3. 购物车数量接口收到 +1、+1、-1 三个请求，但由于网络抖动按 -1、+1、+1 到达，应该怎样测试？
4. AI 生成测试用例时出现了大量看似合理、实际不存在的业务规则，如何治理？
5. AI 自动生成的接口用例执行通过，为什么仍然可能没有测试价值？
6. 同一个缺陷只在灰度节点出现，其他节点完全正常，如何定位？
7. 如何测试基于 Kafka 的设备遥测数据处理链路？
8. 请做一下自我介绍
9. 上一段实习为什么离职？

《参考解析》

购物车高风险场景：把「字段联动」当第一类风险

购物车的缺陷基本不出在单个按钮上，而在商品、价格、库存、优惠、用户身份之间的联动。可以按四条线拆：

① 商品与规格：同一商品多规格是否被错误合并成一行、切换规格后数量与价格是否跟随刷新、同商品重复加购是累加数量还是新增行。② 价格一致性：加购后商品调价、活动开始或结束，购物车展示价、结算页价格、支付页实付价必须同源同值，测试时要在「加购 → 结算」之间人为改价，验证是否实时失效或给出提示。③ 库存与状态：库存为 0 仍可加购、超卖、下架/失效/限购商品在购物车中的置灰与不可结算。④ 优惠叠加：满减、店铺券、平台券、会员折扣、跨店满减、运费券的叠加顺序与互斥规则，重点测勾选部分商品时券门槛是否按已勾选金额重算、跨店结算与修改收货地区后运费和优惠是否重算。

还要覆盖多端联动：两台设备同时改同一购物车，数量与勾选状态如何合并（以最后写入为准还是做合并求和，必须与产品约定一致），以及弱网下连续点加号时客户端展示数量、服务端数量、最终订单数量三者一致。

请求乱序：先分清接口传的是「全量」还是「增量」

如果参数是最终数量（依次提交 2、3、2），乱序到达会让旧请求覆盖新值；如果是增量（+1/-1），要防同一请求被重复执行。工程上通用的做法是给每次修改带上单调递增的版本号，服务端只接受版本更新的请求，旧版本直接拒绝或忽略，例如：

PATCH /api/cart/items/927
{"quantity": 2, "version": 18}

测试要点：用代理或故障注入把版本 18 排在版本 17 之前到达，确认服务端保留版本 18 的结果；再发两个版本相同但内容不同的请求，验证不会互相覆盖（幂等键/唯一索引兜底，返回冲突而不是静默覆盖）。另外要确认服务端的「读-改-写」是否原子——SELECT ... FOR UPDATE 或乐观锁（UPDATE ... WHERE version = ? 判断影响行数），否则并发下照样丢更新。校验不能只看接口返回值，必须回查购物车接口、缓存和数据库三方一致。

AI 用例治理：每条规则都要能溯源

核心原则是不让生成结果直接进正式用例库。① 生成前先把需求、接口文档、原型、数据库约束、历史缺陷整理成带版本的知识库；② 要求模型对每条用例输出出处字段，例如 case_title / source_document / source_section / precondition / expected_result，并指明对应章节；③ 生成后做规则校验：接口路径是否真实存在、字段名与枚举值是否在 schema 里、状态迁移是否合法，对不上的一律丢弃；④ 需求文档互相冲突时标记冲突交产品确认，不让模型自己选一个版本；⑤ 找不到依据的规则进人工确认队列，而不是默认正确。

执行通过≠测试有效：断言不能来自被测接口自己

自动化执行通过只说明「实际结果等于脚本预期」。如果预期是 AI 照接口响应反推出来的，就形成了「接口返回什么就断言什么」的同义反复。典型反例是创建接口返回 SUCCESS，脚本直接 assert status == "SUCCESS"，却没有验证数据是否真的写入、字段是否正确、重复提交是否产生两条、下游能否使用这条数据。

高价值用例至少要断言到业务结果、数据落库、状态变化和关键副作用四层：查 DB 或走后查询接口比对落库结果、用唯一索引外的业务键验证不重复、异步链路再断言消息已发送、消费者已处理、最终状态收敛。规则很简单——断言只允许引用需求或接口文档里写明的业务规则，禁止从本次响应生成预期。

灰度单节点缺陷：先确认流量落在哪，再比配置

顺序是：用请求 ID、trace ID、响应头或网关日志确认请求实际落到哪个节点；对比异常节点与正常节点的应用版本、配置项、环境变量、启动参数、依赖版本、容器镜像 digest；版本一致再查节点本地状态——本地缓存、临时文件、时区与系统时间、连接池、服务发现注册信息。常见根因不是代码不同，而是某节点读了旧配置、缓存了脏数据，或没正确连上依赖服务。

然后做二分定位：把异常节点摘出流量，问题随节点消失说明是实例状态问题；问题跟着用户或数据迁移到其他节点，说明是业务数据问题。为了可复现，可以在网关按请求头把同一请求固定路由到指定节点做差异对比。修完不能只验异常节点，还要复盘发布流程为什么没发现节点间不一致。

Kafka 遥测链路：测端到端，而不是只测消费端

按生产、传输、消费、存储、查询五段设计：设备上报是否进入正确 topic、分区键能否让同一设备落到同一分区（保证单设备有序）；生产者 acks 与幂等配置下消息是否重复或丢失；消费侧重点测重复消费的幂等（按 deviceId + 上报时间戳去重）、乱序与迟到数据的处理（事件时间 + 水位线）、消费堆积与 rebalance 期间的重复投递；最后校验落库结果与查询接口一致，并覆盖断点续传与补数场景。