外卖与出行系统测试面试题

本文档包含 18 道外卖与出行（O2O / LBS）系统方向的高频面试题，覆盖 LBS 定位与地图、商家/司机筛选与排序、下单链路、派单匹配算法、计价（含动态调价）、路线规划与导航、骑手/司机端管理、配送状态机、订单履约、安全保障、极端场景（大促/恶劣天气）、运营监控。出行类业务（美团、饿了么、滴滴、Uber、高德/百度地图）是一类对实时性、地理位置准确性、并发匹配能力要求极高的系统，是测试岗位的差异化方向。

一、LBS 基础与下单（4题）

Q1: O2O / LBS 系统的核心业务链路和分层架构？

答案：

O2O（Online to Offline，线上到线下）是把线上需求和线下服务连起来，外卖、打车、跑腿、家政都属于此类。LBS（Location Based Service，基于位置的服务）是 O2O 的核心技术能力，所有匹配、推荐、计价都依赖位置。

O2O 系统的核心特征：

强地理位置依赖。每个订单都和地理位置强绑定，定位偏差几百米就可能匹配错商家或司机。

实时性要求高。外卖要求 30 分钟内送达、打车要求几分钟接单，每个环节延迟都直接影响体验。

供需双边匹配。用户和商家/司机两端都要管理，需要高效的撮合算法。

多方协作。用户、商家、骑手、平台四方协作，任何一方出问题都影响订单。

线下不可控。骑手堵车、商家忙、餐厅出餐慢，线下因素影响线上履约。

测试视角下，每一层都有独特关注点：

LBS 服务。位置精度、位置上报频率、位置查询性能、跨城市边界处理。

派单调度。匹配算法的合理性、调度时延、多方公平性。

计价引擎。基础价、动态加价、优惠、改派后计价。

路线规划。导航准确、ETA 准确、避开拥堵。

骑手/司机端。位置上报、接单流程、配送状态机、收入计算。

外部依赖。第三方地图 API 的可用性、配额、计费。

测试时要把这张图打印贴墙上，每个箭头都对应一组用例。

Q2: LBS 定位测试要做哪些？精度和差异化怎么验证？

答案：

定位是 O2O 系统的"输入"，定位不准所有下游环节都白搭。定位测试需要覆盖各种定位源、各种环境、各种异常。

定位源（按精度排序）：

GPS / GNSS。卫星定位，室外精度 5~10 米。北斗、GPS、伽利略、GLONASS 等多卫星系统融合更准。

WiFi 定位。基于已知 WiFi 接入点位置，精度 20~50 米，室内可用。

基站定位。基于手机连接的基站位置，精度 100~1000 米，最不准但最可靠。

蓝牙 Beacon。商场、机场等场景，精度 1~5 米。

视觉 SLAM。摄像头识别环境特征，AR 导航场景用。

惯性导航。陀螺仪、加速度计推算位置变化，用于隧道、地下等 GPS 失效场景。

测试维度：

精度。

室外开阔环境（公园、广场）：GPS 应能稳定 < 10 米。

城市街道：5~20 米。

高楼夹缝（CBD）：可能漂移到 50~100 米。

室内（商场、地铁）：依赖 WiFi 或 Beacon，精度差。

地下车库：基本无信号，依赖惯性导航。

要建立标准测试地点集，覆盖各种环境。

定位时延。

冷启动（APP 首次打开）：拿到首个定位的时长，目标 < 5 秒。

热启动：< 1 秒。

辅助定位（A-GPS）：用基站信息辅助，加快冷启动。

定位频率。

后台定位：节电要求下减少频率（如每分钟 1 次）。

前台定位：实时定位（如每秒 1 次），用于司机导航场景。

异常处理。

定位失败：弹出"开启定位"引导。

定位超时：用上次缓存位置兜底。

定位不准：用户可手动修正。

漂移。GPS 偶尔会"跳变"（突然位移几公里），要测算法是否能识别和过滤。

跨平台差异。

iOS：定位授权（一次、使用期间、始终允许）的处理。

Android：各厂商定制系统的定位行为差异（华为、小米、OPPO 后台限制更严）。

权限管理。

权限引导。第一次使用引导用户开启定位权限。

权限被拒绝的兜底。手动输入地址或选择最近商圈。

权限变化感知。用户在系统设置里关闭权限后，APP 内能及时感知并提示。

工具：

模拟定位。Android 开发者模式可模拟任意位置（用于测试不同城市、不同地点）。

iOS Xcode 模拟器支持定位模拟、轨迹回放。

字节自研定位测试工具，模拟各种弱信号场景。

定位测试是 O2O 测试的"基本功"，建议建立专项实验室，配备真实环境（室内外、各种设备、各种网络）持续监控。

Q3: 商家/司机列表搜索和排序怎么测？

答案：

用户打开外卖 APP 看到的"附近商家"列表、打开打车 APP 看到的"附近司机数"、地图 APP 搜索"附近 ATM"，本质都是 LBS 检索 + 排序。

LBS 检索机制：

地理空间索引。常用 GeoHash、R-Tree、四叉树等空间索引算法，把二维坐标转换成可索引的字符串/数值。Redis 的 GEO 命令也是基于 GeoHash。

距离计算。Haversine 公式（球面距离），考虑地球曲率。短距离也可用平面距离近似计算。

筛选半径。一般几公里内（外卖 5km、打车几百米），超出范围不展示。

测试维度：

距离精度。

两个已知坐标点的距离计算结果，和地图工具（高德、Google Maps）对比应一致。

跨城市边界、跨国境（涉及不同坐标系，如 WGS84 vs GCJ-02）的距离计算。

南北半球、跨赤道、跨日界线的边界处理。

检索范围。

按用户当前位置检索 5km 内商家，要测半径准确（4.9km 内的应包括，5.1km 不应包括）。

切换城市后是否按新城市检索。

跨城市边界（如北京南六环外）的检索行为。

检索性能。

万级商家场景下检索响应时间（一般 < 100ms）。

百万级司机场景下的实时位置检索（这是滴滴、Uber 的核心挑战）。

排序策略。多维度排序：

距离。最直观的排序方式。

预估送达时间。考虑距离 + 商家出餐速度 + 路线拥堵。

销量。热门商家优先。

