保利威敏捷开发之下的软件质量控制流程

从 2016 年开始建设到现在，保利威视频云 SaaS 直播平台共拥有六大产品矩阵，通过无延迟直播、点播、MR 直播、直播咨询、运营、直播舱等核心产品与服务，为客户提供全流程、全链路视频直播运营服务。

自笔者 2018 年加入保利威以来，视频云 SaaS 的软件质量控制流程建设共走过 5 个年头。本文讲述了保利威在不断建设完善的产品矩阵中，QA 团队是对质量是如何思考和落地的。

如何理解质量

2020 年的疫情打破了许多常规，大量线下活动迁移到线上进行直播，超高并发需求对保利威的稳定性挑战很大，我们在快速迭代中对平台做了一次又一次的稳定性重构，最终在上量几十倍的情况下稳定支撑客户的业务上量。那个时候，保利威 QA 团队对质量做了深度思考：好的质量决定我们走得多远，也决定了品牌价值。

雷军在十年演讲的时候曾提到：质量决定我们走得多远，质量是整个公司的生命线。保利威 QA 团队非常认同这个说法，但是质量的提升改进是一个非常痛苦且繁琐的过程，甚至短时间内看不到疗效，以至于大众都会质疑：到底行不行？QA 怎么干活的？

保利威 QA 始终坚信：面对所有困难，稳住阵脚最重要，质量就是保利威的阵脚，只有稳住质量，才能寻求突破，品牌价值也会随之提升。

软件工程交付质量到底有没有银弹？

想清楚质量方向后，回到软件工程现状：存在质量误区，认为零缺陷，没有任何问题就是质量。

下面通过手机制造业的挖孔技术例子，感受下质量的本质。假设有 X、Y 两个工厂，你会选择哪个工厂？答案当然是 Y 工厂，因为 Y 更靠谱——用户的使用体验审美差异小，更好感受。

保利威 QA 团队也从中思考质量的本质：对差异性的控制越来越强，质量也越来越高，在实际软件工程中至少有五个维度可以减少方差：

1. 产品线需求偏差小（产品）；

2. 研发过程控制偏差小（PM）；

3. 交付质量差异小（QA）；

4. 技术对接体验偏差小（PaaS）；

5. 售后处理问题偏差小都能够提升质量。其中 1-3 的具体实践，后面会着重介绍。

质量的本质指的是差异性小

思考透彻之后，保利威 QA 团队直面问题：质量的本质是方差小，也就是差异小。

通过比较有画面感的手机开孔示例，知道减少差异性，可以带来更好的质量（美观体验）。但如果对差异性解决的时机太滞后的话，修复代价也很高，下面这张图，展示了差异性（缺陷）修复与时间、代价的关系。

上图中，橙色线条代表了传统测试发现缺陷的阶段，大多数集中在功能测试和系统测试阶段被发现；红色线条代表发现缺陷所带来的修复成本。

由此可以看到，越后期修复缺陷的成本就越高，且呈指数增长；缺陷主要是开发前期引入的，前期缺陷修复成本很低，及早发现缺陷，降低差异性，测试质量工作越早介入越好，将测试质量工作左移，当然这些工作测试人员不是唯一参与的角色，还有产品、研发、SRE、售后等等，应当是整个软件生命周期开发过程中涉及到的所有角色。

保利威对质量的思考

相信大家都看过 2022 年世界杯，以踢足球为例，到了最后拼点球来决定胜负的时候，整个现场的紧张度是非常浓烈的。这个时候，拼的真是守门员的各种素质，守门员和球员的压力也是巨大的。

保利威 QA 团队不希望发生这种到最后来拦截点球的局面，始终认为 QA 不是产品质量的守门员，产品需求确定，研发写下第一行代码就决定了产品质量，QA 拦住 bug（所谓的守门）只是基本技能。从长效质量价值看，QA 就相当于教练，通过各种质量保障机制规范来提升产品研发人员的质量意识，并提供完备的质量服务提升研发效能，从而提升产品的质量。

换做在球场上，QA 作为教练，需要有上帝视角，看到全局情况，排兵布阵，把控整个赛场的过程控制，进行合理的攻防布局，消除协同风险的隐患。

同样回到整个敏捷开发的软件质量控制过程，QA 要把质量的能力体现在工程质量左移和右移上，例如：在整个研发流程中，QA 人员通过自动化、工具化、平台化的建设提升测试的效率显得尤为重要：

