前言

俗话说，“测试是质量的守护者”，但单凭测试本身却远远不够。大多数情况下，测试像 “一面镜子”，照出系统的面貌，给开发者提供修改代码的依据，这个 “照镜子” 的过程，就是质量评估的过程，或者说，测试的过程更像 “量体温”，虽然可以测量出温度进而判断健康状况，却不能靠量体温治病。同时，需求交付的高质量不仅仅体现在结果层面，如功能、性能、可靠性、可用性、可维护性、安全性以及用户体验，也应该包括交付的过程层面，如业务需求的高质量、产品文档的高质量、提测代码的高质量等等。所以，应该站在更高的维度、更宽的视野来看待质量保证。

本文基于 C 端用户拉新的业务场景，以质量保证的全视角，总结了质量保证过程中的框架、策略、流程、规范、方法、工具以及实践，全面阐述了用户增长质量保证的价值观、方法论以及我们所理解的内涵，即高质量=质量策略多样化 + 质量流程标准化 + 质量活动规范化 + 质量工具平台化 + 质量运营常态化。

限于自身认知、专业能力以及总结能力的局限，文中有些观点可能有些偏颇甚至是错误的，同时也并不意味着我们的水平足够高，可以在这儿传道解惑，更大的意义在于我们在梳理本篇文章的过程，本身就是一个不断学习、总结、反思及寻找差距的过程，同时也许能给大家带来一些有用的信息及有价值的思考。

一. 用户增长质量保证价值观

1.1 质量保证的职责

作为 “质量的守护者”，澄清质量保证的职责至关重要。在我们看来，质量保证职责可以总结为以下几个方面：

• 确定质量标准

在功能、兼容、体验、性能、安全等属性的基础上，明确业务需求的质量标准，站在用户及业务的角度，用最小的成本达到业务可接受、用户体验有保障的质量要求。

• 制定质量计划

制定质量计划和策略，明确测试目标、测试范围、测试方法和测试时间表，以及其他质量保证活动的安排。

• 测试执行

进行各种测试活动，包括功能测试、性能测试、安全测试等，以评估产品或服务的质量，及时发现并推动解决潜在问题。

• 管理缺陷跟踪

跟踪和管理缺陷报告，确保问题得到及时解决，并与开发团队合作进行缺陷修复和验证。

• 提供建议和改进措施

基于测试结果和质量评估，质量保证人员提供针对改进产品或服务质量的建议和措施，以确保产品或服务的持续提升。

• 质量监控和洞察分析

持续监控产品或服务的质量，进行统计和洞察分析，并参与持续集成和持续交付的流程，以确保质量活动的有效性和持续改进。

• 优化流程规范及培训

针对共性的质量问题、安全问题及用户体验问题，优化质量保证流程规范，提供相关的培训和指导，分享最佳实践。

1.2 质量的挑战

在京东科技 - 市场与平台运营中心的用户增长领域，其项目整体表现形式是通过活动带动增加金融 APP 新、业务新和 C 端新的用户数量，进而进一步提升 APP 的活跃用户数，提高白条、金条、小金库、基金等业务的交叉转化。这些活动大致可分为三种类型：大促会场、C 端拉新活动和营销工具。

大促会场是指我们在 618、双十一、年货节等大型活动期间推出的会场页面，通过展示不同的利益点、玩法、商品楼层以及推荐算法，来吸引不同身份的用户进行转化；C 端拉新活动的表现形式主要包括在金融场、零售场及外场（微信、抖快、其他 app）投放拉新各类活动，同时结合节日、社会热点等进行营销活动投放，此外还可以通过玩游戏的方式引导用户进行实名认证、完成九要素、绑卡、开通金融业务等业务转化；"一分购"系列是典型的拉新工具，针对新客支付一分钱购买的形式实现业务转化，包括一分系列工具等项目。若按照拉新的策略分类，可以分为拉新工具、扩大流量敞口、提升承接效率三类项目，如下图所示：

针对以上三类项目，我们总结了用增项目的以下几个特点及质量挑战：

1.2.1 主打一个快

基于用户增长项目本身的特殊性和时效性，很多项目本身就是一个不断试错的过程，因此，需要快速上线、快速反馈和快速调整。这就要求测试人员能够快速识别和验证各种场景，出现线上质量问题需第一时间解决，尽量减少对业务的损失和用户体验的损伤。

1.2.2 细节定成败

很多活动的成功是体现在细节上的，需要不断琢磨用户心理，例如一份返现项目，在页面文案、样式、交互、利益点等方面反复调整，通过给不同样式的活动页面做分流以及一段时间的运营，找到幻化效率的最有方式，同时为防止用户审美疲劳，也要周期性的更换文案和样式。在此过程中，测试需要准确识别出需要验证及回归的流程和功能点，做到低成本精准测试。

1.2.3 回归深似海

用户增长项目的很多功能是相互影响的，牵一发而动全身。因此，在进行功能改造和新增时，我们需要对历史功能进行回归测试，这个回归测试不仅仅局限于主流程，还需要关注更多细节。由于项目的快速迭代，要求测试人员具备高效的测试技巧和精准定位回归范围的能力，以确保项目的稳定性和可靠性。通过持续的回归测试，我们能够发现和解决潜在的问题，提高项目的质量和用户体验。

1.2.4 体验要求高

体验问题也是用户增长的项目需要重点关注的事项之一。由于项目大多数是直接面向 C 端用户的，一些微小的问题，如话术不严谨、跳转异常、字体太大/太小、按钮位置不居中、提示信息不明确、挽留弹窗太多、热区太大、关闭按钮不明显等都可能会成为客诉原因，且用户体验的友好程度直接关系到用户增长和业务转化的效率。因此，测试同学在需求评审、测试用例评审及测试执行时，要把自己当成一个普通用户来思考交互是否合理、体验是否有优化的空间。

1.2.5 资损压力大

用户增长项目大多都会给用户发放各类权益，是否会被刷、风控用户如何处理、如何预防资损风险、如何识别异常流程以及如何做好兜底，是需要思考的重中之重。另外一方面，为保证项目运营过程中随时调整运营策略，一般会将文案、弹窗、利益点、人群策略等全部配置化，如何从系统层面简化配置、防止配置错误也是需要解决的重要课题，一旦配置错误，可能会导致巨额的资损或批量的客诉。

