Variabel Postman Tidak Tersimpan di Runner: Penyebab Utama dan Cara Mengatasi

TL;DR

Variabel yang diatur selama eksekusi permintaan manual sering kali hilang saat Anda menjalankan koleksi yang sama di Collection Runner Postman. Akar masalahnya adalah ketidakcocokan cakupan variabel: pm.environment.set berperilaku berbeda di runner dibandingkan dalam mode manual, dan variabel koleksi bekerja berbeda dari variabel lingkungan. Panduan ini menjelaskan dengan tepat mengapa hal ini terjadi dan cara memperbaikinya, kemudian menunjukkan bagaimana Apidog menangani cakupan variabel dengan cara yang lebih sulit untuk salah konfigurasi secara tidak sengaja.

tombol

Pendahuluan

Anda telah menguji API secara manual di Postman. Anda menjalankan permintaan login, skrip pra-permintaan mengatur token otentikasi, dan permintaan berikutnya mengambilnya dengan baik. Semuanya berfungsi.

Kemudian Anda mengklik “Jalankan Koleksi.” Runner dimulai, permintaan login berhasil, tetapi permintaan berikutnya gagal dengan kode 401. Token tidak ada.

Skenario ini berulang kali muncul di Stack Overflow dan forum komunitas Postman. Responsnya biasanya menunjuk ke cakupan variabel, tetapi jarang menjelaskan gambaran lengkap mengapa perilakunya berbeda antara pengujian manual dan runner.

Memahami hal ini memerlukan pemahaman hierarki cakupan variabel Postman. Setelah Anda melihatnya dengan jelas, solusinya sederhana.

Hierarki Cakupan Variabel Postman

Postman memiliki lima cakupan variabel, yang terdaftar dari prioritas tertinggi ke terendah:

Variabel lokal – hanya tersedia dalam eksekusi skrip saat ini, tidak dapat diakses di seluruh permintaan
Variabel data – dimuat dari file CSV atau JSON untuk eksekusi berbasis data
Variabel koleksi – dicakupkan ke koleksi, tetap ada di seluruh permintaan dalam koleksi tersebut
Variabel lingkungan – dicakupkan ke lingkungan yang dipilih, tetap ada di seluruh koleksi
Variabel global – tersedia di koleksi mana pun di lingkungan mana pun

Ketika Postman menyelesaikan referensi variabel seperti {{token}}, ia menelusuri daftar ini dan menggunakan kecocokan pertama yang ditemukannya.

Masalahnya adalah “tetap ada” memiliki arti berbeda tergantung pada bagaimana Anda menjalankan koleksi.

Mengapa Variabel Hilang di Collection Runner

Perbedaan nilai saat ini vs. nilai awal

Setiap variabel Postman memiliki dua bidang: “nilai awal” dan “nilai saat ini.”

Nilai awal disinkronkan ke cloud Postman dan dibagikan dengan rekan tim.
Nilai saat ini bersifat lokal untuk mesin Anda dan tidak pernah disinkronkan.

Ketika Anda mengatur variabel secara terprogram dalam skrip menggunakan pm.environment.set('token', value), Postman memperbarui nilai saat ini di lingkungan aktif Anda.

Dalam mode pengujian manual, ini berfungsi seperti yang diharapkan karena nilai saat ini lokal Anda tetap ada di seluruh eksekusi permintaan individual dalam sesi yang sama.

Di Collection Runner, perilakunya berubah. Runner memulai setiap eksekusi dari keadaan lingkungan saat ini pada awal eksekusi. Skrip yang memperbarui variabel selama eksekusi berfungsi dengan benar dalam eksekusi tersebut. Tetapi jika runner dikonfigurasi untuk menghapus variabel di antara eksekusi, atau jika nilai awal kosong dan runner menggunakan snapshot lingkungan yang baru, Anda dapat berakhir dalam keadaan di mana skrip Anda berjalan tetapi variabel tersebut tampaknya tidak tetap ada.

Masalah variabel lingkungan vs. variabel koleksi

Berikut adalah jebakan yang lebih umum. Anda mengatur variabel dalam skrip pasca-respons:

pm.environment.set('token', pm.response.json().access_token);

Ini mengatur variabel di **lingkungan aktif**. Tetapi Collection Runner memiliki opsi yang disebut “Pertahankan nilai variabel.” Jika kotak centang ini tidak dicentang (secara default tidak dicentang), runner akan mengatur ulang variabel lingkungan ke nilai awalnya setelah eksekusi. Setiap nilai yang diatur selama eksekusi akan dibuang.

Jika Anda menjalankan koleksi tanpa lingkungan yang dipilih, pm.environment.set akan gagal secara diam-diam. Tidak ada lingkungan untuk ditulis. Variabel tersebut menghilang.

Ketidakcocokan cakupan antara mode manual dan runner

