Devops 建设思路——顺丰科技 靓汤

• 感知->判断->设计->执行度量->运营
• 感知：推动方向有三种
  • 从上到下：价值导向，但比较难预测、没标准
  • 从前到后：研发先推，再到运维。容易竖井
  • 上下一致：左右限制？
  • 从后向前：缺乏上下文，运维不熟悉业务，低效紧张
  • 系统学：只要内在连接和总目标稳定，即使替换所有要素（比如关键骨干离职），系统也会保持不变或者只是缓慢变化。
  • 职责分工：开发->业务 + 需求 +QA+ 研发 + 基础运维 + 应用运维->交互 + 产品 + 测开 + 全栈研发 + 全栈架构 + 运营？
  • 产品->产品集->战略集：高度不同，方法不同 (scrum->less->商业画布）
• 判断
  • DevOps 道法术器（三步工作法属于 “法”）
  • 项目->组件框架->资源自助->研发流水线->组织
  • 按时间来判断瓶颈（等待时间），消除瓶颈
• 设计
  • SPAM（午餐肉）：认知折叠
  • 8 字环：每个位置选用合适的工具/平台，并把数据打通，流动起来
  • Aone git 分支流程：研发只关注自己的分支，其它不用关心，系统接管，减少研发负担。
  • 框架规范先行，保持统一
  • 数据库变更：基线管理，保证顺序避免人为介入
  • 配置变更：热加载（配置中心，不用重启就生效）、冷加载（环境变量等，重启才生效）
• 执行与度量
  • 7 个核心指标：交付效率（需求交付效率、研发交付效率、交付吞吐量、人均交付吞吐量）、交付质量（线上缺陷数、用户问题反馈数、监控预警量）
• 运营
  • 更多人，参与更多活动

QA：

• 数据库脚本如何管理？——用 nas 另行管理，用目录结构而非版本管理来管理
• 如何在线上测试？——预发布环境，在生产区单独隔离出来，但基本和生产一致，数据标识隔离（影子表）

在实际公司业务应用的参考：

• 从更大的角度看 devops
• 度量指标可供参考

图像分类、AI 与自动化测试——OPPO

• 图像与测试
  • 基础知识：图像分类、目标检测、类别分割、实例分割
  • 测试领域：airtest、基于 YOLOv3 的 UI 异常检测方案（爱奇艺）https://www.infoq.cn/article/2v-VuuLL5DVUaA6tf9rI
• 从启动速度开始
  • 当前方案：日志埋点（开发者角度）、视频录制（用户角度）
  • 结合目标识别：选定检测物，存在即认为启动完成。缺点是效率和准确度难取舍（标志物多会慢，少就不准）、图片素材管理、优化难
  • 结合图像分类与 AI：用 AI 训练，自动寻找标志物和识别。缺点是需要手动采集训练集、变化过程难分类、UI 有变动要重新训练
• 全流程自动化
  • stagesepx：把人工挑选训练集干掉，自动建模。
  • 基于状态是否稳定来判别，而非具体标志
  • 更具体：图像分类、AI 与全自动性能测试
  • 有 hook 机制，支持自扩展来挑选适合的稳态

在实际公司业务应用的思考：

• 优：界面耗时类专项做起来比较省事
• 劣：目前稳态要求是整个界面的稳态，对轮播比较敏感，这部分需要自定义。需要视频，视频需要另外想办法解决。
• 结论：暂时先观望状态。

画质测试——腾讯 陈曦明

• 概述
  • 明确画质：清晰度 + 用户观感
  • 不包括：流畅、花屏、噪点
• 怎么测
  • 全参考：源视频 + 失真视频->全参考算法->测试结果
  • 无参考：失真视频->无参考算法->测试结果
• 实际使用的问题
  • 你测的是什么？——主播端、互联网、用户观看端
  • 全参考适合你吗？——秀场直播，关注的是美颜效果；游戏直播，关注的是清晰度。要按实际场景选择。
  • 你所用的 “源视频” 真的合适吗？——用硬件采集卡获取 “原画画质”，码率得达到 160M-200M 左右（一般用户用的是 4M 内）
  • 你获取的 “失真视频” 合适吗？（后续的有其它事情在做，没记录到。。。）

在实际公司业务应用的思考：

• 和公司业务关联度比较低，主要作为开阔视野

全程软件测试——平安智慧城市

• 测试人员需具备素质
  • 端正认识
  • 沟通、外交、移情能力
  • 技术全面
  • 5 心（专、细、耐、责任、自信）
  • 记忆力、评判思维、洞察力
  • 探索、创新、挑战
• 产品质量模型——国标
• 后续的基本和《全程软件测试》差不多，可能全面度方面还有一些距离，所以没怎么记录。

PS：平安智慧城市是政府项目，整体属于长瀑布型，非常重文档，和互联网业务快速迭代，差异会比较大。

在实际公司业务应用的思考：

• 要更好地抓关键点
• 不要忽略测试策略

httprunner 接口测试平台——乐信

• httprunner 简介——简洁、规范（用 yml 而非编程语言）
• 核心功能设计
• 关键转变
  • 接口模板——抽离元素点->postman 风格、关键字 tab 化、组件化（一个文件一个组件一个关键字）
  • 前端 json 转 httprunner 标准 json
  • 测试用例——左侧 api 列表，右侧组合用例。通过拖动组合，形成用例
• 附属功能
  • 驱动代码——实现在线 python 编辑器（代码存成文件->新进程执行并获取 stdout->显示回界面）
  • 域名管理——解析后，直接给所有 api 的 request 里面 host 换成 ip
  • 装载过程：数据->域名替换->环境参数->加载配置->动态导包->执行引擎（httprunner）->报告解析
• 整体架构
• 内部实际应用
  • 测试用例管理平台
  • 发布系统（借这个平台做自动化回归）
  • 扩缩容快速验证（扩缩容后自动化回归）
  • 任务调度器（线上拨测）
• 其它
  • 首页显示单人操作数据统计（每个月增加、修改、删除用例数）
  • 自己重新做了个类似 extent report 的报告输出，好看一些

在实际公司业务应用的思考：

• 可以学习思维模式，先考虑核心功能，再逐步进行转换，形成具体的平台
• 平台组件尽量拆散，各自独立，便于随时调整
• 关注度量，度量数据放在首页