1.2.6 物料准备难

由于 C 端拉新活动要针对各种类型的新人账号（未实名、未 9 要素、未绑卡、C 端新、业务新等）实现活动可见、可领，领取利益点之后实现身份转变，因此测试过程中需要各种类型的账号针对各种正常和异常场景进行测试验证。难点主要体现在测试账号需求量大、账号不能重复使用、同一账号在上线前无法完成全流程验证、上线后需要真实的账号（C 端新、业务新）进行验收等。虽然内部可以通过账户加白名单、申请 C 端新内部账号、申请超级账户等方式来支持测试，但由于依赖风控、实名、营销、银行等多个外部系统，大多数情况下测试账号很难验证全流程。

1.3 质量价值观

针对用户拉新业务领域，结合该领域的业务特点、质量实践和我们对质量的理解，我们总结了以下几个方面作为对用户增长质量价值观的思考，并在团队内部达成了共识。

1.3.1 全民质量保证

质量不是测试同学的专属职责，也不是光靠测试同学就能达到高质量，质量需要全员参与，每个人都是质量的守护者。在我们的质量实践中，在交付全流程中共有 7 道防线来防范缺陷逃逸到线上，业务/运营、产品、研发、测试及项管虽分工不同，但都是质量防线必不可少的角色。

1.3.2 预防大于发现

质量保证过程中，预防问题的发生比事后发现和纠正问题更为重要和有效，在问题发生之前采取预防措施，以便在源头上消除潜在的质量问题，其预防成本往往比缺陷修复的成本更低。在我们的实践中，预防缺陷的主要举措包括：强调需求文档的准确性、清晰性和完整性；提测前严格的代码评审，可以减少代码中的潜在问题和错误；提前介入测试，以确保产品满足需求，从根本上提升产品质量；推广质量文化，各个角色都应该意识到缺陷预防的重要性。

1.3.3 质量是免费的

为了保证交付质量，应该尽量在产品设计、开发和测试环节上投入足够的时间、资源和精力。虽然短期内产生的投入可能会增加成本，但与质量问题相关的额外成本（客诉、资损、研发修复成本等）可能会更高，而质量的提升最终都会体现在线上质量稳定、性能提升、交付效率提升及用户体验的提升。所以，从某种意义上讲，质量不是成本，质量不仅是免费的，还会产生额外的利润。

1.3.4 质量不是测出来的

测试本身不能有效提高质量，就像温度计并不能降低体温一样，质量内建才是质量保证的核心，需要从需求分析、研发设计、开发、测试、上线、运营等各个环节都关注质量。提高全民质量意识、尽早发现缺陷、落地敏捷 DevOps 理念、工具和方法，建立并不断优化研发流程和上线规范，通过质量前置及测试右移等方式建立全流程质量保证体系。通过这些质量内建的方法，可以有效减少缺陷和问题的发生，提高质量和稳定性，同时也能节省后续的测试和修复工作，降低研发成本。

1.3.5 质量不是越高越好

过高的质量水平可能会导致资源浪费和不必要的成本增加，质量应该与业务的实际需求和使用场景相符，过度追求完美的质量可能会导致开发周期延长、成本增加甚至对用户体验造成不必要的局限。简而言之，质量就是综合考虑成本、进度、风险等因素前提下的满足需求，而不是超过需求。

1.3.6 质量不是无形的

质量不仅能被感受到，还可以被度量。在用户增长领域，我们常用的质量度量指标包括：需求平均缺陷数和研发人均缺陷数，用以度量缺陷的密度；缺陷关闭率和缺陷关闭时长，用以度量缺陷解决完成度和解决效率；回滚率用以度量待交付需求的稳定性和可靠性；线上事故数用以度量缺陷逃逸到线上的数量，说明线上系统的稳定性。通过质量度量可以将质量目标转化为具体的可衡量的指标，从而更好地指导和监控质量改进。

二. 用户增长质量保证方法论简述

2.1 质量保证方法论

结合用户增长领域长期的质量实践及我们所认可的质量价值观，我们对增长领域的质量保证工作进行了梳理，在过程质量、发布质量和线上质量保证过程中需采取不同的质量活动，应用不同的质量策略并使用不同的质量工具，为保证质量策略和质量活动的顺利进行，需要与各角色共识质量管理的流程，并通过持续的质量运营，让质量理念深入人心。总结来说，质量=质量策略 + 质量流程 + 质量活动 + 质量运营 + 质量工具，而在用户增长领域，高质量=质量策略多样化 + 质量流程标准化 + 质量活动规范化 + 质量工具平台化 + 质量运营常态化，这就是我们认为的用户增长质量保证方法论。

2.2 质量保证体系

我们所在的部门，是直接支持业务获客和业务增长的研发团队，在京东生态场、京东金融 APP 中心场及外部私域场（微信、抖快、电销及其他外部 APP）通过高效的拉新工具、活动投放、用户承接工具等方式，进行用户拉新、促活及交叉转化，不断扩大用户规模及交易规模，进而推动消金、财富及支付等 C 端业务的稳定增长。获取新用户是业务增长最为基础的工作，不仅有助于保持竞争力、促进收入增长，还可以通过获在取新用户的过程中不断优化产品和服务，加强京东金融 APP 影响力，对于公司来说具有重要的作用和意义。因此，用户增长质量保证工作至关重要。

上述质量保证方法论给我们提供了整体的目标和方向，我们对方法论进行细化，质量策略、质量流程、质量活动、质量运营及质量工具都拆解成为可以落地到质量保证的日常工作中的具体事项，结合平台研发部整体的质量保证体系以及用户增长质量保证方法论，我们总结了用户增长领域质量保证体系全景图，如下图所示：

下面将从质量策略、质量流程、质量活动、质量工具及质量运营等 5 个方面分别阐述用户增长质量保证方法论的内涵和我们的实践。

三. 用户增长质量策略多样化

用户增长项目大多以活动投放的形式针对特定用户进行拉新，需综合利用各类拉新工具或组件，以扩大流量敞口、提升承接效率以及最终的转化率为主要目标，投放渠道、活动场景、适用人群、前端交互、用户操作路径及利益点多种多样，相应的质量要求及测试过程也有较大差异，需要根据不同的需求类型和业务场景采用不同的质量策略。在用户增长项目中，以下几个质量策略被广泛应用。

