质量保障体系--2023/07/10

前言

测试的核心价值在于保障产品的质量，提效增质；要全面的保障质量，就需要一个完善的体系，从各方面入手来保障产品的质量，本次将以传易互联--音乐项目的质量保障体系进行分析，从而探索质量保障体系的设计

大纲

传易音乐质量保障体系
质量保障体系的设计理念
质量保障体系落地
传音音乐质量保障体系理想版

传音音乐质量保障体系

质量保障体系是为具体业务服务的，因此需要结合业务特色设计，好的质量保障体系是兼顾质量、效率、成本，的一种综合性的设计

传易音乐业务特点

传易音乐提供面向非洲主要国家的，音频流媒体服务（音乐+音频直播）；主要由内容端+产品端+数据端+直播业务+商业化业务构成；主要特点是服务国家多，语种人群多，终端设备复杂，产品交付链路复杂，基于这种复杂的海外业务特点，质量保障体系，需要兼顾各类复杂场景

传音音乐产品交付体系

传易音乐的产品交互体系如下；参与方主要有产品、设计、开发、测试、项目管理人员；整个链路主要基于tapd平台来进行管理追溯，项目主要由项目管理人员协调跟踪，通过在线excel表格来排期和维护进度。整个链路整体合理，各方都有参与；但也有不足之处，问题如下：

交互体系的缺陷

对用户来说：我们的产品设计风格变动极大，几乎每一个大版本风格都有极大变化；广告太多；不太稳定；
业务：业务缺乏全局的规划，重点经常变；比如这个季度重点发力会员，下个季度就是游戏，突然重心又在广告，产品方面也是，这种混乱局面会导致一系列问题，出现这种问题的原因个人觉得还是管理层对音乐业务了解并不够深；
需求：由于公司是由业务主导的，业务的混乱导致需求没有一个全局的规划，业务方经常会介入研发过程，会导致开发中断，转而开发新的需求；但后期项目方和业务进行了沟通后，需求由三方（项目、业务、产品）协商准入，并于每周四统一进行需求评审，一定的解决了插入问题；
价值：由于公司内部博弈剧烈，且需求没有一个全局的规划，导致整个产品的风格变动频繁，未有效形成产品自身的品牌，且需求的价值无法量化，投入产出比无法量化分析；
研发：需求无全局规划，研发的人员波动很大，经常会出现项目开发到一半，就出现人员抽调情况，导致原有排期受阻；不过研发在每个季度都有大方向的规划，一般是偏向架构/稳定性/成本把控的，基本都能有效落地；
业务排期：开发/测试，排期极度紧张，且每个人手上同时期基本上都有三四个需求，导致业务很难复盘，资料/能力很难总结，人浮于事的后果就是，整个过程很难实现量化，投入产出比很难分析；且研发虽然在架构方面有大的规划，但过于紧张的人效和时间，导致落地会大打折扣，导致上线产品容易出现性能/稳定性问题；
测试：测试方面在年度季度都会有规划，基本就是我于年终/季度末提交下一季度的规划，这些规划会转变为部门的okr由我负责完成（21年的时候，我手底下还有两个人一般意义上是由我这个组来完成），但由于从21年中开始，公司持续在裁员（一起负责测试架构的另外两个同事被裁了），且公司业务中心变动极大，我又开始负责广告业务，基本没有时间完成规划，只有在管理层有需求时，如（预装需求，必须要做稳定性）；线上出现严重性能问题（必须要进行性能治理），才有一段较时间来完成特定的非业务需求；
总体来看，就是没规划、没标准、无数据无法量化、无细则；

传易音乐质量保障体系分析

传易质量保障体系在全面保障质量的情况下，还需要兼顾成本和效率；同时由于海外业务的复杂性，主要是非洲网络环境较差，普遍都是2/3G网络，终端环境配置较低；因此在设计质量保障体系时需要兼顾这种复杂场景。现有质量保障体系如下：

质量保障体系的缺陷

质量保障体系，未做量化分析改造，无数据产出及呈现，很难量化价值；
且体系未制定细化的标准，效果很难衡量；
体系缺乏完整/长期的规划，未能有效的实施和优化；
部分环节/工具，落地不到位，效果不佳，如UI自动化，接口自动化等；
缺失归纳整理，无wiki资料库，能力很难输出和传递；
工具很散乱，未做平台化集成；

质量保障体系的设计理念

质量保障体系，需要遵循全面保障质量；有效平衡质量、效率、成本的理念设计；需要做到质量有数据可量化、有标准可衡量、能落地有效果、可传承可输出、使用成本低

设计理念

有标准可衡量
有能力有效果
有数据可量化
可传承可输出使用成本低,能兼顾成本、效率、质量

