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.
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:
- Interfejs serwera WWW i serwera aplikacji
- 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.
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.

