【ユーザーのリアルな声】Postman vs EchoAPI：｢環境作成｣から｢自動化テスト｣まで

前回の
「はじめて API リクエストを送ってみた」体験記 に続き、
今回も同じ 新人開発者さん に、API テスト学習の 次の関門 を記録してもらいました。

それが——
「環境作成から自動化テストを最後まで回す」体験 です。

Postman と EchoAPI で、
5 つの API をつなぎ、自動化テストを実行するとき、
体験にどんな違いが生まれるのか？

慣れている人には当たり前の作業でも、
新人にとっては
「自分はいま正しい道を進んでいるのか？」
を常に問い続ける時間になります。

👇

これは、このブログをもとに作った比較動画です。よかったら、ぜひチェックしてみてください！

1. Postman で一通りやってみる

1. 環境を作成する

すべては「一見すると簡単そう」なこの一歩から始まります。

1.環境 → 環境を作成

2.名前を テスト環境 に設定

ここまでは特に問題なし。
当時の正直な気持ちは、

「うん、これは分かる。環境だよね。」

2. 最初の API を開く

1.コレクション 内の 1 つ目の API を開く

GET：/products?page=1&size=10&search=Laptop

2.画面右上で、先ほど作成した テスト環境 を選択

ここまでは、まだ「初心者向け」と言える範囲。
画面は少し複雑でも、自分が何をしているかは分かっていました。

3.環境設定後、そのまま「送信」をクリック

……エラー。

ここで初めて、
あ、API の前に baseURL を付けないといけないんだ」と気づきました。

でも、
どこで設定するのかが分からない。

画面を一通り見回しても入口が見つからず、
仕方なく URL の先頭に {{baseUrl}} を手入力。

すると、
マウスを乗せた瞬間に、ようやく入力欄が現れました。

「最初からここを教えてほしかったな……」
そんな気持ちになりつつ、環境変数を設定します。

環境変数に baseUrl を追加し、以下を入力：

https://dummyjson.com

4. リクエスト送信 → 変数抽出（スクリプト必須）

ここで、初めて本気で詰まりました。

1. スクリプト をクリック
2. Post-response Script を手書きで追加：

var response = pm.response.json();
pm.environment.set("id", response.products[0].id)

正直に言うと、私は JS が分かりません。
このスクリプトも AI に書いてもらっただけです。

問題はそこからで──
中身が理解できない以上、正しいかどうか判断できない。

• 次の API が動かなかったとき
  • API 自体が悪いのか？
  • それともこのスクリプトが間違っているのか？

この瞬間から、
私はもう「API をテストしている」というより、

自分には理解できないスクリプトに賭けて、
全体の流れが動くかどうかを祈っている状態

になっていました。

1. 送信 を押して、変数が本当に環境に保存されたか確認し、そのあと忘れずに 保存。

5. 次の API（2〜5 個目）

2 つ目の API を開いた瞬間、違和感がありました。

さっきコレクションに baseURL を設定したはずなのに、
この API には反映されていない。

結局ここでも、
URL に 手動で {{baseUrl}} を入力して初めて認識される、という状態。

残り 4 つの API でも、毎回同じ作業を繰り返します。

• API を開く
• baseURLを設定
• 前の API の値を使いたいので、
  id の Value を {{id}} に変更

6. 自動化テストを実行する

1. 5 つの API がすべて 200 OK になったので、いよいよ 人生初の自動化テストを実行します。

……が、最初は本当に分かりませんでした。

「自動化テストを実行する場所は、API 画面にはない」
という事実に。

視線は自然とボディの周辺を探してしまいます。
実際の入口は、

その他の操作を見る → 実行

という、開かないと存在に気づけない場所。

初見でここにたどり着くのは、かなり難しいです。

2.実行

3.成功／失敗結果を確認

動きはする。
でも終始「どこかで間違えていないか」を気にし続けていました。

2. 同じことを EchoAPI でやってみる

正直、最初はこう思っていました。

「API ツールなんて、どれも大差ないでしょ？」

1. 環境を作成

1.現在の環境を管理 → 環境を新規作成

2.そのまま入力：

一切都非常清晰，在这里就可以直接设置基本URL。
基本URL：

https://dummyjson.com

Environment Name：

テスト環境

3.最初の API を開き、作成した「テスト環境」を選択

API 画面に戻った瞬間、気づきました。

基本URL が自動で付与され、しかも説明付き。

そのときの率直な感想は、

「あ、これは覚えなくていいんだ。」

2. リクエスト送信 → 変数抽出（スクリプト不要）

1. 送信 をクリック
2. 後処理 → タスクを追加 → 変数を抽出

3.以下を入力：

• 変数：id
• 変数のタイプ：環境変数
• JSONPath式：$.products[0].id（最初の返却データの id）

4.環境設定を開き、変数が自動保存されていることを確認。

JS なし。
pm.response なし。
「書き間違えたかも」という不安もなし。

考えていたのは、ただ一つ。

「どの値を使いたいか？」

3. 次の API（2〜5 個目）

残りの API も、特に迷うことはありませんでした。

• 環境は自動で維持
• URL は {{baseUrl}} が自動補完
• 前の API の値を使うときは、Value に {{id}} を入力して、送信して保存するだけ

4. 自動化テスト

1.EchoAPI では 自動テスト が独立したモジュールとして用意されています。
自動テスト → 新しいテストケース

2.ステップを追加　→ APIからインポートする

3.先ほどの 5 つの API を選択

4.テスト環境 を選択

5.保存 → 実行 、結果が出る

なぜ EchoAPI は「自動テスト」を独立したモジュールにしているのか？

最初は私も疑問でした。

「なぜ各 API の中にテストを置かないのか？」

しかし一連の流れを終えて分かりました。
この設計は、初心者の認知順序にかなり配慮されています。

1. API を叩くことと、テストを回すことは別物

Postman では：

• リクエスト作成
• パラメータ調整
• Script 記述
• 自動化テスト実行

すべてが同じ画面に混在しています。

慣れている人には便利ですが、初心者にとっては：

「今、自分は API を調整しているのか、
それともテストを組んでいるのか分からない」

EchoAPI では テスト を分離することで、

今やっているのは「自動化テスト」だ

と、はっきり意識できます。

2. API 画面で「入口探し」をしなくていい

Postman のテスト実行入口は、

• リクエスト欄ではない
• レスポンス欄でもない
• 一番見ている場所にもない

そのため初心者は、

「機能は知っているけど、どの階層にあるのか分からない」
という状態になりがちです。

EchoAPI では、

• API管理：その API が動くかどうか
• 自動テスト：複数 API をどう回すか

役割が明確に分かれています。

まとめ

EchoAPI は、

テストは一つの流れとして用意する。
原理だけ理解すれば、
細かい実装はツール側が引き受ける

Postman は、

テストの場所も、
スクリプトの書き方も、
すでに分かっている前提の設計

初心者にとって重要なのは、
機能の多さではなく、
考え方が表に出ているかどうかだと感じました。