Testowanie oprogramowania - poziomy

Podczas procesu testowania są różne poziomy. W tym rozdziale przedstawiono krótki opis tych poziomów.

Poziomy testowania obejmują różne metodologie, których można używać podczas przeprowadzania testów oprogramowania. Główne poziomy testowania oprogramowania to -

• Testy funkcjonalności

• Testowanie niefunkcjonalne

Testy funkcjonalności

Jest to rodzaj testu czarnoskrzynkowego, który opiera się na specyfikacjach testowanego oprogramowania. Aplikacja jest testowana przez wprowadzenie danych wejściowych, a następnie sprawdzane są wyniki, które muszą być zgodne z funkcjonalnością, do której została przeznaczona. Testowanie funkcjonalne oprogramowania przeprowadza się na kompletnym, zintegrowanym systemie w celu oceny zgodności systemu z określonymi wymaganiami.

Testowanie aplikacji pod kątem funkcjonalności obejmuje pięć kroków.

Kroki	Opis
ja	Określenie funkcjonalności, jaką ma wykonywać zamierzona aplikacja.
II	Tworzenie danych testowych na podstawie specyfikacji aplikacji.
III	Dane wyjściowe oparte na danych testowych i specyfikacjach aplikacji.
IV	Pisanie scenariuszy testowych i wykonywanie przypadków testowych.
V	Porównanie rzeczywistych i oczekiwanych wyników na podstawie wykonanych przypadków testowych.

Skuteczna praktyka testowania pozwoli zastosować powyższe kroki w polityce testowania każdej organizacji, a tym samym zapewni, że organizacja zachowuje najsurowsze standardy, jeśli chodzi o jakość oprogramowania.

Testów jednostkowych

Ten typ testowania jest wykonywany przez programistów przed przekazaniem konfiguracji zespołowi testowemu w celu formalnego wykonania przypadków testowych. Testy jednostkowe są przeprowadzane przez odpowiednich programistów na poszczególnych obszarach przypisanych do kodu źródłowego. Programiści używają danych testowych, które różnią się od danych testowych zespołu zapewniania jakości.

Celem testów jednostkowych jest wyodrębnienie każdej części programu i pokazanie, że poszczególne części są poprawne pod względem wymagań i funkcjonalności.

Ograniczenia testów jednostkowych

Testowanie nie może wychwycić każdego błędu w aplikacji. Niemożliwe jest oszacowanie każdej ścieżki wykonania w każdej aplikacji. To samo dotyczy testów jednostkowych.

Istnieje ograniczenie liczby scenariuszy i danych testowych, których deweloper może użyć do zweryfikowania kodu źródłowego. Po wyczerpaniu wszystkich opcji nie pozostaje nic innego jak przerwać testy jednostkowe i scalić segment kodu z innymi jednostkami.

Testy integracyjne

Testowanie integracyjne definiuje się jako testowanie połączonych części aplikacji w celu określenia, czy działają one poprawnie. Testowanie integracyjne można przeprowadzić na dwa sposoby: oddolne testy integracyjne i odgórne testy integracyjne.

Sr.No.	Metoda testowania integracji
1	Bottom-up integration Testowanie rozpoczyna się od testów jednostkowych, po których następują testy kombinacji jednostek o coraz wyższym poziomie zwanych modułami lub kompilacjami.
2	Top-down integration W ramach tego testu najpierw testowane są moduły najwyższego poziomu, a następnie testowane są stopniowo moduły niższego poziomu.

W kompleksowym środowisku programistycznym najpierw przeprowadza się testy oddolne, a następnie odgórne. Proces kończy się wielokrotnymi testami całej aplikacji, najlepiej w scenariuszach naśladujących rzeczywiste sytuacje.

Testowanie systemu

Testowanie systemu testuje system jako całość. Po zintegrowaniu wszystkich komponentów aplikacja jako całość jest rygorystycznie testowana w celu sprawdzenia, czy spełnia określone standardy jakości. Ten rodzaj testów jest wykonywany przez wyspecjalizowany zespół testowy.

Testowanie systemu jest ważne z następujących powodów -

• Testowanie systemu to pierwszy krok w cyklu życia oprogramowania, w którym aplikacja jest testowana jako całość.

• Aplikacja jest dokładnie testowana pod kątem zgodności ze specyfikacjami funkcjonalnymi i technicznymi.

• Aplikacja jest testowana w środowisku bardzo zbliżonym do środowiska produkcyjnego, w którym aplikacja zostanie wdrożona.

• Testowanie systemu umożliwia nam testowanie, weryfikację i walidację zarówno wymagań biznesowych, jak i architektury aplikacji.

Testowanie regresji

Za każdym razem, gdy wprowadzana jest zmiana w aplikacji, jest całkiem możliwe, że zmiana ta wpłynęła na inne obszary aplikacji. Testy regresyjne są wykonywane w celu sprawdzenia, czy naprawiony błąd nie spowodował naruszenia innej funkcjonalności lub reguły biznesowej. Celem testów regresyjnych jest upewnienie się, że zmiana, taka jak naprawa błędu, nie spowoduje wykrycia innego błędu w aplikacji.

Testowanie regresji jest ważne z następujących powodów -

• Zminimalizuj luki w testowaniu, gdy aplikacja z wprowadzonymi zmianami ma zostać przetestowana.

• Testowanie nowych zmian w celu sprawdzenia, czy wprowadzone zmiany nie wpłynęły na żaden inny obszar aplikacji.

• Ogranicza ryzyko podczas przeprowadzania testów regresyjnych w aplikacji.

• Zakres testów jest zwiększony bez uszczerbku dla terminów.

• Zwiększ szybkość wprowadzania produktu na rynek.

Testy akceptacyjne

Jest to prawdopodobnie najważniejszy rodzaj testów, ponieważ jest przeprowadzany przez Zespół Zapewnienia Jakości, który oceni, czy aplikacja spełnia założone specyfikacje i spełnia wymagania klienta. Zespół ds. Kontroli jakości będzie miał zestaw gotowych scenariuszy i przypadków testowych, które zostaną wykorzystane do przetestowania aplikacji.

Będzie udostępnionych więcej pomysłów na temat aplikacji i będzie można przeprowadzić więcej testów, aby ocenić jej dokładność i powody, dla których projekt został zainicjowany. Testy akceptacyjne mają na celu nie tylko wskazanie prostych błędów ortograficznych, błędów kosmetycznych lub luk w interfejsie, ale także wskazanie wszelkich błędów w aplikacji, które spowodują awarie systemu lub poważne błędy w aplikacji.

Wykonując testy akceptacyjne aplikacji, zespół testujący ograniczy sposób, w jaki aplikacja będzie działać na produkcji. Istnieją również wymogi prawne i umowne dotyczące akceptacji systemu.

Testy alfa

Ten test jest pierwszym etapem testowania i zostanie przeprowadzony przez zespoły (deweloperów i zespoły ds. Kontroli jakości). Testy jednostkowe, testy integracyjne i testy systemowe w połączeniu ze sobą określane są jako testy alfa. Na tym etapie w aplikacji zostaną przetestowane następujące aspekty -

• Błędy w wymowie

• Zepsute połączenia

• Pochmurne kierunki

• Aplikacja zostanie przetestowana na maszynach o najniższej specyfikacji, aby przetestować czasy ładowania i wszelkie problemy z opóźnieniami.

Testowanie beta

Ten test jest wykonywany po pomyślnym wykonaniu testów alfa. W testach beta próbka docelowej grupy odbiorców testuje aplikację. Testy beta są również znane jakopre-release testing. Wersje beta testowe oprogramowania są idealnie rozprowadzane do szerokiego grona odbiorców w Internecie, częściowo po to, aby dać programowi test „w prawdziwym świecie”, a częściowo po to, aby zapewnić podgląd następnej wersji. W tej fazie publiczność będzie testować następujące elementy -

