核心要点
- 多租户架构机械地放大了需要测试的视觉面：一份代码库，N 种视觉上不同的渲染
- 每个租户都可能有自己的品牌（logo、颜色、字体、域名），让同一个应用产生 N 个视觉版本
- 一个视觉缺陷在默认租户上可能不可见，而在某个特定配置的租户上是灾难性的
- 经典视觉测试（基于单一基线）在结构上不适用于多租户
- 按租户的视觉测试是唯一能为每个客户保证视觉质量的方式，不只是为第一个
多租户，按 NIST（National Institute of Standards and Technology, SP 800-145）的定义，是*"一种软件架构模型，其中应用的单一实例服务于多个客户组织（租户），每个租户都拥有逻辑上隔离的视图与配置，同时共享底层基础设施和代码库"*。
如果您开发一个多租户 SaaS，您熟悉这种现实：您的代码库是唯一的，但每个客户看到的是您应用的不同版本。客户 A 在白色背景上有他们的蓝色 logo、自定义域名和无衬线字体。客户 B 在灰色背景上有他们的红色 logo、子域名和衬线字体。客户 C 禁用了某些模块，加了自定义 footer，并配置了完全自定义的色板。
同样的代码。同样的组件。同样的模板。但视觉渲染却可能极不相同。
这是没人足够早问的问题：当您部署一次更新，谁来验证它对您每一个客户都正确显示？
多租户放大了视觉面
要理解问题的规模，让我们做一个简单的计算。
您有一个 SaaS 应用，主要页面有20个。每页有3种断点（手机、平板、桌面）。这就是60种页面-断点组合。
如果您只有一个租户（单一视觉配置），您需要测试60种视觉渲染。已经不少，但可控。
现在加上多租户维度。您有50个客户，每个都有自己的视觉配置。理论上，您需要测试60乘以50，即3,000种视觉渲染。
实际上，并非所有租户都视觉上不同。许多使用默认配置。但即便50个里只有10个有显著定制，您也从60跃升到600种渲染要验证。十倍多。
这一计算还没算上其他变体：每租户的深色模式、语言设置、启用或禁用的模块、自定义组件。每多一个维度都是一个倍数。
多租户不是把您的视觉测试面加倍。它是把它乘起来。
按租户视觉定制的五个维度
租户定制远远超出简单的 logo 替换。下面是产生视觉上不同渲染的五个维度。
品牌：logo、favicon、主色
这是最显眼的维度。每个租户都有他们的 logo，可能是横向的、纵向的、方形的、带或不带 tagline、彩色或单色的。logo 嵌入到为某种尺寸设计的 header 中。一个过宽、过高，或比例出乎意料的 logo 可能破坏 header 布局、导航或登录页。
租户的主色通过 CSS 变量或主题系统应用。但白色背景上的亮黄不像深蓝那样运作。对比变了。彩色背景上的文字可能不可读。作为主色变体的交互状态（hover、focus、active）可能变得难以区分。
字体
某些 SaaS 产品允许租户选择品牌字体。这是一个强大的定制杠杆——也是一个相当可观的视觉缺陷来源。
每种字体都有自己的度量：x-height、ascender 高度、descender 高度、平均字符宽度。把默认字体（为您布局优化）替换为客户字体（不为任何特别的东西优化）会改变行高、文本块宽度、断行，以及可能影响每个含文字组件的整个布局。
为 Inter 24px 一行设计的标题，在 Georgia 24px 下可能换到两行，把它下面的所有内容都推下去。
域名与导航上下文
每个租户通过自己的域名（client-a.your-app.com 或 app.client-a.com）或子路径（/client-a/dashboard）访问应用。域名本身不影响视觉渲染。但 SSL 证书、安全 header，以及域名特定的 CSP（Content Security Policy）规则可能阻止某些资源（字体、图片、脚本）的加载并造成降级渲染。
启用的模块和功能
在多租户中，并非所有客户都有相同功能。客户 A 有 analytics 模块。客户 B 同时有 analytics 和 reporting。客户 C 都没有但有自定义模块。
每种模块组合都创造了潜在不同的布局：导航项目增减、控制面板部分有无、表格列可见或隐藏。每种组合都必须视觉上一致。
内容和客户特定数据
租户带来的不只是品牌。他们带来数据。破坏卡片布局的长产品名。比例不标准的个人头像。超出原定容器的描述。客户 A 用3列、客户 B 用15列的表格。
内容定制是最不可预测的维度，因为它不受您主题代码控制。它取决于您客户在应用中放了什么。
为什么您当前的测试方式不够
大多数多租户 SaaS 团队以下列方式之一对应用做视觉测试。没有一种是足够的。
"默认租户"方式
您只用默认配置（标准主题，无定制）测试。这是最常见也最危险的方式。一个用您默认色板看不出的缺陷，可能在某个客户色板下显得刺眼。一个能配合您横向 logo 工作的布局，可能配合方形 logo 就破裂。
您不是在测试您的应用。您是在测试您应用的一个版本，并希望其他版本也能工作。
"参考租户"方式
您用2或3个代表最常见情况的参考配置测试。这比默认租户好，但它不覆盖极端配置——异常宽的 logo、对比度边缘的主色、度量异常的字体。然而恰恰是这些极端配置产生最严重的视觉缺陷。
"客户报告缺陷"方式
您等您的客户报告视觉问题。这是最糟糕的方式，原因有三。第一：您的客户不会报告小的视觉缺陷——他们默默忍受并失去对您产品的信心。第二：当他们真的报告时，损害已经造成——缺陷已经在生产中存在数日或数周。第三：每一次客户报告的缺陷都是一次支持事件，耗费时间、金钱和信誉。
多租户视觉测试的架构
多租户视觉测试需要一种与经典视觉测试在结构上不同的方式。下面是基本原则。
每个租户一个基线
在经典视觉测试中，每个页面、每个断点对应一个基线（参考截图）。在多租户中，您有每个页面、每个断点、每个租户配置一个基线。
这看起来是基线爆炸，但实践中租户可以归入"视觉画像"。一个画像把那些共享相同重要定制维度的租户分组。如果50个租户中有30个使用默认配置，他们共享同一个画像和同一个基线。
思路是识别视觉上重要的变体轴（主色、logo 类型、字体、启用的模块），并为每种独特组合创建一个画像。一个多租户 SaaS 应用通常有5到15种不同的视觉画像，无论租户数量。
按画像的测试矩阵
为每个视觉画像，您定义一个覆盖关键页面在重要断点的测试矩阵。这一矩阵是您按画像的视觉质量合同。
矩阵不需要为所有画像覆盖所有页面。某些页面对定制不敏感（如法律声明页）。其他页面则非常敏感（登录页、控制面板、带品牌的报告）。矩阵应根据每个页面对定制的敏感度加权。
并行执行
由于有多个视觉画像和每画像多个页面，视觉测试的串行执行不可行。多租户视觉测试必须为并行执行而设计：每个画像独立测试，运行在配置了对应租户参数的环境上。
这正是无代码视觉测试工具变得无价的地方。手动为每个租户画像配置测试脚本需要可观的开发投入。一款无代码工具让您能可视化地配置画像、定义按画像的测试矩阵，并启动并行执行——无需写代码。
多租户特有的视觉缺陷
某些视觉缺陷是多租户架构特有的。它们在单租户应用中不存在，也不被经典测试策略覆盖。
"渗漏的主题"
某个租户通过 CSS 变量或主题系统应用其定制。但一次代码更新引入了一个不使用主题变量的组件——它使用硬编码的颜色。在默认租户上，硬编码的颜色与主题变量重合，所以缺陷不可见。在带自定义色板的租户上，组件以默认颜色显示在使用客户颜色的界面中。不一致是显眼的。
破坏布局的 logo
一个新 header 组件被开发并以默认 logo（比如160×40像素的横向 logo）测试。在生产中，租户 A 有100×100像素的方形 logo。租户 B 有300×60像素的横向 logo。租户 C 有80×120像素的纵向 logo。
那个用默认 logo 完美工作的 header 在客户 logo 下表现不可预测。导航栏间距变化。手机上汉堡菜单错位。header 高度变化，影响主内容定位。
对比度不足的主色
您的应用使用租户的主色用于按钮、链接、活跃导航元素和徽章。用您的默认颜色（一种对比良好的蓝），一切可读。但租户 X 选择了一种浅黄色作为主色。浅黄色背景上白文字按钮不可读。白色背景上的黄色链接几乎不可见。
这个缺陷既是无障碍问题也是视觉质量问题。而它直接与多租户定制相关。
让一切重新调整尺寸的字体
租户 Y 使用一种字符平均比默认字体宽15%的自定义字体。每段文字都占更多空间。按钮变宽。菜单需要更多位置。控制面板卡片不再能放进三列——它们掉到两列，破坏整个控制面板布局。
这一缺陷阴险，因为每个组件单独看都正确——文字可读、按钮能用。是页面整体在视觉上被退化了。
让一切错位的缺失模块
租户 Z 没有"analytics"模块。在 sidebar 导航中，"Analytics"项缺席。看起来无害，但如果导航使用基于计算位置的固定布局，缺失元素会让所有后续元素错位。"Settings"图标最终落到了通常被"Analytics"占据的位置。习惯了 Settings 位置的用户点错了项目。
这不是功能缺陷（Settings 链接还能用）。这是仅对没有 analytics 模块的租户存在的用户体验缺陷。
务实的多租户视觉测试策略
面对视觉面的成倍增加，诱惑是把一切都测。这不现实。下面是一种务实的四级策略。
第1级：在极端画像上测试关键页面
识别您视觉上最敏感的5个页面（登录页、控制面板、设置页、可打印报告、带品牌的公开页）。识别您最"极端"的视觉画像——那些与默认配置偏离最多的。在这些极端画像上测试这5个页面。
这是您最低可行覆盖。如果这些组合通过，中间组合就有较大机会通过。
第2级：在默认画像上测试所有页面
在默认画像上测试您所有的页面。这是您对通用回归（与定制无关的）的安全网。
第3级：在所有画像上测试敏感页面
在所有视觉画像上测试您敏感的页面（在第1级中识别的）。这覆盖定制与关键页面之间的相互作用。
第4级：穷尽测试
在所有画像上测试所有页面。这是理想，借助自动化工具与并行执行能够实现。但请从第1到第3级开始，并在流程稳定后再加上第4级。
Delta-QA 与多租户：在该简单的地方简单
Delta-QA 是为那些需要在没有技术复杂度的情况下做视觉测试的团队而设计的。在多租户场景中，这意味着能够按租户配置视觉画像、按画像定义测试矩阵，并获取按租户的报告——全都无需写代码。
工作流很直接。您配置您的视觉画像（重要的定制组合）。您按画像定义要测试的页面。Delta-QA 为每种组合捕获截图、与按租户的基线比较、并产出一份按客户识别回归的清晰报告。
结果：在每次部署之前，您就知道这次更新是否对您的一个或多个客户造成了破坏。不是之后。不是当客户来电时。是之前。
多租户不是不测试的借口
我们最常听到的论点是："我们租户太多，没法把所有都视觉测试。"这是一个能力上的论点，不是相关性上的论点。没人否认多租户视觉测试是有用的。质疑在于它的可行性。
而这正是为什么自动化必不可少。您不可能手动在3种断点下对20个页面跨10种租户画像做视觉测试。那是600次视觉比较。没人会去做。
但一个自动化工具能在几分钟内完成。无疲劳、无主观、无遗漏。
多租户放大了要测试的视觉面。自动化放大了您测试它们的能力。一个补偿另一个。前提是您选择自动化。
常见问题
如何在不耗尽 QA 预算的情况下做多租户 SaaS 的视觉测试？
关键是视觉画像策略。把您的租户按相似视觉配置分组而不是逐个测试每个租户。从极端画像和关键页面开始，再逐步扩展。一款自动化视觉测试工具让这一流程在数十个画像下也可行。
每个租户都需要一份视觉测试基线吗？
概念上是的。实践中，您按视觉画像而不是按单个租户创建基线。共享相同视觉配置的租户共享同一基线。这极大减少了要维护的基线数，同时覆盖渲染的多样性。
多租户特有的视觉缺陷有哪些类型？
最特有的缺陷是："渗漏的主题"（一个忽略租户主题变量的组件）、破坏布局的 logo（出乎意料的比例）、对比度不足的颜色（与背景不兼容的客户主色）、让布局重新调整尺寸的自定义字体，以及让导航错位的缺失模块。
多租户视觉测试能集成进 CI/CD 流水线吗？
能，并且推荐这么做。方式是在您流水线中并行运行每个租户画像的视觉测试，在每次部署之前。如果在一个或多个画像上检测到回归，视觉测试会阻止部署。这确保每次发布对您所有客户都经过视觉验证。
如何处理某些租户的极端视觉定制？
某些租户有超出简单品牌的定制（自定义 CSS、特定组件、修改的布局）。为这些租户，创建一个带特定基线的专门视觉画像。额外成本（多一个画像）相比向战略客户交付破碎渲染的风险是适度的。
视觉测试能检测与租户颜色相关的对比度问题吗？
通过比较的视觉测试会检测渲染变化，包括对比度变化。然而，仅靠一款视觉测试工具并不计算 WCAG 对比度比率。推荐的方式是把视觉测试（检测回归）与无障碍审计（验证 WCAG 合规）针对每个租户画像结合使用。
延伸阅读
您管理一个多租户 SaaS 并希望为每个客户保证视觉质量？