1、能力左移前置【预防：长效质量】：从需求阶段参与进行需求测试消除含混性，编码过程要求研发出设计说明和强化冒烟自测环节，在集成阶段提供持续集成、自动化构建及早发现问题、让代码进入提前研发自测、产品提前介入验收减少进入到测试阶段的问题数；

2、能力右移后置【拦截：纠正当下】：提供平台构建回归和全量自动化测试拦截变更带来的穿质量穿透问题，以及灰度测试把部分测试难以覆盖模拟、场景复杂的测试交给市场验证，都是需要通过高效的策略手段，来保障产品交付质量。

保利威软件质量控制是如何做的？

通过以上质量思考，保利威 QA 团队认为长效质量控制至少围绕三大要点：研发过程管理、质量数据度量、灰度发布和线上巡讲，来开展质量的生产力改造。

研发过程管理

首先来看看研发过程改进，围绕敏捷开发流程、研发代码质量控制、周版本负责人机制，在需求分析的时候需要考虑商用价值以及包含非功能性的评估（需求安全和性能两个维度），整个研发过程的落实也引入不少持续构建的自动化测试支撑。

Scrum 敏捷过程管理

我们认为项目管理并不能直接提升产品质量，在失控的过程管理中，投入再多测试也不能直接、立马提升产品质量，因为产品需求在转化为编码任务的过程中已经决定了质量。项目管理更多是：事前预防、事中控制、事后分析。

关于保利威对于项目管理过程的思考可以参考《敏捷项目管理，POLYV 来支招》

目前保利威敏捷迭代开发的策略是：双班车制度。

• 快速版本：每周有发布窗口，重要紧急的关键交付为主；

• 版本班车：每三周一趟，SaaS 产品常规需求迭代交付为主。两种班车的发布，对交付质量有很大的挑战，每周的质量控制会通过周版本迭代负责人机制来解决。

周版本迭代负责人机制

最初保利威的发布节奏是三周一次，面对复杂变化的市场，交付依然不够快；后来调整为每周都有发布窗口，常规一周一次，在足够敏捷交付的前提下，对交付质量有很大的挑战。

保利威周版本阶段要求如下：

为了迭代有序进行，在日常迭代管理、发布执行都归 QA 同学。QA 做好周版本迭代负责人，保障发布质量，牢抓回归卡点、发布执行，以及线上问题复盘等工作，其中每周发布检查清单如下：

目前这些检查清单一些是人工，一些是通过持续构建的流程机制进行通知。

长远来说会逐步统一到研发效能通道上去建设整个过程的持续构建和反馈。

研发对交付代码质量负责

设定静态代码扫描门禁

研发在 coding 第一行代码的时候就决定了编码质量，测试没法代替改变代码质量，但是可以想办法将进入测试的代码质量提高，这样子测试人员能专注更多时间在测试深度上，才有可能将隐藏 bug 发现。

研发代码质量除了常规的团队 CodeReview，还会通过设定静态代码扫描的质量门禁，在研发 commit 代码的时候触发构建，保利威研发团队通过 SonarQube 的一组静态分析 (SAST)规则，查找应用程序代码中的安全漏洞，避免遗漏到线上。

强化质量意识研发冒烟自测

在进入提测之前，为了提高软件质量，研发人员对自己交付的代码质量负责，整合集成上下游代码之后，需要做一次全面的冒烟测试。冒烟测试用例由 QA 提供，执行标注 P0 级别的额用例，开发自测目的是确认系统基础的功能正常，核心的流程能跑通，以确保软件系统能够运行并能够执行后续的正式测试。

通过自测，也提高后续测试工作效率，节约测试的时间成本，减少测试轮数，也避免提测不达标，开发返工，造成项目延期等不必要的情况发生。

需求安全维度评估

在安全扫描/渗透测试方面，保利威 QA 团队以业界安全应用标准最具有权威的“十大安全漏洞"(OWASP Top10)为核心脉络，对 SaaS 平台 Web 端进行全面的渗透测试，包括静态代码分析、动态执行等方式方法测试全面覆盖包括业界关注 TOP10 的漏洞，拦截基本的 Web 安全问题，推动研发和产品改进。

需求性能维度评估

