Blogger 集成测试：实施检查清单（1-5）

当 API 返回一个帖子 ID 时，Blogger 集成并不算完成。只有当预期文章已发布、公开路由可正常加载、搜索引擎被允许索引、分析工具能够观测到访问情况，并且系统留下足够的证据来诊断故障时，它才算完成。

对于自动化 AI 辅助发布的工程团队来说，这一区分至关重要。某个工作流可能返回 200 OK，却创建的是草稿而不是上线文章，发布了错误语言，丢失了封面图，生成了冲突的规范 URL，或者把分析事件发送到了错误的属性。

这份 Blogger 集成测试实施检查清单将发布流程转变为一个五阶段的发布闸门。它专为基于 API 的工作流设计，但同样的结构也适用于低代码自动化和自定义 CMS 适配器。

五项检查一览

核心规则很简单：在开始下一阶段之前，先验证每个阶段的输出。不要把一次成功的请求当作整个发布工作流成功的证明。

1. 在写入之前验证 Blogger 配置

大多数集成失败最初都源于配置错误，并在后续表现为令人困惑的内容问题。在创建文章之前先验证目标。

你的预检应确认：

• 站点或博客 ID 属于预期的生产属性；
• API 基础 URL 指向正确的环境；
• 凭据可以读取目标站点，并且已被授权创建和发布文章；
• 源语言受到站点支持；
• 已配置的翻译语言是显式指定的，而不是从旧默认值推断出来的；
• 所选分类在目标站点上存在；
• 公开站点基础地址与计划发送的规范 URL 匹配；
• 当前运行中的自动发布行为是有意设置的。

将密钥保存在运行时密钥存储中。测试日志应记录凭据是否存在以及使用了哪个身份或作用域，但绝不应打印凭据值。

一个有用的配置断言如下所示：

{
  "site_id_verified": true,
  "environment": "production",
  "source_language": "en",
  "target_languages": ["zh"],
  "category_verified": true,
  "canonical_base": "https://example.com",
  "credentials_logged": false
}

如果发布所需的任何值缺失，就使运行失败。猜测分类、语言键或 canonical base 会让工作流变得不可确定。

2. 创建草稿并回读

草稿创建是第一次写入操作。它应该可以独立测试，并且是幂等的。如果你直接与 Google 的服务集成，请使用官方 Blogger Posts: insert reference 作为创建请求的契约，而不是照搬旧客户端中的字段。

在调用 API 之前，先构建一个规范化的文章对象。至少应包括：

• 标题和适合 URL 的 slug；
• 源语言；
• Markdown 和渲染后的 HTML 内容；
• 摘要；
• 元标题和元描述；
• canonical URL；
• 公开封面图片 URL；
• 作者显示名称；
• 已验证的分类 ID。

不要将本地文件系统路径作为封面图片上传。先上传图片，验证返回的 URL 可以公开访问，然后将该最终 URL 放入文章载荷中。

在创建请求之后，必须获得真实的 post ID。然后从 API 中读取草稿，并比较重要字段。如果服务悄悄地规范化或省略了关键值，即使响应成功也不够。

const created = await createPost(article);

if (!created.id) {
  throw new Error("Draft creation returned no post ID");
}

const draft = await getPost(created.id);

assert.equal(draft.slug, article.slug);
assert.equal(draft.language, article.language);
assert.equal(draft.cover_image_url, article.cover_image_url);
assert.equal(draft.meta_title, article.meta_title);

对于可重复的测试，请定义当 slug 已存在时的预期行为。要么更新已知文章，要么创建一个带版本号的测试 slug，或者以冲突错误停止。绝不要让重试创建出数量未知的重复文章。

3. 先发布源文章，再发布译文

将草稿创建和发布视为两个独立状态。如果平台有专门的发布端点，请显式调用它并保存原始响应。

源文章必须先成功发布，然后翻译任务才能开始。这个顺序可以防止在权威源失败时，本地化文章却变成公开状态。

对于每个已配置的目标语言：

1. 发送一条翻译请求；
2. 保留源文章的结构元素和封面图片；
3. 确认已创建本地化文章；
4. 确认其已达到 published 状态；
5. 保存其 post ID 和公开 URL。

除非服务文档说明支持可靠的批处理行为，否则请一次只运行一个目标语言。单语言请求更容易隔离超时、重试和部分失败。

你的发布结果应区分完整、部分和失败三种结果：

{
  "source": { "status": "published", "url": "https://example.com/blog/test-post" },
  "translations": {
    "zh": { "status": "published", "url": "https://example.com/zh/blog/test-post" }
  },
  "overall_status": "complete"
}

如果源内容发布成功但某个已配置的翻译失败，请报告为部分多语言失败。不要将其重新标记为仅源内容成功发布。

这与 内容发布 QA 中使用的同一种发布闸门思路一致：每一次状态转换都需要证据，而不是乐观判断。

