Use Cases

Pengujian QA halaman hasil pencarian milik sendiri dengan CAPTCHA

Web Scraping reCAPTCHA v3
Oleh Tim CaptchaAI Indonesia
Diterbitkan pada Jul 10, 2026
Pengujian QA halaman hasil pencarian milik sendiri dengan CAPTCHA
Gambar unggulan tidak tersedia

Lingkup aman: Panduan ini hanya untuk lingkungan QA, staging, dan praproduksi yang Anda punya otorisasinya - pola pengujian dan observabilitas untuk integrasi CAPTCHA sendiri, bukan situs pihak ketiga.

Kalau semua skenario halaman hasil pencarian tiba-tiba merah di pipeline, penyebabnya jarang regresi produk: biasanya ambang skor reCAPTCHA v3 baru diturunkan, dan runner CI Anda cocok dengan profil trafik yang ingin diredam. Jalan keluarnya bukan mematikan proteksi di staging, melainkan mereplikasi konfigurasi CAPTCHA produksi ke lingkungan QA sendiri, mengisinya dengan data sintetis, lalu menyelesaikan tantangan lewat API CaptchaAI supaya assertion kembali menguji logika pencarian, bukan widget-nya.

Tiga pendekatan, dan hanya satu yang menguji jalur produksi

Putuskan dulu bagaimana suite Anda melewati widget:

  • Mematikan CAPTCHA di staging. Paling cepat, tetapi jalur verifikasi token tidak pernah teruji; bugnya baru ketahuan di produksi.
  • Allowlist untuk IP runner CI. Masuk akal untuk smoke test, tetapi menyembunyikan perilaku aplikasi pada skor rendah.
  • Menyelesaikan tantangan lewat API. Rantainya utuh: widget dirender, token diterbitkan, backend memverifikasi, hasil tampil. Hanya opsi ini yang membuat tes Anda mewakili produksi.

Kombinasi praktis: allowlist untuk smoke test per commit, penyelesaian penuh lewat API untuk suite regression.

Kenapa runner CI terlihat seperti trafik bot di halaman pencarian

Halaman hasil pencarian mahal: satu kueri bisa memicu query database, agregasi, dan layanan rekomendasi sekaligus, jadi reCAPTCHA v3 sering dipasang di sana.

Sialnya, suite QA berpola mirip trafik yang ingin diredam: rate permintaan tinggi, kueri identik berulang, tanpa jeda baca, dari IP pusat data runner CI. Skor v3 turun, challenge muncul, dan tes gagal justru karena proteksinya bekerja sesuai desain - kondisi lingkungan, bukan bug aplikasi.

Menghitung kebutuhan thread: contoh tim QA di Jakarta

Ambil tim QA marketplace dengan runner CI di AWS ap-southeast-3 (Jakarta) dan aplikasi di ap-southeast-1 (Singapura). Suite pencarian mereka menjalankan sekitar 40 skenario tiap malam, masing-masing memicu satu tantangan v3.

Karena CaptchaAI menagih per thread bersamaan - bukan per solve - biaya ditentukan konkurensi. Empat worker paralel muat di paket BASIC ($15/bulan, 5 thread); begitu konkurensi naik ke belasan job serentak, STANDARD ($30/bulan, 15 thread) jadi ukuran yang wajar. Jumlah solve per thread tidak dibatasi, jadi menambah skenario tidak menaikkan tagihan. Jarak Jakarta-Singapura sendiri hanya menambah beberapa puluh milidetik per hop - yang lebih sering merusak hasil adalah batas waktu tes yang terlalu ketat.

Langkah 1: siapkan dataset kueri sintetis

Isi indeks staging dengan katalog fiktif, bukan salinan data produksi. Susun 20-50 kueri tetap: hasil kosong, hasil tunggal, paginasi, dan karakter non-ASCII - nama produk berbahasa Indonesia dengan tanda hubung dan singkatan paling sering terlewat.

Simpan kueri dan hasil yang diharapkan dalam satu file fixture agar assertion tidak bergantung pada isi indeks. Ini sekaligus menjauhkan pipeline QA dari data pribadi: UU Pelindungan Data Pribadi (UU 27/2022) membuat salinan data pengguna nyata di staging jadi risiko yang tidak perlu diambil.

Langkah 2: samakan sitekey dan action dengan produksi

Sitekey staging boleh berbeda, tetapi tipe CAPTCHA dan nilai action harus sama. reCAPTCHA v3 mengirim action pada setiap eksekusi dan backend umumnya menolak token yang action-nya tidak cocok, sehingga ketidaksesuaian di sini menghasilkan kegagalan yang membingungkan. Simpan pasangan sitekey-action di variabel environment pipeline, bukan di kode tes.

Kalau formulir Anda menaikkan tantangan ke reCAPTCHA v2 saat skor v3 rendah, buat skenario terpisah. CaptchaAI menyelesaikan reCAPTCHA v3 di bawah 4 detik dan v2 di bawah 60 detik, jadi batas waktu dibedakan per jalur.

