Baseline i diffy walkera
Baseline i diffy porównują dwa autonomiczne walki tej samej aplikacji. Pomagają oddzielić nowe, utrzymujące się i rozwiązane ustalenia oraz pokazują, gdzie zmienił się zapisany stan UI.
Baseline to punkt odniesienia do porównań, a nie certyfikacja. Przypnij go dopiero po sprawdzeniu celu, stanu uwierzytelnienia, limitów, ustaleń i pokrycia.
Zalecany przebieg pracy
- Uruchom i przejrzyj walk uznany za poprawny.
- Przypnij go przez
set_walk_baseline. - Wdróż zmianę i uruchom nowy walk z porównywalną konfiguracją.
- Wywołaj
diff_walksz dwoma ID walk. - Przejrzyj raport rekursywny i każde ustalenie blocker/major.
- Uruchom zapisane scenariusze dla przepływów, gdzie liczy się deterministyczne pokrycie.
set_walk_baseline(
walk_id="<reviewed-walk>",
app_name="my-app",
notes="Reviewed staging reference for revision <sha>"
)
diff_walks(
base_walk_id="<reviewed-walk>",
new_walk_id="<candidate-walk>"
)Tożsamość i ograniczenia porównań
Stany są adresowane treścią na podstawie sygnatur trasy i DOM. Ustalenia są łączone z znormalizowanymi kluczami deduplikacji. Dzięki temu możliwe są stabilne porównania, ale dynamiczna treść nadal może sprawić, że jeden logiczny ekran wygląda na nowy, a normalizacja czasem nieoczekiwanie scala lub dzieli ustalenia.
Dla wiarygodnego porównania utrzymuj te same wejścia:
- aplikacja i środowisko;
- uwierzytelnione konto i rola;
- seed URL i dozwolone origins;
- tryb walkera, limity state/depth/action i profil fuzz; oraz
- feature flags i dane testowe.
Jeśli te wejścia się różnią, udokumentuj różnicę zamiast traktować liczby jako sygnał regresji jakości release.
Dostępne narzędzia
| Narzędzie | Cel |
|---|---|
set_walk_baseline | Przypina jeden przejrzany walk na klucz owner/app |
get_walk_baseline / list_walk_baselines | Sprawdza bieżące odniesienia |
clear_walk_baseline | Usuwa przypięcie bez usuwania walk |
diff_walks | Porównuje stany i ustalenia między dwoma własnymi walkami |
walk_recursive_report | Renderuje zapisane drzewo stanów z adnotacjami zmian |
walk_findings_to_tickets | Tworzy payloady trackera dla wybranych ustaleń |
run_all_app_scenarios | Kolejkuje zapisane scenariusze dla aplikacji |
Eksport ticketów zwraca payloady JSON dla Linear, Jira lub GitHub. Nie publikuje ich. Przejrzyj tytuły, linki evidence, severity, wrażliwą treść, projekt i assignee, zanim cokolwiek wyślesz do zewnętrznego trackera.
Interpretacja release
Przydatny sygnał kandydata to:
- brak nowego ustalenia blocker lub major przy porównywalnym pokryciu;
- docelowe ustalenie wygląda na rozwiązane;
- ważne zapisane scenariusze przechodzą w zamierzonym środowisku; oraz
- ktoś sprawdza usunięte stany lub zmniejszone pokrycie.
Nie uznawaj release za green tylko dlatego, że findings_new wynosi zero. Nieudane
logowanie, wczesny timeout, mniejsza frontier lub niedostępny tester też mogą dać mniej
ustaleń.