4、验收工具与准备：常用设计稿查看工具（Sketch、Figma、蓝湖等）、切图标注、设备与模拟器选择、验收环境搭建
视觉验收不是打开设计稿“看一眼”就结束的简单动作，而是一个需要精确比对、多端验证、环境可控的工程化过程。如果工具选择不当、标注信息缺失、设备环境混乱，验收结论就会失真——明明在电脑上看起来完美的界面，到了真机上却出现字体发虚、颜色偏色、间距错位等问题。本章将系统梳理验收前的工具链与准备流程，帮助你在动手验收之前，先把“尺子”和“试验台”搭好。
4.1 设计稿查看工具的选择与使用
核心原理：工具决定验收基准的准确性
设计稿查看工具是视觉验收的“第一现场”。它的核心作用不是“看图”，而是提供可测量的设计基准——精确到像素的间距、字号、色值、圆角、阴影参数。不同工具在数据精度、协作方式、切图导出能力上差异显著，选错工具会导致验收时拿不到关键数据，只能靠肉眼“估”，这违背了视觉验收的初衷。
| 工具 | 适用场景 | 标注读取 | 切图导出 | 协作能力 | 注意事项 |
|---|---|---|---|---|---|
| Sketch | macOS 团队、UI 源文件设计 | 需安装插件（如 Measure） | 支持切片，需手动命名 | 需配合云同步工具 | 仅限 Mac，Windows 无法直接打开 |
| Figma | 跨平台团队、实时协作 | 内置标注，点击即看 | 支持多倍率导出，自动命名 | 原生在线协作，评论@人 | 需注意版本历史与分支管理 |
| 蓝湖 | 设计稿交付、开发与测试查看 | 自动标注，无需插件 | 一键下载多倍率切图 | 支持设计稿版本对比 | 需上传设计稿，注意文件同步 |
| Zeplin | 设计交付、开发标注 | 自动标注，支持代码片段 | 按平台导出 | 支持项目与成员管理 | 免费版限制项目数量 |
判断方法与操作流程
在实际验收中，建议按以下流程操作：
- 确认设计稿版本：与设计师确认当前验收的版本号，避免拿到旧版设计稿。
- 选择主查看工具：优先使用 Figma 或蓝湖，因为它们支持在线标注且无需安装插件。若团队使用 Sketch，则需提前安装 Measure 插件并确认标注可读。
- 开启标注模式：在 Figma 中选中元素即可查看右侧属性面板；在蓝湖中点击元素即可弹出标注浮层。
- 核对关键属性：逐一检查尺寸、位置、颜色、字号、字重、行高、圆角、阴影、不透明度等参数。
- 截图存档：对每个界面截图，并标注“设计稿版本 + 截图时间”，作为后续比对依据。
案例拆解：Figma 标注读取实战
某电商 App 改版后，验收首页 Banner 区域时，开发实现的圆角为 12px，而设计稿标注为 16px。验收人员最初通过肉眼观察并未发现异常，但在 Figma 中点击 Banner 组件后，右侧属性面板清晰显示“Corner Radius: 16”。随后验收人员截图并附上标注，提交给开发修复。整个过程不到 2 分钟，避免了后续 UI 走查阶段的返工。
常见误区与总结
- 误区一：只看设计稿整体效果，不点开属性面板——导致间距、字号等细微偏差被忽略。
- 误区二：多个工具混用——例如用 Figma 看标注，又用蓝湖下载切图，容易因版本不同步产生偏差。
- 误区三：忽略设计稿的“交互状态”——很多设计稿包含 hover、press、disabled 等状态，验收时需切换状态查看。
4.2 切图标注与资源准备
核心原理：切图是视觉还原的“原材料”
切图标注不仅是给开发用的，验收人员同样需要理解切图规范，才能判断界面中的图标、图片是否被正确使用。常见的切图倍率包括 @1x、@2x、@3x，分别对应不同像素密度的设备。如果切图倍率不匹配，会导致图标模糊或体积过大。
切图标注的关键要素
- 尺寸标注：每个切图应标注逻辑尺寸和物理像素尺寸。
- 倍率要求：iOS 通常需要 @2x 和 @3x，Android 需要 mdpi/hdpi/xhdpi/xxhdpi 等多套。
- 命名规范：例如
icon_cart_normal.png、icon_cart_pressed.png，便于开发引用。 - 安全区域：图标周围需留出安全边距，避免被系统裁切。
操作流程：从设计稿到验收资源
- 在 Figma 或蓝湖中打开设计稿，进入“切图”或“导出”面板。
- 选择需要导出的元素，设置倍率（如 @2x、@3x）。
- 导出后检查文件命名是否规范，尺寸是否符合预期。
- 将切图放入验收资源文件夹，与设计稿版本号对应。
常见误区
- 误区一：只关注大图，忽略小图标——小图标在低倍率下更容易模糊。
- 误区二：切图命名随意——导致开发引用错误，验收时难以追溯。
- 误区三：不检查透明通道——部分切图导出后透明区域异常，影响界面效果。
4.3 设备与模拟器选择策略
核心原理：真机优先，模拟器兜底
视觉验收的最终目标是确保用户在真实设备上的体验。模拟器虽然方便，但在色彩还原、字体渲染、性能表现上与真机存在差异。因此，验收策略应为：核心界面用真机验收，边缘场景用模拟器覆盖。
| 维度 | 真机 | 模拟器 |
|---|---|---|
| 色彩还原 | 准确，反映真实屏幕 | 可能偏色，受电脑屏幕影响 |
| 字体渲染 | 系统字体渲染引擎 | 与真机有差异 |
| 性能 | 真实帧率与卡顿 | 依赖电脑性能，不准确 |
| 覆盖成本 | 需购买多台设备 | 免费，可快速切换型号 |
设备选择矩阵
建议建立“最小覆盖矩阵”：
- iOS：iPhone 15 Pro（@3x）、iPhone SE（@2x 小屏）、iPhone Plus 系列（大屏）。
- Android：一款主流旗舰（如小米 14）、一款中低端机（如 Redmi Note 系列）、一款大屏折叠屏（可选）。
案例拆解：模拟器漏检的字体问题
某团队在模拟器上验收通过后发布，用户反馈“首页标题字体模糊”。排查发现，模拟器使用电脑字体渲染，而真机使用系统字体（如苹方、思源黑体），两者在笔画粗细和抗锯齿算法上存在差异。后续改为“真机验收 + 模拟器补充”策略后，此类问题大幅减少。
4.4 验收环境搭建与标准化
核心原理：环境一致性决定验收可复现性
验收环境包括硬件、软件、网络、亮度等多个维度。如果环境不统一，验收结论就无法复现。例如，同一台手机在亮度 50% 和 100% 下看到的颜色完全不同；在弱网环境下，图片加载策略也会影响视觉呈现。
验收环境搭建清单
| 类别 | 项目 | 标准要求 |
|---|---|---|
| 硬件 | 测试机数量 | 至少 2 台 iOS + 2 台 Android |
| 硬件 | 屏幕亮度 | 固定为 50% 或 100%，并记录 |
| 软件 | 系统版本 | 锁定主要版本，避免跨大版本验收 |
| 软件 | App 版本 | 使用同一构建号，记录 Git 提交号 |
| 网络 | 网络环境 | Wi-Fi + 4G/5G 各测一轮 |
| 辅助 | 截图工具 | 使用系统截图 + 标注工具（如 iMarkup） |
操作流程：搭建标准化验收环境
- 设备准备：将测试机恢复出厂设置，关闭自动亮度、原彩显示、夜间模式。
- 网络准备：连接稳定的 Wi-Fi，并准备一张 4G/5G 流量卡用于弱网测试。
- 版本锁定：在测试机上安装指定构建号的 App，并记录安装时间。
- 模板准备：创建验收记录表，包含“界面名称、设计稿版本、截图、问题描述、严重程度、负责人”等字段。
- 预检：打开 App 首页，确认无白屏、无崩溃，再进行正式验收。
案例拆解：环境不一致导致的验收返工
某团队在验收时，测试机 A 开启了“原彩显示”，测试机 B 未开启。结果同一张商品图在 A 上偏黄、在 B 上正常，验收人员误判为“开发调色错误”，要求开发修改。开发排查后发现是环境问题，重新统一环境后问题消失。此次返工耗时 2 小时，教训深刻。
常见误区与总结复盘
- 误区一：忽略屏幕亮度设置——亮度不同，色彩感知差异巨大。
- 误区二：测试机系统版本混乱——不同系统版本的渲染引擎可能有差异。
- 误区三：不记录验收环境——导致问题复现时无法还原现场。
验收工具与准备是视觉验收的“地基”。设计稿工具提供基准，切图标注提供资源，设备选择提供载体，环境搭建提供一致性。四者缺一不可。只有把准备工作做扎实，后续的逐项验收才能高效、准确、可追溯。建议团队将本章内容固化为《验收准备检查单》，每次验收前逐项打钩确认，避免凭经验跳过关键步骤。