移动App 质量把控

news/2024/10/31 5:37:01/

对于质量问题,直接以小故事的形式展开。下面是移动中台年度针对质量复盘的一些思考

  1. 技术方案阶体现测试用例 对于业务项目来说,会存在测试资源、冒烟用例、精准测试、QA 新业务的业务回归、核心业务的 UI 自动化、高铁阶段的 QA 人工回归等。这里简单讲讲这些词语,对于新的业务项目,一定会有测试资源,简单说就是 QA,新项目在经过 PRD、MRD、需求讨论会、Kick-off 之后,技术方案评审后,会经过测试用例评审,产出的结果就是用例指南,到时候 QA 会在用例平台指配给对应的开发。 敏捷开发思想下,业务需求跟车,而不是针对业务项目开车,每周一创建本周高铁,需求买票跟着上车。上车之前针对你的开发分支,会走精准测试,产出精准测试报告,分析测试报告,如果覆盖率比较低,需要分析是兜底代码太多,还是 QA 没有执行完全,针对后者你可以结合用例,是否有遗漏,然后去 push QA 再去回归。 针对不变的业务,沉淀出的自动化用例,会走 UI 自动化测试。期间线下性能监控会发现一些性能问题。每周值班 QA 会无差别回归业务。

但是啊,这些大多是针对业务,如果是基础 SDK 的能力和性能,大多是无法定位到问题的,所以针对技术 SDK 可能没有测试资源,需要中台开发者在 SDK 阶段,去思考基础 SDK 本身的核心用例,用例需要思考功能用例和性能用例,还需要思考一些开关情况、版本升级等问题。 所以第一个话题,主要是针对基础 SDK 来说的,不过业务项目,在技术方案阶段思考的不是测试用例,而是天网报警(业务异常埋点上报)、业埋点(核心数据)等

  1. 官方组件引入 BetterMR 经过约定:业务代码经过测试之后,才可以从个人分支合并到 dev 分支(注意 dev 分支不是市场分支,release 分支是市场分支)。提交的 MR 必须至少 +2 后才可以合并。其中1个人是同技术栈的老司机,另一个人是同项目的业务开发,做到对齐。

代码质量直接关系到产品质量,Code Review 是保证代码质量一个最显著可行的措施之一,而 BetterMR 是我们探索最佳 Code Review 的方式之一。

约定与建议 【约定】后续所有项目与日常均默认走 betterMR 流程,如果相对简单,可以申请不走 betterMR 流程; 【约定】MR 分级,默认为普通 MR,在 24H 内完成 review;提交者可选择为紧急 MR,在 2H 内要完成 review; 【约定】在后续规划中,架构师在工作分配上预留一定时间到 CR 上; 【约定】被 @ 的 reviewer 当自己手头忙碌无法 review 的情况下,可以选择在评论中 @ 一位 backup 替自己 review; 【建议】紧急MR发出后,请提 MR 的同学主动口头或企业微信联系和催促 reviewer 快速响应; 【建议】reviewer 手头忙碌时,可以先 +1 merge,后续再 review 建议;

reviewer 数量与选择 约定与建议 【约定】每个 MR @ 到两位同学,其中包含该业务域的 owner,以及另一位适合的同学(熟悉业务或者熟悉代码); 【约定】MR 不要 @ 超过两位同学;

小MR流程上是否可以更快一些 约定与建议 【约定】质量是核心问题,因此暂时所有走 betterMR 的项目和日常都坚持走 +2 的逻辑;直至我们的质量数据有显著好转,代表我们的质量意识有明显提升,再考虑轻量化; 【建议】提MR的同学和 reviewer 可以通过更有效的描述、注释、沟通来加速 review 流程,如 UI 部分更快速 review,逻辑部分重点review 等;

