1.测试主要是检查开发实现的功能是否符合产品的预期，通过设计和执行测试用例，尽可能发现软件中存在的缺陷问题，测试的目的是找出问题，然后推动技术修复，达到产品预期的交付质量，测试是质量环节中的重要一环。
2.质量是比测试更广泛的概念，它涵盖了软件的整个生命周期，不仅需要关注测试阶段，也要关注包括但不限于需求产出、需求评审、设计评审、代码review、发布阶段等容易引发产品问题的各个过程阶段，最大限度的减少缺陷问题的产生或追赶发现问题的阶段，尽早暴露并解决，将损失降低至最小。
其次，从测试负责人转变为质量负责人，我们自身也需要做出一定的改变：
1.首先是思维的转变，需要跳出测试思维，全局考虑软件开发到交付周期中，团队不同职能可以做哪些事情来提升产品的质量，从某个业务的功能测试，转变为更专注产品整体的质量目标。
2.需要参与到项目流程的各个阶段，挖掘不同阶段中存在的质量问题，进而推动解决，提升质量。
3.提升沟通协调能力，将自己作为团队的中间枢纽，连通各个职能，建立职能间的密切沟通合作，确保质量目标的充分实现。
4.提升风险评估能力，快速有效地识别产品质量风险，制定标准化的风险应对手段，进而保障产品质量。
总之，从测试到质量，也是从个人到团队的转变，相信大家也都听过，质量是设计出来的，不是被测试出来的，那我们就不能只做测试的执行者，要做质量的设计者，发挥QA更大的价值。
下面从成熟迭代类业务和短周期业务分别总结分享下，基于不同的业务发展阶段，以及不同的业务特色，我们应该如何去识别质量问题，以及如何提升产品的质量。
02 成熟迭代类业务的质量建设思路
这部分主要结合之前参与过的某厂toB垂类项目，介绍下成熟迭代类业务的质量建设思路。
首先简单介绍下业务，该项目核心业务是为B端客户和C端用户建立桥梁，帮助B端客户快速达成交易，C端用户得到优质满意的服务。平台需要为B端客户提供一定的会员权益，如检索推荐、曝光、线索等，达到平台预期的客户续费率；为C端用户提供精准搜索，快速触达客户的能力，满足用户定制化诉求。
其次质量建设通常可以从两个方向出发考虑，一是自下而上，以项目交付流程为载体，主动分析各阶段过程中容易引发问题的地方，做质量防护建设，这部分可以直接借鉴一些业界通用的典型的质量建设方案；二是自上而下，从业务暴露的问题分析做质量改进建设，这部分就需要结合不同的业务特色，做定制化的质量建设方案。
1.
从项目交付流程出发
以项目交付流程（CICD建设）为核心，质量建设通用思路模板参考：
需求管理：明确需求开单规范，拆分规则，文档管理规范；
需求变更：需求变更需要有对应的准入机制，避免随意变更或插入；
需求排期：需求排期及阶段状态由单子跟进，并建立相应的提醒机制，包括需求提测、提测延期、测试完成、走查提醒等；
工作流配置：技术代码提交&发布流转、QA用例&测试状态等所有项目工作流均挂钩需求单子，便于项目管理及后续质量数据采集。
2. 开发：
技术评审：项目开发前，要求技术发起技术评审，确保前端&QA对技术实现的互通，以及高工对本次技术实现方案的把控；
接口文档：要求后端开发前提供完整接口文档给前端，以及接口文档的规范管理；
自测质量：可以借助IDE，建设单测自动生成能力，降低技术单测编写成本，提升自测覆盖率，进而保障提测质量。
3. 准入：
自动化测试：建设核心业务的自动化测试能力，包括接口自动化、前端自动化、接口diff、性能diff等基础拦截能力；
静态代码扫描：引入通用静态代码扫描能力，也可以加入一些业务定制化的规则做拦截；
准入评估：建设提测准入评估能力，通过自测覆盖率、接口自动化、静态代码扫描以及人员风险等指标，引入质量度模型，评估质量系数，进而判定项目风险，为后续项目执行不同的发布策略做参考。
4. 测试：
环境搭建：建设测试环境自动搭建能力，保持与正式环境一致的部署方式，配置数据能够做到自动同步；
用例评审：针对重点需求，提测前QA需要发起测试用例评审，也是各方对需求的再次对齐，过程中往往可以发现较多的需求漏洞问题；
数据构造：建设通用的数据构造&接口mock能力，支持多个异常场景的快速构造，逐步积累能力，降低新人或换人测试成本；
测试质量评估：测试完成后，与准入评估一致，可以通过测试覆盖率、bug数、人员风险等指标，引入质量度模型，评估测试质量系数，判定交付项目风险，增加准出评估能力。
5. 发布：
发布拦截：针对不同发布系统，发布失败时有相应的自动拦截能力；
变更拦截：针对程序变更、配置变更，建设0级case、精细化、场景化的自动拦截能力。
6. 线上：
服务监控：建设完备的线上监控能力，服务资源、页面核心元素、接口可用性、服务稳定性等，确保各种异常情况下，问题能够做到主动召回，将损失降至最低；
自动定位：建设线上问题的基础自动定位能力，如果涉及多模块，可以通过logid打通各模块间的调用，通过链路拓扑逐步分析错误日志信息，给出初步排查结论，辅助问题快速定位&解决闭环；
稳定性：建设系统稳定性指标，关注第三方服务和自身平台稳定性；
混沌工程：定期组织故障演练，验证系统自身保活能力。
当然底层基础能力的建设也是必不可少的，也是支撑各环节顺利执行的基底和牵引，主要包括：流水线、系统测试平台、自动化平台、覆盖率计算能力、智能客服、数字化分析等。
可以看一个相对完整的CICD流水线示例：
可以看到这个流水线执行任务是比较多的，如果是小变更的话，执行时间也会很长，后期也确实暴露出了流水线单次执行时间过长或任务经常失败的问题，此类情况下，可以考虑引入智能构建策略，同样是以需求单来挂钩，通过增加一些定制化字段，触发不同的流水线策略，执行不同的任务，在保障质量的前提下，提升执行效率；另外针对任务执行失败的问题，可以引入智能客服，辅助技术自行解决失败任务，降低QA人力投入。改进版流水线示例：
综上，通用的质量保障体系可以总结为在一个规范的流程机制运行下，以数字化指标为牵引，在项目各流程各关键阶段贴合业务特色建设一定的自动化质量保障&拦截能力，使得系统服务是可持续集成、可持续部署、可持续监测的。
2.
从问题出发
这部分主要介绍下，结合业务特色，从问题出发应该怎么去设计定制化的质量改进方案。同样，我们也可以参考一个通用的思路模板：
1.质量问题的暴露：线上问题的减少，是质量改进的首要目标，从问题出发做改进思考，也是最有效的分析角度；
2.问题聚类分析：线上问题聚类分析，可以看到各类问题的占比，辅助我们判定改进建设的优先级，质量建设更有方向性，另外同类问题反复出现，那也一定是我们需要首要改进的地方；
3.改进方案制定：针对不同类型的问题，寻找适合的改进手段，制定针对性的改进方案；
4.体系化改进建设：一个问题的出现，需要思考后面会不会有类似的，从单个问题到一类问题的解决，才是更有意义的改进，这也要求我们需要有体系化的建设思维，养成深度思考、动态思考、全局思考的做事习惯。
下面结合业务发展阶段以及暴露的问题，简单介绍下不同阶段面对不同的质量问题，做的重点改进事项。
1）业务发展初期
项目主要为了达到快速上线的目的，尽快落地满足客户/用户需求，QA重点关注业务功能测试，线上问题的反馈基本来自客户/用户侧，问题无监控召回能力，无自动拦截能力；另外初期对项目流程规范关注度低，流程导致的质量问题也逐渐露出；业务无数字化能力，无法直观看到项目基本质量，无法观测系统质量，质量改进无指标牵引。
因此，初期我们主要进行了一些业务的基础建设，包括：
【项目流程】建立标准化项目流程规范&质量红线，各阶段不同职能需要完成的事项，达成的指标项，在业务范围内达成共识，确保无流程不规范导致的线上问题露出，完整的流程规范参考：
【监控建设】从页面展示、后端接口、底层日志、业务数据效果进行分层监控建设；针对重点业务，如会员权益、订单生命周期等，单独提取做专项监控完善。完整的分层监控包括基础层、应用层、业务层，指标类型包括功能效果、业务指标、稳定性指标，参考：
【质量数字化】建立质量数字化体系，制定业务核心质量目标和过程指标，以目标驱动，定期关注质量基本盘，观测并有效度量线上质量，牵引质量改进工作，辅助业务改进决策，数字化指标参考：
【CICD建设】建设基础的CICD拦截能力，提供项目准入准出测试能力，如接口&前端自动化、接口diff测试等，提升测试覆盖度，提升测试效率。（CICD参考第一部分）
2）业务发展中期
平台能力的不断扩大，业务流量的不断增长，项目中期暴露了较多系统问题，如拓展性不足、性能较差、代码冗余导致的开发效率低，小改动引入大问题等，系统稳定性未达预期。
因此，中期我们主要做了一些针对性的专项改进，包括：
【技术债清理】由于项目前期的快速迭代上线，QA基本只从功能进行测试，很多底层设计不合理问题，随着业务流量的上涨，逐渐暴露出来，也影响了研发效率，同样的我们也是从问题归类分析出发，从坏味代码、低效代码、无用代码三个角度，结合静态代码扫描、监控、自动化及白盒测试工具等，同时与技术负责人对齐技术债的清理和问题闭环原则，建立有效的跟进机制和效果度量指标，成立质量改进专项，助力了业务质量的提升。
【性能提升】监控建设初期已经暴露了部分接口性能差的问题，但由于优先级低，技术也未做深入定位，问题一直被搁置，也是借助上述技术债清理专项，我们单独成立了性能改进小组，引入了代码性能分析工具，辅助技术快速定位到性能问题根因，助力问题得到了有效闭环；同时建立了redis、SQL监控，排查了所有慢SQL、缓存未生效或缓存设计不合理问题，助力平台性能得到了有效提升。
【稳定性提升】由于平台涉及第三方服务较多，稳定性依赖较强，这部分主要通过系统架构梳理，建立了标准化第三方服务代码调用模板、监控模板；排查自身服务单点部署、单点依赖问题，避免单点挂掉导致系统整体挂掉；定期进行第三方故障演练，验证并排查自身系统稳定性问题。
【反馈通路】用户反馈问题无统一收口，前期靠运营人员线下收集或邮件反馈，为提升效率，也为全局分析线上质量，建设了统一的问题反馈平台，所有外部问题收口，同时建立了明确的问题跟进闭环机制，与运营产品达成目标一致，不断提升客户/用户满意度，助力业务稳健发展。
3）业务发展后期
业务后期质量基建已经较为完善，且线上质量基本趋于稳定，考虑到垂类行业、平台内容质量、以及突发舆论或政策改动等很容易引发产品风险或舆论风险，因此QA开始协同产品和运营着手业务赋能的专项改进，包括：
【风险体验挖掘】主要通过结合线上badcase分析及客诉问题，从平台风险、用户/客户体验、热点风险、死链监测、内容质量等角度出发，利用定时巡检脚本、本竞品数据diff、热点监控、NLPC语义分析、文本图片相似度分析等技术手段，做一些线上风险问题的挖掘，来辅助提升客户/用户体验。
【客诉反馈治理】建立了标准化的L3层问题反馈机制，针对每层责任人制定响应&解决时效，明确产品和研发责任划分，L2层产品团队负责问题流转效率，对问题响应、解决效率负责，L3层研发团队负责产品问题的响应，对问题的解决质量负责；其次协同产品运营整理常见问题FAQ、提供智能答复等自动化解析工具，减少简单问题的人力投入，助力产品客诉问题24h解决率目标达成。
这部分业务特性较强，这里不展开详细介绍，只介绍下思路。
综上，在通用质量保障体系较完善，可以保障80%质量的情况下，剩下的20%是需要我们紧贴业务特色，紧随业务发展，持续在不同阶段不同问题背景下，做一些定制化专项化的质量保障。以及QA需要做的不仅仅是业务测试工作，更需要保持业务质量风险的敏感度，强化自己的体系化结构化思维，为业务持续稳定发展负责。
3.
短周期类业务的质量建设思路
这部分主要讲一下，加入网易后参与的短期活动类业务，简单分享下目前的建设思路。
首先分析下这类业务的特性，与成熟类业务的区别：
1.短期活动，线上运行周期短，非稳定持久化业务
2.业务流程有一定共通性，玩家角度大致是活动时间限制->参加活动的玩家条件限制->参与活动完成任务->奖励领取条件限制->发放奖励
3.活动类型有一定重复性，如换肤、人拉人、年度数据回顾、赛事等
4.活动功能有一定重复性，如登录、发奖、分享、排行榜等
其次分析下团队特性和基础建设现状：
1.团队各职能外包占比高，质量意识相对较弱
2.每个项目都是新活动，且涉及多个游戏，固定化的项目流程无法满足所有场景，大多数人的感受是 "乱"
3.测试手段单一，业务基本是手工功能测试，且大部分基于需求进行测试，对底层代码关注度较低
4.基建平台能力较弱，建设自动化、监控或CICD能力无法快速实现
下面简单分享下如何结合遇到的问题，结合业务特色，逐步做质量改进建设，举几个例子说明：
1. 活动类业务涉及配置较多，如活动名、活动时间、活动地址、奖励配置、分享配置等，线上也经常出现配错的问题，可以从以下方面进行改进：
1）业务梳理：由于业务对接多个游戏方，涉及到的活动配置平台较多，因此首先需要梳理清楚有哪些配置平台，不同业务的配置流程是什么样；
2）配置规则：增加配置规则校验，增加错误配置自动拦截能力，这里需要基于问题，基于业务，梳理校验规则（如正式环境test拦截、正式测试配置diff、地址规则校验等），全局排查添加，而不能只针对单个case单个平台增加校验；
3）减少中间步骤：如分享配置目前需要产品提供，然后技术写入代码，再到QA配置，后续考虑由产品通过平台配置后直接生效，去掉中间环境，进而减少出错。
2. 项目提测质量低，专题活动基本线下bug超100个
1）冒烟测试流程：在没有任何自动拦截能力的情况下，首先想到的一定是推冒烟测试流程的执行，但由于各职能业务任务都很重，加上流程排期较乱，以及无人监督，冒烟流程一直执行效果不佳，针对此类现象，首先分析了下原因：
QA内部：在线用例平台不符合组内写用例习惯、并行项目多没有时间写用例
技术侧：用例提供太晚，一般在提测后；测试用例看不懂，不知道怎么执行
针对此类问题，QA内部快速低成本搭建了一个在线用例管理平台，内部对齐了用例管理规范、用例编写规范，并整理冒烟执行技术侧操作指南，过程中持续收集大家执行遇到的问题，降低执行成本，并且定期整理冒烟执行效果，推进提测质量的提升；另外针对提测前给不到用例的情况，持续提取一些业务通用功能点的冒烟用例，保障在QA时间紧张的情况下，有一份通用的执行用例给到技术，能够保障基础功能的提测质量。
2）自动拦截能力：除去冒烟用例，在提测前如果能有一定的自动化拦截能力，也可以降低低级bug的QA投入成本，但是对于短周期类业务，构建什么样的自动化能力，如何构建是需要我们深度思考的（这部分目前还未实际开展，这里只简单介绍下思路方向）：
(1)识别重复性工作，提取可自动化的地方，比如每个活动都涉及登录、分享、发奖等，对于技术来说是通过组件化来降低成本，那对于QA而言，也可以寻找相应的组件化测试方式，实现场景自动化测试；
(2)针对复用需求，编辑功能复用，技术代码复用，只需修改简单配置，那QA同样也可以维护一套自动化用例，做到测试复用；
(3)从尽早拦截问题的角度，最有效的方式是代码单元测试，但是对于目前来说，时间紧，项目任务重是比较大的阻碍，那从QA的角度，可以思考如何能够降低技术单测编写成本，提升单测覆盖率，比如自动生成单测框架、自动生成单测用例，目前都有比较成熟的框架，后续可以做调研参考。
3. 质量可视化
对于当前业务，质量度量指标是不够明确的，部分改进实施起来缺乏抓手、依据以及效果验收，需要逐步构建一套完整的数字化指标，牵引全面高效的质量保障体系。
1）目标可视化，根据业务状态，聚焦当下主要问题，确定观测目标，低成本收集数据，监控产品质量；
2）过程可视化，要达到好的目标，最关键的还是在执行过程中，因此在每个阶段也需要制定一些合理的小目标，确保过程数据可视化，也用于指导过程中问题的解决，通过数据驱动实现问题的快速闭环。
总之，在做事情前明确出来自己的目标是什么，从多维度制定合理的评估指标，将数字化手段作为提升系统质量的重要抓手，会让质量决策更有依据，改进更有方向性，结果也更可控。当然指标不是一成不变的，也需要随着业务和团队的发展变化，不断做调整和优化。
对于目前负责的业务质量建设，还未能形成体系化，本次只分享几个从问题出发的改进思路，待后续持续完善。另外目前组内一些基建平台的支撑度也相对较弱，后续在实际开展改进时，也会考虑选取公司或市面已经成熟的质量平台，减少开发成本，在满足质量目标的前提下，尽量降低人工维护成本。
最后再来回到分享主题，质量保障不是QA，也不是其他某个单一角色可以做到的，需要不同角色不同视角的输入，以及需要全员参与并承担起质量责任才可以，但是QA作为质量首要负责人，需要主动发挥更大能动性，牵引调动全员提升质量意识，发挥主人翁精神，从测试跳出到质量来思考问题，将视野扩散到项目整个生命周期中，关注质量各个维度，才能更好的建立体系化思维，更好的做好质量保障工作，也更有助于个人成长。本文提到的各种质量改进经验，希望对大家有所帮助。
推荐阅读
