TestSprite — 本地化开发审查及反馈

发布: 1小时前 (2026年4月22日 GMT+8 11:05)

5 分钟阅读

Source: Dev.to

项目背景

一个面向国内与海外用户的管理后台（React + Node.js），包含订单金额、时间范围筛选、多语言切换、CSV 导出等功能。以往做国际化测试，往往靠人工切换语言、改系统时区、输入法乱敲一遍，效率低且容易漏。TestSprite 的定位更像“可执行的 Dev Review”：在真实项目上跑一轮自动化测试后，能给到偏开发落地的反馈，尤其适合需要同时关注功能回归与本地化细节的团队。

接入步骤

在测试环境准备一套 staging 数据（含多币种订单、不同语言用户）。
配置测试入口 URL、登录方式（测试账号）。
指定要覆盖的关键路径：登录 → 订单列表 → 订单详情 → 导出 → 语言切换 → 个人设置。
在测试中显式设置 locale 和 timezoneId，并对 UI 文案和数值格式做断言（建议所有团队都做的最小集）。

代码示例

import { test, expect } from '@playwright/test';

test.use({
  locale: 'zh-CN',
  timezoneId: 'Asia/Shanghai',
});

test('订单金额与日期在 zh-CN 下显示正确', async ({ page }) => {
  await page.goto(process.env.STAGING_URL!);
  await page.getByLabel('邮箱').fill('test@demo.com');
  await page.getByLabel('密码').fill('123456');
  await page.getByRole('button', { name: '登录' }).click();

  await page.getByRole('link', { name: '订单' }).click();

  // 金额：zh-CN 通常期望 1,234.56 或 ￥1,234.56（视产品定义）
  const priceText = await page.locator('[data-testid="order-price"]').first().innerText();
  expect(priceText).toMatch(/(¥|￥)?\s?\d{1,3}(,\d{3})*(\.\d{2})?/);

  // 日期：检查是否包含本地化格式或明确的 yyyy-MM-dd
  const dateText = await page.locator('[data-testid="order-createdAt"]').first().innerText();
  expect(dateText).toMatch(/\d{4}[-/]\d{1,2}[-/]\d{1,2}/);
});

运行结果截图

替换为实际截图后发布

TestSprite 测试运行截图

建议截图内容包含：项目 URL（可打码）、测试用例列表、执行结果（pass/fail）、以及至少一条本地化相关提示。

发现的问题与修复建议

时间显示不一致

问题：列表页使用 new Date(iso).toLocaleString()（浏览器时区），详情页使用后端渲染的 UTC 字符串，导致在 Asia/Shanghai 时出现 +8 小时偏移，跨天时尤为明显。
修复建议：
- 前端统一使用 UTC + 时区库格式化，例如 date-fns-tz 或 luxon。
- 或后端统一返回 ISO 8601，前端统一格式化展示。
- UI 上明确标注时区（如 “GMT+8”）在跨国场景中非常关键。

金额格式不稳定

问题：在 en-US 环境下偶发显示为 1234,5（小数位不稳定），原因是手写格式化 Number(value).toFixed(2).replace('.', ',')。
修复建议：改用 Intl.NumberFormat：

export function formatCurrency(
  value: number,
  locale: string,
  currency: string
) {
  return new Intl.NumberFormat(locale, {
    style: 'currency',
    currency,
    maximumFractionDigits: 2,
  }).format(value);
}

// zh-CN + CNY => ￥1,234.56
// de-DE + EUR => 1.234,56 €

非 ASCII 输入导致后端错误

问题：UI 层面可以输入中文/阿拉伯文，但请求参数在后端被错误地做了 encode/decode，导致搜索结果为空。
修复建议：确保后端对所有字符使用统一的 UTF-8 编码/解码流程。

翻译缺口

问题：语言切换到 ja-JP 后，仍有按钮（如 “Export CSV”）未翻译。
修复建议：利用 TestSprite 的“翻译缺口扫描”功能，集中列出未走 i18n 的节点，逐一修复。

适用场景

已有 staging 环境，想用自动化手段做一次“开发向评审”。
产品涉及多地区用户，时间/货币/数字/输入法问题常见。
团队希望把本地化检查从“上线前临时抱佛脚”变成“持续发现”。

后续计划

将 TestSprite 纳入发布前 Checklist：每次上线前跑一轮关键路径，并固定覆盖 zh-CN、en-US、de-DE 三组 locale + 不同时区，以尽早发现“看起来没问题、换个地区就崩”的隐性 bug。

文章发布地址

https://blog.example.com/testsprite-localization-review