评分。高评分商家优先。

广告位。付费推广位插入。

个性化推荐。基于用户历史订单的偏好。

每个维度的权重和组合方式都要测。

特殊场景。

新用户首单。可能有"首单优惠"商家加权。

时段差异。中午、晚上、夜宵时段排序权重不同。

天气影响。下雨天可能减少"远距离"商家曝光。

地理位置敏感。住在某商圈的用户优先看商圈内商家。

筛选与组合。

按品类筛选（中餐、西餐、奶茶）。

按价位筛选（低、中、高）。

按配送方式筛选（专送、商家自配）。

按优惠筛选（满减、券）。

筛选条件组合后的排序逻辑。

实时性。

商家状态变化（打烊、爆单）后多久从列表移除。

新增商家入网后多久能被检索到。

测试时建议建立"标准检索场景集"，覆盖各种地点、时段、品类组合，定期回归。

Q4: 外卖下单和打车下单的差异？测试要点？

答案：

虽然都叫"下单"，外卖下单和打车下单在业务模型、状态机、关键路径上差异巨大。

外卖下单关键路径：

挑选商家 → 选商品入购物车 → 选地址 → 选配送方式 → 选优惠 → 提交订单 → 支付 → 等待商家接单 → 等待出餐 → 等待骑手配送 → 送达。

打车下单关键路径：

输入起终点 → 选车型 → 预估价 → 呼叫司机 → 等待司机接单 → 司机前往起点 → 上车 → 行驶 → 到达终点 → 支付。

外卖下单测试要点：

购物车。多商家不能混合下单（一般每个订单只能一个商家）、商品库存检查、商品价格变更后是否同步购物车。

地址。

常用地址管理。

地址精度（小区、楼栋、单元、门牌号）。

特殊地点（学校、公司、医院、商场）的引导。

跨配送范围（用户在 A 商圈，地址在 B 商圈不在配送范围）。

配送方式。平台专送（骑手）vs 商家自配。配送费、时效不同。

优惠组合。商家券 + 平台券 + 满减 + 红包（详见电商章节 24-Q8）。

下单时段。

营业时间内。

预订单（非营业时段下单，到点出餐）。

商家爆单时的处理（拒单、延长出餐时间、关闭下单）。

支付。

支付方式（微信、支付宝、银行卡、余额）。

支付超时（一般 10~15 分钟未支付订单关闭）。

支付后状态机变更（详见 Q11）。

打车下单测试要点：

起终点。

定位起点（默认当前位置，可手动调整）。

输入终点（搜索、收藏地址、地图选点）。

起终点过近（< 100 米）的拒绝。

起终点过远（跨城市）的特殊处理。

车型。

经济型、舒适型、商务型、豪华型，每种价格和体验不同。

新能源、传统燃油车的选择（部分城市有限行）。

特殊车型（轮椅可达、宠物友好）。

预估价。

显示估算价格区间（一般 ±20%）。

实际价格按里程 + 时长 + 调价系数计算（详见 Q7）。

呼叫机制。

平台派单 vs 用户抢单。

附近司机数显示（让用户有预期）。

无车辆响应的等待时长和兜底。

预约单。

预约几小时后的车，要确认司机能在约定时间到达。

预约单怎么调度（提前 30 分钟开始派单）。

支付。

行程结束后自动扣款（绑定支付方式）。

异常支付（司机调价、用户拒付）的处理。

发票申请。

差异总结：

外卖订单是"商家驱动"（用户下单后等商家接受）；打车订单是"司机响应"（用户呼叫后等司机抢单）。

外卖订单状态相对线性（接单 → 出餐 → 配送 → 送达）；打车订单更动态（司机可能改派、用户可能改终点）。

外卖订单平均 30~60 分钟完成；打车订单 10~30 分钟。

测试时要按各自业务模型建独立用例集，不要套用同一套模板。

二、派单匹配与计价（5题）

Q5: 派单算法怎么测？

答案：

派单（订单与骑手/司机的匹配）是 O2O 系统的核心算法，决定了用户等待时长、骑手收入、平台 GMV，是高度优化的领域。

派单模式：

抢单模式。订单广播给周围多个骑手/司机，谁先抢到归谁。优点：响应快、骑手主动性高。缺点：可能没人抢、远的骑手抢到导致超时。

指派模式。系统按算法把订单指派给最合适的骑手/司机。优点：调度全局最优。缺点：被指派的可能不愿意接，需要拒单机制。

混合模式。先抢单几秒，没抢到就指派。多数平台采用。

派单算法考虑因素：

距离。骑手/司机离订单起点距离。

方向。是否顺路（特别是出行场景，避免逆向接单）。

时长。骑手当前订单的预计完成时间 + 新订单时间。

骑手能力。承载量（外卖一次最多带 3~5 单）、车型匹配（小车不能接大件订单）。

历史表现。骑手响应率、完成率、评分高的优先派。

收入公平性。要给所有骑手合理的单量，不能集中给"明星骑手"。

商业利益。某些 VIP 商家或活动订单优先派给优质骑手。

测试维度：

派单准确性。

按预设场景（用户位置 + 周围骑手分布）输入，断言算法选出的骑手符合预期。

要建"标准派单场景集"覆盖各种分布。

派单时延。

抢单模式：广播延迟 + 抢单等待时间。

指派模式：指派决策延迟（一般 < 1 秒）。

派单成功率。

订单 5 分钟内成功匹配到骑手的比例。

未匹配的兜底（扩大半径、降低门槛、提示用户加价）。

公平性。

骑手单量分布是否合理（不能 80% 单量给 20% 骑手）。

新骑手是否能获得合理单量。

各时段、各区域的骑手收入是否均衡。

特殊场景。

爆单（高峰期）：算法是否能优先派给空闲骑手、是否会大量延误。

骑手不足（恶劣天气）：算法是否提示用户加价、是否扩大派单半径。

骑手过剩（深夜）：算法是否合理分配避免"空跑"。

跨区订单：用户在 A 区下单地址在 B 区，跨区配送如何处理。

异常路径。

骑手接单后拒单。要测拒单机制（强制拒单、惩罚机制）、订单重新派单。

骑手接单后失联（手机没电、网络断）。要测系统识别和重派。

