パズルのピースを力技で無理に押し込むのはやめようね〜テストレベル Part3
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
最近、変な夢を見て夜中に目を覚ますことが多くて寝不足気味なんだ。
ライブ前のアイドルがゲーセンで遊んでて、「間に合わへんくなるよー！」と勝手な心配をした所で目を覚ますとか、悪夢とかじゃなく何か意味わかんない系だね。
良い子のみんなは早寝早起き朝ご飯で健康的に過ごしてね。
さて、そろそろ本題のテストレベルの続き、統合テスト（結合テスト）のお勉強をしていくよ。
統合テストの目的
• リスクの軽減
• インターフェースの機能的/非機能的振る舞いが設計および仕様通りであることの検証
• インターフェース品質に対する信頼の積み上げ
• 欠陥の検出(インターフェース自体、コンポーネントに内在、またはシステムに内在)
• 欠陥がより高いテストレベルまで見逃されることの防止
シラバスでは統合テストには2つの異なるレベルがあると解説されているよ。
• コンポーネント統合テスト
統合するコンポーネント間の相互処理とインターフェースに焦点をあててテストする。
• システム統合テスト
システム、パッケージ、マイクロサービス間の相互処理とインターフェ ースに焦点をあててテストする。
外部組織(Webサービスなど)との相互処理、または外部組織により提供されるインターフェースをカバーすることもある。
外部組織が作るシステムとかは開発側の組織で制御できない場合もあって、テストをブロックする欠陥が外部組織のコードに存在したり、テスト環境の調整などの課題が発生する場合があるよ。
システム統合テストのタイミングはシステムテストの後、またはシステムテスト実行と並列して行うのが良いとされているんだ。
テストベースとテスト対象
テストベース
統合テストでテストベースとして使用できる作業成果物の例:
• ソフトウェア設計とシステム設計
• シーケンス図
• インターフェースと通信プロトコルの仕様
• ユースケース
• コンポーネントレベルまたはシステムレベルのアーキテクチャー
• ワークフロー
• 外部インターフェース定義
テスト対象
統合テストの典型的なテスト対象の例:
• サブシステム
• データベース
• インフラストラクチャー
• インターフェース • API
• マイクロサービス
コンポーネントテストでは一つのコンポーネントに対しての細かい処理が記載されたテストベースを元にしていたけど、複数のコンポーネント同士で処理を行う内容、処理の方法やデータのやり取り、ユーザーの使用する想定（ユースケース）、システムの構造が分かる資料などのテストベースを使用してテスト対象の範囲も広くなるんだ。
見つけておきたい典型的な欠陥と故障
コンポーネント統合テストの典型的な欠陥と故障の例:
• 正しくないデータ、データ不足、正しくないデータエンコーディング
• インターフェース呼び出しの正しくない順序またはタイミング
• インターフェースの不整合
• コンポーネント間のコミュニケーション故障
• コンポーネント間のコミュニケーション故障の処理不在、または不適切な処理 • コンポーネント間で渡されるデータの意味、単位、境界の正しくない思い込み
システム統合テストの典型的な欠陥と故障の例:
• システム間で一貫性のないメッセージ構造
• 正しくないデータ、データ不足、正しくないデータエンコーディング
• インターフェースの不整合
• システム間通信による故障
• システム間通信処理不在、または不適切な処理による故障
• システム間で渡されるデータの意味、単位、境界の正しくない思い込み • 必須のセキュリティ規制への非準拠
コンポーネントかシステムかの違いで見つけておくべき欠陥は似たような観点と言うことになるね。
アプローチと責務
コンポーネント統合テストとシステム統合テストは、統合だけに焦点を絞ってテストを行うのを前提としているよ。
コンポーネントやデータベース自体の処理はコンポーネントテストで確認済みだったり、システムテストで個別システムの機能がテスト対象の場合、個別の処理やシステムの機能ではなく統合した部分のデータのやり取り、処理と処理の間にある連結部分の動作確認を行うんだね。
ネットショッピングとか予約サイトの会員登録の流れで言えば、データを届けるインターフェースがデータをちゃんと届けられるかどうか？書き込まれたデータをシステムの画面に表示できるか？と言うポイントになるよ。
図の中の緑文字はコンポーネントテスト範囲だね。
この図では省いたけどデータベースからデータを取り出して会員情報の画面へデータを届ける人（インターフェース）もあるよ。
欠陥と故障のポイントも説明しておくね。
二つともDBに会員データが入らないと言う故障だけど欠陥の場所が違うからどのテストレベルで検出するのが妥当かという違いがあるんだ。
インターフェースの途中の欠陥で故障になるのは統合テストで見つけるべき欠陥と故障になるよ。
コンポーネントテストで見つけるべき欠陥からの故障が統合テストで検出された場合、（心の中だけで）コンポーネントテストの内容が甘かったんやねー？と、じと目で開発担当を見てあげようね。
目的の部分でコンポーネント統合テスト、システム統合テストがあると書いたけど、一般的にコンポーネント統合テストは開発担当者が実行、システム統合テストはテスト担当者が実行するとされているよ。
またシステム統合テストを実行するテスト担当者はシステムアーキテクチャーを理解して統合計画の作成に関与するのが推奨されてるから開発担当者にしっかりお話を聞いてシステム統合テストに取り掛かろうね。
今回は統合テストが2つのレベルに分かれること、コンポーネントテストと比較してテストベース、テスト対象がどう違うかの把握、コンポーネントテストやシステムテストと被る範囲は除外してコンポーネント間やシステム間の統合箇所に焦点を当てると言うポイントを押さえておこうね。
次はシステムテストのお勉強をしようね。
では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？