GENZ, Inc.

第三者検証サービス API管理ツールのゲートウェイ設定から呼び出しまでをテスト

API管理ツール導入後の自社の設定を検証対象とするテストです。ゲートウェイの設定から呼び出しまでを第三者が検証し、稟議や監査で使える証跡を残します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

API管理ツールでよくある不具合

APIゲートウェイの設定ミスは、公開中のAPIへそのまま波及します。変更のたびに影響範囲を洗い出し直す体制では見落としが残り、利用側の画面や連携先の処理で初めて表面化する不具合が起きます。

流量制御の上限値が意図と異なり、正常な呼び出しが拒否される

上限値の設定が利用プランの意図と合わないと、契約内の呼び出しまで拒否され、連携先の処理が停止して手作業での対応となります。

流量制御

権限設定の漏れで、権限のないトークンでもAPIが通る

スコープやロールの設定漏れがあると、権限のないトークンや期限切れのトークンでもAPIが呼び出せてしまい、監査で証跡を提出できない状態になります。

認証認可

変換設定の不備で項目欠落や文字化けが起きる

変換ポリシーの不備でレスポンスの項目が欠落したり文字コードが崩れたりすると、利用側の取り込み処理が失敗し、原因の切り分けに時間がかかります。

変換ポリシー

API定義と実挙動がずれ、利用側が想定外のエラーになる

API定義と実際のレスポンスが一致しないと、利用側の実装段階で想定外のエラーが起き、個別の問い合わせ対応となって設定の根拠が文書に残りません。

API定義

経路設定により旧バージョンの呼び出しが新処理へ転送される

経路設定の誤りで旧バージョン宛の呼び出しが新しい処理へ転送されると、利用側へ予告のない仕様変更となり、業務データの不整合が発生します。

ルーティング
02 RISK

残存した不具合により生じる問題

見落とした不具合は検証の場ではなく、公開後の運用の場で問題へ変わります。放置した場合に生じる事業上・企業上の損失を、三つの局面で整理します。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

静的テスト(レビュー)でおさえるべき観点

API管理ツールの検証は、実行を伴うテストの前に、設計書と設定値、公開ドキュメントを突き合わせるレビューから始まります。この段階で見つかる不整合は設定値の修正で済み、公開後の手戻りを防げます。

照合しないまま公開すると、定義どおりの呼び出しが正しい経路へ届かず、利用側の実装段階で差し戻しが発生するおそれがあります。

API定義とゲートウェイのルーティング設定の照合

API定義に記載した経路とメソッドを、ゲートウェイのルーティング設定と漏れなく突き合わせます。定義と設定の不整合は、公開後に利用側の実装段階で初めて表面化します。

確認する資料
  • API定義書
  • 経路設定一覧
  • 公開API一覧
権限の定義とポリシー設定の不一致を見落とすと、権限のない呼び出しの通過や、正規トークンの拒否が本番で発生するおそれがあります。

認証認可方式の設計と権限設計(スコープ・ロール)の照合

採用する認証認可方式(APIキー・トークン検証・相互TLSなど)の設計と、スコープ・ロールの定義をポリシー設定と照合します。定義と設定が不一致だと、正規の利用者の呼び出しが拒否されます。

確認する資料
  • 認証方式設計
  • 権限設計書
  • スコープ定義
上限値と処理能力の対応を確認しないと、制限内の呼び出しでタイムアウトが発生し、ゲートウェイ側とバックエンド側の切り分けに時間を要するおそれがあります。

流量制御の設定値とバックエンドの処理能力要件の照合

レート制限とクォータの上限値を、バックエンドの処理能力要件と突き合わせます。上限値が処理能力を上回る設定では、制限内の呼び出しでもタイムアウトが発生します。

確認する資料
  • 上限値設定表
  • 性能要件書
  • 負荷試試験結果
エラー仕様とガイドの不一致を残すと、利用側でエラーを処理できず、同じ説明を利用者ごとに繰り返す問い合わせ対応が発生するおそれがあります。

エラーレスポンスの仕様と利用側の実装ガイドの照合

認証エラーや上限超過時のエラーレスポンスの仕様を、利用側へ配布する実装ガイドと照合します。仕様とガイドの不一致は、解釈違いと実際の不具合の混在した問い合わせを生みます。

確認する資料
  • エラー仕様書
  • 実装ガイド
  • 応答サンプル
手順書と公開ドキュメントの不一致を残すと、予告のない変更が適用され、連携先の業務が停止するおそれがあります。

バージョン追加・廃止の手順書と公開ドキュメントの照合

バージョン追加・廃止の手順書と、利用者へ公開するドキュメントの記載内容を照合します。予告の内容と実際の変更が一致しないと、連携先の処理が停止し、手作業での対応となります。

確認する資料
  • 変更手順書
  • 公開手順書
  • 廃止予告文
  • 利用者通知
04 TEST DESIGN

動的テストの設計・実行のポイント

ゲートウェイの設定変更が波及するAPIを特定し、優先順位を付けて検証します。検証範囲の確定から回帰テストまで順に進めます。

