Co to jest testowanie interfejsu? Typy i przykłady

⚡ Inteligentne podsumowanie

Testowanie interfejsu weryfikuje poprawną wymianę danych między dwoma połączonymi systemami oprogramowania. Obejmuje ono łącza serwera WWW, serwera aplikacji i serwera bazy danych, które obsługują każde żądanie aplikacji, wraz z obsługą błędów w tym zakresie.

  • 🔗 Definicja: Interfejs to dowolne połączenie — API, usługa internetowa lub kolejka komunikatów — łączące dwa komponenty.
  • 🧭 Dwa segmenty: Testowanie ma na celu sprawdzenie połączenia serwera WWW z serwerem aplikacji oraz połączenia serwera aplikacji z serwerem bazy danych.
  • 📄 Przykład rozwiązania: Dane wejściowe XML i dane wyjściowe JSON są weryfikowane pod kątem zgodności ze specyfikacjami opublikowanych formatów.
  • 🧪 Rodzaje testów: Przepływ pracy, przypadki skrajne, wydajność i obciążenie, a także każdy indywidualny system testowany w izolacji.
  • 🛠️. Obróbka: Klienci API i wirtualizacja usług generują żądania, mimo że nie istnieje żaden klikalny interfejs użytkownika.
  • 🔍 Granica zakresu: Testowanie interfejsu to podtyp testowania integracyjnego skupiający się na kompatybilności połączeń.tracsamo w sobie.

Testowanie interfejsu pomiędzy serwerem WWW, serwerem aplikacji i serwerem bazy danych

Co to jest testowanie interfejsu?

Testowanie interfejsu jest definiowane jako rodzaj testowania oprogramowania, który sprawdza, czy komunikacja między dwoma różnymi systemami oprogramowania odbywa się prawidłowo.

Połączenie integrujące dwa komponenty nazywa się interfejsem. W świecie komputerów interfejs ten może obejmować API, usługi sieciowe itp. Testowanie tych łączących usług lub interfejsów nazywa się testowaniem interfejsu.

Interfejs to tak naprawdę oprogramowanie składające się z zestawów poleceń, komunikatów i innych atrybutów umożliwiających komunikację pomiędzy urządzeniem a użytkownikiem.

Ważne jest, aby interfejs miał złączetract: uzgodniony format żądania, uzgodniony format odpowiedzi, uzgodniony zestaw kodów błędów i uzgodniony limit czasu. Ćwiczenia z testowania interfejsu, któretracz obu stron, więc zmiana wprowadzona przez jeden zespół nie powoduje cichego uszkodzenia drugiego. Ponieważ większość tego ruchu nigdy nie dociera do ekranu, znalezione przez niego defekty są niewidoczne dla testy czarnej skrzynki wykonywane wyłącznie za pośrednictwem interfejsu użytkownika.

Jak przeprowadzić testowanie interfejsu

Testowanie interfejsu obejmuje testowanie dwóch głównych segmentów:

  1. Interfejs serwera WWW i serwera aplikacji
  2. Serwer aplikacji i interfejs serwera bazy danych.

W przypadku powyższych scenariuszy testowanie interfejsu odbywa się w celu

  • Sprawdź, czy serwery działają poprawnie, czy nie
  • Błędy są obsługiwane prawidłowo lub zwracają komunikat o błędzie w przypadku dowolnego zapytania wykonanego przez aplikację
  • Sprawdź wyniki resetowania połączenia z serwerem internetowym w międzyczasie

Poniższy diagram przedstawia te dwa segmenty jako pojedynczy łańcuch, w którym przeglądarka komunikuje się z serwerem internetowym, serwer internetowy komunikuje się z serwerem aplikacji, a serwer aplikacji komunikuje się z serwerem bazy danych.

Testowanie interfejsu w całym łańcuchu serwerów WWW, serwerów aplikacji i serwerów baz danych

W praktyce tester przechodzi przez ten łańcuch krok po kroku. Każdy krok jest najpierw sterowany prawidłowym żądaniem, następnie błędnym, a na końcu celowo niedostępnym terminalem, tak aby zarówno ścieżka sukcesu, jak i ścieżka błędu były rejestrowane w tym samym rekordzie. walizka testowa.