订单改派（用户改地址、商家延迟出餐换骑手）。

监控大盘。

各区域、各时段的派单成功率、平均接单时长、骑手分布。

异常告警（某区域派单失败率突增）。

派单是 O2O 系统的"心脏"，测试同学要联动算法、运营、骑手运营一起维护这套系统，每次算法变更都要 A/B 实验。

Q6: 司乘匹配在高峰、雨天、机场、夜间等场景下怎么测？

答案：

打车的匹配挑战在不同场景下千差万别。同一个算法在不同场景下表现可能截然不同，需要建立"场景化测试"体系。

高峰场景（早晚高峰）：

特点。用户需求暴涨（早高峰 8~9 点、晚高峰 18~20 点）、司机供给相对不足、道路拥堵。

测试要点。

需求突增能否快速调度更多司机（实时调价、调度算法激励司机接单）。

派单半径扩大策略（平时 1km 内，高峰扩到 3~5km）。

预估等待时间准确性（用户能否提前知道大概等多久）。

排队机制（用户队列、按下单时间优先派单）。

是否会有大量"打不到车"的情况（要保证基础供给）。

雨天/雪天场景：

特点。需求激增（步行/骑车的人都打车）、司机不愿出车（路况差、风险高）、道路通行慢。

测试要点。

雨天动态加价（鼓励司机出车），加价幅度的合理性。

雨天派单半径策略调整。

是否禁用某些服务（如顺风车在恶劣天气下不可用）。

接送时长预估的调整（要考虑天气因素）。

机场场景：

特点。机场出发的乘客有航班时间限制（不能错过登机）；机场接机的乘客需要司机准时到达。

测试要点。

机场停车排队。机场有"网约车蓄车池"，司机按到达顺序排队，要测排队算法。

航班延误识别。接机用户输入航班号后，系统能否自动延迟派单时间（如航班晚点 1 小时，派单时间相应推迟）。

机场接机的高峰应对（如春运、节假日）。

机场出发的应急（错过航班的责任划分）。

夜间场景：

特点。需求低（深夜出行少）、司机少（很多司机回家）、安全风险高（醉酒乘客、女性独自出行）。

测试要点。

夜间最低供给保障。

夜间安全保障（行程录音、紧急联系人、安全中心）。

夜间长途订单的特殊调度（如凌晨打车去机场，要保证有司机响应）。

夜间加价机制。

特殊场景：

紧急场景。送医、紧急赶飞机等用户标注紧急时，优先派单。

群体行程。一群人一起打车（如团建、聚会结束），是否支持一键叫多辆车。

跨城订单。从北京到天津的长途，派单算法和计价规则都不同。

包车订单。包车几小时，算法和派单规则特殊。

测试方法：

场景库。建立"标准场景库"，覆盖以上各种场景，每次算法升级跑场景库回归。

A/B 实验。新算法或新策略上线灰度，对比效果。

仿真测试。用历史真实数据回放或仿真生成数据，验证算法表现。

线上监控。各场景的关键指标（派单成功率、等待时长、用户体验评分）实时监控。

司乘匹配测试是个长期工作，每个新场景都是新挑战，要建立持续改进的机制。

Q7: 计价规则怎么测？动态加价怎么测？

答案：

计价是 O2O 系统最容易引起用户投诉和资损的环节。要把每个收费项的规则、组合、边界都覆盖。

外卖计价构成：

商品价。每个商品的单价 × 数量。

配送费。按距离阶梯计费（如 0~3km 5 元、3~5km 7 元）。

包装费。商家收的一次性包装费用。

满减优惠。"满 30 减 10"、"满 50 减 20"等。

优惠券。平台券、商家券（详见电商章节 24-Q8）。

红包。新用户红包、活动红包。

服务费。部分订单收平台服务费。

打车计价构成：

起步价。前 X 公里或 Y 分钟的基础价。

里程费。按公里数计算。

时长费。按分钟数计算（考虑堵车）。

调价系数。动态加价 1.0x~3.0x（详见下文）。

夜间费。22:00~05:00 收夜间费。

跨城费。超出城市边界的额外费用。

机场服务费。机场进出收服务费。

通行费。高速、桥隧费用按实报销或转嫁。

调度费。司机距离用户远时收调度费。

测试维度：

基础计价正确。

每个项目按规则计算。

不同里程、时长、时段的组合。

边界值（如 3.0km 算 0~3km 还是 3~5km 档位）。

精度（详见支付章节 26-Q11，金额精度要严谨）。

动态加价。

加价时机。供需失衡时自动加价（早晚高峰、恶劣天气、大型活动散场）。

加价幅度。一般 1.2x~3.0x，过高会引发用户投诉和监管关注。

加价透明。用户呼叫时明确显示加价系数和原因。

加价上限。监管要求不能无限加价，平台要有自动限制。

加价是否生效需测试：用户接受加价后下单成功率、加价后司机接单率、加价对用户体验的影响。

时段差异。

工作日 vs 周末。

平时 vs 节假日（春节、五一、十一）。

凌晨 vs 白天 vs 夜间。

每种时段都要单独测计价。

异常路径。

订单中改终点（绕路、临时改地址）的计价。

司机绕远路（计价多算了里程）的用户投诉和退款。

订单中断（系统故障、司机离开）的计价处理。

订单完成后用户反馈"路线不对"的退款机制。

跨城/跨国。

跨城打车的计价方式（按城市分段 vs 全程统一）。

跨国（如境外打车）的汇率换算。

合规：

明码标价。每项收费要在订单前明示，不能事后加价。

发票要求。开发票时项目要全、金额要对。

监管报送（部分城市要求出租车计价数据报送）。

退款。

订单异常退款的计算（如骑手未送达、商家未出餐）。

部分退款的计算（取消其中一个商品）。

退款金额必须 ≤ 已付金额。

实战中"价格异议"是 O2O 投诉的大头，测试同学要做到"每个收费项可解释、每个金额可追溯"。

Q8: 路线规划和导航怎么测？

答案：

路线规划是导航和派单的基础能力，影响骑手送达时间、司机接单方向、用户预估时长。多数平台都集成第三方地图 API（高德、百度、腾讯、Google），测试同学要懂如何评估和集成测试。

路线规划要素：

起终点。两个坐标点。

