Kendi QA'nız için ileri düzey Puppeteer + CaptchaAI kalıpları

Güvenli kapsam: Bu rehber yalnızca size ait veya yetkilendirilmiş QA, staging ve ön üretim ortamları içindir. Ele alınan kalıplar kendi CAPTCHA entegrasyonlarınızın tanılama, test ve gözlemlenebilirliğine yöneliktir — üçüncü taraf siteleri veya yetkisiz akışları kapsamaz.

Tek bir CAPTCHA'yı CaptchaAI ile çözmek birkaç satır kod meselesidir. Asıl zorluk, onlarca QA senaryosunu tek bir Puppeteer sürecinde — CI kotanızı zorlamadan ve bellek sızdırmadan — paralel çalıştırmaya başladığınızda ortaya çıkar. Bu rehber tam olarak bu ölçek sorununu ele alır: kontrollü paralelizm, BrowserContext yeniden kullanımı, temiz kapanış ve her çalıştırmayı izlenebilir kılan yapılandırılmış günlükleme.

Puppeteer'da kontrollü paralelizm: kotayı değil throughput'u yönetin

QA suite'iniz büyüdükçe reflekssel çözüm "daha fazla sekme aç" olur — ama sınırsız eşzamanlılık iki ayrı yerde patlar: yerel bellekte ve CaptchaAI thread bütçenizde. Bu iki sınırı ayrı düşünün. Puppeteer tarafında eşzamanlı page sayısını bir kuyrukla sabitleyin; her sayfa yaklaşık 50–100 MB tükettiği için 8 GB RAM'de 5–10 eşzamanlı sayfa makul bir tavandır. CaptchaAI tarafında ise eşzamanlılığı plan thread sayınıza göre ölçün: BASIC ($15/ay, 5 thread) beş in-flight çözümü aynı anda taşır, ADVANCE ($90/ay, 50 thread) elli. Gerçek eşzamanlılığı bu iki tavanın küçüğüyle sınırlayın ve staging ya da dahili kotalarınızı asla zorlamayın.

BrowserContext yeniden kullanımı

Her senaryo için yeni bir tarayıcı başlatmak toplam süreyi kolayca ikiye katlar. Tahripsiz adımlar arasında tek bir tarayıcıyı ayakta tutup her senaryoya izole bir BrowserContext verin: çerezler ve depolama senaryolar arasında sızmaz, ama soğuk başlatma maliyetini yalnızca bir kez ödersiniz. Oturum durumunu paylaşması gereken adımlar aynı context'i, izole olması gerekenler ayrı context'leri kullanır. Kural basit: durumu paylaşın, süreci değil.

Temiz kapanış: handle sızıntısını önleyin

CI'da en sinsi hata, testler geçtiği halde sürecin bir türlü kapanmamasıdır. page ve context'i her zaman finally bloğunda kapatın; böylece bir senaryo istisna fırlatsa bile geride handle kalmaz. Uzun süren pipeline'larda kapanmayan tek bir context, birkaç yüz çalıştırma sonra runner'ı belleksiz bırakır. Bir hata koşusundan sonra --disable-dev-shm-usage ile çalışmak paylaşımlı bellek darboğazını da azaltır.

CaptchaAI ile örnek QA çağrısı

Aşağıdaki Python örneği, kendi staging ortamınızdaki bir CAPTCHA widget'ını CaptchaAI üzerinden test etmek için gereken minimal akışı gösterir: görevi gönderin, taskId'yi alın, sonucu sorgulayın.

import os
import requests

API_KEY = os.environ['CAPTCHAAI_KEY']
QA_PAGE_URL = os.environ['QA_PAGE_URL']  # ör. https://staging.example.com/qa-login
QA_SITE_KEY = os.environ['QA_SITE_KEY']


