Testowanie oprogramowania

Testowanie jest ważnym i kosztownym etapem realizacji projektu informatycznego, pochłaniającym, w systemach o wysokich wymaganiach niezawodnościowych, wartość pięciokrotnego kosztu innych faz systemu informatycznego. Powinno ono być integralnym składnikiem procesu kontroli jakości oprogramowania. Wydawać by się mogło, że naturalne jest, aby tak ważny i kosztowny etap realizacji projektu był przeprowadzany według sprawdzonych reguł sztuki inżynierskiej. Co więcej, koszty usuwania błędów w późniejszych fazach projektowych rosną lawinowo. Głównym sposobem eliminacji błędów powinno być zatem zapobieganie im już we wczesnych fazach realizacji systemu informatycznego z przekonaniem, że wysoka jakość wymagań czy projektu bardzo pomaga w._

wytworzeniu kodu o podobnej jakości. Niezrozumienie istoty testów polega na sprowadzenie ich roli do generalnego, uniwersalnego i najczęściej jedynego narzędzia kontroli jakości systemu informatycznego. Problem jednak tkwi w tym, że celem procesu testowania jest znalezienie błędów, a nie zapewnienie jakości. Osoba poszukująca błędów w programie nie może zapewnić wymaganej funkcjonalności systemu. To powinna gwarantować analiza wymagań, projektowanie i kodowanie.

Testowanie nie zapewnia również efektywności przetwarzania i wykorzystania zasobów. Testy pozwalająją jedynie zmierzyć, ale to dopiero odpowiednio dobrany algorytm i jego realizacja prowadzą do osiągnięcia wymaganych parametrów.

Testowanie nie zapewnia również niezawodności, ale pozwala ocenić jej poziom pośrednio przez oszacowanie liczby błędów i rozkład ich ilości w czasie.

Testowanie ma dobrze określony cel, wynikający z natury procesu wytwarzania oprogramowania, a techniki, których używa są wyspecjalizowane pod kątem realizacji tego celu. Dlatego proces testowania musi być uzupełniony innymi działaniami kontrolno — weryfikacyjnymi tak by system różnorodnych oddziaływań na jakość systemu informatycznego był pełny, tzn. ograniczał propagację błędów z wcześniejszych faz projektowych do późniejszych. Z tych wzglądów, często testowanie utożsamia się z pojęciem kontroli jakości w ogóle obejmując tym procesem także recenzje i przeglądy dokumentacji, modeli wymagań, projektu, itd..

Trudno, zatem zbudować pełny zakres lub strukturę testów, które wykryją wady oprogramowania. Usuwanie wad i korekty błędów mogą pochłaniać nawet połowę czasu pracy projektanta, dlatego każde efektywne udoskonalenie metodologii testów lub jej zautomatyzowanie pozwalające zmniejszyć nakłady czasu zużywanego na testy ma ważny wpływ na czas projektowania i koszt cyklu prac. Należy pamiętać o tym wtedy, gdy będzie planowana możliwość wsparcia prac zespołów testów przez różnego rodzaju narzędzia. Opłacalność każdej inwestycji w usprawnianie i doskonalenie testowania jest szczególne widoczna w wypadku testów regresji, które dotyczą funkcjonalności już przetestowanej, a która mogła ulec degradacji na skutek efektów ubocznych zmian np. w innym module programu. Potrzeba takich testów jest skutkiem natury błędów oprogramowania, które ujawniają się w dynamice realizacji funkcji wykonywanych w kontekście danych wejściowych.

Przeprowadzanie testów regresji bez wsparcia narzędziowego oznacza wykonywanie po setki razy tych samych testów.

Podstawą do wykonywana testów są kryteria testowe opracowywane pod kątem kryteriów jakości istotnych dla klienta. Systemy informatyczne są zatem testowane dla sprawdzenia, czy nie ma błędów w realizacji jego funkcji, czy jest bezpieczny lub przyjazny dla użytkownika. Najogólniej dzielimy testowanie na funkcjonalne (black - box - testing), podczas którego szukane są błędy i niezgodności ze specyfikacją w jakiejś wydzielonej i zamkniętej części programu i tzw. white - box - testing, kiedy sprawdzane jest, czy procedura lub moduł znajdują się zawsze w oczekiwanym stanie, czy są błędy w algorytmach realizacji funkcji, czy wszystkie możliwe ścieżki programowe zostały wykonane (zakłada się przy tym typie testowania, że znana jest logika modułów i procedur).

Zależnie od stanu zaawansowania prac nad modułami systemu testowanie przechodzi przez różne, przedstawione w tabeli 2 fazy.

Tab. 2. Podstawowe fazy procesu testowania Faza testów Cel fazy testów Testowanie

jednostkowe

Sprawdzane są ścieżki i błędy wewnątrz modułu. Jest ono ograniczone do zakresu modułu, dzięki czemu może być prowadzone równolegle dla różnych

159

modułów. Zwykle wymaga stworzenia dodatkowego środowiska testowego i specjalnych programów testowych służących do wywoływania sprawdzanych modułów z odpowiednimi parametrami

