当時の怪しいメモ書き曰く「軽く考える」

原文、スペースだけ整形。

レイヤーが低いものから確認していく、確認出来次第テストが実行できる
必要に応じてスキップ・キャッシュできるものもあるはず

1. プロセス（マシン）のチェック、インストール（デプロイメント）
2. 各プロセスで実行するツール（Perl, Rubyとか）のユニットテスト（繰り返しの時はスキップするか）
3. 依存するライブラリの単体テスト・結合テスト（ライブラリのみで動かせるもの）
4. 開発しているシステム自体のテスト
　台数：1台でも動くなら、最小構成から〜
　可能なら1台毎にユニットテスト
　2台〜（考えられるノード構成で、いくつか実行）
　　ユニットテスト？
　＃ 各マシンで立ち上がったことの確認（wait... とか必須. 大変そう）
5. シナリオベースのテスト
シナリオ0: 普通に使う
　1. 初期化〜開始前までの状態の構築（テスト必須）
　2. immutable - ステップ X : 実行＆テスト（Verify）
　　immutableな操作なら、次のステップXに移っても良い（念のため1に戻るのも手か）
　3. mutable - 1へ戻る
　3. immutable + mutable の組み合わせ、順序を変えて連続実行してみる

シナリオX:
　マシンの条件を変える（使用できるメモリ、通信帯域、ディスク）
　実行時パフォーマンスの測定

テスト実行時に記録する物
　各マシンの初期化時間（時刻）
　テスト実行開始日時、テスト実行時間（全体, ユニット）
　Input/Outputのサイズ（通信、ディスク）
　メモリ使用量
　詳しくはMSのテスト本見れ

シナリオの実行（スクリプティング）どうするよ
　何かスクリプティング言語で抽象化して扱うことが出来るとよいね
　シナリオ（モデル）の種類は、テスト対象のどのドメイン（通信、モジュール）に負荷がかかるか、その割合を考えなければならない。
　　がむしゃらにカバレッジ率あげるのも無駄だろうけど、ユーザの操作に対する網羅性はあったほうがよいかも、という。

制約条件
　サーバの準備、確認できる事の種類
　　諦めざるをえない点も多いということ

予測
　どんな行動を予測するのか

ドメイン：システムをまたがる複雑なドメインは存在するか
　セキュリティ
　ログ
　エラーが起こったときの、モジュール（コード）場所の検出：追跡性
　観察性
　テストvsセキュリティ：テスト用のバックドアが残るとやばいぜ