テスト種別（非機能テスト）

非機能テストは「機能が正しいか」ではなく「どのくらい速いか」「どのくらい安全か」「どのくらいアクセスしやすいか」といった品質特性を検証する。開発サイクルの後半でまとめて実施されることが多いが、早期に非機能要件をテストとして定義しておかなければ、リリース直前になって基準未達が判明するリスクがある。

負荷テスト・パフォーマンステストは、システムが期待されるスループットとレイテンシを満たすかを検証する。負荷テスト（Load Testing）は想定される同時接続数での動作確認、ストレステスト（Stress Testing）は限界を超えた負荷での動作確認、スパイクテスト（Spike Testing）は急激なトラフィック増加への応答を検証する。k6はJavaScriptでテストシナリオを書けるモダンなOSSで、Grafanaとの統合によるリアルタイムモニタリングが強い。JMeterはGUI操作で設定でき、企業での採用実績が多い。P95/P99レイテンシの目標値を事前に定義しておくことが重要だ。

セキュリティテストのDASTはデプロイ済みのアプリケーションに対して外部から動的に脆弱性を探索する手法だ。OWASP ZAPはWebアプリのスキャンツールとして広く使われており、CIパイプラインへの組み込みも可能だ。アクセシビリティテストはJIS X 8341やWCAG 2.1への適合を自動検証し、axe-coreはPlaywright/Cypress/Jestと統合してレポートを生成できる。Lighthouseはパフォーマンス・アクセシビリティ・SEOのスコアを一括で測定する。

コードレビューで着目するポイント

• パフォーマンステストでP95/P99レイテンシの閾値が定義されているか
• テストシナリオが本番に近いデータ量・同時接続数を想定しているか
• k6やJMeterのシナリオがユーザーの実際の操作パターンを反映しているか
• セキュリティテストが主要な攻撃ベクター（XSS・SQLインジェクション・認証バイパス等）をカバーしているか
• アクセシビリティテストがCI/CDで自動実行されているか
• 非機能テストの結果が時系列で追跡・比較できるようになっているか

典型的なアンチパターン

リリース直前の初回負荷テスト: 本番リリース前日に初めて負荷テストを実施し、性能問題が発覚する。改修コストが高く、リリース延期や設計変更を余儀なくされる。定期的にパフォーマンス回帰テストを実施すべきだ。

本番とかけ離れたテスト環境: テスト用DBのレコードが数百件のみで負荷テストを実施する。本番の数百万レコードでは全く異なる応答時間が発生し、テスト結果が参考にならない。

アクセシビリティテストの後回し: axe-coreのチェックをリリース後の改修フェーズに先送りにする。UIコンポーネントが固まった後の修正はコストが高く、デザインシステムレベルで対応すべき問題が後から判明する。

参考リソース

• k6 https://k6.io — JavaScriptで書くモダンな負荷テストツール
• Apache JMeter https://jmeter.apache.org — GUIベースの負荷テストツール
• OWASP ZAP https://owasp.org/www-project-zap — WebアプリのDASTスキャナ
• axe-core https://github.com/dequelabs/axe-core — アクセシビリティ自動テストエンジン
• Lighthouse https://developer.chrome.com/docs/lighthouse — パフォーマンス・アクセシビリティの総合スコア測定