1. 外部論理と内部論理と
テスト空間
コヤマン

2. WACATE2012冬から。


WACATE2012 冬において
デバッグ工学研究所の松尾谷徹氏の講演
「CFD++」の資料内にて説明がありました、
「外部論理」と「内部論理」について
コヤマンがぼんやり考えたこと。
前提として、開発とテストが分離している想定
(自分の置かれている状況)

3. 設計をする際に考えること

外部論理




要求・背景
ユーザモデル
予算やスケジュール
内部論理





使用言語による制約
アーキテクチャによる制約
他コンポーネントとの連携による制約
ハードウェアなどとの連携による制約
開発チームメンバによる制約などの影響

4. テストを設計する際に考えること

外部論理





要求・背景
ユーザモデル
予算やスケジュール
テスト対象自身(構造や振る舞い)
内部論理


過去のテスト実績（テスト資産）
テストチームメンバや環境による制約

5. 絵にするとこんな。
要求・背景
ユーザモデル
上側：外部論理
予算
スケジュール
対象システム
(構造や振る舞い)
要求分析
対象システム用
テスト
受け入れテスト
過去テスト制約
テストチームメンバ制
約
下側：内部論理
基本設計
システムテスト
過去テスト制約
テストチームメンバ制
約
アーキテクチャ
制約
詳細設計
統合テスト
他コンポーネント制
約
実装
言語制約
チームメンバ制約
ハードウェア制約
コンポーネント
テスト
過去テスト制約
テストチームメンバ制
約
過去テスト制約
テストチームメンバ制
約
対応関係

6. 設計とテストの違い



設計側の内部論理＝作る側の論理
テスト側の内部論理＝使う側、テストする側の論理
テスト側の外部論理＝テスト対象も追加

7. テスト空間





環境
ビジネス領域
システム領域
ソフトウェア領域
環境
ビジネス領域
これらの要求を満たしていることの
証明手段としてのテストも存在する
システム領域
ソフトウェア領域

8. テスト空間に対する
外部論理と内部論理
環境
要求・背景
予算
スケジュール
過去
運用テスト制約
ビジネス領域
過去
システムテスト制約
ユーザモデル
テストチーム
メンバー制約
システム領域
メンバー制約
アーキテクチャ
制約
他コンポーネント
制約
言語制約
過去
統合テスト制約
ソフトウェア領域
ソフトウェア
制約
過去
単体テスト制約

9. 良く考えられたテストとは



外部論理と内部論理を考慮している
テスト空間を意識し、優先順位がある
スコープが明確である
=何をどれだけ知りたいのか、診たいのか