Co to jest Szary Box Testowanie? Techniki, przykład

Co to jest Szary Box Testujesz?

Szary Box Testy (pisane również jako Gray Box Testowanie (ang. „Testing”) to technika testowania oprogramowania, która polega na testowaniu produktu programowego lub aplikacji z częściową znajomością wewnętrznej struktury aplikacji. Celem metody Grey Box Testowanie ma na celu wyszukiwanie i identyfikowanie defektów spowodowanych nieprawidłową strukturą kodu lub niewłaściwym użytkowaniem aplikacji.

W tym procesie powszechnie identyfikuje się błędy specyficzne dla kontekstu, związane z systemami internetowymi. Technika ta zwiększa pokrycie testu koncentrując się na wszystkich warstwach złożonego systemu, a nie tylko na jednej z nich.

Szary Box Testowanie to metoda testowania oprogramowania, która łączy Biały Box Testy oraz Czarny Box TestyRóżnica między nimi sprowadza się do tego, ile wewnętrznej struktury może zobaczyć tester:

• W kolorze białym Box Testowanie wewnętrznej struktury (kodu) jest znane.
• W czerni Box Testowanie wewnętrznej struktury (kodu) jest nieznane.
• W kolorze szarym Box Testowanie wewnętrznej struktury (kodu) jest częściowo znane.

Poniższy diagram umieszcza te trzy metody na tej samej skali widoczności.

In Inżynieria oprogramowania, Szary Box Testowanie daje możliwość testowania obu stron aplikacji – warstwy prezentacyjnej, jak i kodu, który za nią stoi. Jest to przydatne przede wszystkim w testy integracyjne oraz testy penetracyjne.

Przykład szarości Box Testowanie: Jeśli podczas testowania funkcji witryny internetowej, takich jak linki lub linki osierocone, tester napotka problem z tymi linkami, może od razu wprowadzić zmianę w kodzie HTML i sprawdzić ją w czasie rzeczywistym.

Dlaczego szary Box Testy

Szary Box Testowanie przeprowadza się z następujących powodów:

• Zapewnia połączenie korzyści testowania czarnej skrzynki i testowania białej skrzynki.
• Łączy w sobie wkład programistów i testerów, co pozwala na poprawę ogólnej jakości produktu.
• Zmniejsza obciążenie długiego procesu testowania typów funkcjonalnych i niefunkcjonalnych.
• Daje deweloperowi wystarczająco dużo wolnego czasu na naprawienie usterek.
• Testowanie odbywa się z punktu widzenia użytkownika, a nie projektanta.
• Awarię można wyjaśnić, a nie tylko zgłosić, ponieważ tester może zobaczyć warstwę, w której wystąpiła.

Szary Box Testowanie kontra czerń Box przeciwko białym Box Testy

Te trzy metody nie tyle stanowią konkurujące ze sobą alternatywy, co raczej trzy poziomy dostępu, z których każdy odpowiada na inny rodzaj pytań. Zestawienie ich ze sobą sprawia, że ​​wybór staje się konkretny.

Większość zespołów korzysta ze wszystkich trzech cykl życia testowania oprogramowania, a warstwa szarego pola to miejsce, w którym zazwyczaj wychwytywane są defekty występujące pomiędzy interfejsem użytkownika a magazynem danych.

Szary Box Strategia testowania

Aby wykonać Grey Box Testowanie – tester nie musi mieć dostępu do kodu źródłowego. Test jest projektowany w oparciu o wiedzę o algorytmach, architekturach, stanach wewnętrznych lub innych ogólnych opisach zachowania programu.

Aby wykonać Grey Box Testowanie:

• Stosuje proste techniki testowania metodą czarnej skrzynki.
• Opiera się na generowaniu przypadków testowych na podstawie wymagań, co oznacza, że ​​wszystkie warunki są wstępnie ustalane przed przetestowaniem programu metodą assertion.

Techniki stosowane w przypadku Greya Box Testy obejmują:

• Testowanie matrycy: Technika ta polega na zdefiniowaniu wszystkich zmiennych występujących w programie i ryzyka, jakie każda z nich ze sobą niesie, dzięki czemu widoczne są zmienne nieużywane i te obarczone wysokim ryzykiem.
• Testy regresji: Sprawdza, czy zmiana w poprzedniej wersji nie wpłynęła negatywnie na inne aspekty programu w nowej wersji. Odbywa się to za pomocą strategii takich jak ponowne testowanie wszystkich aplikacji, ponowne testowanie ryzykownych przypadków użycia oraz ponowne testowanie w obrębie zapory sieciowej.
• Testowanie układu ortogonalnego lub OAT: zapewnia maksymalne pokrycie kodu przy minimalnej liczbie przypadków testowych.
• Testowanie wzorców: Przeprowadzono je na podstawie danych historycznych dotyczących poprzednich usterek systemu. W przeciwieństwie do testów typu „czarna skrzynka”, Box Testowanie pozwala przeanalizować kod i ustalić przyczynę wystąpienia błędu.

Szary Box metodologia zwykle wykorzystuje automatyzację narzędzia do testowania oprogramowania do przeprowadzenia testów. Moduły stub i sterowniki modułów są tworzone tak, aby tester nie musiał ręcznie generować kodu.

Kroki wykonania zabiegu Grey Box Testy obejmują:

• Krok 1: Zidentyfikuj dane wejściowe.
• Krok 2: Zidentyfikuj wyniki.
• Krok 3: Określ główne ścieżki.
• Krok 4: Zidentyfikuj podfunkcje.
• Krok 5: Opracuj dane wejściowe dla podfunkcji.
• Krok 6: Opracuj wyniki dla podfunkcji.
• Krok 7: Wykonaj przypadek testowy dla podfunkcji.
• Krok 8: Sprawdź poprawność wyników dla podfunkcji.
• Krok 9: Powtórz kroki od 4 do 8 dla pozostałych podfunkcji.
• Krok 10: Powtórz kroki 7 i 8 dla pozostałych podfunkcji.

Przypadki testowe dla Greya Box Testowanie może obejmować między innymi kwestie związane z interfejsem graficznym, bezpieczeństwem, bazą danych, przeglądarką i systemem operacyjnym. Każdy wygenerowany przypadek nadal wymaga standardowego walizka testowa atrybuty, ponieważ przypadek, którego nie można odtworzyć na podstawie jego własnego opisu, jest mało przydatny podczas regresji.

Gdzie Szary Box Testowanie jest używane

Technika ta znajduje zastosowanie wszędzie tam, gdzie defekt można zdiagnozować jedynie poprzez analizę dwóch warstw jednocześnie. Najczęściej stosuje się ją w następujących sytuacjach:

• Przepływy pracy oparte na bazie danych: akcja jest wykonywana za pośrednictwem interfejsu użytkownika, a następnie wynikowe wiersze są bezpośrednio przeszukiwane w celu potwierdzenia, że ​​wartości, typy i relacje zostały zapisane zgodnie z przeznaczeniem.
• Usługi sieciowe i interfejsy API: wysyłane jest żądanie, a status odpowiedzi, nagłówki i ładunek są sprawdzane pod kątem opublikowanych danychtract, która jest codzienną formą Testowanie API.
• Punkty integracji: wiadomości przekraczające granicę między dwoma modułami są sprawdzane, przy czym oba moduły są traktowane jako działające systemy, a nie jako pliki źródłowe.
• Ocena bezpieczeństwa: Tester penetracyjny, któremu udostępniono normalne konto użytkownika i przegląd architektury, odtwarza pozycję osoby z wewnątrz, co jest standardowym modelem zaangażowania typu grey box.
• Aplikacje internetowe i interfejsy graficzne: uszkodzone łącza, porzucone strony, obsługa sesji i walidacja po stronie klienta — wszystkie te czynności są sprawdzane z częściową widocznością znaczników i przepływu żądań.

We wszystkich tych przypadkach całkowity koszt usterek systemowych ulega zmniejszeniu, ponieważ problemy są wykrywane i wyjaśniane zanim przejdą dalej w dół procesu. testowanie systemu lub produkcja.

Szary Box Narzędzia testujące

Żadne narzędzie nie wykonuje szarości Box Testowanie samo w sobie. Kategoria potrzebuje połączenia sterownika interfejsu, narzędzia inspekcyjnego dla warstwy niższej oraz sposobu na jednoczesne utworzenie skryptu dla tych dwóch elementów.

• Klienci API i usług sieciowych jak na przykład Postman oraz SoapUI, służy do wydawania żądań i potwierdzania kodów statusu i treści odpowiedzi.
• Klienci baz danych i narzędzia zapytań SQL, służy do weryfikacji trwałego stanu po akcji interfejsu.
• Narzędzia dla programistów przeglądarek i serwery proxy HTTP jak na przykład Burp Suite, używany do sprawdzania i modyfikowania żądań podczas sesji zorientowanych na bezpieczeństwo.
• Ramy automatyzacji interfejsu użytkownika jak na przykład Selenium, używany do sterowania warstwą prezentacji wewnątrz testowanie automatyzacji na.
• Narzędzia do rejestrowania i monitorowania, służy do korelowania zaobserwowanej awarii z tym, co aplikacja zarejestrowała wewnętrznie w danym momencie.

Wybór ma mniejsze znaczenie niż okablowanie: jeśli sterownik interfejsu i krok inspekcji nie są wykonywane w ramach tego samego skryptowanego przepływu, w rezultacie pojawią się dwa oddzielne ręczne sprawdzenia, a nie jeden test typu grey box.

Szary Box Wyzwania testowe

Częściowa widoczność powoduje problemy, których żadna z metod czystych nie ma. Oto problemy, z którymi zespoły spotykają się najczęściej:

• Gdy testowany komponent ulegnie jakiejś awarii, trwająca operacja może zostać przerwana, a reszta sekwencji nie zostanie wykonana.
• Test może zostać wykonany w całości, mimo że treść wyniku jest niepoprawna. W takiej sytuacji weryfikacja powinna polegać na sprawdzeniu wartości, a nie ukończeniu testu.
• Pełne pokrycie ścieżki kodu nie jest możliwe, ponieważ tester nigdy nie zobaczy każdej gałęzi, do której dotarłoby testowanie białej skrzynki.
• Dokumentacja projektowa, na której opierają się testy, może być nieaktualna, a nieaktualny schemat lub specyfikacja interfejsu w sposób dyskretny unieważniają projekt testów.
• Testerzy muszą rozumieć daną dziedzinę i posiadać dogłębną wiedzę techniczną, a to stanowi węższy profil umiejętności, pod kątem których warto ich rekrutować.
• Rozproszone i mocno napięte mięśnie brzuchatracW przypadku architektur TED trudno przypisać zaobserwowaną awarię konkretnemu wewnętrznemu komponentowi.

Ograniczenia te przemawiają za leczeniem szarości Box Testowanie jako jedna z kilku warstw, a nie jako zamiennik pozostałych, co jest punktem odniesienia w szerszym zestawie techniki testowania oprogramowania oraz rodzaje testowania oprogramowania. Naturalnie leży obok testy funkcjonalności i podejścia oparte na specyfikacji, takie jak testowanie oparte na modelu.

FAQ