9 rodzajów testów oprogramowania w inżynierii oprogramowania

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Testowanie oprogramowania to rzemiosło. Tester oprogramowania, podobnie jak rzemieślnik, powinien dobrze rozumieć dostępne narzędzia do testowania oprogramowania. Przygotowaliśmy listę 9 różnych rodzajów testowania oprogramowania oraz narzędzi wykorzystywanych w każdym z nich, aby pomóc analitykom ds. jakości i wszystkim innym osobom pracującym w branży testowania oprogramowania lepiej zrozumieć swoje rzemiosło. Dlaczego potrzebujemy testowania oprogramowania? Czasami warto […]

Testowanie oprogramowania to rzemiosło. Tester oprogramowania, podobnie jak rzemieślnik, powinien dobrze rozumieć dostępne narzędzia do testowania oprogramowania. Przygotowaliśmy listę 9 różnych rodzajów testowania oprogramowania oraz narzędzi wykorzystywanych w każdym z nich, aby pomóc analitykom ds. jakości i wszystkim innym osobom pracującym w branży testowania oprogramowania lepiej zrozumieć swoje rzemiosło.

Dlaczego potrzebujemy testowania oprogramowania?

Czasami warto przypomnieć sobie, dlaczego to, co robimy, ma znaczenie. Faktem jest, że każde oprogramowanie, które kiedykolwiek opracowano i które odniosło sukces, zawdzięcza go pomocy testerów oprogramowania, którzy niestrudzenie pracowali nad tym, aby produkt spełniał możliwie najwyższe standardy. Oto trzy powody, dla których testowanie oprogramowania ma znaczenie. 

  1. Satysfakcja klienta: Podczas opracowywania projektu łatwo zagubić się w gąszczu kodu i zapomnieć, że użytkownik również musi być zadowolony ze sposobu działania oprogramowania. Analitycy ds. jakości i pozostali członkowie zespołu ds. jakości pełnią właśnie tę rolę. 
  2. Jakość produktu: Każda profesja, w której zespół lub pojedyncza osoba tworzy coś od podstaw, wymaga obecności innego zespołu, który wychwyci błędy. Pisarze potrzebują redaktorów. Reżyserzy filmowi również potrzebują redaktorów. Deweloperzy oprogramowania nie potrzebują redaktorów, ale potrzebują zespołu ds. jakości, który zapewni obiektywny punkt widzenia i wychwyci ewentualne błędy. 
  3. Bezpieczeństwo: Z każdym dniem ten aspekt wydaje się coraz ważniejszy. Klienci chcą mieć pewność, że informacje wprowadzane przez nich do oprogramowania oraz praca wykonywana w jego ramach pozostaną prywatne. Jednym z zadań zespołu ds. jakości jest zapewnienie klientom takiego zaufania. 

Metodyki testowania oprogramowania

Każda technika testowania oprogramowania wymieniona w tym artykule należy do jednej z dwóch głównych kategorii: testowania statycznego i testowania dynamicznego. Zanim omówimy szczegółowe informacje dotyczące dziewięciu różnych technik testowania oprogramowania, wyjaśnię różnicę między tymi dwiema metodykami oraz to, w którym miejscu cyklu tworzenia oprogramowania mają one zastosowanie. 

Testowanie statyczne

Testowanie statyczne to rodzaj testowania oprogramowania przeprowadzanego na wczesnym etapie cyklu tworzenia. Jest to opłacalny sposób na znalezienie błędów, zanim staną się one poważnym problemem dla zespołu deweloperskiego. Testy statyczne wykonuje się na wczesnym etapie cyklu tworzenia, ponieważ można je przeprowadzić bez w pełni funkcjonalnego oprogramowania. Zgadza się — oprogramowanie można debugować, zanim będzie choćby bliskie ukończenia. Widzisz, jakie może to być przydatne? 

Testy statyczne przeprowadza się na dwa sposoby:

  • Badania manualne: Kod jest analizowany przez analityka ds. jakości lub testera. 
  • Analiza automatyczna: Narzędzie do testowania automatycznie sprawdza dokument programu i odnotowuje wszelkie błędy.

Testowanie statyczne:

Większość testów statycznych przeprowadza się w formie przeglądów dokumentów. W tym przypadku dokumentem jest pisemny opis produktu, znany jako dokument projektu oprogramowania, albo kod źródłowy programu. Oto kilka technik testowania statycznego, które każdy analityk ds. jakości powinien znać:

  • Przegląd nieformalny:  Nie ma ścisłych wytycznych dotyczących przeglądu nieformalnego. Zespół przegląda dokumenty testowe i komentuje to, co widzi. Nie prowadzi się dokumentacji.
  • Przegląd krok po kroku: Autor kodu omawia swój dokument, a zespół ds. jakości zgłasza pytania i wątpliwości. Przeglądy krok po kroku są zazwyczaj bardzo nieformalne i stanowią dobry sposób na omawianie tematów z osobami spoza branży oprogramowania. 
  • Przegląd techniczny: Eksperci techniczni spotykają się, aby przeanalizować specyfikacje techniczne kodu. Wykonanie tego na wczesnym etapie procesu tworzenia zapewnia, że produkt końcowy będzie spełniał wymagane specyfikacje.
  • Inspekcje: Najbardziej formalna ze wszystkich form przeglądu. Zespół przeszkolonych moderatorów dokładnie sprawdza dokumenty podczas spotkania. Wszelkie znalezione błędy są formalnie dokumentowane i rejestrowane do dalszej analizy. Odbywa się również spotkanie uzupełniające, aby sprawdzić, czy udokumentowane błędy zostały usunięte. 

W większości przypadków przeglądy testów statycznych są przydatne, ponieważ cały zespół ds. zapewniania jakości przeanalizuje produkt i zaproponuje zmiany na podstawie zauważonych problemów oraz problemów przewidywanych. Oprócz korzyści wynikającej z zaangażowania w rozmowę wielu różnych osób, przynosi to dodatkową korzyść w postaci zapoznania wszystkich członków zespołu z postępami i projektem. 

Użyj testów statycznych, jeśli Twój zespół:

  • Jest na wczesnym etapie procesu tworzenia.
  • Szuka opłacalnego sposobu na znalezienie błędów.
  • Ma oprogramowanie, które nie jest jeszcze gotowe do uruchomienia.
  • Chce wykrywać błędy na wczesnym etapie tworzenia.
Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

Testowanie dynamiczne

W przeciwieństwie do testowania statycznego testowanie dynamiczne jest rodzajem testowania oprogramowania, które wymaga uruchomienia kodu. Naturalnie oznacza to, że prace nad oprogramowaniem muszą być bardziej zaawansowane w cyklu produkcyjnym. Zaletą testowania wykonywalnego kodu jest możliwość sprawdzenia przez analityków ds. zapewniania jakości, jak oprogramowanie działa w rzeczywistej sytuacji. Jest to świetny sposób na sprawdzenie funkcjonalnego działania oprogramowania oraz innych elementów, takich jak wykorzystanie procesora. Testowanie dynamiczne sprawdza, czy oczekiwany wynik odpowiada wynikowi rzeczywistemu. Głównym celem testowania dynamicznego jest zweryfikowanie, czy produkt spełnia wymagania projektowe i funkcjonalne określone przed rozpoczęciem projektu.

