はじめに

DXの実現やシステムのモダナイゼーションでAPI開発やAPIを利用する動きが加速しています。この記事では、APIを利用するアプリケーションのテスト課題と最適なテスト戦略について紹介します。

次のような方におすすめです。

• これからAPIを利用するアプリケーションの開発案件に関わる方
• すでにAPIを利用するアプリケーションのテスト計画や実施に携わっている方

API連携のメリット

API(Application Programming Interface)を活用したアプリケーション同士の連携を「API連携」と呼びます。Webアプリケーションからのリクエストに対し、機能やデータを提供するバックエンドのAPIがレスポンスする連携に加え、バックエンド同士がAPI連携でつながるケースなどさまざまです。

システムのモダナイゼーションでは、API GW(ゲートウェイ)の導入やAPI基盤を開発することで、レガシー機能が提供するデータを利活用する取り組みが行われています。ビジネス要件に素早く対応するためには、各機能をAPI化することで開発を高速化できるメリットがあります。

次の図はショッピングサイトにおけるAPI連携の例になります。ユーザー体験(操作)からバックエンドとのAPI連携が発生し、システムが動きます。

昨今のDX(Digital Transformation)の加速により、API連携は増加しており、現在、22,000を超えるAPIが公開されていると報告されています。一般公開(B2CまたはB2Bで公開)するパブリックAPI以外にも、公開範囲を限定したプライベートAPIがあり、その数は数百万とも推定されています。また、パブリックAPIの数は年々増加傾向にあり、API連携を伴うシステム開発は今後も増え続けることが予想されます。

• パブリックAPI：他の企業に対して提供しているAPI
• プライベートAPI：企業内でのみ利用するAPI

API連携が注目を集めている理由には、主に次のメリットがあります。

メリット1：新しいサービスの提供を容易にする

パブリックAPIを利用すると、他社の独自サービスが部品として利用可能になるため、アプリケーション開発の際に、自社の既存サービスと他社サービスを組み合わせた新しいサービスを提供可能になります。プライベートAPIにおいても、同様な効果を期待できます。

メリット2：開発の高速化とコスト削減を可能にする

パブリックAPI、プライベートAPIともに、部品化された機能やデータを利用することで、搭載したい機能を一から開発する必要が無いので、アプリケーション開発のスケジュールを短縮できるといったメリットがあります。また、その結果、開発コストの削減が可能となります。

メリット3：セキュリティ対策を向上させる

自社でセキュリティの高いログイン認証システムを一から開発するよりも、API連携により既存のサービスを利用する方が、高セキュリティで利便性も高いシステムを提供できるケースがあります。

API連携による並行開発のテスト課題

API連携には、メリットもある一方で、「APIを提供する企業やチームへの依存」という課題もあります。何らかの理由でAPIが利用できなくなった場合、API連携を伴うアプリケーションの開発やテストが困難になります。これは、パブリックAPIに限らず、プライベートAPIにおいても、同様な問題が発生します。

たとえば、バックエンドチームのAPI開発が遅延していてAPI連携できないことや、他のチームが共通のAPIを利用するテストを行っている間、自分のチームは、他のチームのテストが終了するまで待たないといけないといったような課題が発生します。

このように、API連携をおこなうアプリケーションの開発やテストにおいては、外的要因で開発やテストが中断するといった課題(デメリット)が発生することを前提としたテスト戦略が必要になります。テストが遅延すると、リリーススケジュール全体にも支障をきたすことになります。

APIを利用するアプリケーションの開発やテストでは、主に次の課題が発生します。

課題1：とにかく待たされる

• バックエンドのAPI開発が遅延していて結合テストできない
• 共通のAPIを使用する他チームのテストが終わるまでテストできない

課題2：十分なテストができない

• APIを提供する他チームや他社との調整が必須で、テストできるタイミング限定される
• 正常系・異常系のバリエーションのある結合テストができない

API連携による並行開発のテスト戦略

API連携による課題を解決するためには、連携先の都合に依存しない、独立したテスト環境(バックエンドの役割を果たす疑似環境)を用意する必要があります。連携先の動作をまねる(エミュレートする)疑似環境を用意することで、API連携先に依存することなくAPIを利用するアプリケーションの開発やテストを実施できます。

