以检查清单组织的标准来测试资产的测试

(opens new window)

(opens new window)

在过去的几年中，测试设计资产在规划中往往被忽视，如果有测试，也只是随便处理。现在，一些团队对Figma组件进行严格的测试。许多团队在发布任何更新之前都要求进行Figma组件审查。

形式各异。然而，对组件质量的投入正在持续增长，严谨程度也在不断提高。一个标准的组件审查流程通常包括：

1. 测试准备：明确组件的预期行为、变体覆盖与约束规则；
2. 执行审查：结合实际场景与极端数据测试组件健壮性；
3. 记录问题：记录在审查过程中发现的所有缺陷与不规范之处；
4. 验证修复：由创建者修复后，复核验收修改结果；
5. 闭环迭代：重复上述审查与修复步骤，直至所有问题圆满解决。

对每个被测组件重复上述步骤，可以系统化地验证设计系统中每个部件的功能完备性。

按类别组织审查标准

为了进一步规范测试流程，将待验证的指标分类归纳会大有裨益。这有助于测试人员聚焦具体维度，确保无死角覆盖：

• 样式（Styles）：检查组件是否严格遵循既定的色彩、阴影与品牌规范。
• 属性（Properties）：验证所有变体选项（Variants）、布尔开关与文本属性是否配置正确且命名规范。
• 布局（Layout）：确保 Auto Layout 自适应缩放正常，内边距、外边距及对齐方式准确无误。
• 内容（Content）：验证预设文案与占位内容是否准确、完整，无溢出或文字截断风险。

通过这种结构化的分类，测试人员可以清晰快速地逐项核对，确保系统的各个层面都经过严格审查。

结语

为测试人员配备清晰的工作流与检查清单，能够显著提升设计系统资产测试的效率与可靠性。随着 Figma 功能的不断扩充（如变量、模式和高级原型），投入精力确保这些功能规范、无误地落地至关重要。考虑将指令（准备→审核→重新测试和解决→完成）和标准结合在一个易于参考的位置。例如，您可以将两者都嵌入到放置在页面上以跟踪工作、沟通状态并在循环完成时处理的 Figma 组件中。

用于测试人员使用的“组件审核”Figma 组件

根据您的清单标准的数量，它可能会变得非常长。因此，讨论如何保持其紧凑和有效。清单应该使测试人员能够在进行过程中将项目标记为通过、失败或（经过整理）不适用，例如，通过为每个标准项目使用一个状态属性的子组件。

一个 Figma 组件，使测试人员能够将标准的状态更改为失败、通过或不适用

全目录审核：“完成程度矩阵 在整个目录中进行质量改进时，会涉及到电子表格。也许甚至还有一个功能强大的Airtable。在过去，EightShapes曾将在这样的结构中跟踪更大的工作量称为“完成矩阵”。行可以对应于特性（如UI组件列表），通常按照顺序进行组织。列对应于要验证的标准。

UI组件质量目录审计中每个UI组件相关的标准矩阵

按类别验证的标准

本文讨论的是在测试组件时要足够细致。要测试的属性范围涵盖元数据、解剖学、颜色、文本、属性、内容、间距、布局和模块化方法等类别。

因此，设计系统团队将根据他们最需要和最重视的内容来确定、分类和定制标准。当您为自己量身定制列表时，可以根据自己的需要进行调整。 ## 元数据

作为产品设计师，我可以插入一个准确命名和描述准确的组件。

一个揭示组件名称和其他元数据的组件实例

✔︎ 名称： 是否与代码和网页文档的名称一致？

✔︎ 命名空间： 是否适当地命名空间，例如在系统缩写前加上 ESDS (EightShapes Design System)？

✔︎ 描述： 是否有足够的描述，例如使用来自网页文档的组件介绍 (opens new window)？ ✔︎ 状态：状态是否更新，例如版本（与代码匹配的1.5.0）和稳定性（稳定、实验性、测试版或...）？

解剖学

作为产品设计师，我希望能够与一个组织良好、构建清晰的组件解剖学进行交互，以便根据需要查找和调整元素。

使用图层面板检查组件解剖学

✔︎ 图层名称：图层名称是否与指定的组件解剖学一致，例如使用标题和详情而不仅仅是文本？

✔︎ 图层格式：图层名称是否以句子大小写格式进行格式化，而不是“框架###”？