def submit_qa_recaptcha() -> str:
    payload = {
        'clientKey': API_KEY,
        'task': {
            'type': 'NoCaptchaTaskProxyless',
            'websiteURL': QA_PAGE_URL,
            'websiteKey': QA_SITE_KEY,
        },
    }
    response = requests.post(
        'https://api.captchaai.com/createTask',
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()['taskId']


def fetch_qa_result(task_id: str) -> dict:
    payload = {'clientKey': API_KEY, 'taskId': task_id}
    response = requests.post(
        'https://api.captchaai.com/getTaskResult',
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

Gözlemlenebilirlik: her çalıştırmayı yeniden oynatın

Her QA çalıştırması için yapılandırılmış (JSON) günlükler üretin. Toplam token süresi, HTTP yanıt kodu, görev kimliği ve kuyruk derinliği gibi ölçümler panolarınızı ve uyarılarınızı besler. Ortamları — geliştirme, staging, ön üretim — ayrı kanallara yazın ve dağıtık izleme (örneğin OpenTelemetry) ile her çalıştırmaya bir bağıntı kimliği (correlation id) taşıyın. Zaman damgalarını Europe/Istanbul yerine UTC tutup panoda yerelleştirin; böylece farklı runner'ların günlükleri hizalanır. Tek bir bağıntı kimliğinden tüm senaryoyu yeniden oynatabilmek, bir olay sırasında tanılama süresini gözle görülür biçimde kısaltır.

Ödeme adımı QA'sı: Türkiye'den bir senaryo

Türkiye'de QA yükünün büyük kısmı e-ticaret ve ödeme akışlarında yoğunlaşır. Tipik senaryo şu: çok adımlı bir kayıt ya da ödeme adımı formunun son ekranında bir CAPTCHA çıkar ve otomatik regresyon testiniz tam orada durur. Doğru kalıp, üretim sitesini hedeflemek değil — o korumayı staging.example.com/qa-login gibi kendi staging kopyanızda yeniden üretip CaptchaAI ile doğrulamaktır. Test verisinde gerçek müşteri bilgisi kullanıyorsanız, üretilen ya da kazınan kişisel verilerin KVKK kapsamına girdiğini unutmayın; dummy veriyle (+90 formatlı telefonlar, tr-TR locale) çalışın ve testleri yalnızca yetkili ortamlarla sınırlayın. USD bazlı, thread başına sabit fiyatlandırma, TL oynaklığından bağımsız öngörülebilir bir QA maliyeti sağlar — bu da tekrarlanan CI çalıştırmalarında bütçelemeyi kolaylaştırır.

Sorun giderme

Üretim öncesi kontrol listesi

• Kapsam kesinlikle kendi uygulamalarınız veya yetkilendirilmiş kaynaklarla sınırlı.
• CaptchaAI anahtarı CI gizli deposunda ya da kasada saklanır; kaynak kodda asla bulunmaz.
• Her çalıştırmada çağrı süresi ve yanıt kodu kayıt altına alınır.
• Geçici hatalar için idempotent, üstel geri çekilmeli (exponential backoff) yeniden deneme kuruludur.
• Eşzamanlılık hem RAM hem thread bütçesinin küçüğüyle sınırlandırılmıştır.
• Testler CI ortamınızdan tekrarlanabilir biçimde yeniden oynatılabiliyor.

Sık sorulan sorular

CaptchaAI thread sayısı ile Puppeteer sayfa eşzamanlılığı aynı şey mi?

Hayır. Puppeteer eşzamanlılığı yerel RAM'inizle sınırlıdır; CaptchaAI thread sayısı ise aynı anda kaç çözümü işleme alabileceğinizi belirler. İki tavanı ayrı ölçün ve gerçek eşzamanlılığı küçük olanına sabitleyin.

QA çalıştırmalarımı CI'da nasıl tekrarlanabilir kılarım?

Her çalıştırmaya bir bağıntı kimliği verin, girdileri ve yanıt kodlarını günlükleyin, anahtarları ortam değişkeni veya kasa üzerinden enjekte edin. Böylece aynı senaryo farklı runner'larda birebir yeniden oynatılır.

ERROR_NO_SLOT_AVAILABLE hatası ne anlama geliyor?

O an tüm thread'lerinizin dolu olduğu anlamına gelir. Üstel geri çekilmeli (1s, 2s, 4s) idempotent bir yeniden deneme genelde yeterlidir; hata kalıcıysa daha yüksek thread sayılı bir plan gerekir.

Kendi staging ortamım yoksa üretim CAPTCHA'sını nasıl test ederim?

Üretim trafiğini hedeflemeyin. Aynı CAPTCHA türünü ve sitekey yapılandırmasını staging.example.com/qa-login gibi izole bir kopyada yeniden üretip orada doğrulayın.

Güvenli ilgili kılavuzlar

• CaptchaAI hızlı başlangıç rehberi
• Yetkili CAPTCHA QA testleri
• Kendi formlarınızda CAPTCHA endpoint testleri
• Tarayıcı testi başarısız ama API başarılı: hata ayıklama
• reCAPTCHA v2'yi API ile çözme
• Cloudflare Turnstile'ı API ile çözme
• GeeTest v3'ü API ile çözme

CAPTCHA entegrasyonunuzu kendi ortamınızda CaptchaAI ile doğrulayın.