Testowanie oprogramowania

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacji, wyszukiwania

Testowanie oprogramowania – proces związany z wytwarzaniem oprogramowania. Jest to jeden z procesów zapewnienia jakości oprogramowania. Testowanie ma na celu weryfikację oraz walidację oprogramowania. Weryfikacja oprogramowania ma na celu sprawdzenie, czy wytwarzane oprogramowanie jest zgodne ze specyfikacją. Walidacja sprawdza, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika. Testowanie oprogramowania może być wdrożone w dowolnym momencie wytwarzania oprogramowania (w zależności od wybranej metody). W podejściu klasycznym największy wysiłek zespołu testerskiego następuje po definicji wymagań oraz po zaimplementowaniu wszystkich zdefiniowanych funkcjonalności. Nowsze metody wytwarzania oprogramowania (np. Agile), skupiają się bardziej na jednostkowych testach wykonywanych przez członków zespołu programistycznego, zanim oprogramowanie trafi do właściwego zespołu testerów.

Informacje ogólne[edytuj | edytuj kod]

Testowanie nigdy nie jest w stanie wykryć wszystkich błędów danego oprogramowania, jednak może dostarczyć informacji o stabilności oprogramowania, zgodności z wymaganiami klienta, czy też zgodności z oczekiwaniami klienta. Trzeba pamiętać, że testowanie nie sprawdza pod kątem wszelkich możliwych warunków początkowych, lecz jedynie z wybranymi warunkami. Testowanie może we wczesnych fazach projektu wykryć defekty oprogramowania. Wczesne wykrycie defektu jest ważne z ekonomicznego punktu widzenia ponieważ gwarantuje niskie koszty naprawy. Nie wszystkie defekty oprogramowania wynikają z błędów kodowania aplikacji. Duża część defektów jest wynikiem błędów popełnionych podczas definicji wymagań. Tak więc testowanie oprogramowania sprowadza się również do wstępnej analizy wymagań.

Podział testów[edytuj | edytuj kod]

Testy można podzielić na kilka sposobów:

  • na testy elementów systemu (klas, komponentów, podsystemów, systemowe)
  • na białoskrzynkowe oraz czarnoskrzynkowe (inaczej testy strukturalne i niestrukturalne)
  • na testy warstw (testy funkcjonalne - testujące warstwę logiki biznesowej, testy API, testy UI, testy GUI, testy warstwy danych,...)
  • na testy wymagań (wszystkie testy weryfikujące zgodność implementacji z wymaganiami, np. testy funkcjonalne, testy GUI), w tym testy niefunkcjonalne - por. klasyfikacja wymagań (i testów) FURPS+ zdefiniowana w ramach Rational Unified Process (RUP) oraz testy implementacji (testy weryfikujące zgodność implementacji z założeniami programisty, np. testy jednostkowe)

Częstym błędem jest utożsamianie testów funkcjonalnych z testami czarnej skrzynki, podczas gdy testy funkcjonalne mogą wymagać znajomości kodu źródłowego (rzadziej, np. w systemach czasu rzeczywistego może być wymagana znajomość struktury pakietów danych przesyłanych w protokołach transmisji) lub nie (częściej). Testy funkcjonalne należą do innego kryterium podziału niż testy czarnej-skrzynki.

Dodatkowo można wyróżnić testy wykonane w określonym celu:

  • retesty – testy poprawek błędów
  • testy regresywne – testy niezmienionych części oprogramowania po wykonaniu zmian.

Poziomy testowania[edytuj | edytuj kod]

Testy dzieli się na pięć poziomów:

Standardy w testowaniu[edytuj | edytuj kod]

Podstawowym standardem dla testowania oprogramowania jest IEEE 829-1998 (829 Standard for Software Test Documentation). Jest to standard określający formę zbioru 8 dokumentów potrzebnych w każdej z faz testowania oprogramowania. W efekcie każdej z tych faz tworzony jest 1 dokument wynikowy. Standard ten określa dokładnie format dokumentów, jednak nie wymaga, aby wszystkie były wykonane. Nie zawiera także informacji o tym, co dokładnie mają zawierać.

  • Test Plan – dokument planowania zarządzania projektem, który składa się z informacji o tym, w jaki sposób będą prowadzone testy, kto będzie je przeprowadzał, co będzie testowane, jak długo potrwa cały proces oraz jaki będzie zakres testów.
  • Test Design Specification – szczegóły na temat warunków testowania, oczekiwanych wyników a także kryteriach przejścia testu.
  • Test Case Specification – specyfikuje dane testowe do użycia podczas wdrażania warunków testowania określonych w Test Design Specification.
  • Test Procedure Specification – zawiera szczegóły na temat przeprowadzenia każdego testu włączając w to założenia oraz poszczególne kroki testów.
  • Test Item Transmittal Report – zawiera raporty na temat czasu przejścia testowanych fragmentów oprogramowania między etapami.
  • Test Log – zawiera informacje o tym, które przypadki testowania zostały użyte, kto je użył i w jakim porządku oraz informacje o ich powodzeniu.
  • Test Incident Report – zawiera informacje o testach zakończonych niepowodzeniem. Informacje o wynikach oraz dlaczego dany test nie powiódł się.
  • Test Summary Report – raport ten zawiera wszystkie istotne informacje ujawnione podczas zakończonych testów oraz wyceny jakości procesów testowania, jakości oprogramowania poddanego testowi, a także statystyki uzyskane z Incident Report. Raport referuje również do typów i czasu trwania wykonanych testów w celu usprawnienia wszelkich planów związanych z testami w przyszłości. Ostateczna forma dokumentu jest wykorzystywana w celach weryfikacji poprawności testowanego systemu względem wymagań zdefiniowanych przez zleceniodawców.

Do innych standardów związanych z testowaniem oprogramowania należą: IEEE 1008, IEEE 1012, BS 7925-1, BS 7925-2.

Od 2008 roku nowszym standardem jest standard IEEE 829-2008.

Zobacz też[edytuj | edytuj kod]

Linki zewnętrzne[edytuj | edytuj kod]