Browserprofil-Trennung für QA-Tests mit CaptchaAI

Anwendungsbereich: Dieser Leitfaden zeigt Browserprofil-Trennung für eigene oder autorisierte QA-Umgebungen – reproduzierbares Testen mit getrennten Cookies, Storage-Inhalten und Testkonten. Umgehungs-, Verdeckungs- oder Identitätsmaskierungstechniken sind ausdrücklich nicht Gegenstand dieses Artikels.

Getrennte Browserprofile sind in der QA vor allem eine Frage der Reproduzierbarkeit, nicht der Browsermanipulation. Wer mehrere Testkonten, Rollen oder Mandanten gegen dieselbe Staging-Umgebung prüft, braucht pro Testfall einen klar definierten Ausgangszustand – sonst lässt sich am Ende nicht mehr sagen, ob ein fehlgeschlagener CAPTCHA-Flow an der Integration oder an übrig gebliebenen Cookies lag. Dieser Leitfaden zeigt, wie Sie Profile pro Testrolle isolieren und CaptchaAI so einbinden, dass jeder Lauf dasselbe Ergebnis liefert.

Warum Profiltrennung QA-Läufe belastbar macht

In Staging- und Preprod-Systemen wollen Sie einzelne Szenarien isoliert nachvollziehen können. Ohne Trennung überlagern sich diese Fälle gegenseitig, und die Diagnose wird unzuverlässig:

• Erstbesuch ohne vorhandene Sitzung
• Rückkehr eines bekannten Testkontos
• Wechsel zwischen Regionen oder Mandanten
• parallele Regressionstests mit mehreren Rollen

Sobald alte Cookies aktiv bleiben, lokaler Speicher neue Testdaten überschreibt oder ein Profil versehentlich den Zustand eines anderen Testfalls übernimmt, verwischt die Grenze zwischen Integration und Restzustand des Browsers. Eine klare Profiltrennung macht QA-Läufe stabiler, vergleichbar und aussagekräftiger.

Welche Zustandsdaten pro Profil getrennt gehören

Für QA reicht es, zustandsbehaftete Daten sauber je Profil zu trennen. Der Fokus liegt auf Reproduzierbarkeit, nicht auf Browsermanipulation.

Wenn Ihr Team Profilmanager einsetzt, sollten diese ausschließlich als QA-Werkzeug für saubere Sitzungsgrenzen dienen. Entscheidend ist nicht das Tool, sondern die Disziplin, Profile pro Testfall klar zu definieren und nach dem Lauf konsistent zurückzusetzen.

Ein Hinweis zur DSGVO: Cookies und IP-Adressen können personenbezogen sein. Verwenden Sie in QA-Profilen daher synthetische Testkonten statt echter Nutzerdaten, und dokumentieren Sie, welche Zustände Sie speichern. Das hält Staging-Läufe rechtlich unkompliziert und Ihre Testdaten sauber.

Profilzustand pro Testrolle speichern und laden

Ein pragmatischer Ansatz ist, den Startzustand pro Testrolle als Datei zu speichern und bei jedem Lauf kontrolliert zu laden.

from pathlib import Path
import json


PROFILE_DIR = Path("./qa-browser-profiles")
PROFILE_DIR.mkdir(exist_ok=True)


def state_file(profile_name: str) -> Path:
    return PROFILE_DIR / f"{profile_name}.json"


def save_profile_state(profile_name: str, cookies: list[dict], local_storage: dict) -> None:
    payload = {
        "profile": profile_name,
        "cookies": cookies,
        "local_storage": local_storage,
    }
    state_file(profile_name).write_text(json.dumps(payload, indent=2), encoding="utf-8")


def load_profile_state(profile_name: str) -> dict:
    path = state_file(profile_name)
    if not path.exists():
        return {"cookies": [], "local_storage": {}}
    return json.loads(path.read_text(encoding="utf-8"))

So definieren Sie feste Rollen wie checkout-first-visit, logged-in-user oder expired-session und verwenden denselben Zustand in mehreren Testläufen wieder. Jede Rolle bleibt unabhängig, und die Ergebnisse eines Laufs lassen sich jederzeit reproduzieren.

CaptchaAI in die Staging-Suite einbinden

Sobald die Profile klar getrennt sind, lässt sich die CAPTCHA-Prüfung pro Testrolle stabil in Ihre Suite einbauen. CaptchaAI löst dabei die Abfrage – etwa reCAPTCHA v2 oder Cloudflare Turnstile – und Ihre Suite verifiziert das Ergebnis gegen den eigenen Staging-Endpunkt.

import requests
import time


CAPTCHAAI_API_KEY = "YOUR_API_KEY"