STEP 01 検証範囲の確定波及範囲の一覧が承認の根拠になります
どう確かめるか

API一覧と変更範囲を洗い出し、検証範囲とテスト計画を確定する

公開中のAPI一覧とポリシー設定を突き合わせ、変更が波及するAPIを特定します。対象と検証の深さを確定し、テスト計画へ反映することで、承認の場で範囲の根拠を説明できる状態にします。

  • 01API一覧とポリシー設定の突き合わせ
  • 02変更が波及するAPIの特定と優先順位付け
  • 03検証範囲とテスト計画の確定
OUTPUT検証範囲とテスト計画
STEP 02 テスト設計と項目書作成境界値の項目が不整合の検出に直結します
どう確かめるか

同値分割と境界値でパラメータと上限値のテスト項目書を作成する

認証キーやクォータの上限値など、ポリシーの設定値を同値分割と境界値で整理します。境界値の前後で挙動が切り替わる地点を項目化し、API定義と実際のレスポンスの不整合を公開前に検出します。

  • 01パラメータの同値分割と境界値の抽出
  • 02認証方式とクォータ上限値の項目化
  • 03API定義と実挙動の照合項目の作成
OUTPUTテスト項目書
STEP 03 ユニットテストと統合テストの実行異常系の結果が原因の切り分けを早めます
どう確かめるか

単体と結合の両面で正常系・異常系を検証する

ポリシーごとのユニットテストと、ゲートウェイからバックエンドまでの統合テストを実施します。認証エラーやタイムアウトなどの異常系を意図的に発生させて検証し、切り分けの手がかりを残します。

  • 01ポリシーごとのユニットテストの実行
  • 02バックエンドまでの統合テストの実行
  • 03異常系を意図的に発生させて検証
OUTPUT不具合票と検証結果
STEP 04 パフォーマンステストと回帰テスト数値でリリース判断の材料を示せます
どう確かめるか

流量制御のパフォーマンステストと既存APIの回帰テストを実施する

流量制御の上限値に負荷を掛け、応答時間とエラー率が許容範囲に収まるかを検証します。既存APIには回帰テストを実施し、変更前と同じ挙動を保つことを確認してからリリース判断へつなげます。

  • 01上限値への負荷によるパフォーマンステスト
  • 02既存APIの回帰テストの実施
  • 03結果の集約とリリース判断材料の整理
OUTPUT性能と回帰の報告書
05 RATIONALE

GENZが代行するAPI管理ツールのテスト

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 検証範囲をAPIとポリシーの対応表として整理します
  • 異常系と境界値のテスト観点を項目書として標準化します
  • テスト設計から実行・不具合票の管理まで第三者が代行します
  • 検証の範囲と費用の対応を書面でご提示します
06 SERVICE

定義とポリシーから組み立てる第三者検証

API管理ツールの検証は、貴社が設定したAPI定義とポリシーを対象として組み立てます。GENZがテスト設計から実行・不具合票の管理・報告までを第三者の視点で担い、リリース判断と監査に使える証跡を残します。

SVC 01

API定義を起点にテスト設計

API定義とポリシー設定を読み合わせ、同値分割と境界値でテスト項目を設計します。認証認可の異常系や流量制御の上限値も項目化します。

リスク要因と優先順位を示す無文字の図解。
SVC 02

連携先の呼び出しまで検証する

ゲートウェイ単体の挙動にとどめず、連携先システムへの転送やトークン検証をまたいだ呼び出しを実行し、設定どおりに動作するかを検証します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

既存の開発・リリース体制に合わせて伴走する

スプリントや受け入れ日程に合わせて検証工程を組み込みます。製品更新のたびの回帰テスト範囲も定型化し、繰り返し使える形で残します。

計画から報告までの流れを示す無文字の図解。
SVC 04

判断と監査に使える報告書と証跡

テスト項目書・不具合票・報告書を、稟議と監査の説明に使える形式で提出します。実装側の自己検証とは別に、第三者が検証した事実が残ります。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご相談から納品までの流れ

現状のAPI構成の聞き取りから報告書の納品まで、成果物をご確認いただきながら順に進めます。

現状のAPI構成と課題のヒアリング

ゲートウェイ方式と公開中のAPI一覧を確認し、検証範囲を整理します。

テスト設計と見積もりのご提示

整理した範囲をもとにテスト項目の案と必要工数を示し、見積もりをご提示します。

テストの実施と結果の共有

合意したテスト項目書に沿って検証し、不具合票と進捗を開発チームと共有します。

報告書の納品と修正後の再確認

結果を報告書にまとめて納品し、修正後の確認でリリース判断の材料を揃えます。

検証範囲と優先順位の整理から始められます

API管理ツールの検証範囲と優先順位をGENZにご相談ください

API管理ツールの設定検証をご検討の企業様へ。対象APIごとのテスト範囲の切り分けと優先順位、必要工数の考え方を整理してお返しします。そのまま稟議の材料としてお使いいただけます。