Jedna paczka do testów GUI, scenariuszy TestQL, shell/terminala, osobnych kontraktów API i ciągłej obserwacji.
To scalone wydanie wcześniejszych Testwins 0.2/0.3 oraz migracji twin_ux / Clonerd.
Nazwa dystrybucji Python: testwins. Landing dla testwins.com jest w osobnym landing/.
ZIP zawiera kod, wheel, sdist, Docker/noVNC, Makefile, profile i dokumentację.
Paczka nie została opublikowana na PyPI, domena nie została wdrożona, repozytoria WUP/Planfile nie zostały zmienione zdalnie.
Wymagania hosta: Docker z Compose v2, Python 3.11–3.13 i GNU Make. Potrzebny dostęp do sieci do pobrania obrazów i zależności. Nie potrzebujesz lokalnego pulpitu ani zainstalowanych przeglądarek.
cp .env.example .env
make landing-check MATRIX=chromium
# Osobny nginx + Testwins: Chromium x desktop/tablet/mobile + scenariusz TestQL.
make report INSTANCE=landing
make vnc-password INSTANCE=landing
make landing-down
http://127.0.0.1:8090/ — landing, http://127.0.0.1:6080/vnc.html — pulpit,
http://127.0.0.1:8088/ — raporty. noVNC pokazuje wykonywany przebieg, nie zachowuje otwartych kart po jego zakończeniu.
# Pełne macierze 3 x 3, wykonywane przez runner:
make landing-check MATRIX=cdp # Chrome, Edge, Brave; Linux amd64
make landing-check MATRIX=engines # Chromium, Firefox, WebKit
# Ciągła obserwacja własnego landing + SSE/SQLite i kontrola zasobów:
make live-novnc
# Panel: http://127.0.0.1:9067/ ; desktop: http://127.0.0.1:6080/vnc.html
make live-novnc-down
Przed drugim środowiskiem zatrzymaj pierwsze: oba mogą zajmować te same porty. Chrome/Edge/Brave współdzielą silnik. Firefox i WebKit nie używają transportu CDP. Emulacja viewportu/touch nie jest fizycznym urządzeniem ani rzeczywistym Safari na iOS. Przykład live domyślnie obserwuje 3 trasy x 3 profile x Chromium, nie trzy silniki.
make bootstrap
. .venv/bin/activate
# Alternatywa bez bootstrap, po utworzeniu i aktywowaniu venv:
python -m pip install './dist/testwins-0.4.0-py3-none-any.whl[live,terminal]'
python -m playwright install chromium
testwins --version
testwins doctor
testwins init moja-aplikacja
Podstawa nie instaluje LLM, YOLO ani TestQL niejawnie. Instaluj potrzebny backend:
python -m pip install '.[testql]' # dystrybucja TestQL z PyPI
make install-testql-source TESTQL_REF=main # jawny wariant źródłowy + kontrola publicznego SDK
python -m pip install '.[llm,cv]' # LiteLLM i OpenCV
python -m pip install '.[desktop,terminal]' # przechwytywanie GUI / PTY
python -m pip install '.[yolo]' # opcjonalne Ultralytics; osobna analiza licencji
main to ruchoma referencja, nie lockfile. Przed wdrożeniem przypnij TESTQL_REF i PLANFILE_REF do przejrzanych commitów.
Obrazy pełnego labu nadal instalują i sprawdzają API TestQL przy budowaniu; obraz live nie potrzebuje tego SDK.
doctor raportuje dostępność backendów, nie wykonuje testów i nie jest bramką poprawności aplikacji.
testwins init ./clonerd-tests --profile clonerd
cd clonerd-tests
make configure BASE_URL=http://127.0.0.1:8891
make validate
make scan # 9 wejściowych tras x 3 profile; GUI tylko do odczytu
make personas # 6 deklaratywnych person x 3 profile + osobny GET /v1/menu
make watch # monitoring wejściowych widoków, nie niejawne klikanie person
Aplikacja musi już działać. Dla Dockerowego wykonawcy użyj originu osiągalnego z jego sieci, nie hostowego 127.0.0.1.
Z katalogu źródeł można też użyć make clonerd-init / make clonerd-check CLONERD_URL=http://127.0.0.1:8891.
Profil zawiera wykonywalne YAML person, nie bibliotekę legacy. Zachowuje layout=desktop dla desktop/tablet i
layout=onepage dla mobile. Nowe kontrakty nie przemilczają brakującej kontrolki. Przykłady dla PDF, budżetu heap i
mutującego API są oddzielne i nie uruchamiają się w domyślnym skanie.
Selektory pochodzą z przesłanych testów: nie zostały sprawdzone na rzeczywistej aplikacji Clonerd.
W scope.json wskazano granice: płatności, semantyka faktury, egzekwowanie RBAC, połączenie noVNC i aktualność danych
nie stają się zweryfikowane od samej obecności elementu. Szczegóły: integrations/clonerd/README.md.
make check APP=/sciezka/do/aplikacji \
APP_IMAGE=php:8.3-cli \
APP_COMMAND='php -S 0.0.0.0:8080 -t public' \
MATRIX=chromium CONFIG=configs/audit.yaml
Podaj obraz, instalację zależności (APP_INSTALL), port i komendę odpowiednie dla swojej aplikacji.
Folder jest kopiowany do osobnego obrazu SUT; audytor GUI go nie dostaje. Wykluczane są standardowe katalogi sekretów,
.env, .auth, pliki *.storage-state.json, repozytorium Git, zależności i cache. To filtr nazw, nie gwarancja wykrycia każdego sekretu.
Domyślnie sieć runtime jest wewnętrzna. Dodatkowe usługi dodaj w COMPOSE_OVERRIDE.
W wydaniu 0.4 plan wszystkich obowiązkowych kroków powstaje przed uruchomieniem przeglądarki.
Jedna nieudana asercja blokuje sukces, nawet przy repeats: 1, bez potwierdzonych naruszeń wizualnych i bez udziału LLM.
Nie wolno zamienić timeoutu, braku przeglądarki lub pominiętego kroku na wynik pozytywny.
testwins run --config konfiguracja.yaml --output artifacts
testwins gate artifacts/KONKRETNY-RUN
testwins verify artifacts/KONKRETNY-RUN
Dla run / gate: 0 = wszystkie zaplanowane kontrakty zaliczone i kompletny zadeklarowany zakres bez potwierdzonych naruszeń;
1 = nieudana obowiązkowa asercja, przekroczony jawny budżet albo potwierdzone naruszenie;
2 = niekompletność, brak wymaganego dowodu lub błąd konfiguracji. Kandydat wizualny nie jest automatycznie potwierdzony.
Kod 0 nie dowodzi poprawności wszystkich niewidzianych stanów aplikacji.
verify sprawdza integralność, a nie poprawność UI. vision raportuje analizę kandydatów, a nie zaliczenie produktu.
Raport zawiera report.json, plan kroków, ich statusy, screenshoty przed/po, DOM, junit.xml, macierz CSV,
manifest plików i propozycje Planfile. JUnit, HTML, CLI i suite używają tej samej bramki.
storage_state, ładowanym do nowego kontekstu; bez automatycznego odczytu profilu hosta.download czeka na rzeczywiste zdarzenie pobrania i sprawdza nazwę, rozmiar, opcjonalny prefix i SHA-256. Payload domyślnie nie jest zachowywany.testwins api wykonuje jawne kontrakty HTTP raz, niezależnie od macierzy urządzeń. POST wymaga allow_mutation i --approve-mutations.pytest -p testwins.pytest_plugin udostępnia testwins_run i testwins_assert_report bez automatycznego skanowania.Przykłady: docs/RELEASE-0.4.md. API i metryki CDP są oddzielone od diagnozy opartej na obrazie/DOM.
Wybierz dashboard, form, commerce lub content i zadeklaruj oczekiwany
feedback, fokus, zmianę wyglądu oraz budżety reakcji i animacji. Testwins wiąże
pomiary z krokami scenariusza i blokuje zaliczenie niespełnionego kontraktu UX.
Profile symulują nawyki, np. klawiaturę i ograniczenie ruchu.
testwins strategies
testwins run --config configs/ux.yaml --output artifacts/ux
testwins ux-review artifacts/ux/KONKRETNY-RUN --output artifacts/ux-review
Przykład aplikacji, konfiguracja subactor/subllm i granice pomiarów:
Strategie UX. ux-review tworzy propozycje
napraw powiązane z dowodami, do przeglądu i ponownego testu.
make wup-integrate WUP_ROOT=/repo/wup # podgląd
make wup-integrate WUP_ROOT=/repo/wup APPLY=1 # lokalny zapis + backup
wup gui watch /repo/aplikacja --config testwins.watch.yaml
WUP integruje live-monitor jako wup gui, nie zmienia działania wup watch. Nie wykonujemy push/PR.
Dokumentacja WUP.
Konfiguracja LiteLLM jest w jednym .env. Model musi obsługiwać obrazy; nazwy modelu nie zgadujemy.
Transfer zdalny wymaga LLM_ALLOW_REMOTE=1. YOLO wymaga lokalnych przejrzanych wag i jawnego zaufania modelowi.
LLM nie wykonuje zmian ani poleceń, a jego wnioski pozostają kandydatami. Live ogranicza kolejkę, równoległość,
CPU/pamięć, retencję, liczbę wywołań i stosuje gradację L0–L3; nie gwarantuje obserwacji wszystkich stron co sekundę.
Vision, live, 92 klasy GUI.
testwins live-export .testwins/live --output exports/review --project moja-aplikacja
testwins publish exports/review/proposals.json --project /repo/aplikacja
# --apply dopiero po przeglądzie; .planfile musi istnieć.
make test # jednostkowe + lokalne HTTP/PTY/CV, bez przeglądarki
make test-browser # wszystkie testy przeglądarkowe, także wymagające normalnej polityki sieci
make test-final # dodatkowo wymaga rzeczywistego SDK TestQL
make package-final # wheel + sdist + kompletny ZIP + SHA256SUMS
Dokładne wykonane testy i ograniczenia środowiska są w verification/STATUS.md. Nie zastępuj ich historycznymi liczbami z dokumentacji poprzednich wersji. Dwa testy integracyjne (pełne odtworzenie localStorage i browser download) pozostają wymagane na docelowym komputerze; w środowisku przygotowania istnieje administracyjna blokada URL. Nie wyłączano ani nie omijano tej polityki. Pełny Docker i zewnętrzne SDK nie były tu uruchomione. Ciężkie dowody z rendererów są w osobnym archiwum weryfikacyjnym; ZIP projektu zawiera podsumowania i testy do odtworzenia.
Apache-2.0 obejmuje własny kod Testwins. Warunki zależności i modeli są oddzielne: THIRD_PARTY.md.
Licensed under Apache-2.0.