<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>测试 on 老张开工了</title>
    <link>/%E6%B5%8B%E8%AF%95/</link>
    <description>Recent content in 测试 on 老张开工了</description>
    <generator>Hugo</generator>
    <language>zh-cn</language>
    <lastBuildDate>Mon, 27 Jul 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="/%E6%B5%8B%E8%AF%95/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>实战五：AI 测试与 CI 集成</title>
      <link>/posts/2026/07/ai-ci-integration/</link>
      <pubDate>Mon, 27 Jul 2026 00:00:00 +0000</pubDate>
      <guid>/posts/2026/07/ai-ci-integration/</guid>
      <description>前 28 章你的 AI 工作都是&amp;quot;我自己在 OpenCode 里跑跑&amp;quot;。第 29 章把这一摊 x fail + AI action 流搬到 CI/CD pipeline 上：每个 PR 一来，就触发一组&amp;quot;AI 验证 + AI 改进建议 + 安全扫描&amp;quot;jobs，让 review 之前先帮 reviewer 把关。&#xA;29.1 任务范围 把 5 个 AI-augmented jobs 加到 .github/workflows/pr-review.yml：&#xA;┌─ on: pull_request │ ├─ Job 1: digest (1 min, $0.01) 摘要 + AI 一句话 review │ ├─ Job 2: sanity (2 min, $0.05) 安全 / 私有 / license 扫 │ ├─ Job 3: unit (10 min, $0) 跑测试 │ ├─ Job 4: skill-check (3 min, $0.</description>
    </item>
    <item>
      <title>Skill 测试与演化</title>
      <link>/posts/2026/07/skill-testing/</link>
      <pubDate>Wed, 15 Jul 2026 00:00:00 +0000</pubDate>
      <guid>/posts/2026/07/skill-testing/</guid>
      <description>Skill 写完不等于&amp;quot;做完&amp;quot;——它跟代码一样会被模型版本变化、用户工作流变化、新 harness 行为变化折腾。本章把 Skill 当成 software：有 unit test、有 regression、有 changelog，让它在 6 个月后还能用。&#xA;23.1 为什么 Skill 也需要测试 不要等你某天打开 OpenCode 发现某个 Skill 触发率从 70% 跌到 5%——Skill 的&amp;quot;准确度&amp;quot;会随模型版本而漂移，prompt 中某词语的 token 化变了，召回就崩。可追踪、可回归是关键。&#xA;23.2 三类测试 类型 名称 测试对象 1 Trigger test &amp;ldquo;在 X 输入下会被召回吗&amp;rdquo; 2 Behavior test &amp;ldquo;被召回后遵循 Skill 内的 flow 吗&amp;rdquo; 3 Regression test &amp;ldquo;上次行为跑得 OK，这次没变吗&amp;rdquo; 23.3 Trigger test：写 probe 集 Create tests/probes.toml：&#xA;[[probe]] text = &amp;#34;给 lib/validators.py 加一个 is_alpha 函数&amp;#34; expect = &amp;#34;engaged&amp;#34; [[probe]] text = &amp;#34;为什么 Python 不需要类型?</description>
    </item>
    <item>
      <title>测试入门：unittest 与 pytest</title>
      <link>/posts/2026/05/testing/</link>
      <pubDate>Wed, 27 May 2026 00:00:00 +0000</pubDate>
      <guid>/posts/2026/05/testing/</guid>
      <description>当项目从几十行代码膨胀到几千行时，你会面临一个残酷的现实：改了一处逻辑，不知道哪里会碎。手动测试一遍所有功能越来越耗时，而且人总会漏掉东西。这就是自动化测试登场的地方——用代码来验证代码。&#xA;Python 的标准库内置了 unittest 模块，社区则更青睐简洁的 pytest。本章从零开始，带你建立测试思维，掌握两种测试框架，最终写出可维护的测试。&#xA;为什么需要测试？ 没有测试的项目就像走在钢丝上：&#xA;# 假设这是你的核心函数 def calculate_discount(price: float, member_level: str) -&amp;gt; float: &amp;#34;&amp;#34;&amp;#34;根据会员等级计算折扣价&amp;#34;&amp;#34;&amp;#34; discounts = {&amp;#34;normal&amp;#34;: 0.95, &amp;#34;silver&amp;#34;: 0.9, &amp;#34;gold&amp;#34;: 0.8} return price * discounts.get(member_level, 1.0) # 改了一行代码——有人把 silver 的折扣改成了 0.85 # 没有测试的话，你可能永远不会发现这个&amp;#34;优化&amp;#34;改变了行为 测试带来的好处：&#xA;好处 说明 回归防护 修改代码后立即知道是否有东西被破坏 活的文档 测试代码展示了函数在各种情况下的预期行为 设计反馈 如果函数很难写测试，通常意味着它的设计需要改进 信心 重构时不怕改出问题，测试网络会兜住你 unittest：标准库自带 unittest 是 Python 标准库的一部分，灵感来自 Java 的 JUnit。不需要额外安装，开箱即用。&#xA;基本结构 import unittest # 被测函数 def add(a, b): return a + b class TestMathOperations(unittest.</description>
    </item>
  </channel>
</rss>
