Testowanie oprogramowania - krótki przewodnik

Co to jest testowanie?

Testowanie to proces oceny systemu lub jego komponentów w celu stwierdzenia, czy spełnia on określone wymagania, czy nie. Mówiąc najprościej, testowanie to wykonywanie systemu w celu zidentyfikowania wszelkich luk, błędów lub brakujących wymagań w przeciwieństwie do rzeczywistych wymagań.

Zgodnie ze standardem ANSI / IEEE 1059 testowanie można zdefiniować jako - proces analizy elementu oprogramowania w celu wykrycia różnic między istniejącymi a wymaganymi warunkami (tj. Defektów / błędów / błędów) oraz oceny funkcji elementu oprogramowania.

Kto przeprowadza testy?

Zależy to od procesu i powiązanych interesariuszy projektu (-ów). W branży IT duże firmy dysponują zespołem odpowiedzialnym za ocenę tworzonego oprogramowania pod kątem określonych wymagań. Ponadto programiści przeprowadzają również testy o nazwieUnit Testing. W większości przypadków w testowaniu systemu w ramach swoich możliwości zaangażowani są następujący specjaliści:

  • Tester Oprogramowania
  • Programista
  • Kierownik / kierownik projektu
  • Użytkownik końcowy

Różne firmy mają różne oznaczenia dla osób testujących oprogramowanie na podstawie swojego doświadczenia i wiedzy, takich jak tester oprogramowania, inżynier ds. Zapewnienia jakości oprogramowania, analityk QA itp.

Nie ma możliwości testowania oprogramowania na żadnym etapie jego cyklu. Kolejne dwie sekcje określają, kiedy testowanie powinno zostać rozpoczęte, a kiedy zakończyć podczas SDLC.

Kiedy rozpocząć testy?

Wczesne rozpoczęcie testowania zmniejsza koszty i skraca czas potrzebny do przepracowania i wyprodukowania wolnego od błędów oprogramowania, które jest dostarczane klientowi. Jednak w cyklu życia oprogramowania (SDLC) testowanie można rozpocząć od fazy gromadzenia wymagań i kontynuować aż do wdrożenia oprogramowania.

Zależy to również od używanego modelu rozwoju. Na przykład w modelu Waterfall formalne testy są przeprowadzane w fazie testowania; ale w modelu przyrostowym testowanie jest wykonywane na końcu każdego przyrostu / iteracji, a cała aplikacja jest testowana na końcu.

Testowanie odbywa się w różnych formach na każdym etapie SDLC -

  • Podczas fazy zbierania wymagań analiza i weryfikacja wymagań jest również traktowana jako testowanie.

  • Za testowanie uważa się również przegląd projektu w fazie projektowania z zamiarem jego ulepszenia.

  • Testowanie wykonywane przez programistę po ukończeniu kodu jest również klasyfikowane jako testowanie.

Kiedy przestać testować?

Trudno jest określić, kiedy przerwać testowanie, ponieważ testowanie to niekończący się proces i nikt nie może twierdzić, że oprogramowanie jest w 100% przetestowane. Aby zatrzymać proces testowania, należy wziąć pod uwagę następujące aspekty:

  • Terminy testowania

  • Zakończenie wykonywania przypadku testowego

  • Zakończenie pokrycia funkcjonalnego i kodu do pewnego momentu

  • Wskaźnik błędów spada poniżej pewnego poziomu i nie są identyfikowane żadne błędy o wysokim priorytecie

  • Decyzja zarządu

Weryfikacja poprawności

Te dwa terminy są bardzo mylące dla większości ludzi, którzy używają ich zamiennie. W poniższej tabeli przedstawiono różnice między weryfikacją a walidacją.

Sr.No. Weryfikacja Uprawomocnienie
1 Weryfikacja rozwiązuje problem: „Czy dobrze to budujesz?” Walidacja rozwiązuje problem: „Czy tworzysz właściwą rzecz?”
2 Zapewnia, że ​​system oprogramowania spełnia wszystkie funkcje. Zapewnia, że ​​funkcjonalności odpowiadają zamierzonemu zachowaniu.
3 Weryfikacja ma miejsce jako pierwsza i obejmuje sprawdzenie dokumentacji, kodu itp. Walidacja następuje po weryfikacji i obejmuje głównie sprawdzenie całego produktu.
4 Wykonane przez programistów. Wykonane przez testerów.
5 Ma działania statyczne, ponieważ obejmuje zbieranie recenzji, instrukcje i inspekcje w celu weryfikacji oprogramowania. Ma dynamiczne działania, ponieważ obejmuje wykonywanie oprogramowania zgodnie z wymaganiami.
6 Jest to proces obiektywny i do weryfikacji oprogramowania nie powinna być potrzebna żadna subiektywna decyzja. Jest to proces subiektywny i obejmuje subiektywne decyzje dotyczące tego, jak dobrze działa oprogramowanie.

