Postman adalah salah satu alat yang paling banyak digunakan untuk mengirim permintaan HTTP dan memeriksa bagaimana perilaku sebuah API. Ini dimulai sebagai ekstensi browser dan berkembang menjadi aplikasi desktop lengkap yang menangani segala hal mulai dari permintaan GET cepat hingga rangkaian uji berskrip yang berjalan di CI. Jika Anda membangun atau mengonsumsi API, Anda hampir pasti akan menjumpainya.
Panduan ini akan membahas pengujian API di Postman sebagaimana yang akan Anda lakukan sehari-hari. Anda akan mengirim permintaan, memeriksa respons, menulis pernyataan (assertions) di tab Tests, mengatur environment sehingga Anda dapat beralih antara staging dan production, serta menjalankan seluruh koleksi sekaligus dengan Collection Runner. Contoh-contohnya menggunakan API publik sehingga Anda dapat mengikutinya tanpa perlu menyiapkan apa pun terlebih dahulu.
Mulai Postman dan kirim permintaan pertama Anda
Unduh Postman dari situs resmi dan instal aplikasi desktop. Anda dapat menggunakannya tanpa akun untuk pekerjaan lokal, meskipun masuk akan menyinkronkan koleksi Anda di seluruh perangkat. Buka aplikasi dan klik tombol New, lalu pilih HTTP Request.
Sebuah permintaan membutuhkan minimal tiga hal: sebuah metode, sebuah URL, dan terkadang sebuah body. Pilih GET dari dropdown metode dan masukkan endpoint yang sebenarnya. Layanan JSONPlaceholder berguna untuk latihan:
GET https://jsonplaceholder.typicode.com/users/1
Klik Send. Panel respons akan terisi dengan body, kode status (200 OK), waktu respons, dan ukurannya. Alihkan tampilan body antara Pretty, Raw, dan Preview untuk melihat format JSON atau seperti yang dikirim server.
Untuk permintaan POST, ubah metodenya, buka tab Body, pilih raw, dan pilih JSON dari dropdown format. Tempelkan payload seperti ini:
{
"name": "Maria Chen",
"email": "maria.chen@example.com"
}
Header seperti Content-Type: application/json ditambahkan secara otomatis saat Anda memilih tipe body JSON. Tab Headers memungkinkan Anda menambahkan apa pun yang dibutuhkan API, seperti header Authorization. Jika Anda baru mengenal kode respons yang diharapkan, panduan tentang kode status HTTP yang harus digunakan API REST adalah referensi yang berguna.
Atur permintaan ke dalam koleksi
Satu permintaan baik untuk pemeriksaan cepat. Pengujian sesungguhnya berarti banyak permintaan yang saling terkait: membuat pengguna, mengambil pengguna tersebut, memperbaruinya, menghapusnya. Postman mengelompokkan ini ke dalam koleksi.
Klik Collections di sidebar, lalu ikon + untuk membuat koleksi baru. Beri nama yang jelas seperti “Uji asap API Pengguna.” Simpan setiap permintaan ke dalam koleksi dengan Ctrl/Cmd + S dan berikan nama yang jelas. Anda dapat menumpuk folder di dalam koleksi untuk memisahkan, misalnya, permintaan otentikasi dari permintaan sumber daya.
Koleksi juga merupakan unit yang Anda bagikan. Ekspor sebagai file JSON, atau bagikan tautan jika Anda menyinkronkan ke cloud. Rekan tim mengimpornya dan memiliki permintaan yang persis sama dengan Anda. Ini adalah dasar untuk segalanya, karena Collection Runner dan pengujian otomatis keduanya beroperasi pada koleksi, bukan permintaan yang terpisah.
Sebuah koleksi juga dapat membawa perilaku bersama. Postman memungkinkan Anda melampirkan skrip pada tingkat koleksi atau folder, bukan hanya pada satu permintaan. Sebuah skrip pra-permintaan pada koleksi berjalan sebelum setiap permintaan di dalamnya, yang berguna untuk menyegarkan token atau memberi stempel waktu. Skrip pengujian pada tingkat koleksi berjalan setelah setiap permintaan, yang berguna untuk pernyataan (assertion) yang Anda inginkan di mana saja, seperti “waktu respons masuk akal.” Mendefinisikan ini sekali menjaga permintaan individual Anda tetap fokus pada apa yang unik bagi mereka.
Tulis pengujian di tab Tests
Mengirim permintaan memberi tahu Anda apa yang kembali. Sebuah pengujian memberi tahu Anda apakah yang kembali itu benar, secara otomatis, setiap saat. Postman menjalankan JavaScript di area Scripts pada sebuah permintaan (versi lama menyebut ini tab Tests) setelah respons tiba.
Postman mengekspos objek pm untuk menulis pernyataan (assertions). Pola intinya adalah pm.test(name, callback), di mana callback akan melempar error jika ekspektasi gagal. Berikut adalah pernyataan yang akan sering Anda gunakan:
// Check the status code
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
// Check response time
pm.test("Response is under 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
// Check a field in the JSON body
pm.test("User has the expected email", function () {
const body = pm.response.json();
pm.expect(body.email).to.eql("maria.chen@example.com");
});
// Check a header
pm.test("Content-Type is JSON", function () {
pm.expect(pm.response.headers.get("Content-Type"))
.to.include("application/json");
});
Sintaks pernyataan berasal dari Chai, jadi pm.expect mendukung .to.eql, .to.include, .to.be.above, dan lainnya. Klik Send dan hasilnya akan muncul di tab Test Results, dengan setiap pengujian berwarna hijau atau merah.
Beberapa kebiasaan menjaga agar pengujian tetap berguna. Beri nama setiap blok pm.test sesuai dengan perilaku yang diperiksanya, bukan endpoint, sehingga pesan kegagalan terbaca seperti sebuah kalimat. Periksa hal-hal yang benar-benar akan merusak konsumen API: kode status, bentuk body, dan field yang diandalkan klien. Hindari membuat pernyataan pada nilai yang tidak Anda kontrol, seperti stempel waktu yang dihasilkan server, karena hal-hal tersebut menghasilkan kegagalan yang tidak stabil yang melatih orang untuk mengabaikan merah. Postman juga menyediakan panel Snippets di samping editor dengan pernyataan siap pakai yang dapat Anda klik untuk disisipkan, yang merupakan cara tercepat untuk mempelajari API pm. Jika Anda ingin melihat lebih dalam tentang desain pernyataan, lihat rincian pernyataan API dan cara menuliskannya dengan baik. Untuk gagasan yang lebih luas tentang menyusun pemeriksaan menjadi kasus bernama, panduan contoh kasus uji API layak dibaca bersama ini.
Gunakan environment dan variabel
Melakukan hardcode https://api.staging.example.com ke setiap permintaan sangat merepotkan saat Anda perlu mengarahkannya ke production. Environments mengatasi masalah ini. Sebuah environment adalah kumpulan variabel yang diberi nama.
Klik ikon environment di sidebar dan buat satu yang disebut “Staging.” Tambahkan variabel base_url dengan nilai https://jsonplaceholder.typicode.com. Buat environment kedua yang disebut “Production” dengan base_url yang berbeda. Sekarang referensikan variabel dalam permintaan Anda menggunakan kurung kurawal ganda:
GET {{base_url}}/users/1
Pilih environment aktif dari dropdown di kanan atas, dan setiap permintaan yang menggunakan {{base_url}} akan beralih dengannya.
Variabel juga membawa data antar permintaan. Permintaan login dapat menangkap token dari responsnya dan menyimpannya untuk digunakan oleh permintaan selanjutnya:
pm.test("Save the auth token", function () {
const token = pm.response.json().token;
pm.environment.set("auth_token", token);
});
Setiap permintaan selanjutnya dapat mengirim Authorization: Bearer {{auth_token}}. Rantai ini adalah cara Anda menguji alur yang bergantung pada status, seperti membuat sumber daya lalu memverifikasi keberadaannya.
Postman memiliki dua lingkup variabel terkait yang patut diketahui. Variabel environment milik environment yang dipilih dan berubah saat Anda beralih environment. Variabel koleksi milik sebuah koleksi terlepas dari environment, yang cocok untuk nilai yang konstan untuk API tersebut. Ada juga variabel global, yang berlaku di mana saja, dan variabel lokal yang berumur pendek yang hanya ada untuk satu kali eksekusi. Memilih lingkup yang tepat menjaga nilai tetap pada tempatnya dan menghindari kejutan saat Anda beralih target.
Jalankan seluruh koleksi dengan Collection Runner
Mengklik Send pada setiap permintaan akan cepat membosankan. Collection Runner mengeksekusi setiap permintaan dalam sebuah koleksi secara berurutan, menjalankan semua pengujiannya, dan memberi Anda ringkasan lulus/gagal.
Buka sebuah koleksi, klik tombol Run (atau menu tiga titik, lalu Run collection). Runner menampilkan permintaan Anda secara berurutan. Pilih environment, atur berapa banyak iterasi yang akan dijalankan, dan secara opsional lampirkan file data. Klik Run dan Postman akan mengirim setiap permintaan, dari atas ke bawah, mengeksekusi pengujian setiap permintaan.
Halaman hasil mencantumkan setiap pernyataan (assertion) di setiap permintaan, dengan total yang lulus dan gagal. Ini adalah pemeriksaan regresi Anda. Jalankan setelah deploy dan Anda akan tahu dalam hitungan detik apakah API masih berfungsi. Runner juga menyimpan riwayat eksekusi sebelumnya, sehingga Anda dapat membandingkan hasil hari ini dengan kemarin dan melihat kapan suite yang sebelumnya hijau mulai gagal.
Urutan penting dalam runner. Karena permintaan berjalan dari atas ke bawah, Anda dapat menempatkan permintaan login terlebih dahulu sehingga mengisi auth_token, lalu membiarkan setiap permintaan di bawahnya menggunakan token tersebut. Hal yang sama berlaku untuk setup dan cleanup: buat sumber daya di awal, gunakan di tengah, hapus di akhir. Koleksi yang diurutkan dengan baik secara efektif membuat skrip perjalanan pengguna yang lengkap.
Untuk pengujian berbasis data, lampirkan file CSV atau JSON di runner. Setiap baris menjadi satu iterasi, dan Anda mereferensikan kolom sebagai variabel seperti {{username}}. Ini memungkinkan satu permintaan menguji lusinan kombinasi input tanpa menduplikasi permintaan. Endpoint login, misalnya, dapat dipanggil dengan satu baris kredensial valid dan beberapa baris kredensial buruk, dengan setiap baris menyatakan kode status yang diharapkan. Artikel tentang pengujian API berbasis data dengan CSV dan JSON membahas pola ini secara rinci. Untuk menjalankan koleksi yang sama di CI tanpa GUI, Postman menyediakan alat baris perintah Newman, yang dijelaskan dalam perbandingan Newman versus Postman.
Di mana Postman menjadi berat, dan apa yang perlu dipertimbangkan
Postman sangat baik untuk pengujian eksplorasi dan suite berukuran kecil hingga sedang. Dua titik gesekan muncul seiring pertumbuhan proyek. Pertama, pernyataan (assertions) berada di JavaScript, sehingga non-developer dan staf QA yang lebih menyukai pendekatan visual memiliki kurva pembelajaran. Kedua, Postman menyimpan desain API, pengujian, mocking, dan dokumentasi di tempat terpisah, yang berarti data uji dan kontrak API Anda dapat menyimpang.
Apidog adalah platform API all-in-one yang mengatasi keduanya. Ini mengimpor koleksi Postman secara langsung, sehingga migrasi bukanlah penulisan ulang. Pernyataan (assertions) dapat dibangun secara visual tanpa kode, sambil tetap memungkinkan skrip saat Anda membutuhkannya. Karena desain, debugging, mocking, pengujian, dan dokumentasi berbagi satu sumber kebenaran, pengujian Anda tetap selaras dengan spesifikasi API yang sebenarnya. Jika Anda sedang mempertimbangkan opsi, rangkuman alternatif Postman untuk pengujian API menjelaskan pertukaran. Anda dapat mengunduh Apidog dan mengimpor koleksi yang sudah ada untuk membandingkan secara langsung.
Tak satu pun dari ini berarti Anda harus meninggalkan Postman. Ini tetap menjadi pilihan yang solid, terutama untuk pemeriksaan cepat dan tim yang sudah menggunakannya. Intinya adalah mengetahui di mana setiap alat cocok.
Pertanyaan yang sering diajukan
Apakah saya perlu menulis kode untuk menguji API di Postman?
Untuk mengirim permintaan dan membaca respons, tidak. Untuk pernyataan (assertion) otomatis, ya, setidaknya sedikit. Tab Tests Postman menjalankan JavaScript dan menggunakan objek pm. Polanya sederhana dan Anda dapat menyalinnya dari panel potongan kode bawaan Postman, tetapi itu tetap JavaScript. Jika Anda menginginkan pembuat pernyataan visual tanpa kode, platform khusus seperti Apidog menanganinya.
Apa perbedaan antara koleksi Postman dan environment?
Koleksi adalah kumpulan permintaan yang dikelompokkan bersama, seringkali dengan pengujiannya. Environment adalah kumpulan variabel yang diberi nama, seperti base_url atau auth_token. Koleksi menyimpan apa yang Anda kirim. Environment menyimpan nilai yang berubah antara staging, production, dan lokal. Anda mengarahkan satu koleksi ke environment yang berbeda untuk menguji permintaan yang sama terhadap server yang berbeda.
Bagaimana cara menjalankan pengujian Postman secara otomatis di CI?
Gunakan Newman, runner baris perintah Postman. Ekspor koleksi dan environment Anda, lalu jalankan newman run collection.json -e environment.json. Newman akan keluar dengan kode non-nol jika ada pengujian yang gagal, itulah yang diperiksa oleh pipeline CI Anda. Panduan tentang mengotomatiskan pengujian API di CI/CD menjelaskan cara menyambungkannya ke pipeline.
Bisakah Postman menguji lebih dari sekadar API REST?
Ya. Postman modern mendukung permintaan GraphQL, gRPC, WebSocket, dan SOAP selain HTTP dan REST biasa. Tab Tests dan pernyataan (assertions) berfungsi di sebagian besar dari ini, meskipun pengaturan permintaan yang tepat berbeda per protokol.
Berapa banyak pernyataan (assertion) yang harus dimiliki satu permintaan?
Cukup untuk memastikan responsnya benar, tidak terlalu banyak sehingga satu perubahan merusak selusin pengujian. Patokan umumnya adalah kode status, waktu respons, dan dua atau tiga field yang penting untuk endpoint tersebut. Jaga agar setiap blok pm.test fokus pada satu ekspektasi sehingga kegagalan memberi tahu Anda dengan tepat apa yang rusak.