避让条件。避开拥堵、避开收费、避开高速、避开渡轮。

车型。小车 vs 大车，部分道路对车型有限制。

时段。早晚高峰路线可能不同（避开拥堵）。

实时路况。当前道路通行情况（拥堵、事故、施工）。

测试维度：

路径合理性。

最短路径 vs 最快路径 vs 最优路径，每种规划目标都要测。

避开违章、限行、单行道。

考虑交通管制（赛事、活动期间）。

ETA（预计到达时间）准确性。

ETA 误差。理想 ±10%，差的 ±50%。

不同时段、路况下的 ETA 准确率。

ETA 影响业务：派单（用户等待预期）、骑手考核（超时扣款）、调度（顺路接单）。

实时调整。

路上遇到拥堵自动重新规划路线。

司机偏离原路线后是否能识别并重新规划。

到达终点前 N 米提前提示。

各种导航场景。

步行导航。骑手取餐用，要走人行道、避开机动车道。

骑行导航。共享单车、骑手送餐用，走非机动车道、考虑禁骑路段。

驾车导航。司机用，要考虑车型、限行、违章拍照点。

地铁导航。换乘方案、时刻表、票价。

公交导航。线路、班次、步行换乘距离。

骑手送餐特殊场景。

园区/学校/医院内部导航。许多场景 GPS 不准，要靠用户标注门牌号。

封闭社区/小区门禁。骑手能否进、什么时间能进、需不需要登记。

楼层导航。送到几楼几号房（部分送到楼下）。

异常路径。

地图数据陈旧。新修的路、新开的小区可能在地图上找不到，要测兜底。

GPS 漂移导致路线规划异常（如把骑手定位到马路对面、规划路线绕一大圈）。

第三方 API 故障。降级到本地缓存路线、提示用户。

工具：

模拟轨迹。用脚本模拟骑手/司机的行进轨迹，测算法表现。

真实路测。重要路线（机场、火车站、商圈、医院）专门派人真实测试。

A/B 实验。新算法和旧算法对比，比较 ETA 准确率、用户满意度。

第三方对比。和高德、百度、Google 等地图工具的路线对比，定位差异。

实战中地图能力是个长期投入领域，多数平台买第三方 API 比自建更划算。测试同学要懂集成和评估，关注上游 API 的更新和影响。

Q9: 异常订单怎么处理？取消、改派、超时未接单的测试要点？

答案：

O2O 系统的"快乐路径"只占 70%~80%，剩下 20%~30% 是各种异常。异常订单处理体现产品的成熟度，是测试同学的重点关注。

订单取消：

用户取消。

未匹配时。用户可随时取消，无费用。

已匹配未接单。可能扣少量违约金（外卖 0 元、打车几元）。

骑手/司机已出发但未到达。扣较多违约金。

完成后取消。一般不支持，按售后处理。

商家取消。

接单后发现没库存或要打烊。要补偿用户（红包、优惠券）。

商家长期高拒单率的处罚。

骑手/司机取消。

接单后又不想接（家里有事、车坏了）。按规则扣分或扣钱。

频繁取消的处罚（封号、停接）。

平台取消。

风控触发（用户/骑手疑似作弊）。

系统故障。

监管要求（如恶劣天气暂停服务）。

测试要点。

取消按钮的可见性和文案。

取消原因选择。

取消费用计算。

取消后状态机变更（详见 Q11）。

取消通知（推送给对方）。

订单改派：

什么时候改派。

骑手长时间不接（用户主动改派）。

骑手意外（车坏、生病、家事）。

骑手位置异常（长时间不动、远离起点）。

商家延迟出餐导致原骑手已接其他单。

改派流程。

平台自动改派 vs 用户主动申请。

新骑手的派单算法和原派单一致。

改派后用户感知（新骑手姓名、车牌、距离）。

改派费用归谁（一般平台兜底）。

测试要点。

改派触发条件。

改派后的订单状态正确流转。

改派次数限制（防滥用）。

改派后的计费、配送时效不变。

超时未接单：

外卖。

用户下单后 N 分钟商家未接单：自动取消订单 + 退款 + 给用户红包。

商家接单后 N 分钟未出餐：提醒用户、给券或允许退款。

骑手接单后 N 分钟未到店：提醒用户、自动改派。

骑手取餐后 N 分钟未送达：提醒用户、可能补偿。

打车。

用户呼叫后 N 分钟无司机响应：提醒用户、自动加价、扩大范围。

司机接单后 N 分钟未到上车点：提醒用户、可改派。

各种"N 分钟"的具体值要按业务规则测，每个超时都要触发对应行为。

测试方法：

异常场景库。建立"标准异常场景库"，覆盖各种取消、改派、超时组合。

自动化用例。把异常路径做成自动化用例，每个新版本回归。

线上巡检。监控异常订单比例，超过阈值告警（如取消率突然飙升说明系统或运营出问题）。

异常订单的体验直接影响用户对平台的信任，测试同学要在产品设计阶段就参与，确保每个异常都有合理预案。

三、骑手/司机端与配送状态机（4题）

Q10: 骑手/司机端的接单流程怎么测？

答案：

骑手/司机端 APP 是 O2O 系统的"另一半"，承载着接单、导航、收入计算等核心功能，测试要把它当作独立产品对待。

接单流程：

订单推送。新订单按算法（详见 Q5）推送给候选骑手/司机。

通知方式。

APP 内弹窗 + 声音 + 振动。

后台时通过厂商通道推送。

骑手 APP 在后台也要保持可接收（依赖长连接）。

抢单/指派。

抢单：骑手点击"抢单"按钮，先到先得。

指派：系统直接指派给骑手，骑手可拒（按规则可能扣分）。

接单后操作。

外卖：导航到店 → 到店 → 取餐 → 送达。

打车：导航到上车点 → 等乘客 → 上车 → 行驶 → 到达。

测试维度：

订单推送。

正确性。订单按算法推送给候选人，不漏不错推。

时效。推送延迟（一般 < 1 秒）。

弱网下的推送（厂商通道兜底）。

骑手开振动/勿扰模式下的提示。

抢单/接单。

抢单按钮的响应时间（要快，不然抢不到）。

并发抢单的公平性（先到先得，不能因为网络快慢造成不公）。