Poniżej przedstawiono niektóre z najczęstszych mitów dotyczących testowania oprogramowania.

Mit 1: Testowanie jest zbyt drogie

Reality- Jest takie powiedzenie, płać mniej za testowanie podczas tworzenia oprogramowania lub płać więcej za konserwację lub poprawki później. Wczesne testowanie oszczędza czas i koszty w wielu aspektach, jednak obniżenie kosztów bez testowania może skutkować niewłaściwym zaprojektowaniem aplikacji, co spowoduje, że produkt będzie bezużyteczny.

Mit 2: Testowanie jest czasochłonne

Reality- Podczas faz SDLC testowanie nigdy nie jest procesem czasochłonnym. Jednak diagnozowanie i naprawianie błędów zidentyfikowanych podczas prawidłowego testowania jest czynnością czasochłonną, ale produktywną.

Mit 3: Testowane są tylko w pełni opracowane produkty

Reality- Bez wątpienia testowanie zależy od kodu źródłowego, ale przeglądanie wymagań i tworzenie przypadków testowych jest niezależne od tworzonego kodu. Jednak podejście iteracyjne lub przyrostowe jako model cyklu rozwojowego może zmniejszyć zależność testowania od w pełni opracowanego oprogramowania.

Mit 4: Pełne testowanie jest możliwe

Reality- Staje się problemem, gdy klient lub tester uważa, że ​​pełne testowanie jest możliwe. Możliwe, że wszystkie ścieżki zostały przetestowane przez zespół, ale przeprowadzenie pełnego testowania nigdy nie jest możliwe. Mogą istnieć scenariusze, które nigdy nie są wykonywane przez zespół testowy lub klienta podczas cyklu życia oprogramowania i mogą zostać wykonane po wdrożeniu projektu.

Mit 5: Testowane oprogramowanie jest wolne od błędów

Reality - To bardzo powszechny mit, w który wierzą klienci, kierownicy projektów i zespół zarządzający. Nikt nie może twierdzić z absolutną pewnością, że aplikacja jest w 100% wolna od błędów, nawet jeśli tester z doskonałymi umiejętnościami testowania przetestował aplikację .

Mit 6: Pominięte usterki są spowodowane przez testerów

Reality- Nie jest poprawnym podejściem obwinianie testerów za błędy, które pozostają w aplikacji nawet po przeprowadzeniu testów. Ten mit dotyczy czasu, kosztu i wymagań zmieniających ograniczenia. Jednak strategia testowa może również skutkować pominięciem błędów przez zespół testujący.

Mit 7: Testerzy są odpowiedzialni za jakość produktu

Reality- Bardzo częstą błędną interpretacją jest to, że tylko testerzy lub zespół testujący powinni być odpowiedzialni za jakość produktu. Do obowiązków testerów należy identyfikacja błędów dla interesariuszy, a następnie to od nich zależy, czy naprawią błąd, czy udostępnią oprogramowanie. Wydanie oprogramowania w tym czasie wywiera większą presję na testerów, ponieważ zostaną obarczeni winą za każdy błąd.

Mit 8: Aby skrócić czas, należy wszędzie, gdzie to możliwe, stosować automatyzację testów

Reality- Tak, to prawda, że ​​automatyzacja testów skraca czas testowania, ale nie jest możliwe rozpoczęcie automatyzacji testów w dowolnym momencie podczas tworzenia oprogramowania. Automat testowy należy uruchomić po ręcznym przetestowaniu oprogramowania i pewnej stabilizacji. Ponadto automatyzacji testów nie można nigdy używać, jeśli wymagania stale się zmieniają.

Mit 9: Każdy może testować aplikację

