Pengujian API negatif

Pemeriksaan positif menunjukkan bahwa API menangani skenario yang diharapkan. Pemeriksaan negatif mengungkap ketahanannya terhadap masukan tidak valid, tidak terduga, dan berbahaya. Ini berharga bagi QA karena sering mengungkap kelemahan validasi, penanganan kesalahan, keamanan, dan stabilitas layanan.

Pengguna dan integrasi jarang bertindak sempurna. Mereka dapat mengirim kolom kosong, tipe salah, token kedaluwarsa, payload terlalu besar, atau memanggil endpoint dalam keadaan tidak valid. API yang baik harus merespons secara aman dan dapat diprediksi, bukan sekadar tidak crash.

Makna pengujian API negatif

Pengujian API negatif memeriksa perilaku sistem terhadap masukan tidak valid, tidak terduga, terlarang, atau bertentangan.

Cakupannya jauh lebih luas daripada mengirim kolom kosong:

→Kolom wajib tidak ada
→Format nilai salah
→Tipe data tidak sesuai
→Nilai di luar rentang
→Kombinasi kolom melanggar aturan bisnis
→Pengguna tidak terautentikasi atau tidak berizin
→Payload terlalu besar
→Content-Type tidak terduga
→Metode yang tidak seharusnya didukung endpoint
→Request berulang menimbulkan konflik

Pengujian negatif memeriksa kebenaran masukan sekaligus ketahanan API terhadap penyalahgunaan.

Mengapa ini sangat penting untuk API

UI memberikan sebagian perlindungan melalui formulir, mask, dropdown, dan tombol nonaktif. API tidak memiliki lapisan yang sama. API menerima request mentah dan harus menentukan cara menanganinya.

Pengujian API negatif yang lemah biasanya menyisakan tiga risiko:

→Layanan gagal menghadapi masukan buruk.
→Layanan berperilaku tidak terduga.
→Layanan menerima sesuatu yang seharusnya ditolak.

Jika hanya menguji happy path, Anda melihat bagian yang sangat terbatas dari perilaku sistem nyata.

Apa yang perlu diuji

Pengujian negatif yang baik mengikuti kelas masukan, bukan percobaan acak memasukkan data sembarangan.

Uji kelompok ini secara rutin:

→Kolom wajib tidak ada.
→Kolom ada tetapi kosong.
→Kolom ada tetapi null.
→Tipe salah: string alih-alih angka, atau objek alih-alih array.
→String melebihi panjang maksimum.
→Angka di bawah minimum atau di atas maksimum.
→Format tanggal, email, telepon, UUID, atau nilai enum tidak valid.
→Parameter membentuk kombinasi tidak valid.
→Kolom tambahan yang tidak diharapkan disertakan.
→Metode request salah.
→Content-Type salah.
→Token rusak atau kedaluwarsa.
→Request menargetkan sumber daya pengguna lain.
→Body request terlalu besar.
→Request diulang dalam keadaan yang berkonflik.

Pendekatan sistematis menjadikan pemeriksaan ini model kualitas API yang dapat diulang, bukan upaya kacau untuk merusak sesuatu.

Ciri pengujian negatif yang baik

Pengujian negatif lemah hanya memeriksa munculnya kesalahan. Pengujian yang kuat memeriksa lebih banyak hal.

→Apakah kode status benar?
→Apakah kesalahan dapat dipahami klien?
→Apakah respons membocorkan detail internal yang tidak diperlukan?
→Apakah data berubah padahal seharusnya tidak?
→Apakah muncul efek samping?
→Apakah pengulangan request tidak valid yang sama menghasilkan perilaku konsisten?
→Apakah layanan menghindari 500 untuk masalah di sisi klien?

Contohnya, JSON tidak valid umumnya memerlukan 400, bukan 500. Upaya mengubah sumber daya pengguna lain biasanya memerlukan 403 atau 404, bukan sukses. Body terlalu besar dapat memerlukan 413. Tujuannya penanganan yang konsisten dan jelas, bukan menebak satu kode ideal untuk setiap kasus.

Apa yang diperiksa selain kesalahan

Biasakan selalu memeriksa keadaan sistem setelah request gagal.

→Apakah benar tidak ada record yang dibuat?
→Apakah status objek tidak berubah?
→Apakah tidak ada uang yang ditagih?
→Apakah tidak ada email yang dikirim?
→Apakah audit dan log mencatat peristiwa dengan benar?
→Apakah pengulangan request membiarkan sistem dalam keadaan valid?

