Keuntungan:
- Keupayaan untuk menjalankan ujian API secara mendalam dengan sokongan kecerdasan buatan pada kod status, skema/kontrak, peraturan perniagaan dan lapisan negatif/kebenaran
- Keupayaan untuk menjana skema JSON daripada respons sampel dan mengelakkan keyakinan pseudo melihat hanya pada kod status dengan jenis dan pengesahan penting
- Keupayaan untuk menguji senario keselamatan seperti kebenaran dan IDOR dengan data sintetik dan untuk tujuan pertahanan hanya dalam kebenaran
Kebanyakan perisian moden bercakap antara satu sama lain di latar belakang melalui API (Antara Muka Pengaturcaraan Aplikasi — antara muka di mana dua keping perisian bercakap mengikut kontrak tertentu). Apabila apl mudah alih menambahkan item pada troli, ia sebenarnya menghantar permintaan kepada API pada pelayan. Ujian API menyemak bahawa perbualan ini betul, selamat dan konsisten, tanpa mengira antara muka; Ia lebih pantas, lebih stabil dan lebih mendalam daripada ujian UI. Kecerdasan buatan (AI) sangat cekap dalam ujian API: ia menjana ujian daripada definisi API, mengekstrak skema tindak balas (kontrak yang mentakrifkan struktur data), menyenaraikan kes tepi. Tetapi sekali lagi kaveat utama terpakai: AI tidak mengetahui peraturan perniagaan sebenar API anda; cenderung untuk menghasilkan ujian cetek yang hanya mengesahkan "200 dikembalikan". Tugas anda adalah untuk memastikan ujian mengesahkan kontrak sebenar dan logik perniagaan.
Dalam unit ini, anda akan belajar cara menyediakan ujian API mendalam yang disokong AI dengan pendekatan seperti Posmen, REST Assured dan pengesahan skema.
Lapisan ujian API
Pertimbangkan ujian API dalam beberapa kedalaman, dengan AI membantu secara berbeza pada setiap lapisan:
1. Kod status dan respons asas. Adakah permintaan mengembalikan kod status HTTP yang dijangkakan (200/201 untuk kejayaan, 400/401/404 untuk ralat)? Ini adalah lapisan yang paling cetek; AI menghasilkan dengan mudah tetapi sahaja memberikan kepercayaan palsu.
2. Pengesahan skema/kontrak. Adakah struktur respons sesuai dengan kontrak — adakah medan yang dijangkakan hadir, adakah jenisnya betul, adakah medan yang diperlukan tiada? AI boleh menjana Skema JSON — piawaian yang mentakrifkan struktur dokumen JSON — daripada respons sampel dan ujian boleh mengesahkan terhadap skema itu. Ini jauh lebih mantap daripada menulis penegasan berasaskan medan secara manual.
3. Pengesahan peraturan perniagaan. Nilai sebenar adalah di sini: "Untuk pesanan 1000 TL, medan diskaun hendaklah 100", "pesanan yang dibatalkan tidak boleh dibatalkan lagi". AI hanya akan mengesahkan ini jika anda memberikan peraturan; Jika anda tidak memberikannya, ia akan melompat.
4. Negatif dan keselamatan. 401 untuk token tidak sah, 403 untuk mengakses data orang lain, kosongkan 400 untuk badan buruk. Ujian kebenaran (mengesahkan bahawa pengguna hanya boleh mengakses data mereka sendiri) adalah nadi keselamatan API dan dilakukan untuk tujuan pertahanan.
Petua: Jangan minta ujian tanpa memberitahu AI untuk "sahkan bukan sahaja kod status, tetapi juga skema respons dan peraturan perniagaan tersebut." Jika tidak, anda akan diberikan ujian yang mengatakan "200 dikembalikan, lulus" tetapi tidak menyedari API mengembalikan data yang rosak.
Gesaan lemah / Gesaan kuat
Lemah: "Tulis ujian untuk API ini."
Kuat: "Tulis ujian REST Assured (Java) untuk POST /titik tamat pesanan. Perjanjian: productId dan kuantiti adalah wajib dalam badan; 201 dan {orderId, total, discount, status} dikembalikan apabila berjaya. Peraturan perniagaan: diskaun 10% melebihi 1000 TL; 400 jika dalam kuantiti yang sah<=0; 301 jika pengguna dilihat apabila dalam 0; 401 Pesanan. Ujian: (1) kod status, (2) pengesahan skema JSON, (3) peraturan perniagaan diskaun, (4) mengikat setiap penegasan kepada peraturan perniagaan yang jelas;
Gesaan kuat memberikan kontrak, peraturan perniagaan, senario keselamatan dan jangkaan pengesahan skema.
Ujian kontrak: mencegah perpecahan antara pasukan
Dalam seni bina perkhidmatan mikro (struktur di mana aplikasi dibahagikan kepada perkhidmatan kecil yang bebas antara satu sama lain dan bercakap dengan API), menukar format tindak balas perkhidmatan secara senyap mengganggu perkhidmatan lain yang disambungkan kepadanya. Ujian kontrak — ujian yang mengesahkan bahawa kontrak API antara perkhidmatan pembekal dan perkhidmatan pengguna tidak dipecahkan di kedua-dua belah pihak — menangkap rehat sedemikian lebih awal. Ideanya ialah: pengguna mentakrifkan bentuk tindak balas yang dia harapkan daripada pengeluar sebagai "kontrak"; Dengan setiap perubahan, pengilang menguji bahawa ia masih mematuhi perjanjian ini. Jadi apabila nama atau jenis medan berubah, pengguna memberitahu saluran paip sebelum ia ranap.
AI mempercepatkan dua tugas dalam konteks ini: merangka kontrak yang mencerminkan jangkaan pengguna daripada respons API sedia ada dan pratanda klausa kontrak mana yang boleh dilanggar oleh perubahan. Tetapi kontrak itu sendiri adalah keputusan perniagaan: pakar menentukan bidang mana yang benar-benar kritikal, perubahan mana yang akan memecahkan keserasian ke belakang — pengguna lama terus bekerja. AI menulis kontrak; Anda adalah orang yang meluluskannya.
Petua: Memadamkan medan atau menukar jenis medan dalam API hampir selalu merupakan perubahan besar. Menambah medan baharu biasanya selamat. Mempunyai AI mengklasifikasikan perubahan sebagai "pecah atau selamat" menyediakan semakan keselamatan pra-keluaran yang cepat.
Posmen atau berasaskan kod?
kriteria
Posmen/Newman
REST Assured / kod (Java, C#, JS)
Pembelajaran
Mudah, visual
Pengetahuan kod diperlukan
Kawalan versi
Koleksi JSON
Terus dalam kod sumber
logik yang kompleks
Terhad (skrip JS)
Kuasa pengaturcaraan penuh
Penyepaduan CI/CD
dengan Newman
Bergantung secara langsung pada binaan
Pengesahan skema
Dengan skrip ujian
Berkuasa dengan perpustakaan
Skala pasukan
kecil/sederhana
besar, matang
AI menjana kod untuk kedua-duanya; Jelas yang mana satu anda mahu.
Empat templat yang boleh disalin
1) Ujian API berasaskan kontrak:
Peranan anda: jurutera ujian API kanan.Tulis ujian untuk titik akhir berikut dengan [alat/bahasa]: [kaedah + laluan].Kontrak: [medan yang diperlukan, kod kejayaan, struktur tindak balas].Peraturan perniagaan: [peraturan].Lapisan ujian: (1) kod status (2) pengesahan skema respons(3) setiap peraturan perniagaan (4) negatif + kebenaran. Pautkan setiap pernyataan kepada peraturan klausa yang berkaitan.
2) Penjanaan skema daripada respons sampel:
Hasilkan Skema JSON daripada sampel respons API di bawah. Tentukan medan, jenis, kekangan format yang diperlukan (tarikh, e-mel, julat nombor). Kemudian berikan contoh ujian yang mengesahkan terhadap skema ini. Contoh respons: [tampal JSON]
3) Senario negatif dan kebenaran:
Hasilkan kes ujian negatif dan keselamatan untuk titik akhir[titik akhir]. Termasuk: medan hilang/diperlukan, jenis salah, nilai terlalu besar, token tidak sah/tamat tempoh, akses kepada sumber yang tidak dibenarkan (IDOR — akses kepada rekod orang lain dengan menukar ID), had kadar. Tentukan kod status yang dijangkakan dan badan ralat untuk setiap senario. Nota: hanya akan diuji pada API saya sendiri, dibenarkan.
4) Kawalan pseudo-amanah:
Semak ujian API ini. Adakah ujian ini akan ditangkap jika pelayan mengembalikan kod status yang betul tetapi FALSEbody/data? Jika tidak, tambahkan skema dan pengesahan peraturan perniagaan. Ujian: [tampal ujian]
tiga kes mini
Kes 1 — Kuasa pengesahan skema. Satu pasukan hanya menyemak kod status dalam ujian yang dihasilkan dengan AI. Dalam satu versi, API mula tersilap mengembalikan jumlah medan sebagai teks ("1200"); ujian kekal hijau kerana ia masih mengembalikan 200. Aplikasi mudah alih ranap. Selepas menambah pengesahan jenis dengan templat "Penjanaan skema daripada respons sampel", ralat yang sama telah ditangkap serta-merta.
Kes 2 — Jurang kuasa (IDOR). Seorang pakar menjalankan ujian IDOR antara "senario negatif dan kebenaran" yang dijana oleh AI: Dia meminta ID pesanan pengguna B dengan token pengguna A. API mengembalikan data 200 dan B — kerentanan kebenaran yang serius. Ujian pertahanan ini menutup kebocoran data sebelum ia disiarkan secara langsung.
Kes 3 — Pintasan peraturan perniagaan. AI menjana 8 ujian untuk titik akhir diskaun; semua menyemak 200, tiada yang mengesahkan jumlah diskaun. Pakar itu menambahkan peraturan perniagaan pada gesaan dan memintanya diterbitkan semula. Ujian baru mendedahkan bahawa diskaun telah dikira secara salah pada had 1000 TL (diskaun juga digunakan untuk 999). Kawalan kontrak tidak mencukupi; Kawalan peraturan perniagaan adalah satu kemestian.
Kesilapan biasa
- Hanya melihat kod status. Untuk mengatakan "200 telah kembali dan berlalu"; tidak melihat badan yang rosak (amanah palsu).
- Melangkaui pengesahan skema. Tidak menyemak jenis medan dan kewajipan; perubahan jenis berlalu secara senyap.
- Meminta ujian tanpa menyediakan peraturan perniagaan. AI tidak tahu peraturan; ia hanya menghasilkan kawalan teknikal.
- Melupakan senario negatif dan kelayakan. Kerentanan keselamatan (IDOR, akses tanpa kebenaran) ditangkap hanya oleh ujian ini.
- Menggunakan token dan data sebenar/pengeluaran. Gunakan media khusus dan data sintetik untuk ujian; Jangan masukkan kunci sebenar ke dalam kenderaan.
- Ujian keselamatan yang tidak dibenarkan. Hanya jalankan ujian kebenaran pada API anda sendiri dan dengan kebenaran.
Secara ringkasnya
Ujian API mengesahkan pertuturan kepingan perisian dengan cepat dan mendalam, tanpa mengira antara muka. AI; ujian kontrak sangat cekap dalam menjana skema JSON dan senario negatif/keselamatan daripada respons sampel. Tetapi ujian cetek yang hanya menyemak kod status memberikan keyakinan palsu. Memerlukan semua empat lapisan: kod status, pengesahan skema, peraturan perniagaan, negatif dan kebenaran. Letakkan peraturan perniagaan dan kontrak dengan segera; Lakukan ujian keselamatan dengan data sintetik dan hanya dengan kebenaran.
Tugasan permohonan
Pilih titik akhir API daripada projek anda sendiri. Minta AI menulis ujian empat lapisan dengan templat "pengujian API berasaskan kontrak". Kemudian tambahkan pengesahan jenis/penguatkuasaan dengan "penjanaan skema daripada respons sampel" dan gunakan "pemeriksaan pseudo-trust". Jalankan sekurang-kurangnya satu IDOR/senario kebenaran dalam persekitaran ujian anda sendiri. Laporkan sebarang pelanggaran kontrak atau peraturan perniagaan yang anda temui; Jika anda tidak menemui apa-apa, jalankan ujian terhadap tindak balas yang sengaja dikacau untuk membuktikan bahawa ia telah menangkapnya.
senarai semak
- [ ] Saya merangkumi empat lapisan ujian (kes, skema, peraturan perniagaan, negatif/kebenaran).
- [ ] Saya dengan jelas memberikan kontrak dan peraturan perniagaan kepada AI.
- [ ] Saya menyediakan ujian yang mengesahkan skema respons (medan, jenis, imperatif).
- [ ] Saya telah mencuba sekurang-kurangnya satu kebenaran/senario IDOR secara defensif.
- [ ] Saya menggunakan persekitaran ujian dan data sintetik dan bukannya token/data sebenar.
- [ ] Saya membuktikan dengan "semakan keyakinan pseudo" bahawa setiap ujian menangkap respons yang rosak.