マイクロサービス上に構築されたアプリには多くの利点があるが、新しいテストアプローチが必要
ソフトウェア・アーキテクチャは過去30年の間に大きく進化し、ソフトウェア・テストのアプローチもそれに合わせて変化してきた。 ここでは、NashTechのシニアテストチームマネージャーであるVinh Phamが、今日のマイクロサービスベースのアプリをテストするためのベストプラクティスのアプローチについて説明します。
モノリシックからマイクロサービスへ - テストの課題
ソフトウェア・アーキテクチャは常に進化している。1990年代のスパゲティのようなデザインから、2000年代初頭にはラザニアのようなレイヤード・アーキテクチャに移行した。 今日、これらのアーキテクチャは、ソースの中に浮かぶ小さなパッケージ（「マイクロサービス」）のようなラビオリのようなものだ。
マイクロサービス・アーキテクチャは、ソフトウェア・アプリを、定義されたAPIを使用して相互に通信する、より小さなサービスのスイートとして構築することを可能にする。 従来の「モノリシック」なアーキテクチャと比較して、マイクロサービス・アーキテクチャは、異なるプログラミング言語やテクノロジーを使用してアプリを構築する柔軟性を提供する。 また、スケーラビリティも向上し、継続的インテグレーションとデプロイメント（CI/CD）やDevOpsアプローチに適している。
しかし、どんな新しいアーキテクチャでもそうであるように、テストには新しいアプローチが必要である。 マイクロサービス・アーキテクチャの場合、テスト戦略は、サービスの通信方法、各サービスのセキュリティ、データの一貫性、各サービスが他のサービスに与える影響などの側面をカバーしなければならない。 機能テスト、非機能テスト、各プロジェクトに合わせたツールを組み合わせる必要がある。 そして、コンポーネント・サービスを個別にテストし、システム全体の挙動をテストすることをサポートしなければならない。
マイクロサービス・アーキテクチャはまた、多くのテストの課題をもたらす。 テストケースを正しく書くためには、各サービスを深く理解する必要がある。 また、各サービスがどのようにあるべきかを明確に理解する必要がある：
- 単独走行
- 他のサービスと連携してアプリを構成する
使用中の各APIエンドポイントには明確なリクエスト／レスポンスがあり、サードパーティのアプリやパートナーからのサービスを実行できるようになっていなければならない。
5層のテスト
マイクロサービスベースのアプリが正しく動作していることを検証するために、ユニットテスト、統合テスト、コンポーネントテスト、コントラクトテスト、エンドツーエンドテストからなる5層アプローチを適用する。
ユニットテスト
サービスの最小単位（アプリのテスト可能な最小部分）が、クラスレベルまたはプログラマーによって定義された関連クラスの小さなグループのレベルで、期待通りに実行されているかどうかを理解できるようにする。 ユニットテストは次のように分けられる：
- 単独テスト – モックやスタブなどのテスト・ダブルを使用することで、コンポーネントの依存関係をすべて取り除くことができる。
- ソシアブル・テスト – コンポーネントの外部動作をテストする。
コンポーネント・テスト
アプリの各部分（コンポーネントまたはマイクロサービス）を分離してテストすることで、マイクロサービスベースのアプリでしばしば見られる複雑さを回避する。 各コンポーネントを単独でテストし、その依存関係を他のサービスのテスト・ダブルやモックアップを使って置き換える。 コンポーネント・テストは、マイクロサービスのテストをより簡単に、より速く、より信頼できるものにするのに役立つ。
統合テスト
コンポーネントやマイクロサービス間の通信経路や相互作用を実行し、依存関係が正しく機能していることを確認する機会を提供する。 私たちは、ボトムアップ、トップダウン、またはサンドイッチ/ハイブリッドアプローチを使用して、マイクロサービスがビジネス要件を満たすためにスムーズに連携していることを検証することができます。
契約テスト
マイクロサービスの明示的・暗黙的なコントラクトが広告通りに機能するか検証できる。 2つの視点がある：
- コンシューマ – マイクロサービスを利用するエンティティ
- プロバイダー – サービスを提供する主体
契約書のテストは、契約書の宣伝通りに物事が動くかどうかを確認することに重点を置いている。 これは、APIを介して転送されるデータの属性やフォーマット、そしてレスポンスを検証することを意味する。 これは、APIエンドポイントのコードが期待通りに実行されることを保証する。 さらに、コンシューマー・コントラクト駆動型テストを使って、コンシューマー・ワークフローのバグを発見することもできる。
エンド・ツー・エンド・テスト
アプリの全プロセスと全ユーザーフローをテストし、ビジネスプロセスが正しくスムーズに機能し、要件を満たしていることを確認することを目的とする。 すべてのサービスとデータベースの統合が含まれています。
マイクロサービスベースのアプリのすべての可動部分は、エンドツーエンドのテストでカバーされる。 また、サービス間のギャップをカバーし、マイクロサービス間の依存関係を確実にテストする。
セキュリティとパフォーマンスのテスト
5つの主要なテストレイヤーに加え、特にマイクロサービスアプリでサードパーティのサービスが使用されている場合、データ転送におけるAPIのリクエスト/レスポンスが安全であることを確認するためにセキュリティテストを実施します。
アプリは、分離されていながらも互いに依存し合う複数のサービスから構築されるため、パフォーマンステスト（または「負荷テスト」）はマイクロサービスアーキテクチャにおいて必要である。 アプリには、外部環境のサードパーティ・サービス（PaaS）が関わることが多い。 これらがうまく機能しないと、アプリ全体のパフォーマンスに大きな影響を与える可能性がある。
テスト自動化
マイクロサービス・ベースのアーキテクチャでは、自動化はテストにおいて重要な役割を果たす。 自動化により、インクリメンタルリリースやサービスAPIバージョンの更新を通じて、リグレッションテストを各テストレイヤーで迅速かつ容易に実施し、アプリ全体が正しく動作していることを保証することができます。
テスト自動化への投資対効果は、アプリのアーキテクチャの仕様と変更頻度に依存する。 統合レイヤーのテストにPostmanやSoapUIのようなツールを使うことは利点になる。
もっと知りたいですか？
NashTech ソフトウェア・テスト・サービスの詳細については、info@nashtechglobal.comまでメールでお問い合わせください。
おすすめ記事
THE OUTがプレミアムレンタカー業界をどのように破壊するか
ベトナムのナッシュテック開発チームと緊密に協力し合うことで、高品質でデジタルファーストの高級レンタカーサービスを構築することができた。 将来を見据えて、THE OUTは製品ロードマップに注力し、旅行代理店やコンシェルジュ・パートナーを含むB2B顧客へのサービスを拡大し、そのための新しいポータルを構築している。
オーストラリアで設立された広告・メディア費ビジネスは、ナッシュテックの支援により、いかにして駆け出しのビジネスから世界的な大企業へと成長したのか？
オーストラリアで設立された広告・メディア支出企業は、現在世界的な事業展開をしており、ナッシュテックがその成長を支えていることを知っている。
- トピックス