Zazwyczaj dynamiczne testowanie oprogramowania systemowego obejmuje cztery kroki, które analitycy ds. zapewniania jakości powinni znać:

  • Testowanie jednostkowe: Podczas testowania jednostkowego oprogramowanie dzieli się na najmniejsze możliwe komponenty i testuje indywidualnie. Dzięki testowaniu w ten sposób analitycy ds. zapewniania jakości mogą mieć pewność, że każda część oprogramowania działa zgodnie z przeznaczeniem. Jeśli zostanie znaleziony błąd, łatwiej będzie go naprawić na tym etapie tworzenia, ponieważ można szybko odizolować problematyczny kod. Zazwyczaj, gdy zespół ds. zapewniania jakości rozpoczyna testowanie dynamiczne (choć czasami ten etap testowania jest obsługiwany przez zespół programistów), zaczyna od testów jednostkowych.
  • Testowanie integracyjne: Po dokładnym rozłożeniu oprogramowania na komponenty i przetestowaniu ich za pomocą testów jednostkowych oprogramowanie jest składane w grupy i ponownie testowane. O ile testowanie jednostkowe ma na celu upewnienie się, że każda pojedyncza część działa prawidłowo, testowanie integracyjne sprawdza, czy te części komunikują się ze sobą zgodnie z założeniami. Można to porównać do montażu samochodu. Na każdym etapie montażu poszczególne części samochodu (silnik, pedały, kierownica) są testowane indywidualnie. Następnie samochód jest składany i testowany jako całość, aby upewnić się, że pedał gazu prawidłowo komunikuje się z silnikiem (i że hamulce również działają prawidłowo!). Chcesz zapewnić bezproblemową integrację między modułami? Nasze polecane narzędzia do testowania oprogramowania mogą Ci w tym pomóc.
  • Testowanie systemowe: Testowanie systemowe jest trzecim poziomem testowania oprogramowania. Na tym etapie testowane jest kompletne i w pełni zintegrowane oprogramowanie. Celem testu systemowego jest upewnienie się, że oprogramowanie spełnia wymagania, czyli wykonuje to, do czego zostało zaprojektowane. 
  • Testowanie akceptacyjne: Ostatni etap testowania dynamicznego. Test akceptacyjny polega na ponownym sprawdzeniu zgodności z wymaganiami i upewnieniu się, że oprogramowanie jest dopracowane do akceptowalnego standardu. Wykonuje się go, aby upewnić się, że żadne błędy nie przedostały się przez pozostałe etapy testowania. Zasadniczo jest to ponowna kontrola przeprowadzana dla zachowania bezpieczeństwa. 

Etapy testowania dynamicznego

  1. Testowanie jednostkowe
  2. Testowanie integracyjne
  3. Testowanie systemowe
  4. Testowanie akceptacyjne

Szybka wskazówka: testowanie weryfikacyjne a testowanie walidacyjne 

Testowanie weryfikacyjne ma wszystkie kluczowe cechy testowania statycznego. Celem testu weryfikacyjnego jest zweryfikowanie wszystkich dokumentów i kodu, co osiąga się za pomocą tych samych metod, które są stosowane podczas testowania statycznego

Podobnie testowanie walidacyjne ma wszystkie kluczowe cechy testowania dynamicznego. Test walidacyjny koncentruje się na potwierdzeniu, że oprogramowanie jest wysokiej jakości, czym dokładnie zajmują się testy systemowe i akceptacyjne.

Teraz, gdy omówiliśmy kilka kluczowych pojęć związanych z testowaniem oprogramowania, przyjrzyjmy się 9 rodzajom testowania oprogramowania, które każdy analityk ds. zapewniania jakości powinien znać.

9 rodzajów testowania oprogramowania, które powinien znać każdy analityk ds. zapewniania jakości:

  1. Testowanie czarnoskrzynkowe
  2. Testowanie białoskrzynkowe
  3. Testowanie szaroskrzynkowe 
  4. Testowanie automatyczne 
  5. Testowanie jednostkowe
  6. Testowanie regresji
  7. Testowanie eksploracyjne
  8. Testowanie funkcjonalne
  9. Testowanie użyteczności

1. Testowanie czarnoskrzynkowe

Testowanie czarnoskrzynkowe to strategia testowania oprogramowania, w której tester nie zna projektu testowanego systemu.

Pamiętasz scenę pod koniec filmu Pulp Fiction, w której Samuel Jackson otwiera walizkę, a jego twarz się rozjaśnia? Jako widzowie wiemy, co walizka oznacza i reprezentuje w kontekście filmu, ale nigdy nie dowiadujemy się, co jest w środku. Tester czarnoskrzynkowy jest widzem, który wie, co dana rzecz — niezależnie od tego, czy jest to walizka, czy oprogramowanie systemowe — powinna robić, ale nie wie, z czego jest zbudowana.

Zdjęcie testowania czarnoskrzynkowego, rodzaje testowania oprogramowania

