前言
这篇文章实际上构思了很久，如标题所述：如何建立高效的质量保障机制。
在之前无论是写文章还是工作实践，在质量保障机制方面也有大量心得，但总觉得缺点什么，直到前几天写了项目交付系列的几篇文章才豁然开朗。
之前关注的视角大多还是从测试或QA角度出发，但如果从项目角度的全局出发，反而可以将很多的实践经验串联起来，形成体系化的东西。
这篇文章，我想和大家聊聊，关于建立高效的质量保障机制，我自己的一些认知和想法。
思维导图
如上图所示，我个人理解的高效质量保障机制，由下面几点构成：
质量把控：需求质量+过程质量+交付质量；
项目落地：通过不同的项目来达成质量保障的核心：风险可识别+问题可追踪+结果可验证+数据可量化；
交付能力：持续迭代+持续集成+持续发布+持续运营+持续度量（用户和业务是不断变化的，交付能力也要持续跟进）;
标准体系：工程方法+工程系统+专业团队（用专业的团队，采用业内成熟的软件工程方法论来指导工程系统落地演进）;
质量文化：质量+效率（先保障最终质量可控，再提高过程效率，通过节省下来的资源去投入到提高质量的实践和迭代）;
质量把控
关于质量把控，我在前面的文章《复盘归因，提高交付质量的秘诀》中已经做过详细的赘述，这里摘取部分内容。
从质量保障和交付的角度来讲，软件交付生命周期中大体可分为如下三个阶段：
需求设计质量
为什么需要做大量评审工作呢？因为如果在源头存在问题，那么研发过程和后面的用户使用质量，就无从谈起。方向错了，就全错了。
评审最大的作用就是集各个角色(产品&研发&测试)从不同角度对需求设计进行解读理解，提出疑问和建议并进行修正。确保开始就确定方向和需求细节，尽可能降低或者避免遗漏及不合理带来的质量交付风险。
研发过程质量
“软件质量是构建出来的，不是测试出来的”。
测试的本质是验证研发交付的产出物是否达到需求设计及预期的标准。并不能直接带来质量的提升，只能通过种种手段多维度去验证是否达标，并通过流程规范、度量标准等去保障最终的交付物达标。
因此我们常说的各种测试手段，都是验证和保障交付质量的手段，而不是构建质量的手段。
交付用户质量
用户质量指是软件上线后，对用户使用过程进行追踪并采集数据进行评估度量的过程。
常见的评估维度有线上缺陷逃逸率、客诉工单、用户反馈建议、数据埋点等。
项目落地
这里提到项目落地，含义是指通过技术项目来保障上述三点质量把控能更好的完成。
我在之前的文章中聊过流程对质量保障的价值：风险可识别+问题可追踪+结果可验证+数据可量化。上面的思维导图中介绍的五个模块，他们的作用分别如下：
独立项目
独立项目的作用是支撑上述的从需求到交付的过程质量可以很好的进行保障，提前识别存在的风险。
环境治理
环境是我们开展一切测试工作的前提，也是最底层的基础设施，因此环境的稳定性是至关重要的。
但随着业务、技术以及人的不断变化，环境的稳定性越发的成为部分企业技术团队特别是测试团队面临的巨大问题。
关于环境治理，具体可参考我之前的文章：《被忽视的问题：测试环境稳定性治理》。
监控告警
基于不同环境，我们需要搭建完善的监控告警和日志体系，作用是为了更快的识别过程质量中出现的种种问题，并且能做到快速跟踪定位，然后进行修复优化。
还有一点作用是，对问题的可视化展示和记录，有助于后续的复盘归因，让问题的发生得到收敛。
覆盖率平台
谈起覆盖率，我们可能会想起很多名词，比如：单元测试覆盖率、自动化测试覆盖率、测试用例覆盖率等等。扩展一下甚至还包括线上缺陷逃逸率。那覆盖率的作用是什么？
脱离数据讲质量是空中楼阁，我们从各种不同的维度去评估覆盖率，至关重要的一点就是多维度的评估和验证过程质量。
质量大盘
如何理解质量大盘？即从需求质量到交付质量整个周期中，将每个阶段的要做的事情，出现的问题，发生的风险以及结果都进行可量化的记录展示，然后从中进行分析评估，找到不足之处。
质量一定要可量化，质量度量的本质是具体的定量，而非抽象的定性。
交付能力
无论是保障质量，还是通过独立项目或者技术手段来支撑质量保障，都需要持续的某些能力来支撑他们。
这些支撑横向交付的流水线能力，主要包括CI持续迭代-CI持续集成-CD持续发布-CO持续运营-CM持续度量。
持续迭代（ContinuousIteration）
一般来说我们日常工作中的需求，都是通过不断的迭代来持续打磨产品，不断为用户提供更好的服务和价值。
这里的持续迭代，更多指的是业务或者需求上的一种可持续的变化。
持续集成（ContinuousIntegration）
持续集成可以帮助技术团队更加频繁的将代码更改合并到共享分支或"主干"中。一旦对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，
确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI可以更加轻松地快速修复这些错误。
持续发布（ContinuousDeployment）
这里的持续发布包括持续交付（ContinuousDelivery）和持续部署（ContinuousDeployment）。
完成CI中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中，每个阶段都涉及测试自动化和代码发布自动化。在流程结束时可以快速的将应用部署到生产环境中。
对于一个成熟的CI/CD管道来说，最后的阶段是持续部署。作为持续交付的延伸，持续部署可以自动将应用发布到生产环境，持续部署在很大程度上都得依赖精心设计的测试自动化。
持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。
总而言之，所有这些CI/CD的关联步骤都有助于降低应用的部署风险，因此更便于以更快的节奏发布对应用的更改。不过，由于还需要编写自动化测试以适应CI/CD管道中的各种测试和发布阶段，因此前期建设需要很大的资源投入。
持续运营（Continuousoperation）
上面聊到了持续集成、持续交付和持续部署，应用在生产环境发布后，需要持续的跟踪线上质量、用户反馈建议以及线上可能发生的一些问题或者故障。
所有线上的用户建议、可能发生的问题或者故障，其实从本质来说，和交付质量都息息相关。因此这里提出了持续运营，就是提倡质量的把控、验证、度量即使到了生产环境，也需要持续不断的将这套机制运行下去。
持续度量（Continuousmeasurement）
还记得上文中提到的关于覆盖率和质量大盘的内容me？
脱离数据讲质量是空中楼阁，从需求质量到交付质量整个周期中，将每个阶段的要做的事情，出现的问题，发生的风险以及结果都进行可量化的记录展示，然后从中进行分析评估，找到不足之处。这是个需要持续投入的过程。
质量一定要可量化，质量度量的本质是具体的定量，而非抽象的定性。
标准体系
前面我们介绍了需求保障的三个要素，支撑需求保障过程的项目支撑能力以及横向的持续交付能力，但这些都脱离不了标准的体系化支撑。纵向的组织标准化体系，需要工程方法+工程系统+管理机制+专业团队来兜底。
工程方法：即采用业内成熟或者前沿的软件工程方法，来指导这些底层技术工作的开展。
工程系统：工程系统，既包括我们上面提到的CI/CD等基础技术设施，又包含环境治理、监控告警甚至日志管理等。
管理机制：管理是个很复杂的问题，这里我试图借用我之前关于测试流程的一些理解，为大家提供一些视角。
流程是什么？
流程是保障团队目标达成的最佳实践，因人/团队/业务类型/迭代速度/资源紧张程度而异。
为什么要有流程？
没有流程会导致团队中的个体各自为战，目标不统一，进度不协调，资源配给失衡而导致交付质量下降。
流程能解决什么问题？
流程能保障团队或者群体在大方向上保持协调一致，尽可能降低由于团队人员能力、认知水平、资源不足、意外情况导致的项目延期或者质量下降。
专业团队：无论是工程方法还是软件工程系统，甚至质量度量和质量运营，都需要专业的人来做这些事。
综合来说，标准的组织体系，最大的作用是通过实际校验的技术工程建设来保障底层。
质量文化
在软件质量保障领域，质量文化概括来说就四个字：质量+效率。
质量，就是在日常交付中保障软件质量，并且在长期发展过程中，不断提高软件的质量。如何评估质量是否是稳定且不断提升的，就需要引入评估体系，用事实、结果、背后的分析逻辑和数据来证明。
效率，就是提高效率。怎么提高效率呢？引入ROI体系，从交付时间、耗用资源、团队成长方面着手。
有了文化，还要将其拆分为不同的目标。行业在变，组织架构在变，因此目标也要跟随整体的变化而调整。
当然，质量文化是需要不断强调和落地的，这就需要制定一些规则来保证文化的落地效果。这里的规则不是强制要求大家一定要做什么，而是为了避免某些方式对团队不好的影响。常见的规则比如：信息同步机制、反馈机制。
谈到文化这一块，一直是很务虚的东西，很多同学对之嗤之以鼻，2020年之前我也是这么想的。
20年读了一本书：《重新定义公司：Google是如何运营的》。里面对企业文化这一部分做了很经典的解释：企业文化就是指导员工面临艰难选择时，做正确的选择。
内容总结
这篇文章，整体的逻辑在开篇的思维导图就已经很明确进行了概括总结。
建立质量保障文化，通过纵向的组织标准化体系来建设底层的技术基础设施和持续的流水线交付能力，这些能力可以支撑具体的项目落地，而这些项目对需求质量、过程质量以及交付质量具有巨大的提升作用。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