在满足业务诉求的情况下，保利威 QA 团队对平台的并发承载能力进行检查，落实服务器性能指标基线数据，输出平台服务能力的结果指标。

保利威 QA 团队，基于 renren-fast Java 开发平台开发，性能内核基于 Jmeter-Api 和 Jmeter 脚本实现分布式性能压测平台。

在整个性能测试过程，有几个关注点：

持续构建自动化测试

如何在高频发布下保障交付质量，关键还是需要持续集成能力和自动化能力，后面有专门篇幅分享自动化测试的探索思路，这里简单说一下，在每周的交付工作中，有大量持续集成的自动化构建作为辅助检查的机制，好比智能汽车的辅助驾驶。

比尔盖茨在《比尔盖茨——AI 时代已然开启》提到：GPT 表达思想的能力将越来越像一个白领工人，可帮助您完成各种任务。微软将其描述为拥有一个副驾驶。人工智能将完全融入像 Office 这样的产品中，它将增强您的工作——例如帮助撰写电子邮件和管理收件箱。

测试任务的评估依据

ToB 产品的商业价值 &质量非常重要，测试任务的评估分为两个维度：按照产品的质量等级和 ThinkPoint 来做组合，做更好的质量维度的评估。

产品的质量等级：

Think Point 评估依据：增加跟业务相关的维度

质量数据度量

bug 收敛跟踪

研发过程中 P0P1P2 的重大 bug 不能遗漏到线上，通过自研的数据度量平台进行检查

缺陷跟踪复盘改进

通过跟踪需求缺陷密度来把控总体周版本发布质量，分析每个线上缺陷引发的根因，推进产研团队在：流程机制、人员素质、工具建设等多个方面改进。

针对发现的缺陷，保利威 QA 团队采用 5Why 复盘法：对一个问题点连续以 5 个“为什么”来提问，对其进行深入分析。

1. 为什么在预生产环境没有发现这个问题？

2. 为什么 SRE 评审没有发现这个问题？

3. 为什么测试环境没有测出这个问题？

4. 为什么 回归测试 没有发现这个问题？

5. 为什么 Code review 没有发现这个问题？

代码变更可观测：让测试成长

保利威 QA 团队非常关注研发代码变更带来的影响，特别是改动底层公共组件影响到上层业务的情况，我们称之为质量穿透：底层质量问题穿透到应用层。通过质量部门自研的工具平台，收集研发代码变更影响面数据，通过不断调整测试用例提升覆盖度，设定代码行覆盖度高于 90%才准许放行，当然还可以设定更多标准细节，例如 P0P1 需要高于 90%覆盖度、P2P3 高于 80%覆盖度放行，P4 需求研发自测高于 80%可进行测试免测。

在实际工作中，可以抓研发提交代码的一刻开始，持续构建，比较提交分支代码差异，将这些差异所影响函数调用链的 API 自动化用例筛选出来自动构建，同时触发这些 API 所关联的业务方面 UI 的自动化构建，覆盖全链路 API 和业务层。

灰度发布和线上自动化测试巡检

线上灰度发布机制

过往 sdk 播放器存在上线即用的问题，一旦正式发布后，遇到有问题需要紧急回滚播放器，对于质量保障和客户体验都欠佳；

现在通过线上灰度机制，从内部使用、到不同级别客户逐级发布的灰度策略，通过不断验证达到正式发布的质量要求。

灰度发布后，有 IM 系统通知具体情况。

灰度发布需要审批，质量风险定义区分：高、中、低来采取不同的灰度发布策略。

线上持续构建自动化测试巡检

版本发布之后，还有一项持续 24 小时以上的线上巡检，覆盖 API、观看页、管理后台、底层聊天室信令通讯等多个核心业务。

后续质量建设的思考

通过建设研发效能通道，把过程质量的检查点和持续构建自动化能力做成流水线，从研发 commit 代码开始就触发整个通道每个环节的构建，完成当前环节质量检查之后，推送到下一个环节，直到提测之前完成所有质量检查点，让测试人员更加专注系统测试和探索式测试，完成之后推送到自动化回归构建，最终可交付的成品处于等待发布状态。

还有最近比较火的 chatGPT，更多在辅助驾驶层面可以着重探索，后面具体落地再进行分享。

作者介绍

李乐（乐少），POLYV 保利威工程质量与服务保障部总监。