拒单机制。允许拒单的次数上限、拒单原因选择、拒单后惩罚。

订单详情。

订单信息完整。商品/起点/终点、用户备注、特殊说明（如"放门口""不要香菜"）。

用户/商家联系方式（一般用平台中转电话保护隐私）。

订单金额、配送费、预计收入。

配送过程。

状态变更（详见 Q11）。

每个状态的操作按钮（如"到店"按钮）和确认机制（防误操作）。

异常上报。商家爆单、用户联系不上、商品有问题，要有反馈渠道。

完成订单。

完成后立即结算（如完成订单 5 元配送费立即入账）。

完成后接下一单（连续单优化）。

用户评价后是否影响骑手收入。

骑手特定功能：

多单同时接（外卖骑手一般同时带 3~5 单）。

顺路单识别（同方向订单合并配送）。

休息状态。骑手主动设置"暂停接单"。

收入查看。日收入、周收入、月收入。

订单历史。查询已完成订单。

司机特定功能：

车辆信息绑定（车牌、车型、颜色）。

行驶证、驾驶证有效期监控（到期前提醒）。

收车（结束今日营运）。

异地接单/还车（专车业务）。

测试方法：

真机测试。骑手/司机端必须在真机上测，模拟器不能反映网络、定位、电量等真实情况。

实地测试。安排测试同学跑外卖/接乘客，亲身体验流程。

弱网测试。隧道、地下停车场、电梯等场景的接单和配送。

设备多样性。不同 Android 版本、不同厂商手机（特别是华为、小米的后台管理严格）。

骑手/司机端的体验直接影响他们的工作效率和收入，骑手/司机不满意会通过低接单率影响平台运营，测试同学要重视。

Q11: 配送状态机怎么测？

答案：

外卖和打车订单的状态机比电商订单更复杂，因为涉及商家、骑手、用户、平台四方，每个状态变更都要联动多方。

外卖订单状态机：

打车订单状态机：

测试维度：

合法迁移。每条箭头对应一组用例，验证状态变更触发条件、副作用、通知。

非法迁移。每个状态尝试触发不允许的操作，断言被拒。

并发迁移。多个事件同时到达（如骑手在用户取消的同时点送达），原子推进保证最终状态唯一。

副作用。每个状态变更触发：

通知（推送给用户/商家/骑手）。

记录日志（操作时间、操作人、变更原因）。

业务联动（如商家接单后通知骑手、骑手取餐后开始计时）。

数据更新（订单表、骑手状态表、统计表）。

异常路径。

状态变更失败的回滚。

回调乱序（如送达通知比取餐通知先到）。

骑手位置异常（10 分钟没移动，自动改派或告警）。

状态机的"灰色"场景：

商家说做好了但骑手说没拿到（取餐分歧）。

骑手说送了但用户说没收到（送达分歧）。

司机说乘客没上车但乘客说上了（上车分歧）。

这些场景需要业务规则裁决（一般以平台流水时间为准），要测兜底和申诉流程。

监控。

订单状态分布大盘（实时多少订单在什么状态）。

异常订单监控（卡在某状态过久的订单）。

各状态平均耗时（接单时长、取餐时长、送达时长）。

测试时强烈建议引入"订单状态机一致性巡检"脚本，定期扫数据库对比订单状态和实际行为，发现 Bug 早。这是 O2O 系统的"健康度晴雨表"。

Q12: 骑手位置上报和轨迹回放怎么测？

答案：

骑手实时位置是 O2O 系统的核心数据，影响用户体验（看到骑手在路上）、平台调度（动态派单）、骑手考核（轨迹分析）、安全保障（轨迹追踪）。

位置上报机制：

上报频率。

骑手有订单时：高频（如每 3~5 秒一次）。

骑手空闲时：低频（如每 30 秒一次）。

骑手休息时：极低频或不上报。

按时段调整：高峰期高频、夜间低频。

上报方式。

主动上报（APP 定时上报）。

被动查询（系统按需查询）。

混合（活跃时主动，静止时被动）。

上报内容。

经纬度。

精度（GPS、WiFi、基站）。

速度。

方向。

时间戳。

电量（影响后续上报频率决策）。

测试维度：

上报频率。

不同业务状态下的频率是否符合配置。

频率切换（接单时立即切到高频）。

电量低时自动降低频率。

后台限制下的频率（iOS、Android 各厂商后台限制不同，要专门测）。

位置准确性。

定位精度（详见 Q2）。

异常位置过滤。

GPS 漂移（突然位移几公里）。

跨越河流、海洋等不可能位置。

零点（0,0）异常上报。

数据流。

上报延迟。从骑手位置变化到平台收到的时长（一般 < 5 秒）。

数据传输可靠性。弱网下的重传、丢失处理。

存储性能。海量骑手实时位置写入和查询的性能。

跨城市切换。

骑手跨城市后位置上报是否还能正常工作。

跨城市的派单和数据归属。

后端处理。

实时位置缓存。Redis GEO 命令或自研空间索引。

历史轨迹存储。HBase、ClickHouse、TimescaleDB 等时序数据库。

数据清理。历史轨迹按合规要求保留（外卖一般 30 天，打车 1 年）。

轨迹回放：

用途。

订单争议时回放骑手是否按预期路线送达。

骑手考核（路线效率、是否绕路）。

安全保障（行程中异常情况追溯）。

监管要求（特定订单的全程可追溯）。

测试要点。

轨迹完整性。骑手送一单的完整轨迹应能完整回放。

时间轴对齐。轨迹点的时间戳和实际行进时间一致。

回放控制。能暂停、加速、回退、跳到某时间点。

地图展示。轨迹在地图上正确绘制，沿着真实道路（不能横穿建筑）。

性能。长时间订单（如几小时的打车）的轨迹回放不应卡顿。

权限。普通用户能看自己订单的轨迹，骑手能看自己的轨迹，运营能看所有，监管按需提供。

异常场景：

骑手手机没电或离线。位置上报中断的处理。

骑手关闭定位权限。系统提示和引导。

骑手用模拟器定位（作弊）。要检测异常位置模式（如瞬间移动、不可能的速度）。

骑手主动作弊（用其他设备替代真实位置）。结合多源数据（WiFi、基站、行为模式）识别。

