Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Testowanie oprogramowania Marcin Jerzak Piotr Fisz.

Podobne prezentacje


Prezentacja na temat: "Testowanie oprogramowania Marcin Jerzak Piotr Fisz."— Zapis prezentacji:

1 Testowanie oprogramowania Marcin Jerzak Piotr Fisz

2 Testowanie oprogramowania Jest to proces związany z wytwarzaniem oprogramowania. Celem testowania jest wykrywanie błędów oraz badanie niezawodności systemu. 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ą.

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

4 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.

5 Weryfikacja Weryfikacja ma na celu sprawdzenie spełnia założenia powstałe podczas startu danej fazy. 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ć: Przy weryfikacji możemy wykorzystać: Przeglądy, inspekcje, testowanie, sprawdzanie, audytowanie.

6 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.

7 Przegląd Przeglądy formalne mogą mieć postać: - przeglądu technicznego (ocena zgodności postępu prac względem planu). - przejść ( ). - audytu (potwierdzenie zgodności z założeniami, dokumentami itp. Przez osoby z zewnątrz firmy). 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).

8 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. 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. Dla zapewnienia lepszych wyników audyt powinien być wykonany przez osoby z zewnątrz.

9 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. 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%. Ś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. Jest to technika rzadko stosowana ponieważ wymagane są planowanie oraz kompetentni ludzie. Dodatkowym minusem jest utrudniona analiza kosztów i zysków.

10 Inspekcje Cechy inspekcji: - Sesje są zaplanowane i przygotowane - Błędy i problemy są notowane - wykonywane przez techników dla techników 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 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

11 Rodzaje testów Wykrywanie błędów – znajdowanie jak największej ilości błędó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 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 dynamiczne – wykonywanie kawałków programu i porównywanie wyników z poprawnymi Testy statyczne – analiza kodu Testy statyczne – analiza kodu

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

13 Fazy testowania Bezpieczeństwo oprogramowania 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

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

15 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. 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 Często jest wymagane przygotowanie danych testowych spełniających nasze wymagania Minusem jest brak możliwości pokazania brakujących funkcji Minusem jest brak możliwości pokazania brakujących funkcji

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

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

18 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 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 strukturalne – zakładają znajomość sposobu implementacji testowanych funkcji

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

20 Testy strukturalne Dane wejściowe dobiera się na podstawie analizy struktury programu realizującego daną funkcję. 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. 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.

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

22 Testy statyczne Testy statyczne polegają na analizie kodu bez jego uruchamiania. Testy statyczne polegają na analizie kodu bez jego uruchamiania. Dowody poprawności – praktycznie nie używane 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. 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.

23 Testy systemu Testowanie wstępujące – najpierw testujemy moduły niższego poziomu a potem wyższego. 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. Testowanie zstępujące – najpierw testujemy moduły wyższego poziomy a potem niższego.

24 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 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 odpornościowe pokazują jak zachowuje się system w przypadku np. zaniku prądu, wprowadzenie niepoprawnych danych itp.

25 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. 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. 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.

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

27 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ć. 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ć.

28 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 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 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 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 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 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 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 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 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.

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

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


Pobierz ppt "Testowanie oprogramowania Marcin Jerzak Piotr Fisz."

Podobne prezentacje


Reklamy Google