3.1 在测试理念方面，综合运用敏捷测试和传统测试的实践

作为敏捷研发模式的一个环节，敏捷测试注重迭代测试和增量式交付，系统在不断的迭代中逐步构建和完善，不强调测试用例的全面性及测试覆盖度，甚至可以利用探索式测试代替完整的测试用例，以支持快速迭代和收集用户反馈为主要目标。例如，在一个团队默契度高、人员稳定的项目组，团队采用敏捷测试方法，按节奏进行测试活动，快速验证，快速上线，有时为确保快速交付，可以容忍功能、性能及体验的暂时缺失，以换取主功能的快速交付和面客验证，并在后续的版本中快速迭代优化。敏捷研发模式提升了协作效率和研发产能，但并不一定适合所有的场景，传统的瀑布式交付模式，也有其独特的优势。

传统测试更加注重完备的测试计划和详尽的测试用例，适用于对稳定性、功能完整性、体验或性能要求较高的项目，通过完备的测试验证计划，确保完整的测试覆盖，非常适用于功能极为重要、或者提供基础能力供多方调用的项目团队，快节奏的迭代和频繁的上线并不是最优项。

总之，敏捷测试与传统测试没有好坏之分，需要适配测试的场景，针对同一个项目，在不同阶段也要采取不同的策略。例如一分钱拉新的工具，包括一分返现/返券、一分充值、一分秒现、一分抽奖等拉新工具，在前期，为了快速验证，采用敏捷研发模式和敏捷测试机制，针对功能和运营策略快速上线，并投放到不同的渠道快速验证效果，一些小的体验问题、不影响主流程的功能问题都可以放到后续的版本中优化，但是到了项目成熟阶段，项目组成员被大量抽调到其他项目，新人或临时性支持的人员较多，这时再强调快速迭代，对底层功能进行大量的修改且不经过完整的测试，一定会对线上的质量造成巨大的影响，此时，按部就班地开发、制定完备的测试计划、准备完整的回归用例是非常必要的，此时的慢、稳有可能是第一要务。

3.2 在测试执行方面，综合采用手工测试和自动化测试

手工测试能够根据测试人员的经验和直觉发现一些难以预料的问题。例如，在一个针对运营的配置系统中，测试人员通过手工点击和输入的方式测试用户界面的响应和交互。自动化测试能够提高测试效率和一致性，测试人员采用自动化测试工具，编写测试用例并进行自动化测试，以保证软件的核心功能的稳定性和正确性。

手工测试适用于需要严格细节和需要掺杂较多人为因素的测试场景，测试人员可以快速上手，外部依赖较少且可以灵活运用各种测试策略，通常手工测试可以发现比自动化测试更多的缺陷。而自动化测试适用于要求大量重复性、稳定性或大量数据的测试场景，就像流水线一样，快速执行，但是实现自动化测试用例本身需要需要投入大量的时间和精力，并且由于自动化测试的脆弱性，已经开发完成的用例还必须随着被测对象的改变而不断更新，你还需要为此付出维护测试用例的成本。在用户增长领域的测试中，针对临时活动类、新项目及前端交互较为复杂的项目，以手工测试为主；针对较为成熟的拉新工具、运营端功能及测试回归时，偏重自动化测试，其自动化用例需要不断积累并持续更新维护。

3.3 在测试用例方面，综合使用脚本测试和探索式测试

脚本测试通过编写测试脚本来进行测试，并可以覆盖大部分常规场景，通过编写一系列的测试脚本（包括测试代码、文字描述的测试用例、操作数据库和缓存的脚本等），用于验证各个功能模块的正确性和可靠性。探索式测试充分发挥测试人员的主观能动性，通过不断尝试和探索来寻找应用未知的测试场景，在测试过程中没有或者较少使用测试脚本。

在京小福 GO 小程序中的有一个合成宝石小游戏，在测试过程中，测试同学结合合成类游戏的特点，通过不断尝试不同的操作和游戏路径，以发现潜在的问题和优化点。脚本测试适用于对已知场景的覆盖，而探索式测试作为敏捷测试的重要实践，适用于对未知场景和新功能的探索，合理使用探索式测试，可以大幅降低测试成本。在我们的用户增长的质量实践中，一贯鼓励大家积极尝试不同的测试策略和方法，不管是局部探索式测试、全局探索式测试还是混合探索式测试，都有其在不同测试场景不断探索和实践的现实意义。

3.4 在测试范围方面，综合利用测试左移和测试右移的实践

测试左移主要目标是把质量活动前置，通过各种缺陷预防工作，有效减少后期的问题修复成本。在用户增长的质量实践中，除了在在需求评审主动识别业务流程断点、异常流程、分支流程、测试数据和测试物料诉求、验收标准等常规问题之外，我们对测试用例进行了前置，通过测试用例的梳理和评审，给与研发设计和代码编写更多的输入，提前识别业务流程及需求交付过程中的问题，并及时与产品和开发进行沟通。测试右移指对质量的把控延伸到系统上线之后及日常的运营和运维过程中，通过日常的人工巡检、自动化巡检、体验治理等方式，及时发现和用户体验问题。总结来说，测试左移和右移只是一个形象的表述，其核心是质量保证不应该仅仅针对测试执行阶段，而应该贯穿于研发质量管理的各阶段及需求交付的全生命周期。

3.5 在测试策略方面，综合应用金字塔、冰淇淋和橄榄型模型等类型的策略

金字塔模型、冰淇淋模型和橄榄型模型是常用的测试策略模型，它们在测试覆盖和测试优先级方面有不同的侧重点。金字塔模型基于测试用例的优先级和数量来划分测试层级，金字塔的底部是大量的单元测试或单元组件测试，接着是少量的集成测试，再往上是更少量的系统测试和用户界面测试等。金字塔模型的目标是将更多的测试重点放在低层级的测试中，通过更细粒度的测试覆盖来发现和解决问题，最大程度地提高测试效率和准确性。

冰淇淋模型强调功能性和非功能性测试，并注重用户体验，该模型特别适合用户驱动的测试，如用户界面测试、用户验收测试等。橄榄型模型综合了金字塔模型和冰淇淋模型的优点，兼顾了测试覆盖和用户需求验证。金字塔模型适用于快速研发的小型项目或服务端逻辑较为复杂的项目，冰淇淋模型适用于极致强调用户体验的项目，而橄榄型模型在中等规模的项目上适用性更高。以上三类测试策略模型只是一些常见的指导方法，应根据具体的项目和测试需求选择合适的测试策略，有时可能需要使用多个模型的组合。

相较于其他业务场景，用户增长领域主要与 C 端用户及业务运营人员直接交互，迭代速度快，用户体验要求高，因此，冰淇淋模型被广泛应用。我们对于所有的需求都会安排上线前的产品验证及上线后的运营验收，从需求提出者、产品方案设计者、终端用户三个角度验证系统的功能和用户体验。

3.6 在测试协同方面，综合考虑局部最优和全局最优之间的平衡

在测试与其他角色的协同中，不仅考虑测试单元的独立性和正确性，还要考虑整个需求开发和交付过程的效率和质量。这种综合考虑有助于优化团队合作，提高产品的整体质量和交付速度。举例来说，在敏捷开发团队中，测试人员与开发人员、产品负责人等角色进行协同。在局部最优的视角下，测试人员可能会只关注检查局部功能是否符合需求和规范，而忽略其他角色的需求和期望。然而，从全局最优的视角来看，测试人员应该参与需求讨论，并与其他角色密切合作，以确保需求的准确性和全面性。

这样可以避免后续开发过程中的变更和延误，并提高整个团队的生产力。同样的道理，交付过程中我们提倡定期评审、按节奏开发、按客观工作量评估排期、冒烟准入等实践都是为了防止在某个阶段或某个角色的局部最优却导致全局低效或低质量。然而在现实的工作中，有时不得不为了局部最优牺牲掉全局最优，这跟项目所处的阶段、组织环境、内外部业务压力等因素有很大关系。所以，综合考虑局部最优和全局最优在测试与其他角色的协同中非常重要，因为这有助于促进团队的有效沟通和协作，提高整体工作效率和产品质量。通过综合考虑局部和全局的需求和期望，测试同学可以在开发和交付过程中发挥更大的作用。

综上所述，在用户增长质量保证过程中，需根据不同的业务场景、项目要求和组织环境，综合运用和组合各种质量策略，采用不同的测试方案和测试方法，提高交付质量，减少潜在问题的发生，增强用户体验。需要强调的是，在用户增长质量保证的实践中，我们并不会僵化地、机械地使用以上策略，而是把它们应用到日常质量工作中，做到润物细无声。

四. 用户增长质量流程标准化

质量不在测试阶段产生，更不在测试阶段结束，质量贯穿整个产品生命周期中的每个环节，包括方案设计、开发、测试、发布、运营及下线。在敏捷开发模式中，测试人员会尽早开始测试，包括对需求、研发设计及测试用例的及时评审，更重要的是，能够及时、持续对产品/项目/需求质量进行反馈，可以总结为下图：

针对用户增长产品交付的特点，测试团队需要做到 “又快又好” 的完成工作，需要把质量保障和降本增效贯穿到整个需求交付的各个阶段，所以我们在每个阶段都制定了相应的质量流程标准化的规范。我们把测试活动概括为 “需求分析”、“用例分析和设计”、“测试执行阶段” 和 “线上质量监控阶段” 这几个阶段，接下来我们详细讲述在每个阶段的具体工作方式。

如在需求阶段，我们制定需求准入的规范，包括需求文档内容展示、前端页面交互等内容，避免在开发过程中因需求细节不清晰导致到测试阶段再找产品核对、研发再修改、测试再验证；在用例设计阶段，测试用例评审前置评审，从功能层面可以对产品的需求细节进行补充，从系统实现层面可以根据研发的实现方式列举出影响的功能点及回归测试点，提升用例的有效性；产品发布时会根据需求特点制定灰度发布方案；线上运营中进行线上功能定期巡检及系统整体动态数据的监控。

4.1 需求分析：识别业务价值和商业价值

Dave Hendricksen 在他的著作《软件架构师的 12 项修炼》中提出：“系统架构师在考虑软件架构的真正价值时，不能只关注系统构造的技术，更要对客户价值和商务价值——你能帮助客户真正解决怎样的问题、你怎样帮助公司赚钱——有深刻的认识” 。即便产品使用的是最先进的开发技术，如果不能满足用户的痛点、不能解决业务的诉求，这样的产品就是无用的产品，不能称为成功的产品。在项目启动阶段，测试人员的深度参与至关重要，有助于识别业务价值和商业价值，体现在以下几个方面：

• 洞察业务：对业务的洞察是质量保证的基础，通过深入了解业务，测试人员可以更好地实施测试策略、创建准确的测试用例，覆盖重要的业务场景和流程，以确保业务需求在产研交付后的正确性和完整性。可以说没有对业务领域的深入理解和洞察，质量保证将成为无源之水、无本之木。
• 理解需求价值：了解需求的目标和价值，同时基于与业务和产品经理的沟通，搞清楚需求背后所代表的业务涵义、所解决的业务上的问题，而不仅仅是需求文档中的功能说明。
• 理解需求功能：深刻理解用户的使用场景，了解业务操作流程，以及该需求所对应的功能及在业务流程中的位置。我们的系统通常具有较高的复杂性，可能涉及一个项目中的多个模块，或者是多个项目、多个部门的功能协作。因此，在串联流程时，需要通盘考虑。
• 分析用户体验：深入理解产品的体系、架构和交互关系。从业务流程的角度考虑，确保业务流程的合理性、流畅性和完整性，保证用户在操作过程中没有疑惑。以用户视角思考使用场景和操作流程，让用户少操作、少思考。

4.2 系统分析：确定待交付功能能够满足业务需求

在设计需求验证点时，需要考虑 “看得见的需求” 和 “看不见的需求”。“看得见的需求” 即为产品经理需求文档中描述的需要实现的功能是什么。“看不见的需求” 即为研发同学在代码实现过程中运用了什么技术，这些技术可能需要一些测试用例进行验证。所以，我们需求分析的输入不仅包括产品需求，还必须考虑代码的具体实现，在测试开始前深入了解研发详细设计有助于测试人员制定合适的测试策略。在需求交付过程中可以通过以下方式对研发设计做深入的理解：