Reality- Osoby spoza branży IT myślą, a nawet wierzą, że każdy może przetestować oprogramowanie, a testowanie nie jest pracą twórczą. Jednak testerzy doskonale wiedzą, że to mit. Myślenie alternatywnych scenariuszy, próba awarii oprogramowania z zamiarem zbadania potencjalnych błędów nie jest możliwa dla osoby, która je opracowała.

Mit 10: Jedynym zadaniem testera jest znajdowanie błędów

Reality- Znajdowanie błędów w oprogramowaniu jest zadaniem testerów, ale jednocześnie są oni ekspertami dziedzinowymi w zakresie danego oprogramowania. Deweloperzy są odpowiedzialni tylko za określony komponent lub obszar, który jest im przypisany, ale testerzy rozumieją ogólne działanie oprogramowania, jakie są zależności i wpływ jednego modułu na inny moduł.

Testowanie, zapewnienie jakości i kontrola jakości

Większość ludzi jest zdezorientowanych, jeśli chodzi o określenie różnic między zapewnianiem jakości, kontrolą jakości i testowaniem. Chociaż są one ze sobą powiązane i do pewnego stopnia można je uznać za te same działania, ale istnieją punkty odróżniające je od siebie. W poniższej tabeli wymieniono punkty, które odróżniają QA, QC i Testing.

Zapewnienie jakości Kontrola jakości Testowanie
QA obejmuje działania zapewniające wdrożenie procesów, procedur i standardów w kontekście weryfikacji tworzonego oprogramowania i zamierzonych wymagań. Obejmuje działania zapewniające weryfikację tworzonego oprogramowania pod kątem udokumentowanych (lub w niektórych przypadkach nie) wymagań. Obejmuje czynności zapewniające identyfikację błędów / błędów / defektów w oprogramowaniu.
Koncentruje się na procesach i procedurach, zamiast przeprowadzać rzeczywiste testy systemu. Koncentruje się na faktycznym testowaniu poprzez wykonanie oprogramowania w celu zidentyfikowania błędu / defektu poprzez wdrożenie procedur i procesu. Koncentruje się na rzeczywistych testach.
Działania zorientowane na proces. Działania zorientowane na produkt. Działania zorientowane na produkt.
Działania profilaktyczne. To jest proces naprawczy. Jest to proces zapobiegawczy.
Jest to podzbiór cyklu życia testów oprogramowania (STLC). QC można uznać za podzbiór zapewniania jakości. Testowanie jest podzbiorem kontroli jakości.

Audyt i inspekcja

Audit- Jest to systematyczny proces mający na celu określenie, jak rzeczywisty proces testowania jest przeprowadzany w organizacji lub zespole. Generalnie jest to niezależne badanie procesów zachodzących podczas testowania oprogramowania. Zgodnie z IEEE jest to przegląd udokumentowanych procesów, które organizacje wdrażają i przestrzegają. Rodzaje audytów obejmują audyt zgodności z prawem, audyt wewnętrzny i audyt systemu.

Inspection- Jest to formalna technika, która obejmuje formalne lub nieformalne techniczne przeglądy dowolnego artefaktu poprzez identyfikację wszelkich błędów lub luk. Zgodnie z IEEE94, inspekcja jest formalną techniką oceny, w ramach której wymagania oprogramowania, projekty lub kody są szczegółowo badane przez osobę lub grupę inną niż autor w celu wykrycia błędów, naruszeń standardów programistycznych i innych problemów.

Formalne spotkania inspekcyjne mogą obejmować następujące procesy: planowanie, przygotowanie przeglądowe, spotkanie inspekcyjne, przeróbka i kontynuacja.

Testowanie i debugowanie

Testing- Obejmuje identyfikację błędu / błędu / defektu w oprogramowaniu bez jego poprawiania. Zwykle w identyfikację błędów biorą udział specjaliści z doświadczeniem w zapewnianiu jakości. Testowanie odbywa się w fazie testowania.

Debugging- Obejmuje identyfikację, izolację i naprawę problemów / błędów. Programiści, którzy kodują oprogramowanie, przeprowadzają debugowanie po napotkaniu błędu w kodzie. Debugowanie jest częścią testów białej skrzynki lub testów jednostkowych. Debugowanie można przeprowadzić w fazie rozwoju podczas przeprowadzania testów jednostkowych lub w fazach podczas naprawiania zgłoszonych błędów.

