---
generated_at: 2026-02-20 12:00:00
metrics:
  claims_total: 32
  claims_with_evidence: 29
  claims_without_evidence: 3
confidence_derived: 0.91
---

# 根拠レポート：テスト方針書

## 本レポートについて

### 目的
本レポートは、生成された設計書・ドキュメントの信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

### チェック方法
以下の観点でドキュメントの内容（Claim：主張）を検証しています：

1. **根拠の有無確認**：各主張に対して、ソースコード・既存設計書・要件定義書などの根拠（Evidence）が存在するか
2. **根拠との整合性**：主張の内容が根拠と矛盾していないか
3. **網羅性**：参照すべき情報源を適切にカバーしているか

### 信頼度スコアの算出
- **confidence_derived** = 根拠あり件数 / 総主張件数
- 状態「○」：根拠あり、「△」：根拠不足または要確認

### 本レポートの使い方
1. まず「サマリー」で全体の信頼度と優先レビュー項目を確認
2. 「Claims と根拠の対応」で △ の項目を重点的にレビュー
3. 「不足情報」で補完が必要な情報源を確認

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.91**
  - 根拠あり：29 / 32、根拠なし：3
- 優先レビュー（高）
  1. **受入テストの担当・実施方法**：プロジェクト内に受入テストの明確な定義がなく推定で記載
  2. **セキュリティテストの具体的実施内容**：セキュリティテストの設定ファイル・スクリプトが存在しない
  3. **不具合管理フロー**：GitHub Issuesの使用は一般的推定であり、プロジェクト固有のルール文書は未確認

## 2) 参照した情報（Evidence一覧）
> ここに「実在するもの」だけ列挙。抽出フェーズで付けたIDをそのまま出す。

- E-01: `dub.json` — メインパッケージ設定、依存関係、unittest/unittest-optimized configuration定義
- E-02: `.github/workflows/unittest.yml` — CIユニットテスト・結合テストワークフロー定義
- E-03: `.github/workflows/nightly.yml` — ナイトリービルドワークフロー定義
- E-04: `.github/workflows/releases.yml` — リリースワークフロー定義
- E-05: `test/runtests.sh` — 結合テスト実行スクリプト
- E-06: `test.bat` — ローカルテスト一括実行スクリプト
- E-07: `test/tc_as_a_exe/source/app.d` — E2Eテスト実装
- E-08: `test/tc_as_a_exe/source/tests/package.d` — テストヘルパークラス定義
- E-09: `null_server_test/source/app.d` — null_server E2Eテスト実装
- E-10: `workspace-d/source/workspaced/helpers.d` — テストユーティリティ関数
- E-11: `test/data/` — テストデータディレクトリ
- E-12: `test/tc_implement_interface/tests/` — インターフェース実装テストの入力/期待出力ペア
- E-13: `workspace-d/dub.sdl` — workspace-dサブパッケージ設定（silly依存定義）
- E-14: `source/served/info.d` — バージョン情報（0.8.0-beta.18）
- E-15: `.vscode/launch.json` — デバッグ設定
- E-16: `workspace-d/.travis.yml` — 旧Travis CI設定
- E-17: `ci/build.sh` / `ci/build.bat` — CIビルドスクリプト
- E-18: `ci/validate_version.d` — バージョン検証スクリプト
- E-19: `test/data/dcd/download_dcd.d` — DCDダウンロードスクリプト
- E-20: `source/served/utils/ddoc.d` 他42ファイル — unittest含むソースファイル群

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | serve-dはD言語製LSPサーバーでバージョン0.8.0-beta.18 | E-14 | ○ |
| C-02 | 6つのサブパッケージ（http, protocol, lsp, serverbase, dcd, workspace-d）で構成 | E-01 | ○ |
| C-03 | 単体テストはD言語組み込みunittestブロックで実装 | E-20 | ○ |
| C-04 | 42以上のファイルにunittestブロックが存在 | E-20 | ○ |
| C-05 | テストランナーとしてsillyを使用（バージョン~>1.1.1） | E-01, E-13 | ○ |
| C-06 | 結合テストは`test/tc_*`ディレクトリに8テストケースが存在 | E-05, E-07 | ○ |
| C-07 | tc_dubテストケースでDUBプロジェクト操作を検証 | E-05 | ○ |
| C-08 | tc_as_a_exeでserve-dプロセスのE2Eテストを実施 | E-07, E-08 | ○ |
| C-09 | null_server_testでJSON-RPC通信のE2Eテストを実施 | E-09 | ○ |
| C-10 | 受入テストは対象エディタでの手動確認 | **根拠なし** | △ |
| C-11 | CIはGitHub Actionsで3ワークフロー構成 | E-02, E-03, E-04 | ○ |
| C-12 | unittest.ymlはmaster pushとPRでトリガー | E-02 | ○ |
| C-13 | CIマトリクスは3 OS × 2コンパイラ（一部除外あり） | E-02 | ○ |
| C-14 | 各サブパッケージのテストに個別のタイムアウトが設定 | E-02 | ○ |
| C-15 | nightly.ymlは毎日UTC 02:00にcron実行 | E-03 | ○ |
| C-16 | releases.ymlはリリース公開時にトリガー | E-04 | ○ |
| C-17 | バージョン検証にci/validate_version.dを使用 | E-18 | ○ |
| C-18 | カバレッジ計測は未導入 | E-01, E-02（-covフラグ・lcov等の設定が不在） | ○ |
| C-19 | テストデータは`test/data/`に`__EOF__`マーカー形式で格納 | E-11 | ○ |
| C-20 | インターフェース実装テストは入力.dと期待出力.d.expectedのペアで管理 | E-12 | ○ |
| C-21 | E2Eテスト用テンプレートが`test/tc_as_a_exe/template/`に配置 | E-07, E-08 | ○ |
| C-22 | DCD依存テストは`.needs_dcd`マーカーで識別しDCDを自動ダウンロード | E-05, E-19 | ○ |
| C-23 | ServedTest/ServedInstancedTest抽象クラスがE2Eテスト基盤を提供 | E-08 | ○ |
| C-24 | makeTemporaryTestingWorkspaceが一時ワークスペースを作成 | E-10 | ○ |
| C-25 | runTestDataFileTestsがテストデータファイルを読み込み実行 | E-10 | ○ |
| C-26 | セキュリティテストとしてTLS検証・パストラバーサル防止等を実施 | **根拠なし** | △ |
| C-27 | 不具合管理はGitHub Issuesで実施 | **根拠なし** | △ |
| C-28 | ローカルテスト実行はtest.bat/test.shで一括実行可能 | E-06 | ○ |
| C-29 | workspace-dに旧Travis CI設定が残存 | E-16 | ○ |
| C-30 | 対応プラットフォームはLinux, macOS, Windowsの3種 | E-02, E-03, E-04 | ○ |
| C-31 | .vscode/launch.jsonでGDB/LLDBデバッグに対応 | E-15 | ○ |
| C-32 | CIビルドスクリプトはci/build.sh, ci/build.batで管理 | E-17 | ○ |

