Co to jest uprząż testowa? (Przykłady)

Uprząż testowa w testowaniu oprogramowania

Uprząż testowa w testowaniu oprogramowania to zbiór kodów pośredniczących, sterowników i innych narzędzi pomocniczych wymaganych do automatyzacji wykonywania testów. Wiązka testowa wykonuje testy przy użyciu biblioteki testów i generuje raporty z testów. Wiązka testowa zawiera wszystkie informacje potrzebne do skompilowania i uruchomienia testu, takie jak przypadki testowe, docelowy port wdrożenia (TDP), testowany plik źródłowy, kody pośredniczące itp.

Mówiąc prościej, uprząż opakowuje komponent, który chcesz zweryfikować, w kontrolowanym środowisku. Sąsiednie, brakujące moduły są zastępowane małymi, tymczasowymi programami, dane wejściowe pochodzą ze stałego zestawu danych, a każdy wynik jest zapisywany w dzienniku zamiast odczytywać go z ekranu. Poniższe sekcje wyjaśniają, dlaczego zespoły budują uprząż, z czego się składa, jak działa i gdzie się znajduje.

Dlaczego warto używać uprzęży testowej?

Istnieje uprząż, która eliminuje oczekiwanie z cyklu testowego. Ponieważ symuluje ona wszystko, co nie jest jeszcze gotowe, Testowanie oprogramowania Zespół może rozpocząć weryfikację działania już w pierwszym sprincie, a nie po ostatecznej integracji. Poniższy diagram pokazuje, gdzie znajduje się uprząż między skryptami testowymi a testowaną aplikacją.

• Zautomatyzuj proces testowania
• Wykonuj zestawy testów przypadków testowych
• Generuj powiązane raporty z testów
• Wsparcie dla debugowania
• Rejestrowanie wyników testów dla każdego z testów
• Pomaga programistom mierzyć pokrycie kodu na poziomie kodu
• Zwiększ produktywność systemu poprzez automatyzację
• Popraw jakość komponentów oprogramowania i aplikacji
• Aby poradzić sobie ze złożonymi warunkami, których symulowanie jest dla testerów trudne

Te korzyści są najbardziej istotne w przypadku krótkich cykli wydawniczych. Gdy kod jest wysyłany kilka razy w tygodniu, błąd, który przetrwa do etapu integracji, kosztuje znacznie więcej. tracwięcej niż jeden przyłapany na kikucie w dniu, w którym to napisano. Jednak ta nagroda nadchodzi dopiero wtedy, gdy uprząż zostanie złożona z odpowiednich części.

Kluczowe elementy zestawu testowego

Uprząż nie jest pojedynczym programem, lecz zbiorem części, z których każda usuwa jedną przeszkodę, która w innym przypadku uniemożliwiłaby przeprowadzenie testu bez nadzoru.

• Skrypty testowe: Zautomatyzowane instrukcje określające kroki do wykonania i oczekiwany wynik, napisane zgodnie z skrypt testowy konwencje.
• Silnik wykonywania testów: Moduł uruchamiający, który odczytuje skrypty w kolejności, rozwiązuje zależności i uruchamia sekwencyjne lub równoległe wykonywanie.
• Repozytorium danych testowych: Wartości wejściowe przechowywane poza skryptem w formacie CSV, JSON, XML lub bazie danych z nasionami, często wypełniane przez narzędzia do generowania danych testowych.
• sterowniki: Wywołanie modułów pozorne, które wywołuje testowany komponent, gdy prawdziwa górna warstwa, np. interfejs użytkownika, nie jest jeszcze ukończona.
• Zalążki: Moduły wywoływane metodą „dummy” zwracające gotowe odpowiedzi, na przykład usługa płatnicza odpowiadająca „Płatność powiodła się” bez kontaktowania się z bankiem.
• Walidator wyjściowy: Logika asercji porównująca rzeczywisty wynik z wartością oczekiwaną i oznaczająca każdy przypadek jako zaliczony lub niezaliczony.
• Warstwa rejestrowania i raportowania: Znaczniki czasu, zrzuty ekranu, dane wyjściowe konsoli i podsumowanie przebiegu, które informują o każdej awarii tracmożliwe do spożycia później.

Po usunięciu dowolnej części uprząż przestaje być automatyczna, ponieważ wówczas trzeba przy każdym przebiegu dostarczać coś ręcznie.

Jak działa uprząż testowa?

Uprząż powtarza tę samą pętlę przy każdym wykonaniu. Znajomość tej pętli dokładnie wskazuje, gdzie znajduje się twoja własna testowanie automatyzacji zasoby są podłączone, a także który krok kończy się niepowodzeniem, gdy przebieg staje się czerwony.

1. Przygotuj środowisko: Uprząż rozwiązuje konfigurację środowiska, otwiera połączenia i ładuje urządzenia, dzięki czemu każdy przebieg rozpoczyna się od tego samego, znanego stanu.
2. Załaduj skrypty testowe: Skrypty, parametry i oczekiwane wyniki są odczytywane z repozytorium. Nic nie jest wpisywane w czasie wykonywania, co sprawia, że ​​drugie uruchomienie jest porównywalne z pierwszym.
3. Zastąp brakujące moduły: Sterowniki zastępują dzwoniących, którzy jeszcze nie istnieją, a stuby zastępują usługi, które są niedokończone, niestabilne lub których wywoływanie jest kosztowne.
4. Wywołaj testowaną aplikację: Silnik wykonawczy uruchamia przepływ pracy opisany przez skrypt, niezależnie od tego, czy jest to wywołanie metody, API żądanie lub interakcja przeglądarki.
5. Przechwyć rzeczywisty wynik: Wartości zwracane, ładunki odpowiedzi, wiersze bazy danych, wiersze dziennika i stan ekranu są rejestrowane w momencie ich wygenerowania.
6. Porównaj z oczekiwanymi wynikami: Walidator wyników sprawdza każdą przechwyconą wartość. Każda niezgodność oznacza przypadek jako niepowodzenie i rejestruje zarówno wartość oczekiwaną, jak i obserwowaną.
7. Rejestruj i raportuj: Uprząż zapisuje znacznik czasu tracprzebiegu i generuje raport zaliczony/niezaliczony, który programista może odczytać bez konieczności ponownego uruchamiania czegokolwiek.
8. Zburzyć: Tymczasowe dane, połączenia i stan szczątkowy są czyszczone, tak aby kolejny przypadek nie mógł odziedziczyć pozostałości po tym.