Dalam pengujian manual, Anda biasanya memiliki lingkungan yang dipilih dan lingkungan tersebut tetap ada di seluruh sesi Postman Anda. Ketika Anda menjalankan permintaan, mengatur variabel, dan menjalankan permintaan lain, semuanya terjadi dalam konteks lingkungan persisten yang sama.

Collection Runner membuat konteks eksekusi terpisah. Ini memuat status lingkungan di awal, menjalankan semua permintaan, dan kemudian (kecuali Anda mencentang “Pertahankan nilai variabel”) mengembalikan lingkungan ke status sebelum eksekusi.

Ini berarti variabel yang diatur oleh satu permintaan di runner tersedia untuk permintaan berikutnya dalam eksekusi yang sama, tetapi tidak tetap ada di panel lingkungan Anda setelah eksekusi berakhir kecuali Anda secara eksplisit menyimpannya.

Perbaikan

Perbaikan 1: Centang “Pertahankan nilai variabel” di runner

Di Collection Runner, sebelum mengklik Jalankan:

Cari opsi “Pertahankan nilai variabel” di panel konfigurasi runner.
Centang kotak ini.

Ini memberi tahu runner untuk menulis kembali setiap perubahan variabel ke lingkungan aktif Anda setelah eksekusi selesai. Variabel yang diatur oleh skrip selama eksekusi akan terlihat di panel lingkungan Anda saat eksekusi selesai.

Kapan menggunakannya: Ketika Anda ingin runner memperbarui status bersama, seperti menyegarkan token otentikasi yang akan digunakan oleh alat lain atau eksekusi berikutnya.

Kapan tidak menggunakannya: Ketika Anda menjalankan beberapa iterasi dan variabel yang diatur dalam iterasi 1 akan mengkontaminasi iterasi 2. Dalam kasus tersebut, gunakan file data atau setel ulang variabel secara eksplisit di awal setiap iterasi.

Perbaikan 2: Gunakan variabel koleksi alih-alih variabel lingkungan untuk status intra-eksekusi

Jika variabel hanya perlu dibagikan di antara permintaan dalam eksekusi koleksi yang sama, gunakan variabel koleksi alih-alih variabel lingkungan:

// Di skrip pasca-respons permintaan login Anda:
pm.collectionVariables.set('token', pm.response.json().access_token);

// Di skrip pra-permintaan permintaan berikutnya:
const token = pm.collectionVariables.get('token');

Variabel koleksi selalu tersedia di runner terlepas dari apakah lingkungan dipilih. Variabel ini tetap ada selama durasi eksekusi koleksi. Variabel ini adalah cakupan yang tepat untuk nilai-nilai yang diatur dan digunakan dalam satu koleksi.

Perbaikan 3: Pastikan lingkungan dipilih sebelum menjalankan

pm.environment.set gagal secara diam-diam ketika tidak ada lingkungan yang aktif. Sebelum menjalankan koleksi:

Buka Collection Runner.
Verifikasi bahwa lingkungan dipilih di dropdown “Environment”.
Jika Anda tidak memerlukan variabel tingkat lingkungan, gunakan variabel koleksi sebagai gantinya (Perbaikan 2).

Perbaikan 4: Gunakan nilai awal untuk variabel yang harus selalu ada

Jika variabel seperti baseUrl perlu tersedia dari permintaan pertama dalam eksekusi, atur sebagai nilai awal di lingkungan Anda, bukan hanya nilai saat ini.

Di editor lingkungan:

Atur bidang “Nilai awal”, bukan hanya bidang “Nilai saat ini”.
Nilai awal adalah apa yang digunakan runner sebagai status awal.

Jika hanya nilai saat ini yang diatur dan runner tidak memiliki akses ke nilai saat ini lokal Anda (misalnya, rekan tim yang menjalankan koleksi, atau eksekusi Newman/Apidog CLI), variabel akan dimulai kosong.

Perbaikan 5: Debug dengan pencatatan konsol

Tambahkan console.log ke skrip pra-permintaan dan pasca-respons Anda untuk melihat dengan tepat apa yang terjadi:

// Skrip pra-permintaan
console.log('token sebelum permintaan:', pm.collectionVariables.get('token'));
console.log('token lingkungan:', pm.environment.get('token'));

Buka Postman Console (Lihat > Tampilkan Postman Console) sebelum menjalankan koleksi. Log akan menunjukkan dengan tepat cakupan mana setiap variabel dibaca dan nilai apa yang dipegangnya di setiap langkah.

Bagaimana Apidog menangani cakupan variabel

Apidog menggunakan hierarki cakupan yang sama: global, lingkungan, koleksi, dan lokal. Perbedaan utamanya ada pada UI.