• Użytkownicy zainstalują, uruchomią aplikację i wyślą swoje opinie do zespołu projektowego.

• Błędy typograficzne, zagmatwany przepływ aplikacji, a nawet awarie.

• Otrzymując informację zwrotną, zespół projektowy może rozwiązać problemy przed udostępnieniem oprogramowania rzeczywistym użytkownikom.

• Im więcej naprawisz problemów, które rozwiązują rzeczywiste problemy użytkowników, tym wyższa będzie jakość Twojej aplikacji.

• Posiadanie aplikacji wyższej jakości po udostępnieniu jej dla ogółu społeczeństwa zwiększy satysfakcję klienta.

Testowanie niefunkcjonalne

Ta sekcja jest oparta na testowaniu aplikacji pod kątem jej niefunkcjonalnych atrybutów. Testowanie niefunkcjonalne obejmuje testowanie oprogramowania pod kątem wymagań, które są z natury niefunkcjonalne, ale ważne, takie jak wydajność, bezpieczeństwo, interfejs użytkownika itp.

Poniżej omówiono niektóre ważne i powszechnie używane typy testów niefunkcjonalnych.

Test wydajności

Służy głównie do identyfikowania wąskich gardeł lub problemów z wydajnością, a nie do wyszukiwania błędów w oprogramowaniu. Istnieją różne przyczyny, które przyczyniają się do obniżenia wydajności oprogramowania -

• Opóźnienie sieciowe

• Przetwarzanie po stronie klienta

• Przetwarzanie transakcji w bazie danych

• Równoważenie obciążenia między serwerami

• Renderowanie danych

Testowanie wydajnościowe jest uważane za jeden z ważnych i obowiązkowych typów testów pod względem następujących aspektów -

• Szybkość (tj. Czas odpowiedzi, renderowanie danych i dostęp)

• Capacity

• Stability

• Scalability

Testowanie wydajności może być jakościowe lub ilościowe i można je podzielić na różne podtypy, takie jak Load testing i Stress testing.

Testowanie obciążenia

Jest to proces testowania zachowania oprogramowania poprzez zastosowanie maksymalnego obciążenia w zakresie dostępu oprogramowania do dużych danych wejściowych i manipulowania nimi. Można to zrobić w warunkach obciążenia normalnego i szczytowego. Ten typ testowania identyfikuje maksymalną wydajność oprogramowania i jego zachowanie w godzinach szczytu.

W większości przypadków testy obciążenia są wykonywane za pomocą zautomatyzowanych narzędzi, takich jak Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test itp.

Użytkownicy wirtualni (VUsers) są definiowani w narzędziu do automatycznego testowania, a skrypt jest wykonywany w celu weryfikacji testów obciążenia oprogramowania. Liczbę użytkowników można zwiększać lub zmniejszać jednocześnie lub przyrostowo w zależności od wymagań.

Test naprężeń

Testy warunków skrajnych obejmują testowanie zachowania oprogramowania w nietypowych warunkach. Na przykład może obejmować zabranie niektórych zasobów lub zastosowanie obciążenia przekraczającego faktyczny limit obciążenia.

Celem testów warunków skrajnych jest przetestowanie oprogramowania poprzez przyłożenie obciążenia do systemu i przejęcie zasobów wykorzystywanych przez oprogramowanie do identyfikacji punktu zerwania. Testowanie to można przeprowadzić, testując różne scenariusze, takie jak -

• Losowe zamykanie lub ponowne uruchamianie portów sieciowych

• Włączanie lub wyłączanie bazy danych

• Uruchamianie różnych procesów, które zużywają zasoby, takie jak procesor, pamięć, serwer itp.

Test użyteczności

Testowanie użyteczności jest techniką czarnej skrzynki i służy do identyfikowania wszelkich błędów i ulepszeń w oprogramowaniu poprzez obserwację użytkowników podczas ich użytkowania i działania.