质量标准

质量的标准简单理解就是不出问题，因此对问题的定义，就是对质量标准的定义；我们一般要考虑功能、稳定性、性能（前后端/系统性能）,易用性，因此质量标准的建立抓手就是业务，只有基于业务建立细致完善的质量标准才有意义，而有了标准体系才能有效运转

传易音乐的质量标准

以季度为周期，责任主体是按流程、事故原因分担的；一般的功能性故障必现且是主流程的测试承担100%责任（严重级别），用例漏测同理；非主流程的或非必现的且出现概率较高的，严重级别低一级，测试承担主要责任，开发次之；非测试环境出现的问题或发布导致的问题，开发和测试均摊责任；性能或者稳定性问题，视问题类型，来界定责任主体，此类问题测试只承担次要责任；同时问题持续时间，影响范围，也会影响问题的严重性和责任主体；
每年度制定功能性问题合规标准、性能、系统稳定性问题的合规标准；并根据影响时长，影响范围，严重程度来划分问题等级，问题由项目经理统一收纳，并记录责任主体，在季度末由此数据来影响kpi分值；
提测标准，业务主流程功能ok,自测用例执行通过；
测试通过标准，尽量保证无bug遗留或无严重级别/普通级别的bug遗留；同时根据业务类型来确定，功能、性能、稳定性、安全、兼容性、回归策略是否通过；
验收标准，测试不参与标准制定；但会提交一份验收用例给产品、设计、业务方，是否通过验收由他们自行决定；

不足

标准制定的不够细致，只有大的框架；
质量问题，只有线上严重级别的问题才会收纳、复盘；且通过在线excel维护；没有形成长期的工作，数据太少，无法持续分析，很难通过数据来进一步优化；
整个标准落地执行不到位，尤其是提测/验收的标准未严格实施；其针对标准不执行的情况，没有成文的解决方案，很难长期有效针对此类问题暴露风险；

参考

合理的质量标准

标准必须要成文，可落地的，既有大框架，也有细则且与业务贴合的；
必须要数据支持，不建议通过一个简单的excel维护，必须要成习惯，有长期数据；
标准必须要在每个阶段都有（自测/测试/验收/线上），且标准不仅限制于事上，对人员，流程都要有要求；
标准必须要有效，要和kpi、升职加薪结合；
除了以上情况，海外业务由于其特殊性；对系统可用性/稳定性有着更高的要求；业界对可用性通常通过Availability公式来衡量（Availability=MTBF/MTBF+MTTR=系统非故障时间/系统非故障时间+系统故障后平均修复时间）,由此可知，要提升系统的可用性，需要从系统的稳定性和系统的维护性下手；另一个衡量系统可用性的标准是1-5-10（1分钟发现、5分钟定位、10分钟修复），这对系统的架构设计有着更高的要求；
覆盖率标准：代码覆盖率是测试度量的有效手段之一，但是要均衡覆盖和成本，做全量代码覆盖不太现实，而且很难做到精细化；在日常迭代过程中，增量代码覆盖率更加直观，可以对每次代码变更做精细化的覆盖率管理，持续提升代码覆盖率。做覆盖率分析是要考虑影响范围，需要考虑（变更导致的调用链路，及链路中受影响的函数；同时也要考虑多链路下其他的分支）
问题率：质量体系最重要的点是保证质量，因此不出现问题才是质量保障的核心；

部分细节如下：
增量代码覆盖率原理

覆盖范围

理论上质量保障体系要全面的保障质量，方方面面都要覆盖，但实际工作中要均衡考虑
范围

流程：流程把控，流程优化
测试环节：codereview、单元、集成、系统
类别：性能、兼容、稳定性、监控、功能、安全

测试能力建设

能力建设，一般是指自动化、工具或平台研发能力；但实际项目过程中，协作能力也很重要,这里讲讲工具/平台的建设

工具/平台价值

解决手动测试无法解决的事，如稳定性测试；
自动化测试执行是按固定逻辑来的，能实现执行标准的统一；
提效，可用于解决大量的重复性工作的场景，节省人力，提高效率；
有数据，可溯源；有利于沉淀数据和能力，精准的分析解决问题；

质量保障体系三要素：质量活动、工具平台、质量流程

以下按这三块来分别讲述质量体系的构建

质量活动及测试执行

在测试策略方面保障质量；主要有两种思路①根据问题设计策略，②分析流程来设计策略

根据问题来设计策略

发现问题，分析问题，从而预防问题

需要一个记录问题的‘小本本’，记录下问题、然后分析问题（做复盘，是共性、还是特定问题、是否经常出现）、然后设计策略来预防此类问题；如app经常崩溃，那么质量活动需要包含此类检测；
可以拉取最近一年的线上数据分析，来发现问题；

