Przykład techniczny · dane demonstracyjne

Testy integracji API
i zachowania interfejsu

Wykonywalny pakiet testów dla synchronizacji zamówień B2B: od danych źródłowych, przez mapowanie, po odpowiedź systemu docelowego i raport PASS/FAIL.

Zakres demonstracyjny12 deterministycznych scenariuszy2 syntetyczne endpointyRaport wartości oczekiwanych i rzeczywistych

Wejście

Payload źródłowy i kontrakt odpowiedzi API.

Jak działa kontrola

Mapowanie → żądanie HTTP → walidacja odpowiedzi.

Co system wykrywa

Status, schemat, mapowanie, duplikat i timeout.

Co otrzymujesz

Wartości oczekiwane i rzeczywiste, różnice JSON i raport JSON/CSV.

Jak odbierany jest wynik

Wyniki zgadzają się z macierzą scenariuszy; dodatek async: PASS → jedna regresja → PASS.

ŹródłoSystem AGET /source/orders

→

KontraktWalidacja i mapowanie12 scenariuszy testowych

→

CelSystem BPOST /target/orders

→

OdbiórRaport testówPASS / FAIL

Odbiór dostarczania webhooków

HMAC-SHA256, klucz idempotencji, duplikat dostarczenia, limit czasu i ponowienie. Izolowany odbiornik wykonuje scenariusze w jednym żądaniu do API. Timeout jest kontrolowaną symulacją transportu.

Referencja: wszystkie testy PASS. Kontrolowana zmiana: wyłączenie deduplikacji jednego dostarczenia. Oczekiwane odrzucenie błędnego wejścia oznacza PASS testu.

Pakiet scenariuszy

Wynik wykonania

Zamierzone wyniki FAIL wykazują wykrycie rozbieżności — nie oznaczają błędu aplikacji.

12scenariuszy

Pakiet sprawdzi mapowanie pól, walidację kontraktu, statusy HTTP, idempotencję, zgodność danych oraz zachowanie retry.

API oparte na kontrakcie

Walidacja kontraktu i kompatybilności

Mały kontrakt odpowiedzi jest wykonywany na sześciu odpowiedziach syntetycznych. Dodatkowe pole opcjonalne zachowuje zgodność, a brak pola wymaganego lub zmiana typu narusza kontrakt.

Wersja kontraktutarget-order-response/1.2

Zgodne2

Niezgodne lub błędne4

Scenariusz	Wersja odpowiedzi	Wynik	Kompatybilność	Pole / reguła	Oczekiwane / rzeczywiste
`CONTRACT-BASELINE` Kontrakt referencyjny	target-order-response/1.2	PASS	referencyjna	response CONTRACT_REQUIRED_FIELDS	odpowiedź zgodna z kontraktem zgodne
`CONTRACT-MISSING` Brak wymaganego pola	target-order-response/1.2-bad-missing	FAIL	niezgodne	targetId CONTRACT_REQUIRED_FIELDS	obecne brak
`CONTRACT-TYPE` Nieprawidłowy typ pola	target-order-response/1.2-bad-type	FAIL	niezgodne	targetId CONTRACT_FIELD_TYPE	string number
`CONTRACT-ENUM` Nieprawidłowa wartość enum	target-order-response/1.2-bad-enum	FAIL	niezgodne	lifecycle CONTRACT_ENUM_VALUE	NEW\|CONFIRMED\|SHIPPED ARCHIVED
`CONTRACT-ADDITIVE` Dodane pole opcjonalne	target-order-response/1.3-compatible	PASS	zgodne	response CONTRACT_ADDITIVE_OPTIONAL	odpowiedź zgodna z kontraktem zgodne
`CONTRACT-BREAKING` Zmiana łamiąca kontrakt	target-order-response/2.0-breaking	FAIL	niezgodne	accepted CONTRACT_FIELD_TYPE	boolean string

Co ten przykład pokazuje

Testowalny kontrakt zamiast niejasnej integracji

Scenariusze i dane są syntetyczne. W realnym zakresie kryteria powstają na podstawie uzgodnionej specyfikacji i przykładów.

01 · Wejście

Kontrakt i przykłady

Specyfikacja pól, wartości słownikowych i przykładowe dane źródłowe oraz docelowe.

02 · Scenariusze

Jawne scenariusze

Sukcesy, oczekiwane odrzucenia, błędy kontraktu oraz zachowanie transportu.

03 · Wynik

Raport PASS/FAIL

Identyfikator, payload, oczekiwany i rzeczywisty wynik oraz czytelny JSON diff.

04 · Odbiór

Mierzalny odbiór

Stały zestaw danych, uzgodnione wyniki i wykonywalny pakiet regresji do ponownego użycia.

Zakres wdrożeniowy

Wydzielony odbiór integracji API

Specyfikacja API i przykłady → uzgodnione scenariusze → wykonywalny pakiet testów → raport rozbieżności → odbiór PASS/FAIL.

Zakres koncentruje się na wydzielonej integracji, regresji po zmianie lub walidacji migracji i jednoznacznych kryteriach odbioru.

Omówić podobny zakres