Przykład testowania interfejsu

Załóżmy, że dla dowolnej aplikacji xyz interfejs przyjmuje XML plik jako dane wejściowe i dostarcza JSON Plik jako wynik. Aby przetestować interfejs tej aplikacji, wystarczy podać specyfikacje formatu pliku XML i JSON.

Korzystając z tych specyfikacji, możemy utworzyć przykładowe pliki wejściowe XML i przesłać je do interfejsu. Następnie, w ramach testów interfejsu, możemy zweryfikować plik wejściowy (XML) i wyjściowy (JSON) pod kątem spełnienia wymagań.

Zwróć uwagę, czego przykład nie wymaga: brak ekranu, brak kompilacji front-endu i brak znajomości kodu interfejsu. Do napisania testów wystarczą dwie specyfikacje formatu, dlatego testowanie interfejsu można rozpocząć na długo przed powstaniem interfejsu użytkownika.

Dlaczego testowanie interfejsu

Testowanie interfejsu zostało zakończone

  • Zapewnienie, że użytkownicy końcowi lub klienci nie powinni napotkać żadnych problemów podczas korzystania z określonego oprogramowania
  • Aby zidentyfikować obszary zastosowań, do których zwykle mają dostęp użytkownicy końcowi, a także sprawdzić ich przyjazność dla użytkownika.
  • Weryfikacja wymagań bezpieczeństwa podczas propagacji komunikacji pomiędzy systemami
  • Aby sprawdzić, czy rozwiązanie jest w stanie obsłużyć awarie sieci pomiędzy serwerem aplikacji a stroną internetową

Istnieje również argument kosztowy. Usunięcie wady w formacie żądania jest tanie, gdy oba systemy są jeszcze połączone, a kosztowne, gdy system podrzędny już zapisze wadliwe dane.

Rodzaje testowania interfejsu

Podczas testowania interfejsu przeprowadzane są różne rodzaje testów interfejsu, które mogą obejmować

  • Workflow: Zapewnia to, że silnik interfejsu obsługuje standardowe przepływy pracy zgodnie z oczekiwaniami.
  • Przypadki brzegowe – nieoczekiwane wartości: Jest to brane pod uwagę przy testowaniu polegającym na odwróceniu daty, miesiąca i dnia.
  • Testowanie wydajności, obciążenia i sieci: Interfejs o dużej objętości może wymagać więcej Testowanie obciążenia niż interfejs o małej objętości, w zależności od silnika interfejsu i infrastruktury łączności
  • Poszczególne systemy: Obejmuje to testowanie każdego systemu osobno. Na przykład system rozliczeniowy i system zarządzania zapasami dla sklepu detalicznego powinny móc działać oddzielnie.

Pierwszy element jest wystarczająco blisko testowanie przepływu pracy aby ponownie wykorzystać swoje scenariusze, a ostatni element pokrywa się z testowanie modułów, ponieważ system, który ulegnie awarii samoczynnie, ulegnie awarii ponownie po podłączeniu.

Strategia testowania interfejsu

Strategia testowania interfejsów to metoda używana do testowania interfejsów za pomocą wspólnych testów, niezależnie od implementacji. Możemy użyć abstracPrzypadki testowe i tworzenie konkretnych instancji przypadku testowego dla każdej implementacji strategii testowania interfejsu. Baza/abstracPrzypadki testowe wykonują testy niezależne od implementacji, podczas gdy testy konkretne zajmują się tworzeniem obiektów do testowania i wykonywaniem testów specyficznych dla implementacji.

Korzyścią z tej struktury jest możliwość ponownego wykorzystania. Gdy pojawia się trzecia implementacja tego samego interfejsu,tract suite działa bez zmian, a napisany musi zostać jedynie kod instancji. Ta sama idea jest stosowana na większą skalę w testowanie komponentów, gdzie wspólny kontracPakiet t jest uruchamiany w odniesieniu do każdego komponentu, który twierdzi, że spełnia jego wymagania.

