Testowanie oprogramowania
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 pozwala skontrolować, 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 stosowanej metody). W podejściu kaskadowym zgodnym z modelem V wysiłek zespołu testerskiego zaczyna się wraz z definicją wymagań i jest kontynuowany po zaimplementowaniu zdefiniowanych wymagań. Nowsze metody wytwarzania oprogramowania (np. metody zwinne) rozkładają wysiłek testerski równomiernie na poszczególne iteracje i skupiają się na testach jednostkowych oraz automatyzacji weryfikacji wykonywanych przez członków zespołu[1].
Historia[edytuj | edytuj kod]
Glenford J. Myers(ang.) zaproponował odróżnienie debugowania od testowania w publikacji z 1979 r., chociaż jego uwaga była poświęcona testom na złamanie – „A successful test case is one that detects an as-yet undiscovered error”, czyli „udany przypadek testowy to taki, który odkrywa dotąd nieznany błąd”. Zilustrował chęć społeczności inżynierów oprogramowania do oddzielenia podstawowych działań rozwojowych, takich jak debugowanie, od weryfikacji[2].
Informacje ogólne[edytuj | edytuj kod]
Testowanie nie jest w stanie wykryć wszystkich defektów oprogramowania, jednak może dostarczyć informacji o jego zgodności z wymaganiami klienta, czy też z jego oczekiwaniami. Trzeba pamiętać, że testowanie nie sprawdza oprogramowania pod kątem wszelkich możliwych warunków początkowych, lecz jedynie w wyselekcjonowanych warunkach.Testowanie może we wczesnych fazach projektu wykryć defekty nie tylko oprogramowania, ale i specyfikacji wymagań czy projektu. Wczesne wykrycie defektu jest ważne z ekonomicznego punktu widzenia, ponieważ gwarantuje niższe koszty jego naprawy. Defekty oprogramowania nie wynikają jedynie z błędów kodowania. Duża część defektów jest wynikiem błędów popełnionych podczas definicji wymagań. Testowanie oprogramowania sprowadza się również do analizy statycznej i testowania wymagań. Spora część defektów jest spowodowana niejednoznacznymi wymaganiami i skutkuje nieprawidłowym wskazaniem obecności defektu tak jak w tablicy pomyłek. W sytuacji gdy wymagania są niejasne to ciężko jest określić poprawne zachowanie systemu. W skrajnych przypadkach taki defekt może być celowo nienaprawiany lub odłożony do naprawy w kolejnej iteracji[3].
Podział testów[edytuj | edytuj kod]
Testy można podzielić na kilka sposobów:
- ze względu na weryfikowane obiekty (przykładowo testy klas, komponentów, podsystemów, systemu lub zintegrowanych systemów)
- na białoskrzynkowe (strukturalne), weryfikujące kod źródłowy oraz czarnoskrzynkowe testujące warstwę interfejsu
- bazujące na wymaganiach (testy weryfikujące zgodność implementacji z wymaganiami, np. testy funkcjonalne, testy graficznego interfejsu użytkownika), testy niefunkcjonalne – por. klasyfikacja wymagań (i testów) FURPS+ zdefiniowana w ramach Rational Unified Process (RUP) czy testy weryfikacji (testy sprawdzające zgodność implementacji z założeniami np. programisty)
- ze względu na metodę weryfikacji z wyróżnieniem testów statycznych, bez uruchomienia aplikacji i testów dynamicznych wymagającej pracę na uruchomionym oprogramowaniu
Częstym błędem jest stawianie znaku równości między testami funkcjonalnymi, a testami czarnej skrzynki. Testy funkcjonalne mogą wymagać umiejętności czytania kodu źródłowego, czego nie wymaga się przy testach interfejsów zewnętrznych.
Dodatkowo można wyróżnić testy wykonane w określonym celu:
- retesty – testy poprawek defektów
- testy regresywne – testy oprogramowania po wykonaniu zmian, niekoniecznie w kodzie (przykładowo aktualizacji wersji systemu operacyjnego)
Poziomy testowania[edytuj | edytuj kod]
Testy dzieli się na pięć poziomów:
- testy jednostkowe
- testy akceptacyjne, w których możemy wyróżnić również specyficzne dla oprogramowania komercyjnego testy alfa i testy beta
- testy integracyjne komponentów
- testy systemowe
- testy integracyjne z systemami
Standardy w testowaniu[edytuj | edytuj kod]
W testowaniu zdefiniowano kilka standardów, ale żaden z nich nie odgrywa poważniejszej roli w formalizowaniu testowania, ani nie został powszechnie przyjęty za obowiązujący. Przykładowe standardy w testowaniu:
- IEEE 829- 2008 Standard for Software and System Test Documentation
- ISO / IEC / IEEE 29119 Software Testing Standard
- IEEE 730-2014 Standard for Software Quality Assurance Processes
- ISO/IEC 25010:2011 Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models
Przypisy[edytuj | edytuj kod]
- ↑ Radosław Smilgin: Zawód Tester. PWN, 2016. ISBN 978-83-01-18317-2.
- ↑ Glenford J. Myers, The art of software testing, New York: Wiley, 1979, ISBN 0-471-04328-1, OCLC 4194539 [dostęp 2019-06-08].
- ↑ Paweł Kwasik: Wynik false-positive czyli defekt którego nie ma. 2019-08-02. [dostęp 2019-08-02].