分享主题是“服务客户，保证质量”。自从20年开始，我们把质量提升到了一个前所未有的高度。为什么会如此重视质量呢？在竞争激烈和复杂的市场环境中，产品质量对于企业的重要性不言而喻。一旦出现了质量事故，对客户和企业本身都会带来非常大的影响。
一、质量的重要性
让我们来看一个例子，2019年3月份，某友商的云基础设施出现了大规模的宕机故障，多家互联网公司的应用和网站陷入瘫痪，事故持续了三个小时以上，数百家互联网公司的业务受到重大影响。该云服务厂商对受影响的客户作出了数额不菲的赔偿。这样的例子还有很多，相比我们之前比较熟悉的To C的产品，To B的产品有着更高的质量要求。用户是付费购买了我们的产品和服务，更关注产品的稳定性和服务质量。同时，To B的产品是面向客户生产业务，帮助客户解决生产问题，为客户创造价值，其产品的专业性和复杂度也更高。因此，To B产品在可靠性、可用性和可维护性上面有着近乎苛刻的质量要求。
二、质量团队的工作
那么，作为质量团队，我们在打造产品高质量上又做了哪些工作呢？
研究传统IT厂商和主流云厂商的质量体系
首先我们研究了传统IT厂商和主流云厂商的质量体系，可借鉴的地方主要包括几个方面：
- 完善的研发基础设施服务：包括研发工具服务和环境服务，极大地提升了服务开发效率和交付效率。
- 端到端的质量门禁：通过自动化测试持续看护，快速反馈质量内建在研发过程中。
- 依赖DevOps流和业务流：打造服务上线安全可靠的高速公路，支持每年超过5000万次部署，超过500个新特性和服务上线。
测试团队的质量动作
结合我们当前的研发重点和实际情况，测试团队的质量动作主要聚焦在研发基础设施能力的完善上面，以服务化的方式提供给产、研支持产品快速高质量上线，主要包括研发环境服务、自动化测试服务、流水线服务和DF专项建设服务。
（1）研发环境服务
为了满足不断变化的用户需求，加快需求上线的速度，多需求并行开发成为常态。研发过程各个活动不同的角色都需要测试环境来支持，包括开发联调、自测试、产品体验、集成测试等等。测试环境的不足，需要大家排队使用环境，严重影响了交付效率。同时，测试环境无法按需获取，也阻碍了相应的质量活动的开展。
测试环境的匮乏主要有几个方面的原因：
云产品的业务架构复杂：服务的依赖多，部署测试环境所需要的资源需求量大，部署成本高。
测试环境部署效率低：部署过程复杂，全手工部署一套测试环境平均需要1~2天的时间。
测试环境稳定性不够：环境的服务质量无法满足业务需要，需要大量的人力来维护。
针对环境问题，我们打造了统一的环境管理平台，首先将测试环境所需要的母机资源、虚拟资源、容器资源等质化管理，让资源充分流动起来，环境动态申请即用即销，避免了资源独占带来的浪费，节省了成本。
我们也践行了“基础设施即代码”的思想，将环境类型模板化，镜像软件标准化，配置搜索与代码化，让整个部署过程自动化起来。这样将传统部署环境流程20多步缩短到一步，简化了整个部署过程，实现了测试环境一键生成。
同时，针对环境的稳定性，我们也通过低成本的容灾设计实现了全链路的容灾能力。每个服务支持多副本部署，并能够根据业务的流量进行动态调整。同时，我们构建了分层监控体系，对组件和资源的状态、接口可用性、业务流量以及异常进行实时监控，快速发现和预防故障，环境的稳定性也得到进一步的提升。
测试环境服务实现了让不同的角色按需生成不同类型的研发测试环境，研发环境数量已经不再是瓶颈，研发联调、产品体验、集成测试等活动的环境都能够按需生成，从之前的两套扩展到现在的50多套并行运行，彻底解决了环境瓶颈带来的效率问题。环境部署时间也从之前的1~2天降低到10分钟，实验测试环境随时可获得，环境的服务质量也接近三个9，整个服务稳定可用。
环境问题的一个彻底解决，在支撑效率提升的同时，也让我们有更多的时间和精力聚焦在质量上面，也让各种质量活动的充分开展成为可能。+
（2）自动化测试服务
快速的质量反馈是研发过程不同角色的一致诉求。我们经常会遇到这样的一些场景：研发同学对代码做了重构，希望快速验证一下是否影响了存量功能；测试同学在评估需求影响时也发现性能风险比较大，如何快速地完成全量的回归测试；一位同学发布了一个新的版本，希望快速基于现网做一次回归验证。
快速的质量反馈依赖于自动化测试服务的完整和成熟，现有的自动化水平是无法满足快速反馈的诉求的，整体自动化率还不足40%。为了打造成熟的自动化测试服务，支撑不同角色对质量快速反馈的诉求，质量团队成立了自动化专项小组，加强自动化建设，目标是提供成熟的自动化测试服务来支撑产品质量提升和降本增效。
在自动化的建设过程中，最大的挑战是如何降低自动化开发成本。我们希望快速地完成自动化的开发，以及以较低的成本进行存量自动化的持续维护。我们采用分层设计的自动化框架，将业务分成了5层：通信层、业务对象层、业务数据层、工具层和测试用例层。每一层的功能独立解耦，并在测试用例层制定测试用例积累业务积累的一个基层关系，定义了通用的实例的变量和方法，以此来增加测试代码的复用度。同时，支持以最少的变更来应对接口参数的变化或对象发放的一个增删改，有效降低了自动化开发和维护的成本。
除此之外，我们还充分构建和完善了自动化工具平台的能力，在自动化执行效率、自动化运营效率、自动化应用性上面有一些突破，实践进一步提升了自动化测试服务的成熟度，让自动化测试服务能够充分应用于研发流程，帮助不同的角色实现质量的一个快速反馈。
经过专项建设，腾讯云的自动化用地规模和自动化覆盖率都实现了大幅度的提升，整体的功能自动化率从35%提升到85%，并且从0到1构建了可靠性和性能的自动化能力。
以某个产品为例，经过自动化的建设，自动化用地规模新增了两倍以上，在之前单纯的功能和接口测试的基础上，丰富了场景自动化、性能自动化、兼容性自动化，自动化覆盖更全面，自动化测试服务实现了基本运维的需求的全量自动化测试回归。我们累计服务了5000多次，运维变更回归效率较之前提升了4倍。通过自动化测试也实现了性能需求的测试效率提升，性能回归测试从平均的4天缩短到了0.5天。得益于整个自动化带来的测试效率提升，测试需求吞吐能力也提升将近一倍。
而自动化服务除了在效率提升上面的意义之外，在质量提升方面也发挥了重大的作用。我们利用自动化带来的测试成本降低和测试效率提升，自动化测试服务作为流水线门禁，使流水线运转持续测试。当前流水线上面自动化运营规模已经达到11万个，自动化门禁的拦截问题的数量同比之前也提升了三倍以上，同时现网质量也有明显的改善。
（3）CICD流水线服务
结合历史问题分析，我们发现问题流出的原因比较集中在基础稳定的缺失以及流程规范的遵从性上面。从质量防控的角度，我们希望基于研发流程落地体系化的质量要求，包括过程质量稳定指标等等。从效率提升的角度，我们也希望全流程自动化规范化实现一站式的交付。所以说，我们要进行研发模式的一个升级。
前面的实践环境服务解决了研发环境的可获得性和稳定性的问题，自动化测试服务也提供了高效可信的稳定能力，剩下的挑战主要集中在当前研发模式五花八门，如何因地制宜，契合研发团队的诉求，更好地服务于他们？如何基于通用的平台能力，满足不同场景业务的一个需要，是我们需要思考和解决的问题。
首先，流程设计上我们尊重了以下几个原则：
- 以需求价值链为中心进行流水线搭建，任何流程和步骤服务于需求交互过程。
- 打通工具链，构建全流程的自动化。
- 端到端的质量门禁去提升研发内定质量。
基于以上原则，我们设计了包括开发流水线、汽车流水线、河流流水线发布流水线在内的整套流水线方案，把从代码提交、构建、部署、测试到发布的整个过程全部嵌入到流水线上，服务于研发端到端的质量和效率提升。
我们是基于扩建平台进行流水线的建设的，扩建平台本身提供了一些基础的能力，包括代码管理、持续集成及部署代码解释等等，但它仅仅靠这些通用的能力，还无法满足复杂业务场景的一些需要。我们利用流水线的一些插件能力去开发各种插件，同时利用第三方工具去解决实际场景中遇到的一些问题，例如多组件联合开发场景、跨项目联合开发场景等等，去满足不同业务团队不同的研发习惯的一些特殊要求。
基于流水线我们也落地了完备的研发流程约束检查，包括分支命名规范检查、需求组建关联检查、包夹带检查等等，有效地提升了研发过程的规范性。人为误操作导致的质量风险得到进一步的控制。
依托流水线，我们也构建了贯穿整个需求生命周期的多维度质量门禁，包括开发流水线里面的代码经验检查、单元测试、模原测试、提车流水线的一些提车门禁、系统测试以及河流回归测试、日构件发布回归等等。端到端的质量门禁，让需求交付的每一个研发过程都得到一个充分验证。
落地效果这一块，我们统计了一个季度各个业务流水线门禁的一个拦截效果，可以看到流水线门禁在提升研发内建质量方面发挥了重大的作用，业务线网质量表现也得到了进一步的一个提升。
（4）DF专项测试服务
在云产品的整个测试体系框架中，DF（Design for X）专项测试服务扮演着至关重要的角色。DF测试不仅仅是对产品功能性的验证，更是对产品在设计阶段就融入的质量属性进行深度剖析和优化的过程。这里的“X”代表了产品的各种关键质量属性，如可靠性、性能、安全性、可维护性等，这些属性共同构成了云产品高质量的基础。
DF专项测试服务的核心目标
- 早期介入设计：在产品设计初期就引入测试思维，确保从源头上就考虑到各种质量属性的需求，避免后期因设计缺陷导致的重大返工。
- 全面覆盖：针对云产品的复杂性和多样性，DF专项测试服务需要全面覆盖所有关键质量属性，确保产品在各个方面都能达到预期标准。
- 深度优化：通过专项测试发现潜在问题，并提供针对性的优化建议，帮助开发团队不断完善产品设计，提升产品质量。
DF专项测试服务的实施策略
1.构建故障模式库
针对云产品内部组件多、业务流程复杂的特点，我们构建了覆盖计算、存储、网络、应用层等多个层面的故障模式库。这些故障模式库基于历史数据和行业最佳实践，涵盖了常见的故障场景和异常处理逻辑。通过模拟这些故障场景，我们能够更全面地验证系统的韧性和稳定性。
2.抽象业务操作序列
除了故障模式库外，我们还抽象了业务特性的一些操作序列，包括客户操作、后台流程、运营操作等。这些操作序列反映了实际业务场景中用户与系统的交互过程。通过将这些操作序列与故障模式库结合，我们能够构建出更贴近真实使用场景的测试案例，从而提高测试的针对性和有效性。
3.动态调整执行策略
基于开源的自动化测试框架（如JUnit、pytest等），我们整合了故障模式库和操作序列，实现了测试任务的动态调整和执行概率的灵活配置。这意味着在测试过程中，我们可以根据实际需要调整测试序列和任务的执行顺序、频率等参数，以更好地模拟实际业务场景中的并发操作和异常情况。
4.多维度质量评估
DF专项测试服务不仅关注功能性的验证，还注重对产品性能、可靠性、安全性等多维度质量属性的评估。通过模拟高并发、大压力等极端场景下的系统表现，我们能够发现潜在的性能瓶颈和可靠性问题；通过安全测试手段（如渗透测试、漏洞扫描等），我们能够评估产品的安全防护能力。
5.DF专项测试服务的实践案例
以我们针对某款云存储产品的DF专项测试为例，通过构建覆盖存储层、网络层和应用层的故障模式库，并结合实际业务操作序列进行测试，我们发现了多个潜在的性能瓶颈和可靠性问题。例如，在高并发写入场景下，存储节点的响应时间显著增加；在特定网络故障情况下，数据同步机制未能及时恢复导致数据丢失等。针对这些问题，我们提出了针对性的优化建议，并协助开发团队进行了相应的代码修改和配置调整。经过优化后，该云存储产品的性能和可靠性得到了显著提升，客户满意度也得到了有效提高。
未来展望
随着云计算技术的不断发展和市场需求的不断变化，云产品的质量要求也将越来越高。作为质量团队的一员，我们将继续深化DF专项测试服务的研究和实践，不断提升测试服务的覆盖率和深度。同时，我们也将积极探索新技术、新方法在DF测试中的应用，如人工智能、大数据分析等，以进一步提升测试效率和准确性。我们相信，在全体团队成员的共同努力下，腾讯云产品的质量和口碑将会得到持续的提升和巩固。
