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.
Suite QA yang tadinya cuma lima skenario gampang dijalankan berurutan. Begitu jumlahnya naik ke puluhan — reCAPTCHA, Turnstile, dan variasi form staging — proses satu per satu mulai memakan waktu terlalu lama, sementara BrowserContext baru untuk tiap kasus bikin CI runner kehabisan memori. Panduan ini membahas empat pola lanjutan untuk masalah itu: paralelisme yang dibatasi secara sadar, reuse BrowserContext yang aman, penutupan resource yang rapi, dan observability yang bisa diaudit — semuanya untuk lingkungan Anda sendiri.
Kapan pola dasar tidak lagi cukup
Setup Puppeteer + CaptchaAI dasar — satu browser, satu context, submit token, lanjut ke test berikutnya — bekerja baik sampai suite QA Anda melewati sekitar 10–15 skenario per run. Setelah itu, tiga gejala biasanya muncul: run pipeline CI molor karena semuanya sekuensial, context yang tidak ditutup dengan benar menumpuk dan bikin runner kehabisan memori, dan sulit menelusuri kasus mana yang gagal karena log tercampur di satu stream. Pola di bawah ini menjawab ketiganya satu per satu.
Paralelisme terkontrol: batasi concurrency sesuai kuota thread
Jangan jalankan semua kasus QA sekaligus tanpa batas — itu cara paling gampang membanjiri baik memori runner CI maupun kuota thread CaptchaAI Anda. Batasi konkurensi per kasus_qa dengan angka tetap, lalu naikkan bertahap sambil memantau median waktu solve.
Sebagai patokan kasar: tim yang menjalankan QA lintas beberapa proyek klien atau tim data internal biasanya berlangganan STANDARD ($30/bulan, 15 thread) atau ADVANCE ($90/bulan, 50 thread). Sisakan headroom — jangan mepetkan concurrency Puppeteer persis di angka thread paket Anda, karena pipeline lain (staging environment lain, cron job lain) mungkin memakai kuota yang sama secara bersamaan. Kalau CI runner Anda deploy di region ap-southeast-1 (Singapura) atau ap-southeast-3 (Jakarta), latensi jaringan ke ocr.captchaai.com biasanya bukan bottleneck utama — concurrency dan alokasi thread jauh lebih sering jadi batas nyata.
Reuse BrowserContext tanpa menular efek samping antar test
Bagikan satu BrowserContext antar langkah yang benar-benar non-destruktif — misalnya beberapa smoke test baca-saja yang tidak mengubah state form. Ini memangkas overhead launch browser berulang kali dan mengurangi total waktu run.
Batasannya: jangan reuse context antar test yang saling bergantung pada state form yang bersih, seperti alur checkout multi-langkah. Kalau satu test menyisakan cookie sesi atau field yang belum ke-reset, test berikutnya bisa gagal karena state yang bocor — bukan karena bug sungguhan — dan itu membuat hasil QA Anda tidak bisa dipercaya.
Penutupan resource yang bersih di pipeline CI
Pastikan page dan context ditutup di blok finally, bukan cuma di jalur sukses. Kalau exception terjadi sebelum baris close(), instance browser dan process turunannya tetap hidup di runner. Di CI yang menjalankan banyak job paralel, beberapa context yang bocor saja sudah cukup membuat runner kehabisan memori dan gagal secara acak — gejala yang paling sulit di-debug karena penyebabnya bukan di test yang tampak gagal itu sendiri.
Observability: dari log mentah ke correlation id
Catat log terstruktur untuk setiap eksekusi QA, bukan cuma status pass/fail. Metrik yang dianjurkan: durasi total token, kode respons HTTP, ID tugas dari CaptchaAI, dan kedalaman antrean saat solve dikirim. Pisahkan saluran log per lingkungan (development, staging, pra-produksi) supaya insiden staging tidak tercampur noise dari environment lain, lalu korelasikan lewat distributed tracing (mis. OpenTelemetry) memakai satu correlation id per run. Kemampuan memutar ulang skenario penuh dari satu id biasanya memangkas waktu diagnosis insiden setidaknya separuh, karena Anda tidak perlu merekonstruksi urutan kejadian dari log yang terpisah-pisah.
Pemecahan masalah umum saat QA berjalan paralel
| 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 |
| Beberapa proses paralel saling menunggu | Turunkan concurrency di bawah kuota thread paket Anda dan cek ulang |
Checklist sebelum menjalankan pipeline CI
- Cakupan pengujian dibatasi pada aplikasi sendiri atau sumber daya yang Anda miliki otorisasinya.
- Kunci CaptchaAI disimpan di secret manager CI atau vault, bukan di source code.
- Setiap eksekusi mencatat latensi dan kode status respons.
- Strategi retry idempoten dengan batas atas untuk error sementara.
- Concurrency Puppeteer diset di bawah kuota thread paket CaptchaAI Anda, dengan headroom untuk pipeline lain.
- Pengujian dapat direproduksi di pipeline CI.
- Data uji yang diproses tetap milik environment sendiri, sejalan dengan UU Pelindungan Data Pribadi (UU 27/2022).
Contoh pemanggilan QA lewat CaptchaAI
Contoh Python berikut menunjukkan alur minimum: kirim task reCAPTCHA ke in.php, lalu polling res.php sampai token siap. Pola yang sama berlaku dipanggil dari tiap worker paralel, selama tiap panggilan memakai task_id sendiri-sendiri.
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)
Pertanyaan yang sering diajukan
Berapa banyak BrowserContext yang aman dijalankan paralel dalam satu suite QA?
Tidak ada angka universal — batasnya RAM runner CI Anda dan kuota thread paket CaptchaAI. Mulai dari concurrency rendah (3–5), naikkan bertahap sambil memantau memori runner dan median waktu solve, lalu berhenti sebelum mendekati batas thread paket Anda.
Kapan reuse BrowserContext justru berisiko dibanding aman?
Aman untuk test baca-saja yang tidak mengubah state form. Berisiko untuk alur berurutan seperti checkout multi-langkah, karena state yang tersisa dari test sebelumnya — cookie sesi, field yang belum ke-reset — bisa membuat test berikutnya gagal karena alasan yang salah.
Apa akibatnya kalau context atau page tidak ditutup di blok finally?
Instance browser dan process turunannya tetap berjalan di runner. Di pipeline yang menjalankan banyak job paralel, beberapa context yang bocor saja cukup membuat runner kehabisan memori — kegagalan yang muncul acak dan sulit direproduksi karena penyebabnya bukan di test yang gagal itu sendiri.
Apakah menaikkan paralelisme memengaruhi tingkat keberhasilan CaptchaAI?
Tidak secara langsung — CaptchaAI menyelesaikan tiap task secara independen di sisi worker-nya. Yang berubah kalau concurrency naik terlalu jauh di atas kuota thread paket Anda adalah antrean: task baru menunggu slot thread kosong, sehingga total waktu tunggu naik meski solve individual tetap konsisten.
Strategi apa yang disarankan untuk error sementara seperti ERROR_NO_SLOT_AVAILABLE?
Retry idempoten dengan exponential backoff (mis. 1s, 2s, 4s) dan batas atas percobaan. Error jaringan, respons 5xx, dan ERROR_NO_SLOT_AVAILABLE layak di-retry karena sifatnya sementara; error otorisasi yang persisten (API key salah) tidak boleh terus di-retry.
Panduan terkait yang aman
- Mulai cepat API CaptchaAI
- Pola QA CAPTCHA yang terotorisasi
- Menguji endpoint CAPTCHA pada formulir sendiri
- Debug ketika test browser gagal tapi API berhasil
- Cara menyelesaikan reCAPTCHA v2 lewat API
- Cara menyelesaikan Cloudflare Turnstile lewat API
- Cara menyelesaikan GeeTest v3 lewat API
Uji pola paralelisme dan reuse context ini di lingkungan QA Anda sendiri dengan CaptchaAI.