4. 测试上线后的公共路由

API 状态和公共可用性是不同的系统。最终页面可能经过路由、渲染、CDN、缓存、本地化以及 SEO 模板层，而文章 API 从未触及这些层。

发布后请求每一个公共 URL，并验证：

• 该路由返回 HTTP 200，且没有意外的重定向循环；
• 响应中包含预期的文章标题或唯一内容标记；
• 页面只有一个页面级 H1；
• canonical 指向正确的公共 URL；
• 不存在意外的 noindex 指令；
• 封面图已存在且与 API 记录一致；
• 本地化页面暴露了预期语言以及相互对应的 hreflang 链接；
• 内部链接指向可访问的目标。

一个最小的 shell 检查可以捕获路由失败：

status=$(curl -L -sS -o page.html -w '%{http_code}' "$PUBLIC_URL")
test "$status" = "200"
grep -F "$EXPECTED_TITLE" page.html >/dev/null

随后再进行 HTML 级断言。解析文档，而不是依赖脆弱的字符串匹配来检查 canonical、robots、标题和语言。

Google 的索引系统评估的是公共页面，而不是你的内部 API 响应。Google 将 canonicalization 说明为整合重复 URL 的一种方法，而其 noindex 指南 解释了该规则必须可抓取，Google 才能看到它。正因如此，路由验证应当属于发布流程，而不是后续的编辑抽查。

如果你的工作流发布的是 AI 生成或本地化内容，也要检查最终渲染文本中是否存在模板泄漏、占位符值、重复标题和格式错误的代码块。关于更广泛的自动化决策框架，请参阅 Blog Automation Test: Comparison and Alternatives。

5. 验证度量并保留发布证据

即使文章已上线且可被索引，仍然需要一个观察计划。集成测试应证明度量配置正确，而不是假装发布当天的性能数据已经存在。

在发布时，记录：

• 源站和本地化后的公开 URL；
• 文章 ID 和发布时间戳；
• HTTP 状态和可索引性检查；
• 该路由预期的分析属性和事件名称；
• Search Console 后续跟进的负责人和日期；
• 转化复盘的负责人和日期。

对于 GA4，请使用 DebugView 或受控访问来确认该页面生成了预期事件。验证主机名、页面位置和内容元数据是否与生产路由一致。不要将你自己的测试会话作为有意义互动或转化表现的证据。

对于 Google Search Console，请在部署后检查准确的 URL，并在正常抓取和报告延迟之后监控展示次数和点击次数。第一次检查是技术可用性；后续检查是 Google 是否发现、编入索引并展示了该页面。

请将机器可读的结果文件与简洁的人类报告一起保存：

{
  "published_url": "https://example.com/blog/test-post",
  "http_status": 200,
  "indexability": "pass",
  "analytics_smoke_test": "pass",
  "gsc_follow_up": "scheduled",
  "artifacts": [
    "create-response.json",
    "publish-response.json",
    "route-check.json"
  ]
}

这些证据会把一个不稳定的发布脚本变成一个可运维的系统。当下一次故障发生时，团队可以识别它是发生在配置、草稿创建、发布、公开渲染还是测量阶段。

故障处理和重试规则

重试应当有上限，并且按阶段区分。

• 对瞬时网络故障进行退避重试。
• 不要在不更改负载或配置的情况下重试校验错误。
• 在重新尝试超时的创建请求之前，检查文章是否已经创建成功。
• 源内容发布失败后，绝不要开始翻译。
• 在少量、明确定义的尝试次数之后停止，并报告阻塞响应。
• 保留已去除密钥的原始 API 响应。

最危险的重试是未验证的创建重试。如果第一次请求已经成功但响应丢失，盲目重试可能会创建重复内容。在 API 支持幂等键时请使用它；否则，在再次创建之前，按你确定性的 slug 或外部运行 ID 进行搜索。

完成定义

只有当以下五项都为真时，Blogger 集成测试才算通过：

1. 配置已验证：工作流指向预期的网站、分类、语言、规范基址和凭据作用域。
2. 草稿已验证：API 返回文章 ID，且回读内容保留了文章包。
3. 发布已验证：源内容及所有已配置翻译都达到了所需的公开状态。
4. 路由已验证：每个公开 URL 都返回 HTTP 200，并通过规范、可索引性、标题、图片和语言检查。
5. 测量已验证：分析埋点可被观测到，且发布后的 Search Console 和转化跟进都有负责人。

这份检查清单故意比“API 调用成功了”更严格。发布本身就是一个上线流程。请以你对代码、提示词以及其他生产变更所采用的同样严谨标准来测试它。

如果 AI 生成内容是流程的一部分，请在发布前增加令牌和成本检查。用于 SEO 文章生成和本地化的令牌预算说明了如何将生成和翻译工作负载控制在可预测的范围内。