Testowanie integracyjne

Kontroluje poprawności interfejsów między modułami. Jest ono systematyczną techniką składania oprogramowania z modułów w większe fragmenty (podsystemy) z jednoczesnym testowaniem interfejsów, gdzie poszczególne moduły nie operują na danych testowych, ale na rzeczywistych danych produkowanych przez współpracujące moduły

Testowanie walidacyjne

Dotyczy uruchomionego programu, który teoretycznie powinien być pozbawiony już błędów implementacyjnych i integracyjnych. Walidacja polega na sprawdzeniu, czy program funkcjonuje w sposób oczekiwany i opisany w specyfikacji wymagań, a szczególnie w rozdziale o kryteriach akceptacji. Jest to ostatni krok przed przekazaniem oprogramowania użytkownikowi, będący jakby testami akceptacyjnymi u producenta.

Testowanie systemowe Beta-testy

Testowanie systemowe obejmuje testy w środowisku użytkownika przeprowadzane przez producenta lub w postaci beta-testów przez samego użytkownika (np. dystrybutorów, partnerów, itp.) w jego systemie i na jego rzeczywistych danych.

Nazywane jest również testowaniem akceptacyjnym.

Źródło: na podstawie [5]

Duże znaczenie ma psychologiczny dobór odpowiedniego zespołu testującego. Osoba testująca, która jest autorem programu nigdy nie będzie obiektywna. Dlatego testowanie powinna przeprowadzać inna, niezależna osoba, której zadaniem jest bez „sentymentów” znaleźć błąd.

Testy powinny być zaplanowane (przykładowy szablon planu testów zawiera tabela 3) co wyznacza kolejność: najpierw strategiczne planowanie testów formułujące koncepcję testów najbardziej adekwatną do specyfiki projektowanego systemu, potem operacyjne organizujące pracę, produkty testowe i fazy testów i w końcu taktyczne, a więc procedury i przypadki testowe oraz nadzorowanie wykonania testów. Ostatnim elementem który łączy wszystkie poprzednie jest repozytorium testowe. Stanowi ono swego rodzaju bazę wszelkich informacji dotyczących testów w projekcie. Obejmuje wszelkie niezbędne dokumenty, z których łatwo mogą korzystać testujący, gotowe do wielokrotnego wykorzystania

procedury testowe i zestawy danych testowych. Jest to także najwłaściwsze miejsce dla rejestru błędów z historią ich obsługi, a także statystyk i charakterystyk niezawodnościowych systemu, podsystemów, modułów, itd. Jest to swoista hurtownia danych testowych, pozwalająca na różnego rodzaju wielowymiarowe analizy stanu produktu, przewidywanego poziomu niezawodności, itd.

Tab. 3. Przykładowy szablon planu testów Plan testów

Wprowadzenie Opis celu i zakresu testów, ogólnej koncepcji testów i zastosowanego podejścia.

Architektura systemu

Opis architektury systemu w zakresie niezbędnym do zrozumienia potrzeby i zakresu testów

Środowisko testowe

Opis konfiguracji sprzętowo - programowej, w której będą uruchamiane testy. Środowisko testowe może się zmieniać w zależności od zakresu testów, fazy projektowej i kryteriów, które w danym momencie podlegają badaniom

Kryteria testowe Opis warunków spełnienia wymagań przez oprogramowanie.

Zwykle kryteria odnoszą się do podstawowych kategorii jakościowych tzn.: funkcjonalności, użyteczności, efektywności, bezpieczeństwa, przenośności i niezawodności Techniki testów Opis technik testów, które będą wykorzystywane w testach

oprogramowania, np. technika logicznego pokrycia grafu wywołań

Produkty testowe Opis produktów projektowych, które będą powstawać w wyniku przygotowania do procesów testowania (plan testów, projekty testów), w jego trakcie (zestawy danych testowych, wyniki testów, rejestr błędów) i po zakończeniu (wyniki testów, zalecenia, dokumentacja testowa, statystyki)

Organizacja procesu testowania

Opis struktury, ról, podziału odpowiedzialności i zasobów niezbędnych do przeprowadzenia testów

Harmonogram testów

Opis planu poszczególnych działań związanych z testami oprogramowania rozłożonych na osi czasowej

Repozytorium testów

Opis bazy danych testowych zawierający specyfikację produktów przechowywanych w bazie, szablony dokumentów, proceduiy gromadzenia danych testowych, wyników testów, narzędzie i procedury rejestracji błędów i uzgadniania przekazywania ich do poprawek, itp.

Źródło: na podstawie [5]

Są różne sposoby wykonywania testów, ale trzeba o nich myśleć i je planować już na etapie analizy wymagań. Oprogramowane powinno mieć modularną strukturą pozwalającą na łatwe testowanie. Musi istnieć dokumentacja

161

projektowa, specyfikacje wymagań, interfejsów, kryteria efektywności, bezpieczeństwa, itp. Bez tego nie da się przygotować skutecznych procedur testowych, a samo oprogramowanie także straci na niezawodności.