Postmanを導入してAPIテスト効率をUPした話
株式会社dott / TomiGie
メンバー / バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名
利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|---|
Freeプラン | Collection, Environment | 10名以下 | 2019年 | B to B |
導入の背景・解決したかった問題
導入背景
Postman導入前の課題
導入前の課題としては以下の2点がありました。
- APIリクエスト作業の冗長化
- APIのリクエスト先の切り替え
⏳ APIリクエスト作業の冗長化
Postman導入前、OpenAPI(Swagger)を利用しており、APIをテストする時などはそこで行っていました。 OpenAPIでAPIのリクエストをする場合、以下の手順を踏む必要がありました。
- 管理者もしくはユーザーアカウントのログインAPIにリクエストし、アクセストークンを取得
- 取得したアクセストークンをコピーし、OpenAPIのAuthorizeパラメータにセット
- テストしたいAPIにリクエスト
そして、この手順を踏むために毎回リクエストボディをデフォルトの状態からテスト用の値へ書き換える作業が発生します。
これが単発のテストであれば気にする程でもない手間ですが、何十何百とこの作業をする事になるので、無視できない作業量になることが多いです。
🔄 APIリクエスト先の切り替え
担当の案件では、開発・ステージング・本番環境の3環境があり、その環境ごとにOpenAPIがサーバーレス環境にデプロイされて利用できる状態です。そのため、各環境のAPIのテストをするためにはそれぞれのデプロイ先の環境(OpenAPI)にアクセスをして、前述の操作を行う流れになります。
なので、一度テストをした環境とは別環境でテストを行う場合、再度別の環境(OpenAPI)にアクセスする必要があり、また1からリクエストの値を取得・設定をして実行する手順を踏む必要があります。
これも繰り返しの作業が増えると、無視できない作業時間になることが多いです。
どのような状態を目指していたか
前述の課題2つを解決し、繰り返しのAPIテストにおけるリクエスト作業の効率化を図ることを目指すべく、以下の要件をクリアすることを目標としました。
- 冗長化した操作を共通・自動化 → データの取得作業を省いて作業効率UP
- リクエスト内容を保持 → 最新のリクエスト内容を保持することで作業効率UP
- リクエスト内容をパターン化(テンプレート化) → リクエストボディの内容をパターン化し、変更作業の省略で作業効率UP
- リクエスト先の切り替えの簡略化 → 環境切り替え・リクエスト値の再設定作業の省略で作業効率UP
比較検討したサービス
OpenAPI(Swagger)
比較した軸
課題の解決の部分でも上げましたが、以下の要件がクリアできることを重要視していました。
- 冗長化した操作を共通化・自動化できる
- リクエスト内容を保持できる
- リクエスト内容をパターン化(テンプレート化)できる
- リクエスト先の切り替えが簡略化できる
選定理由
ツールが使いやすいという大前提に加えて、重要視する点で上げた要件を満たす機能を持っている点が一番の決め手になりました。
導入の成果
改善したかった課題はどれくらい解決されたか
結果から言いますと、以下の課題は全て解決できたと思います。
- 冗長化した操作を共通化・自動化できる
- リクエスト内容を保持できる
- リクエスト内容をパターン化(テンプレート化)できる
- リクエスト先の切り替えが簡略化できる
どのような成果が得られたか
全体的にAPIリクエストを行うための手順が削減できたため、APIテストの際の作業効率が上がりました。
導入時の苦労・悩み
課題を解決するためのCollectionの構成を設計する部分ですかね。 ここは苦労したというか、時間をかけて試作・改善していった部分になります。
導入に向けた社内への説明
上長・チームへの説明
最初は個人的にAPIのテストで導入するところから始めたため、この時点での説明は行っていませんでした。
個人で導入後、以下の段階を踏まえて最終的にチームへのPostmanの導入の相談を行いました。
- 個人で色々とCollectionの構成を試してみてある程度運用方針を固める
- 実際にAPIのテスト等で個人運用してみて、従来のAPIテストよりも作業効率が上がるという材料を集める
- 材料が集まったらチームメンバーに共有し、導入すべきかフィードバックをもらい判断する
また、費用に関する説明については、当面はFreeプランで事足りる利用想定だったため特にこの点の説明は行っていません。
活用方法
普段は担当案件のチーム内で、開発・修正した機能のレビューをする際に、APIのテストツールとしてリクエストやレスポンスの確認などで利用しています。
どの様に設計したかは、以下の記事にまとめていますのでよろしければご覧ください。
ぼくのかんがえたさいきょうのPostmanかんきょう
よく使う機能
- Collection(APIリクエスト)
- Environment(API実行環境の切り替え)
ツールの良い点
- Collection, Environmentのインポート/エクスポート
- ユーザー間でのデータの移行が容易
- アカウントにCollectionのデータが紐づいている
- PCを移行しても今まで利用していたCollectionの環境をすぐに利用できる
- コードスニペット
- 各言語でのAPIリクエスト処理を動的に生成してくれるため、知識が浅い言語を扱う場合にとても役に立つ
- Scripts
- APIの実行前後に実行するスクリプトをカスタマイズできる
- モックサーバー
- モックサーバーを作成すると指定のパスに対するリクエスト/レスポンスパラメータを設定することが可能
- バックエンドの実装を待たずにフロントエンドの開発を行う事ができるので、開発効率アップが望める
- Postbot
- Scriptに組み込むテストスクリプトをプロンプトを指定して自動生成できる ←これおすすめ
ツールの課題点
- 4人以上のチームで同じワークスペースを利用する場合、有料プランの契約が必要となる
ツールを検討されている方へ
Postmanの導入(特にチームでの導入)を検討する際は、段階的なアプローチをするのが良いと思います。
具体的には、チーム内の各メンバーが個人でワークスペースを作成し、Collectionなどの操作感を確認することにより、ツールの使用感を低コストで把握できます。
次の段階として、チームでの共用ワークスペース利用を検討します。この段階を踏むことでチームでの利用効果をより具体的に評価できるでしょう。
なお、Postmanには既存のCollectionをインポート/エクスポートする機能があるので、有用なCollection構成ができた場合、ファイル形式でチーム内への共有が可能です。
このアプローチにより、4人以上で必要となる有料プランへの移行を急ぐことなく、段階的かつ効果的にPostmanを導入できます。チームのニーズに合わせて柔軟に対応しながら、ツールの価値を最大限に活用することができると思います。
また、ここ最近だとPostman以外にもApidogやThunderClientなどのツールもよく見かけるようになりましたので、用途に合ったツールを選んで行くのが良いと思います。
今後の展望
今後やりたい事として漠然としたイメージですが、以下をやれたらいいなと思っています。
- 簡易的なユニットテスト
- Postmanプラットフォームで自社サービスのAPIの公開
- APIドキュメントをPostmanで一元管理
1. 簡易的なユニットテスト
PostmanにはAPIのレスポンスに対してテストスクリプトを実行する機能があります。 それを利用して、特定のAPIのリクエストパラメータやレスポンスパラメータの仕様変更が発生していないか検知する仕組みを作りたいです。
テストを実行するタイミングとしては、開発時に手動でテストを実行する場合と、プルリクエストを作成した際にGitHub Actionsに埋め込んで、アプリケーションのデプロイ時にテストを自動で実行するケースを想定しています。
2. Postmanプラットフォームで自社サービスのAPIの公開
今後dottでも自社サービスとして何かしら外部にAPIを公開する機会が出てくるかもしれません。
その際に、PostmanプラットフォームでAPIのCollectionを公開してみたいなと思っています。
PostmanプラットフォームにAPIを公開する事で、Postman利用者は公開されているAPIのCollectionを簡単にインポートすることが可能になるため、dottのAPIを利用していただく開発者の方にとって便利になりそうだなと思っています。
3. APIドキュメントをPostmanで一元管理
2と理由が重なる部分がありますが、PostmanのCollectionを設定すると半自動的にAPIのドキュメントを作成してくれるため、APIの仕様が変更になった場合もドキュメント更新がおざなりになる課題を改善できそうという点が1つ。
後は、これも外部にAPIを公開する場合に一緒にこのドキュメントも公開することが可能なので、よりAPIの利用者に親切なサービスにできそうなのでやってみたいというところです。
株式会社dott / TomiGie
メンバー / バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名
よく見られているレビュー
株式会社dott / TomiGie
メンバー / バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名