Tester odpowiedzialny za testowanie czarnoskrzynkowe oprogramowania do rejestrowania czasu uruchomi program bez znajomości jego wewnętrznego projektu i wypróbuje różne funkcje oraz menu, aby upewnić się, że działają zgodnie z oczekiwaniami. Powodem stosowania testowania czarnoskrzynkowego jest to, że bez szczegółowej wiedzy o projekcie oprogramowania tester będzie podchodził do niego z podobnymi oczekiwaniami jak użytkownik końcowy. 

Niektóre zalety testowania czarnoskrzynkowego to:

  • Testerzy nie potrzebują dużej wiedzy na temat języków programowania, ponieważ korzystają z oprogramowania z perspektywy użytkownika.
  • Zapewnia bezstronną ocenę oprogramowania, ponieważ test przeprowadza zespół QA, a nie jego twórcy.
  • Testerzy nie muszą być na bieżąco z procesem tworzenia systemu oprogramowania, co oznacza, że przed rozpoczęciem testów potrzeba bardzo niewiele czasu na przygotowanie.

Powiązany artykuł: 10 najlepszych narzędzi do testowania czarnoskrzynkowego

2. Testowanie białoskrzynkowe

W testowaniu białoskrzynkowym członek zespołu QA w pełni rozumie wewnętrzną strukturę i projekt testowanego oprogramowania. Podchodzi do testu jak inspektor, upewniając się, że każda część programu działa prawidłowo. Testowanie białoskrzynkowe jest czasami nazywane testowaniem przezroczystoskrzynkowym, ponieważ tester obserwuje interakcje między jednostkami podczas testowania oprogramowania. W przeciwieństwie do testowania czarnoskrzynkowego tester białoskrzynkowy nie koncentruje się tak bardzo na doświadczeniu użytkownika. 

Niektóre zalety testowania białoskrzynkowego to:

  • Testy można przeprowadzać na wczesnych etapach tworzenia oprogramowania. Graficzny interfejs użytkownika (GUI) nie musi być w pełni funkcjonalny. 
  • Testy są bardziej szczegółowe i celowe niż testy czarnoskrzynkowe.

W przykładzie z filmu Pulp Fiction tester białoskrzynkowy to postać grana przez Tima Rotha, wpatrująca się bezpośrednio w zawartość walizki. 

3. Testowanie szaroskrzynkowe

W testowaniu szaroskrzynkowym tester ma pewną wiedzę na temat wewnętrznej struktury i projektu oprogramowania (testowanie białoskrzynkowe), ale nadal testuje je z perspektywy użytkownika końcowego (testowanie czarnoskrzynkowe). W ten sposób narodziło się testowanie szaroskrzynkowe. W testowaniu szaroskrzynkowym projekt testu jest opracowywany na podstawie wewnętrznej struktury oprogramowania, a sam test przeprowadza się za pomocą interfejsu użytkownika.

Ponownie, gdyby chodziło o tę słynną scenę z filmu Pulp Fiction, tester szaroskrzynkowy nie byłby ani widzem, ani Timem Rothem. Tym razem testerem byłby sam Quentin Tarantino.  

4. Testowanie automatyczne

Testy automatyczne wykorzystują oprogramowanie do wykonywania zadań bez ręcznych instrukcji testera.

W testowaniu ręcznym tester wykonuje zaplanowane czynności w oprogramowaniu, aby sprawdzić, czy działa ono prawidłowo. Testy automatyczne wykonują takie czynności w imieniu testera. Oto krótka lista narzędzi do automatyzacji oprogramowania i QA, które analitycy QA powinni znać:

Aby uzyskać bardziej szczegółowy przegląd narzędzi do testowania automatycznego, zapoznaj się z listą najlepszych narzędzi do testowania automatycznego, których warto używać.

5. Testowanie jednostkowe

Narzędzia do testów jednostkowych zapewniają prawidłowe działanie każdej pojedynczej części oprogramowania. Niezwykle ważne jest, aby testy jednostkowe były przeprowadzane prawidłowo, w przeciwnym razie zespół programistyczny poniesie ogromne konsekwencje, gdy później okaże się, że kluczowa część oprogramowania nie działa. 

6. Testy regresji