Banyak defect berbahaya tersembunyi di sini. API mengembalikan kesalahan tetapi secara internal sudah mengubah sebagian data. Pengguna mungkin baru melihat akibatnya kemudian sebagai bug yang tampak acak, padahal penyebabnya penanganan skenario negatif yang buruk.

Contoh praktis

Pertimbangkan endpoint pembuatan pengguna.

Skenario positif sederhana: kirim email, nama, dan kata sandi valid lalu terima 201 Created.

Sekarang pertimbangkan skenario negatif:

→Email tidak ada.
→Email kosong.
→Email tidak valid.
→Kata sandi terlalu pendek.
→Kolom body memiliki tipe tidak terduga.
→Otorisasi tidak ada padahal diwajibkan.
→Email yang sama didaftarkan lagi.
→Body terlalu besar.
→Content-Type bukan application/json.

QA perlu memverifikasi bahwa:

→Server merespons secara dapat diprediksi.
→Kesalahan cukup jelas bagi klien.
→Kode status sesuai dengan kelas masalah.
→Tidak ada record tidak valid yang dibuat.
→Tidak muncul efek samping yang tidak disengaja.
→Pengulangan request tidak valid yang sama tidak merusak sistem lebih lanjut.

Di sini pengujian negatif menjadi penilaian nyata atas kematangan API, bukan tambahan opsional.

Hal penting bagi engineer QA

→Pengujian API negatif memeriksa ketahanan bersama kesalahan masukan.
→Pengujian negatif yang baik memeriksa kode kesalahan dan keadaan sistem setelahnya.
→API yang kuat menangani request buruk secara aman dan dapat diprediksi.
→Happy path saja hampir tidak pernah membuktikan keandalan layanan nyata.
→Susun pemeriksaan negatif berdasarkan kelas risiko, bukan percobaan acak merusak sesuatu.

Bacaan lanjutan

→Dalam basis pengetahuan ini: Metode, kode status, dan header
→Dalam basis pengetahuan ini: Autentikasi dan otorisasi
→Sumber eksternal: OWASP REST Security Cheat Sheet

Matriks pengujian negatif lokal dengan pemeriksaan efek samping

Gunakan kontrak lokal sintetis, bukan menebak respons setiap API. Fixture latihan menerima POST /items dengan token latihan administrator, Content-Type application/json, name sepanjang 3–12 huruf ASCII, dan quantity bilangan bulat dari 1 sampai 5. Body harus berisi tepat dua kolom tersebut. Data berada di memori; mulai server baru untuk setiap pengujian independen.

plain text

Kasus	Contoh	Hasil yang diharapkan pada fixture ini
Kolom tidak ada	{"name":"abc"}	422 invalid_fields
Tipe salah	{"name":"abc","quantity":"1"}	422 invalid_quantity
Di luar rentang	{"name":"abc","quantity":6}	422 invalid_quantity
Kolom tambahan	{"name":"abc","quantity":1,"admin":true}	422 invalid_fields
JSON tidak valid	{	400 malformed_json
Media type salah	Content-Type: text/plain	415 json_required
Body melebihi 1024 byte	body berukuran 1025 byte	413 payload_too_large

Sebelum setiap operasi tulis yang ditolak, jalankan GET /items dan catat total; ulangi sesudahnya dan pastikan total tidak berubah. Ini mendeteksi implementasi yang menulis record sebelum mengembalikan kesalahan. Untuk nama baru yang diterima, harapkan 201 dan total + 1; pengiriman ulang menghasilkan 409 tanpa penambahan kedua. Status ini menjelaskan kontrak yang dinyatakan, bukan aturan universal untuk semua produk.

plain text

python3 mock_api.py --port 8765
# In another terminal, using only the synthetic local token:
curl -i http://127.0.0.1:8765/items -H "Authorization: Bearer demo-admin" -H "Content-Type: application/json" --data '{"name":"abc","quantity":6}'
python3 -m unittest test_mock_api.py -v

Fixture sengaja dibuat lokal dan sederhana. Gunakan untuk berlatih pemilihan masukan dan pengumpulan bukti; jangan salin token tetap atau server HTTP-nya ke sistem autentikasi produksi.

Lanjutkan belajar

Unduh lab latihan lokal (ZIP)

Periksa otorisasi secara terpisah

Turunkan nilai batas