Dlaczego testowanie jest ważne?

Transkrypt

1 Testowanie

2 Dlaczego testowanie jest ważne? Oprogramowanie które nie działa poprawnie może doprowadzić do: straty czasu, pieniędzy utraty reputacji uszkodzeń ciała a nawet śmierci

3 Definicja błędu Oprogramowanie nie robi czegoś co zostało wymienione w jego specyfikacji Oprogramowanie wykonuje coś czego według specyfikacji nie powinno robić Oprogramowanie robi coś o czym specyfikacja nie wspomina Oprogramowanie nie wykonuje czegoś o czym specyfikacja nie wspomina mimo że powinno to być wymienione jako istotna część systemu. Oprogramowanie jest trudne do zrozumienia, powolne lub skomplikowane.

4 Przyczyny błędów oprogramowania błędy ludzkie: natura ludzka, presja czasu duże skomplikowanie kodu źródłowego duże skomplikowanie infrastruktury zmiany technologii zmiany wymagań interakcje z wieloma innymi systemami złe zarządzanie projektem korzystanie z niesprawdzonych narzędzi Copy paste

5 Rola testowania oprogramowania zmniejsza ryzyko wystąpienia awarii w czasie użytkowania oprogramowania podnosi jakość oprogramowania konieczne do spełnienia wymagań kontraktu, wymagań prawnych, wymagań standardów przemysłowych

6 Zasady testowania Testowanie udowadnia istnienie błędów Testy wyczerpujące są niemożliwe Testować jak najwcześniej Kumulowanie się błędów Mylne przekonanie o braku błędów Programu nie da się przetestować całkowicie

7 Cele testów Znalezienie defektów Uzyskanie informacji o poziomie jakości oprogramowania (zbudowanie zaufania) Zapobieganie defektom: projektowanie testów jak najwcześniej

8 Rodzaje testów testy developerskie znalezienie i eliminacja jak największej liczby błędów testy akceptacyjne potwierdzenie, że oprogramowanie spełnia wymagania testy utrzymaniowe sprawdzenie czy nowe defekty nie zostały wprowadzone testy operacyjne sprawdzenie charakterystyk niefunkcjonalnych oprogramowania test regresji zapewnienie że nowe błędy w częściach nie zmienionych przez poprawki nie zostały wprowadzone/odkryte

9 Rodzaje testów testy integracyjne wykonywane są w celu wykrycia błędów w interfejsach i interakcjach pomiędzy modułami testy wydajnościowe sprawdzenie czy poszczególne akcje wykonywane są przez aplikację w akceptowalnym czasie testy obciążeniowe jak wiele zapytań jest w stanie obsłużyć system w określonym przedziale czasu. testy jednostkowe

10 Podstawowy proces testowy Planowanie i kontrola Analiza i projektowanie Implementacja i wykonanie Obliczanie kryteriów wyjścia i raportowanie Zakończenie testów

11 Planowanie i kontrola Planowanie testów: Weryfikacja misji testowania Zdefiniowanie strategii testowania Zdefiniowanie celów testowania Określenie aktywności testowych mających spełnić cele i misję testowania Kontrola testów: Porównywanie aktualnego postępu w stosunku do założonego planu Raportowanie statusu (szczególnie odchyłek od założonego planu) Podejmowanie kroków niezbędnych do spełnienia założonej misji i celów testów

12 Analiza i projektowanie Przegląd bazy testów: wymagania, architektura, projekt systemu, projekt interfejsów Oszacowanie testowalności bazy testów i celów testów Identyfikacja i priorytetyzacja warunków testowych na podstawie analizy bazy testowej Projektowanie i priorytetyzacja przypadków testowych Identyfikacja koniecznych danych testowych Projekt środowiska testowego, identyfikacja wymaganej infrastruktury i narzędzi

13 Implementacja i wykonanie Implementacja przypadków testowych poprzez projektowanie i prioretyzację procedur testowych Wybór danych testowych Przygotowanie automatycznych skryptów testowych Stworzenie zestawów testów z procedur testowych dla wygodniejszego wykonywania testów Weryfikacja przygotowania środowiska testowego.

14 Obliczanie kryteriów wyjścia i raportowanie Oszacowanie kryteriów zakończenia testów i porównanie ze zdefiniowanymi celami: Porównanie wyników testów z kryteriami wyjścia zdefiniowanymi na etapie planowania Oszacowanie czy konieczna jest kontynuacja testów Przygotowanie Raportu Podsumowującego

15 Zakończenie testów Zebranie informacji z zakończonych testów w celu zgromadzenia doświadczeń, produktów testów, potrzebnych statystyk Dostarczenie dokumentacji z testów Zamknięcie błędów Archiwizacja pełnej dokumentacji testowej Analiza wniosków w celu ulepszenia procesu testów w przyszłych dostawach

16 Co podlega testowaniu? Kompletność i jakość złożonych funkcji systemu Interfejsy systemu Zabezpieczenie systemu odporność systemu na naruszenie prywatności, tajności, integralności Przenaszalność oprogramowania poprawność działania w zróżnicowanym środowisku Niezawodność oprogramowania zwykle mierzona średnim czasem pomiędzy błędami Odtwarzalność oprogramowania mierzona średnim czasem doprowadzenia do poprawnego działania po awarii

