Keuntungan:
- Kemampuan untuk melakukan pengujian API secara mendalam dengan dukungan kecerdasan buatan pada kode status, skema/kontrak, aturan bisnis, dan lapisan negatif/otorisasi
- Kemampuan untuk menghasilkan skema JSON dari respons sampel dan menghindari kepercayaan semu karena hanya melihat kode status dengan validasi tipe dan imperatif
- Kemampuan untuk menguji skenario keamanan seperti otorisasi dan IDOR dengan data sintetis dan untuk tujuan defensif hanya dalam otorisasi
Sebagian besar perangkat lunak modern berkomunikasi satu sama lain di latar belakang melalui API (Application Programming Interface - antarmuka tempat dua perangkat lunak berbicara sesuai dengan kontrak tertentu). Saat aplikasi seluler menambahkan item ke keranjang, aplikasi tersebut sebenarnya mengirimkan permintaan ke API di server. Pengujian API memeriksa apakah percakapan ini benar, aman, dan konsisten, apa pun antarmukanya; Ini lebih cepat, lebih stabil, dan lebih dalam daripada pengujian UI. Kecerdasan buatan (AI) sangat efisien dalam pengujian API: ia menghasilkan pengujian dari definisi API, mengekstrak skema respons (kontrak yang menentukan struktur data), mencantumkan kasus-kasus edge. Namun sekali lagi peringatan utama berlaku: AI tidak mengetahui aturan bisnis sebenarnya dari API Anda; cenderung menghasilkan tes dangkal yang hanya mengkonfirmasi "200 dikembalikan". Tugas Anda adalah memastikan pengujian tersebut memverifikasi kontrak dan logika bisnis yang sebenarnya.
Di unit ini, Anda akan mempelajari cara menyiapkan pengujian API mendalam yang didukung AI dengan pendekatan seperti Postman, REST Assured, dan validasi skema.
Lapisan pengujian API
Pertimbangkan pengujian API dalam beberapa tingkatan, dengan bantuan AI yang berbeda di setiap lapisan:
1. Kode status dan respon dasar. Apakah permintaan mengembalikan kode status HTTP yang diharapkan (200/201 untuk sukses, 400/401/404 untuk kesalahan)? Ini adalah lapisan paling dangkal; AI berproduksi dengan mudah tetapi hanya memberikan kepercayaan palsu.
2. Validasi skema/kontrak. Apakah struktur respons sesuai dengan kontrak — apakah kolom yang diharapkan ada, apakah tipenya benar, apakah kolom yang wajib diisi tidak ada? AI dapat menghasilkan Skema JSON — standar yang mendefinisikan struktur dokumen JSON — dari respons sampel, dan pengujian dapat memvalidasi skema tersebut. Ini jauh lebih kuat daripada menulis pernyataan berbasis lapangan secara manual.
3. Validasi aturan bisnis. Nilai sebenarnya ada di sini: "Untuk pesanan 1000 TL, bidang diskon harus 100", "pesanan yang dibatalkan tidak dapat dibatalkan lagi". AI hanya akan memverifikasi ini jika Anda memberikan aturannya; Jika Anda tidak memberikannya, ia akan melompat.
4. Negatif dan keamanan. 401 untuk token tidak valid, 403 untuk mengakses data orang lain, hapus 400 untuk badan buruk. Tes otorisasi (memverifikasi bahwa pengguna hanya dapat mengakses data mereka sendiri) adalah inti dari keamanan API dan dilakukan untuk tujuan defensif.
Tip: Jangan meminta pengujian tanpa memberi tahu AI untuk "memvalidasi tidak hanya kode status, tetapi juga skema respons dan aturan bisnis tersebut". Jika tidak, Anda akan mendapatkan pengujian yang mengatakan "200 dikembalikan, lulus" tetapi tidak melihat API mengembalikan data yang rusak.
Perintah lemah / Perintah kuat
Lemah: "Tulis tes untuk API ini."
Kuat: "Tulis pengujian REST Assured (Java) untuk titik akhir POST /order. Perjanjian: productId dan quantity wajib ada di badan; 201 dan {orderId, total, discount, status} dikembalikan jika berhasil. Aturan bisnis: diskon 10% lebih dari 1000 TL; 400 jika kuantitas<=0; 401 jika token tidak valid; 403 saat melihat pesanan pengguna lain. Pengujian: (1) kode status, (2) respons validasi skema JSON, (3) diskon aturan bisnis, (4) ikat setiap pernyataan ke aturan bisnis eksplisit, jangan hanya mencentang 200/201.”
Perintah yang kuat memberikan kontrak, aturan bisnis, skenario keamanan, dan ekspektasi validasi skema.
Pengujian kontrak: mencegah perpecahan antar tim
Dalam arsitektur layanan mikro (struktur di mana aplikasi dibagi menjadi layanan kecil yang independen satu sama lain dan berkomunikasi dengan API), mengubah format respons suatu layanan secara diam-diam akan mengganggu layanan lain yang terhubung dengannya. Pengujian kontrak — pengujian yang memverifikasi bahwa kontrak API antara penyedia layanan dan layanan konsumen tidak terputus di kedua sisi — mendeteksi kerusakan tersebut lebih awal. Idenya begini: konsumen mendefinisikan bentuk tanggapan yang diharapkannya dari produsen sebagai sebuah "kontrak"; Dengan setiap perubahan, pabrikan menguji apakah mereka masih mematuhi perjanjian ini. Jadi ketika nama atau jenis bidang berubah, konsumen memberi tahu saluran pipa sebelum terjadi kerusakan.
AI mempercepat dua tugas dalam konteks ini: menyusun kontrak yang mencerminkan harapan konsumen dari respons API yang ada, dan menandai terlebih dahulu klausul kontrak mana yang dapat dilanggar oleh perubahan. Namun kontrak itu sendiri merupakan keputusan bisnis: ahli menentukan bidang mana yang benar-benar kritis, perubahan mana yang akan merusak kompatibilitas – konsumen lama terus bekerja. AI menulis kontrak; Andalah yang menyetujuinya.
Tip: Menghapus bidang atau mengubah jenis bidang di API hampir selalu merupakan perubahan yang dapat menyebabkan gangguan. Menambahkan kolom baru biasanya aman. Memiliki AI yang mengklasifikasikan perubahan sebagai “rusak atau aman” memberikan pemeriksaan keamanan pra-rilis yang cepat.
Tukang pos atau berbasis kode?
kriteria
Tukang Pos/Orang Baru
REST Assured / kode (Java, C#, JS)
Belajar
Mudah, visual
Pengetahuan kode diperlukan
Kontrol versi
Koleksi JSON
Langsung di kode sumber
logika yang rumit
Terbatas (skrip JS)
Kekuatan pemrograman penuh
Integrasi CI/CD
dengan Newman
Bergantung langsung pada build
Validasi skema
Dengan skrip pengujian
Kuat dengan perpustakaan
Skala tim
kecil/sedang
besar, dewasa
AI menghasilkan kode untuk keduanya; Perjelas mana yang Anda inginkan.
Empat templat yang dapat disalin
1) Pengujian API berbasis kontrak:
Peran Anda: insinyur pengujian API senior.Tulis pengujian untuk titik akhir berikut dengan [alat/bahasa]: [metode + jalur].Kontrak: [bidang yang wajib diisi, kode sukses, struktur respons].Aturan bisnis: [aturan].Lapisan pengujian: (1) kode status (2) validasi skema respons(3) setiap aturan bisnis (4) negatif + otorisasi.Tautkan setiap pernyataan ke aturan/klausul kontrak yang relevan.
2) Pembuatan skema dari respons sampel:
Hasilkan Skema JSON dari contoh respons API di bawah. Tentukan bidang yang diperlukan, jenis, batasan format (tanggal, email, rentang nomor). Kemudian berikan contoh pengujian yang memvalidasi skema ini. Contoh respons: [tempelkan JSON]
3) Skenario negatif dan otorisasi:
Hasilkan kasus uji negatif dan keamanan untuk titik akhir[titik akhir]. Termasuk: bidang yang hilang/wajib diisi, jenis yang salah, nilai terlalu besar, token tidak valid/kedaluwarsa, akses ke sumber daya tidak sah (IDOR — akses ke catatan orang lain dengan mengubah ID), batas kapasitas. Tentukan kode status yang diharapkan dan isi kesalahan untuk setiap skenario. Catatan: hanya akan diuji pada API saya sendiri, yang diotorisasi.
4) Kontrol kepercayaan semu:
Lihat tes API ini. Apakah pengujian ini akan berhasil jika server mengembalikan kode status yang benar tetapi FALSEbody/data? Jika tidak, tambahkan validasi skema dan aturan bisnis. Tes: [tes tempel]
tiga kasus mini
Kasus 1 — Kekuatan validasi skema. Sebuah tim hanya memeriksa kode status dalam pengujian yang dilakukannya dengan AI. Dalam satu versi, API mulai secara keliru mengembalikan total bidang sebagai teks ("1200"); pengujian tetap hijau karena masih menghasilkan 200. Aplikasi seluler mogok. Setelah menambahkan validasi tipe dengan templat "Pembuatan skema dari respons sampel", kesalahan yang sama segera terdeteksi.
Kasus 2 — Kesenjangan otoritas (IDOR). Seorang ahli menjalankan pengujian IDOR antara “skenario negatif dan otorisasi” yang dihasilkan oleh AI: Dia meminta ID pesanan pengguna B dengan token pengguna A. API mengembalikan data 200 dan B — kerentanan otorisasi yang serius. Tes defensif ini menutup kebocoran data sebelum dipublikasikan.
Kasus 3 — Pengabaian aturan bisnis. AI menghasilkan 8 pengujian untuk titik akhir diskon; semua memeriksa 200, tidak ada yang memverifikasi jumlah diskon. Pakar tersebut menambahkan aturan bisnis ke dalam perintah dan memperbanyaknya. Pengujian baru mengungkapkan bahwa diskon dihitung secara salah pada batas 1000 TL (diskon juga diterapkan pada 999). Pengendalian kontrak saja tidak cukup; Kontrol aturan bisnis adalah suatu keharusan.
Kesalahan umum
- Hanya melihat kode status. Mengatakan "200 telah kembali dan lulus"; tidak melihat tubuh yang rusak (kepercayaan palsu).
- Melewati validasi skema. Tidak memeriksa jenis bidang dan kewajibannya; perubahan tipe terjadi secara diam-diam.
- Meminta pengujian tanpa memberikan aturan bisnis. AI tidak mengetahui aturannya; itu hanya menghasilkan kontrol teknis.
- Melupakan skenario negatif dan skenario yang menguntungkan. Kerentanan keamanan (IDOR, akses tidak sah) hanya terdeteksi oleh pengujian ini.
- Menggunakan token dan data nyata/produksi. Gunakan media khusus dan data sintetis untuk pengujian; Jangan memasukkan kunci asli ke dalam kendaraan.
- Pengujian keamanan tidak sah. Hanya jalankan tes otorisasi pada API Anda sendiri dan dengan izin.
Singkatnya
Pengujian API memverifikasi ucapan perangkat lunak dengan cepat dan mendalam, apa pun antarmukanya. AI; pengujian kontrak sangat efisien dalam menghasilkan skema JSON dan skenario negatif/keamanan dari respons sampel. Namun pengujian dangkal yang hanya memeriksa kode status memberikan kepercayaan semu. Memerlukan keempat lapisan: kode status, validasi skema, aturan bisnis, negatif, dan otorisasi. Cantumkan aturan bisnis dan kontrak pada prompt; Lakukan uji keamanan dengan data sintetis dan hanya dengan otorisasi.
Tugas aplikasi
Pilih titik akhir API dari proyek Anda sendiri. Minta AI menulis pengujian empat lapis dengan templat “pengujian API berbasis kontrak”. Kemudian tambahkan validasi jenis/penerapan dengan "pembuatan skema dari respons sampel" dan terapkan "pemeriksaan kepercayaan semu". Jalankan setidaknya satu skenario IDOR/otorisasi di lingkungan pengujian Anda sendiri. Laporkan setiap pelanggaran kontrak atau aturan bisnis yang Anda temukan; Jika Anda tidak dapat menemukannya, jalankan pengujian terhadap respons yang sengaja dibuat kacau untuk membuktikan bahwa respons tersebut berhasil.
daftar periksa
- [ ] Saya membahas empat lapisan pengujian (kasus, skema, aturan bisnis, negatif/otorisasi).
- [ ] Saya dengan jelas memberikan kontrak dan aturan bisnis kepada AI.
- [] Saya menyiapkan tes yang memvalidasi skema respons (bidang, jenis, keharusan).
- [ ] Saya telah mencoba setidaknya satu skenario otorisasi/IDOR secara defensif.
- [] Saya menggunakan lingkungan pengujian dan data sintetis alih-alih token/data asli.
- [ ] Saya membuktikan dengan "pemeriksaan kepercayaan semu" bahwa setiap tes menangkap respons yang rusak.