Langkah 3: kirim task, polling, lalu pasang token

Alurnya sama untuk bahasa apa pun:

  1. Kirim task ke in.php dengan method=userrecaptcha, googlekey, dan pageurl staging.
  2. Simpan task ID dari respons.
  3. Polling res.php sampai statusnya bukan CAPCHA_NOT_READY.
  4. Pasang token ke field g-recaptcha-response sebelum tes mengirim formulir.

Beri jeda pertama lebih panjang daripada polling berikutnya; mengecek hasil satu detik setelah pengiriman hanya membuang kuota.

Kerangka helper Python untuk suite QA

Kerangka minimum helper suite: satu fungsi mengirim task, satu lagi menunggu hasilnya. Nilai sensitif dibaca dari environment variable.

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)

Kembalikan hasil fetch_qa_result ke driver tes, lalu isikan tokennya ke field CAPTCHA pada formulir pencarian staging.

Langkah 4: buktikan backend benar-benar memverifikasi token

Bagian ini paling sering terlewat: tes yang hanya memeriksa "halaman hasil tampil" tetap hijau meski endpoint menerima token sembarangan. Jalankan tiga assertion negatif sebelum skenario sukses:

  • Permintaan tanpa field token ditolak 400, bukan diteruskan ke layanan pencarian.
  • Token yang sudah dipakai ditolak pada percobaan kedua.
  • Token dengan action salah ditolak walau sitekey-nya benar.

Setelah ketiganya lulus, jalankan jalur positif: token valid masuk, endpoint mengembalikan hasil fiktif sesuai fixture.

Log dan metrik yang membuat kegagalan CI terbaca

Catat log terstruktur tiap eksekusi QA: durasi sampai token diterima, kode status HTTP, task ID, dan kedalaman antrean tes. Korelasikan lewat satu correlation id (misalnya dengan OpenTelemetry) supaya saat pipeline gagal Anda langsung tahu penyebabnya: jaringan runner, sitekey, atau antrean solver.

Gejala umum dan cara mendiagnosisnya

Gejala Kemungkinan penyebab Tindakan
Tes tidak menemukan widget Widget dirender setelah hydration Tunggu selector siap, jangan andalkan jeda tetap
CaptchaAI mengembalikan ERROR_NO_SLOT_AVAILABLE Semua thread paket terpakai Coba ulang dengan jeda meningkat eksponensial, atau naikkan thread
Backend QA menolak token action atau sitekey staging tidak cocok Bandingkan pasangan sitekey-action di konfigurasi tes
Token diterima tapi hasil kosong Fixture indeks belum di-seed Jalankan seeding sebelum suite pencarian
Hijau di lokal, merah di CI API key belum ada di secret CI Periksa injeksi environment variable pada job

Checklist sebelum suite masuk pipeline CI

  • Pengujian dibatasi pada lingkungan yang Anda punya otorisasinya.
  • API key diambil dari secret manager CI, bukan source code.
  • Tiap eksekusi mencatat latensi, kode status respons, dan task ID.
  • Coba ulang idempoten dengan batas atas percobaan.
  • Dataset staging sintetis, tanpa data pengguna nyata.
  • Skenario negatif verifikasi token ikut dijalankan.

FAQ

Apakah lebih praktis mematikan CAPTCHA di staging saja?

Praktis, tetapi mahal kemudian: jalur verifikasi token tidak pernah dieksekusi tes, dan action yang tidak dicek baru ketahuan di produksi. Kompromi wajar: matikan hanya untuk smoke test, penyelesaian penuh tetap di regression.

Tipe CAPTCHA apa saja yang bisa diuji lewat alur ini?

reCAPTCHA v2 dan v3 termasuk varian Enterprise, Cloudflare Turnstile dan Cloudflare Challenge, GeeTest v3, serta CAPTCHA gambar dan grid. hCaptcha dan FunCaptcha (Arkose Labs) belum didukung, GeeTest v4 segera hadir. CaptchaFox, Friendly Captcha, dan Lemin berstatus beta.

Berapa tambahan durasi yang perlu dimasukkan ke batas waktu tes?

Hitung waktu penyelesaian tantangan ditambah overhead polling. reCAPTCHA v3 selesai di bawah 4 detik dan v2 di bawah 60 detik, jadi tetapkan batas waktu per skenario dengan margin untuk jam sibuk.

Bisakah alur ini dipakai pada halaman pencarian milik pihak lain?

Tidak. Panduan ini mengasumsikan domain QA milik sendiri seperti staging.example.com. Untuk properti pihak ketiga, dasarnya izin tertulis pemiliknya, bukan konfigurasi teknis.

Panduan terkait yang aman

Validasi integrasi CAPTCHA Anda di lingkungan sendiri bersama CaptchaAI.

Komentar dinonaktifkan untuk artikel ini.