17 Co podlega testowaniu? Bezpieczeństwo oprogramowania stopień minimalzacji katastrofalnych skutków wynikających z niesprawnego działania Testy zużycia zasobów nie przekraczanie ograniczeń np. na zużycie pamięci, obciążenie procesora Obciążalność oprogramowania zdolność do poprawnej pracy przy dużych obciążeniach Skalowalność systemu spełnienie warunków np. czasowych przy wzroście obciążenia Akceptowalność systemu stopień usatysfakcjonowania użytkownika Jakość dokumentacji

18 Podział testów Ze względu na widzialność kodu: Białoskrzynkowe Czarnoskrzynkowe

19 Testy białoskrzynkowe Zalety: ponieważ wymagana jest znajomość struktury kodu, łatwo jest określić jaki typ danych wejściowych/wyjściowych jest potrzebny, aby efektywnie przetestować aplikację pomaga zoptymalizować kod aplikacji pozwala dokładnie określić przyczynę i miejsce w którym znajduje się błąd Wady: ponieważ wymagana jest znajomość struktury kodu, do przeprowadzenia testów potrzebny jest tester ze znajomością programowania co podnosi koszty

20 Testy czarnoskrzynkowe Zalety: testy są powtarzalne : zainwestowany wysiłek może być użyty wielokrotnie Wady: nie wszystkie właściwości systemu mogą zostać przetestowane przyczyna błędu nie jest znana

21 Kiedy zakończyć testy Zbliża się deadline Przypadki testowe przechodzą z zadawalającym prawdopodobieństwem Budżet na testy się kończy Pokrycie kodu, funkcjonalności i wymagań osiągnęło wymagany poziom

22 Niezależność testowania Ryzyko związane z testowaniem własnego kodu Korzyści: Wzrost efektywności znajdowania błędów Spojrzenie na oprogramowanie pod innym kątem Specjalistyczna wiedza o testowaniu Brak powiązania z produktem Wady: Izolacja w stosunku do zespołu programistów Niezależni testerzy mogą stanowić wąskie gardło jako ostatni punkt sprawdzenia oprogramowania Programiści mogą stracić poczucie odpowiedzialności za jakość oprogramowania

23 Poziomy niezależności Testy projektowane przez autora kodu (Programistę) brak niezależności Testy projektowane przez inną osobę z zespołu Programistów Testy projektowane przez osoby z odrębnego zespołu w organizacji (np. zespołu testowego) Testy projektowane przez inną organizację lub firmę (outsourcing) Testy projektowanie przez testerów z organizacji klienta bądź użytkowników Niezależni specjaliści testowi do wybranych typów testów np. testów użyteczności, wydajności

24 Konserwacja oprogramowania Inne używane terminy to pielęgnacja lub utrzymanie (ang. maintenance) Konserwacja polega na zapewnieniu poprawnego i efektywnego funkcjonowania systemu poprzez wprowadzenie niezbędnych modyfikacji. Istnieją trzy główne klasy wprowadzanych w oprogramowaniu modyfikacji: poprawiające polegają na usuwaniu z oprogramowania wykrytych podczas normalnej pracy błędów (nie zostały one wykryte podczas testowania) a popełnionych w czasie analizy wymagań, projektowania lub najczęściej implementacji ulepszające polegają na poprawie jakości oprogramowania, dostosowujące polegają na dostosowaniu oprogramowania do zmian zachodzących w wymaganiach użytkownika lub w środowisku pracy oprogramowania

25 Koszty konserwacji oprogramowania Występuje tendencja, aby zbyt nisko oceniać koszt konserwacji; okazuje się jednak, że koszty te mogą być bardzo duże, zwłaszcza w przypadku organizacji funkcjonujących w zmiennym środowisku

26 Obiektywne czynniki wpływające na koszty konserwacji Stabilność środowiska w którym pracuje system zmiany zachodzące w przepisach prawnych, zmiany struktury organizacyjnej i sposobów działania po stronie klienta prowadzi do zmian wymagań wobec systemu; Stabilność platformy sprzętowej i oprogramowania systemowego wymiana sprzętu może skutkować koniecznością dostosowania systemu; Czas użytkowania systemu całkowite koszty konserwacji oczywiście rosną, gdy system jest eksploatowany przez dłuższy czas.

27 Czynniki redukcji kosztów konserwacji Znajomość dziedziny problemu Jeżeli analitycy pracujący nad systemem dobrze znają dziedzinę problemu, mają mniej trudności z właściwym zebraniem wymagań oraz budową oddającą rzeczywistość modelu; możliwe jest również przewidzenie i uwzględnienie potencjalnych kierunków rozwoju. Wysoka jakość modelu i projektu Wysoka jakość dokumentacji technicznej Powinna w pełni odpowiadać systemowi, być szczegółowa i zgodna ze standardami przyjętymi w firmie. Stabilność personelu Najlepiej jakby ludzie tworzący system byli dostępnie, choćby w formie konsultantów. Środowisko implementacji Zaawansowane narzędzia skracają czas poprawek. Niezawodność oprogramowania Zmniejsza liczbę modyfikacji.