Testowanie oprogramowania Marcin Jerzak Piotr Fisz

Testowanie oprogramowania Jest to proces związany z wytwarzaniem oprogramowania. Celem testowania jest wykrywanie błędów oraz badanie niezawodności systemu. Weryfikacja (verification) - testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań. Atestowanie (validation) - ocena systemu lub komponentu podczas lub na końcu procesu jego rozwoju na zgodności z wyspecyfikowanymi wymaganiami. Atestowanie jest więc weryfikacją końcową.

Cele testowania: Oprogramowanie testujemy głównie mając na uwadze wykrycie i pozbycie się błędów w systemie oraz ocena niezawodności oprogramowania.

Błędy Błąd (failure, error) – jest to niepoprawna konstrukcja znajdująca się w programie, która może doprowadzić do niewłaściwego działania. Błędne wykonanie (failure) - niepoprawne działanie systemu w trakcie jego pracy. Należy mieć na uwadze, że te samo błędne wykonanie programu może być spowodowane przez różne błędy pracy oprogramowania.

Weryfikacja Weryfikacja ma na celu sprawdzenie czy produkt w danej fazie rozwoju spełnia założenia powstałe podczas startu danej fazy. Przy weryfikacji możemy wykorzystać: Przeglądy, inspekcje, testowanie, sprawdzanie, audytowanie.

Przeglądy Przeglądem nazywamy spotkanie, w czasie którego produkt lub jego części są prezentowane kierownictwu, użytkownikom, klientom lub innym osobom mającym kontakt z produktem w celu uzyskania opinii i wskazówek. Rozróżniamy przeglądu formalne i nieformalne.

Przegląd Przeglądy formalne mogą mieć postać: - przeglądu technicznego (ocena zgodności postępu prac względem planu). - przejść (ocena dokumentów, modeli, projektów i kodu w celu znalezienia i naprawy błędów). - audytu (potwierdzenie zgodności z założeniami, dokumentami itp. Przez osoby z „zewnątrz firmy”).

Audyt Jest to przegląd i ocena jakości oprogramowania, która zapewnia zgodność ze standardami i specyfikacjami oraz daje obraz o stanie całego projektu. Dla zapewnienia lepszych wyników audyt powinien być wykonany przez osoby z zewnątrz.

Inspekcje Jest to technika polegająca na badaniu kodu przez osoby lub grupę osób nie będących autorami programu w celu znalezienia błędów. Średnia skuteczność wynosi 60%. Jest to technika rzadko stosowana ponieważ wymagane są planowanie oraz kompetentni ludzie. Dodatkowym minusem jest utrudniona analiza kosztów i zysków.

Inspekcje Cechy inspekcji: - Sesje są zaplanowane i przygotowane - Błędy i problemy są notowane - wykonywane przez techników dla techników Korzyści inspekcji: - Wzrost produktywności od 30% do 100% - Skrócenie czasu projektu od 10% do 30% - Skrócenie kosztu i czasu wykonywania testów od 5 do 10 razy

Rodzaje testów Wykrywanie błędów – znajdowanie jak największej ilości błędów Testy statystyczne – wykrywanie najczęściej statystycznie występujących błędów oraz ocena niezawodności systemu Testy dynamiczne – wykonywanie kawałków programu i porównywanie wyników z poprawnymi Testy statyczne – analiza kodu

Fazy testowania Testy modułów Testy systemu Testy akceptacji Wydajność systemu Interfejs systemu Własności operacyjne systemu Testy zużycia zasobów Zabezpieczenie systemu Przenoszalność systemu Niezawodność programu Odtwarzalność oprogramowania

Fazy testowania Bezpieczeństwo oprogramowania Kompletność i jakość założonych funkcji systemu Nie przekraczanie ograniczeń Modyfikowalność oprogramowania Obciążalność oprogramowania Skalowność systemu Akceptowalność systemu Jakość dokumentacji

Testowanie na zasadzie czarnej skrzynki Metoda polega na testowaniu bez sprawdzania wnętrza programu Powinno się testować dla całego zakresu danych Dane powinno się podzielić na takie, które mogą dawać podobne błędy Plusem jest możliwości pokazania brakujących funkcji

