推荐订阅源

SINOZO自动化测试面试题20251225

第一部分：数据逻辑

场景设定：数据库存在两张核心业务表， 具体信息如下：

表名	字段	说明
t_ ad_launch（广告投放明细表）	投放ID、广告主ID、投放金额、投放时间、投放渠道	记录单条广告投放的核心信息
t_ advertiser_level（广告主等级表）	广告主ID、等级名称	等级分为普通/高级/VIP，关联广告主核心信息

1.1 SQL查询

题目 ：编写SQL查询2025年内 ，每个广告主等级中投放总额排名前3的广告主ID。

答：

WITH advertiser_total AS (

    SELECT

        a.广告主ID,

        l.等级名称,

        SUM(l.投放金额) AS total_amount

    FROM t_ad_launch l

    JOIN t_advertiser_level a ON l.广告主ID = a.广告主ID

    WHERE l.投放时间 BETWEEN '2025-01-01 00:00:00' AND '2025-12-31 23:59:59'

    GROUP BY a.广告主ID, l.等级名称),

ranked AS (

    SELECT

        广告主ID,

        等级名称,

        total_amount,

        ROW_NUMBER() OVER (PARTITION BY 等级名称 ORDER BY total_amount DESC) AS rk

    FROM advertiser_total)SELECT 等级名称, 广告主ID, total_amountFROM rankedWHERE rk <= 3;

1.2 数据一致性分析

题目 ： BI系统  当日广告投放总金额报表 ，前端展⽰值与数据库原始数据求和值不一致。从数据流转角度说出3个核心差您原因。

答：

1. 数据采集 / 写入延迟：原始数据已入库，但 BI 报表未刷新、未读取最新分区，导致统计口径不一致。
2. 计算逻辑差异：BI 报表做了去重、过滤、四舍五入、折扣 / 退款扣减等逻辑，数据库原始求和未做处理。
3. 数据链路丢失 / 重复：消息队列丢失数据、实时计算重复消费、ETL 清洗时数据被误删，导致两边行数 / 金额不一致。

第二部分： 自动化

场景设定：需通过自动化脚本保障广告投放核心数据统计的准确性与一致性， 完成数据校验工作。

2.2 自动化对比数据

题目 ：设计Python脚本实现广告投放金额自动对账校验A库与B库中t_ad_launch表的投放金额总和sum(cost) 是否一致

答：

python

运行

import pymysql

# 数据库配置

DB_A = {"host": "", "user": "", "password": "", "database": ""}

DB_B = {"host": "", "user": "", "password": "", "database": ""}

def get_sum(db_config):

    conn = pymysql.connect(**db_config)

    cursor = conn.cursor()

    cursor.execute("SELECT SUM(投放金额) FROM t_ad_launch")

    result = cursor.fetchone()[0] or 0

    cursor.close()

    conn.close()

    return result

sum_a = get_sum(DB_A)

sum_b = get_sum(DB_B)

print(f"A库总和：{sum_a}")print(f"B库总和：{sum_b}")

if abs(sum_a - sum_b) < 0.01:

    print("对账一致")else:

    print(f"对账不一致，差额：{abs(sum_a - sum_b)}")

2.3 自动化回归思路

题目 ：业务新增规则：按「广告主+投放渠道J  维度统计日/周/月投放总金额 ，结果落地至业务存储表。编写自动化回归脚本时 ，如何实现测试数据自动生成与 预期结果自动计算 ，避免手工编写固定数据？

答：

测试数据自动生成 + 预期结果自动计算

1. 测试数据自动生成
2. 用 Faker / 随机函数生成广告主 ID、投放渠道、投放时间、金额。
3. 按天 / 周 / 月生成多组数据，写入测试库t_ad_launch。
4. 固定种子保证数据可复现，支持批量插入。
5. 预期结果自动计算
6. 按广告主+投放渠道+时间维度分组，用 Python 做groupby.sum()。
7. 把计算结果存为预期 JSON / 字典，和业务表结果对比。
8. 支持日 / 周 / 月自动切换，自动对齐业务统计口径。
9. 执行流程清空测试表 → 生成数据 → 执行业务统计 → 自动算预期 → 断言对比。