• 理解研发设计的实现流程，包括系统架构设计、模块划分及各模块的技术和数据交互。如在数据存储方面，需详细了解不同数据存储的特点及相应的实现方案，例如关系型数据库、NoSQL 数据库、Redis、ES 等，以便评估其性能和可用性；数据交互层面，深入了解系统中的数据交互方式，包括同步和异步的调用方式、数据格式转换、数据传输的加密与压缩等方面；了解系统的各种异常类型和对应的处理方式，包括错误码定义、异常日志记录、告警机制和异常回滚处理等，以确保系统的可靠性和可维护性。
• 系统配置方面，包括配置文件的格式、配置项的分类和命名规则、配置的动态更新和预加载机制等，以确保配置的灵活性和可扩展性；调度任务方面包括任务的调度频率、调度策略、失败重试机制、作业优先级管理等方面，以保证任务的可靠执行和高效调度。
• 了解与外部系统的依赖和交互。在微信域拉新时，大量需求涉及到与企微、小程序的交互，企微主被动加微、消息群发、社群运营等需要详细了解微电、用增活动、小程序与腾讯侧系统的交互，如接口定义、协议规范、数据交换格式和数据校验、回调方式、重试机制等。
• 代码改动点及调用链路梳理。用户增长项目一直处于快速迭代过程中，项目涉及的功能点及调用关系都较为复杂。对于研发实现需进一步梳理每个代码改动点对其他模块的调用和影响，分析其可能引发的潜在问题，以确保每个改动点、受影响功能点的稳定性。

4.3 测试执行：确保待交付功能与产品的显性和隐性需求一致

经过以上需求分析和系统分析后，我们可以根据这些输入来设计测试用例。总结来讲，测试用例可以从业务功能分析、系统实现分析及系统实现的改动点带来的影响范围划定等三方面进行设计，在测试用例评审完毕之后，就是测试执行了。有效的测试执行能够确保软件功能的正确性、提高软件质量，以及减少软件维护成本，测试过程中的结果和问题反馈能够帮助开发团队及时修复问题并改进软件开发的过程，从而提高整体的交付质量和开发效率，因此，测试执行是确保产品质量的关键环节。

测试执行阶段除了测试人员本身的质量活动和行为之外，也是与业务/运营、产品、研发等沟通最为频繁的阶段，因此 合理规范的测试流程约束和质量问题快速归因是高质量交付的保障。将测试过程划分成多个节点并共享，能够使职责划分明确，有利于相关人员分析质量卡点原因及进度把控。在测试阶段需完成功能测试、非功能测试两部分，其中功能测试是产品质量显性的验证，非功能测试是产品质量的深层次的检验。

• 功能测试：功能测试的目标是验证软件系统是否实现产品需求文档中定义的功能要求，进行功能测试的步骤一般为：设计测试用例、准备测试环境、执行测试用例、验证测试结果、缺陷跟踪和复现、缺陷修复和回归测试、发送测试报告和总结等，其中为适应敏捷交付的要求，坚持测试左移原则将部分测试步骤前置，如测试用例设计&评审在编码之前完成，测试环境搭建以及物料准备在研发提测前完成。坚持测试左移的原则可以在敏捷开发过程中帮助整个团队更早地发现问题，减少后期修复的成本和风险，同时通过前置测试步骤，可以促进测试与开发的紧密协作，提高需求交付的质量和效率。
• 非功能测试：经过功能测试的验证已经实现了业务需求功能部分的检验，但质量的检测只完成了第一阶段，第二阶段是软件性能以及潜在风险点验证，确保需求交付后万无一失。非功能测试主要测试带交付需求的可靠性、可用性、性能、安全性、兼容性等方面。非功能测试通常需要使用专门的测试工具和技术，设计合适的测试场景和测试条件进行测试验证，比如每年两次的大促压测，都是利用 Forcebot、泰坦等压测工具进行性能测试。

此外，有些工作不太好区分是功能测试还是非功能测试，但也是非常重要的质量保证工作，比如关于埋点和数据准确性的验证。主要工作包括：

• 需求阶段

在需求阶段推动埋点需求评审，识别埋点设计方案的合理性，推动埋点需求质量提升。

• 测试阶段

包括埋点测试策略设计、手工埋点验证、自动化埋点验证等工作。

• 埋点上线阶段

测试同学回归验证，推动产品、量化人员做埋点验收。

• 数据应用阶段

通过数测平台校验数仓数据与应用层数据的一致性和准确性，提升比对范围和效率；从用户使用视角提出分析平台优化建议，提升数据应用平台用户体验。

4.4 上线发布：执行上线前 check 与上线后灰度发布

当需求开发阶段接近尾声时，团队的工作也进入到了关键的上线发布阶段。为保障已完成质量检测的产品功能正常上线，在需求上线之前。用户增长质量团队协同其他各个角色通常需要在上线阶段做以下工作：

• 产品验收测试：测试团队在业务验收测试过程中，会模拟真实业务场景，在测试环境或预发环境中，测试待交付功能在不同业务流程中的运行情况，并与产品经理、业务方对比验证，确保软件的功能能够正常运行。
• 上线前 Checklist 执行：我们梳理了从需求评审到上线验证过程中各个阶段检查点和关注点，有些是可选动作，有些是必选动作，避免在交付过程中有所遗漏或没有前置沟通而导致返工或线上问题。Checklist 检查项按角色进行区分，分为运营检查点、产品检查点、研发检查点和测试检查点等四个部分。其中研发检查点主要包括代码合并情况、编译打包是否完成、数据库升级是否成功等。测试检查点主要包括测试环境是否搭建完备、测试用例是否执行完整、bug 修复情况等。测试团队需要仔细对照这个 Checklist，确保每个检查点都已经完成，以确保软件上线前的稳定性和可靠性。
• 封版时间把控：在封版时间之后，除了线上 bug，开发团队将不再接受新的功能需求和修改请求。测试团队需要把控好封版时间点，并确保在封版之前，所有的测试工作都已经完成。封版时间的把控对于软件的上线进程非常重要，它能够保证软件的稳定性和质量，在上线之后降低问题和风险。目前在微电 C 端相关的项目，执行上线当天 12 点前封板，晚上 18 点开始上线的约定。
• 版本灰度发布：在需求上线之前，通常会先进行版本灰度发布，即将新功能逐步投放给一部分用户使用，以验证软件在真实环境中的稳定性和可靠性。测试团队参与沟通灰度发布计划，协同产品和运营确定灰度的人群、灰度比例、切量计划及应急预案，并收集用户的反馈和问题报告。

