提升点

sql的分组练习
select a.uid , sum(b.score) as total ,  avg(b.score) as avg_s , count(distinct b.car_id) as count_car
from table1 a left join table2 b 
on a.uid = b.uid
where date between '2026-07-01' and '2026-07-31'
group by a.uid
having sum(b.score)>=2000

 

冒泡排序
小的向上　　
def test_arr(arr):
    n = len(arr)
    for i in range(n-1):
        for j in range(n-1-j):
            if arr[j+1] > arr[j]:
                arr[j],arr[j+1] = arr[j+1],arr[j]
    return arr

test = [5, 3, 8, 4, 2]
print(test_arr(test))

 

✅ 窗口函数

✅ 想要明细数据 + 组内统计值 → 窗口函数 OVER ()

✅ 想要多行合并成一行，只看汇总结果 → GROUP BY 聚合

1. 基础概念
   • 区分聚合函数 GROUP BY 和窗口函数区别：GROUP BY 会合并行；窗口函数保留原有行数
   • 语法结构：函数() OVER(PARTITION BY 分组列 ORDER BY 排序列)
2. 核心常用函数（必掌握）
   • ROW_NUMBER()：分组内连续编号（相同值序号递增）
   • RANK()：并列会跳号 1,2,2,4
   • DENSE_RANK()：并列不跳号 1,2,2,3

• LAG() / LEAD() 获取上一行、下一行数据（时序数据： 首条没有上期，要做ifnull case； 上期数据是0单独处理； 断天拿的最近的上一条数据，环比失真）
• SUM() OVER() 分组内累计求和
• 窗口框架：ROWS / RANGE（行范围，滚动窗口、滑动平均）

✅ Monkey稳定性测试

1. 环境准备
   • ADB 环境配置，手机开启 USB 调试，确认 adb devices 识别设备
   • 下载 Platform Tools，配置环境变量，cmd输入adb version检查安装成功（只包含 adb、fastboot）
   • SDK 平台工具版本说明  |  Android Studio  |  Android Developers
   • MuMu模拟器官网_安卓15模拟器_网易手游模拟器

   • C:\Users\TS>adb kill-server
     
     C:\Users\TS>adb start-server
     * daemon not running; starting now at tcp:5037
     * daemon started successfully
     

     　C:\Users\TS>adb devices
     　List of devices attached
     　emulator-5554 device

      

2. 基础命令完整参数

adb shell monkey -p 包名 --throttle 操作间隔300 --ignore-crashes --ignore-timeouts -s随机种子 事件次数 > 重定向到c盘文件夹下
adb shell monkey -p com.android.settings --throttle 300 --ignore-crashes --ignore-timeouts -s 6666 10000 > monkey_log.txt
adb shell monkey -p com.android.settings --throttle 400 --ignore-crashes --ignore-timeouts --pct-rotation 0禁止自动旋转屏幕 -s 6666 10000 > monkey_log2.txt

逐个理解含义：

--throttle 毫秒：事件之间延时，避免操作过快
-s 种子值：固定随机序列，复现 bug 必备
--ignore-crashes：崩溃后继续执行
--ignore-timeouts：出现 ANR 继续执行
> xxx.txt：输出日志保存到文件
--pct-rotation 0：屏蔽屏幕翻转（规避模拟器报错）

 

　　3. 日志关键字检索

✅ 需要提交缺陷：CRASH：应用闪退崩溃；ANR：应用无响应卡死

⚠️ 各类 IOException、Injection Failed、管道异常、连接断开，大多是模拟器 / ADB 通信层面问题，不是 App 业务崩溃。

4. 基础执行流程清理后台 → 启动 App → 执行 Monkey → 导出日志 → 筛选崩溃、整理测试报告
5. 查找包名
cadb shell dumpsys window | findstr mCurrentFocus
1. 输出示例： mCurrentFocus=Window{xxxx u0 com.tencent.mm/com.tencent.mm.ui.LauncherUI}
2. com.tencent.mm 就是微信包名

⚠️ 进阶拓展（学完基础再练）

• 限制操作事件比例：触摸、滑动、按键事件占比 --pct-xxx
• 白名单、休眠策略、系统后台干扰
• 持续长时间稳定性压测方案（比如 8 小时）

学习达标自测

1. 可以独立写出完整 Monkey 命令，会设置种子保证问题复现
2. 跑完压测，能从日志定位崩溃，简单描述复现条件
3. 输出一份标准稳定性测试小结：执行时长、事件总数、崩溃次数、问题清单

问答预备

Q：Monkey 测试流程是什么？遇到崩溃怎么排查？

 

回答：

 

通过 ADB 连接设备，指定应用包名配置随机种子、操作间隔执行压力；执行过程保存完整日志，测试结束检索 CRASH、ANR 关键字定位异常。随机种子很关键，方便稳定复现偶现崩溃，同时记录复现前后操作场景，提交缺陷给到开发。

adb shell monkey xxx > monkey_log.txt

 

 

 

 

冒烟用例频繁误报，你是怎么处理的？