Wiele organizacji na całym świecie opracowuje i wdraża różne standardy, aby poprawić wymagania jakościowe swojego oprogramowania. W tym rozdziale pokrótce opisano niektóre z powszechnie stosowanych norm związanych z zapewnianiem jakości i testowaniem.

ISO / IEC 9126

Ten standard dotyczy następujących aspektów w celu określenia jakości aplikacji -

  • Model jakości
  • Wskaźniki zewnętrzne
  • Wskaźniki wewnętrzne
  • Wskaźniki jakości w użyciu

Ten standard przedstawia zestaw atrybutów jakości dla dowolnego oprogramowania, takich jak -

  • Functionality
  • Reliability
  • Usability
  • Efficiency
  • Maintainability
  • Portability

Wyżej wymienione atrybuty jakości są dalej podzielone na pod-czynniki, które można zbadać, szczegółowo przestudiując normę.

ISO / IEC 9241-11

Część 11 tego standardu dotyczy zakresu, w jakim produkt może być używany przez określonych użytkowników do osiągnięcia określonych celów z efektywnością, wydajnością i satysfakcją w określonym kontekście użytkowania.

W normie zaproponowano ramy opisujące komponenty użyteczności i relacje między nimi. W tym standardzie użyteczność jest rozpatrywana w kategoriach wydajności i satysfakcji użytkownika. Zgodnie z ISO 9241-11 użyteczność zależy od kontekstu użytkowania, a poziom użyteczności będzie się zmieniał wraz ze zmianą kontekstu.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 jest powszechnie znana jako norma, która zawiera wytyczne dotyczące wymagań jakości oprogramowania i oceny (SQuaRE). Standard ten pomaga w organizowaniu i ulepszaniu procesu związanego z wymaganiami jakościowymi oprogramowania i ich ocenami. W rzeczywistości ISO-25000 zastępuje dwie stare normy ISO, tj. ISO-9126 i ISO-14598.

SQuaRE jest podzielony na części, takie jak -

  • ISO 2500n - Dział Zarządzania Jakością
  • ISO 2501n - Dział modeli jakości
  • ISO 2502n - Dział Pomiarów Jakości
  • ISO 2503n - Dział wymagań jakościowych
  • ISO 2504n - Dział Oceny Jakości

Główną zawartością SQuaRE są -

  • warunki i definicje
  • Modele referencyjne
  • Instrukcja ogólna
  • Indywidualne przewodniki po podziałach
  • Norma związana z inżynierią wymagań (tj. Specyfikacja, planowanie, pomiar i proces oceny)

ISO / IEC 12119

Ten standard dotyczy pakietów oprogramowania dostarczanych do klienta. Nie koncentruje się ani nie zajmuje się procesem produkcyjnym klientów. Główna treść jest związana z następującymi pozycjami -

  • Zestaw wymagań dotyczących pakietów oprogramowania.
  • Instrukcje testowania dostarczonego pakietu oprogramowania pod kątem określonych wymagań.

Różne

Niektóre inne standardy związane z procesami zapewniania jakości i testowania są wymienione poniżej -

Sr.No Standard i opis
1

IEEE 829

Standard dotyczący formatu dokumentów używanych na różnych etapach testowania oprogramowania.

2

IEEE 1061

Metodologia ustalania wymagań jakościowych, identyfikowania, wdrażania, analizowania i walidacji procesu oraz produktu metryk jakości oprogramowania.

3

IEEE 1059

Przewodnik dotyczący planów weryfikacji i walidacji oprogramowania.

4

IEEE 1008

Standard testów jednostkowych.

5

IEEE 1012

Standard weryfikacji i walidacji oprogramowania.

6

IEEE 1028

Standard kontroli oprogramowania.

7

IEEE 1044

Standard klasyfikacji anomalii oprogramowania.

8

IEEE 1044-1

Przewodnik po klasyfikacji anomalii oprogramowania.

9

IEEE 830

Przewodnik dotyczący opracowywania specyfikacji wymagań systemowych.

10

IEEE 730

Standard planów zapewnienia jakości oprogramowania.

11

IEEE 1061

Standard metryk i metodologii jakości oprogramowania.

12

IEEE 12207

Standard dotyczący procesów cyklu życia oprogramowania i danych dotyczących cyklu życia.

13

BS 7925-1

Słownictwo terminów używanych w testowaniu oprogramowania.

14

