本文旨在介绍精准测试模型原理与多维表格工程的应用，部分代码细节和算法释义不在正文中推导&聚焦，相关同学有兴趣可以阅读原文评论区交流。

背景

随着当前公司的快速发展，各个业务线拥有数千个前端项目，需求迭代越来越快，系统架构越来越复杂，测试周期越来越短。比如飞书多维表格业务是基于No-code，提供GUI能力的个性化效率应用平台，前端功能众多且内聚，版本节奏迅速，用例膨胀庞大。迭代至今一周一发版的现状下，单次回归测试就至少需要20+人日投入，所以人效问题成为了重中之重。与此同时，业务还具有链条长、系统结构复杂、依赖人工保障等多个特点，这就导致会存在以下问题：

• 回归测试的精准性需要提升
• 黑盒测试的充分性难以衡量
• 开发人员与测试人员之间的交互和沟通存在壁垒
• 测试风险分析的颗粒度粗放导致结果可信度降低

测试同学在长期业务跟进中，积累了巨量的测试用例与执行结果，在快速迭代的需求任务场景中，如何利用有限的资源人力快速应对与日俱增的业务需求成为面临的主要问题。为解决上述难题，精准测试在敏捷&效能的背景下应运而生。

对此， 精准测试通过深入系统代码层级，更加有针对性地聚焦测试范围，提高测试过程的可追溯性和透明度，整体性提高测试工作效率和质量，将“好钢用在刀刃上”，为解决上述问题提供了新的思路和方案。本文在深入分析精准测试诞生背景及应用价值的基础上，尝试总结了飞书(多维表格)业务构建精准测试体系的可行路径，并对其后续发展前景进行了展望。

名词解释