实际项目里位置数据是 O2O 系统最大的数据存储（外卖一天产生几亿位置点），测试同学要懂海量数据下的性能、成本、合规权衡。

Q13: 骑手/司机收入计算和结算怎么测？

答案：

骑手/司机的收入计算关系到 ta 们的切身利益，错算少算引发投诉甚至维权，是 P0 级 Bug。要把每个收入项的规则和组合覆盖到位。

外卖骑手收入构成：

基础送单费。每单根据距离、时段、品类计算。

奖励。

跑量奖励（送 50 单奖 100 元）。

时段奖励（午高峰、晚高峰、夜宵单价更高）。

恶劣天气奖励（雨雪、高温等。

冲量奖励（周完成 X 单额外奖 Y 元）。

补贴。商家补贴、平台补贴。

罚款。

超时罚款（每超 N 分钟扣 X 元）。

差评罚款（顾客差评扣 X 元）。

投诉罚款。

违规罚款（送错餐、未戴头盔、违章）。

打车司机收入构成：

行程费。基础价 + 里程费 + 时长费（详见 Q7）。

奖励。

完单奖（每天完成 N 单奖 X 元）。

时段奖（高峰、夜间）。

新司机奖（前 30 天双倍）。

调价系数（高峰加价时司机分成更多）。

平台抽成。一般 10%~25%（合规要求公开抽成比例）。

罚款。

差评、投诉。

拒单（接单后又取消）。

行为违规（绕路、宰客）。

测试维度：

基础费用计算。

每单按规则计算，金额精度严谨（详见 26-Q11）。

边界值（如距离 3.0km 算 3km 还是 3.01km）。

不同时段、不同品类的差异化定价。

奖励发放。

奖励触发条件。

奖励金额。

奖励到账时间（一般实时入余额或当日结算）。

奖励是否累积（如月度跑量奖励）。

罚款。

罚款触发条件。

罚款金额（要在 SOP 范围内）。

罚款申诉（被冤罚的可申诉）。

罚款上限（防止单次罚款过高）。

结算时效。

实时结算（部分平台每完成一单立即入余额）。

T+1 结算（多数平台次日 1 点出账）。

提现到账（用户提现到银行卡的时效）。

异常处理。

订单状态异常（卡在某状态）时收入如何计算。

订单退款时已发放奖励是否扣回。

骑手作弊（刷单、虚假定位）被发现的清算。

公平性。

不同区域、时段的收入差异是否合理。

新老骑手的奖励差异（新人激励政策）。

是否存在算法歧视（某类骑手系统性收入低）。

合规与监管：

收入公开。骑手能在 APP 内清楚看到每单收入构成。

社保和保险。部分平台为骑手买意外险，要测保险触发条件。

监管报送。骑手收入数据按要求报送。

测试方法：

数据回归。每天对账骑手收入：系统计算 = 各项规则按订单数据计算。

抽样审计。每周抽样几个骑手的当周收入，按规则人工核对。

申诉处理。建立骑手收入异议的快速响应机制（一般 24 小时内反馈）。

实战中骑手收入的最大隐患是"规则变更后算法没同步"或"边界场景算错"，建议把每条规则变更都做成自动化用例长期回归。

四、用户体验、安全与运营（5题）

Q14: 司机评级、违规和封禁机制怎么测？

答案：

司机管理是出行平台的核心治理环节，关系到用户安全和服务质量。要建立"激励 + 约束 + 退出"完整体系。

司机评级体系：

服务分。综合各项指标的总分（一般 0~100 或 0~5 星）。

子项分。

订单完成率。

接单响应率。

用户评分均值。

差评率。

投诉率。

迟到率。

每个子项有自己的权重。

测试要点。

评分计算公式准确。

历史评分随新订单实时更新。

评分变化趋势可查询（司机能看到自己的成长）。

不同业务（专车、快车、顺风车）的评分体系是否独立。

司机违规：

轻度违规。

未戴头盔、未戴口罩。

车内异味、车况差。

接单后让乘客取消。

中度违规。

绕路、宰客。

接单后无理由取消。

接到非系统派的单（黑车行为）。

私下加价。

严重违规。

身份冒用（让别人替代驾驶）。

车辆冒用（用未注册车辆接单）。

性骚扰、暴力行为。

发生事故未上报。

测试要点。

违规识别。

用户举报触发。

系统识别（如行驶路线明显绕路、行程录音识别）。

监督员暗访。

违规处理。

警告。

减少接单（限流）。

冻结一段时间。

永久封禁。

违规申诉。

申诉提交（提供证据）。

审核反馈（48 小时内）。

申诉成功撤销处罚。

封禁机制：

封禁类型。

账号封禁（账号不能登录）。

身份证封禁（同一身份证不能注册）。

设备封禁（同一手机不能注册）。

车辆封禁（车辆不能用于网约车）。

封禁周期。

短期（几天到几周，行为改正后解封）。

长期（几个月，多次违规累计）。

永久（严重违法或多次永久违规）。

封禁解除。

到期自动解除。

申诉解除。

整改后申请解除（如完成培训、补充资料）。

测试要点。

封禁生效。

封禁后立即下线。

封禁期间不能接单、不能登录、不能注册新账号。

封禁通知（短信、APP 内通知）。

跨账号管理。

司机用多个身份证 / 手机号注册多个账号，封禁如何穿透。

车辆和司机的关联管理（一辆车多个司机）。

数据关联。

司机过去订单的金额是否冻结。

未结算的收入怎么处理（按规则部分或全部扣回）。

合规：

监管协同。严重违法（性骚扰、人身伤害）的处罚要联动公安。

申诉公开。处罚和申诉记录可监管查阅。

司机权益。处罚要有"程序正义"（明确规则、申诉渠道、合理时效）。

测试方法：

场景模拟。各种违规场景模拟，验证识别和处理。

数据巡检。每天扫描司机评分、违规数据，异常告警。

人工审核演练。模拟运营人工处理，验证流程可执行性。

司机管理是平台治理的核心能力，测试同学要保证"该处罚的处罚、不该处罚的保护、整个流程公开公正"。

Q15: 用户端订单跟踪、催单和投诉测试

答案：

订单履约过程中用户的"焦虑感"很强（外卖等饿了、打车等急了），订单跟踪、催单、投诉是缓解焦虑的关键环节。