BS 7925-2

Standard testowania komponentów oprogramowania.

W tej sekcji opisano różne typy testów, które można wykorzystać do testowania oprogramowania podczas SDLC.

Testowanie ręczne

Testowanie ręczne obejmuje testowanie oprogramowania ręcznie, tj. Bez użycia jakichkolwiek zautomatyzowanych narzędzi lub skryptów. W tym typie tester przejmuje rolę użytkownika końcowego i testuje oprogramowanie w celu zidentyfikowania nieoczekiwanego zachowania lub błędu. Istnieją różne etapy testowania ręcznego, takie jak testy jednostkowe, testy integracyjne, testy systemowe i testy akceptacyjne użytkownika.

Testerzy używają planów testów, przypadków testowych lub scenariuszy testowych do testowania oprogramowania w celu zapewnienia kompletności testów. Testowanie ręczne obejmuje również testowanie eksploracyjne, podczas którego testerzy badają oprogramowanie, aby zidentyfikować w nim błędy.

Testowanie automatyczne

Testowanie automatyczne, znane również jako automatyzacja testów, polega na tym, że tester pisze skrypty i używa innego oprogramowania do testowania produktu. Ten proces obejmuje automatyzację procesu ręcznego. Testowanie automatyczne służy do ponownego uruchamiania scenariuszy testowych, które były wykonywane ręcznie, szybko i wielokrotnie.

Oprócz testów regresyjnych, testy automatyczne są również używane do testowania aplikacji z punktu widzenia obciążenia, wydajności i stresu. Zwiększa pokrycie testowe, poprawia dokładność oraz oszczędza czas i pieniądze w porównaniu z testami ręcznymi.

Co zautomatyzować?

Nie jest możliwe zautomatyzowanie wszystkiego w oprogramowaniu. Obszary, w których użytkownik może dokonywać transakcji, takie jak formularz logowania czy formularze rejestracyjne, każdy obszar, w którym duża liczba użytkowników może jednocześnie uzyskać dostęp do oprogramowania, powinien zostać zautomatyzowany.

Ponadto wszystkie elementy GUI, połączenia z bazami danych, walidacje terenowe itp. Można skutecznie przetestować poprzez automatyzację procesu ręcznego.

Kiedy automatyzować?

Automatyzacja testów powinna być używana z uwzględnieniem następujących aspektów oprogramowania -

  • Duże i krytyczne projekty
  • Projekty wymagające częstego testowania tych samych obszarów
  • Wymagania nie zmieniają się często
  • Dostęp do aplikacji w celu obciążenia i wydajności z wieloma użytkownikami wirtualnymi
  • Stabilne oprogramowanie pod względem testowania ręcznego
  • Dostępność czasu

Jak zautomatyzować?

Automatyzacja odbywa się za pomocą wspomagającego języka komputerowego, takiego jak skrypty VB i zautomatyzowana aplikacja. Dostępnych jest wiele narzędzi, których można użyć do pisania skryptów automatyzacji. Zanim wspomnimy o narzędziach, określmy proces, który można wykorzystać do automatyzacji procesu testowania -

  • Identyfikacja obszarów w oprogramowaniu do automatyzacji
  • Dobór odpowiedniego narzędzia do automatyzacji testów
  • Pisanie skryptów testowych
  • Rozwój kombinezonów testowych
  • Wykonywanie skryptów
  • Twórz raporty wyników
  • Zidentyfikuj potencjalne błędy lub problemy z wydajnością

Narzędzia do testowania oprogramowania

Następujące narzędzia mogą być używane do testowania automatyzacji -

  • HP Szybki test Professional
  • Selenium
  • IBM Rational Functional Tester
  • SilkTest
  • TestComplete
  • Testowanie w dowolnym miejscu
  • WinRunner
  • LoadRunner
  • Visual Studio Test Professional
  • WATIR

Istnieją różne metody testowania oprogramowania. W tym rozdziale pokrótce opisano dostępne metody.

Testowanie czarnoskrzynkowe

Technika testowania bez znajomości wewnętrznego działania aplikacji nazywana jest testowaniem czarnoskrzynkowym. Tester jest nieświadomy architektury systemu i nie ma dostępu do kodu źródłowego. Zwykle podczas wykonywania testu czarnej skrzynki tester wchodzi w interakcję z interfejsem użytkownika systemu, dostarczając dane wejściowe i badając dane wyjściowe, nie wiedząc, jak i gdzie są przetwarzane dane wejściowe.

