0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

[初心者向け]テストレベル - 統合テスト

Posted at

徹底攻略 JSTQB Foundation教科書&問題集 シラバス2018対応を勉強しているので、自分のメモとしてまとめています。第10弾。

テストの目的

統合テストの目的は、インターフェース部分の振る舞いが正常かどうかを確認すること。

属性

  • インターフェースの振る舞いが設計・仕様通りであることの検証
  • インターフェースに存在する欠陥の検出
  • インターフェースの品質に対する信頼の積み上げ
  • 欠陥が上位レベルのテストまで見逃されることの防止
  • リスクの低減

説明

統合テストは、コンポーネントテストやシステム間の相互処理のテストのこと。
あくまで相互処理やインターフェースに焦点を当ててテストを行う。
ただ、統合テストにおいてコンポーネントやシステムに内在する欠陥が検出されることもよくある。

特性

リグレッションテストの自動化

コンポーネントテストと同様。
自動化しておくことでコードの変更が既存のインターフェースやコンポーネント、システムを破壊しないという信頼性を提供できる。

コンポーネント統合テストとシステム統合テスト

統合テストではテスト対象が2つある。
コンポーネント間のインターフェースを対象とするものをコンポーネント統合テスト、システム間のインターフェースを対象とするものがシステム統合テストである。

コンポーネント統合テスト

  • コンポーネント間の相互処理とインターフェースに焦点を当ててテストをする
  • コンポーネントテストが終わった後で実施
  • 継続的インテグレーションの一環として自動化されることも多い

システム統合テスト

  • マイクロサービス(小さなサービスを組み合わせてソフトウェアを作る手法における構成要素)間の相互処理とインターフェースに焦点を当ててテストする
  • システムテストが終わった後、またはシステムテストと並行して実施
  • 外部システムとのインターフェースが正常かどうかを確認する作業も範囲内

テストベース

  • ソフトウェア設計書システム設計書
  • インターフェース仕様や通信プロトコルの仕様
    • システム間の連携部分に関するもの
  • シーケンス図(オブジェクト間のやり取りを時間軸に沿って表現するもの)
  • ユースケース図(ユーザー目線でシステムがどのような使われ方をするのかの図)
  • ワークフロー(業務の流れを図解したもの)
  • コンポーネントレベルやシステムレベルのアーキテクチャー
  • 外部とのインターフェース定義

など

テスト対象

統合テストの対象は、いくつかのコンポーネントのかたまりで、以下のインターフェースやAPIがテスト対象になる。

典型的な欠陥と故障

コンポーネント統合テスト

以下が主な典型例になる。

  • データの欠陥
    • データが正しくない
    • データ不足
    • データエンコーディング(コード変換)が正しくない
  • インターフェースの欠陥
    • 呼び出しが正しくない
    • 順序やタイミングが不正
    • 不整合
  • コミュニケーションの欠陥
    • コンポーネント間のコミュニケーション故障
    • 処理が不在または不適切
  • 仕様不一致の欠陥
    • コンポーネント間で渡されるデータの意味・単位・境界の正しくない思いこみ

システム統合テスト

以下が主な典型例になる。

  • システム間で一貫性のないメッセージ構造
  • データの欠陥
    • データが正しくない
    • データ不足
    • データエンコーディング(コード変換)が正しくない
  • インターフェースの不整合
  • システム間通信の故障
    • 処理が不適切
    • データが合わない など
  • 仕様の不一致
    • システム間で渡されるデータの意味、単位、境界の正しくない思いこみ
  • 必須セキュリティ規制への非準拠

アプローチと責務

統合テストのアプローチと責務に関して、次のような特徴を示す。

インターフェースに集中

コンポーネント統合テストとシステム統合テストは、相互連携やインターフェースなど、統合部分だけに集中してテストする。

機能テスト、非機能テスト、構造テストを行える

統合テストでは、機能テスト(機能要件が正しいことを評価)のほかに非機能テスト(セキュリティや使用性など、機能以外の要件が正しいことを評価)、構造テスト(コンポーネントやシステムの構造、アーキテクチャが仕様通りであることを評価)なども行うことができる。

テスト担当者がテスト

コンポーネント統合テストは開発担当者自信がテストするが、システム統合テストは通常テスト担当者が実行する。
そのため、テスト担当者はシステムアーキテクチャを理解し、統合テスト計画の作成に関与すべきとされている。

開発前にテスト戦略を計画

コンポーネントやシステムを構築する前に統合テストや統合戦略を計画にすると、テスト効率が高いシステムを作ることができる。
統合戦略とは、システムアーキテクチャや機能的タスク、トランザクション処理シーケンスなどがベースになる。

インクリメンタルにテスト

統合テストはビックバン(すべてのコンポーネントやシステムを一度にテストする)ではなく、ある部分から順番にテスト範囲を広げるインクリメンタルなテストが望ましい。

複雑なインターフェースのリスク分析

複雑なインターフェースに対しては、リスク分析を行うことで統合テストのどこに焦点を当てるべきかのあたりをつけることが効果的。

継続的インテグレーションで自動化

統合の範囲が大きくなるほど、欠陥の特定が難しくなり、リスクが増えてトラブルシューティングの時間が増大する。
そのため、継続的インテグレーションにより統合テストの自動化を行うことが普及しつつある。

次回

テストレベル - システムテスト(記事書いたらリンク貼る)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?