Respons
200 OK menjawab pertanyaan yang sempit: server menyatakan request berhasil. Ia belum membuktikan bahwa angka di body benar, perubahan tersimpan, atau operasi yang sama tetap aman ketika dijalankan bersamaan. Sebuah laporan hasil test perlu menjelaskan apa yang diperiksa sebelum label “lulus” bisa dipakai untuk mengambil keputusan rilis.Explaining 9 Types of API Testing dari ByteByteGo memberi kosakata awal yang berguna. Saya membacanya sebagai kumpulan sudut pemeriksaan. Sembilan label itu tidak membentuk urutan wajib, dan sebagian bisa melekat pada test yang sama.
Sembilan label untuk pertanyaan yang berbeda
Tabel berikut merangkum sembilan jenis dalam sumber. Kolom terakhir menunjukkan batas kesimpulan yang saya pakai saat membaca hasilnya.
Jenis | Pertanyaan | Batas bukti |
Smoke | Apakah fungsi penting bisa diakses? | Cakupan sempit; bukan pemeriksaan seluruh aturan. |
Functional | Apakah perilaku sesuai requirement? | Hanya kondisi yang diberi assertion. |
Integration | Apakah komponen bertukar data dengan benar? | Hasil mengikuti dependency yang dilibatkan. |
Regression | Apakah perubahan merusak perilaku lama? | Bergantung pada kasus yang dipertahankan. |
Load | Bagaimana kinerja pada beban yang ditentukan? | Berlaku untuk profil beban dan lingkungan itu. |
Stress | Bagaimana sistem gagal saat melampaui kapasitas? | Perlu memeriksa pemulihan dan keutuhan data. |
Security | Bisakah batas akses atau perlindungan dilewati? | Tidak membuktikan semua ancaman sudah dicakup. |
UI | Apakah client menampilkan hasil API dengan benar? | Memeriksa integrasi client, bukan hanya endpoint. |
Fuzz | Apa akibat input tidak terduga? | Kegagalan perlu disimpan agar bisa direproduksi. |
Ada beberapa penyederhanaan yang perlu diluruskan. Smoke test tidak harus menunggu pengembangan API selesai; ia juga berguna setelah deployment untuk mendeteksi konfigurasi atau dependency yang salah. Integration test tidak selalu end-to-end: API yang berbicara dengan database asli sudah memiliki batas integrasi, meskipun browser dan layanan eksternal tidak ikut dijalankan.
Regression menyatakan tujuan pengujian setelah perubahan. Functional dan integration test yang sudah ada bisa menjadi regression suite. Fuzzing adalah teknik menghasilkan input, sehingga dapat membantu security testing sekaligus menemukan bug ketahanan biasa. Menghitung sembilan label sebagai sembilan suite terpisah justru dapat menggandakan pekerjaan.
Assertion menentukan nilai sebuah functional test
OpenAPI 3.1.0 menyediakan tempat untuk mendeskripsikan operasi, parameter, request body, response, dan skema data. Kontrak ini membantu menentukan bentuk request dan response yang perlu diperiksa. Namun kesesuaian skema tidak otomatis membuktikan aturan bisnis.
Misalnya, API reservasi tiket menerima
POST /reservations dengan eventId dan quantity. Requirement-nya menetapkan quantity bilangan bulat positif, stok tidak boleh negatif, dan penolakan tidak boleh membuat reservasi. Kontrak request dapat ditulis seperti ini:openapi: 3.1.0
info:
title: Ticket Reservation API
version: 1.0.0
paths:
/reservations:
post:
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [eventId, quantity]
additionalProperties: false
properties:
eventId:
type: string
minLength: 1
quantity:
type: integer
minimum: 1
responses:
'201':
description: Reservation created
'400':
description: Invalid reservation input
'409':
description: Insufficient ticket stockPemilihan
400 untuk input tidak valid dan 409 untuk konflik stok merupakan keputusan kontrak contoh ini. RFC 9110 menjelaskan semantik status HTTP; aplikasi tetap harus menentukan kondisi bisnis yang menghasilkan setiap respons. Menulis skema juga belum mengaktifkan validasi di server.Test untuk quantity nol harus mengirim nilai itu, memeriksa status
400, lalu memastikan jumlah reservasi dan stok tetap seperti sebelum request. Tanpa assertion terakhir, implementasi yang mengurangi stok lebih dahulu lalu mengembalikan error masih bisa dianggap lulus.Untuk dua request yang berebut tiket terakhir, assertion-nya berbeda: hanya satu reservasi berhasil, request lain ditolak sesuai kontrak, dan stok akhir nol. Pemeriksaan ini menyentuh concurrency serta database, sehingga tidak cukup dijalankan dengan mock yang selalu menerima operasi. Hasil test baru bermakna ketika setup data, tindakan, dan kondisi akhir dinyatakan jelas.
Dependency asli dan mock memberi bukti yang berbeda
Mock berguna untuk membuat timeout atau respons error yang sulit dipicu dari layanan eksternal. Ia juga membuat pengujian cepat dan dapat diulang. Biayanya: perilaku mock bisa berbeda dari layanan sebenarnya.
Pada API reservasi tadi, mock database tidak membuktikan bahwa transaksi dan batasan stok bekerja di database produksi. Sebaliknya, memanggil penyedia pembayaran asli pada setiap perubahan kode menambah biaya dan ketidakstabilan. Saya akan memakai database pengujian dengan mesin yang sama untuk aturan stok, lalu sandbox penyedia untuk memeriksa format dan alur integrasinya. Jalur timeout tetap perlu diuji secara terkontrol.
UI testing berada di batas lain. Respons error API yang benar belum menjamin browser menghentikan loading, menampilkan alasan kegagalan, atau mencegah pengguna mengirim ulang tindakan tanpa sadar. Sebagian kecil alur browser bernilai tinggi dapat membuktikan hubungan ini; mengulang semua variasi validasi lewat browser membuat diagnosis lebih lambat.
Load test membutuhkan target, stress test membutuhkan jalan pulih
Angka request per second tanpa profil request sulit dipakai untuk keputusan kapasitas. Membaca daftar acara berbeda bebannya dari membuat reservasi yang mengunci stok. Proporsi operasi, ukuran data, cache, durasi test, serta kapasitas mesin harus dicatat bersama hasil.
Sebelum menjalankan load test, tentukan target latency dan error rate untuk beban yang mewakili penggunaan. Ukur throughput yang benar-benar tercapai, bukan hanya request yang hendak dikirim. Periksa percentile latency seperti p95 agar respons lambat tidak tertutup rata-rata. Pantau juga antrean dan penggunaan koneksi database untuk menjelaskan penyebab penurunan kinerja.
Stress test menaikkan tekanan melewati batas tersebut. Tujuannya mencatat kapan layanan mulai menolak pekerjaan, apakah penolakan terkendali, dan apakah layanan pulih setelah beban diturunkan. Untuk reservasi, error rate yang kembali normal belum cukup: stok dan jumlah reservasi harus tetap konsisten. Jalankan pengujian ini di lingkungan yang diizinkan dan terisolasi dari transaksi pengguna.
Hasil test perlu menjadi keputusan rilis
Saya akan menempatkan functional test yang cepat dan regression test untuk bug yang pernah ditemukan pada setiap perubahan kode. Integration test menjaga batas data dan dependency yang terdampak. Setelah deployment, smoke test memberi sinyal cepat bahwa jalur penting benar-benar hidup. Load, stress, dan fuzz test membutuhkan anggaran waktu serta lingkungan tersendiri sesuai risiko perubahan.
Security test perlu menyatakan larangan yang diuji: pengguna tanpa hak tidak boleh membuat reservasi atas nama akun lain, dan input tambahan tidak boleh mengubah field internal. Respons penolakan harus disertai pemeriksaan bahwa tidak ada efek samping. Memiliki scanner atau fuzzing job saja belum memberi bukti bahwa aturan akses ini benar.
Saat meninjau hasil pengujian, saya ingin melihat hubungan langsung antara perubahan dan bukti yang dibawa. Untuk perubahan aturan stok, laporan yang berguna berbunyi: dua request memperebutkan satu tiket, tepat satu berhasil, stok akhir nol, dan tidak ada reservasi ganda. Label “integration test passed” menyusul sebagai keterangan tentang cara bukti itu diperoleh.