Narzędzia do testowania interfejsu

Ponieważ interfejs nie ma ekranu, narzędzia muszą konstruować żądania bezpośrednio i odpowiadać na surowe odpowiedzi. Zespoły zazwyczaj łączą trzy kategorie narzędzi.

  • Klienci API i konstruktorzy żądań: Narzędzia takie jak Postman, SoapUIInsomnia i Hoppscotch wysyłają wywołania REST, SOAP lub GraphQL, przechowują je jako kolekcje wielokrotnego użytku i potwierdzają kody statusu, nagłówki i treści odpowiedzi.
  • Codebiblioteki testów na poziomie: Biblioteki działające w ramach istniejącego zestawu testów pozwalają na przeprowadzanie kontroli interfejsu równolegle z testami jednostkowymi i ich wykonywanie przy każdej kompilacji, co zapobiega ich dezaktualizacji.
  • Narzędzia ładowania i protokołu: Narzędzie takie jak JMeter steruje tym samym interfejsem na poziomie głośności, co zmienia kontrolę funkcjonalną w test wydajności połączenia.
  • Wirtualizacja usług i makiety: Zastępczy odcinek połączenia pozwala na przetestowanie jednej strony, podczas gdy druga jest niedostępna, niedokończona lub zbyt kosztowna, aby dzwonić wielokrotnie.

Wybór ma mniejsze znaczenie niż pokrycie. Niezależnie od wybranego klienta, zbiór żądań musi być przechowywany w systemie kontroli wersji wraz z kodem, aby zmiana interfejsu i zmiana jego testów pojawiały się w tym samym zatwierdzeniu. Szczegóły dotyczące szerszej kategorii omówiono w Testowanie API.

Lista kontrolna testowania interfejsu i najlepsze praktyki

Krótka lista kontrolna zapewnia uczciwe pokrycie interfejsu w różnych wersjach. Należy ją sprawdzać dla każdego połączenia, a nie dla całej aplikacji.

  • ztracnajpierw: Sprawdź, czy schematy żądań i odpowiedzi odpowiadają opublikowanej specyfikacji, pole po polu, włączając w to typy danych i pola opcjonalne.
  • Wartości graniczne: Wysyłaj puste ładunki, pola o maksymalnej długości, nieoczekiwane zestawy znaków i odwrócone formaty dat.
  • Ścieżki błędów: Sprawdź, czy każda awaria zwraca zrozumiały kod i komunikat, a nie stos trace lub cichy sukces.
  • Przekroczenia limitu czasu i ponowne próby: Przerwij połączenie w trakcie żądania i potwierdź, że osoba wywołująca bezpiecznie ponawia próbę, nie duplikując transakcji.
  • Bezpieczeństwo: Sprawdź uwierzytelnianie, autoryzację i szyfrowanie łącza i upewnij się, że komunikaty o błędach nie ujawniają szczegółów wewnętrznych.
  • Spójność danych: Przeczytaj zapis od drugiej strony i upewnij się, że nic nie zostało obcięte, ponownie zakodowane lub uporządkowane w trakcie przesyłania.
  • Tom: Powtórz połączenie o największym ruchu przy jednoczesnym obciążeniu i obserwuj, czy pula połączeń się nie wyczerpie.

Trzy praktyki sprawiają, że ta lista kontrolna jest powtarzalna. Po pierwsze, zautomatyzuj pakiet i uruchamiaj go przy każdej kompilacji, ponieważ interfejsy zmieniają się ciszej niż ekrany. Po drugie, rejestruj pełne żądanie i odpowiedź dla każdej awarii, ponieważ odtworzenie defektu interfejsu na podstawie zrzutu ekranu jest praktycznie niemożliwe. Po trzecie, uniezależnij pakiet od danych testowych generowanych przez inne pakiety, tak aby awaria wskazywała na interfejs, a nie na brakujący rekord.

Kontrole te naturalnie wpisują się w szerszy plan opisany w rodzaje testowania oprogramowaniai działają zanim te same połączenia zostaną wykonane od końca do końca podczas testowanie systemu.

Testowanie interfejsu a testowanie integracji