W poniższej tabeli wymieniono zalety i wady testowania czarnoskrzynkowego.

Zalety Niedogodności
Dobrze dopasowane i wydajne do dużych segmentów kodu. Ograniczony zasięg, ponieważ faktycznie wykonywana jest tylko wybrana liczba scenariuszy testowych.
Dostęp do kodu nie jest wymagany. Nieefektywne testowanie ze względu na to, że tester ma jedynie ograniczoną wiedzę o aplikacji.
Wyraźnie oddziela perspektywę użytkownika od perspektywy programisty poprzez wyraźnie zdefiniowane role. Niewidoczne pokrycie, ponieważ tester nie może kierować się na określone segmenty kodu lub obszary podatne na błędy.
Duża liczba średnio wykwalifikowanych testerów może testować aplikację bez znajomości implementacji, języka programowania lub systemów operacyjnych. Przypadki testowe są trudne do zaprojektowania.

Testowanie białoskrzynkowe

Testowanie białoskrzynkowe to szczegółowe badanie wewnętrznej logiki i struktury kodu. Nazywa się również testowaniem białoskrzynkowymglass testing lub open-box testing. W celu wykonaniawhite-box testując aplikację, tester musi znać wewnętrzne działanie kodu.

Tester musi zajrzeć do wnętrza kodu źródłowego i dowiedzieć się, która jednostka / fragment kodu zachowuje się nieprawidłowo.

W poniższej tabeli przedstawiono zalety i wady testów białoskrzynkowych.

Zalety Niedogodności
Ponieważ tester ma wiedzę o kodzie źródłowym, bardzo łatwo jest dowiedzieć się, jaki rodzaj danych może pomóc w skutecznym przetestowaniu aplikacji. Ze względu na to, że do przeprowadzenia testów białoskrzynkowych potrzebny jest wykwalifikowany tester, koszty są zwiększone.
Pomaga w optymalizacji kodu. Czasami nie można zajrzeć do każdego zakamarka, aby znaleźć ukryte błędy, które mogą powodować problemy, ponieważ wiele ścieżek pozostanie niesprawdzonych.
Można usunąć dodatkowe wiersze kodu, co może spowodować ukryte wady. Trudno jest utrzymać testy typu whitebox, ponieważ wymagają wyspecjalizowanych narzędzi, takich jak analizatory kodu i narzędzia do debugowania.
Dzięki wiedzy testera na temat kodu maksymalne pokrycie jest osiągane podczas pisania scenariusza testowego.

Testowanie Gray-Box

Testowanie szarych skrzynek to technika testowania aplikacji przy ograniczonej wiedzy o wewnętrznym działaniu aplikacji. W testowaniu oprogramowania fraza im więcej wiesz, tym lepiej przenosi dużą wagę podczas testowania aplikacji.

Opanowanie domeny systemu zawsze daje testerowi przewagę nad kimś z ograniczoną znajomością domeny. W przeciwieństwie do testów czarnoskrzynkowych, gdzie tester testuje tylko interfejs użytkownika aplikacji; w testach szarej skrzynki tester ma dostęp do dokumentów projektowych i bazy danych. Mając tę ​​wiedzę, tester może przygotować lepsze dane testowe i scenariusze testowe podczas tworzenia planu testów.

Zalety Niedogodności
Tam, gdzie to możliwe, oferuje połączone korzyści testów czarnoskrzynkowych i białoskrzynkowych. Ponieważ dostęp do kodu źródłowego nie jest dostępny, możliwość obejścia kodu i pokrycia testów jest ograniczona.
Testerzy szarej skrzynki nie polegają na kodzie źródłowym; zamiast tego opierają się na definicji interfejsu i specyfikacjach funkcjonalnych. Testy mogą być nadmiarowe, jeśli projektant oprogramowania uruchomił już przypadek testowy.
Opierając się na ograniczonych dostępnych informacjach, tester z szarą skrzynką może zaprojektować doskonałe scenariusze testowe, zwłaszcza dotyczące protokołów komunikacyjnych i obsługi typów danych. Testowanie każdego możliwego strumienia wejściowego jest nierealne, ponieważ zajęłoby nieracjonalnie dużo czasu; dlatego wiele ścieżek programu nie będzie testowanych.
Test jest wykonywany z punktu widzenia użytkownika, a nie projektanta.