总体来说，在需求的上线阶段，用增测试团队需要业务&产品验收测试、上线前 Checklist 执行和封板时间把控、版本灰度发布等一系列的工作。这些工作的完成能够确保软件在上线之后能够稳定运行，并满足用户的需求。测试团队需要与运营、产品及研发团队紧密合作，保证各项工作的顺利进行，确保高质量、按时交付。

4.5 投产运营：收集用户反馈并沉淀经验教训

需求上线之后，用增质量团队仍需协同各方进行一系列的质量保证工作，主要包括：

• 监控和收集反馈：监控软件的运行情况，及时了解是否存在异常或客诉，确保线上问题可以在第一时间修复。质量团队还需要主动收集用户反馈，为业务规划和产品优化方案提供更多输入，不断改进用户体验。
• Bug 跟踪和修复：部分缺陷因时间问题可能需要留待上线之后逐步修复，质量团队协同业务和产品，评估问题的优先级和严重程度，并协调开发团队及时修复。
• 性能监测和优化：质量团队需要持续进行性能监测，包括对软件的响应时间、并发处理能力和资源占用情况等方面进行评估。如果发现性能问题，需要与开发团队合作，优化性能和用户体验。
• 自动化测试和持续集成：上线后，质量团队可以进一步推进自动化线上测试和持续集成的工作。通过自动化巡检，及时发现线上问题并第一时间通知到项目团队，同时持续集成可以帮助测试团队更快地修复问题。
• 产品功能文档沉淀：上线后，质量团队通过结合整个测试流程所遇到的问题和困难进行梳理，将业务理解、测试策略、测试方法、经验教训等整理成文字，一方面有助于自我总结和反思，另一方面有助于分享给其他同学，做到共同提升。

总之，质量流程标准化对于保证产品和需求质量有着重要作用，它确保产品能够符合客户和业务方的期望，并且提供可靠的性能和持久的价值，通过标准化的质量流程，能够迅速拉齐团队内部不同职级、不同能力的测试同学的质量保证工作，确保每一步都经过仔细的审查、测试及验证，以最大程度地减少缺陷逃逸到线上的机率，同时，通过不断总结沉淀，不断优化完善质量流程。

五. 用户增长质量活动规范化

所谓质量活动，是指为确产品或服务的质量而进行的一系列活动和过程，旨在预防和检测潜在的质量问题，并采取相应的措施来纠正和改进。用户增长的运营需要不断尝试不同的用户增长策略，并根据用户反馈及数据反馈快速调整，同时能够快速跟进市场热点，快速迭代产品功能。为了在满足快速交付的同时不以牺牲产品质量为代价，我们制定了用增质量门禁体系，通过规范化的质量活动对需求交付的各个阶段进行质量准入和准出，即所谓的七道防线。

5.1 第一道防线：测试前置

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

5.2 第二道防线：单元测试

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

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

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

5.3 第三道防线：冒烟测试

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

5.4 第四道防线：测试执行

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

5.5 第五道防线：产品验证

产品验证是确保软件质量的第五道防线，包括 UAT、UI 走查以及体验验收三部分。在需求准备上线之前，我们会邀请产品经理在预发环境或测试环境对待交付功能进行验证，此时，测试人员和产品经理一同参与对产品的系统验证，测试同学进行主流程演示或者产品经理自主验证功能、性能和用户体验是否满足最初的需求和预期，同时验证运营配置是否有问题。产品验证的结果分为两种情况：通过和不通过。

对于通过的情况，我们可以开始进行最终的发布和交付工作。对于不通过的情况，我们第一时间反馈给开发团队，以便及时修复和优化问题。在产品验收阶段，基于产品设计和用户视角，产品经理可以提出各种观点和意见，从而进一步完善产品。这种多元化的反馈和意见可以帮助团队在上线前识别和解决潜在问题，虽然此时已经处于需求交付的后期，但因系统还未面客，仍有一定的时间修复问题，这样可以尽量避免问题逃逸到线上产生客诉。

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

5.6 第六道防线：运营验收

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

5.7 第七道防线：容灾演练

随着业务发展、微服务架构、分布式架构和虚拟化容器技术的广泛普及，软件架构的复杂度在不断提升，服务之间的依赖所带来的不确定性也成指数级增长，在这样的服务调用网中，任何一环出现的正常或者异常的变化，都有可能对其他服务造成类似蝴蝶效应一般的影响。随着用户增长线上营销活动、拉新工具、公共组件的不断增加，整体链路增长以及数据流转复杂，对整个系统的可用性、稳定性挑战也越来越大，所以非常有必要主动找出系统中的脆弱环节，然后针对性地进行加固、防范，从而避免故障发生时所带来的严重后果，进一步提升业务系统的高可用，提高业务系统应急保障能力。

近几年，国内外已经发生了数次大规模的故障导致对海量用户的服务长时间中断，产生了巨大的负面影响。为有效减少因内外部环境的故障对系统造成的影响，我们在日常工作中模拟各类故障，以检验对系统的影响及研测团队的风险应对能力，我们在用户增长领域进行了两类容灾演练：

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

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

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

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

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

六. 用户增长质量工具平台化

根据第一章的描述，在用户增长质量保证过程中，在交付质量和效率方面存在着诸多的挑战，这些挑战不能单纯依靠质量策略、方法、流程规范及无休止的加班解决，质量工具在此过程中发挥着重要的作用。质量工具的种类繁多，包括自动化测试工具、性能测试工具、安全测试工具、数据构造工具等等。我们对测试团队常用的测试工具进行了梳理，发现测试过程中使用了大量的内外部工具。以下是较为常用的工具：