Di editor variabel Apidog, nilai awal dan saat ini ditampilkan dengan label dan warna yang eksplisit. Antarmuka membuatnya lebih sulit untuk secara tidak sengaja hanya mengatur nilai saat ini. Ketika sebuah skrip mengatur variabel menggunakan pm.environment.set (yang didukung Apidog untuk kompatibilitas Postman), panel lingkungan akan diperbarui secara visual secara real time sehingga Anda dapat melihat perubahan terjadi.

Runner pengujian Apidog juga tidak mengatur ulang nilai variabel di antara langkah-langkah kecuali Anda secara eksplisit mengkonfigurasinya untuk melakukannya. Perilaku default adalah mempertahankan status variabel di seluruh permintaan dalam eksekusi, yang sesuai dengan apa yang diharapkan sebagian besar pengembang dari pengujian manual.

Untuk skenario tim, model Apidog yang mengutamakan lokal berarti variabel lingkungan disimpan di disk. Tidak ada sinkronisasi cloud yang menimpa nilai saat ini Anda di antara eksekusi.

Ringkasan Kesalahan Umum

Kesalahan	Gejala	Perbaikan
Tidak ada lingkungan yang dipilih	`pm.environment.set` gagal secara diam-diam	Pilih lingkungan atau gunakan variabel koleksi
Hanya nilai saat ini yang diatur	Variabel hilang di CI atau mesin rekan tim	Atur nilai awal di editor lingkungan
"Pertahankan nilai variabel" tidak dicentang	Variabel diatur ulang setelah runner selesai	Centang “Pertahankan nilai variabel” di konfigurasi runner
Menggunakan variabel lingkungan untuk status intra-eksekusi	Berfungsi dalam mode manual, gagal di runner	Beralih ke `pm.collectionVariables.set`
Memeriksa cakupan yang salah di log	Variabel ada tetapi nilai yang salah digunakan	Catat kedua cakupan dan periksa prioritas resolusi

FAQ

Mengapa pm.environment.set berfungsi dalam mode manual tetapi tidak di runner?Dalam mode manual, Anda memiliki sesi lingkungan yang persisten. Di runner, lingkungan dimuat di awal eksekusi dan secara default diatur ulang di akhir. Skrip yang mengatur variabel selama eksekusi masih berfungsi untuk permintaan berikutnya dalam eksekusi tersebut, tetapi perubahannya tidak tetap ada di lingkungan Anda kecuali “Pertahankan nilai variabel” dicentang.

Apa perbedaan antara pm.environment.set dan pm.collectionVariables.set?pm.environment.set menulis ke lingkungan aktif, yang dibagikan di semua koleksi yang menggunakan lingkungan tersebut. pm.collectionVariables.set menulis ke cakupan yang terikat pada koleksi tertentu. Untuk nilai yang hanya penting dalam satu eksekusi koleksi, variabel koleksi lebih tepat dan tidak memerlukan lingkungan untuk dipilih.

Apakah masalah ini terjadi di Newman?Ya. Newman memiliki model cakupan yang sama. Secara default, Newman memulai setiap eksekusi dengan nilai awal lingkungan yang diekspor dan tidak mempertahankan perubahan setelah eksekusi kecuali Anda menggunakan flag --export-environment untuk menulis status lingkungan akhir ke file.

Apa itu flag --export-environment di Newman?Ini memberi tahu Newman untuk menulis status akhir lingkungan, termasuk nilai apa pun yang diatur oleh skrip selama eksekusi, ke file JSON setelah eksekusi selesai. Anda kemudian dapat meneruskan file tersebut sebagai lingkungan untuk eksekusi berikutnya. Ini berguna untuk pipeline di mana satu eksekusi menghasilkan token yang digunakan oleh eksekusi berikutnya.

Apakah Apidog mendukung pm.collectionVariables.set?Ya. Apidog mendukung API skrip Postman lengkap, termasuk pm.collectionVariables.set, pm.collectionVariables.get, pm.environment.set, dan pm.environment.get. Koleksi yang dimigrasikan dari Postman menggunakan sintaks skrip yang sama.

Bagaimana cara meneruskan variabel dari satu koleksi ke koleksi lain di Postman?Gunakan variabel global: pm.globals.set('token', value). Variabel global tetap ada di seluruh koleksi dan lingkungan selama sesi Postman. Berhati-hatilah dengan pendekatan ini dalam pengaturan tim karena variabel global tidak dicakupkan dan dapat menyebabkan tabrakan nama.

Masalah cakupan variabel di Postman adalah salah satu sumber paling andal dari negatif palsu dalam rangkaian pengujian API. Pengujian yang lulus secara manual tetapi gagal di runner bukanlah pengujian yang dapat Anda percaya. Memahami model cakupan, menggunakan setter yang tepat untuk konteks yang tepat, dan mencentang “Pertahankan nilai variabel” bila sesuai adalah tiga langkah yang menyelesaikan sebagian besar masalah ini.

tombol