Ticketing kuyruğu ve checkout akışları için CAPTCHA testi

Güvenli kapsam: Bu kılavuz yalnızca size ait veya açıkça yetkilendirilmiş QA, staging ve ön üretim ortamlarını kapsar. Konu, kendi CAPTCHA entegrasyonunuzun tanılaması, testi ve gözlemlenebilirliğidir — üçüncü taraf ticketing siteleri, gerçek satışlar veya yetkisiz akışlar kapsam dışıdır.

Etkinlik satışa çıkmadan önce yanıtlamanız gereken tek soru şu: kuyruk ve checkout akışınızdaki CAPTCHA, ani yük altında token'ı zamanında döndürüyor mu? Bunu öğrenmenin güvenli yolu, canlı satışa hiç dokunmadan kendi staging kopyanızda sahte etkinlikler ve test koltuklarıyla akışı uçtan uca çalıştırmaktır. Bu kılavuz, CaptchaAI'yi bu QA döngüsüne nasıl bağlayacağınızı gösterir.

Neden staging ortamında CAPTCHA testi yaparsınız?

Yüksek talepli bir etkinlikte kuyruk saniyeler içinde dolar; checkout adımındaki birkaç saniyelik CAPTCHA gecikmesi, kullanıcıyı koltuğunu kaybetmeden önce bekletir. Türkiye'deki e-ticaret ve fintech ekipleri, ödeme adımını (checkout) yoğun sezon öncesinde zaten yük testine tabi tutar — CAPTCHA doğrulaması da bu akışın kritik bir parçasıdır ve aynı titizlikle test edilmelidir.

Test senaryolarında gerçek kullanıcı verisi kullanmayın. Sahte etkinlik, sahte koltuk ve tr-TR biçimli kukla kayıtlarla çalışmak hem KVKK açısından güvende kalmanızı sağlar hem de üretim verisini hiç riske atmaz. Amaç bir bileti "kapmak" değil; kendi entegrasyonunuzun ölçülebilir biçimde doğru çalıştığını kanıtlamaktır.

Kapsamı netleştirin

• Yalnızca size ait veya yetkilendirilmiş ticketing platformları.
• Sahte etkinlikler, test koltukları, sahte biletler ve test ödeme token'ları.
• Dahili kuyruk ve QA uç noktalarının doğrulanması.
• Üçüncü taraf platform, gerçek bilet satışı veya üretim ödemesi yok.

Dahili kuyruk modelini kopyalayın

Önce üretimdeki kuyruk mimarisini staging'de birebir yeniden kurun. QA kullanıcısı https://staging.example.com/ticketing/queue-test adresinde sahte kuyruğa girer, bir sıra konumu alır ve slot açıldığında https://staging.example.com/ticketing/checkout-test adresine yönlendirilir. Bu iki aşamayı ayrı ayrı test etmek önemlidir: kuyruk girişi ile checkout, farklı sitekey ve farklı zamanlama davranışına sahip olabilir.

Sahte etkinlik, koltuk ve ödeme verileri tanımlayın

Test verilerini kod içinde sabit ve kolay okunur tutun. Aşağıdaki yapı, tek bir sahte etkinlik ve 20 test koltuğu ile simüle bir ödeme token'ı üretir:

FAKE_EVENT = {
    'id': 'evt_qa_001',
    'url': 'https://staging.example.com/ticketing/fake-event',
    'seats': [{'row': 'A', 'col': i, 'price_cents': 5000} for i in range(1, 21)],
}
FAKE_PAYMENT = {'token': 'qa_pm_token_demo'}

CaptchaAI ile staging görevini gönderin

Kuyruk veya checkout sayfasındaki CAPTCHA widget'ının sitekey ve pageurl değerlerini alın, görevi CaptchaAI'ye gönderin ve sonucu periyodik olarak sorgulayın. CaptchaAI reCAPTCHA v2, reCAPTCHA v3 ve Cloudflare Turnstile'ı destekler; ticketing akışlarında en sık karşılaştığınız türler bunlardır.

import os, requests, time
API_KEY = os.environ['CAPTCHAAI_API_KEY']

def solve_recaptcha_v2(sitekey, pageurl):
    r = requests.post('https://ocr.captchaai.com/in.php', data={
        'key': API_KEY, 'method': 'userrecaptcha',
        'googlekey': sitekey, 'pageurl': pageurl, 'json': 1,
    }).json()
    tid = r['request']
    while True:
        time.sleep(5)
        rr = requests.get('https://ocr.captchaai.com/res.php', params={
            'key': API_KEY, 'action': 'get', 'id': tid, 'json': 1,
        }).json()
        if rr['status'] == 1:
            return rr['request']

