Mitmproxy v UI-autotestech: řízení provozu pro QA

Integrace mitmproxy do automatizovaných UI testů: Řízení síťového provozu pro QA inženýry

Proxyování síťového provozu je klíčovým nástrojem pro zvýšení efektivity UI automatizovaných testů. Na rozdíl od manuálního testování, kde se používají Charles Proxy nebo Fiddler, automatizace vyžaduje programovatelná řešení. Mitmproxy, se svým Python API a headless režimem, umožňuje integrovat řízenou síťovou vrstvu přímo do testovací infrastruktury.

Proč je proxy potřebné v automatizovaném testování

UI automatizované testy často trpí "síťovou slepotou" – neschopností detekovat problémy spojené s API, WebSocket nebo backendem. To vede k flaky testům, falešným pádům a obtížím v diagnostice. Integrace proxy řeší tyto problémy přidáním network visibility do testů. Klíčové aplikace:

• Zachycení a analýza HTTP požadavků a odpovědí pro ověření chování aplikace.
• Modifikace status kódů (např. 200 → 404) pro testování zpracování chyb na klientovi.
• Nahrazení dat v JSON/XML odpovědích pro simulaci testovacích stavů bez použití DEV prostředí.
• Logování provozu a sledování sekvence požadavků.
• Práce s WebSocket zprávami, včetně injektování a modifikace za běhu.

Volba mitmproxy jako optimálního řešení

Charles, Proxyman a Fiddler nejsou vhodné pro automatizaci kvůli absenci API pro externí řízení. Mitmproxy, jako open-source nástroj, nabízí:

• Python API pro psaní skriptů, které zachycují a modifikují provoz.
• Headless režim pro spuštění v CI prostředích bez grafického rozhraní.
• Podporu WebSocket, což je kritické pro moderní mobilní a webové aplikace.
• Multiplatformnost (Windows, Linux, macOS).

Mitmproxy funguje ve třech režimech: mitmproxy (interaktivní CLI), mitmweb (webové rozhraní) a mitmdump (neinteraktivní výstup). Pro automatizované testy se používá mitmdump nebo mitmweb s vlastními skripty.

Architektura integrace s testovacím frameworkem

Spuštění mitmproxy probíhá jako samostatný proces, nezávislý na testovacím frameworku. Interakce mezi nimi je organizována přes konfigurační soubor (např. config.json) a Python modul (proxy_handler.py). Základní postup:

• Instalace mitmproxy (např. přes brew install mitmproxy).
• Nastavení certifikátů na testovacích zařízeních pro zachycení HTTPS provozu.
• Spuštění proxy příkazem mitmweb -s proxy_handler.py.
• Dynamické řízení chování proxy přes aktualizaci config.json z testů.

Implementace nahrazení status kódů: praktický příklad

Uvažujme případ modifikace HTTP statusů pro konkrétní API. Konfigurace je nastavena v config.json:

{
    "status": {"api/v1/user": 404, "api/v2/settings": 500}
}

Pro jednorázové nahrazení se používá číselná hodnota, pro dlouhodobé – seznam (např. [404]). Modul proxy_handler.py zpracovává tato nastavení:

import re
import mitmproxy.ctx as ctx
from mitmproxy import http
from file_worker import FileWorker

file_worker = FileWorker()

def response(flow: http.HTTPFlow) -> None:
    url = flow.request.url
    if not flow.response.content:
        return
    cfg = file_worker.get_proxy_params()
    cfg_status = cfg.get("status")
    for api, sc in list(cfg_status.items()):
        if bool(re.compile(api).search(url)):
            flow.response.status_code = int(sc[0] if isinstance(sc, list) else sc)
            ctx.log.info(f"Status code was mocked '{api}' -> {sc}")
            if not isinstance(sc, list):
                del cfg_status[api]
                file_worker.set_proxy_param("status", cfg_status)
                cfg["status"] = cfg_status
            break

Klíčové body implementace:

• Použití regulárních výrazů (modul re) pro flexibilní porovnávání URI.
• Zpracování obou formátů konfigurace (jednorázové a dlouhodobé nahrazení).
• Logování operací pro ladění.
• Oddělení práce se soubory do samostatné třídy (FileWorker) pro čistotu kódu.

Rozšíření funkcionality: mockování dat a logování

Podobně jako nahrazení status kódů lze implementovat modifikaci těla odpovědí. V config.json se přidá sekce "mock":

{
    "mock": {"api/v1/data": {"field": "new_value"}}
}

V proxy_handler.py zpracování vypadá takto:

cfg_mock: dict = cfg.get("mock")
if cfg_mock:
    for mock_api, params in list(cfg_mock.items()):
        if bool(re.compile(mock_api).search(url)):
            data = flow.response.content.decode()
            modified = file_worker.mock(params[0] if isinstance(params, list) else params, data)
            if modified:
                flow.response.content = modified.encode()
                ctx.log.info(f"Param {params} were mocked for '{mock_api}'")
            if not isinstance(params, list):
                del cfg_mock[mock_api]
                file_worker.set_proxy_param("mock", cfg_mock)
                cfg["mock"] = cfg_mock
            break

Pro uložení odpovědí serveru do souborů (např. pro následnou analýzu) se používá sekce "get_response" v config.json. To je užitečné pro:

• Ověření struktury dat v automatických kontrolách.
• Vytvoření referenčních odpovědí pro regresní testování.
• Ladění složitých scénářů interakce s backendem.

Co je důležité

• Network visibility: Integrace proxy odstraňuje "slepota" automatizovaných testů k síťovým problémům, zlepšuje diagnostiku a stabilitu.
• Flexibilita mitmproxy: Python API a podpora WebSocket umožňují vytvářet složité scénáře modifikace provozu bez závislosti na GUI nástrojích.
• Konfigurační řízení: Použití config.json pro dynamické změny chování proxy zjednodušuje integraci s testovacími frameworky.
• Výkonnost: Kód handlerů musí být optimalizován, aby nezpomaloval práci proxy a testů.
• Rozšiřitelnost: Architektura založená na modulech (proxy_handler.py, FileWorker) umožňuje snadno přidávat novou funkcionalitu, jako je throttling nebo analýza WebSocket.

Závěr

Zavedení mitmproxy do UI automatizovaných testů mění proxy z nástroje manuální analýzy na řízenou součást automatizované kontroly. To výrazně rozšiřuje možnosti testování klientských aplikací, zejména ve scénářích vyžadujících simulaci specifických stavů backendu nebo detailní monitorování síťové interakce. Pro úspěšnou integraci je důležité dodržovat rovnováhu mezi flexibilitou konfigurace a výkonností handlerů provozu.

— Editorial Team