以上这些工具都是各自独立的，大部分是为了解决质量保证过程中的单点问题，而我们一直所倡导的是敏捷 DevOps 理念，它强调各个团队各个角色之间的无缝协作、持续交付和自动化，在需求交付过程中追求更快的交付速度、更高的质量和更好的用户体验。在我们的实践中，一般利用基于行云底座的需求管理、流水线、缺陷管理、分支管理、发布工具、质量看板、流水线等作为基础性质量工具。

与此同时，基于我们质量部的特点及多年来的沉淀，利用自研静笃平台实现了质量流程管理的线上化，并接入了行云，实现了与行云需求管理模块、缺陷管理模块的打通，包含质量流程管理、接口/UI 自动化、H5 性能检测，指定场景流量回放，大促性能测试工作台等主要功能模块，在静笃平台内我们可以通过 “基础数据配置” 添加业务系统、数据库信息和接口信息等，通过 “数据工厂” 帮助测试同学智能造数，通过 “自动化测试” 实现线上巡检接口和 UI 页面的正确性，通过 “自动化任务” 定时回归测试流程，输出详细的测试报告，还能通过 “智能助手” 帮助解决测试同学知识库对齐等问题。通过行云、静笃等平台化工具，实现了质量保证全流程的线上化和数字化，降低了协作成本，为高质量交付提供了基础性保障。

七. 用户增长质量运营常态化

质量运营聚焦于质量的全方位控制和持续改善，将质量流程、规范、制度、标准、模板、最佳实践和质量意识贯穿于整个部门、各个角色及需求交付的全生命周期。通过质量治理、质量度量、质量文化建设及推动持续改进等举措，使质量理念深入人心，质量活动落实到位，并通过各个角色的协同配合，确保交付质量稳定在合理的水平和空间，这一系列举措成为质量保证过程中的常规工作。质量运营不仅仅是单一的职能部门或个别员工的责任，而是整个组织的共同责任，通过质量运营可以帮我们实现持续的质量改进和优化。 常态化的质量运营包括以下几个方面：

7.1 质量治理

通过建立一系列的机制、流程和标准，以保证产品质量符合规范和业务期望 ，保证交付质量和效率，主要包括以下几个内容：

7.1.1 技术质量治理

通过严格把控冒烟质量、测试用例前置、完备的研发设计文档、规范的代码评审以及提升测试用例评审质量、缺陷定期 review、补充自动化巡检用例等方式，提升提测质量及线上稳定性。

7.1.2 数据质量管理

针对埋点不规范、取数难等痛点，联合奇点产研、量化分析师等团队在市场与平台运营中心内对埋点问题进行了专项治理。主要包括埋点规范升级、埋点上报平台改造、高代码埋点流程试点、埋点平台能力完善等几个方面。来保障埋点采集数据落入数仓的准确性，推动业务数据在分析洞察平台展示的及时性和准确性，降低非数据分析师角色使用的门槛。

7.1.3 用户体验治理

用户体验在用户增长的产品和服务开发中至关重要，通过关注用户的需求、提供易用的界面、设计优雅的交互和提供愉悦的使用体验，可以增强用户满意度、竞争优势和品牌形象，从而实现用户价值的最大化和获取新用户效率的提升。针对用户体验问题，主要从以下几个层面推进体验治理。

• 分类化体验问题与建立体验专项

◦体验问题分类：将体验问题细分为不同类别，如活动类体验、拉新工具体验、运营体验、大促体验等。这样可以更有针对性地进行问题分析和解决。

◦建立体验专项：针对每个体验问题的类别，建立相应的体验专项团队或小组，协同各个角色推动监测、分析和优化解决相关的体验问题，从而提高问题治理的效率和质量。

• 客服进线分析

筛选重点项目的用户进线问题，对问题进行归类、分析，以及给出优化建议，例如改进产品功能、优化界面设计、增强用户引导等。

• 体验问题的准入、检测与监控

◦需求评审和测试用例评审：在评审阶段，邀请客服部门体验 BP 和用研同学参加需求评审和测试用例评审，对用户体验问题进行把控，对于有争议的体验问题进行裁决。

◦前端测试准入、验收规范：针对前端样式不统一、规范不统一等问题，建立前端测试准入和验收的标准，对按钮、输入框、下拉框、表单、菜单等前端组件的样式、功能进行统一规范，作为前端提测准入测试阶段的标准之一。

◦检测与监控指标统一：建立一套完整的性能体验指标体系，统一收集和监控关键指标，如加载时间、响应速度、页面稳定性等，以及时发现体验问题并进行有针对性的优化。

◦端内 H5 性能检测工具：引入端内 H5 性能检测工具，对 H5 页面的性能进行监测和分析。通过定期检测，可以发现并修复潜在的性能问题，提升用户的访问体验。

◦生产性能定时巡检工具：使用定时巡检工具对生产环境的性能进行监测，及时发现并解决系统的性能瓶颈和问题，这样可以保证系统的稳定性和良好的用户体验。

• 缺陷扫除

◦在重大项目上线前预留一定的时间进行缺陷扫除活动，项目组成员全面检查系统中可能存在的体验问题和缺陷，并及时修复。通过这种缺陷大扫除活动，可以把绝大部分功能缺陷和体验问题消灭在功能面客之前。

通过以上举措，可以更加全面地治理产品体验问题，提高产品的质量和用户满意度。另一方面，用户体验是偏主观的，不同的角色从不同的角度可能对同一个体验问题有着不同的结论；同时，用户体验也是动态的，在不同的环境下、不同的阶段对同一个体验问题的看法也会不同；第三，体验问题需要与业务发展保持一定的动态平衡，有时可能不得不做暂时的妥协和牺牲，但妥协和牺牲一定不能突破体验的底线。因此，用户体验与业务发展相伴相生，作为质量保证的角色，在用户体验治理的过程中发挥着至关重要的作用。

7.1.4 质量流程治理

协同 PMO、产研，加强质量内建，提升过程质量，主要包括：

• 需求完整度

通过流程规范及定期复盘，引导产品提升需求质量，避免一句话需求、口头需求，以及需求未充分思考便匆忙评审。

• 交付规范度

按节奏评审和上线，提升交付的节奏感，尽量减少对测试、研发的打扰；研发侧避免未经过评审或提前通知测试而私自接受业务或产品的需求等等。

• 提测质量

