Lingkup aman: Panduan ini berlaku hanya untuk lingkungan QA, staging, dan praproduksi milik sendiri atau yang Anda miliki otorisasinya. Materi membahas pola diagnostik, pengujian, dan observabilitas untuk integrasi CAPTCHA Anda sendiri — bukan untuk situs pihak ketiga atau alur tanpa otorisasi.
Kalkulator tarif kirim termasuk form paling rapuh untuk diuji otomatis: hasilnya angka yang harus tepat, inputnya banyak, dan di depannya sering terpasang CAPTCHA. Begitu suite QA menyentuh widget itu, tes berhenti — bukan karena logika tarif salah, melainkan karena tantangan CAPTCHA tidak ada yang menyelesaikan. Mematikan CAPTCHA di staging bukan jawabannya, sebab justru itu yang ingin Anda validasi. Selesaikan saja secara terprogram, lalu pastikan backend QA Anda menerima token dan mengembalikan tarif yang benar untuk data pengiriman fiktif.
Kenapa kalkulator tarif kirim sulit diuji otomatis
Tiga hal menumpuk di satu halaman:
- Ruang input yang besar. Kombinasi asal–tujuan, berat, dimensi, dan jenis layanan menghasilkan ratusan kasus.
- Perhitungan berlapis. Tarif dasar, biaya volumetrik, surcharge bahan bakar, dan pembulatan sering ditangani modul berbeda, sehingga selisih kecil baru muncul di kasus tertentu.
- Gerbang CAPTCHA di depan submit. Widget dipasang untuk mencegah pemanggilan otomatis, dan suite QA Anda ikut tertahan.
Poin ketiga yang biasanya membuat tim menyerah dan kembali menguji manual. Padahal di lingkungan milik sendiri gerbang itu bisa ditangani secara sah: selesaikan tantangan lewat API, kirim token seperti pengguna sungguhan.
Siapkan data pengiriman fiktif lebih dulu
Sebelum menyentuh CAPTCHA, kunci dulu masukan tesnya: buat berkas fixture berisi pengiriman sintetis dengan asal dan tujuan uji, bukan salinan data pelanggan.
Contoh yang relevan untuk tim di Indonesia: lane domestik seperti Jakarta–Surabaya, Jakarta–Denpasar, dan Medan–Makassar, ditambah kasus batas — paket 0.5 kg, paket 30 kg, dan paket ringan tetapi berdimensi besar yang seharusnya memicu perhitungan berat volumetrik. Lane lintas pulau berguna karena jatuh ke tabel zona berbeda, sehingga kesalahan pemetaan zona langsung terlihat.
Data pengiriman nyata memuat nama dan alamat penerima, jadi pakai data fiktif sepenuhnya agar pengujian tetap sejalan dengan UU Pelindungan Data Pribadi (UU 27/2022). Ini bukan nasihat hukum, hanya kebiasaan yang murah sejak awal.
Simpan setiap fixture bersama hasil yang diharapkan. Tanpa nilai harapan tertulis, tes hanya membuktikan halaman merespons — bukan bahwa tarifnya benar.
Selesaikan widget CAPTCHA di staging Anda
Alurnya sama untuk semua tipe yang didukung, empat langkah: kirim → simpan task ID → polling → pakai token.
- Muat halaman kalkulator di staging, ambil
sitekeydari markup widget. - Kirim task ke
in.phpdengan method yang sesuai —userrecaptchauntuk reCAPTCHA v2,turnstileuntuk Cloudflare Turnstile,postuntuk CAPTCHA gambar. - Lakukan polling ke
res.phpsampai statusnya bukanCAPCHA_NOT_READY. - Sisipkan token ke field form yang benar —
g-recaptcha-responseuntuk reCAPTCHA,cf-turnstile-responseuntuk Turnstile — lalu submit bersama payload pengiriman.
Kesalahan tersering di tahap ini bukan pada API, melainkan urutan: skrip menekan submit sebelum token terisi. Selesaikan CAPTCHA dahulu, baru submit.
Perhatikan juga tipe apa yang tersedia. CaptchaAI menyelesaikan reCAPTCHA v2 dan v3, Cloudflare Turnstile dan Cloudflare Challenge, GeeTest v3, serta CAPTCHA gambar/OCR dan grid; CaptchaFox (beta), Friendly Captcha (beta), dan Lemin (beta) berstatus beta. hCaptcha dan FunCaptcha belum didukung, GeeTest v4 baru segera hadir. Jika staging Anda memakai tipe yang belum didukung, sesuaikan konfigurasinya ke tipe yang bisa divalidasi.
Contoh pemanggilan QA
Contoh Python berikut menunjukkan alur minimum untuk memvalidasi widget CAPTCHA pada lingkungan staging milik Anda sendiri lewat CaptchaAI.
import os
import time
import requests
API_KEY = os.environ['CAPTCHAAI_KEY']
QA_PAGE_URL = os.environ['QA_PAGE_URL'] # contoh: https://staging.example.com/qa-login
QA_SITE_KEY = os.environ['QA_SITE_KEY']
def submit_qa_recaptcha() -> str:
payload = {
'key': API_KEY,
'method': 'userrecaptcha',
'googlekey': QA_SITE_KEY,
'pageurl': QA_PAGE_URL,
'json': 1,
}
response = requests.post(
'https://ocr.captchaai.com/in.php',
data=payload,
timeout=30,
)
response.raise_for_status()
return response.json()['request']
def fetch_qa_result(task_id: str) -> dict:
params = {
'key': API_KEY,
'action': 'get',
'id': task_id,
'json': 1,
}
while True:
response = requests.get(
'https://ocr.captchaai.com/res.php',
params=params,
timeout=30,
)
response.raise_for_status()
data = response.json()
if data.get('request') != 'CAPCHA_NOT_READY':
return data
time.sleep(5)
API key dibaca dari environment variable, bukan ditulis di source code. Fungsi polling di atas sengaja sederhana; untuk pipeline nyata tambahkan batas atas percobaan agar tes tidak menggantung.
Verifikasi backend QA, bukan hanya halamannya
Token yang berhasil diambil belum berarti tes lulus. Setelah submit, bandingkan respons endpoint internal Anda dengan nilai harapan pada fixture. Uji juga jalur negatifnya: token kedaluwarsa, token yang dipakai ulang, dan payload tanpa token harus ditolak dengan kode kesalahan jelas, bukan diam-diam menghasilkan tarif.
Assertion minimum per eksekusi:
- Kode status HTTP dan struktur JSON respons sesuai kontrak.
- Nilai tarif cocok dengan fixture, termasuk pembulatan dan berat volumetrik.
- Permintaan tanpa token valid ditolak, bukan diproses.
Observabilitas
Catat log terstruktur untuk setiap eksekusi QA. Metrik yang dianjurkan: durasi total token, kode respons HTTP, ID tugas, dan kedalaman antrean. Pisahkan saluran log per lingkungan (development, staging, pra-produksi) dan korelasikan dengan distributed tracing (mis. OpenTelemetry) lewat correlation id, agar satu skenario bisa diputar ulang penuh dari satu id saat menelusuri kegagalan.
Untuk tim yang men-deploy di ap-southeast-1 (Singapura) atau ap-southeast-3 (Jakarta), catat latensi jaringan terpisah dari waktu penyelesaian CAPTCHA — tanpa itu, runner CI yang lambat mudah disalahartikan sebagai masalah pada solver.
Biaya menjalankan suite ini secara rutin
Begitu suite dijadwalkan harian, pertanyaannya berubah jadi soal biaya. Harga CaptchaAI berbasis thread, bukan per penyelesaian, sehingga biaya bulanan tetap berapa pun jumlah eksekusi tes. BASIC ($15/bulan, 5 thread) umumnya cukup untuk satu suite QA nightly; STANDARD ($30/bulan, 15 thread) memberi ruang saat beberapa job CI paralel; ADVANCE ($90/bulan, 50 thread) sesuai untuk tim dengan banyak lingkungan staging. Tingkat di atasnya sampai VIP-3 ada di halaman pricing.
Sifat flat ini penting bagi tim yang sensitif biaya: menambah kasus uji tidak menaikkan tagihan, hanya memakai thread lebih lama.
Pemecahan masalah
| Gejala | Tindakan yang disarankan |
|---|---|
| Tes tidak menemukan widget | Periksa selector dan timing pada staging Anda |
CaptchaAI mengembalikan ERROR_NO_SLOT_AVAILABLE |
Coba ulang dengan backoff pada pipeline internal |
| Backend QA menolak token | Bandingkan action/sitekey dengan konfigurasi sebenarnya |
| Tarif berbeda dari perhitungan manual | Periksa field surcharge dan aturan pembulatan |
Checklist sebelum masuk CI
- Cakupan pengujian dibatasi pada aplikasi sendiri atau sumber daya yang Anda miliki otorisasinya.
- Fixture memakai data pengiriman fiktif, bukan data pelanggan.
- API key CaptchaAI disimpan di secret manager CI atau vault, bukan di source code.
- Setiap eksekusi mencatat latensi dan kode status respons.
- Retry idempoten dengan batas atas untuk error sementara.
- Seluruh skenario dapat direproduksi di pipeline CI.
FAQ
Berapa lama satu eksekusi tes kalkulator tarif biasanya berjalan?
Sebagian besar waktunya habis di penyelesaian CAPTCHA, bukan di perhitungan tarif. Turnstile termasuk yang cepat, reCAPTCHA v2 lebih lama. Pakai satu token untuk satu submit, lalu jalankan lane secara paralel sesuai jumlah thread paket Anda.
Staging saya memakai hCaptcha — apakah tipe itu bisa divalidasi?
Belum bisa. hCaptcha dan FunCaptcha tidak didukung CaptchaAI saat ini, dan GeeTest v4 masih segera hadir. Konfigurasikan staging Anda dengan tipe yang didukung seperti reCAPTCHA v2, Cloudflare Turnstile, atau CAPTCHA gambar.
Bisakah pola ini dijalankan di runner CI tanpa browser?
Bisa. Alur in.php → res.php hanya butuh klien HTTP, jadi berjalan di runner headless maupun fungsi serverless. Browser baru diperlukan bila tes Anda memvalidasi perilaku UI, misalnya pesan kesalahan pada form.
Bagaimana menangani error sementara tanpa membuat tes flaky?
Pakai retry idempoten dengan exponential backoff (mis. 1s, 2s, 4s) dan batas atas. Error jaringan, respons 5xx, dan ERROR_NO_SLOT_AVAILABLE layak di-retry; error otorisasi tidak.
Panduan terkait yang aman
- Mulai cepat CaptchaAI
- QA CAPTCHA terotorisasi
- Pengujian endpoint CAPTCHA pada formulir sendiri
- Debug saat tes browser gagal padahal API berfungsi
- Menyelesaikan reCAPTCHA v2 dengan API
- Menyelesaikan Cloudflare Turnstile dengan API
- Menyelesaikan GeeTest v3 dengan API
Ukur ulang akurasi kalkulator tarif kirim Anda di staging bersama CaptchaAI.