分析流程来设计策略

研发过程中的各流程都有可能出问题，本着早发现早解决的原则，在各流程设置卡点，来规避风险，同时各环节也可以设置多条防线，全面的保障质量
如以下情况

Case1: 业务有很复杂的业务人员配置流程，这个环节会引入业务配置问题，可以在这个环节后定制质量活动，如配置规则校验，配置预跑等。   

Case2: 业务在运行时仍有新机构/新商户接入环节，可以定制质量活动，如新接入时进行联调验证、性能压测。

Case3: 业务有间隔性的数据跑批环节，那么在每次数据跑批结束后，可以定制质量活动，在每次跑批后做结果验证。典型业务有日切，月账单生成，关键报表生成等。

工具平台建设

建设工具平台，需要把握好成本和收益；至于如何平衡成本和收益，我的想法是这样的；有些工具是必须的如预装的压测，这种成本不是重点，先必须做出来；但有些比如前端功能测试，研发成熟的ui自动化成本比较高，那可以先考虑部署开源的成熟的产品（或者先手工替代，提前做好回归用例的有效性分析来降低成本）

质量流程

质量流程要平衡好质量防控，和效率；要贴合业务、研发体系来设计；并且要结合实际情况，及时调整

质量保障体系落地

在具体落地的过程中，要把控好，质量、成本、效率，做好均衡来设计具体的质量策略
具体落地的策略

具体的质量策略，要结合业务；最好结合业务数据，做量化分析制定；
评估质量、效率、成本现行情况，做好平衡；
策略要具体，要能保障项目的一致性，形成共识，实现质量标准化；

举例

比如，质量保障体系规定了要做灰度发布，那么怎样做灰度发布？质量策略可以进一步规定执行细节：至少要包含从1%->10%->50%->100%四个阶梯的灰度，且灰度时长不小于2小时。

再比如，质量保障体系约定了低风险项目可开发自测，那么质量策略可以进一步定义低风险项目包括bug fix，页面展示修改类项目等。

再比如，质量保障体系要求回归测试要完整，那么质量策略可以进一步定义完整回归的具体要求：全部P0P1用例(不区分手工自动化) or 全部自动化用例 or 人工评估的所有场景用例 or 代码变更分析的所有自动化用例 等。

质量工具/平台具体落地的策略

提效；要综合提效；代码不是目的，提效才是；
要有具体落地的场景，一个质量工具平台最好能锁定某个稳定存在的质量活动、防线作为服务对象，以保证质量工具平台自身的存续性；
维护/使用/培训成本也需要考虑；
设计时要考虑能力沉淀和输出，最大化工具的价值；
要尊重历史积累，考虑历史工具数据沉淀和价值挖掘；
避免重复造轮子；要做到工具平台信息的充分共享、及时刷新，避免因信息不足导致的重复造轮子，其次在有同类工具平台新建初期，及时发起评审，确定定位和发展路线，避免发展成已有轮子的复制品。最后，要在大横向组织里阶段性review同领域工具平台，做好顶层设计（定向发展or关停并转）；
要做好工具的服务推广，工具的价值在于使用；
要保证工具平台体系的持续发展，需要有统一的度量指标，否则难以运营迭代；服务好业务和需求，阶段性考虑质量工具平台的整合、共建、打通，串联形成工具平台体系，形成一致性的服务体系；
需要考虑工具间的集成，结果的集成，联系，实现持续集成；

先保障基础的平台有，如组织协作的平台，bug管理平台，代码托管平台；
要做好整体规划；分析缺口，必要的工具优先做,但要保证效果（覆盖率，发现率，召回率，准确率等），效果越好越有价值；
非必要的一般是提效的工具，在进一步拆分工作，分析日常工作中各部分工作的占比耗时，以及未来的趋势，优先覆盖重复性强场景；
提效工具要做好性价比综合分析，对比人力或其他工具，当新开发工具的成本（一次性开发成本和维护性成本的考量：接入成本、迁移成本、培训成本、每次使用成本、维护升级成本）相对于收益有明显优势时才有价值；
在devops研发体系、云原生等架构升级中，质量工具做好设计要支持整合同步升级；
自动化测试体系，数据构造是一块很大的工作；可以基于线上流量采集回放的方式；为自动化各环节提供数据；

参考：阿里国际团队质量工具平台的设计方案

针对质量工具/平台各环节，进行了归纳

单元测试

存量老代码，缺乏单测的情况下，需要方案实现快速补全；
复杂系统或者模块，构造数据成本很高，需要有工具支持；
系统重构，单测容易大面积的失效，需要在设计时考虑如何解决；

如下是阿里国际团队的解决思路

