Integrationen

Browserprofil-Trennung für QA-Tests mit CaptchaAI

Anwendungsbereich: Dieser Leitfaden beschreibt Browserprofil-Trennung für eigene oder autorisierte QA-Umgebungen. Ziel ist reproduzierbares Testen mit getrennten Cookies, Storage-Inhalten und Testkonten. Er behandelt keine Umgehungs-, Verdeckungs- oder Identitätsmaskierungstechniken.

Wenn Teams mehrere Testkonten parallel prüfen, entstehen Fehler oft nicht im CAPTCHA selbst, sondern in verschmutzten Sitzungen: alte Cookies bleiben aktiv, lokaler Speicher überschreibt neue Testdaten oder ein Profil übernimmt versehentlich den Zustand eines anderen Testfalls. Eine klare Profiltrennung macht QA-Läufe stabiler und aussagekräftiger.


Warum Profiltrennung in QA wichtig ist

In Staging- und Preprod-Systemen wollen Sie einzelne Szenarien isoliert nachvollziehen können:

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

Ohne getrennte Profile überlagern sich diese Fälle gegenseitig. Das führt zu schwer reproduzierbaren Ergebnissen und verwischt, ob ein CAPTCHA-Verhalten von der Integration oder vom Restzustand des Browsers stammt.


Was pro Profil getrennt werden sollte

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

Profilbestandteil Warum trennen? Typischer QA-Nutzen
Cookies Sitzungen und Login-Zustände bleiben eindeutig Getrennte Testkonten pro Lauf
Local Storage Feature-Flags und UI-Zustände mischen sich sonst Gleicher Startzustand pro Testfall
Session Storage Kurzlebige Formularzustände bleiben isoliert Saubere Negativtests
Download-/Upload-Pfade Artefakte bleiben pro Testlauf nachvollziehbar Einfachere Fehleranalyse
Umgebungsparameter staging, qa, preprod bleiben getrennt Weniger Konfigurationsdrift

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


Beispiel: Profilzustand für QA speichern

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

Mit dieser Struktur können Sie z. B. ein Profil checkout-first-visit, logged-in-user oder expired-session definieren und denselben Zustand in mehreren Testläufen wiederverwenden.


CaptchaAI in eigener Staging-Suite verwenden

Sobald Profile klar getrennt sind, lässt sich die CAPTCHA-Prüfung pro Testrolle stabil in Ihre Suite einbauen.

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

Hier ist das Profil 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.


Fehlerbehebung

Problem Ursache Lösung
Profil übernimmt alten Zustand Reset vor dem Test fehlt Profilzustand vor jedem Lauf gezielt neu initialisieren
Testkonten mischen sich Gemeinsame Cookie-Datei Ein Profil-File pro Testrolle verwenden
Unterschiede zwischen lokalen und CI-Läufen Uneinheitliche Startdaten Gleiche Fixtures in allen Umgebungen laden
CAPTCHA-Verhalten ändert sich zwischen Profilen Unterschiedliche Testdaten Sitekey, Testrolle und Umgebung protokollieren
Diagnose ist nicht reproduzierbar Zustandsänderungen werden nicht gespeichert Profil-Snapshots und Verifikationsantworten archivieren

Sichere verwandte Leitfäden

  • CaptchaAI Schnellstart
  • CAPTCHA-QA in autorisierten Testumgebungen
  • Kontinuierliche Integration mit CAPTCHA-Tests
  • CAPTCHA-Endpoints in eigenen Webformularen testen

Strukturieren Sie QA-Profile klar nach Testfall und Umgebung – CaptchaAI unterstützt reproduzierbare CAPTCHA-Prüfungen in eigenen Staging-Suiten.

Diskussionen (0)

Noch keine Kommentare.