基于风险驱动的交付模式转型探索与实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 基于风险驱动的交付模 式转型探索与实践 2023.03 / 黄佳鑫
2.
3. 分享纲要 1、风险驱动交付模式源起--百度交付现状&挑战&破局 2、风险驱动交付模式构建技术 2.1、模式介绍--何为风险驱动交付 2.2、模式建设--质量风险决策系统 2.3、模式应用--无人值守建设和落地 3、未来展望
4. 风险驱动源起| 百度交付现状  随着工程能力的不断提升,交付模式逐步完成从纯手工测试自动化测试持续集成持续发布的演变。  通过将自动化测试工具集成到流水线中,质效工作逐步左移,研发可以通过流水线完成测试、上线工作。 RB 分支开发、主干合入、分支发布交付模式 从主干 拉分支发布 M1 M2 从主干 拉分支开发 Approve 手动合入主干 Branch 主干测试 实时和 绿灯通过 QA 评估 daily执行 分支测试 绿灯通过 QA 评估 本地开发 执行约花费1小时       集群编译:15分钟 静态代码检查:20分钟 单元测试:10分钟 Diff测试:50分钟 性能测试:60分钟 功能测试: 40分钟      执行约花费1小时 集群编译:15分钟 静态代码检查:20分钟 Diff测试:50分钟 性能测试:60分钟 功能测试:40分钟 发布 发布测试 绿灯通过 QA 评估 Master M3 执行约花费5小时  集群编译:15分钟  性能测试:5个小时 问题 • 月需求万级,关联bug占比20%;构建百万 级,关联bug占比1%,较多冗余执行 • 3阶段执行耗时小时级,但交付周期天级粒 度,人工评估和扭转拉长周期 • 线上百级个bug漏出,测试和准出能力不足
5. 风险驱动源起| 百度交付挑战&破局 RD 和 QA 质 效 心 声 挑战 非所有项目都有风险,80%+无关联bug和线上问题 现 状 剖 析 破局思路 测试本质是减少bug发生的可能性(风险)和产生的影响 以风险驱动,测该测的,评风险评得准,达到质效最优 风险 驱动 不是所有测试任务都能揭错,固化冗余测试占比高 测试人员也有误判的可能,漏测一直存在 针对性 测试 精准 极致 评估 质效
6. 风险驱动交付—模式介绍| 何为风险驱动
7. 风险驱动交付—模式建设| 质量风险决策系统 (核心风险识别、风险控制和风险决策 ) 构建质量决策系统,机器自动识别风险,执行该执行的测试活动,自动决策风险,自动流程流转 ①-风险识别 项目风险画像 人员风险画像 代码动静态风险画像 动态风险点识别 ②-风险控制 功能 测试 稳定 性测 试 性能 测试 ③-风险决策 风险点&概率 风险可视化&闭环 风险可视化报告 业务影响 风险 数据 风险 策略 测试 控制 分级 发布 灰度 报告 反馈 意见 监控 风险闭环 原始代码 AST 语义分析 稳定 性 决策 结论 影响 评估结论,流转&推荐 风险追踪Cover bug 反馈 反馈 优化 路径 提取 模型 上线 性能 深度算法识别 人工 模型 迭代 特征 提取
8. 模式建设—风险识别| 建立识别能力,打通数据血缘关系,量化风险 开发 时长 采集什么数据? 如何采集数据? 怎么串联数据? 变更 次数 模块 是否 数 联调 项目信息 千行bug率 线下bug数 项目熟悉度 提测打回数 线上bug数 pipelinetid jobid 测试信息 代码信息 变更 Bug信息 commitid 高危片段 人员信息 高危场景 卡片id 提测单id 影响 充分度数据 执行数据 杂 更 用户 问题 拦截 业务 历史 用户 密度 密度 能力 指标 bug 路径
9. 模式建设—风险控制| 针对识别风险,给出执行建议和充分度评估 执行哪些测试? 如何执行测试? 测试质量如何? 自动生成 充分度评估 精准测试 智能构建
10. 模式建设—风险控制之智能构建| 精简、自动标注和自愈流水线任务或阶段 智能构建决定应该执行哪些测试,节省流水线构建时间 从几个场景说起 场景一、孤岛函数,diff代码无法进入 function A(){ if gflag3{ B() } } function B(){ if gflag2{ if gflag1{ code diff; }}} 1、函数调用关系 场景二、简单改动,local和trunk都跑 A  B # 原始代码 if (NULL == _p_adx_1 || NULL == _p_adx_2) { return false; } 2、开关依赖关系 gflag3  gflag2  gflag1 3、开关链路状态 4、变更所属开关 false true # 变更代码 if (NULL == _p_adx_1 || NULL == _p_adx_2) { ADX_WARNING("_p_adx_1 or _p_adx_2 is NULL"); return false; } true code diff  gflag1 问题分析  问题1: 简单修改,孤岛,有必要跑那么多测试? 特别是高资源和时间消耗的性能任务 解决方案 跑需要跑的, 跟进需跟进的失败  问题2: 同一次提交,local和trunk的任务都一 样,是否多余  问题3: 任务偶发抖动失败,定位原因耗时,能否 自动重跑,自动定位原因 跳过 落地效果 构建策略 精简策略 自动标注 策略 取消 结果复用 自愈策略 策略 效果 精简任务量 6w+/Q 自愈任务量 8k+/Q
11. 模式建设—风险控制之精准测试| 以更少的用例,达到更多的问题召回 精准测试决定应该如何进行测试,执行哪些用例。 • 前端APP单产品回归用例1500+,总量9w+,单次回归约3天,可接受时间1天内 • 后端系统线上引流百万级,全系统任务最多发送十万级,子系统测试可接受2万 用例与代码关系建立 代码库 基于相关性用例推荐 文件风险特征采集 聚合分 类模型 插桩编译 用例回放 分析用例覆盖信息 用例与分 支关系 用例与函 数关系 Diff 信息 文件级 bug模型 产出diff相关 的风险文件 用例排序 策略 效果 落地业务:20+ 手工用 例选择 压缩率:80% 回归耗时下降:56% 落地模块:100+ 压缩率:70% 黑名单过滤 用例与文 件关系 落地效果 基于风险用例推荐 最大覆盖用例 公共方法过滤 冗余 or 缺失? 采用相关性用例推荐 系统流 量选择 测试耗时压缩:50% 召回bug:200+
12. 模式建设—风险决策| 思路介绍 决策方案 场景借鉴 身体体检 基于启示,方案基于规则+模型+影响进行量化决策 不同群体,不同体检单 类别 内科 实验 检查 体检项 心率、脾胃等 甲功、肾功等 规则 决策 待就诊 待复查 待关注 识别风险,并 控制,如何给 出决策结论? 披露风险点 给出测试建议 规则 模型 给出 风险发生概率 偏专家经验,规则化决策 特征 贡献分 评分卡 银行风控放贷 200 模型、 年龄 300 信用分 收入 信用分 650 策略 不授信 可授信 授额度 决策 专家经验+风控模型的组合决策 影响 获取数据 风控放贷 黑名单规则 决策 监测标注 Pv、收入等 特征工程 闭环 模型上线 模型开发 检验评估
13. 模式建设—风险决策之风险概率模型| 从历史数据自动学习“经验”,预测未来 模型选型 是否有风险,风险概率大小本质上是一个二分类算 法,具体选择哪一种? 模型特征 实验一:以业务测试数据验证效果 风险引入 风险移除 项目风险指标 人员风险指标 测试充分度 监控完备度 代码风险指标 AUC衡量分类好坏。TOP-5算法是AdaBoost、NB、LR、MLP和XGBoost, 逻辑回归(LR)模型效果前列 影响风险指标 实验二:模型需要可解释 逻辑回归是找到从特征空间到输出空间最优线性映射函数,形如: z = � 0 + � 1 ∗ � 1 + � 2 ∗ � 2 + � 3 ∗ � 3 + � 4 ∗ � 4 +b 模型效果 正确率/错误率 LR契合人工判断的方式,可解释性较好,而其余4个都不行 实验三:质量数据量较少速度要求高,模型不能太复杂 LR属于简单模型快速,不容易出现过拟合,Boost和MLP较复杂, 对数据需求高 综合上述3点,选择逻辑回归作为分类模型 准确率/召回率/F1测度 ROC曲线/AUC面积
14. 模式建设—风险决策之决策结论| 量化决策,助力自动流程流转 测试本质是规避风险,减少风险发生概率和发生问题造成的危害,而风险矩阵是一种综合两者的风险评估分析方法 基于风险矩阵,进行决策 Ⅰ:伤害事件发生可能性极大,任何情况下都会重复出现 拦截 Ⅱ:经常发生伤害事件。 拦截 Ⅲ:有一定的伤害事件发生可能性,不属于小概率事件。 拦截 Ⅳ:有一定的伤害事件发生可能性,属于小概率事件。 视情况 Ⅴ:会发生少数伤害事件,但可能性极小。 通过,无人值守 Ⅵ:不会发生,但在极少数特定情况下可能发生 问题发生产生的危害 通过,无人值守
15. 模式建设—风险报告举例
16. 模式建设—架构图| 打造通用工程和策略,管控流程和数字化度量,低成本赋能
17. 风险驱动交付—模式应用| 无人值守建设(完备测试、稳定构建和精确评估)  Diff测试:结果复用 1  功能测试:结果复用  性能测试:结果复用 发布 测试 RB 从主干 拉分支发布 M1 主干 测试 M2 从主干 拉分支开发 低风险自动 分支 测试 Branch 本地开发 绿灯通过 风险决策 3  性能测试:跳过  Diff测试:30分钟  功能测试:20分钟 完备测试能力 绿灯通过 风险评估 智能构建 1 风险决策 3 高风险 流程拦截 QA补充测试 低风险 QA确认通过 手动流程流转 精准测试 2 稳定构建能力 全流程无人(QA)值守 风险决策 3 Master M3 绿灯通过 分支合入主干 发布 无QA跟进, 自动流程流转 精确评估能力
18. 落地效果| 带来测试思维的变革,质量和效能提升明显 01 低风险项目低成本 高效交付 02 降低冗余 测试任务/用例 03 量化风险 减少bug漏出 Q共识别1.1w+可自测项 Q精简任务6w+,约减少 Q共识别3k+不可自测 目,自测占比60%;无 2.88wh执行;压缩用例 项目,共拦截500+bug 人值守项目占比达25% 70%+,测试执行时长降 低50%+
19. 总结&展望| 由机器代替人工自动、深度决策,实现风险驱动交付 测试行为推荐/预警 需求准出 集成准出 灰度准出 分级准出 求 请 请 求 决 策 通过 返 回 建 风险 议 和 分和 推 荐 点, QA 自动/半自动测试执行,充分度评估 分阶段需求发起 质量风险 决策系统 1、测试前(风险识别): 识别风险,推荐/预警活动和用例 2、测试中(风险控制): 定向风险执行,前置拦截 3、测试后(风险决策): 决策风险,给出建议,自动扭转 试 测 、 请 动 申 活 试 例 测 用 回 试 返 测 低风险 准出风险决策 高风险 决策 建议 流程拦截 RD修BUG 测试 分配QA跟进 补充测试/用例 下阶段
20.

Accueil - Wiki
Copyright © 2011-2024 iteam. Current version is 2.139.0. UTC+08:00, 2024-12-28 10:40
浙ICP备14020137号-1 $Carte des visiteurs$