Porównanie metod badawczych

W poniższej tabeli wymieniono punkty, które odróżniają testy czarnoskrzynkowe, szare i białoskrzynkowe.

Testowanie czarnoskrzynkowe Testowanie Gray-Box Testowanie białoskrzynkowe
Nie trzeba znać wewnętrznego działania aplikacji. Tester ma ograniczoną wiedzę na temat wewnętrznego działania aplikacji. Tester ma pełną wiedzę na temat wewnętrznego działania aplikacji.
Nazywany również testowaniem zamkniętym, testowaniem opartym na danych lub testowaniem funkcjonalnym. Nazywany również testowaniem półprzezroczystym, ponieważ tester ma ograniczoną wiedzę na temat wnętrza aplikacji. Znane również jako testowanie z czystym pudełkiem, testowanie strukturalne lub testowanie oparte na kodzie.
Wykonywane przez użytkowników końcowych, a także przez testerów i programistów. Wykonywane przez użytkowników końcowych, a także przez testerów i programistów. Zwykle wykonywane przez testerów i programistów.
Testowanie opiera się na oczekiwaniach zewnętrznych - Wewnętrzne zachowanie aplikacji jest nieznane. Testowanie odbywa się na podstawie wysokopoziomowych diagramów baz danych oraz diagramów przepływu danych. Wewnętrzne działania są w pełni znane, a tester może odpowiednio zaprojektować dane testowe.
Jest wyczerpująca i najmniej czasochłonna. Częściowo czasochłonne i wyczerpujące. Najbardziej wyczerpujący i czasochłonny rodzaj testów.
Nie nadaje się do testowania algorytmów. Nie nadaje się do testowania algorytmów. Nadaje się do testowania algorytmów.
Można to zrobić tylko metodą prób i błędów. Domeny danych i granice wewnętrzne można testować, jeśli są znane. Można lepiej przetestować domeny danych i granice wewnętrzne.

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 spowoduje, że powyższe kroki zostaną zastosowane 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. Zapewnienia 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 (zespoły programistó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.

Testy 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 ​​GUI działa zgodnie z wymaganiami i jest testowane 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.

Dokumentacja testowa obejmuje dokumentację artefaktów, które powinny zostać opracowane przed lub w trakcie testowania Oprogramowania.

Dokumentacja do testowania oprogramowania pomaga oszacować wymagany wysiłek testowy, pokrycie testów, śledzenie / śledzenie wymagań itp. W tej sekcji opisano niektóre z powszechnie używanych udokumentowanych artefaktów związanych z testowaniem oprogramowania, takich jak:

  • Plan testów
  • Scenariusz testowy
  • Przypadek testowy
  • Macierz identyfikowalności

Plan testów

Plan testów określa strategię, która będzie używana do testowania aplikacji, zasoby, które będą używane, środowisko testowe, w którym testy będą wykonywane, a także ograniczenia testowania i harmonogram czynności testowych. Zazwyczaj kierownik zespołu ds. Zapewnienia jakości będzie odpowiedzialny za napisanie planu testów.

Plan testów obejmuje:

  • Wprowadzenie do dokumentu planu testów
  • Założenia podczas testowania aplikacji
  • Lista przypadków testowych wchodzących w skład testowania aplikacji
  • Lista funkcji do przetestowania
  • Jakie podejście zastosować podczas testowania oprogramowania
  • Lista produktów do przetestowania
  • Zasoby przeznaczone na testowanie aplikacji
  • Wszelkie ryzyka związane z procesem testowania
  • Harmonogram zadań i kamieni milowych do osiągnięcia

Scenariusz testowy

Jest to jednowierszowa instrukcja, która informuje, który obszar aplikacji będzie testowany. Scenariusze testowe służą do zapewnienia, że ​​wszystkie przepływy procesów są testowane od początku do końca. Określony obszar aplikacji może mieć od jednego scenariusza testowego do kilkuset scenariuszy, w zależności od wielkości i złożoności aplikacji.

Pojęcia „scenariusz testowy” i „przypadki testowe” są używane zamiennie, jednak scenariusz testowy składa się z kilku kroków, a przypadek testowy - z jednego kroku. Z tej perspektywy scenariusze testowe są przypadkami testowymi, ale zawierają kilka przypadków testowych i sekwencję, w jakiej powinny być wykonywane. Poza tym każdy test jest zależny od wyniku poprzedniego testu.

Przypadek testowy

Przypadki testowe obejmują zestaw kroków, warunków i danych wejściowych, których można używać podczas wykonywania zadań testowych. Głównym celem tego działania jest upewnienie się, czy oprogramowanie przejdzie lub zawodzi w zakresie swojej funkcjonalności i innych aspektów. Istnieje wiele rodzajów przypadków testowych, takich jak funkcjonalne, negatywne, błędne, logiczne przypadki testowe, fizyczne przypadki testowe, przypadki testowe interfejsu użytkownika itp.

Ponadto pisane są przypadki testowe, aby śledzić zakres testów oprogramowania. Ogólnie rzecz biorąc, nie ma formalnych szablonów, których można użyć podczas pisania przypadków testowych. Jednak następujące komponenty są zawsze dostępne i zawarte w każdym przypadku testowym -

  • Identyfikator przypadku testowego
  • Moduł produktu
  • Wersja Produktu
  • Historia zmian
  • Purpose
  • Assumptions
  • Pre-conditions
  • Steps
  • Spodziewany rezultat
  • Rzeczywisty wynik
  • Post-conditions

Wiele przypadków testowych można wyprowadzić z jednego scenariusza testowego. Ponadto czasami dla jednego oprogramowania napisanych jest wiele przypadków testowych, które są wspólnie określane jako zestawy testów.

Macierz identyfikowalności

Macierz śledzenia (znana również jako macierz śledzenia wymagań - RTM) to tabela używana do śledzenia wymagań podczas cyklu życia oprogramowania. Może być używany do śledzenia w przód (tj. Od wymagań do projektu lub kodowania) lub wstecz (tj. Od kodowania do wymagań). Istnieje wiele szablonów zdefiniowanych przez użytkownika dla RTM.

Każde wymaganie w dokumencie RTM jest powiązane z powiązanym przypadkiem testowym, dzięki czemu testowanie można przeprowadzić zgodnie z wymienionymi wymaganiami. Co więcej, identyfikator błędu jest również dołączony i powiązany z powiązanymi wymaganiami i przypadkiem testowym. Główne cele tej macierzy to -

  • Upewnij się, że oprogramowanie zostało opracowane zgodnie z wymienionymi wymaganiami.
  • Pomaga w znalezieniu pierwotnej przyczyny dowolnego błędu.
  • Pomaga w śledzeniu opracowanych dokumentów na różnych etapach SDLC.

Szacowanie wysiłku wymaganego do testowania jest jednym z głównych i ważnych zadań w SDLC. Prawidłowe oszacowanie pomaga w testowaniu oprogramowania z maksymalnym pokryciem. W tej sekcji opisano niektóre techniki, które mogą być przydatne przy szacowaniu nakładu pracy wymaganego do testowania.

Analiza punktów funkcjonalnych

Metoda ta opiera się na analizie wymagań funkcjonalnych użytkownika oprogramowania z następującymi kategoriami -

  • Outputs
  • Inquiries
  • Inputs
  • Pliki wewnętrzne
  • Pliki zewnętrzne

Analiza punktów testowych

Ten proces szacowania jest używany do analizy punktów funkcyjnych w testach czarnoskrzynkowych lub akceptacyjnych. Główne elementy tej metody to: rozmiar, produktywność, strategia, łączenie, złożoność i jednorodność.

Metoda Mark-II

Jest to metoda szacunkowa wykorzystywana do analizy i pomiaru oszacowania w oparciu o funkcjonalny pogląd użytkownika końcowego. Procedura dla metody Mark-II jest następująca -

  • Określ punkt widzenia
  • Cel i rodzaj liczenia
  • Określ granicę liczenia
  • Zidentyfikuj transakcje logiczne
  • Identyfikuj i kategoryzuj typy jednostek danych
  • Policz typy elementów danych wejściowych
  • Policz rozmiar funkcjonalny

Różne

Możesz użyć innych popularnych technik szacowania, takich jak -

  • Technika delphi
  • Szacowanie oparte na analogii
  • Szacowanie na podstawie wyliczenia przypadków testowych
  • Szacowanie oparte na zadaniach (działaniach)
  • Metoda IFPUG