[book] The Art of Application Performance Testing

1. Ch1 なぜ

1.1. 1.1 パフォーマンステストとは

1.1.1. ユーザー体験が第一である

1.1.1.1. 常に反応性があり、注意を妨げられることもない

1.1.2. 1.1.1 測定

1.1.2.1. サービス指向の測定基準

1.1.2.1.1. availability

1.1.2.1.2. response time

1.1.2.2. 効率指向の測定基準

1.1.2.2.1. throughput

1.1.2.2.2. utilization

1.1.3. 1.1.2 業界標準はまだない

1.1.3.1. 2秒以上のラグは、ユーザー体験のかなりのダメージを与える

1.1.4. 1.1.3 インターネットの場合

1.1.4.1. 負荷が瞬間的に集中することもあるので注意

1.2. 1.2 なぜ悪い成績が出やすいか

1.2.1. 1.2.1 性能問題は開発の後期にでやすく、改善にコストを割きにくいため

1.2.2. 1.2.3 性能指向の全体設計は忘れられがちなため

1.2.3. 1.2.2 性能指向の開発スタイルだと運営後に問題が出る確率は5%

1.2.4. 1.2.5 実際の負荷を考慮していないことが多いため

1.2.4.1. ユーザー数は?

1.2.4.2. 同時に使うユーザー数は?

1.2.4.3. アプリへの接続方法は?

1.2.4.4. 長期間で見て、何人のユーザーがアプリに接続するか?

1.2.4.5. サーバーの数と配置場所は最終的にどうなるか?

1.2.4.6. アプリがネットワークの容量に与える影響は?

1.2.5. 1.2.6 サービスの人気を低く見積もってしまうため

1.2.5.1. 最初は人が集まりやすいもの

1.2.6. 1.2.7 性能テストは未熟な分野なため

1.2.7. 1.2.8 自動テストツールを使っていないため

1.2.8. 1.2.9 自動テストツールが使いにくいアプリなため

1.3. 1.3 アプリケーション・パフォーマンステストは、開発サイクル上重要な位置を占めており、もっと注意を向けられるべきである

2. Ch2 基礎

2.1. 要件分析

2.1.1. リリース時にはユーザーは何人いるか? 6ヶ月後は、12ヶ月後は、2年後は?

2.1.2. ユーザーの地理的分布は? 回線は?

2.1.3. リリース時の同時接続数は? 6ヶ月後は、12ヶ月後は、2年後は?

2.2. 条件分析

2.2.1. アプリケーションレイヤごとに必要なサーバー性能と台数は?

2.2.2. 必要なネットワークインフラは?

2.3. テストの実施方針を決める

2.3.1. 適切なテストツールを選ぶ

2.3.2. 適切なテスト環境を選ぶ

2.3.3. 現実的かつ適切な目標を決める

2.3.4. 製品がステーブルなことを確認する

2.3.5. コードフリーズをゲットする

2.3.6. クリティカルなトランザクションを同定し、スクリプトにする

2.3.7. クオリティの高いテストデータを充分用意する

2.3.8. 正確なパフォーマンステスト計画を立てる

2.3.9. パフォーマンス指標をサーバとネットワークについて決める

2.3.10. パフォーマンステストが効果を発揮できるだけの期間をあてる