• 飞书多维表格(http://base.feishu.cn)：飞书多维表格是飞书平台提供的一款高效的数据管理工具，它支持多种数据类型和灵活的表格布局，能够满足企业日常工作中对于数据记录、整理和管理的多样化需求。
• Bits：字节内部的一站式平台及服务，本文主要用到测试管理/创建、场景规范化、报告数据化相关功能
• Research Center：字节内部中聚焦学术前沿在工程上的应用部门，本文主要涉及端智能化方向的相关应用

目标

在有限的测试资源及人力条件下，如何以最小代价更快速的发现问题，是探索精准测试的主要目的。

• 基于代码的智能化白盒测试能力，让测试人员更准确地掌握测试范围
• 构建代码覆盖率监测能力，能在测试完成后输出测试有效性度量数据
• 基于公司平台承载可视化能力，精准定位错误原因

综上所述，精准测试可以在测试范围分析、测试结果覆盖度度量以及缺陷定位等方面提供数字化的分析手段，进而更好地发挥研发过程数据价值，助力测试效率质量双提升的目标。

模型原理

基本概念

精准测试是一种应用于黑盒测试方法的代码级测试覆盖技术，与传统的白盒测试开展代码覆盖测试不同，它将黑盒测试和白盒测试进行了有机结合，通过获取测试用例和代码逻辑之间的关联信息，可以获得白盒测试级的代码覆盖率数据， 精准确定测试范围，提高测试用例设计的针对性和有效性，精准衡量测试执行结果，确保所投即所测，突出测试过程的“可追溯、可量化、透明化”，更有效地发现程序深层隐藏的缺陷， 在相对有限的测试资源投入下实现更高的信息系统质量，从而达到“精准测试”的 目的。

这个“精准”主要体现在：

1. 在测试执行过程中，获取和收集底层代码运行数据，能够可视化地看到代码执行情况（代码执行充分度）， 进而为补充或减少冗余用例提供依据
2. 通过对变更代码的识别，可精准圈定需要回归测试的用例范围
3. 对发现的缺陷，通过测试用例可间接实现对代码的精准定位

在此过程中，需要用到统计代码覆盖率、代码插桩、连接代码和测试用例、测试用例智能选取、智能缺陷定位等技术。

相关技术

代码覆盖率

代码覆盖率是指至少被执行了一次的条目数占整个条目数的百分比，最常用的度量代码覆盖率有四种方式：

1. 行覆盖率（Line Coverag）：是否每一行都执行了
2. 函数覆盖率（Function Coverage）：是否每个函数都调用了
3. 分支覆盖率（Branch Coverage）：是否每个分支都执行了
4. 语句/指令/声明 覆盖率（Statement Coverage）：是否每个语句都执行了

当然覆盖率准则其实还有很多方面，例如路径覆盖率、循环覆盖率等，不过举一反三，所以这里不对各种准则进行解释了。

统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性地进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码

我们通常希望代码覆盖率越高越好，代码覆盖率越高越能说明测试用例设计是充分的，但测试的成本也会随着代码覆盖率的提高以类似指数级的方式迅速增加。

代码插桩技术

在保证被测程序原有逻辑完整性的基础上在程序中插入一些探针（又称为“探测仪”，本质上就是进行信息采集的代码段，可以是赋值语句或采集覆盖信息的函数调用）。（摘自百度百科）

覆盖率产出建立在代码插桩的基础上。根据插桩时机，分为编译时插桩和运行时插桩。

• 编译时插桩，即在代码转译过程中插入覆盖率采集代码，产出代码本身即拥有采集能力
• 运行时插桩，即产出代码本身不具有采集能力，在运行时通过hook的方式在使用的代码中插入覆盖率采集代码

不同于使用babel的编译时插桩，运行时插桩需要额外的hook一步。本质上处理逻辑都一样，这里只介绍利用开源istanbuljs工具编译插桩的原理：

抽象后的图示更简而易见其工作原理：

构建测试用例与代码关系

测试人员在进行黑盒测试的过程中，测试工具(例如录制工具)捕获测试用例步骤关联的函数和相应的调用关系信息，将测试用例、用例相关函数信息、关联函数调用关系信息存储起来形成知识库。而形成知识库的过程，对测试人员和开发人员来说是透明的。构建测试用例与代码关系的过程见下图

测试用例智能推荐

重点：参见原理概况，输出详细推荐机制

测试用例智能选取可根据程序的变动情况对测试用例的优先级进行分析和打分，筛选出优先需要执行的重要用例。使用智能回归测试用例选取功能算法的前提是至少需要两个插桩版本的应用程序。

在回归测试用例选取的时候，会对比选中的工程版本对应的代码，分析代码版本涉及的函数变化，进而通过函数与测试用例的对应关系，推导出涉及到的测试用例，从而实现回归测试用例的自动选取，大大减少回归测试的时间及风险。

智能缺陷定位

缺陷通常是由开发人员来进行分析和定位的，而精准测试则通过用例和代码建立的关联关系，能够将缺陷对应代码出错位置直接定位出来，这相当于增加了测试数据和测试过程的本身价值。

因为精准测试技术可以获知每个用例执行的详细路径信息，如果测试人员告知用例状态（例如是否通过、 是否正确），那么精准测试算法就会根据正确和失败的路径进行差异计算，给出缺陷出现具体位置的可疑度排名，因此对于测试人员来说，只要找到类似的输入，程序在输出上有对错区分用例， 就可以实现智能定位缺陷功能。

原理概括

以下我们详细展开介绍下精准推荐的原理以及流程：

1. 采集用例执行期间的函数级别代码覆盖率，建立用例<->函数的双向关联关系；
2. 根据代码变更，推出受影响的函数，再推出和与之相关的用例集合；

• 语义化 Diff 支持从两个 commit 中提取出变动方法，变动类等语义信息，根据两个 commit，将改动部分以图的形式展示出来，方便用户直观的看到本次修改涉及的影响范围
• git diff 为纯文本信息，提取相关函数信息可能需要手动匹配，语义Diff目的为 MR Diff 提供语义化信息的提取，以帮助分析代码改动所造成的影响。当监听 CodeBase 得知有提交( commit 或 MR )时，会传递参数(变动的文件路径、commitID 等)，来触发处理逻辑，去提取文件的语义信息(函数与类关系、函数起始行与结束行、函数类型(静态、类方法等))，然后和 diff 信息进行对比，得到变动的函数信息(变动占比等)，最后查数据库返回相关的 funcID。

• 查询MR对应改动信息后，基于Diff出来后的Function、代码块等信息确定改动影响边界范围，基于明确的改动影响边界范围与代码块&&函数粒度用例调用信息索引，完成代码块&&参数粒度的关联用例召回；

• 这个步骤主要用于去除用例集合中不在此次关联Diff中函数索引的相关case，生成基本范围列表

• 基于召回用例，完成用例相关性/执行优先级等预估排序打分，并生成用例推荐集，反馈用户；

  其中：

  Score(i)：表示用例ckaase的最终得分

  num()：表示函数function关联的case数量

  num( )：表示block关联的case数量

  ：表示用例中的函数集合

  V：表示函数基本得分，为常量

  Total: 表示总共存在的用例数量

  释义：其中num()和num( )成正相关，代表代码层面的关联情况。V、total作为常量，用于计算函数得分和补充得分

• 打分机制通过函数得分基本和关联用例数量成反比，case分和关联函数成正比的逻辑，计算出范围内Diff全集中函数&代码块的累积得分，然后根据补偿曝光得分作为去噪，最后算出用例的总得分。主要基于以下公式进行预估

• 排序：

最后的整体流程图如下：

有了以上相关技术的了解和原理的深入，我们就可以在此基础上应用具体的业务进行实践应用，在具体业务中进行分析和调整，本文之后将以多维表格业务为基础原型展开应用介绍。

飞书业务实践

飞书多维表格的Web端需求&回归用例已突破1.5w+，测试耗时久且验收成本高，需求&回归效率的提升是急需解决的问题。精准测试是Web端质量工程智能化建设的趋势，在行业内也有一些开源和实践进行精准落地。通过精准测试既能达到既保障测试质量，又可以大幅度节约测试人力。

业务现状

多维表格Web端回归用例已到15000+ 用例的高成本，单仓库周迭代节奏导致实际执行时间极具紧张，发现问题遇见瓶颈，回归ROI的提升是急需解决的问题，主要体现在：

• 走查效率：迭代频率加快后，每周需要发布一次大版本，基于原有人力，至少存在12人日/周的缺口；

• 测试有效性：基于业务某月份数据，其中用例问题占比为：35.9%，用例方面原因主要是如下两个：

• 用例问题：

• 回归关联功能，已有用例但是由于评估范围不足导致遗漏
• 新需求用例&评审缺失的情况

• 信息互通问题

• 评估范围出现遗漏情况

• QA对改动不感知导致逃逸，比如顺手优化代码情况

因此面对业务的严峻情况，必须采用有效的手段在保障质量的基础上，提高交付效率，精准测试则成了必备之选。

业务应用

公司内外部针对精准测试都以客户端为主，主流支持Android&IOS，对于JS侧的Web端则无直接方案可直接应用。因此多维表格 QA和Bits、Research Center携手合作，从0-1的建立起Web端精准测试的体系落地，主要包括覆盖率工程、录制推荐工程、业务扩展工程三个部分，在实际业务中取得了较为显著的成效。

覆盖率工程

由于多维表格业务是重前端的形态特征，整个功能都高度收拢耦合在Web可视化界面。且之前的测试没有前端覆盖率指标，且导致测试不可控，功能范围无感知，无法高效精准，不可衡量ROI，所以覆盖率工程成为迫在眉睫的需求。

飞书多维表格业务利用模型原理中介绍的插桩技术，对前端代码仓库进行babel转译阶段植入统计代码，建立插桩分支独立部署规范流程，与研发流程紧密结合。最后再结合Bits平台进行可视化能力展示，输出指标&报告：

当覆盖率工具成型，也就形成了前端&QA的测试闭环，且完成收拢在Bits平台上，极大提高测试效率。

对于接入覆盖率信息应用到实际流程中落地，多维表格业务接入卡点流程规范、门禁阈值、分支管理等步骤后，在开发阶段、自测阶段、测试阶段和上线四个环节中，利用开发流程介入完成覆盖率上报，嵌入多参综合阈值形成卡点门禁类似的质量把控，严格量化测试效果确保上线交付。最后的应用卡点流程如下：

实际整个多维表格业务的前端覆盖率流程，从产品需求提测后的视角出发，涵盖RD&QA同学的全部操作，从需求提测开始、包含覆盖率插入、指标分析、预发回归执行、卡点数据校验、最终逐步开始灰度分布节奏

通过上述工程解决了业务本身存在的黑盒测试的充分性难以衡量、QA&RD交互壁垒、测试结果可信度低等问题，保障了高质量交付，作为精准测试开始的第一环实际落地。

录制推荐工程

建立前端覆盖率机制背景下，如何进行双向关联代码&用例关系，从而进行测试用例智能推荐成为了关键性问题。由于覆盖率数据已经具备，因此解决的思路是通过在回归测试时对初始化状态进行上报，录制采集用例过程，结束执行时再次上报，利用唯一标识和时间差数据来完成关系建立

鉴于公司内部暂无支持Web端代码和用例关联的录制平台以及工具，所以录制工具(Case Record)是由与Bits团队合作开发Chrome插件实现，利用测试人员手动触发进行录制动作，既可以完成双向关联关系的绑定。

从技术角度出发整个流程经历 Bits 前端->Bits后端->SDK 收集->精准测试 这个链路，通过数据流转完成关联关系录制、分析、索引打分排序和最终推荐

• 测试同学定期录制人工用例，通过用例录制插件上报数据接口，传输录制数据；
• 后台接收录制数据，并基于全量代码的代码块&&函数索引，落盘存储；
• 用例录制后，自动触发用例索引生成接口，完成信息索引生成与更新；
• 需求&回归时根据Diff情况，进行召回推荐，利用(1)公式的打分准则进行排序，完成最后限定推送

从操作视角的交互流程本质希望拥有一个介入性轻的精简方案，使得在每一个版本维度或者需求合入维度，都能在不耗费大量时间成本的情况下获得用例进行执行&验证。

• 操作角色视角(版本发版or需求流程)，研发者&测试者的任务成本(主要聚焦在打包、录制、推荐三个环节)：

1. 研发者

1. 提交业务代码 (↓ 1h)
2. 构建piepline自动打包流水线 (↓ 2h)
3. 校验测试需求报告结论 (↓ 0.5h)

2. 测试者

1. 录制陈旧&新增用例，版本回归 (↑ 1h)
2. 手动创建测试计划&获得推荐用例 (↑ 5min)
3. 执行全量用例，回归&需求阶段 (↓ 3h)
4. 测试标准报告输出 (↑ 1min)

从录制动作结束后，获取推荐用例的流程全部都集成在Bits平台，在新建测试计划的时候，填写必要信息进行版本推荐，状态结果信息直接以机器人自动推送用户，全程流程与原先测试步骤无异。

演示效果

(自动化推荐)

因此业务在此处结合自动化+机器人流程达到0侵入方案，完成双方视角下的效率提升。利用流水线把整个录制推荐流程串联，以达到一键触发业务推荐。pipeline主要包含以下功能：

• Bits平台新建测试计划
• 精准测试获取推荐用例
• 自定义策略精简推荐结果
• 用例得分详情
• 重写测试计划

至此阶段，已经能大致满足业务的实际需求，可以初步完成精准测试的需求。但还是存在部分用例冗余、录制频率更新等问题，因此还需要针对这些问题做出改善扩展，才能真正达到业务批量落地的提效。

业务创新

背景

由于Web端推荐的复杂性，现有支持的推荐策略粒度还停留在比较粗糙的阶段，用例收益在飞书多维表格业务只能达到20%左右，ROI过低导致无法作为线上发布的标准。因此，多维表格业务在原有的推荐基础上增加了精简工程，做出符合业务特点的适配精简，最终使得用例收益从20%递增到60+%，成为能批量应用落地成功的关键。

精简工程

此部分内容结合业务进行扩展，理论结果统一准出适用，但具体指标无法通用，需要进行实验分析适配

由上面介绍，现在多维表格业务的整体流程可以抽象为如下几个阶段和步骤，其中的大多数已经在上述文章中进行详细介绍分析，可以观察发现基于已有能力的"精准推荐"结果，还是会存在大量冗余用例集合、版本过期时间无法界定、关键路径无法已知等问题，这些问题迫使业务在批量应用时跟不上需求迭代，因此依旧需要在原始推荐集合的基础上继续精简才能达到工程化的目的。

所以回归精简用例集的环节成为了重中之重。这里的精简的思路可以拆分成几个部分：

1. 在哪个维度精简用例集合是比较合适的？
2. 精简的效果如何判断？存在理论依据吗?
3. 精简思路的推广性如何？可以解决其它什么样的问题？

一.在哪个维度精简用例集合是比较合适的？

首先基于推荐接口返回的数据，业务调用者可以获取到覆盖率信息、Diff范围、函数信息、推荐reason、用例集合和代码位置，根据先验知识，得出第一条准则：

这里准则的推演显而易见，推荐分数过于小的用例代表着在此次关联范围中，范围的权重是极低的，因此可以被看做是"不相关"用例进行剔除。

• 推荐分数据中过于小的用例集合可以进行精简

有了第一条准则的经验，我们是否能思考在函数粒度中，是否也存在这样权重极低的函数，它们大多是一些底层库函数，或者是一些和此次提交完全不相关的业务函数，把这些函数进行剔除，是不是就可以继续精简一部分用例集合。

二.精简的效果如何判断？存在理论依据吗?

有了上述思路，我们继续实践论证，首先我们采用原始推荐、1000、500、200四个函数数量作为实验变量阈值，进行剔除删减，在三个版本迭代中得到以下数据：

这里取4.2版本数据作为实验数据。由于原始推荐用例数据关联的函数信息是一个一维列表，无法很好的进行数据处理和建模特征不足，所以这里进行升维处理，将数据投影到一个更高维度的空间中，将简单的函数特征通过若干组合形成新的特征

将这些用例在N维空间上的表示将是一些散点的方式，我们任意取一个点对其求欧式距离：

得到一个距离列表

，将这个M列表的四种概率直方图画出，可以发现均呈现出中间高两边低的特征

图1.特定用例-用例距离图1.缺陷-用例距离

多次试验后利用图1数据分析，利用K-S检验得到P值(<0.05)判断M的分布近似正态分布， 我们利用近态转换算法做出相应的曲线可视化观察，使得最后的结果符合正态分布特征

借此得出一个基本的结论：用例集合在关联函数映射的高维空间中的欧氏距离中呈现近似正态分布

有了这个基础结论，接下来就好进行了，我们只需要论证两个结论：

• 阈值过滤后的新分布与原分布大体保持一致
• P()的对应置信区间要保持大等于的关系

首先我们利用机器学习中常用的衡量两个分布的差异性KL散度作为基础指标

由于KL散度的非对称性，结果实验得出这里利用Wasserstein距离进行判断更为合理(越小越好，0为相同)

最终利用实际业务线上缺陷：x = 7.416、4.795、6.856为实验数据作为验 证点，得出EM距离表格，由原始推荐向三个阈值1000/500/200的数据分布虽然呈递增趋势，但总体的EM差异性<1，基本可以忽略不计，因此第一个结论可证

针对置信区间的概率 论证这个结果只需要对应的正态数据分布满足：分布曲线变低或者左移，如果同时互斥，则把数据分布变为标准正态分布，利用置信表直接查阅可得实验数据(P点概率也相同)

只以x=7.41为例(其余试验数据在此处不展示，有兴趣同学可以复现)，观察上述数据可以得出以下结论：

• P(x)的点概率没有劣化
• 的累积概率上升
• 95%的置信区间都可测试覆盖

特殊情况：由上述分布图可直接观察得出函数三个阈值都使得曲线变低，导致上述表格列举的三个缺陷距离 都分布在左侧，所以不用查置信表即可得P的关系成立，结论可证

缺陷与用例之间的关联基本都会小于均值，因为如果分布在右侧，则证明这个缺陷和已存在用例集合D中的相似度极低

因此最后得出结论：利用阈值1000/500/200的过滤函数条件，不会使得用例全集在线上的问题召回率上升

另外，此种方法也适用于录制时间分析和关键路径提取，其思路是：

• 过期后的数据分布会与原始分布产生大的偏差，可以得出临界时间
• 关键路径会集中在概率密度函数最高的区间，比如 的95%置信区间内

业务收益

线上问题召回率打平目前全量回归走查方法的指标，推荐冗余降低60+%，测试人效提升30+% ；

用例收益

飞书多维表格业务从2022年Q4开始陆续在实际中落地精准测试事项，迄今为止总共回归试验了12个版本，从未开始精简工程的12.2->3.3的平均用例收益30%，到3.4版本采用后的平均月收益达到了54+%，侧面论证了业务扩展的有效性，也在用例精简上产生了很好的效果。

录制成本

针对录制成本统计主要基于2023年3月的两个版本，通过10个不同测试人员6天的执行量和执行耗时，最终得出以下数据(最初版本)：

备注：这里存在三个因素导致数据波动

1. 录制环境不稳定
2. 录制接触成本&答疑时间
3. 统计执行时长存在波动，不一定100%对应完全准确的执行耗时

根据以上详细数据的分析，可以得出录制成本数据，进一步得到效率损耗数据：

• 效率损耗：9.08% (最初版本)
• 效率损耗：3% (至今版本)

截止到目前2024年5月，随着录制工具的迭代和测试规范的建立，最新线上版本的成本损耗已经基本可以控制在3%~4% 波动；

测试人效

对于实际业务测试成本的计算，除了推荐冗余的用例收益，还需要考虑进新增录制动作的成本损耗，才能得出最终人效提升的效果收益：

人效收益 = 用例收益 - 录制成本

从各个方面的实验数据监控观察，精准测试落地多维表格业务已经产生实际的收益。在保证线上问题召回率打平目前全量回归走查方法的同时，推荐冗余降低54%，测试成本降低44.9%，节约了大量测试时间，大幅度提升了人效。真正的帮助测试同学在有限的资源人力下快速应对了与日俱增的业务需求，在保障质量的基础上，切实的提高交付效率。

评判规则

上一章节从数学算法的角度论证了有效性，还需要在业务视角拥有一个评判规则来进行实际观察。

精准测试在业务版本迭代中最大化精简用例集合，节省了大量的测试资源。但是还需要更聚焦在：产品质量不能劣化影响，不能因为引入新的算法思路而导致实际产品的线上逃逸；

计算规则

• 规则一：Num( 版本回归过程中发现的缺陷列表 ) == Num( 精简后最小用例集合可发现缺陷列表 )；
• 规则二：非渗透场景(移动端、纯后端等)业务功能模块，实际线上P0/P1逃逸率未增加；
• 规则三：权重分布区间的分值覆盖用例全集的核心功能，不存在遗漏；

落地数据

实际多维表格业务中某个实验版本中实际的精准推荐集合分布数据(精简区间控制在<13.9)：

版本上线过程中发现的总缺陷列表：

• 实际被发现的缺陷列表数量：36个，无用例和非业务占比12，有效可预测总数24个，精准推荐后可预测数22个。(2个未录制建立代码关联，无预测符合预期)；
• 发现缺陷的用例列表如下(部分)：

由上图可知，在当前版本下实际发现的缺陷列表，即使在利用智能推荐算法进行精简后，对应的缺陷用例也依旧包含，未产生对应的逃逸案例。

在此基础上，经过了超过10个版本的实验观察，最后从业务视角得出评判的有效性。

未来推进

噪音：录制行为是为了将函数与用例进行关联，那些不属于用例逻辑的函数如果被关联，就属于噪音

展望未来，精准测试将建设重点聚焦于以下四个方向：

相关文档

论文参考：

• [1] 金融系统应用精准测试技术的探索(https://xueshu.baidu.com/usercenter/paper/show?paperid=18730xq0xv1v06d05n5p0cy0c3799198&site=xueshu_se&hitarticle=1)
• [2] 商业银行精准测试体系实践与思考(https://xueshu.baidu.com/s?wd=%E7%B2%BE%E5%87%86%E6%B5%8B%E8%AF%95%E5%9C%A8%E5%95%86%E4%B8%9A%E9%93%B6%E8%A1%8C%E7%9A%84%E7%A0%94%E7%A9%B6%E4%B8%8E%E5%AE%9E%E8%B7%B5&ie=utf-8&tn=SE_baiduxueshu_c1gjeupa&sc_from=&sc_as_para=sc_lib%3A)
• [3] 精准测试在商业银行的研究与实践(https://www.cnki.com.cn/Article/CJFDTotal-JRDZ202004032.htm)
• [4] 一种基于缺陷分析的精准测试分析方法(https://xueshu.baidu.com/usercenter/paper/show?paperid=17140e10qg1q0xj0kk7s0tj0vp326167&site=xueshu_se)
• [5] 一种精准测试的实现方法 A method to achieve accurate test(https://xueshu.baidu.com/usercenter/paper/show?paperid=913a657b42107d9afcd859498b1ac209&site=xueshu_se)
• [6] 精准测试白皮书（2020-07-09）(https://zhuanlan.zhihu.com/p/231646196)

合作鸣谢

团队：飞书多维表格、Bits&Smarteye虚拟项目组

愿景：希望与更多同学携手交流

建议接入业务：

• 大量回归人力投入业务，需要提升
• 重前端业务，Web端逻辑复杂
• 迭代节奏快速，发展提升型业务