小型测试团队提效之路

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1.
2. 小型测试团队提效之路 手机卫士 陈相举 2021.11
3. 陈相举 手机卫士创新业务测试团队负责人 负责手机卫士部门创新业务 及安全sdk相关业务的测试工作
4. CONTENTS O1 O2 O3 为何做提效 提效是什么 小型测试团队如何做提效
5. CONTENTS 为何做提效
6. 测试团队做效能提升的背景 随着互联网软件发布模式以及测试技术的发展,效能提升成为了测试团队的一个新任务 2012-2015 2015-2018 2019起 业务高速发展 业务达到顶峰 创新业务迭起 以技能分工 自动化高速发展 以业务分组 手工自动化相结合 一个大组 纯手工为主 瀑布或小型瀑布为主,发布节奏相对缓慢 业务测试 版本发布 反馈跟进 大量引入敏捷迭代 发布大幅加快 业务测试 版本发布 反馈跟进 效能提升 自动化测试 测试工具开发 发布提效工具
7. CONTENTS 提效是什么?
8. 当我们讲提效我们在讲什么 为何要做提效? 为何是测试在做? 效能提升工作有什么?  发布节奏大幅加快  测试在工作流末端  编译集成环境治理  相比无bug发布更关心让需  传统的发布方式总是会给  测试工具开发 求尽快见到用户  传统功能测试耗时长  自动化测试的投入周期长见 效慢 测试更大的压力  发布速度快与质量存在天 然的矛盾  发布流程自动化  线上环境监控
9. 行业中通常的效能提升实践 需求及项目 • • • 开发阶段 需求管理平台 项目管理平台 持续集成框架 应具备 • • • • • • • • • • 编译环境维护 代码扫描 代码覆盖率统计 单元测试 代码门禁系统 性能收集插桩 崩溃收集插桩 完整的需求整理与验证 大量的测开投入 充足的开发时间 测试阶段 • • • • • • 发布阶段 用例管理平台 性能测试工具 稳定性测试工具 远控平台 接口测试工具 Ui自动化工具 • • • 线上数据 自动化回归用例 发布检查自动化 自动发布/部署 现状&问题 • • • • • • • 线上接口监控 线上压力监控 崩溃监控分析 性能数据分析 团队规模小 测开资源少 工具开发时间更少
10. 将项目效能提升作为一个项目来分析小团队的落地问题  范围:什么提效平台能对业务产生直接价值 成本  时间:让项目意识到效能提升时间投入的必要性  成本:降低成本让项目愿意尝试 质量 时间  质量:高质量的输出才能让项目愿意持续投入 范围
11. CONTENTS 小型测试团队如何做提效?
12. 从项目管理各维度寻找小团队的提效方案  范围:生根业务细化提效范围,从最快产出的改 进点入手 成本  时间:主动介入流程暴露测试发布慢的问题,为 提效任务争取时间分配 质量 时间  成本:提效任务迭代实现,不追求一步做成平台 范围 成本逐步投入  质量:质量要做验收,产出人自行负责产出质量
13. 生根业务细化提效范围-案例1 安全sdk项目简介 安全SDK是手机卫士当前网络、电话诈骗频发的场景,推 出的电话、短信、网址、病毒等安全相关的识别sdk。 sdk跟各手机厂商合作,直接预置在手机中服务于广大手 机用户。 根据不同阶段的诉求, 尽量借用开源框架快速实现需求 测试用例自动化 instrumation Sdk没有ui只提供接口 性能测试自动化 厂商性能诉求上升 本地代码扫描 sonar GDPR合规要求 本地联网监控 littleprocxy 厂商提出下载要求 代码持续集成 jenkins 线上接口监控
14. 生根业务细化提效范围-案例2 流量型游戏项目简介 流量型游戏项目主要以游戏+商业化为主, 借助开源工程,少量资源投入调研可行性及预期产出 • 基于Airtest的ui自动化 • 基于maxim的monkey+崩溃回收 在游戏内的道具获取、关卡等增加大量激 励视频,游戏实现非android原生依赖游 戏引擎cocos等 难道这个项目没有提效的介入点吗? • • Ui自动化在业务前期没有价值 商业化尤其是激励视频让monkey作用大降
15. 立足于线上数据,深入做线上监控 解决方案 问题 • 基于商业化的项目需要大量数据分析 • 马甲包众多增加了数据分析难度 • 定时数据系统 打点及崩溃收集sdk 数据上报 实时数据系统 手工报表 展示 数据清洗 分析 立足于线上数据往线上监控方向做提效 崩溃率计算 严重崩溃 新增崩溃 日常数据邮件报告 预期打点太低 邮件标红/短信/推 推通知 异常打点 功能异常占比 分级预警
16. 主动介入流程暴露测试发布问题 暴露团队问题才能找到解决问题的方案 计划会&backlog 需求准入问题 站会&看板 信息同步问题 回顾会&复盘 团队改进问题
17. 主动介入流程争取时间分配 跟进用户反馈发现测试不足以及改进流程 “5个为什么”熟悉业务细节 • 严谨分析问题原因,防止类似问题再 改进反馈跟进流程 • 次出现 • 了解开发实现细节为技术沟通打基础 分级制定响应时间,给测试争取必要 的时间 • 分级制定响应策略,避免测试资源的 无效浪费
18. 提效任务迭代实现成本逐步投入 提效工作迭代化,各项目的优化成果以脚本的形式产出 模块化 定制化 平台化 配置化 定制化脚本投入小产 脚本模块化后可快速迁移 平台投入高在基础脚 出快,效果明显 到新项目 本完成后适时推进
19. 提效任务迭代实现成本逐步投入-案例 复杂需求成立虚拟小组专项解决 插件化应用发布记录平台 上线前版本信息检测 上线前自动化检测 测试 Apk/插件信息读取 Apk/插件信息读取 数据合并存储 Apk/插件信息读取 • 插件化应用信息检测 • 打包平台的apk获取 发布数据前端展示 开发、产品、测试
20. 产出要做验收,未经验收的产出不算结项 所有的产出价值都需要有业务/使用测试人员的评估 稳定性测试看抓到的崩溃及线上崩溃率 测试/发布的效能提升核算节约时间 专业 评估 监控预警看预警准确及时度 兼容性测试看产出的业务覆盖度
21. 全面锻炼个人能力以具备独立对质量负责的能力 日常各个项目积累常用提效脚本 业务测试 能力 自动化 能力 • 全部人员承担业务测试 • 提效工作各业务自行发现 • 工作落地各自执行 项目推动 能力 定期强制组内技术分享 每个人都兼顾 产品、开发、测试、项目 多种角色 • 提供提效沟通的场合 • 轮班分享所有人员都要参与 • 分享频率高,每1~2周一次
22. 全面锻炼人才从而提高质量 兼容性测试专项自动化 各业务自发提升发布效率, 成果分享共同进步 基础能力脚本10+ 启动时间自动化 稳定性自动化 崩溃自动bug提交 自动发布检查 各项目实现例行自动化任务20+ 自动发布生成 线上崩溃预警 自动化任务每月100+ 线上打点预警 部分业务持续集成 定制化平台1个 覆盖范围广
23. 360技术 THANKS 360质量效能

inicio - Wiki
Copyright © 2011-2024 iteam. Current version is 2.134.0. UTC+08:00, 2024-10-01 04:21
浙ICP备14020137号-1 $mapa de visitantes$