一线开发的代码质量差异较大，需通过质量度量分析推动研发提升代码质量，提升开发过程的规范度，如尽早代码评审、加强自测和单测等。

• 产研测复盘

定期复盘需求交付过程中的问题，共识改进方向及改进的进度。

7.2 质量度量

通过质量度量体系的建立，制定具体的质量指标和目标，并通过指标衡量结果和改进方向。以平台研发部为例，我们选择了 4 大类共 6 个指标作为质量度量的核心指标。

• 需求平均缺陷数/研发月人均缺陷数：用来衡量体现在每个需求上的以及每个开发人员的缺陷密度。
• 缺陷关闭时长/缺陷关闭率：即研发和测试在缺陷修复和验证上花费的时间、时间占比，用以度量解决缺陷的速度和效率。
• 部署回滚率：用以度量项目团队对系统可靠性和稳定性的把控程度。
• 线上事故数：用以度量生产环境下各个级别线上事故/问题的数量。

通过对这些指标的同环比分析、趋势分析以及与行业的对比分析，反馈出提测质量以及线上质量等问题，有利于各个部门发现问题并及时调整，保证持续的高质量交付。

7.3 质量文化建设

质量文化建设的意义在于创建和培育一个团队内部注重质量的价值观和行为准则，增强团队成员在质量方面的参与感和责任感，促进持续质量改进。在质量文化建设过程中，重点是全员参与。在内部，为了对系统功能进行查缺补漏，并提升用户体验度及推动探索式测试理念和思维方式落地，我们开展了 “缺陷大扫除 “活动。由于报名的团队和业务线比较多，采取了以业务线为单位两两结对的方式，结对小组内部进行业务串讲和评分，每组控制人数四至六人。最终共提报 233 个 BUG，并评选出最能” 找茬 “的测试团队。过程中反馈出的共性质量问题包括：

• 用户体验标准不统一，不同人对于缺陷的认知和认定不一致，导致部分缺陷的认定存在争议。
• 针对运营侧体验问题重视程度不够。
• 测试环境与预发和线上环境存在较多功能、体验不一致的地方。

针对以上问题及发现的缺陷，已安排测试同学专题跟进并反馈解决进展。除此以外，还围绕测试用例设计举办了 “寻找最美测试大师——最美 TestCase 竞技场” 的活动。各团队围绕近期迭代的较为复杂的产品功能，撰写测试用例，并提交至评审处。各评委除依据严格的评审标准外，还结合场外观众的下注投票进行参考。随着 “最美测试大师” 悬念的揭晓，各测试团队也基于赛程的历练，实现了自身能力的精进。

7.4 洞察分析和持续改进

在质量治理过程中，我们完善 BUG 等级和事件提报制度。根据缺陷问题的严重程度主要分为 5 个等级，即 P0、P1、P2、P3、P4，其中 P0 最严重，P4 最轻。针对日常出现的线上问题，要求各业务线及时反馈并统一记录至 event 事件系统，针对 P0、P1、P2 的问题组织复盘会并向上提报。各业务线还需内部复盘，发掘线上问题出现的原因并总结出改进措施并推动落实。

7.5 总结、沉淀与分享

测试同学既要不断提升测试专业能力，也要不断加深对业务的理解，同时还需了解一定的开发技术。专业能力、业务知识及开发技术的增长需要通过不断地学习、总结沉淀与分享来实现。我们团队定期组织集体学习和专题分享，每次分享需要有影像资料留存，并将分享的内容同步产出文章，方便后续其他同事随时学习回顾。

除此之外，由于项目和需求非常多，各个测试同学之间经常需要穿插支持，除了正常的 AB 岗之外，还需要对其他的项目有所了解。因此，大家共同梳理并持续维护用户增长测试白皮书，按照项目维度梳理测试相关的内容，包括测试方案、测试用例、回归策略、测试数据、经验教训等，对部分项目的测试策略和测试方法、数据构造进行深度挖掘，沉淀了数个专利。除此之外，我们定期举办测试串讲活动，测试同学基于对系统、业务、用户及技术架构的理解，以自己的语言把业务和系统串联起来，并对产品和研发同学宣讲，同时抛出问题，产研测一起分析并探讨解决方案，通过测试串讲，测试同学不仅加深了对业务和系统的理解，对产品方案和技术架构的优化改进也提供了很多的输入，可谓一举多得。

综上所述，质量运营对于增强团队质量意识和落地质量流程规范有重要意义。在我们的工作实践中，我们一般安排两名 JDS 兼任质量运营的职责，一般需要分配 10%~20% 的时间精力做以上质量运营相关的工作。

总结

本文旨在总结用户增长质量保证方法论，通过 “高质量=质量策略多样化 + 质量流程标准化 + 质量活动规范化 + 质量工具平台化 + 质量运营常态化” 质量方法论公式，把部门的质量意识、思维、行为和目标拉齐，为部门的质量保证同学提供指导。同时详细阐述了用户增长质量保证价值观及方法论的内涵。首先，质量策略多样化强调根据不同业务需求和产品特点制定相应的质量策略，确保满。其次，质量流程标准化旨在建立一套统一的质量管理流程，提高工作效率和质量。第三，质量活动规范化强调对质量保证活动进行全面规划和管理，通过七道质量门禁对研发活动进行准入和准出。第四，质量工具平台化主张利用先进的质量管理工具和平台，提高质量管理水平和效率。最后，质量运营常态化强调将质量管理融入日常工作中，实现全员参与和质量持续改进。

未来，用户增长质量团队质量保证发展的方向主要有以下几点。首先，随着以 ChatGPT 为基础的 AIGC 技术的不断发展，我们正在探索 AIGC 在质量保证全流程的应用和落地，包括但不限于业务知识普及、测试策略设计、测试用例设计、测试代码生成、测试数据构造等方面。其次，以用户为中心的质量管理正在为主流趋势，我们需要更加注重用户体验和反馈，将用户需求和期望作为质量管理的重要参考依据，不断优化产品和服务。最后，敏捷质量管理将进一步推广落地，通过采用敏捷开发模式和敏捷测试模式，我们可以更快地响应用户增长的业务需求和用户反馈，实现快速迭代和持续改进。

作者：京东科技 王先科

来源：京东云开发者社区 转载请注明来源