第三部分： 系统理解

场景设定： 系统完整数据链路（按流转顺序）：

1.  采集：广告投放端采集原始数据

2.  写入： 数据写入Kafka消息队列

3.  消费： Flink消费数据并执行实时计算

4.  计算：计算结果写入业务存储表

5.  呈现： BI报表查询数据库数据并展⽰

3.1 数据链路定位

题目 ：测试发现BI报表广告投放实时数据 停止更新（数值长时间不变） 。描述分段排查思路 ，重点说明：

（1） 如何验证Kafka是否有新投放数据进入？

（2） 如何确认实时计算任务是否正常运行？

（3） 如何判断问题出在数据存储环节还是报表查询环节？

答：

数据链路分段排查

1. 验证 Kafka 是否有新数据
2. 用kafka-console-consumer消费对应 Topic，查看是否有新消息。
3. 查看 Kafka Manager / 监控，看消息生产速率、offset 是否增长。
4. 检查投放端日志，确认数据正常上报。
5. 确认 Flink 实时任务是否正常
6. 查看 Flink UI：任务 Running、无反压、无报错、Checkpoint 正常。
7. 查看消费 lag，lag 持续上涨说明消费阻塞。
8. 查看 TaskManager 日志，排查异常 / 崩溃。
9. 判断存储 / 报表环节
10. 直接查询业务存储表，看数据是否更新：表更新→问题在报表；表不更新→问题在计算 / 写入。
11. 检查报表缓存（Redis）是否未过期、查询 SQL 是否超时、接口是否报错。
12. 重启报表服务 / 清缓存后观察是否恢复。

3.2 系统问题排查

题目 ： BI前端加载广告主月度投放趋势图表 时频繁出现504超时。结合系统架构（ Redis缓存、数据库查询、微服务接口） ，分析最可能的瓶颈环节及调试思路。

答：

• 最可能瓶颈
  • 数据库慢查询：月度趋势跨大量数据，无索引、分组聚合慢。
  • 缓存未命中 / 失效：Redis 无缓存，大量请求直接打库。
  • 接口层耗时：微服务串行查询、数据处理 / 渲染耗时过长。
  • 调试思路
    • 抓接口耗时，定位是 DB/Redis/ 服务耗时。
    • 开启慢查询日志，优化 SQL、加索引、分库分表。
    • 检查缓存策略：缓存时间、更新机制、穿透 / 击穿问题。
    • 服务层做异步、分页、压缩、降级兜底。

第四部分：测试思维

场景设定： 随着业务迭代， 系统新增功能（定向投放统计、 数据导出等） 增多， 回归测试工作量激增， 需优化测试资源分配。

4.1 需求拆解

题目 ：产品新增需求广告主取消投放后 ，实时扣减当日投放总金额并同步更新BI报表。设计至少3个核心测试场景 ，覆盖关键风险点。

答：

• 正常取消场景：投放中取消，当日总额实时扣减，BI 立即更新。
• 重复取消场景：同一投放多次取消，仅扣减一次，不重复扣减。
• 已结束投放取消：投放已结束 / 已退款，取消不扣减，总额不变。
• 并发取消场景：多端同时取消，保证金额最终一致，无超扣。

4.2 质量改进

题目 ：结合广告BI系统特点（核心为数据统计/报表展⽰ ，迭代频繁且多为计算逻辑/样怯优化），说明如何筛选功能模块：哪些优先自动化测试 ，哪些保留手工测试？简述理由。

答：

• 优先自动化
  • 数据统计、聚合计算、对账校验：逻辑稳定、易断言、回归频繁。
  • 核心链路：数据写入→计算→存储→展示，保障准确性。
  • 接口：增删改查、参数校验、异常返回。
  • 保留手工测试
    • 报表样式、图表展示、交互体验：视觉类难自动化。
    • 紧急小迭代、UI 微调：快速验证，成本低。
    • 复杂业务场景：多分支、边界、异常流程，手工更灵活。