简介：自己算是阿里的老兵了，从实习开始一直投身在 toB 业务的质量保障领域内，不能说是资深的专家，但所经历的、感受的业务特点和体会还是具有一定的代表性，希望能通过这篇文章，总结一下过往，并能和已经躬身进入这个业务领域，以及将要进入的同学们产生一些共鸣。

眼中的ToB业务

自己算是阿里的老兵了，从实习开始一直投身在 toB 业务的质量保障领域内，不能说是资深的专家，但所经历的、感受的业务特点和体会还是具有一定的代表性，希望能通过这篇文章，总结一下过往，并能和已经躬身进入这个业务领域，以及将要进入的同学们产生一些共鸣。

服务专有钉客户的这两年，更像是场战斗，只有躬身入局的胜利者才能这个竞争激烈的市场上存活。专有钉的深度用户已经将专有钉作为日常工作的一部分，跟我们使用钉钉一样，是生产力工具；再小的体验问题，再小概率出现的偶发问题，在大规模日活下，都极易被放大和激化。

即便都是协同办公的业务诉求，也会因为客户行业特性不同而大相径庭。所带来的定制化需求量会随着不同行业客户的增加出现指数上升，这对产品架构的适配、产品研发交付服务链路上的资源投入均带来巨大的挑战。

虽然服务这些不同行业的头部客户很艰难，但是一旦认可我们，口碑就会在这些行业内迅速传播，带动客户的增长。

结合跟 ToC 产品的对比，我眼中 ToB 业务特别明显的特点有如下几个：

质量保障的难度

2年的建设，专有钉已经成为国内第一大政务协同办公平台产品。对于这份答卷很骄傲，组织也给予了认可，但同时，焦虑、压力也在持续积累，因为这个业务实在是太难做了。

1 客户对质量容忍度极低

专有钉在钉钉产品矩阵中，所承担的责任是服务好政府客户、行业头部大型企业客户。这些客户最大的特点，对数字化是有较深的理解和应用，并非小白客户。我们需要展现出较他们更强的专业性，较之前他们所使用产品更好的体验，他们才能接受我们，认可我们，把我们当成数字化改革的同路人。

原先做公司内部产品，在项目周期紧张的情况下，最先想到的解决方案就是保障主干业务，但做专有钉不能固化这样的意识，因为有 VIP 客户这种角色存在。他们是决策者，但也是一个个人，不同人的产品使用路径、所认为的核心产品功能均不同，但有一个相同点，就是对质量的容忍度都极低，客户认为，已经为产品买单了，高质量就应该是标配。这带来的结果是“主干业务”的定义变得边界模糊，在有限的项目周期内，如何做到测全？

另一个特点，是出现问题时，有人可能会质疑，这明显是你们系统运行指标监控没做好。但公有云上常规的系统指标监控方案在专有云环境下，通常无法运转。问题排查难度大，造成口碑积累的难度也极大。

2 安全生产难做

专有钉跑在专有云环境中，资源、数据、产品，所有的一切都属于客户所有，做安全生产，一要严守用户信息安全，二要严控方案所消耗的资源成本。专有云网络基础设施复杂，目前尚无成熟的全链路问题排查工具，且不同客户环境的云底座、中间件差异大，方案复用度低。

组织协同配合困难，安全生产会涉及产研、交付、一线运维、二线运维、三方isv，且后四者在不同的项目也通常会由不同的公司组织来承接。能力参差不齐，职责清晰的难度大。

3 测试技术融入研发过程的迫切性高

专有钉产品在极其有限的版本周期内，既要实现 70~80 个业务需求，又要严格遵守质量门禁，压力极大。质量团队在坚守质量原则的基础上，需要在研发自测阶段提供给研发效率高、覆盖广的测试能力，以此将质量风险消灭在项目前期。

开放生态的背景下，大规模的isv产出物将融入专有钉产品，质量团队需要做质量兜底。将 isv 纳入到质量保障体系中，任重而道远。

4 云原生适配难度大

专有云发展了多年，市场上不乏竞品。客户看中专有钉的专业性，但要让他替换昂贵的云底座成阿里云飞天底座，可能就会迎难而退，发展云原生是出路之一。当前云原生产品缺少标准化，这对测试工作就是场灾难。辛苦完成了测试，由于客户现场部署架构不同，所用的云原生产品规格不同，导致 bug 频出，打脸的同时也无奈。非标下，测试结论无法复用，甚至显得无意义。

当前缺少成熟的安全生产、质量保障的云原生产品，线上可运维性差，稳定性保障能力不足，巧妇难为无米之炊。

5 测试工作具有专业性难度

除了要攻克专有云的技术屏障，在其之上测试功能、性能、安全生产能力建设外，还需要针对核心业务做业务专项测试，比如 IM、音视频、文档等。

略有成效的方法

上述难点有些是做专有钉产品第一天就要面对的，比如专有云的技术屏障，而有些是在业务发展中逐渐出现，比如云原生的适配难度。应对这些难点的策略方法也同样并非一蹴而就，在攻克老问题，迎接新问题的反复中，专有钉质量团队也沉淀了一套适配当前 ToB 业务的质量保障体系，体系取名“定坤”。

1 数据为基础

专有钉产品从诞生便以推动政企客户数字化改革为己任，高质量、高稳定、优体验是这个产品必有的特性，保障体系从建设之初便和产品本身一样，以数字化来驱动，把所有可定义的过程、结果均尽可能地做了结构化，并在其基础上做加工、分析、决策、驱动。

数字化驱动质量风险防控

质量/过程风险数据的结构化，需要标准化的研发流程、缺陷流转规则做匹配，让离散的数据通过规则分析，具备决策和驱动能力。专有钉的研发流程将集团产品 Aone 的能力用到了极致，需求管理、版本管理、缺陷管理全部标准化执行，完全可以作为 Aone 的样板工程存在。

数字化推动研发测试能效提升

专有钉的客户对数据极其敏感，数据安全等级极高，引流回放等的获取均存在天然屏障，如何获取尽可能多的脱敏数据，用到质量保障策略和方案中，是急需但必须谨慎对待的课题。

线上客户数据获取困难，但线下每一个功能用例的执行流量却蕴含着价值，流量基于 jvm-sandbox 获取。可以从中挖掘出sql执行、缓存使用等过程中的性能隐患；也可以沉淀出业务调用链路，基于此，结合故障等级定义、监控覆盖情况、预案覆盖情况，形成产品安全生产能力视图和工作台，直观、高效地开展安全生产工作。下图就是其中一条流量，存在缓存重复调用的性能隐患。

数字化推动产品体验提升

专有钉产品以客户端作为用户体验的前沿阵地，集团提供了较为成熟、丰富的移动端专项评测能力，我们在此基础上完善了整体调度、自动触发执行，以及自动生成竞品报告等能力，用竞品分析数据来推动客户端体验的提升。专有钉在 PC 端有着更加广泛的应用前景，科创端是当前国家大力发展的方向，而集团缺少相应的专项评测能力，我们采取了自建的模式，目前已具备端稳定性、端性能的PC端专项评测能力。

2 风险防控为基调

由于客户的容忍度低下，交付周期又极短，无法通过长时间的灰度或者靠出现问题后做改进的方式来提升产品稳定性，而必须在转交付前做好充足的测试、防控工作。

高可用测试防控稳定性风险

阿里云飞天底座相对成熟，但云原生不同，商用刚开始，尚未经受过磨炼，在交付前

必须进行高可用测试。这里要给阿里云 ADP 团队做个广告，他们已有相对成熟的平台来进行中间件的高可用测试，业务团队只需整理出基于业务的测试场景即可。

故障演练防控安全生产能力不足带来的风险

最理想的状态是在每个版本转交付前，将增量业务的故障等级定义做完善，同时梳理出增量业务的全链路，并进行故障演练，推动完善安全生产能力，包括监控、故障降级/恢复预案、强弱依赖治理等等（当然现实比较残酷，项目周期过于紧张，无法每个版本都进行常态化演练）。专有云上缺少免费的演练平台支持（富裕的可以参考下AHAS），我们采用专有化chaosblade的方案来实现能力，同时搭建平台用来沉淀演练场景，便于常态化高效执行。

容量规划防控机器资源风险