## 4) 不足情報（Unknown / Missing）
- **受入テスト（C-10）**: プロジェクト内に受入テストの手順書やチェックリストが見つからなかった。受入テストの具体的な実施方法は推定に基づく
  - 候補：CONTRIBUTING.md / リリースチェックリスト / code-d拡張側のテスト文書
- **セキュリティテスト（C-26）**: セキュリティテスト専用の設定やスクリプトは存在しない。httpサブパッケージのコードから推定したもの
  - 候補：セキュリティポリシー文書 / SECURITY.md / 脆弱性スキャンCI設定
- **不具合管理フロー（C-27）**: GitHub Issuesの使用は一般的なOSSプロジェクトの慣例から推定。プロジェクト固有の不具合管理ルールは未確認
  - 候補：CONTRIBUTING.md / Issue テンプレート / プロジェクトWiki

## 5) リスクフラグ（レビュー観点）
- **0: 低リスク** — 単体テスト・結合テスト・CI/CD連携に関する記述（C-01〜C-09, C-11〜C-25, C-28〜C-32）：ソースコードと設定ファイルから直接確認済み
- **1: 中リスク** — 受入テストと不具合管理フロー（C-10, C-27）：プロジェクト内に明示的な定義がなく一般的な推定に基づく
- **2: 高リスク** — セキュリティテスト内容（C-26）：セキュリティテストの実態が不明であり、方針書に記載した内容が実際に実施されているか要確認

## 6) レビュアーチェックリスト（最小）
- [ ] 受入テスト（C-10）の実施方法がプロジェクトの実態と合致しているか確認
- [ ] セキュリティテスト（C-26）が実際に実施されているか、または今後の方針として適切か確認
- [ ] 不具合管理フロー（C-27）がプロジェクトの実態と合致しているか確認
- [ ] カバレッジ未導入の現状認識と改善提案が妥当か確認
- [ ] CIタイムアウト値（30分、10分、5分）が実際のワークフロー定義と一致しているか確認