MR的代码量与有效拆分 约定与建议 【约定】在技术评审与 kick-off 阶段对工作量进行MR任务的逻辑拆分,业务域 owner 在这两个阶段进行把关,拆分的任务尽量粒度细化; 【约定】在一个 MR 中尽量将相关逻辑完整提交,有利于代码的整体 review; 【约定】在技术评审阶段,业务域 owner 对技术方案与拆分做内审,提前熟悉改动面和设计细节,避免在 MR 提交的代码之外存在逻辑遗漏; 【建议】在保证子任务MR逻辑完整的前提下,尽量约束每个 MR 的代码量,保证 review 效果;

  1. 业务 SDK 接入精准测试,产出报告必须分析 业务项目我在第一部分说明了会针对业务做哪些测试动作,在中台角度出发,思考业务中台(比如商品、消息)如何保证质量,也可以参考业务项目,接入精准测试,针对每一份测试报告,做进一步的分析,如果覆盖率比较低,需要分析是兜底代码太多,还是 QA 没有执行完全,针对后者你可以结合用例,是否有遗漏,然后去 push QA 再去回归。

技术中台负责的业务中台项目,也就是业务 SDK 也需要严格管控,否则就是业务异常,从而产生线上问题或者线上资损。

  1. 业务项目一定接入天网报警,基础 SDK 关键流程接入天网报警 App 质量与稳定性划分为:性能与质量稳定性、业务稳定性。业务不稳定了就很容易产生线上问题或者资损。针对业务异常,我们对线上问题归因做了一些梳理,一般可以分为: 方法或接口的参数数据类型不对、参数值不在合法区间、边界 case 没有覆盖、其他(历史遗留 bug、三方 SDK 升级导致、2端沟通不足需求没对齐); 假如我们将第一二类问题解决好,线上问题将会显著改善。这正好就是天网报警的设计初衷,天网报警用于业务异常监控并报警。天网报警监控并不像 APM 一样是 SDK 去主动监控的,而是需要开发者自己在当前负责的模块、当前开发的项目、当前开发的日常迭代中去梳理关键业务流程和业务场景,对于一些可能存在的异常 case,去埋点上报。

所以制定规范:业务项目一定要接入天网报警,基础 SDK 比如 IM、商品,Socket 链接有问题,那么就是线上问题,肯定是业务异常。所以这样的关键环节一定要梳理并上报

  1. 新 SDK UT 覆盖率90%以上,老 SDK 基于 BDD 通过 基于资源有限的情况下,历史遗留的 SDK 可能无法去梳理并编写单测,那老的 SDK 可以去给予行为去编写 BDD 测试用例,这里不展开描述什么是 BDD 和怎么实践。针对新的 SDK 在技术方案阶段就需要思考好测试用例并体现出来,开发阶段 UT 覆盖率须大于90%。
  2. SDK 一定要 Lint 通过 这里的 lint 并不是针对语法、锁进等的 OCLint,而是 pod lint。因为发生过一些情况,就是 MR 提交后,去打包系统打包阶段, 因为 pod SDK 的问题导致的打包失败,所以 pod 的 lint 一定要通过,将问题提前解决掉。
  3. SDK Warning 清理 SDK 内部的 warning 尽量清理掉,比如 UIWebView 或者某个使用的 API 苹果标记为待废弃,假如你不按时修改掉,万一上线后用户使用的某个功能异常,那就 GG 了
  4. SDK 核心用例梳理,确保接入 App 集成测试 老的 SDK 梳理核心用例,便于 BDD 测试。SDK 的所有功能需要接入至少2个业务线 App 去验证功能和性能是否符合预期
  5. SDK Demo 必须体现开发能力,多端 Demo 对齐 SDK 的功能设计、类的 API 多端对齐,能力一致。且在 Demo 上可以体现出核心功能
  6. 脏乱差治理并优化 年底统计线上问题原因,经常会发现不管是业务线还是中台,都有一些遗留或者接手的线上问题,所以不管何种原因,都需要 Owner 意识,脏乱差梳理去修复问题
  7. 确保测试用例冒烟通过 QA 指派的测试用例一定要冒烟通过,冒烟打回很严重的,这是对质量的不认真,也是对 QA 工作的不尊重
  8. 关键功能有限老司机操刀开发,避免形成卡点(进度)或者影响质量,太忙的情况下至少老带新 核心业务功能,新人很难评估到所有影响面和边缘 case,所以优先老司机操刀开发,或者新人梳理评估出方案,老司机 review 把关。避免因为不熟悉造成进度落后或者线上质量问题
  9. 基础 SDK 交叉测试 业务项目有 QA 资源,基础 SDK 不一定有测试资源,需要开发者本身去思考测试用例,包括功能和性能方面,最后可以交叉测试,Android、iOS 互测,确保质量。

