システム統合テストでの私の個人的な経験を共有したいと思います。 私たちのチームは、銀行内のすべてのシステムを接続する統合レイヤーを開発しています。 私たちには多くのタスクがありますが、十分な時間はなく、統合テストの問題は常に延期されています。
統合テストはどのように進行していますか？ Oracle Service Bus （OSB）統合バスを介して通信する100以上のシステムがありますが、最短の答えはありません。 この製品には、テスト要求を送信し、受信した応答を表示できるOSBコンソールツールがあります。 開発者がバスに新しいサービスを実装した後、サービスはOSBコンソールを介して手動でチェックされます。 チェックが成功すると、サービスは機能していると宣言され、外部システムの開発者がそれについて苦情を申し立てた場合にのみ変更されます。
使用していたOSBのサポートは間近に迫っていたため、新しいバージョンにアップグレードする必要がありました。 移行自体は大きな問題を引き起こしませんでしたが、疑問が生じましたが、移行されたソリューションの操作性を確認する方法は？ そして、ここで私たちのチームは再び自動テストの導入を考えました。
想像してみた
写真はシンプルで、誰もがすぐに気に入った。
実際、手で行うことを自動化するだけです。 それでは、メッセージのペア（リクエスト、レスポンス）を保存するテストを作成しましょう。 開始後、テストはリクエストを送信し、レスポンスを受信して、保存されている回答と比較します。 回答が一致した場合、テストは成功しました。
サービス仮想化（モック、スタブ）
疑問が生じ、バックエンドシステムとして私たちの環境で何を使用するのでしょうか？ 明らかに、実際のバックエンドシステムはいくつかの理由で適切ではありません。
- テストでは、特定のデータセットで動作するシステムが必要です。 アカウント残高を返すサービスがどのように機能するかをチェックするとします。 このようなテストでは、指定された番号のアカウントが存在し、サービスが特定の値を返す必要があります。 ライブシステムでのテストデータのサポートは、時間のかかるプロセスです。
- システムは、テスト環境ではまったく使用できない場合があります。 または、統合の時点で、サービスはまだ開発中である可能性があります。
- 例外を確認するには、システムがエラーを返す必要があります。
サービスシミュレーターが必要であることが明らかになり、最終的な製品を確認することが論理的に決定されました。
市場にはそのような製品が5つしかないため、見る場所がないことが判明しました。
最初の3つの製品は、ダウンロードして表示できないという理由だけで表示できませんでした。 長いフォームに記入し、営業担当者が私たちに連絡する電話を残しておく必要がありました。一般に、これらはすべて数ヶ月続くことがありました。 原則として、HP Service Virtualizationもこのグループに分類されますが、この製品はすでに当社から購入されていることが判明しました。 しかし、1週間の苦労の後、それを使用しても機能しないことが判明しました。 この製品にはオープンAPIがなく、ビジュアルエディターを使用して数千のサービスを作成するのは非現実的です。 HPの広報担当者は、サービスは手動でしかクリックできず、自動化については考えていないと述べました。
Webアプリケーションとしてモックサービスを起動できるSoap UIに大きな期待が寄せられました。 しかし、SOAP UIは実際には「UI」であることが判明しました。 第一に、スレッドセーフではありません。第二に、大量のメモリを使用し、不安定です。
調査の過程で、私たちの銀行にはすでに4つの（！）Webサービスの自己記述型シミュレーターがあることが判明しました。 それらの1つは非常に個人的なものであることが判明し、基礎として必要に応じて追加されました。 そのため、テスト環境では、特定のHTTP要求に対して特定のHTTP応答を返すWebアプリケーションであるシミュレーターを取得しました。
各仮想サービスはMavenプロジェクトです。 プロジェクト構成（service-descriptor.xml、response-selector.xml）には、HTTP要求に基づいて、どのサービスが呼び出されるか、どの操作が必要か、どのルールでHTTP応答を返すかを決定する方法が記述されています。
ソースコードを変更すると、プロジェクトはJenkinsで自動的にビルドされ、mavenワゴンを使用して、実行中のシミュレータアプリケーションにデプロイされます。
そして今、私たちはテストを書いています
次のステップは、実際にフロントエンドシステムシミュレーターになるテストを作成することです。 つまり、Webサービスクライアントを作成する必要があります。
私たちのテストはMavenプロジェクトです。 プロジェクト内には、実際にはソースであるファイルのペア（要求、応答）があります。 プロジェクトのビルドは、汎用のMavenプラグインがWebサービスを呼び出し、テスト要求をそれに渡し、応答を受信し、それをテストの回答と比較することです。
Jenkinsでは、テストが毎晩自動的に実行されます。
テストデータ作成
主なタスクは移行をテストすることであったため、テスト要求と応答は監査データベースからエクスポートされ、本番環境で機能します。 これらのデータによると、対応するMavenプロジェクトが生成されました。
新しいサービスの開発の場合、生体システムからのデータはまだありません。 そのような場合のために、Eclipseに基づいた独自のツールを作成しました。 数回クリックするだけで、新しいプロジェクトを作成し、テストデータを入力し、バージョン管理システムに配置して、Jenkinsで新しいプロジェクトを作成できます。
どうした
もちろん、10年にわたって作成された統合レイヤーをテストで完全にカバーすることはできませんでした。
- すべてのバックエンドシステムがWebサービスを介して機能するわけではなく、他のプロトコル用のアダプターが必要です。
- 1つのサービスではなく、ビジネスプロセス全体をテストするための要件があります。 この場合、複数のサービスの一貫したデータセットを保存する必要があります。
- バックエンドでできることをすべてサポートするシミュレーターを作成するのは非常に多くの作業です。 RESTサービス、非同期メッセージ、およびさまざまな認証方法をサポートすることはできませんでした。
最も重要なことは、実装されたテストが、移行中に発生するはずのエラーを検出したことです。 また、原則として機能せず、使用されなかったサービスもいくつか見つかりました。 だから私たちの経験は間違いなくポジティブです！
今後の計画
私たちはそれが好きで、私たちは続けます。 近い将来、JMSのシミュレーターを追加し、ビジネスプロセスをサポートし、パフォーマンステストの実施方法を考え出す予定です。
統合をテストしますか？ あなたの経験を共有してください！