✔︎ 图层简称：是否应用了命名约定，例如对只应用自动布局的图层使用空格（]-[）或使用表情符号作为可编辑指示符（✏️）？

✔︎ 嵌套组件名称：是否使用描述性名称命名嵌套组件（例如装饰图标和关闭图标），而不是使用嵌套组件的默认名称（图标）？

✔︎ 默认可见性： 颜色样式

作为产品设计师，组件通过颜色样式和与设计令牌一致的组件特定属性来应用颜色。

检查每个变体属性组合、子组件和基本组件的每个图层。为了更广泛的可追溯性，还可以利用Figma的选择颜色来追踪多个对象上单一样式的一致应用。

使用设计面板检查颜色，包括选择颜色。

✔︎ 颜色准确性： 相对于设计意图，背景、文本和描边颜色是否准确应用，并且如果有的话，是否符合规范？这包括状态、主题和其他颜色的可变性的准确性。

✔︎ 颜色样式： 每个填充、描边、纯色和渐变色是否应用了颜色样式，而不是硬编码的值，如果可能的话。 设计规范：

✔︎ 样式特异性： 每种颜色样式是否应用最具语义的方式（文本 > 链接 > 暗色背景），而不是通用的方式（调色板 > 蓝色 > 50）？

✔︎ 硬编码颜色： 是否讨论并同意使用硬编码值？

✔︎ “隐藏”颜色： 是否准确应用“隐藏”的硬编码颜色，例如应用于阴影效果和其他非样式化的位置？

文本样式

作为产品设计师，组件通过文本样式和特定组件的覆盖来应用系统的排版，这样我就不必为文本样式设置样式。

使用设计面板检查每个元素的文本样式

检查每个文本图层以确认以下内容：

✔︎ 文本样式： 每个文本图层是否关联了定义好的文本样式？

✔︎ 非文本样式属性： 是否准确应用或省略了非样式属性，例如列表样式、垂直对齐和水平对齐？

属性

作为产品设计师，我可以以与设计规范一致的方式调整属性和值。 随着产品设计师，我可以插入一个具有适当默认值的组件。

使用设计面板检查属性

检查属性面板以及放置的实例以交换属性选项以确认：

✔︎ 属性名称： 属性是否被正确命名和格式化？

✔︎ 属性顺序： 属性是否按照合理的顺序排序，例如按优先级、字母顺序、相关的组合或文档顺序排序？

✔︎ 选项名称： 属性选项是否被正确命名和格式化？

✔︎ 选项顺序： 选项是否被正确排序，例如按比例顺序（小、中、大）或按字母顺序排序？

✔︎ 默认选项： 当我插入一个实例时，默认值是否正确？默认选项是否在选项顺序中被正确放置？

内容（包括文本和图片 😉

随着产品设计师，我可以将文本、图片、图标和其他内容流入组件，并且组件内部的布局将适应 错误的内容：它是否呈现错误的内容，例如错误的图标？

✔ 适中的内容： 是否准确呈现正常大小的内容，例如合理长度的标签或典型图像？

✔ 内容过多： 当内容过大时，如换行标签、碰撞或需要裁剪的图像，布局是否会中断？

✔ 内容过少： 是否准确呈现相当小的内容，例如几个字符的标签或容器过小的图像？

✔ 缺少内容： 在缺少内容的情况下，是否会中断，例如省略的文本或缺少的图像？

间距

作为产品设计师，我可以相信元素之间的间距是精确的。

通过检查自动布局、调整大小和固定属性，检查填充、对齐和项目之间的空间：

✔️ Autolayout: 在自动布局中，检查元素之间的间距是否精确。

✔️ Resizing: 在调整大小时，检查元素之间的间距是否保持一致。

✔️ Pinning: 在固定属性中，检查元素之间的间距是否正确。 在每个元素，尤其是嵌套元素的容器周围是否有填充？

✔︎ 对齐：在元素扩展和组件调整大小时，每个元素和相邻元素是否正确对齐？

✔︎ 项目之间的空间：每个元素和相邻元素的缩进和分隔是否与设计规范一致？

布局

作为产品设计师，我可以将组件与其他对象一起放在更广泛的布局中，并且它会正确地对元素进行空间分隔、调整大小和重新排列。

对于在各种尺寸和属性下的所有可能的元素组合和配对，验证以下内容：

✔︎ 元素布局：每个元素在内容或组件大小更改时（垂直和水平方向；固定大小、自适应内容或填充容器）是否正确调整大小，通过自动布局、约束和调整大小？

✔︎ 文本布局：每个文本元素是否设置为自适应大小（自动宽度、自动高度或固定大小）？ 组成

作为一个产品设计师，我可以成功地替换子组件以包含其他设计系统组件和/或自定义内容作为插槽。

对于应用于基础、子组件和嵌套组件的模块化技术范围，检查：

**✔︎ 子组件属性：**在主组件中调整子组件属性（例如“表单标签”的“工具提示”属性）是否正确地重新流动子组件和主组件的内容？

**✔︎ 子组件内容：**在主组件中调整子组件内容（例如“表单标签”）是否正确地重新流动子组件和主组件的内容和元素？

**✔︎ 插槽调整大小：**将不同或自定义组件替换到组件插槽中是否能够正确调整大小（例如垂直或水平的“Hug Contents”或“Fill Container”）？

**✔︎ 插槽内容重新流动：**将不同的组件替换到组件插槽中是否会正确地重新流动内容？ 行为

作为一个产品设计师，我可以利用原型状态、动画和其他行为来为组件进行范围限定。

诚然，EightShapes只在UI组件库中尝试过Figma原型行为。我可以想象出许多你可以验证的标准，但是广度很大，也具体情况而定。

因此，我期望一个构建者和测试者能够讨论一系列功能测试，以确保组件的行为符合预期。这些标准与样式、布局和组合的问题一样重要。