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)
Beteiligen Sie sich an der Unterhaltung
Melden Sie sich an, um Ihre Meinung zu teilen.
AnmeldenNoch keine Kommentare.