システムテストの試験項目

  • 開発現場毎に同一内容の試験なのに用語が違うのはよくある。
  • システムテストを行う前にはテスト計画を行う必要がある。
  • テスト環境と運用環境の差分がテストに影響するのを防ぐため、運用環境と同じ状態で試験を実施する。
  • システムテストではモジュール間を含むという観点では結合テストのモジュール間テストに近いが、システムテストではシステム全体でないと実現できない項目を対象。長期安定テストや(CPU使用率やメモリ使用率等の)効率性テストは、システム全体という観点でないと意味がない。
  • モジュール間に閉じた観点に関しては対象としない(2つのモジュール間のIFなど)。
  • システムテスト段階でバグが発覚すると、個別の結合テストからやり直しとなるので修正にかかる稼働が膨大となる。
  • 当然であるがシステムテストを実施しないなどは性能や機能の担保ができなくなるため論外である。

機能テスト(正常/準正常/異常)

  • システムテストでは、結合テストと異なり個別のモジュールが実装している機能を網羅的に対象とすることはない。そのため同じ機能テストでも試験パターンは単体テスト結合テストより少ない
  • システムテストでは、モジュールの機能単位ではなく、運用上想定される業務シナリオに沿って試験項目を作成する。そのため1つのテスト項目でシステム全体を確認するためテストの確認項目が増える傾向がある

複数複合テスト

  • 「申し込み」「変更」「削除」など複数種類の処理を複数回平行して実行させた場合でもシステムが正常に動作することを確認する。
  • 競合処理間が正しく動作することを確認する

長期安定テスト

  • 通称長安。長期間システムが安定して動作することを確認する。
  • 名前の通り時間がかかるが単に放置するだけではない。期的にシステムにリクエストを送信する場合は長安用のツール作成が必要となる
  • コードや設定ファイルの修正が入るたびに原則としては長安のやり直しとなるのがキツイ

負荷テスト

  • 別名いじめ試験
  • 事前にシステムの想定負荷を決めておく必要がある

回復性テスト

  • 障害が発生しないことではなく運用上想定される障害が発生してもシステムが回復できることを確認する
  • 簡単なケースだとシステムの電源断→電源復旧後に正しく起動できることの確認
  • テストの性格上実際に障害を発生させる必要があるため万が一を想定して一番最後に実施するのが望ましい

時間効率性テスト

  • 1つの業務処理を完了するのに要する時間が事前想定値内に収まることを確認する
  • 事前に想定処理時間を決めておく必要がある

資源効率性テスト

  • CPUやメモリの利用率に異常がないことを確認する
  • メモリリークの有無などはこの項目で確認する

セキュリティテスト

  • 網羅的にやるのは現実的には非常に困難
  • 実際にはFWやWAFの設定確認くらいでお茶を濁すことも多い