DSHIO/T 20—2026 測試方法總則

---

1 範圍

本標準規定了 DSH 插件測試的階段劃分、各階段的目的、操作、觀測對象與判定規則。

本標準適用於任何依據 DSHIO 標準對插件作出判定的個人或系統。

本標準不規定測試條件 —— 環境、資源、網絡、超時等固定值見 DSHIO/T 21。

分工： 本標準回答「做什麼、看什麼、怎麼判」；DSHIO/T 21 回答「在什麼條件下做」。

1.1 實施獨立性聲明

本標準不要求使用特定的測試工具或框架。任何能產生相同觀測結果的實現都是合格的。

本標準定義的是觀測契約，不是腳本。

---

2 規範性引用文件

---

3 術語和定義

DSHIO/T 00—2026 界定的術語適用於本文件。

本文件補充定義：

3.1 階段

stage

測試中的一個獨立檢查環節。六個階段代號為 T0 至 T5。

3.2 階段終止

stage termination

某階段判定失敗後，後續階段不再執行的行為。

理由： 後續階段的結果在前提不成立時無意義，且浪費資源。

3.3 觀測對象

observation target

某階段用於判定的事實來源。例如「命令退出碼」「輸出中的某一行」。

3.4 階段證據

stage evidence

該階段的原始輸出，用於支持判定並供複核。

所有階段的證據必須完整保留，不得只保留判定結果。

---

4 階段總覽

T0–T4 為模型無關階段。 依據：模型接入由獨立插件提供，不在 harness 核心內。

必須按 T0 → T1 → T2 → T3 → T4 順序執行。 T5 在 T4 通過後可選執行。

---

5 T0 靜態檢查

5.1 目的

在不接觸運行環境的前提下，判定插件的結構是否合法。

5.2 前提

無。T0 不需要容器，不需要網絡訪問 DSH。

需要的輸入：

• 插件在 registry 的元數據（package.json）
• patch 文件的內容

5.3 操作

1. 從公共 registry 取插件元數據，確定目標版本
2. 從元數據取 dsh.bundle.patch 的值
3. 從公共 CDN 取該 patch 文件
4. 按 DSHIO/T 10 附錄 A 的順序執行檢查

5.4 觀測對象

5.5 判定

T0 不產生 pass/install_failed 這類判定。 它的輸出是逐條結果加一個布爾值。

5.6 終止規則

T0 不因失敗而終止後續階段。 靜態不合規的插件仍可提交 T1–T4 —— 因為靜態檢查可能有誤，實測才是最終依據。

但工具應提示： 靜態有 critical 不符合時，沙箱測試大概率失敗，建議先修。

---

6 T1 安裝

6.1 目的

判定插件能否被包管理器正確解析並安裝到 DSH profile。

6.2 前提

• 乾淨的 profile（無既有插件依賴）
• 網絡可用（需要下載包）
• 符合 DSHIO/T 21 第 5.1 節的資源限制

6.3 操作

dsh plugin --profile web add <package-spec>

package-spec 為 npm 包名（可帶版本）或 github:owner/repo。

6.4 觀測對象

三者必須一致。 退出碼為 0 但依賴未寫入，不算成功。

6.5 判定

6.6 首次錯誤

失敗時必須從輸出中提取第一條能定位原因的非空行，作為 first_error。

排除： 純 JSON 行、框線裝飾行（╭、│、╰）、進度行（Progress:）。

用途： 給作者修復線索，不用於判定。

---

7 T2 列裝

7.1 目的

判定安裝後的插件是否出現在 profile 的依賴列表中。

7.2 前提

• T1 通過
• 網絡斷開（--network none）

7.3 操作

dsh plugin --profile web list

7.4 觀測對象

輸出的 dependencies 區塊中是否列出目標包及其版本。

7.5 判定

注： T2 失敗時判定為 install_failed 而非獨立判定。理由：T2 失敗意味著安裝沒有真正完成，與 T1 失敗的實際後果相同。

---

8 T3 掛載

8.1 目的

判定插件的 entry 是否進入合成後的配置樹。

這是「裝上了」和「真的生效」的分界線。 很多插件能裝上、能列裝，但 entry 沒有進入配置樹，功能完全不會生效。

8.2 前提

• T2 通過
• 網絡斷開

8.3 操作

dsh --profile web --dump-config

8.4 觀測對象

判定 entry 存在的準確方式： 在輸出的 YAML 中查找 - id: <entry-id> 且其下 name: 為預期的模組名。

不可只 grep 包名 —— 包名可能出現在無關的配置值中。

8.5 判定

8.6 installs_but_not_registered 的意義

這是最容易被忽略、也最讓使用者困惑的失敗模式：

• 使用者看到「安裝成功」
• 插件列表裡也有
• 但功能就是不生效

常見原因：