接口测试

海外业务，由于多集群，多站点的特点，用例的维护成本很高，且会持续加大；因此在用例构造上，需要加大自动化，减少人力投入

在用例收集上，自动收集、分析、自动去重重复用例，就可以自动沉淀用例集，同时也需要有人工输入专家维护，提升特征丰富度和用例覆盖率。

在用例管理上，弱化了传统相对复杂的用例集管理功能，使用系统托管的方式进行用例维护，并且用例运行时自动根据多租户、合规等条件进行调度，保证准确性同时降低人工介入成本。

在回放结果上，通过对错误、断言等聚合分析，有效减少失败分类数量，降低人工排查的成本，并在运行后提供代码覆盖率和业务覆盖率度量结果。

如下是阿里国际团队的解决思路

集成测试

集成测试是针对局部业务，或者模块单元的测试；可通过功能测试实现，但实际工程中可能会存在功能无法覆盖的情况，此时需要通过mock来构造数据，通过模块单元的代码的测试来实现覆盖，关于集成和单元的区别如下

用例/工具持续集成

持续集成，能实现定时/持续调度，能实现定时监控，用例有效性监控，结果聚合，同时进行串联能保证服务的一致性，形成全链路、全覆盖的质量展示，架构如下

环境管控

环境的稳定性，会直接影响开发测试的效率；同时环境还需要兼顾成本，毕竟预算有限；同时作为服务海外用户的公司，我们对海外环境也有需求；
测试环境问题

测试效率问题：测试环境的稳定性，会严重影响上下游测试效率；
测试环境资源问题：需求高峰期并发，涉及测试环境抢占；需求低峰期，多余测试环境被闲置；
测试环境隔离问题：子域内需求需要相互隔离；子域之间快速支撑联调；
测试环境使用成本：测试环境答疑成本，以及构建成本；

其中的难点
支持隔离：测试环境隔离支持同步接口/HTTP服务和异步消息隔离；
弹性部署：测试环境资源根据需求情况，弹性占用，同时也要控制预发环境膨胀的问题；
环境问题定位：往往业务问题、系统问题都会被上报为环境问题，导致排查耗时，如何快速定位问题？
各环境如何保障长期有效，更新同步；

魅族通过集群的方式，实现固定节点放置固定服务，进行标准化，通过代理/路由的方式灵活指向服务机器，来实现隔离，弹性部署；

环境流转的实例（阿里）

保证环境稳定性的思路（阿里）

针对海外/业务特点考虑的落地策略

由于业务在海外，会有数据安全和监管的考量（数据不允许出入境）；测试数据、测试用例运行维护会面临一定挑战；
海外业务，由于要部署多个国家，集群分散，站点众多，测试工作量会大幅提升；
由于业务复杂度较高，且研发有着自测和联调的需求，需要提供工具支持，针对后端接口的自测和联调，现在使用的是免费的工具apifox（提供团队协作、接口管理、mock、调试、压测、联调等能力)

质量流程

要保障质量，但靠人和工具是不行的；还需要一套完善的流程，从工业界的角度考虑即SOP(标准作业程序)，即给整个交互体系，制定一个细化且可量化的流程，sop的价值如下：

流程可量化，有线上数据，正因为如此，才可以进一步的运营和优化；有数据才可以判定价值；
有细致完善的标准，才可保障产品和服务的品质，才能保证有效的覆盖率；
sop还会使整个链路更清晰，从而保证各环节互不干扰，能大幅提高交付效率；

如何建立一个完善的sop流程

要建立完善的交付体系，需要从业务入手；发现现有体系中的问题，聚集关键节点；加强组织协作形成共识；通过线上流程管控沉淀数据；基于数据分析运营优化不断迭代，推导过程如下

参考sop体系如下，核心：筛选关键节点/问题+线下会议对焦+线上流程管控+数据分析优化

SOP研发体系运营和落地
标准作业流程要想产生价值，需要做好运营和落地，但具体的实施还是要和业务结合

• 落地方式：
  • ①通过架构升级的方式来推动落地,建立目标，推动前进；
  • ②绑定kpi、okr指定责任人来，分阶段推动落地，在落地过程中要持续观察数据、分析效果；

SOP流程运营目标（阿里参考表）

SOP数字化参考报表

传音音乐质量保障体系理想版

质量保障体系是用来保障质量的，没问题或者问题变少了就是最大的价值,具体来看

通过量化数据分析，质量问题，通过结果来确定质量保障体系的价值；
分析具体的问题和结果，有问题就能找到体系薄弱点，进一步优化；结果好，也需要确认价值在哪，是否能进一步细化深化优化；
最后分析质量工具平台的支撑度和技术价值，针对性的实现价值量化可呈现；