💡 Wskazówka: Odświeżaj swoje stuby za każdym razem, gdy rzeczywisty moduł ulegnie zmianie. Stub, który nadal odpowiada formatem z poprzedniego kwartału, zgłosi zielony przebieg, podczas gdy integracja na żywo jest już uszkodzona.

Przykładowy schemat ukonkretnia pętlę. Załóżmy, że strona płatności jest gotowa, ale bramka płatności nie. Sterownik wysyła żądanie, które normalnie wysłałby interfejs, a stub odpowiada najpierw komunikatem „Płatność pomyślna”, a następnie przekroczeniem limitu czasu, a walidator potwierdza zamówienie w jednym przypadku, a w drugim wyświetla monit o ponowienie próby. Obie ścieżki są weryfikowane, zanim zespół bramki płatności napisze choćby jedną linijkę kodu.

Istnieją dwa konteksty, w których używana jest wiązka testowa

Ten sam mechanizm służy dwóm różnym celom, a słownictwo różni się nieznacznie w zależności od tego, w którym celu się znajdujesz.

1. Testowanie automatyczne: Zawiera skrypty testowe, parametry niezbędne do uruchomienia tych skryptów i zebrania wyników w celu ich analizy
2. Testy integracyjne: Służy do łączenia dwóch jednostek kodu lub modułu, które współdziałają ze sobą w celu sprawdzenia, czy połączone zachowanie jest zgodne z oczekiwaniami, czy nie

Rozważmy moduł logowania i moduł profilu, które muszą wymienić token użytkownika. W kontekście integracji sterownik symuluje pomyślne logowanie i przekazuje token do logiki profilu, dzięki czemu mapa danych…ping, sprawdzanie uprawnień i renderowanie ekranu można zweryfikować przed zakończeniem rzeczywistej usługi uwierzytelniania. W kontekście automatyzacji ta sama para przypadków jest dodawana do pakietu i uruchamiana ponownie przy każdej kompilacji bez ingerencji kogokolwiek.

Rodzaje uprzęży testowych

Ponieważ oprogramowanie jest zbudowane warstwowo, uprząż jest zazwyczaj wyspecjalizowana do warstwy, którą weryfikuje. Cztery typy uprzęży pokrywają niemal każdy projekt.

A uprząż testów jednostkowych Ćwiczy najmniejsze fragmenty kodu, takie jak pojedyncza funkcja lub metoda, zastępując każdą zależność stubem. Jest najszybszy w uruchomieniu i najtańszy w utrzymaniu, dlatego testów jednostkowych Pakiety są zazwyczaj pierwszym elementem, który buduje zespół. Typowym zastosowaniem jest testowanie kalkulacji podatkowej bez ingerencji w moduł rozliczeniowy.

An uprząż testów integracyjnych Sprawdza, czy dwa lub więcej modułów współpracuje poprawnie i jest warstwą, na której ujawniają się niezgodności danych i nieudane połączenia. Jest to uprząż opisana w testy integracyjne kontekst powyżej, na przykład sprawdzenie, czy usługa składania zamówień przekazuje właściwy ładunek do usługi płatniczej.

A uprząż testowa systemu steruje kompletnym przepływem danych od początku do końca między interfejsem, usługą i bazą danych, dzięki czemu testowanie systemu można potwierdzić, że reguły biznesowe obowiązują, gdy obecna jest każda warstwa. uprząż do testów regresyjnych a następnie ponownie uruchamia zgromadzony pakiet po każdej zmianie, co jest tym, co sprawia, że testy regresji praktyczne, gdy przy każdym łączeniu trzeba powtórzyć kilkaset scenariuszy.

Przetestuj narzędzia uprzęży

Każdy z tych typów jest zazwyczaj tworzony na podstawie istniejącego narzędzia, a nie od podstaw. Dwa klasyczne rozwiązania to nadal frameworki na poziomie jednostki:

• Junita: Narzędzie używane podczas używania Java
• Nunita: Narzędzie używane do używania .Net Framework

Poza tymi dwoma, większość zespołów dodaje narzędzia, które rozszerzają możliwości o przeglądarkę, warstwę API lub profil obciążenia. Poniższa tabela przedstawia typowe opcje i ich rolę.

Niezależnie od wybranej kombinacji, uprząż zwróci się dopiero po jej bezobsługowym użytkowaniu, dlatego podłącz ją do ciągła integracja pracę wcześnie. Szerszy katalog opcji jest wymieniony w Guru99 narzędzia testowe Podsumowanie. Jedno rozróżnienie wciąż budzi wątpliwości i warto je rozstrzygnąć przed podjęciem decyzji.

Wiązka testowa a struktura testowa

Uprząż i framework automatyzacji są często traktowane jako to samo, ale odpowiadają na różne pytania: uprząż to element, który wykonuje test, podczas gdy framework to struktura, w której projektowane są testy. Poniższa tabela zestawia je ze sobą.

FAQ