　　建立失败用例日清闭环：

1. 区分三类失败根因：业务代码 bug、自动化脚本不稳定、测试环境波动；
2. 代码 bug：提缺陷单推动开发当天修复；
3. 脚本不稳定：优化元素定位、增加等待、调整数据驱动；
4. 环境波动：协调运维优化环境稳定性，同时增加重试机制；
   每天复盘冒烟报告，长期下来脚本误报率持续降低，保证自动化结果具备参考价值。

开发觉得 master 门禁冒烟太慢，想直接跳过合并，怎么协调？

1. 先同步过往数据：门禁冒烟拦截过多少线上高危 bug，跳过会带来版本上线风险；
2. 优化方案：精简 master 冒烟用例，只保留不可缺少的主干流程，缩短执行时长；
3. 折中规范：不允许手动跳过门禁，特殊紧急 hotfix 版本走审批流程，事后补充补测与冒烟回归，兼顾效率与质量。

如果让你重新搭建一套分支冒烟体系，你的设计思路？

1. 分支划分：区分开发分支、发布主干；
2. 用例分层：迭代全量冒烟（dev 每日）、主干极简门禁冒烟（master 合并卡点）；
3. 流水线配置：Jenkins 绑定代码仓库，定时触发 + 合并触发双模式；
4. 配套流程：失败日清、每周清理废弃冒烟用例、迭代同步更新用例；
5. 结果推送：冒烟失败自动推送消息到项目群，及时同步相关人员。（冒烟只测主干核心流程，不覆盖全量功能）

 

dev 开发分支：每日定时冒烟怎么做

整体流程

　　代码仓库（Git）分出独立 dev 开发分支，所有开发日常迭代代码都提交到 dev； Jenkins 新建流水线任务，绑定 dev 分支代码地址； 配置定时触发规则：例如每天凌晨 2 点自动拉取 dev 最新代码、部署测试环境； 自动执行 Pytest 自动化冒烟用例（核心页面、数据查询、权限校验流程）； 脚本执行完成自动生成 Allure 报告，失败用例同步推送企业微信 / 钉钉项目群； 执行失败执行日清机制：当天测试 + 开发共同排查环境 / 脚本 / 代码 bug 并修复。

master 主干分支：代码合并门禁（MR/PR 卡点）怎么做

整体流程

1. master 为上线稳定主干，禁止任何人直接推送代码，必须提交合并请求；
2. Git 仓库绑定 Jenkins 流水线，开启合并前置校验；
3. 开发提交 MR/PR 合并到 master 时，自动触发流水线：拉取待合并代码、部署临时环境、执行极简冒烟用例；
4. 判定规则：
   • 冒烟全部通过 → 允许代码合并进入 master；
   • 冒烟存在失败用例 → 直接阻断合并，不允许合入主干；
5. 开发修复代码、重新提交合并，再次走门禁校验，通过后方可合并。

基础题 1： dev 定时冒烟、master 合并门禁分别是怎么配置、怎么运行的？

回答：

 

我使用 Git+Jenkins 搭建双分支分层自动化体系。

1. dev 开发分支：Jenkins 配置每日凌晨定时触发，自动拉取最新代码部署环境，执行全套核心冒烟用例，执行报告推送项目群，失败用例执行日清闭环，提前暴露迭代引入的阻断 bug；
2. master 上线主干：设置代码合并门禁，开发提交合并 MR 时自动触发流水线，运行极简主干冒烟脚本，执行失败直接阻断合并，避免缺陷流入稳定主干；
    
   两套流程配合后，版本提测基础缺陷大幅减少，手工回归工作量降低 40%。

深挖题 2：定时冒烟和门禁冒烟两套用例集为什么分开，不能共用一套？

回答：

 

两套使用场景、性能要求不一样：

1. dev 每日冒烟：覆盖当前迭代新增功能，用例数量更多，目标是尽早测出新需求 bug，每天凌晨执行，不占用白天开发时间；
2. master 合并门禁：代码合并不能等待太久，只保留最小主干流程用例，执行速度控制在 5 分钟内，保障开发迭代效率；
    
   如果共用全套用例，门禁执行耗时过长，会影响团队代码合并效率。

深挖题 3：门禁冒烟经常误报，开发不愿意等，你怎么优化？

回答：

1. 分层清理用例：把不稳定、依赖特殊测试数据的用例从 master 门禁移除，仅保留强稳定主干流程；
2. 脚本优化：增加页面等待、数据前置初始化步骤，减少环境波动导致的偶然失败；
3. 建立日清机制：每日统一复盘冒烟失败记录，区分代码 bug / 脚本缺陷 / 环境问题，长期降低误报率；
4. 同步数据给团队：展示门禁曾经拦截过的线上高危缺陷，让开发认可门禁的质量价值。
5. dev 冒烟覆盖安全分新增统计逻辑、新权限页面；master 门禁只校验登录、安全分首页数据加载两大核心流程，一旦页面打不开、数据为空直接阻断代码合并，防止影响全量用户线上查看分数。