def solve_for_staging(page_url: str, sitekey: str) -> str:
    submit = requests.post(
        "https://ocr.captchaai.com/in.php",
        data={
            "key": CAPTCHAAI_API_KEY,
            "method": "userrecaptcha",
            "googlekey": sitekey,
            "pageurl": page_url,
            "json": 1,
        },
        timeout=30,
    )
    submit.raise_for_status()
    submit_json = submit.json()
    if submit_json.get("status") != 1:
        raise RuntimeError(submit_json.get("request", "unknown submit error"))

    task_id = submit_json["request"]
    for _ in range(30):
        time.sleep(5)
        result = requests.get(
            "https://ocr.captchaai.com/res.php",
            params={"key": CAPTCHAAI_API_KEY, "action": "get", "id": task_id, "json": 1},
            timeout=30,
        )
        result.raise_for_status()
        result_json = result.json()
        if result_json.get("status") == 1:
            return result_json["request"]

    raise TimeoutError("CaptchaAI task timed out in QA")


def verify_profile_flow(profile_name: str, page_url: str, sitekey: str) -> dict:
    token = solve_for_staging(page_url, sitekey)
    response = requests.post(
        "https://staging.example-app.test/qa/captcha/verify",
        json={
            "profile": profile_name,
            "pageUrl": page_url,
            "token": token,
            "environment": "staging",
        },
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

Das Profil ist hier nur ein Reproduzierbarkeitsanker. Das CAPTCHA-Ergebnis wird nicht für fremde Seiten weitergereicht, sondern für einen klar dokumentierten QA-Check gegen die eigene Verifikation verwendet – Rolle, Umgebung und Token bleiben zusammen protokolliert.

Profiltrennung in CI-Pipelines konsistent halten

In vielen DACH-Teams laufen Regressionstests nicht lokal, sondern in GitLab CI – häufig auf eigenen Runnern bei Hetzner oder IONOS. Genau hier zahlt sich die dateibasierte Profiltrennung aus: Weil der Startzustand jeder Testrolle als Fixture im Repository liegt, lädt ein CI-Runner exakt dieselben Cookies und Storage-Werte wie die Entwicklerin auf ihrem Notebook. Der klassische Bruch zwischen „läuft lokal“ und „schlägt in der Pipeline fehl“ verschwindet damit fast vollständig.

Behandeln Sie die Profildateien wie Testdaten: versioniert, ohne echte Zugangsdaten und mit einem klaren Reset zu Beginn jedes Jobs. Der CaptchaAI-Schlüssel gehört in eine CI-Variable, nicht in den Code – der Platzhalter YOUR_API_KEY im Beispiel oben markiert genau diese Stelle. So bleibt ein Shopware- oder Formular-Checkout in Staging über alle Umgebungen hinweg deterministisch prüfbar.

Typische Probleme und Lösungen

Häufige Fragen

Wie strukturiere ich Profile pro Testfall am besten?

Ein Profil pro Testrolle, nicht pro Browserinstanz. Definieren Sie feste Rollen wie checkout-first-visit, logged-in-user oder expired-session, speichern Sie deren Startzustand als Datei und laden Sie ihn zu Beginn jedes Laufs. So bleibt jeder Testfall unabhängig und wiederholbar.

Muss ich Profile zwischen den Läufen zurücksetzen?

Ja. Setzen Sie den Zustand vor jedem Lauf gezielt zurück, statt sich auf Reste des vorherigen Tests zu verlassen. Nur mit einem definierten Ausgangszustand sind Ergebnisse vergleichbar – besonders zwischen lokaler Ausführung und CI.

Kann ich einen CaptchaAI-Schlüssel für mehrere Profile parallel nutzen?

Ja. CaptchaAI rechnet Thread-basiert ab, nicht pro Lösung: Ein Schlüssel bedient so viele gleichzeitige Läufe, wie Ihr Tarif Threads bereitstellt. BASIC (15 $/Monat, 5 Threads) deckt kleine Suiten ab, STANDARD (30 $/Monat, 15 Threads) und ADVANCE (90 $/Monat, 50 Threads) skalieren parallele QA-Läufe nach oben – mit unbegrenzten Lösungen pro Thread.

Wie gehe ich in Test-Profilen mit Cookies und DSGVO um?

Verwenden Sie synthetische Testkonten statt echter Nutzerdaten. Cookies und IP-Adressen können personenbezogen sein; halten Sie Testdaten künstlich und dokumentieren Sie, welche Zustände Sie speichern. Das reduziert den rechtlichen Aufwand in Staging spürbar.

Welche CAPTCHA-Typen deckt CaptchaAI in QA-Flows ab?

Für Web-QA relevant sind vor allem reCAPTCHA v2, reCAPTCHA v3 und Cloudflare Turnstile sowie Bild- und Text-CAPTCHAs. hCaptcha und FunCaptcha werden nicht unterstützt; GeeTest v4 ist bald verfügbar. Prüfen Sie die Abdeckung gegen Ihren konkreten Testfall.

Verwandte Leitfäden

• CaptchaAI-Schnellstart einrichten
• CAPTCHA-QA in autorisierten Testumgebungen
• CAPTCHA-Tests in die CI-Pipeline einbinden
• CAPTCHA-Endpoints in eigenen Webformularen prüfen

Definieren Sie QA-Profile klar nach Testrolle und Umgebung – CaptchaAI liefert reproduzierbare CAPTCHA-Prüfungen in Ihren eigenen Staging-Suiten.