Token'ı QA backend'inde doğrulayın

Dönen token'ı dahili QA bilet sipariş uç noktanıza gönderin. Backend, CAPTCHA token'ını doğrular, sahte koltuğu kilitler ve simüle edilmiş bir sipariş kimliği döndürür. Bu adımda hiçbir gerçek bilet işlenmez — sadece entegrasyonun token'ı kabul edip etmediğini ölçersiniz.

Daha küçük ve widget odaklı bir doğrulama için createTask/getTaskResult uç noktalarını kullanan aşağıdaki minimal akış yeterlidir. Bu örnek, staging'deki tek bir CAPTCHA widget'ını uçtan uca test etmek için gereken en az kodu gösterir:

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()

Pass/fail kararı ve loglama

Bir testin başarılı sayılması için üç koşulun aynı anda sağlanması gerekir: token backend tarafından kabul edilir, sahte koltuk kilitlenir ve uçtan uca gecikme dahili eşiğinizin altında kalır. Her çalıştırmanın toplam token süresini, HTTP yanıt kodunu ve görev kimliğini qa_kasasi altında saklayın. Böylece bir başarısızlık raporunu tek bir kimlikten yeniden oynatabilirsiniz.

Gözlemlenebilirlik

Her QA çalıştırması için yapılandırılmış günlükler üretin. Toplam token süresi, HTTP yanıt kodu, görev kimliği ve kuyruk derinliği gibi ölçümler tablolarınızı ve uyarılarınızı besler. Ortamlarınızı (geliştirme, staging, ön üretim) ayrı kanallara yazın ve dağıtık izleme (örneğin OpenTelemetry) ile bağıntı kimliklerini eşleştirin. Europe/Istanbul saat dilimini loglarınızda tutarlı kullanmak, sezon başlangıcı gibi zaman kritik testlerde olayları doğru sıralamak için önemlidir. Tek bir kimlikten tüm senaryoyu yeniden oynatabilmek, olay sırasında tanılama süresini belirgin biçimde kısaltır.

QA öncesi kontrol listesi

• Kapsam kesinlikle kendi uygulamalarınız veya yetkilendirilmiş kaynaklarla sınırlıdır.
• CaptchaAI anahtarı CI gizli deposunda veya kasada saklanır, kaynak kodda asla bulunmaz.
• Her çalıştırma için çağrı süresi ve yanıt kodu kayıt altına alınır.
• Geçici hatalar için idempotent yeniden deneme stratejisi kuruludur.
• Testler sürekli entegrasyon ortamınızdan tekrarlanabilir biçimde yeniden oynatılır.

Sorun giderme

Sık sorulan sorular

Bu testler üretim satışına veya gerçek kullanıcılara dokunur mu?

Hayır. Tüm örnekler staging.example.com gibi size ait yetkilendirilmiş ortamları varsayar. Üretimdeki CAPTCHA korumasını staging kopyanızda yeniden üretir, gerçek bilet ve gerçek ödeme kullanmazsınız.

Kuyruk ve checkout için hangi CAPTCHA türlerini test edebilirim?

CaptchaAI reCAPTCHA v2, reCAPTCHA v3 ve Cloudflare Turnstile'ı destekler; ticketing akışlarında bunlarla çalışabilirsiniz. hCaptcha ise şu anda desteklenmez, dolayısıyla bu akışa dahil etmeyin.

Aynı anda kaç QA çalıştırması yürütebilirim?

CaptchaAI thread tabanlı fiyatlandırma kullanır; her thread bir eşzamanlı görev anlamına gelir. BASIC ($15/ay, 5 thread) planla beş test paralel koşabilir, yük senaryolarını büyütmek için daha yüksek thread'li planlara geçebilirsiniz. Fiyatlar USD'dir ve aylık öngörülebilir kalır.

API anahtarımı test kodunun içinde saklayabilir miyim?

Hayır. Anahtarı CI gizli yöneticisi, ortam değişkeni veya kasa hizmeti üzerinden enjekte edin. Kod tabanına işlenen bir anahtar derhal döndürülmelidir.

İlgili güvenli kılavuzlar

• CaptchaAI hızlı başlangıç rehberi
• Yetkili ortamlarda CAPTCHA QA testi
• Kendi web formlarınızda CAPTCHA uç noktası testi
• Tarayıcı testi başarısız, 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 staging ortamınızda CaptchaAI ile uçtan uca doğrulayın.