知乎客户端目前实行单周发版，每个版本都需要经历开发自测、产品验收、QA 回归等阶段。商业广告存在大量的广告位和模板，测试时无法在线上刷全所有广告样式。早期离线准备了所有广告 Mock 数据，验收过程中存在如下痛点：
- 研发、QA 使用的离线 Mock 数据不统一，沟通成本高，操作复杂
- 研发和 QA 各自在本地维护 Mock 数据，使用 Charles 的 Map Local 功能进行数据替换。各自维护数据存在数据不一致、数据时效性低的问题。复现 bug 时经常因为数据不一致 导致表现不一致，徒增沟通成本。
- 人工维护的 Mock 数据，在进行异常情况测试时需要频繁修改数据，容易出现改错数据，误报 bug 的情况。
- 视频等数据存在过期校验，使用本地 Mock 数据，每次都需要重新生成有效视频链接，步骤复杂，浪费大量时间。
-
测试门槛高
所有参与项目验收的同学，都需要学习 Charles 的使用方法，手机安装 SSL 证书，了解每一份本地 Mock 数据的用途。
-
线上验收耗时长
进行线上验收时，需要从广告投放系统创建测试的合同、订单、广告，广告审核通过后，才能在线上刷到。流程过长，准备工作较为繁琐。
-
埋点验收复杂
广告埋点都经过了加密处理，QA 验收时，需要解密每一条埋点信息，才能确认埋点是否正确。除此之外，商业广告埋点数据发送到生产环境埋点统计服务，自动化无法实时获取埋点统计数据，导致商业广告客户端自动化无法校验埋点。
为了解决上述问题，知乎商业化质量保障团队设计实现了客户端工作台 —— Simba。在此工作台上，所有项目组成员可以通过扫描广告二维码预览到线上所有广告位的所有模板 / 样式；也可以通过在工作台上勾选、编辑需要测试的广告模板数据（后文称基准数据）进行精细化测试；测试过程中埋点数据自动分析统计，工作台实时展示广告的各种类型埋点数量。同时，Simba 还提供广告素材接口给客户端自动化测试服务，广告素材库更新后，无需修改客户端自动化用例代码，实时更新广告素材。工作台原理如下。
工作台原理
预览
工作台从业务数据库获取广告 id 、创意 id 等字段，按照预览链接规则拼凑成 Schema 链接并生成二维码。客户端扫描二维码后路由到相应的广告页面，在请求 Header 中写入预览链接，给后端发送广告请求。开屏、问答、首页等后端服务，透传预览链接到广告引擎。广告引擎根据请求 Header 中的预览链接返回指定广告。如图一所示。
图一 广告预览原理图
多用户代理
除了上述扫描二维码进行广告实时预览的方式，工作台还提供了代理服务和基准数据，供验收人员修改广告数据，进行更详细的测试。日常工作中，需满足多人同时验收的场景，因此，工作台引入了 Mitmproxy 实现多用户代理。每个用户在工作台上获取、使用专有的代理服务，请求和返回互不干扰，如图二所示。Mitmproxy 可拦截请求、响应，并对其进行修改，同时提供命令行工具 Mitmdump 。启动 Mitmdump 服务时通过添加 -s 参数加载脚本对接收到的请求进行定制化操作，然后返回响应数据。添加 -H 参数为代理的请求添加 Header 来区分用户。
图二 多用户代理
以上就是工作台的主要原理，接下来介绍下工作台的架构和实现。
工作台架构
工作台前端使用 React + AntD 实现，共有 3 个模块，分别是预览、mock、代理 (mitmproxy)。
工作台后端使用 Python Flask 框架，共有 4 个模块，分别是预览、定时任务（基准数据）、mock、代理 (mitmproxy)。
图三 工作台架构
下面我们详细介绍一下 4 个主要模块。
预览
QA 在生产环境创建一批测试广告，置为已拒绝状态，对生产环境无影响。工作台后端通过各广告位预览请求拼接规则生成 Scheme 链接，存储在工作台数据库中。工作台前端展示预投的广告素材及 Schema对应二维码。用户可根据广告位、广告模块、广告样式快速筛选需要验收的广告，使用知乎客户端扫码功能即可跳转到指定广告页面，验收指定广告。如图四所示。
图四 广告预览
基准数据生成
1、基准数据定时器：工作台后端根据预览模块预存的 Schema 链接，以及通过代理服务获得的生产环境广告请求 Header，每天定时模拟广告请求，获得广告响应数据，保存在工作台数据库中作为基准数据。当响应字段发生更改时，更新基准数据。
2、视频数据更新定时器：工作台从所有的 Schema 链接中筛选出视频类广告的预览链接，在基准数据和用户数据中筛选出通过上述 Schema 返回的广告，根据视频 id 重新获得视频链接，定时更新工作台视频基准数据。
3、广告落地页实时更新：在进行不同类型广告落地页测试时，工作台提供了基准数据指定字段 value 值替换功能。这样验证 10 个不同的落地页类型，只需要保存一份基准数据，另外预设 10 个落地页值即可，降低基准数据维护成本。
Mock
Mock 模块提供基准数据复制、基准数据开启、请求 Header 校验和埋点统计等功能。
1、基准数据复制：如前所述，基准数据定时更新为线上最新的接口返回，保证了数据的时效性。验收人员开始一轮测试时，可以复制一份基准数据到个人目录，作为自己的 Mock 数据，然后进入个人目录，勾选特定的数据进行测试。如图五所示。
图五 Mock 数据模块
2、基准数据开启：工作台接收到 Mitmdump 发送的广告请求时，检查 Mock 数据是否启用，如启用返回用户开启的基准数据；否则，使用 Header 中储存的原始数据构建请求发送至目标服务。
3、请求 Header 校验：请求的 Header 出错时，会导致返回的广告数据不符合预期。而 Header 的检查字段多且容易遗忘，为此工作台提供了自动检查功能。对转发到工作台的所有请求，进行 Header 重要字段校验，在工作台上实时显示校验结果。如图六所示。
图六 请求 Header 校验
4、埋点统计：工作台接收到 Mitmdump 发送的埋点请求时，解析请求的 Header 和请求 Url 中的参数，并进行解密，将获得的信息以广告为维度汇总并存入数据库。工作台前端按照广告位、广告、曝光数、点击数等维度，统计当前展现的广告的关键埋点数据，如图七所示。
图七 埋点统计模块
5、客户端 UI 自动化用例接口：自动化测试通过 Scheme 打开广告所在页面对广告进行操作，工作台自动化用例接口接收广告位 id，将此广告位的全部 Scheme 进行样式去重后返回给自动化进行测试。
6、自动化埋点校验接口：编写自动化用例时在 Scheme 后添加固定参数，形如：Key = 工作台 Host : 工作台 Port / 工作台路由。引擎端识别关键字「Key」获得工作台埋点请求的接收地址，并将此地址添加到广告的第三方监控链接中。这样广告发生曝光、点击时，工作台就会接收到广告的埋点请求，调用上文埋点统计功能对请求进行处理。如果 Scheme 中无关键字 Key 则引擎不会有任何特殊操作，因此对正常广告没有影响。在自动化需要验证埋点数据时，请求工作台自动化埋点校验接口获取广告曝光数、点击数等进行断言。
Mitmproxy
Mitmproxy 模块用来过滤、转发请求。用户启动的 Mitmdump 服务在后端服务器上，对用户无感知，且不依赖本地环境。每个用户使用自己的 Mitmdump 代理服务，所以每个用户之间任何操作都不受影响。如图八所示。
1、启动 Mitmdump 时增加参数为此代理接收到的请求增加 Header ，如 Port 用来标记请求，供后端识别请求所对应的用户。
2、增加参数来指定脚本，脚本可以选择性的拦截请求（广告请求、埋点请求等），拦截后修改请求的 Host、Port、Path、Schema，将请求转发到 Mock 模块，同时增加 Header 用来储存请求原始数据，供后续使用。
图八 代理模块
总结
知乎商业测试工作台，为解决线上全量广告卡片模板验收应运而生，目前广泛应用在样式验收、开发自测、版本回归等场景，极大的加快了测试的进度，缩短测试时间。通过和客户端 UI 自动化结合，自动截图全量样式，极大的便利了设计师验收，设计师验收效率提升 4 倍。版本集成回归时间已从 6 小时减至 4 小时。目前平台持续接收产品、开发的需求进行迭代，为商业质量保障提供有力支持。
作者:wmaidouw
出处:https://zhuanlan.zhihu.com/p/70876764