1. patch 的 insert 被 profile 後續層覆蓋或禁用
2. id 與已存在的 entry 衝突，導致覆蓋而非新增
3. patch 文件寫入了但沒有 insert 項

---

9 T4 啟動

9.1 目的

判定載入插件後 profile 能否啟動，並在啟動後保持存活。

9.2 前提

• T3 通過
• 網絡斷開
• 進程數上限（見 DSHIO/T 21 5.1.5）

9.3 操作

dsh --profile web

啟動後觀察 12 秒，期間進程必須保持存活。

9.4 觀測對象

web profile 的啟動成功標誌： 輸出含 dsh web: http://... 行。

9.5 判定

9.6 為什麼要斷網

兩個理由：

1. 可複現性 —— 有網時，插件可能依賴外部服務返回的內容，導致結果隨服務狀態變化
2. 安全性 —— 即使插件有惡意行為，也無處發送資料

同時： 斷網能讓殘留的網絡請求失敗並暴露出來，這本身就是一個有價值的觀測。

---

10 T5 工具調用（模型相關）

10.1 目的

判定模型能否正確理解並調用插件註冊的工具。

10.2 前提

• T4 通過
• 插件註冊了至少一個工具
• 模型可用
• 測試條件符合 DSHIO/T 21 第 6 章

10.3 操作

1. 構造一個明確需要調用目標工具的自然語言請求
2. 記錄系統提示詞全文與測試提示詞全文
3. 在固定模型與固定生成參數下執行
4. 重複 3 次

10.4 觀測對象

10.5 判定

必須在報告中寫明採用哪條判據：

T5 的判定結論必須註明模型。 只寫「通過」不註明模型的 T5 報告無效。

10.6 為什麼 T5 不算在 T0–T4 裡

模型的隨機性使 T5 的結果不是確定性的。把它和確定性的階段混在一起，會讓整個判定看起來不可信。

分開的好處： 使用者能清楚知道「這個插件裝得上」（確定）vs「這個模型能正確用這個插件」（概率）。

---

11 判定與傳播

11.1 判定代號

11.2 傳播規則

一旦某階段判定失敗，後續階段不執行，其結果記為「未執行」。

不得把「未執行」當成「失敗」，也不得當成「通過」。

11.3 不穩定

重複執行得到不同判定時：

1. 判定記為 unstable
2. 保留全部重複的完整證據
3. 不得作為認證依據

常見的不穩定來源：

• 網絡波動（T1）
• 依賴版本漂移
• 資源不足導致的超時

---

12 證據要求

12.1 必須保留的證據

12.2 證據的用途

1. 支持判定結論
2. 供第三方複核
3. 供作者定位問題

只保留判定結果、不保留證據的測試報告，不具備可複核性，不得作為認證依據。

---

13 與 DSHIO/T 21 的接口

本標準的每個階段都依賴 DSHIO/T 21 定義的條件。

執行測試前必須：

1. 讀取 DSHIO/T 21 第 5 章（T0–T4）或第 6 章（T5）
2. 按規定固定全部條件
3. 生成環境指紋
4. 記錄到報告中

條件有任何偏離時： 按 DSHIO/T 21 第 8 章處理，且該報告的判定不得與未偏離的報告比較。

---

附錄 A（規範性）階段執行清單

T0  静态检查
    ├─ 取元数据
    ├─ 取 patch 文件
    ├─ 按 DSHIO/T 10 附录 A 逐条检查
    └─ 输出：逐条结果 + conforming_static
         ↓（无论 T0 结果如何，都可继续）
T1  安装（有网）
    ├─ dsh plugin add
    ├─ 检查退出码
    ├─ 检查 profile package.json
    └─ 失败 → install_failed，终止
         ↓
T2  列装（断网）
    ├─ dsh plugin list
    ├─ 检查目标包是否出现
    └─ 失败 → install_failed，终止
         ↓
T3  挂载（断网）
    ├─ dsh --dump-config
    ├─ 按 entry-id 精确查找
    ├─ 找不到 → installs_but_not_registered，终止
    └─ 命令失败 → config_failed，终止
         ↓
T4  启动（断网）
    ├─ dsh --profile web
    ├─ 观察 12 秒
    ├─ 检查成功标志
    └─ 失败 → boot_failed，终止
         ↓
T5  工具调用（可选，模型相关）
    ├─ 固定模型与参数
    ├─ 重复 3 次
    └─ 按判据输出，注明模型

---

附錄 B（資料性）判定分布參考

基於 3,995 個插件的實測（DSH 0.2.2-rc.1，截至 2026-11-07）：

觀察：

1. 約五分之一的插件在基準版本上裝不上 —— 這是使用者最需要的資訊
2. installs_but_not_registered 佔比雖小（1%），但這個失敗模式最難被使用者自行發現
3. boot_failed 極少（0.3%），說明能掛載的插件通常也能啟動

---

修訂記錄