http://www.ppmy.cn/news/65786.html

相关文章

前端开发中,定位bug的几种常用方法

目录 第一章 前言 第二章 解决bug的方法 2.1 百度 2.2 有道翻译 2.3 debugger 2.4 console.log 日志打印 2.5 请求体是否携带参数 2.6 注释页面渲染代码 2.7 其他 第三章 尾声 备注:该文章只是本人在工作/学习中常用的几种方法,如果有不对大家…

双向带头循环链表

双向带头循环链表 1.前言2.带头双向循环链表的初始化3.创建一个哨兵位头节点4.链表的打印5.malloc函数创建节点5.链表的尾插6.链表的尾删7.链表的头插8.链表的头删9.链表的查找10.链表任意位置插入(在给点定位置的前面插入)11.链表任意位置删除12.空间释…

Scala学习(四)

文章目录 1.闭包2.函数式编程递归和尾递归2.1递归2.2 尾递归 3.控制抽象3.1 值调用3.2 名调用 4.惰性函数 1.闭包 如果一个函数,访问到了它的外部(局部)变量的值,那么这个函数和它所处的环境称之为闭包 //闭包练习def sumX(x:Int){def sumY(y:Int):Int{…

CGAL 建筑物轮廓规则化(二维)

文章目录 一、简介二、实现代码三、实现效果参考资料一、简介 假设给定一组由线段连接的有序二维点,这些点构成一个闭合或开放的轮廓,CGAL中提供了三种方式来实现多边形轮廓的规则化: 平行:将检测到的接近平行的轮廓边缘完全平行。正交性:将检测到接近正交的轮廓边缘,使其完…

【力扣】刷题+剑指offer第二版

文章目录 题目收藏不含重复字符的最长子串最长公共子串 剑指 Offer剑指 Offer 05. 替换空格剑指 Offer 03. 数组中重复的数字剑指 Offer 04. 二维数组中的查找剑指 Offer 09. 用两个栈实现队列剑指 Offer 07. 重建二叉树剑指 Offer 06. 从尾到头打印链表剑指 Offer 11. 旋转数组…

进程调度/页面置换/磁盘调度算法

进程调度算法 进程调度算法也称 CPU 调度算法,毕竟进程是由 CPU 调度的。 当 CPU 空闲时,操作系统就选择内存中的某个「就绪状态」的进程,并给其分配 CPU。 什么时候会发生 CPU 调度呢?通常有以下情况: 当进程从运…

什么是阿里云服务器?云服务器的优缺点

阿里云服务器是什么?云服务器ECS是一种安全可靠、弹性可伸缩的云计算服务,云服务器可以降低IT成本提升运维效率,免去企业或个人前期采购IT硬件的成本,阿里云服务器让用户像使用水、电、天然气等公共资源一样便捷、高效地使用服务器…

2.3 利用NumPy进行统计分析

2.3 利用NumPy进行统计分析 2.3.1 读/写文件1、二进制的文件读写2、读取文本格式的数据 2.3.2 使用数组进行简单统计分析1、排序2、去重与重复数据3、常用的统计函数 2.3.1 读/写文件 NumPy文件读写主要有二进制的文件读写和文件列表形式的数据读写两种形式 1、二进制的文件读…