Według Nielsena użyteczność można zdefiniować za pomocą pięciu czynników, tj. Efektywności użytkowania, zdolności uczenia się, zdolności zapamiętywania, błędów / bezpieczeństwa i satysfakcji. Według niego użyteczność produktu będzie dobra, a system będzie zdatny do użytku, jeśli posiada powyższe czynniki.

Nigel Bevan i Macleod uznali, że użyteczność to wymóg jakościowy, który można zmierzyć jako wynik interakcji z systemem komputerowym. Wymóg ten może zostać spełniony, a użytkownik końcowy będzie usatysfakcjonowany, jeśli zamierzone cele zostaną skutecznie osiągnięte przy użyciu odpowiednich zasobów.

Molich w 2000 roku stwierdził, że system przyjazny dla użytkownika powinien spełniać pięć następujących celów, tj. Łatwy do nauczenia, łatwy do zapamiętania, wydajny w użyciu, zadowalający w użyciu i łatwy do zrozumienia.

Oprócz różnych definicji użyteczności, istnieją pewne standardy i modele jakości oraz metody, które definiują użyteczność w postaci atrybutów i atrybutów podrzędnych, takich jak ISO-9126, ISO-9241-11, ISO-13407 i IEEE std. 610.12 itp.

Testowanie interfejsu użytkownika a testowanie użyteczności

Testowanie interfejsu użytkownika obejmuje testowanie graficznego interfejsu użytkownika oprogramowania. Testowanie interfejsu użytkownika zapewnia, że ​​interfejs GUI działa zgodnie z wymaganiami i jest testowany pod względem koloru, wyrównania, rozmiaru i innych właściwości.

Z drugiej strony, testy użyteczności zapewniają dobry i przyjazny dla użytkownika interfejs, który można łatwo obsługiwać. Testowanie interfejsu użytkownika można traktować jako część składową testów użyteczności.

Testowanie bezpieczeństwa

Testy bezpieczeństwa obejmują testowanie oprogramowania w celu zidentyfikowania wszelkich wad i luk z punktu widzenia bezpieczeństwa i podatności. Poniżej wymienione są główne aspekty, które powinny zapewnić testy bezpieczeństwa -

• Confidentiality

• Integrity

• Authentication

• Availability

• Authorization

• Non-repudiation

• Oprogramowanie jest zabezpieczone przed znanymi i nieznanymi lukami

• Dane oprogramowania są bezpieczne

• Oprogramowanie jest zgodne ze wszystkimi przepisami bezpieczeństwa

• Sprawdzanie i walidacja danych wejściowych

• Ataki typu SQL insertion

• Wady wtrysku

• Problemy z zarządzaniem sesjami

• Ataki typu cross-site scripting

• Bufor przepełnia luki w zabezpieczeniach

• Ataki typu Directory traversal

Testowanie przenośności

Testowanie przenośności obejmuje testowanie oprogramowania w celu zapewnienia jego ponownego użycia oraz możliwości przeniesienia go z innego oprogramowania. Poniżej przedstawiono strategie, których można użyć do testowania przenośności -

• Przenoszenie zainstalowanego oprogramowania z jednego komputera na inny.

• Tworzenie pliku wykonywalnego (.exe) w celu uruchamiania oprogramowania na różnych platformach.

Testowanie przenośności można uznać za jedną z części podrzędnych testowania systemu, ponieważ ten typ testowania obejmuje ogólne testowanie oprogramowania pod kątem jego wykorzystania w różnych środowiskach. Sprzęt komputerowy, systemy operacyjne i przeglądarki są głównym celem testów przenośności. Niektóre z warunków wstępnych testów przenośności są następujące:

• Oprogramowanie powinno być zaprojektowane i zakodowane, mając na uwadze wymagania dotyczące przenośności.

• Na powiązanych komponentach przeprowadzono testy jednostkowe.

• Przeprowadzono testy integracyjne.

• Środowisko testowe zostało utworzone.