App质量把控：简述质量问题现状及解决方案

蔚落 2023-10-08 15:12 22阅读 0赞

![在这里插入图片描述][5fb87c883155482198a70b4dca710d26.gif_pic_center]

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

### 技术方案体现测试用例 ###

对于业务项目来说，会存在测试资源、冒烟用例、精准测试、QA 新业务的业务回归、核心业务的 UI 自动化、高铁阶段的 QA 人工回归等。

这里简单讲讲这些词语，对于新的业务项目，一定会有测试资源，简单说就是 QA，新项目在经过 PRD、MRD、需求讨论会、Kick-off 之后，技术方案评审后，会经过测试用例评审，产出的结果就是用例指南，到时候 QA 会在用例平台指配给对应的开发。

敏捷开发思想下，业务需求跟车，而不是针对业务项目开车，每周一创建本周高铁，需求买票跟着上车。

上车之前针对你的开发分支，会走精准测试，产出精准测试报告，分析测试报告，如果覆盖率比较低，需要分析是兜底代码太多，还是 QA 没有执行完全，针对后者你可以结合用例，是否有遗漏，然后去 push QA 再去回归。

针对不变的业务，沉淀出的自动化用例，会走 UI 自动化测试，期间线下性能监控会发现一些性能问题，每周值班 QA 会无差别回归业务。

但是啊，这些大多是针对业务，如果是基础 SDK 的能力和性能，大多是无法定位到问题的，所以针对技术 SDK 可能没有测试资源，需要中台开发者在 SDK 阶段，去思考基础 SDK 本身的核心用例，用例需要思考功能用例和性能用例，还需要思考一些开关情况、版本升级等问题。

所以第一个话题，主要是针对基础 SDK 来说的，不过业务项目，在技术方案阶段思考的不是测试用例，而是天网报警（业务异常埋点上报）、业埋点（核心数据）等。

### 官方组件引入 ###

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 效果。

### 报告分析 ###

业务 SDK 接入精准测试，产出报告必须分析。

业务项目我在第一部分说明了会针对业务做哪些测试动作，在中台角度出发，思考业务中台（比如商品、消息）如何保证质量。

也可以参考业务项目，接入精准测试，针对每一份测试报告，做进一步的分析，如果覆盖率比较低，需要分析是兜底代码太多，还是 QA 没有执行完全，针对后者你可以结合用例，是否有遗漏，然后去 push QA 再去回归。

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

### 接入天网 ###

业务项目一定接入天网报警，基础 SDK 关键流程接入天网报警 App 质量与稳定性划分为：性能与质量稳定性、业务稳定性。

业务不稳定了就很容易产生线上问题或者资损。针对业务异常，我们对线上问题归因做了一些梳理，一般可以分为：

方法或接口的参数数据类型不对

参数值不在合法区间

边界 case 没有覆盖

其他（历史遗留 bug、三方 SDK 升级导致、2端沟通不足需求没对齐）

假如我们将第一二类问题解决好，线上问题将会显著改善。这正好就是天网报警的设计初衷，天网报警用于业务异常监控并报警。

天网报警监控并不像 APM 一样是 SDK 去主动监控的，而是需要开发者自己在当前负责的模块、当前开发的项目、当前开发的日常迭代中去梳理关键业务流程和业务场景，对于一些可能存在的异常 case，去埋点上报。

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

### 覆盖率大于90% ###

新 SDK UT 覆盖率90%以上，老 SDK 基于 BDD 通过 基于资源有限的情况下，历史遗留的 SDK 可能无法去梳理并编写单测，那老的 SDK 可以去给予行为去编写 BDD 测试用例，这里不展开描述什么是 BDD 和怎么实践。

针对新的 SDK 在技术方案阶段就需要思考好测试用例并体现出来，开发阶段 UT 覆盖率须大于90%。

### SDK一定要Lint通过 ###

这里的 lint 并不是针对语法、锁进等的 OCLint，而是 pod lint。因为发生过一些情况，就是 MR 提交后，去打包系统打包阶段， 因为 pod SDK 的问题导致的打包失败，所以 pod 的 lint 一定要通过，将问题提前解决掉。

### SDK Warning 清理 ###

SDK 内部的 warning 尽量清理掉，比如 UIWebView 或者某个使用的 API 苹果标记为待废弃，假如你不按时修改掉，万一上线后用户使用的某个功能异常，那就没救了。

### SDK 核心用例梳理 ###

确保接入 App 集成测试，老的 SDK 梳理核心用例，便于 BDD 测试。SDK 的所有功能需要接入至少2个业务线 App 去验证功能和性能是否符合预期。

### SDK Demo 必须体现开发能力 ###

多端 Demo 对齐 SDK 的功能设计、类的 API 多端对齐，能力一致。且在 Demo 上可以体现出核心功能。

### 脏乱差治理并优化 ###

年底统计线上问题原因，经常会发现不管是业务线还是中台，都有一些遗留或者接手的线上问题，所以不管何种原因，都需要 Owner 意识，脏乱差梳理去修复问题。

### 确保测试用例冒烟通过 ###

QA 指派的测试用例一定要冒烟通过，冒烟打回很严重的，这是对质量的不认真，也是对 QA 工作的不尊重。

另外，关键功能限老司机操刀开发，避免形成卡点（进度）或者影响质量，太忙的情况下至少老带新。

核心业务功能，新人很难评估到所有影响面和边缘 case，所以优先老司机操刀开发，或者新人梳理评估出方案，老司机 review 把关，避免因为不熟悉造成进度落后或者线上质量问题。

### 基础 SDK 交叉测试 ###

业务项目有 QA 资源，基础 SDK 不一定有测试资源，需要开发者本身去思考测试用例，包括功能和性能方面，最后可以交叉测试，Android、iOS 互测，确保质量。

![在这里插入图片描述][449549c20306422784bcc89c605494fb.png_pic_center]  
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。

关注我的微信公众号：【**`伤心的辣条`**】自行获取~

我的自动化测试之路，一路走来都离不每个阶段的计划，因为自己喜欢规划和总结，所以，我和朋友花了一段时间整理编写了《软件测试工程师发展规划路线》，也整理了不少【教程资源】，打包好了分享在群里面。有需要的朋友可以进群：914172719 获取。希望会给你带来帮助和方向

**喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！**  
![在这里插入图片描述][a6ced78a433e44298b62d44f3d230588.gif_pic_center]

[5fb87c883155482198a70b4dca710d26.gif_pic_center]: https://img-blog.csdnimg.cn/5fb87c883155482198a70b4dca710d26.gif#pic_center
[449549c20306422784bcc89c605494fb.png_pic_center]: https://img-blog.csdnimg.cn/449549c20306422784bcc89c605494fb.png#pic_center
[a6ced78a433e44298b62d44f3d230588.gif_pic_center]: https://img-blog.csdnimg.cn/a6ced78a433e44298b62d44f3d230588.gif#pic_center