Narzędzia do testów regresji uruchamiają stare testy na nowych kompilacjach, aby upewnić się, że oprogramowanie nadal działa zgodnie z założeniami. Przeprowadzanie testów regresji chroni programistów przed ukrytymi skutkami zmian, upewniając się, że modyfikacja oprogramowania w punkcie A nie zepsuła przypadkowo czegoś w punkcie D. 

Dla analityka ds. zapewniania jakości dwa kroki naprzód i jeden krok wstecz nie powinny być postrzegane jako coś negatywnego. Robiąc od czasu do czasu jeden krok wstecz, upewniasz się, że później nie będziesz zmuszony do zrobienia pięćdziesięciu kroków wstecz.

7. Testy eksploracyjne

Testy eksploracyjne są przeznaczone dla osób, które nie lubią planowania. W większości innych sytuacji przypadek testowy jest dokładnie planowany przed wykonaniem. Nie tutaj. Podczas przeprowadzania testu eksploracyjnego tester bada oprogramowanie bez wcześniej ustalonego planu, korzystając ze specjalistycznych narzędzi do testów eksploracyjnych.

Zaletą testów eksploracyjnych jest to, że pozwalają testerowi na bieżąco dostosowywać się do uzyskanych wyników bez konieczności pisania kolejnego przypadku testowego. Testy eksploracyjne umożliwiają również bieżącą współpracę i opracowywanie teorii.

Wraz ze wzrostem znaczenia zwinnej metodyki wytwarzania oprogramowania wzrosło również znaczenie testów eksploracyjnych. Pozwalając testerom ds. zapewniania jakości korzystać z intuicji, można wykryć wiele interesujących błędów, których tradycyjne wykonanie testów mogłoby nie obejmować. 

Uwaga: testy eksploracyjne mogą wymagać dużej kreatywności. 

More Articles

8. Testy funkcjonalne

Testy funkcjonalne przeprowadza się, aby upewnić się, że oprogramowanie systemowe spełnia wymagania projektu określone przed rozpoczęciem prac programistycznych.

Tester oprogramowania sprawdzi, czy dane wejściowe odpowiadają oczekiwanym wynikom. Testy te są przeprowadzane na jednym z ostatnich etapów testowania, podczas testów systemowych lub akceptacyjnych, i stanowią wyłącznie formę testów czarnoskrzynkowych, ponieważ nie ma znaczenia sposób działania oprogramowania, o ile ono działa. 

9. Testy użyteczności

Testerzy użyteczności upewniają się, że decyzje projektowe są funkcjonalne, a jednocześnie intuicyjne.

Jeśli przewidujesz, że wielu użytkowników oprogramowania będzie chciało tworzyć kopie zapasowe swoich dokumentów co pół godziny, najlepiej umieścić funkcję tworzenia kopii zapasowych w łatwo dostępnym miejscu, zamiast ukrywać ją za czterema podmenu. 

W wielu przypadkach opracowano oprogramowanie, które działa bez zarzutu i zaspokaja ważną potrzebę rynkową, ale z perspektywy użytkownika jest całkowicie niemożliwe do obsługi. Można to wyjaśnić brakiem testów użyteczności na etapie testowania oprogramowania.

Ostatecznie, niezależnie od tego, jak dobre jest oprogramowanie pod względem technicznym, trudno będzie znaleźć dla niego rynek, jeśli użytkownicy nie będą czerpać przyjemności z korzystania z niego.

Chcesz więcej?

Branża testowania oprogramowania stale się zmienia, a analitycy ds. zapewniania jakości muszą być na bieżąco z aktualnymi trendami. Istnieje nieskończenie wiele materiałów na temat testowania oprogramowania, w tym podcasty, książki, newslettery i nie tylko.

Zapisz się do newslettera The CTO Club aby otrzymywać aktualizacje produktów, recenzje narzędzi i kolejne zestawienia zasobów.

Jason Boog
Over his 15-year career, Jason Boog has worked as a QA tester, QA analyst, and Senior QA Analyst on video games, commercial sites, and interactive web applications. He spent more than a decade building out the QA team and process as Director of Quality & Client Support at a full-service digital agency.
Follow the author: