产品需求交付质量保证的“七重门”-Toy模板网

这篇具有很好参考价值的文章主要介绍了产品需求交付质量保证的“七重门”。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

前言

随着互联网红利的逐渐消失，互联网公司获取新客户的难度和成本越来越高，用户增长的运营同学需要不断尝试不同的拉新策略，并根据用户反馈及数据反馈快速调整，同时能够快速跟进市场热点，快速迭代产品功能。我们所在部门承接大量的金融业务（金白条、支付、小金库、基金等）拉新获客的诉求。为了在满足快速交付业务需求不以牺牲产品质量为代价，我们制定了用户增长质量门禁体系，通过规范化的质量活动对需求交付的各个阶段进行质量准入和准出，步步为营，形成用户增长产品需求交付质量保证“七重门”。

一重门：用例前置-未雨绸缪，把缺陷消灭在萌芽阶段

TDD（Test-Driven Development）是敏捷测试的重要实践，它强调在编写代码之前先编写测试代码，以此驱动代码质量的提升以及功能的覆盖。结合当前平台研发部质量保证的现状，测试用例绝大部分都是利用XMind编写的文字描述形式的，若完全按照典型的TDD实践进行落地，编写测试代码的成本较高，短时间内难以看到效果，因此我们第一阶段优先实现了测试用例的前置，即测试用例的编写和评审前置到设计评审或代码开发之前，通过测试用例进一步明确功能需求、性能要求、异常流程、数据需求及验收标准，并弥补需求评审环节可能遗漏的功能点和流程有欠缺的地方，提前预防缺陷，减少了在后期测试阶段的返工和修复成本。通过在用户增长、微电等领域多个项目的试点，各方均给与了正向的反馈，目前正在扩大试点范围，目标是80%的需求实现用例前置。

二重门：单元测试-分而治之，确保每个最小功能单元的正确性

单元测试是对软件中的最小可测试单元（即代码中的函数、方法、类等）进行独立的测试。它的主要目的是验证每个单元是否按照预期正确工作。单元测试具有以下几个好处：

提高代码质量：通过编写单元测试，开发人员可以验证每个单元的行为是否符合预期，这可以帮助发现潜在的错误、边界情况和异常行为。
确保模块间的独立性：单元测试要求每个单元都能够独立地进行测试，有助于构建更加灵活、可扩展和可维护的代码。
支持重构和代码重用：可以帮助开发人员验证重构后的代码是否仍然能够正确工作，确保重用的组件在新环境中的行为符合预期。
减少调试时间：单元测试可以快速发现问题所在，缩小调试的范围，加快问题排查的速度。
建立信心和提供文档：通过编写全面的单元测试，开发人员可以建立对代码行为的信心，并且在代码发生变更时，可以快速运行测试来验证代码是否仍然正常工作。

总之，单元测试是一种有效的软件测试手段，它由开发人员编码实现并执行，充分体现了全民质量保证的理念。在用户增长的项目中，研发较为看中单元测试，在编码的同时写了大量的单测代码，尤其是用户增长研发团队接入了ChatGPT，并联合集团其他部以JoyCoder联合项目组的形式，不断迭代优化，目前已经可以快速自动生成较为规范的单元测试代码，可以大大降低单元测试的工作量。

三重门：冒烟演示-严格把关，确保基本功能正常

冒烟测试在产品质量保障中起到了早期筛选问题、初步评估待交付需求质量的作用。合格的冒烟测试能够快速筛选问题、帮助团队优化资源和工作分配，并实现对产品质量的初步评估，能够促进团队交付效率的提升。在用户增长质量保证的实践中，我们一般通过行一组关键功能和核心流程的基本测试用例来验证系统在最初阶段是否适合进行更深入的测试，一般采用冒烟演示的方式，研发认为具备提测的条件之后，邀请测试同学一起现场进行冒烟用例的演示和走查。在我们的实践中，一般会把总用例中30%左右的用例标记为为冒烟用例，一般都是主流程、核心功能的验证点。不同的需求冒烟用例的比例可能差别较大，与需求的难易程度、涉及核心主流程的多少等有关系，一般情况下，研发和测试很容易就冒烟用例的内容和比例达成共识。

四重门：测试执行-明察秋毫，将缺陷一一捕获

在产品、项目和需求交付流程中，测试的执行是产品质量保障的第四道防线，也是确保软件质量的最关键步骤之一。通过有效的测试执行，能够将产品缺陷尽早发现，缺陷的类型包括且不限于：功能问题、用户体验问题、性能问题、安全漏洞、埋点规范、兼容性、风控防刷等等。测试执行阶段是测试同学工作时长最长的阶段，也是其他角色最为熟悉的测试工作内容。通常在该阶段发现的需求缺陷能达到95%以上，一般情况下，在测试执行阶段的工作量占比总体研发工作的30%~50%，当然，不同的需求，测试工作量占比可能差别较大，尤其是回归测试的比例，以及自动化测试在回归测试中的占比，都直接影响测试执行阶段的工作量和时长。

五重门：产品验证-精益求精，功能、性能、体验一个不能少

