以检查清单组织的标准来测试资产的测试
在过去的几年中，测试设计资产在规划中往往被忽视，如果有测试，也只是随便处理。现在，一些团队对Figma组件进行严格的测试。许多团队在发布任何更新之前都要求进行Figma组件审查。
形式各异。然而，投资正在增长，严谨程度也在不断提高。一个团队改变了一个 tive testing techniques. 3. Document any issues found during the review. 4. Validate the fixes made by the builder. 5. Repeat steps 2-4 until all issues are resolved.
These steps can be repeated for each component being tested, allowing testers to systematically review and validate the functionality of each part of the system.
Organize criteria by category #
To further streamline the testing process, it is helpful to organize the criteria to be validated into categories. This allows testers to focus on specific aspects of the system and ensures thorough coverage. Some common categories to consider include:
- Styles: Check that the component adheres to the defined styles and branding guidelines.
- Properties: Verify that all properties and attributes are set correctly.
- Layout: Ensure that the component is displayed correctly and aligned properly.
- Content: Validate that the content is accurate, complete, and error-free.
By organizing the criteria in this way, testers can easily navigate through the checklist and ensure that all aspects of the system are thoroughly reviewed.
Conclusion #
Equipping testers with a simple workflow and checklists can greatly enhance the efficiency and effectiveness of the testing process. By providing a structure and organizing criteria by category, testers can focus on specific aspects of the system and ensure thorough coverage. As Figma capabilities continue to expand, it is important to invest in assuring that they are applied effectively without error. 考虑将指令（准备→审核→重新测试和解决→完成）和标准结合在一个易于参考的位置。例如，您可以将两者都嵌入到放置在页面上以跟踪工作、沟通状态并在循环完成时处理的 Figma 组件中。
用于测试人员使用的“组件审核”Figma 组件
根据您的清单标准的数量，它可能会变得非常长。因此，讨论如何保持其紧凑和有效。清单应该使测试人员能够在进行过程中将项目标记为通过、失败或（经过整理）不适用，例如，通过为每个标准项目使用一个状态属性的子组件。
一个 Figma 组件，使测试人员能够将标准的状态更改为失败、通过或不适用
全目录审核：“完成程度矩阵 在整个目录中进行质量改进时，会涉及到电子表格。也许甚至还有一个功能强大的Airtable。在过去，EightShapes曾将在这样的结构中跟踪更大的工作量称为“完成矩阵”。行可以对应于特性（如UI组件列表），通常按照顺序进行组织。列对应于要验证的标准。 #
UI组件质量目录审计中每个UI组件相关的标准矩阵
按类别验证的标准 #
本文讨论的是在测试组件时要足够细致。要测试的属性范围涵盖元数据、解剖学、颜色、文本、属性、内容、间距、布局和模块化方法等类别。
因此，设计系统团队将根据他们最需要和最重视的内容来确定、分类和定制标准。当您为自己量身定制列表时，可以根据自己的需要进行调整。 ## 元数据
作为产品设计师，我可以插入一个准确命名和描述准确的组件。
一个揭示组件名称和其他元数据的组件实例
✔︎ 名称： 是否与代码和网页文档的名称一致？
✔︎ 命名空间： 是否适当地命名空间，例如在系统缩写前加上 ESDS (EightShapes Design System)？
✔︎ 描述： 是否有足够的描述，例如使用来自网页文档的组件介绍 (opens new window)？ ✔︎ 状态：状态是否更新，例如版本（与代码匹配的1.5.0）和稳定性（稳定、实验性、测试版或...）？
解剖学 #
作为产品设计师，我希望能够与一个组织良好、构建清晰的组件解剖学进行交互，以便根据需要查找和调整元素。
使用图层面板检查组件解剖学
✔︎ 图层名称：图层名称是否与指定的组件解剖学一致，例如使用标题和详情而不仅仅是文本？
✔︎ 图层格式：图层名称是否以句子大小写格式进行格式化，而不是“框架###”？
✔︎ 图层简称：是否应用了命名约定，例如对只应用自动布局的图层使用空格（]-[）或使用表情符号作为可编辑指示符（✏️）？
✔︎ 嵌套组件名称：是否使用描述性名称命名嵌套组件（例如装饰图标和关闭图标），而不是使用嵌套组件的默认名称（图标）？
✔︎ 默认可见性： 颜色样式
作为产品设计师，组件通过颜色样式和与设计令牌一致的组件特定属性来应用颜色。
检查每个变体属性组合、子组件和基本组件的每个图层。为了更广泛的可追溯性，还可以利用Figma的选择颜色 (opens new window)来追踪多个对象上单一样式的一致应用。
使用设计面板检查颜色，包括选择颜色。
✔︎ 颜色准确性： 相对于设计意图，背景、文本和描边颜色是否准确应用，并且如果有的话，是否符合规范？这包括状态、主题和其他颜色的可变性的准确性。
✔︎ 颜色样式： 每个填充、描边、纯色和渐变色是否应用了颜色样式，而不是硬编码的值，如果可能的话。 设计规范：
✔︎ 样式特异性： 每种颜色样式是否应用最具语义的方式（文本 > 链接 > 暗色背景），而不是通用的方式（调色板 > 蓝色 > 50）？
✔︎ 硬编码颜色： 是否讨论并同意使用硬编码值？
✔︎ “隐藏”颜色： 是否准确应用“隐藏”的硬编码颜色，例如应用于阴影效果和其他非样式化的位置？
文本样式 #
作为产品设计师，组件通过文本样式和特定组件的覆盖来应用系统的排版，这样我就不必为文本样式设置样式。
使用设计面板检查每个元素的文本样式
检查每个文本图层以确认以下内容：
✔︎ 文本样式： 每个文本图层是否关联了定义好的文本样式？
✔︎ 非文本样式属性： 是否准确应用或省略了非样式属性，例如列表样式、垂直对齐和水平对齐？
属性 #
作为产品设计师，我可以以与设计规范一致的方式调整属性和值。 随着产品设计师，我可以插入一个具有适当默认值的组件。
使用设计面板检查属性
检查属性面板以及放置的实例以交换属性选项以确认：
✔︎ 属性名称： 属性是否被正确命名和格式化？
✔︎ 属性顺序： 属性是否按照合理的顺序排序，例如按优先级、字母顺序、相关的组合或文档顺序排序？
✔︎ 选项名称： 属性选项是否被正确命名和格式化？
✔︎ 选项顺序： 选项是否被正确排序，例如按比例顺序（小、中、大）或按字母顺序排序？
✔︎ 默认选项： 当我插入一个实例时，默认值是否正确？默认选项是否在选项顺序中被正确放置？
内容（包括文本和图片 😉 #
随着产品设计师，我可以将文本、图片、图标和其他内容流入组件，并且组件内部的布局将适应 错误的内容：它是否呈现错误的内容，例如错误的图标？
✔ 适中的内容： 是否准确呈现正常大小的内容，例如合理长度的标签或典型图像？
✔ 内容过多： 当内容过大时，如换行标签、碰撞或需要裁剪的图像，布局是否会中断？
✔ 内容过少： 是否准确呈现相当小的内容，例如几个字符的标签或容器过小的图像？
✔ 缺少内容： 在缺少内容的情况下，是否会中断，例如省略的文本或缺少的图像？
间距
作为产品设计师，我可以相信元素之间的间距是精确的。
通过检查自动布局、调整大小和固定属性，检查填充、对齐和项目之间的空间：
✔️ Autolayout: 在自动布局中，检查元素之间的间距是否精确。
✔️ Resizing: 在调整大小时，检查元素之间的间距是否保持一致。
✔️ Pinning: 在固定属性中，检查元素之间的间距是否正确。 在每个元素，尤其是嵌套元素的容器周围是否有填充？
✔︎ 对齐：在元素扩展和组件调整大小时，每个元素和相邻元素是否正确对齐？
✔︎ 项目之间的空间：每个元素和相邻元素的缩进和分隔是否与设计规范一致？
布局 #
作为产品设计师，我可以将组件与其他对象一起放在更广泛的布局中，并且它会正确地对元素进行空间分隔、调整大小和重新排列。
对于在各种尺寸和属性下的所有可能的元素组合和配对，验证以下内容：
✔︎ 元素布局：每个元素在内容或组件大小更改时（垂直和水平方向；固定大小、自适应内容或填充容器）是否正确调整大小，通过自动布局、约束和调整大小？
✔︎ 文本布局：每个文本元素是否设置为自适应大小（自动宽度、自动高度或固定大小）？ 组成
作为一个产品设计师，我可以成功地替换子组件以包含其他设计系统组件和/或自定义内容作为插槽。
对于应用于基础、子组件和嵌套组件的模块化技术范围，检查：
**✔︎ 子组件属性：**在主组件中调整子组件属性（例如“表单标签”的“工具提示”属性）是否正确地重新流动子组件和主组件的内容？
**✔︎ 子组件内容：**在主组件中调整子组件内容（例如“表单标签”）是否正确地重新流动子组件和主组件的内容和元素？
**✔︎ 插槽调整大小：**将不同或自定义组件替换到组件插槽中是否能够正确调整大小（例如垂直或水平的“Hug Contents”或“Fill Container”）？
**✔︎ 插槽内容重新流动：**将不同的组件替换到组件插槽中是否会正确地重新流动内容？ 行为
作为一个产品设计师，我可以利用原型状态、动画和其他行为来为组件进行范围限定。
诚然，EightShapes只在UI组件库中尝试过Figma原型行为。我可以想象出许多你可以验证的标准，但是广度很大，也具体情况而定。
因此，我期望一个构建者和测试者能够讨论一系列功能测试，以确保组件的行为符合预期。这些标准与样式、布局和组合的问题一样重要。