订单跟踪：

实时状态展示。

外卖：商家接单 → 出餐 → 骑手已取餐 → 骑手在路上 → 即将送达 → 已送达。

打车：司机已接单 → 司机正在赶来 → 司机已到达 → 行程中 → 已到达终点。

骑手/司机位置。

地图上实时显示骑手/司机位置。

预计到达时间动态更新。

距离用户的距离实时显示。

预估送达时间。

下单时给出预估送达时间。

后续根据实际进度动态调整。

延迟时主动告知用户（如"商家出餐慢，预计延误 10 分钟"）。

骑手/司机信息。

姓名、头像、电话（一般用虚拟号保护隐私）。

车牌号、车型（打车）。

联系方式（IM 聊天）。

测试要点。

状态展示与后台一致（实时同步）。

地图渲染流畅（不卡、骑手图标不漂移）。

ETA 准确性（误差 ±20% 以内）。

各端一致性（APP、小程序、PC 看到的状态一致）。

催单：

催单触发条件。

订单超过预估时间但未送达。

订单卡在某状态过久。

用户主动催单。

催单方式。

APP 内催单按钮（频率限制，不能滥催）。

电话联系骑手/商家。

平台介入（运营协助）。

催单后处理。

骑手/商家收到催单通知（强提醒）。

骑手/商家给用户反馈（"还有 5 分钟到"）。

如果还是不送达，启动赔付流程。

测试要点。

催单按钮可见性和限制。

催单通知是否能到达。

催单后的状态变化和用户感知。

频次限制（防滥用）。

投诉与售后：

投诉类型。

外卖：缺餐漏餐、品质差、配送慢、骑手态度、商家拒单。

打车：绕路、宰客、司机态度差、车况差、安全事件。

投诉渠道。

APP 内提交（最常用）。

电话客服。

社交媒体（微博、小红书）反映。

监管投诉（市长热线 12345、12315）。

投诉处理流程。

平台首次响应（一般 1 小时内）。

调查取证（订单数据、行程录音、IM 聊天）。

裁决（平台 / 商家 / 骑手 / 用户责任划分）。

赔付（红包、优惠券、现金赔偿）。

申诉（被处罚方可申诉）。

测试要点。

投诉提交流程顺畅，证据上传方便。

投诉受理及时（不能让用户等几天没回复）。

调查取证完整（所有相关数据都能调出）。

赔付到账及时。

申诉机制有效。

监管联动。

监管投诉的优先级最高（影响平台口碑和评级）。

监管报送数据准确。

测试方法：

全流程模拟。从下单到投诉的完整闭环，覆盖各种异常。

客服测试。客服后台的功能（查订单、查行程、退款、客户标签）。

数据指标。投诉率、处理时效、赔付率、满意度。

实战中投诉处理质量是平台口碑的核心指标，测试同学要把"用户体验"贯穿到每一步，发现问题早，处理果断。

Q16: 出行安全保障体系怎么测？

答案：

出行安全是用户最关心的问题之一，特别是女性独自打车、夜间出行等敏感场景。平台必须建立完整的安全保障体系。

事前防护测试：

司机审核。

身份证有效性核查（联网公安系统）。

驾照真伪、有效期。

驾龄要求（一般 ≥ 3 年）。

无犯罪记录证明。

测试要点：各种异常情况（身份证过期、驾照吊销、有犯罪记录）的拒绝逻辑。

车辆审核。

行驶证、保险有效期。

车辆年检通过。

车型、排量、车龄符合标准。

测试要点：到期前提醒、过期后限制接单。

人脸识别上岗。

每次出车前人脸识别比对，防止账号被他人使用。

测试要点：识别准确率、夜间/暗光识别、口罩识别。

定期培训。

新司机入职培训。

定期合规培训（每月、每季度）。

完成培训才能继续接单。

事中监控测试：

行程录音。

全程录音（一般在用户上车后自动开启）。

录音存储在云端（不留本地，防篡改）。

录音权限严格（仅安全事件时由授权人员调阅）。

异常识别（如骂人、求救声音）触发告警。

测试要点：录音正常采集、上传、存储、不可篡改、合规权限控制。

实时定位监控。

司机和乘客位置都实时上报。

偏离规划路线超过阈值时告警。

长时间停留告警。

异常行驶速度（超速、零速度）告警。

测试要点：阈值合理、告警及时、告警送达指定人员。

紧急按钮 SOS。

APP 内显眼位置的紧急按钮。

按下后立即录音、位置上报、通知紧急联系人。

可直接拨打 110。

测试要点：按钮可见性、误触防护（如长按 3 秒确认）、信息送达完整。

行程分享。

用户可一键分享行程给指定联系人。

联系人能实时看到位置、车牌、司机信息。

到达后自动结束分享。

测试要点：分享链接可访问、信息实时、隐私保护。

事后响应测试：

7x24 安全客服。

电话客服（专用安全热线）。

APP 内安全求助入口。

响应时效（紧急情况秒级响应）。

公安联动。

平台与公安、120 等机构对接，紧急时一键报警。

数据共享（按规定共享司机信息、行程信息）。

事件调查。

事件发生后调取全程数据（行程、录音、聊天、定位）。

平台介入责任判定。

赔付流程（按平台保险或自掏腰包）。

数据合规：

录音、定位、聊天等敏感数据按法规存储（一般 1~3 年）。

数据访问严格权限控制和审计。

涉及隐私的数据脱敏处理。

数据按需提供监管（公安、网信办）。

测试方法：

场景演练。模拟各类安全场景（迷路、车祸、不法行为）的完整响应链路。

红蓝对抗。红队模拟黑产或不法分子，蓝队检验防护能力。

合规审计。定期审计数据访问、保留、销毁的合规性。

应急演练。每月一次安全事件演练，检验团队响应能力。

安全是出行平台的"生命线"，做好了是隐形护城河，做不好是平台关停的导火索。测试同学要把安全测试作为最高优先级。

Q17: 大促和极端天气下的稳定性测试

答案：

O2O 业务的高峰场景（双 11 外卖、春节打车、台风外卖、节假日打车）流量可达平时的几倍，对系统稳定性是极大考验。

典型大促/极端场景：