产品验证是确保软件质量的第五道防线，包括UAT、UI走查以及体验验收三部分。在需求准备上线之前，我们会邀请产品经理在预发环境或测试环境对待交付功能进行验证，此时，测试人员和产品经理一同参与对产品的系统验证，测试同学进行主流程演示或者产品经理自主验证功能、性能和用户体验是否满足最初的需求和预期，同时验证运营配置是否有问题。产品验证的结果分为两种情况：通过和不通过。对于通过的情况，我们可以开始进行最终的发布和交付工作。对于不通过的情况，我们第一时间反馈给开发团队，以便及时修复和优化问题。在产品验收阶段，基于产品设计和用户视角，产品经理可以提出各种观点和意见，从而进一步完善产品。这种多元化的反馈和意见可以帮助团队在上线前识别和解决潜在问题，虽然此时已经处于需求交付的后期，但因系统还未面客，仍有一定的时间修复问题，这样可以尽量避免问题逃逸到线上产生客诉。

另外，若涉及较多前端交互的需求，在产品验证完需要邀请UI设计师进行UI走查以及用户体验同事进行体验验收。作为上线前用户操作、用户体验方面的验收，若因体验存在缺陷导致验收不通过，用户体验同事有权决定推迟上线，直至完成了优化，或者各方就体验问题达成了共识，可以先上线，并在大范围投放之前完成优化。

六重门：运营验收-结果导向，以用户和运营双视角审视待投放功能

运营验收主要是在需求上线后，邀请运营同学在线上进行最终的验收，运营同学站在业务及用户视角，验证待交付功能是否与最初的预期一致，运营验收阶段是功能面客前的最后一道防线，基于对用户的深刻洞察、敏锐的直觉以及对市场上同类功能的深入研究，运营同学在该阶段经常能发现一些大家容易忽略的问题或缺陷。同时，更重要的是，可以验证后台配置是否有问题、预算是否充足，并决定新旧功能的分流比例、缺陷是否在容忍范围内、是否需要报备客服，并确定投放后的运营策略、运营节奏及后续的产品迭代规划。在该阶段，偶尔会发生运营意见与产品意见、研发测试意见不一致的情况，因此，该阶段也是一个互相说服、拉齐认知的重要阶段。

七重门：容灾演练-防患未然，极端情况下仍能保持业务连续性

随着业务发展、微服务架构、分布式架构和虚拟化容器技术的广泛普及，软件架构的复杂度在不断提升，服务之间的依赖所带来的不确定性也成指数级增长，在这样的服务调用网中，任何一环出现的正常或者异常的变化，都有可能对其他服务造成类似蝴蝶效应一般的影响。随着用户增长线上营销活动、拉新工具、公共组件的不断增加，整体链路增长以及数据流转复杂，对整个系统的可用性、稳定性挑战也越来越大，所以非常有必要主动找出系统中的脆弱环节，然后针对性地进行加固、防范，从而避免故障发生时所带来的严重后果，进一步提升业务系统的高可用，提高业务系统应急保障能力。近几年，国内外已经发生了数次大规模的故障导致对海量用户的服务长时间中断，产生了巨大的负面影响。为有效减少因内外部环境的故障对系统造成的影响，我们在日常工作中模拟各类故障，以检验对系统的影响及研测团队的风险应对能力，我们在用户增长领域进行了两类容灾演练：

一种是应用层面的混沌演练（Chaos Engineering）

混沌演练是一种通过有意引入系统随机性、不稳定性和故障来测试和改进系统可靠性的实践方法，它旨在帮助组织识别和解决潜在的系统缺陷和性能问题，以减少系统故障和提高系统的容错性。混沌演练的关键理念是“通过引入故障来发现故障”。通过有节制地引入不稳定因素和故障场景，例如关闭某个服务、模拟网络延迟、引发硬件故障等，混沌演练可以验证系统的弹性、容错能力和恢复能力。它能够帮助我们发现隐藏的系统弱点，识别性能瓶颈和独立失败点，并提供改进系统稳定性和可靠性的机会。

第二种是数据存储的高可用以及机房网络的断网容灾演练

演练的场景包括运营商网络断网、京东云机房断网、存储设备断网、网络流量抖动、网络流量丢包等，影响范围可能更广，因此需要提前梳理好演练内容和应急方案，具体包括根据不同场景梳理演练SOP、根据SOP设置演练模板、根据模板评估系统是否达到演练要求、根据演练要求升级改造系统、根据演练模板设计演练流程及checklist，确保不会因演练而影响线上系统。通过对演练过程、演练内容、风险事项、应对方案的梳理，做到万一发生类似基础性故障或网络、数据库切换的时候，有序执行SOP操作，系统处于风险可控的状态。截止目前，已经完成了针对用户增长领域挂奖、发奖、资金组件等三个核心应用的数据库、缓存切换演练，达到了预期效果。

总结

本文介绍了用户增长领域在快速交付产品的同时为保证交付质量所设置的七道防线，每道防线都像一道门禁，只有满足了准入要求，才能进入下一个阶段，以此来规范各个阶段的质量活动，并作为质量保证全流程的执行标准。需要指出的是，在实际的质量实践中，不是形而上的、简单粗暴的执行以上质量活动，我们会根据产品和业务需求的实际情况进行一定范围的灵活调整或裁剪，在质量和效率之间达到一个动态的、适度的平衡。