Testowanie na zasadzie białej skrzynki Metoda polega na testowaniu wewnętrznej logiki po przez dobranie odpowiednich danych wejściowych, co umożliwia przetestowanie wszystkich ścieżek. Często jest wymagane przygotowanie danych testowych spełniających nasze wymagania Minusem jest brak możliwości pokazania brakujących funkcji

Określenie niezawodności oprogramowania Prawdopodobieństwo błędnego wykonania podczas realizacji tranzakcji. Miarą nazywamy częstość wystąpienia błędnych tranzakcji. Częstotliwość występowania błędnych wykonań. Średni czas między błędami. Dostępność. Jest to prawdopodobieństwo dostępności systemu w danej chwili.

Oszacowanie niezawodności Ma duży wpływ na koszt konserwacji oprogramowania. Pozwala oszacować koszt serwisu, liczbę personelu, liczbę zgłoszeń błędów. Pozwala ocenić i polepszyć proces wytwarzania.

Wykrywanie błędów Testy funkcjonalne – zakładają znajomość wymagań wobec testowanej funkcji. System traktujemy jak czarną skrzynkę, która realizuje funkcje w nieznany sposób. Testy strukturalne – zakładają znajomość sposobu implementacji testowanych funkcji

Testy funkcjonalne Uniemożliwiają przetestowanie rzeczywistego systemu ze względu na liczbę kombinacji danych wejściowych. Zakłada się, że jeśli dana funkcja działa dla kilku danych wejściowych poprawnie to i dla reszty też tak będzie.

Testy strukturalne Dane wejściowe dobiera się na podstawie analizy struktury programu realizującego daną funkcję. Wyróżniamy kryterium pokrycia wszystkich instrukcji, czyli dane wejściowe są tak dobrane by każda instrukcja wykonała się co najmniej raz oraz kryterium pokrycia warunkowego czyli istnieje możliwość, że dla danych wejściowych nie będą spełnione ich wymagania.

Co używamy do testowania: Programy uruchamiające (debuggers) Analizatory przykrycia kodu Programy porównujące

Testy statyczne Testy statyczne polegają na analizie kodu bez jego uruchamiania. Dowody poprawności – praktycznie nie używane Metody nieformalne – jest to analiza kodu prze programistów. Pozwala znaleźć błędy takie jak: niezainicjowanie zmiennych, przepełnienie tabeli, nieprawidłowe urzucie kursorów i wskaźników itp.

Testy systemu Testowanie wstępujące – najpierw testujemy moduły niższego poziomu a potem wyższego. Testowanie zstępujące – najpierw testujemy moduły wyższego poziomy a potem niższego.

Testy pod obciążeniem i odpornościowe Testy obciążeniowe umożliwiają zbadanie zachowania, wydajności i niezawodności systemu podczas pracy pod pełnym lub nadmiernym obciążeniem. Testy odpornościowe pokazują jak zachowuje się system w przypadku np. zaniku prądu, wprowadzenie niepoprawnych danych itp.

Testy akceptacyjne Testy akceptacyjne polegają na przekazaniu oprogramowania klientom docelowym w celu zatwierdzenia. Jeżeli oprogramowanie jest realizowane na zamówienie system przekazywany jest do przetestowania przyszłemu użytkownikowi po stronie zleceniodawcy. Takie testy są nazywane testami alfa. Dla oprogramowania sprzedawanego rynkowo przewidziane są testy polegające na nieodpłatnym przekazaniu pewnej liczby kopii systemu grupie użytkowników. Testy te są nazywane testami beta.

Czynniki sukcesu Na czynniki sukcesu wpływa: Określenie fragmentów o szczególnej niezawodności Właściwa motywacja testerów Poprawa znalezionych błędów Oszacowanie niezawodności i kosztów konserwacji.

Standardy w testowaniu 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ć.

Standardy w testowaniu 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.

Test plan - zawartość (ang. requirements traceability) Opis Odwzorowanie testów na wymagania (ang. requirements traceability) Weryfikacja pokrycia wymagań Wyszczególnienie co będzie podlegać testowaniu Plan czasowy Procedury przeprowadzania testów Zachowywanie wyników testów Wymagania sprzętowe i programowe Znane ograniczenia

Podsumowanie Weryfikacja != walidacja Cel testowania: stwierdzenie błędów w systemie Testowanie musi być uwzględnione od początku w planach projektu Również w alokacji zasobów do projektu Test plan – niezbędny dokument projektowy