外卖：双 11、618、节假日、世界杯、外卖节、寒冬促销。

打车：春运、五一/十一、跨年夜、台风/暴雨、大型演唱会/赛事散场。

这些场景的特点：

需求暴增。订单量短时间内飙升 3~5 倍。

供给紧张。骑手/司机数量增长慢于订单。

调度复杂。各种突发情况（如演唱会散场几万人同时呼叫）。

体验脆弱。用户对延迟、失败容忍度极低（饿了等不及、急着回家）。

稳定性测试维度：

容量评估。

预测大促订单量（基于历史数据 + 增长系数）。

预测峰值 QPS（订单提交、派单、位置查询等）。

按峰值的 1.5~2 倍准备资源容量。

全链路压测。

压测目标流量按预期峰值的 1.5 倍。

覆盖所有核心链路（下单、派单、计价、支付、配送）。

混合场景压测（多种业务同时高并发）。

线上影子库压测（不影响真实业务的全链路压测）。

降级演练。

每个核心功能要有降级开关。

降级方案：

派单算法简化（弃用复杂算法用最简）。

地图实时路况降级到静态路况。

实时调价降级到固定加价。

预估时间降级到粗略估算。

降级后用户体验可接受。

弹性扩容。

K8s 自动扩容（HPA）。

云上紧急资源（提前预订）。

扩容时延（要在分钟级响应）。

扩容后服务依然稳定。

故障预案。

每类典型故障（数据库主库挂、Redis 故障、地图 API 故障、推送通道故障）有详细 SOP。

应急联系人和决策权清晰。

定期演练（每月）。

特殊场景测试：

恶劣天气。

暴雨/暴雪。需求激增、供给减少、配送时长大幅延长。要测：

派单算法是否能应对（扩大半径、提高加价）。

预估时间是否动态调整。

是否启动应急预案（暂停某些区域、提高补贴吸引骑手）。

用户端是否提示天气影响。

高温/严寒。骑手安全保障（户外作业风险高），可能要暂停部分时段配送。

台风/地震。极端情况下平台暂停服务，要测暂停范围、用户通知、订单处理。

大型活动散场。

演唱会、球赛、跨年夜，散场后几万人同时呼叫打车。

要测：

调度算法在密集请求下的表现。

排队机制（让用户预估等待时间）。

引导用户到附近地点（不在原地堵车，挪到旁边路口）。

特殊路线规划（避开管制路段）。

监控大盘：

实时核心指标。订单量、成功率、平均接单时长、平均送达时长。

异常告警。任何指标突破阈值立即告警。

值班响应。安排专人 7x24 值班，分钟级响应。

实战经验：

提前演练。大促前 1~2 周做全链路压测和应急演练。

冗余设计。永远按预测峰值的 1.5~2 倍准备资源，不要"刚刚好"。

降级优先级。明确"什么功能必须保""什么可以牺牲"，决策快。

事后复盘。每次大促后必须复盘，沉淀经验给下次。

O2O 系统的稳定性是用户口碑的根基，测试同学要把"大促保障"作为重要工作来抓。

Q18: O2O 系统的核心数据指标和运营大盘怎么测？

答案：

O2O 系统的运营高度数据驱动，几十个核心指标决定每天的资源调配、激励发放、问题排查。数据准确性直接关系到业务决策。

核心数据指标分类：

订单指标。

订单量。日订单量、月订单量、年订单量。

订单结构。各品类、各时段、各区域、各价位的订单分布。

订单状态分布。多少在等接单、多少在配送、多少已完成。

订单成功率 = 完成订单数 / 提交订单数。

订单取消率 = 取消订单数 / 提交订单数。

时效指标。

平均接单时长（提交到匹配）。

平均配送时长（取餐到送达）。

平均行程时长（打车）。

ETA 准确率 = |预估时间 - 实际时间| / 实际时间。

超时率 = 超时订单数 / 完成订单数。

用户指标。

DAU / MAU。

新增用户。

留存率。

复购率（一段时间内多次下单的用户）。

人均单量（每用户每月订单数）。

骑手/司机指标。

注册量。

活跃量（当日有上线的）。

接单率 = 实际接单数 / 派单数。

完单率 = 完成订单数 / 接单数。

收入分布。

供需匹配指标。

需求供给比。订单数 / 骑手数。

爆单率。超过供给能力的订单比例。

冷区数。订单极少的区域（运营要重点开拓）。

热区数。订单极多的区域（要保证供给）。

商家指标（外卖）。

商家活跃度。

商家流水。

商家口碑（评分、差评率）。

新商家入网。

商家流失。

财务指标。

GMV（成交总额）。

平台佣金。

骑手/司机收入。

补贴成本。

净收入。

测试维度：

指标计算准确性。

公式正确。每个指标按定义计算，不能模糊。

数据源准确。从哪些埋点取数、是否实时、有无丢失。

去重和归因。同一行为不重复计算、归属正确。

实时性。

实时指标 vs T+1 指标的区分。

实时指标的延迟（一般 < 1 分钟）。

T+1 指标的稳定时间（一般凌晨 1~3 点出数据）。

异常监测。

阈值告警（如某区域成功率 < 80% 告警）。

异常检测（机器学习识别非阈值的异常模式）。

突发事件识别（如某商家突然爆单）。

权限。

不同角色看不同数据（运营、骑手运营、商家运营、财务）。

敏感数据脱敏。

跨大盘一致。

运营大盘、产品大盘、技术大盘的同一指标应一致。

和第三方报表（财务、合规）对账。

监管报送：

订单数据、价格数据、骑手数据按当地监管要求报送（一般 T+1）。

报送数据准确、完整、及时。

测试方法：

数据回归。每次大版本发布后重新计算关键历史日的数据，确认未变化。

埋点测试。每个新功能上线必须验证埋点正确（详见社交章节 28-Q18）。

抽样审计。每周抽样几个订单/用户/骑手，对照实际行为验证数据准确。

A/B 实验。实验组数据的隔离性和准确性。

实战中"数据看着对其实错"是常见隐患，测试同学要把数据看板当作"产品"对待，建立专门的回归用例和持续对账机制。

O2O 运营高度依赖数据，数据准确性 = 决策正确性 = 业务健康。测试同学是数据可信度的最后一道防线。