专有云上的容量规划完全是理想很美好，现实很残酷的工作。最早做容量规划的时候，过于单纯，将“具备线性扩容”能力认为是云上机器的标配能力。但现实十足的打脸，实际测试下来完全不具备线性扩容能力，这导致在实验室环境测试下来的容量需求，做推算后和实际不符，必须在每个专有云环境下做真实的性能压测，成本和可行性都备受挑战。当前虽然用了各种算法来做尽可能接近的估算，但依然无法减少真实压测这一环节的资源消耗。

项目研发过程质量风险管理

基于质量、风险数据，结合标准化的研发、交付、服务流程，制定了全生命周期软件质量分体系，覆盖了版本研发阶段、交付阶段以及上线使用阶段整个生命周期，分成准入准出标准和质量分两个载体。当前版本研发阶段的质量分和标准相对成熟，质量分用于事后总结，做后续版本的问题规避，而标准则代表着能否进入集成回归，能否转交付。

要达到标准，获得质量高分，均是有前人总结的方法论，结合这些方法论，并融合质量分数据现状，“在合适的时机智能化地提供解决方案，规避风险”，这是当前建设中的质量风险管理能力的目标。

3 研发效能做加持

2年，我们一直在为业务奔跑，但只要有间隙，提升研发效能必定被提上日程，因为我们坚信这是提升幸福感的出路之一。

自测工作台提升自测效能

要做好开发自测，首先要做的是联合开发，跟PM争取到固定的、合适的自测时间。我们提供了开发主动要求的功能自动化、测试用例，同时提供了专有云下的服务链路调试、版本前后链路对比、测试数据工厂、服务MOCK、基于流量数据的性能隐患识别、性能问题初步筛查等增值能力。“越早发现 bug，修复成本越低”，这乃亘古不变的道理。未来要思考的是，即使自测时间被榨干，也能在提测前充分自测。

分层自动化提升测试效能

自动化从来没有像当前如此被需要，测试团队需要，研发团队也需要，交付团队更需要，根本还是业务特性和当前所处阶段决定。互联网产品搬的迭代周期，军工级的产品品质要求。通过自动化做越多的内容，就有越多的人力出来覆盖那些原本无人力、无技术覆盖的部分。自动化测试我们认定分层的理念，不同层就应该用合适的自动化手段。

专有云服务端低代码自动化平台具备支持 LWP、HSF、HTTP接口测试的能力，同时能支持服务端SDK的自动化测试。之所以叫“低代码”，是因为这个平台从孕育开始（在宜搭出现之前）就开始秉承“低代码”的理念，让所有想做接口自动化的同学能上手，无关编码能力，目前提供了简单配置实现、流量自动生成两种用例生成方式。下图是配置页面：

客户端不仅采用了 UI 自动化做端到端的功能覆盖，同时对 JSAPI、端上 SDK支持自动化测试。UI自动化还需要考虑一码多端适配，即一套代码能在不同的端稳定运行，端越多，自动化发挥的价值就越显著，节省的人工投入就越可观。

自动化不仅仅体现在功能测试上，在性能测试、客户端体验专项测试，均是优先考虑通过自动化来实现。一站式性能测试平台实现从执行、结果分析、瓶颈定位、基线控制的闭环自动化。客户端体验的大多数专项测试均能自动触发执行，自动生成竞品对比分析报告。在产品版本质量保障过程中，自动化也无所不在，自动生成质量日报、自动生成转交付申请、自动生成版本质量报告、每天定时自动播报风险......

质量标准提升组织协同效能

钉钉希望携手合作伙伴一起投入数字化改革的浪潮中，随着生态开放，钉钉提供底层能力，让 ISV 在上面随意畅享，实现他们的梦想。梦想的实现不能务虚，而是需要实实在在的协同机制、约定来保障，质量就是所需要保障的其中一块。专有钉的开放平台上连接了数千个 ISV 产出的应用、数量庞大的 SDK 和 API，为了保护自己，也更好的协助 ISV 提供高质量的产品，测试团队制定了ISV 产物的质量准入标准，同时逐步将我们用的成熟的测试能力提供给 ISV，让质量保障更加的容易，更加的公平。