Te dwa terminy są ze sobą powiązane, a nie sprzeczne: testowanie interfejsu to część prac integracyjnych, która koncentruje się na samym połączeniu. Poniższa tabela przedstawia nacisk na każdą ze stron.

Testowanie interfejsu Testy integracyjne
Typ testu integracyjnego, który dotyczy testowania interfejsów między komponentami lub systemami Testowanie przeprowadzane w celu wykrycia defektów w interfejsach i interakcjach pomiędzy zintegrowanymi komponentami lub systemami.
Skupienie jest oszustwemtract — format żądania, format odpowiedzi, kody błędów i limity czasu Fokus to łączone zachowanie komponentów po ich połączeniu
Można wykonać od razu po zaistnieniu specyfikacji, z końcowym szczątkiem Wymaga wspólnego zbudowania i wdrożenia wszystkich komponentów
Awaria wskazuje na jedno połączenie Awaria może wskazywać na dowolny komponent w zmontowanej grupie

Każdy, kto dopiero zaczyna interesować się szerszą dyscypliną, znajdzie opisane tu poziomy otaczające testy integracyjne i ogólnie Testowanie oprogramowania wstęp, podczas gdy terminologia użyta powyżej pochodzi ze standardu Inżynieria oprogramowania W przypadku systemów skierowanych do przeglądarek te same połączenia są ostatecznie ponownie uruchamiane podczas testowanie aplikacji internetowych.

FAQ

Zazwyczaj inżynierowie ds. zapewnienia jakości, którzy odpowiadają za integrację, współpracują z programistami obu systemów. W przypadku produktów wymagających dużej liczby usług, zadanie to wykonuje dedykowany tester API, ponieważ praca wymaga umiejętności konstruowania żądań, a nie nawigacji po ekranie.

Brak widocznych wyników do sprawdzenia, zewnętrzne punkty końcowe, których nie można swobodnie wywołać, dane testowe, które muszą istnieć po obu stronach, oraz specyfikacje zmieniające się bez powiadomienia. Zastępcze bazy danych i kolekcje żądań z kontrolą wersji redukują większość z tych problemów.

W dużym stopniu się pokrywają. API to jeden rodzaj interfejsu, więc Testowanie API Testowanie interfejsu dotyczy konkretnej technologii. Testowanie interfejsu obejmuje również usuwanie plików, kolejki komunikatów i łącza do baz danych, które nie zawierają interfejsu API.

Nie. Nazwa jest wspólna, ale cel jest inny. Testowanie interfejsu sprawdza połączenia między systemami; testowanie interfejsu użytkownika sprawdza ekrany, elementy sterujące i układ. Pomylenie tych dwóch elementów powoduje, że połączenia po stronie serwera nie są testowane.

Gdy tylko specyfikacje żądań i odpowiedzi zostaną uzgodnione, co zazwyczaj następuje przed zakończeniem pracy któregokolwiek z systemów, zastąpienie drugiego końca pozwala na wcześniejsze uruchomienie pakietu, a ten sam pakiet jest ponownie wykorzystywany po uruchomieniu obu systemów.

Udział udokumentowanych punktów końcowych z co najmniej jednym pozytywnym i jednym negatywnym wynikiem testu, udział faktycznie wyzwolonych zadeklarowanych kodów błędów i liczba usterek interfejsuping do późniejszych faz. Surowe wyniki testów dowodzą bardzo niewiele.

Uczenie maszynowe odczytuje schemat i generuje ładunki graniczne i negatywne, które człowiek by pominął, a następnie grupuje nieudane odpowiedzi, aby jedna przyczyna źródłowa nie była zgłaszana osiem razy. Oznacza również zmiany schematu, które uniemożliwiają dopasowanie istniejących żądań.

Tak. Na podstawie schematu lub przykładowego ładunku szybko tworzy konstruktory żądań, asercje i odpowiedzi typu stub. Specyfikacja nadal musi zostać dostarczona przez człowieka, ponieważ wygenerowana asercja jest tylko tak poprawna, jak poprawna jest…tract za tym.

Podsumuj ten post następująco: