Postman membantu QA mengeksplorasi API dan mengubah request manual yang berhasil menjadi pemeriksaan berulang. Nilainya dimulai dari penjelasan kontrak yang dilanggar, data yang dikirim, dan alasan respons tidak dapat diterima pengguna. Mengklik Send dan melihat 200 tidak cukup: server bisa mengembalikan pesanan orang lain, mata uang salah, atau sukses tanpa menyimpan data. Susun pekerjaan berdasarkan skenario dan ekspektasi yang dapat diuji.
Isi collection yang berfungsi
Request menentukan metode, URL, header, otorisasi, dan body. Collection mengelompokkan request terkait dan pengaturan bersama; folder dapat mewakili perjalanan pengguna. Environment menyediakan parameter deployment tertentu. Pre-request script menyiapkan data, dan post-response script memverifikasi hasil. Respons serta riwayat membantu penyelidikan tetapi tidak menggantikan skenario tersimpan: rekan harus dapat mengulangi pemeriksaan tanpa keadaan lokal atau penjelasan lisan Anda.
Memulai penyelidikan API
Cari dahulu kesepakatan perilaku: OpenAPI, persyaratan, contoh klien, dan pembatasan peran. Verifikasi URL lingkungan dan versi layanan, lalu kirim request valid terkecil. Hapus kolom opsional dan tentukan mana yang benar-benar memengaruhi hasil. Simpan contoh berfungsi dengan deskripsi tujuan. Lalu ubah satu kondisi setiap kali: tipe kolom, nilai wajib hilang, izin pengguna, atau keadaan objek. Ini mengubah pengamatan menjadi eksperimen terkontrol.
Variabel tanpa ketergantungan tersembunyi
Simpan alamat layanan pada baseUrl dan ID pesanan baru pada orderId. {{baseUrl}}/orders/{{orderId}} lebih jelas daripada alamat sembarang dengan angka tetap. Nilai variabel Postman bergantung pada cakupan: global, collection, environment, data iterasi, dan lokal. Nama sama lintas cakupan menyulitkan debugging. Sebelum menjalankan pengujian, periksa environment terpilih dan nilai alamat setelah resolusi; jangan mengandalkan nama tab saja.
Simpan token dan kata sandi dalam mekanisme khusus rahasia, lalu berikan rahasia CI melalui lingkungan runtime. Sebelum ekspor, periksa nilai variabel dan contoh respons secara terpisah. Penandaan sensitif dan penyamaran di antarmuka tidak membuktikan nilai absen dari berkas, console, atau laporan terlampir.
Latihan: membuat dan membaca pesanan
Misalkan kontrak API uji membuat pesanan lewat POST /orders dan mengembalikan 201, id, serta totalMinor dalam satuan mata uang terkecil. Tersedia pengguna buyer-a, produk uji, dan penagihan nyata dinonaktifkan. Pada contoh, satu produk berharga 1250, quantity dua, dan pengiriman gratis. Ini masukan uji dan hasil yang diharapkan, bukan format API universal.
- 1.Buat pesanan dengan quantity=2. Harapkan 201, ID tidak kosong, dan totalMinor=2500; simpan id hanya setelah memvalidasi respons.
- 2.Panggil GET /orders/{{orderId}} sebagai pengguna sama. Harapkan pemilik, isi, dan total sama; konfirmasi keberhasilan pembuatan dengan membaca pesanan.
- 3.Ulangi pembacaan sebagai buyer-b. Harapkan penolakan sesuai kontrak tanpa isi pesanan pengguna lain; kode spesifik bergantung pada kebijakan layanan.
- 4.Kirim quantity=0. Harapkan kesalahan validasi yang disepakati dan tidak ada pesanan baru; verifikasi efek samping dengan metode yang tersedia.
Pemeriksaan yang membuktikan hasil bermakna
Post-response script perlu memverifikasi nilai bisnis dan struktur bersama kode HTTP. Contohnya, request pembuatan dapat menggunakan asersi berikut. Menyimpan id secara bersyarat melindungi langkah berikutnya dari data jelas tidak valid, tetapi tidak membuat seluruh rantai bebas dari keadaan.
pm.test('Order created', () => {
pm.response.to.have.status(201);
const body = pm.response.json();
pm.expect(body.id).to.be.a('string').and.not.empty;
pm.expect(body.totalMinor).to.eql(2500);
});
if (pm.response.code === 201) {
const body = pm.response.json();
if (typeof body.id === 'string' && body.id.length > 0) {
pm.environment.set('orderId', body.id);
}
}Hindari membandingkan seluruh respons dengan satu snapshot tetap ketika berisi waktu pembuatan dan ID acak. Periksa kolom wajib, tipe, dan relasi nilai yang valid. Nilai atribut tambahan tak terduga menurut kontrak kompatibilitas, bukan otomatis melaporkannya sebagai defect.
Eksekusi berulang dan pembersihan data
Collection harus membuat data sendiri atau mendokumentasikan penyiapan. Hapus orderId lama sebelum mengulang agar tidak membaca pesanan eksekusi sebelumnya. Jelaskan penghapusan atau penandaan entitas uji dan pemulihan setelah kegagalan parsial. Gunakan penanda eksekusi unik untuk eksekusi bersamaan. Pengguna bersama dan pesanan permanen sering mengubah pemeriksaan valid menjadi kondisi balapan acak antar penguji.
Menjalankan dalam CI
Per Oktober 2026, dokumentasi Postman v12 menjelaskan format collection v3 dan merekomendasikan Postman CLI. Newman deprecated, tidak lagi didukung, dan tidak dapat menjalankan v3. Tentukan format collection, script tersedia, dan runner terpilih dahulu. Selalu uji migrasi request dari aplikasi ke CI: vault lokal, cookie, dan kemampuan antarmuka tidak otomatis tersedia di lingkungan lain.
Untuk operasi asinkron, respons sukses mungkin hanya berarti pekerjaan diterima. Jika pembuatan mengembalikan status processing, tentukan cara menunggu keadaan akhir, batas waktu, dan respons perantara yang diterima. Jangan menggantinya dengan jeda panjang sembarangan: lingkungan cepat membuang waktu, yang lambat tetap tidak stabil. Periksa retry setelah timeout secara terpisah: hasil yang tidak diketahui klien tidak berarti objek tidak dibuat. Jika idempotency key didukung, pertahankan kunci untuk retry dengan maksud sama dan pastikan pesanan kedua tidak muncul.
Menyelidiki perbedaan
Bandingkan URL aktual, otorisasi, header, dan body yang dikirim, lalu status, respons, dan waktu. Periksa resolusi variabel serta redirect otomatis. Manual berhasil tetapi CI gagal sering melibatkan token berbeda, zona waktu, data hilang, atau jaringan. Lampirkan request minimal anonim, ekspektasi kontrak, respons aktual, build, dan ID korelasi ke defect. Dump environment lengkap biasanya mengandung lebih banyak data tak perlu daripada bukti berguna.
Kesalahan umum dan hasil QA
Kesalahan umum meliputi menyimpan seluruh regresi dalam tab belum disimpan, menganggap status hijau bukti benar, mengubah alamat manual pada puluhan request, dan menjalankan operasi pengubah keadaan di lingkungan salah. Kesalahan lain ialah rantai tak terkontrol ketika kegagalan pertama menghasilkan dua puluh kesalahan turunan. Collection baik memiliki penyiapan jelas, pemeriksaan bermakna, ketergantungan mudah didiagnosis, dan pembersihan aman. Postman kemudian mendukung diskusi API berdasarkan fakta yang dapat direproduksi.
Bacaan lanjutan
Collection lokal berulang: status, schema, dan keadaan bisnis
Gunakan API fiktif dengan GET /items dan POST /items. Kontraknya menerima name tidak kosong dan quantity bilangan bulat 1 sampai 10; penulisan valid menghasilkan 201, quantity di luar rentang 422, dan JSON tidak valid 400. Status ini milik contoh, bukan setiap API. Mulai dengan satu item yang disiapkan dan reset fixture sementara sebelum setiap eksekusi collection.
Urutan eksekusi Request Hasil yang diharapkan
1 Reset fixture sementara Satu item awal
2 GET /items 200; items adalah array dengan panjang 1
3 POST /items {"name":"Pen","quantity":2} 201; id=2, name=Pen, quantity=2
4 POST /items {"name":"Pen","quantity":11} 422; kesalahan rentang quantity
5 POST /items dengan JSON tidak valid 400; kesalahan JSON tidak valid
6 GET /items Tepat 2 item; penulisan yang ditolak tidak menambah apa punAsersi status saja dapat melewatkan hasil bisnis salah. Tambahkan asersi schema untuk kolom wajib dan tipe, lalu bandingkan nilai penting. Pembacaan akhir memeriksa penyimpanan dan ketiadaan efek samping. Simpan baseUrl dalam environment terpisah; jangan masukkan kredensial nyata ke collection pembelajaran yang diekspor.
pm.test('Created', () => pm.response.to.have.status(201));
pm.test('Business values', () => {
const item = pm.response.json();
pm.expect(item.name).to.eql('Pen');
pm.expect(item.quantity).to.eql(2);
});Untuk otomatisasi baru, lihat alur Postman CLI terkini. Panduan resmi kini merekomendasikan CLI yang dipelihara; Newman adalah opsi kompatibilitas bagi collection v2.1 yang sudah ada. Untuk collection lokal v2.1 hasil ekspor, perintah kompatibilitasnya newman run collection.json -e environment.json. Ikat server pembelajaran ke loopback dan reset fixture sementara sebelum eksekusi.