たとえば、APIを利用するアプリケーションのテストの際に、APIが利用可能になるのを何日も待つのではなく、数秒、数分でAPIの応答を簡単に設定することができる疑似環境があれば、すぐにテストを実施することができます。

このように、いつでも、何度でもテストをおこなう環境が整っていることは、API連携を伴うアプリケーション開発において、外的要因によるスケジュール遅延を防ぎ、品質を確保するうえで重要なテスト戦略と言えるでしょう。

従来、このような場合、疑似環境としてスタブを開発することが一般的ですが、スタブには次のような課題があります。

スタブの開発やメンテナンスに時間を浪費する・・・

• スタブを開発しても、固定のレスポンス値を返すだけのものではテストのバリエーションが不十分・・・
• バリエーション豊富なテストを可能にするスタブを作るには工数がかかる！また、メンテナンスが大変・・・
• スタブの開発ではなく、そもそも本来の開発やテストに工数を割り当てたい・・・

リクエストの内容に適したレスポンスを返すようにするには、プログラミングでif文やcase文を多用し、レスポンス条件を記述する必要があります。そのため、スタブは必然的に複雑なコーディングとなります。また、開発においてスタブの設計書を作ることはないため、複雑なレスポンス条件の妥当性についての理解を含め、メンテナンスが非常に大変になります。

これらの手間をなくして、豊富なテストパターンやデータのバリエーションに対応可能な高性能な疑似環境(スタブ)を、簡単に、素早く作成し、尚且つ、効率的にメンテナンスする方法はないのでしょうか？

API連携による並行開発をシフトレフトするテストソリューション

APIテスト自動化/仮想化ツール「Parasoft SOAtest/Virtualize」を使用すると、高性能な疑似環境(スタブ)を簡単に構築することができます。これは、本来の開発目的ではない疑似環境の構築工数を削減し、API連携を伴うテストに集中することを可能にします。

主に次の点が自作スタブとの比較ポイントになります。
 

ユースケース	自作スタブ	SOAtest/Virtualizeによる サービス仮想化
疑似環境の構築	プログラミングでスタブを開発	OpenAPI/Swagger、RAML、WSDL、XMLスキーマなどのIF定義ファイルから高性能なスタブを自動生成 トラフィックを記録し、高性能なスタブを自動生成
豊富なテストパターンに対応	スタブの作り込みで工数がかかる if文やcase文の多用で複雑なスタブになる	各APIに対するスタブを組み合わせて、複数の種類のAPIコール(例：検索API、更新APIなど)が発生するシナリオパターンに対応 if文やcase文など、コーディングをしなくともリクエストとレスポンスの関連付けが可能
豊富なテストデータに対応		予めExcelやCSVで用意したデータを一括投入し、データ駆動型のスタブへと素早く拡張 if文やcase文など、コーディングをしなくともリクエストとレスポンスの関連付けが可能
メンテナンス工数	作り込んだスタブは複雑であるため、メンテナンスが大変 スタブの設計書が無いため、後任者に引継ぎが困難。if文やcase文が多用されたコードを読んで理解する必要がある	複雑に作り込まなくても豊富なテストパターンとテストデータのパターンに対応した高性能なスタブを作成できるので、メンテナンスが簡単

Parasoft SOAtest/Virtualizeでは、OpenAPI/Swaggerなどの定義ファイルから疑似環境を構築するだけでなく、API連携でつながるフロントエンドとバックエンド間の通信を記録し、疑似環境を自動生成する機能もあります。開発フェーズに応じて必要となる疑似環境の最適な構築手法が用意されているため、API連携を必要とするアプリケーションの開発やテストを強力にサポートします。Parasoft SOAtest/Virtualizeに関する詳細は、以下のページをご参照ください。

高性能なスタブを作るサービス仮想化ツール「Virtualize」
 

• サービス仮想化でアプリケーションをテスト
• サービス仮想化でパフォーマンス・負荷テスト
• 柔軟なカスタマイズ性

まとめ

この記事では、API利用者の視点からみた、API連携でつながるアプリケーションのテスト戦略についての記事をお届けしました。次の記事では、API提供者のテスト戦略についてお届けします。