Podstawy Inżynierii Oprogramowania WYKŁAD 8 Modele cyklu życia oprogramowania MODEL KASKADOWY Faza Dokumentacji i Faza testowania Dr hab. inż. Barbara Dębska, prof. PWSZ Dr hab. inż. Barbara Dębska, prof. PWSZ

FAZA DOKUMENTACJI Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Analiza Faza strategiczna Instalacja Dokumentacja Dokumentacja Dr hab. inż. Barbara Dębska, prof. PWSZ

Rodzaje dokumentacji: - dokumentacja dla użytkowników końcowych, lub - dokumentacja dla administratora systemu. Składowe dokumentacji użytkowej: Opis funkcjonalny. To wstępna część dokumentacji, która w zwarty sposób opisuje przeznaczenie i główne funkcje systemu. Opis funkcjonalny powinien dostarczać wszystkich niezbędnych informacji osobie rozważającej zakup systemu, np. udzielić odpowiedzi na pytanie, czy system spełni oczekiwania i potrzeby Dr hab. inż. Barbara Dębska, prof. PWSZ

Składowe dokumentacji użytkowej: (c.d.) Podręcznik użytkownika. Jest to opis systemu przeznaczony dla początkujących użytkowników, który powinien zawierać informacje o: sposobach uruchamiania oraz kończenia pracy z systemem, sposobach realizacji najczęściej wykorzystywanych funkcji systemu, metodach obsługi błędów, np. o sposobach odwoływania błędnych operacji wykonanych przez użytkownika, oraz sposobach korzystania z systemu pomocy (help’u). Dr hab. inż. Barbara Dębska, prof. PWSZ

Składowe dokumentacji użytkowej: (c.d.) Kompletny opis. To opis systemu przeznaczony dla doświadczonych użytkowników, który powinien zawierać: szczegółowy opis wszystkich funkcji systemu, informacje o wszystkich sposobach wywoływania tych funkcji, opis formatów danych, opis błędów, które mogą wystąpić podczas pracy z systemem, oraz informacje o wszystkich ograniczeniach, które dotyczą np. zakresów danych. Dr hab. inż. Barbara Dębska, prof. PWSZ

Składowe dokumentacji użytkowej: (c.d.) - Opis instalacji. Jest to część dokumentacji przeznaczona głównie dla administratora systemu. Zawiera ona opis procedury instalacyjnej oraz dostrojenia środowiska, w którym system będzie pracować. Podręcznik administratora systemu. To część dokumentacji przeznaczona dla administratora systemu, która opisuje możliwości zmian konfiguracji systemu i sposoby udostępniania systemu użytkownikom końcowym. Ponadto, dokumentacja użytkowa może zawierać: - Słownik używanych terminów i indeks (opcjonalnie) oraz - Opis help’ów dostępnych w formie elektronicznej (opcjonalnie) Dr hab. inż. Barbara Dębska, prof. PWSZ

Na jakość dokumentacji wpływają następujące czynniki: 1. struktura (podręcznik powinien być w czytelny i zrozumiały sposób podzielony na rozdziały, podrozdziały i sekcje), 2. zachowanie standardów (spójna struktura, forma i sposób pisania zarówno całego podręcznika jak i jego fragmentów), 3. sposób pisania, w tym: - stosowanie formy aktywnej oraz zwracanie się bezpośrednio do czytelnika, np. nie pisać Na ekranie pojawi się dialog ... Aby otworzyć plik należy wybrać z menu ... lecz wyświetlić komunikat w postaci Na ekranie zobaczysz dialog ... Jeżeli chcesz otworzyć plik, wybierz z menu ... Dr hab. inż. Barbara Dębska, prof. PWSZ

Czynniki wpływające na jakość dokumentacji (c.d.) - poprawność gramatyczna i ortograficzna, - krótkie zdania, - krótkie akapity, - oszczędność słów, - precyzyjna definicja używanych terminów, - powtarzanie trudnego opisu, - stosowanie tytułów i podtytułów sekcji, wyliczeń i wyróżnień, oraz zrozumiałe odwołania do innych rozdziałów, np. nie pisać W rozdziale 5.1. znajduje się ... , lecz wyświetlić komentarz W rozdziale 5.1 omawiającym zagadnienia ... znajduje się .... Wynikiem fazy dokumentowania jest dokumentacja użytkowa w formie drukowanej i elektronicznej. Dr hab. inż. Barbara Dębska, prof. PWSZ

FAZA TESTOWANIA Określenie wymagań Projektowanie Implementacja Testowanie Testowanie Konserwacja Analiza Faza strategiczna Instalacja Dokumentacja Dr hab. inż. Barbara Dębska, prof. PWSZ

Testowaniem programów zajmują się testerzy. testowanie programu ma kluczowe znaczenie dla powstającej aplikacji, wielkość i złożoność współczesnych programów wymaga, aby testować profesjonalnie i skutecznie, albowiem ryzyko wyprodukowania błędnie działającej aplikacji jest zbyt wielkie. Testowaniem programów zajmują się testerzy. Cechy dobrego testera: są oni dobrze wykształceni w dziedzinie programowania, znajomość metod programowania czyni ich skuteczniejszymi i wydajniejszymi, lubią próbować psuć dobre rzeczy, lubią znajdować trudno uchwytne awarie systemów, znajdują wielką satysfakcję z psucia najbardziej nawet złożonych programów, składają sobie gratulacje i cieszą się, gdy uda im się złamać system. Dr hab. inż. Barbara Dębska, prof. PWSZ

Tester musi być: 1. odkrywcą. Testerzy nie mogą się obawiać nieznanych sytuacji. Uwielbiają dostać nowy program, zainstalować go na swoim komputerze i zobaczyć, co też się stanie. 2. łowcą problemów. Testerzy musza się szybko domyślać, dlaczego coś nie działa. Uwielbiają łamigłówki. 3. nieustępliwym. Testerzy próbują raz za razem. Zdarza się, że dostrzegają awarię, która potem szybko znika lub trudno ją wywołać ponownie. Nie zlekceważą jej i będą próbować wszelkich sposobów, aby ją odtworzyć. 4. twórczym. Testowanie tego co oczywiste nie wystarcza. Praca testera polega na wymyślaniu twórczych i nawet ”zwariowanych” sposobów szukania błędów. Dr hab. inż. Barbara Dębska, prof. PWSZ

Tester musi być (cd.) : 5. profesjonalistą. Dążyć do doskonałości, ale wiedzieć, kiedy nie da się jej osiągnąć, i umieć poprzestać na zbliżaniu się do doskonałości. 6. osobą cechującą się rozsądkiem i umiejętnością podejmowania decyzji. Specjaliści od testowania muszą sami podejmować decyzje, co będą testować, jak długo i czy przyczyną zaobserwowanej awarii rzeczywiście jest błąd programowania. 7. taktownym i dyplomatycznym. Testerzy zawsze przynoszą złe wiadomości. Muszą umieć taktownie i profesjonalnie przedstawić programistom uwagi o znalezionych błędach w testowanej aplikacji. 8. przekonywujący. Programiści nie zawsze traktują z należytą powagą błędy znalezione przez testerów . Testerzy muszą umieć jasno wytłumaczyć swój punkt widzenia, zademonstrować, dlaczego dany błąd rzeczywiście musi być naprawiony, i dopilnować, żeby został usunięty. Dr hab. inż. Barbara Dębska, prof. PWSZ

Mówiąc o testowaniu należy rozróżnić: atestowanie (ang. validation), czyli testowanie zgodności systemu z rzeczywistymi potrzebami użytkownika, weryfikację (ang. verification), czyli testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie wymagań. Cele testowania: wykrycie i usunięcie błędów w systemie, ocena niezawodności systemu. Błąd – niepoprawna konstrukcja znajdująca się w programie mogąca prowadzić do niewłaściwego działania. Błędne wykonanie – niepoprawne działanie systemu w trakcie jego pracy. 1. Błąd może prowadzić do wielu różnych błędnych wykonań. 2. W wielu sytuacjach może jednak nie objawiać się błędnym wykonaniem. 3. Takie same błędne wykonania mogą być spowodowane różnymi błędami. Dr hab. inż. Barbara Dębska, prof. PWSZ

Podział testów z punktu widzenia głównego celu: wykrywanie błędów, czyli testy, których głównym celem jest wykrycie jak największej liczby błędów w programie, testy statystyczne, czyli testy, których głównym celem jest wykrycie przyczyn najczęstszych błędnych wykonań oraz ocena niezawodności systemu. Podział testów z punktu widzenia podstawowej techniki wykonywania testów: testy dynamiczne, które polegają na wykonywaniu (fragmentu) programu i porównywaniu uzyskanych wyników z wynikami poprawnymi (wykrywają wyłącznie błędne wykonania), testy statyczne, czyli testy oparte na analizie kodu ( pozwalają ustalić przyczynę błędu). Dr hab. inż. Barbara Dębska, prof. PWSZ

Źródła błędów Inne Kod Specyfikacja Projekt Główną przyczyną powstawania błędu jest niekompletna specyfikacja wymagań. Dr hab. inż. Barbara Dębska, prof. PWSZ

Fazy testowania systemu: Faza modułów. Są one wykrywane już w fazie implementacji bezpośrednio po zakończeniu realizacji poszczególnych modułów. Faza systemu. W fazie tej integrowane są poszczególne moduły i testowane są podsystemy oraz system jako całość. Faza akceptacji. 1)Testy alfa. W przypadku oprogramowania realizowanego na zamówienie system przekazywany jest do przetestowania przyszłemu użytkownikowi. 2) Testy beta. W przypadku oprogramowania sprzedawanego rynkowo testy takie polegają na nieodpłatnym przekazaniu pewnej liczby kopii systemu grupie użytkowników. Dr hab. inż. Barbara Dębska, prof. PWSZ

Testy statystyczne przebiegają według cyklicznego algorytmu: 1. losowa konstrukcja danych wejściowych zgodnie z rozkładem prawdopodobieństwa tych danych, 2. określenie wyników poprawnego działania systemu na tych danych, 3. uruchomienie systemu oraz porównanie wyników jego działania z poprawnymi wynikami. Założeniem testów statystycznych jest położenie nacisku na przetestowanie działania systemu w typowych sytuacjach. Uwaga: Należy zwiększyć częstotliwość testowania tych sytuacji, jeśli zachowanie systemu w pewnych sytuacjach jest szczególnie ważne. ”Brutalna siła testów statystycznych” – proces testowania statystycznego można zautomatyzować i dzięki temu można wykonać bardzo dużą liczbę przebiegów testowych w krótkim czasie. Dr hab. inż. Barbara Dębska, prof. PWSZ

Właściwości testów statystycznych: wymagają określenia rozkładu prawdopodobieństwa danych wejściowych (gdy dokładne określenie tego rozkładu jest bardzo trudne stosuje się rozkłady danych wejściowych możliwie bliskie rzeczywistemu rozkładowi), jeśli rozkład prawdopodobieństwa generowanych danych wejściowych mocno odbiega od rozkładu danych rzeczywistych, to wnioski dotyczące niezawodności oprogramowania wyciągnięte na podstawie analizy wyników testów statystycznych mogą okazać się błędne, założeniem testów statystycznych jest przetestowanie działania systemu w typowych sytuacjach (dane typowe generowane są częściej niż nietypowe), główną zaletą testów statystycznych jest łatwość ich automatyzacji (jeśli jest znany rozkład danych wejściowych oraz sposób określania pożądanego działania systemu). Dr hab. inż. Barbara Dębska, prof. PWSZ

Miary niezawodności oprogramowania: Prawdopodobieństwo błędnego wykonania podczas realizacji transakcji. W przypadku pewnych systemów wykonywane operacje mają charakter transakcji, które powinny zakończyć się pełnym sukcesem lub zostać zaniechane. Każde błędne wykonanie należy uznać za niepowodzenie całej transakcji. Miarę tę można oszacować na podstawie częstości występowania transakcji, które nie powiodły się z powodu jednego lub kilku błędów. Częstotliwość występowania błędnych wykonań. Miara ta określa spodziewaną liczbę błędnych wykonań w jednostce czasu, np. 0.1/h. Szacując tą miarę na podstawie testów należy wziąć pod uwagę fakt, że zazwyczaj ma miejsce różna intensywność użytkowania systemu w czasie testowania i podczas praktycznego użytkowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

Miary niezawodności oprogramowania: (c.d.) Średni czas miedzy błędnymi wykonaniami. Miara jest odwrotnością poprzedniej. Dostępność. Miara ta opisuje prawdopodobieństwo, że w danej chwili system będzie dostępny do użytkowania. Miarę tę można oszacować na podstawie stosunku czasu w którym system jest dostępny na podstawie testów. Na miarę tę wpływają wyłącznie te błędne wykonania, które prowadzą do czasowej niedostępności systemu. Wielkość tej miary zależy nie tylko od liczby błędnych wykonań, lecz także od szybkości powrotu do stanu normalnego po zajściu błędnego wykonania. Dr hab. inż. Barbara Dębska, prof. PWSZ

Niezawodność = Niezawodność początkowa * exp(-C * liczba testów) Testy statystyczne pozwalają sprawdzić, czy został osiągnięty wymagany przez klienta poziom niezawodności. Cykliczny algorytm szacowania niezawodności oprogramowania podczas testowania statystycznego: 1. wykryty został błąd w oprogramowaniu, 2. ustala się przyczynę występowania błędu, 3. błąd zostaje usunięty, 4. oblicza się niezawodność oprogramowania wg. logarytmicznego modelu wzrostu niezawodności oprogramowania: Niezawodność = Niezawodność początkowa * exp(-C * liczba testów) (Uwaga: stała C zależy od konkretnego systemu. Wyznacza się ją na podstawie obserwacji niezawodności systemu w trakcie procesu testowania, metodą regresji nieliniowej – np. stosując metodę najmniejszych kwadratów). 5. sprawdza się, czy osiągnięty został założony poziom niezawodności, 6. jeśli nie, kroki 1-5 powtarza się cyklicznie aż do osiągnięcia zadowalającego poziomu niezawodności. Dr hab. inż. Barbara Dębska, prof. PWSZ

Rys. Logarytmiczny model poziomu niezawodności aplikacji. Częstotliwość występowania błędnych wykonań [1/h] Obserwowana niezawodność Przewidywana niezawodność Pożądana niezawodność Liczba testów Rys. Logarytmiczny model poziomu niezawodności aplikacji. Dr hab. inż. Barbara Dębska, prof. PWSZ

Testerzy mogą być zmuszeni do ograniczenia liczby testów z powodów ekonomicznych. Koszt testowania Liczba opuszczonych testów Ilość Optymalna liczba testów Niedomiar testów Nadmiar testów Liczba testów Rys. Związek pomiędzy liczbą wykonanych testów a liczbą odkrytych błędów. Dr hab. inż. Barbara Dębska, prof. PWSZ

Podział testów dynamicznych zorientowanych na wykrywanie błędów: Testy funkcjonalne. Zakładają znajomość jedynie wymagań wobec testowanych funkcji. System traktowany jest jako czarna skrzynka, która w niezawodny sposób realizuje wymagane funkcje. Testy tego typu muszą być wykonywane przez osoby, które nie były zaangażowane w realizację testowanych fragmentów systemu. Zakładają one, że zbiór danych wejściowych można podzielić na klasy i jeśli działanie systemu jest poprawne dla kilku danych należących do danej klasy, to jest poprawne dla całej klasy. Podział danych wejściowych na klasy odbywa się na podstawie opisu wymagań. Przykład. Wyliczony programem Pity_2003 podatek pobrany od podatnika może być większy od odpisów, których może on dokonać. Sugeruje to, podział danych wejściowych na trzy klasy. Testując odpowiednią funkcję systemu należy wprowadzić dane dla których: zapłacony podatek jest (<, = , lub >) niż możliwy odpis. Dr hab. inż. Barbara Dębska, prof. PWSZ

Ogólne warunki wyboru funkcji i danych do testowania: W praktyce przetestowanie wszystkich kombinacji danych wejściowych jest niemożliwe. Dlatego niezbędny staje się wybór testowanych funkcji i zbiorów danych wejściowych. Ogólne warunki wyboru funkcji i danych do testowania: Możliwość wykonania funkcji jest ważniejsza niż jakość jej wykonania. Brak możliwości wykonania pewnej funkcji jest poważniejszym błędem niż np. niepoprawne odświeżanie ekranu podczas jej realizacji. Funkcje systemu znajdujące się w poprzedniej wersji są istotniejsze niż nowo wprowadzone. Użytkownicy, którzy korzystali z poprzedniej wersji systemu będą szczególnie niezadowoleni, jeżeli posługując się nową wersją nie będą mogli wykorzystać operacji, które wykonywali poprzednio. Typowe sytuacje są ważniejsze niż wyjątki. Błąd w funkcji wykonywanej przez typowego użytkownika co kilka minut jest ważniejszy niż błąd w funkcji wykonywanej raz w miesiącu. Dr hab. inż. Barbara Dębska, prof. PWSZ

Podział testów dynamicznych zorientowanych na wykrywanie błędów (cd.): Testy strukturalne. Zakładają znajomość sposobu implementacji testowanych funkcji. W przypadku tych testów dane wejściowe dobiera się na podstawie analizy struktury programu realizującego testowane funkcje, stosując różne kryteria doboru danych testowych: 1. Kryterium pokrycia wszystkich instrukcji – każda instrukcja ma być wykonana co najmniej raz. Przykład. Spełniając powyższe kryterium łatwo pominąć pewne błędy: if x >0 then begin . . . end; y:= ln (x); Wprowadzenie wartości zmiennej większej od zera zapewnia wykonanie wszystkich instrukcji. Nie zapewnia jednak wykrycia błędu arytmetycznego, który pojawia się, gdy zmienna jest x ≤ 0. Dr hab. inż. Barbara Dębska, prof. PWSZ

Podział testów dynamicznych zorientowanych na wykrywanie błędów (cd.): Testy strukturalne. 2. Kryterium pokrycia instrukcji warunkowych – każdy elementarny schemat instrukcji warunkowej ma być co najmniej raz spełniony i co najmniej raz niespełniony. Test należy wykonać także dla wartości granicznej każdego warunku. Jeżeli tester popełni błąd polegający na nie uwzględnieniu istnienia pewnej klasy danych wejściowych, to błąd taki ma niewielkie szanse wykrycia. Przykład. Jakie testy przygotować dla programu liczącego rzeczywiste pierwiastki równania kwadratowego? a x 2 + b x +c = 0 a=? b=? c=? Dr hab. inż. Barbara Dębska, prof. PWSZ

Podział testów dynamicznych zorientowanych na wykrywanie błędów (cd.): Testy strukturalne. 3. Testowanie programów zawierających pętle – należy tak dobrać dane wejściowe aby: (1) została wykonana przeciętną ilość iteracji, (2) została wykonana maksymalna ilość iteracji, (3) nie została wykonana żadna iteracja pętli lub, jeżeli nie jest to możliwe została wykonana minimalna ilość iteracji. Przykład. Jakie testy przygotować dla programu w którym występują pętle wielokrotne? Dr hab. inż. Barbara Dębska, prof. PWSZ

Stosowane techniki testowania statycznego: Testy statyczne – polegają na analizie kodu bez uruchamiania programu przez śledzenie przebiegu programu lub wyszukiwanie typowych błędów. Stosowane techniki testowania statycznego: 1. metody nieformalne. Polegają na analizie kodu przez programistów. Stosowane podejścia: - śledzenie przebiegu programu (program jest uruchamiany ”w umyśle” testera) oraz - wyszukiwanie typowych błędów (wyszukiwanie błędów polega na przeglądaniu kodu bez śledzenia jego działania, przy czym zwraca się uwagę na błędy, które zazwyczaj popełniają programiści) Dr hab. inż. Barbara Dębska, prof. PWSZ

Testy statyczne Lista typowych błędów: niezainicjowane zmienne, porównania liczb zmiennoprzecinkowych, indeksy wykraczające poza tablice, błędne operacje na wskaźnikach, błędy w warunkach instrukcji warunkowych, niekończące się pętle, błędy popełnione dla granicznych wartości ( np. >= zamiast >), błędne użycie lub pominięcie nawiasów w złożonych wyrażeniach, nieuwzględnienie błędnych danych. Dr hab. inż. Barbara Dębska, prof. PWSZ

Jedna z możliwych strategii stosowania testów nieformalnych: Testy statyczne nieformalne mogą być wykonywane zarówno przez pojedyncze osoby, jak i przez grupy testerów podczas specjalnych spotkań. Jedna z możliwych strategii stosowania testów nieformalnych: Programista, który dokonał implementacji danego modułu w nieformalny sposób analizuje jego kod. Kod uznany przez autora implementacji za nie zawierający zbyt wielu błędów jest analizowany przez doświadczonego programistę, np. szefa zespołu programistów. Jeżeli już na wstępie okaże się, że moduł zawiera wiele błędów jest on zwracany do przejrzenia autorowi. Szczególnie istotne moduły są analizowane przez grupę osób. Wnioski: - Techniki nieformalne są bardzo efektywne w praktyce. - Testy funkcjonalne są efektywniejsze niż strukturalne. Praktyczne eksperymenty porównawcze różnych technik wykrywania błędów (Fagan 1986) wskazują, że to właśnie techniki nieformalne pozwalają wykryć największą ilość błędów w najkrótszym czasie. Dr hab. inż. Barbara Dębska, prof. PWSZ

Stosowane techniki testowania statycznego (cd.): Testy statyczne Stosowane techniki testowania statycznego (cd.): 2. dowody poprawności. Stosowanie formalnych dowodów poprawności jest techniką sugerowaną już od wielu lat (Dijkstra 1976, McGettrick 1982). Jest to technika bardzo złożona. Ocenia się, że udowodnienie poprawności fragmentu programu jest o rząd trudniejsze i bardziej czasochłonne niż jego opracowanie. Dowody poprawności są związane nie tylko z dużymi kosztami, ale istnieje ryzyko popełnienia błędu na etapie tworzenia dowodu. Obecnie technika ta jest rzadko stosowana w praktyce (Sommerville 1995). Dr hab. inż. Barbara Dębska, prof. PWSZ

Przykład. Algorytm Euklidesa znajdowania największego wspólnego dzielnika dwóch dodatnich liczb naturalnych x , y przyjmuje postać funkcji: function NWD (x, y : integer) : integer; var r : integer; begin {: x>0  y>0  y>x} r := x mod y; if r = 0 then NWD := y else NWD := NWD (y, r) { : NWD = (x, y)} end; Dowód poprawności semantycznej algorytmu: Przez (x, y) oznaczamy największy wspólny dzielnik dodatnich liczb naturalnych x, y . Chcemy dowieść, że dla każdych x, y obliczenie wykonane wg. funkcji NWD(x, y) kończy się wartością NWD = (x, y). Stosujemy indukcję względem wartości y. Zakładając poprawność dla wszystkich 0<y1<y, otrzymujemy, że x mod y =0 i wtedy (x, y) =y. Poprawność działania funkcji wynika też z założenia indukcyjnego dla pary y, x mod y i wewnętrznego wywołania rekurencyjnego. Wtedy otrzymujemy również (x, y) = (y, mod y). Dr hab. inż. Barbara Dębska, prof. PWSZ

Ocena liczby błędów Liczba błędów w programie nie musi mieć jednoznacznego związku z niezawod- nością oprogramowania. Oszacowanie liczby błędów może mieć duże znaczenie dla producenta oprogramowania, albowiem może mieć bezpośredni wpływ na koszty konserwacji oprogramowania. Znając: szacunkową liczbę błędów w programie, średni procent błędów zgłaszanych przez użytkowników systemu, oszacowany na podstawie danych z poprzednich przedsięwzięć, oraz średni koszt usunięcia błędu, także pochodzący z analizy danych poprzednich przedsięwzięć, można oszacować koszt konserwacji systemu związany z usuwaniem błędów. Jest to szczególnie ważne dla firm sprzedających oprogramowanie pojedynczym lub nielicznym użytkownikom. W tym wypadku koszt związany z pojawieniem się informacji o błędnych wykonaniach jest niewielki w porównaniu z kosztami usuwania błędów. Dr hab. inż. Barbara Dębska, prof. PWSZ

Szacowanie liczby błędów techniką posiewania błędów Polega na wprowadzeniu do programu pewnej liczby błędów podobnych do błędów, które występują w programie. Następnie wykonywana jest pewna liczba testów przeprowadzanych przez testerów, którzy nie brali udziału w posiewaniu błędów. Na podstawie liczby wszystkich znalezionych błędów oraz liczby znalezionych błędów sztucznie wprowadzonych, można oszacować liczbę błędów w programie. Jeśli: N – oznacza liczbę wprowadzonych błędów, M – to liczba wszystkich wykrytych błędów, i X – jest równe liczbie tych wprowadzonych błędów, które zostały wykryte, to szacunkowa liczba błędów przed wykonaniem testów wynosiła: (M – X) * N / X, a liczba błędów po usunięciu wykrytych jest następująca: (M - X) * (N / X – 1) (zakłada się, że wprowadzone błędy były podobne do błędów już znajdujących się w programie i że sztucznie wprowadzone błędy zostały usunięte) Dr hab. inż. Barbara Dębska, prof. PWSZ

Testy systemu wykonuje się techniką wstępującą lub zstępującą. Wstępująco – testuje się najpierw pojedyncze moduły, potem moduły coraz wyższego rzędu, aż do osiągnięcia poziomu całego systemu. Zstępująco – testowanie rozpoczyna się od testowania modułów wyższego poziomu. Ich testowanie wymaga konstrukcji szkieletów modułów niższego poziomu. Po przetestowaniu modułu wyższego poziomu dołączane są moduły poziomu niższego i rozpoczyna się test tej grupy modułów. Proces ten kontynuuje się aż do zintegrowania i przetestowania całego systemu. Dr hab. inż. Barbara Dębska, prof. PWSZ

BEZPIECZEŃSTWO OPROGRAMOWANIA Bezpieczny system nie musi być niezawodny. Niezawodność i bezpieczeństwo wynikają z różnych czynników: system zawodny może być bezpieczny, jeśli skutki błędnych wykonań nigdy nie są groźne, wymagania wobec systemu mogą być niepełne i mogą nie opisywać zachowania się systemu we wszystkich sytuacjach. Dotyczy to zwłaszcza sytuacji wyjątkowych, np. wprowadzenie złych danych. niebezpieczeństwo może wynikach z awarii sprzętowych. Analiza bezpieczeństwa rozpoczyna się od określenia potencjalnych niebezpieczeństw związanych z użytkowaniem systemu. Dr hab. inż. Barbara Dębska, prof. PWSZ

Niebezpieczeństwo, to sytuacja w której zachodzi: ryzyko utraty życia, ryzyko utraty zdrowia, duża strata materialna, czy złamanie przepisów prawa. Podstawową techniką zwiększania bezpieczeństwa jest analiza drzew błędu. Korzeniem takiego drzewa jest niebezpieczna sytuacja, a węzłami pośrednimi i liśćmi są sytuacje, które mogą prowadzić do zaistnienia sytuacji odpowiadającej wierzchołkowi wyższego rzędu. Przykład Pity_2003. Niebezpieczeństwa związane z użytkowaniem tego systemu: błędne rozliczenie podatnika z urzędem płatniczym, nie złożenie zeznania podatkowego, lub złożenie wielu zeznań dla jednego płatnika, być może w różnych urzędach. Dr hab. inż. Barbara Dębska, prof. PWSZ

Fragment drzewa błędu systemu podatkowego Pity_2003: Błędne rozliczenie podatnika Wprowadzenie błędnych danych Błąd obliczeniowy Błędny wydruk rozliczenia Błędnie obliczona podstawa opodatkowania Błędnie obliczony podatek Błędnie obliczona nadpłata/ dopłata Błędnie zsumowane dochody Błędnie zsumowane ulgi lub Dr hab. inż. Barbara Dębska, prof. PWSZ

Podstawowe rezultaty fazy testowania: poprawiony kod, projekt, model i specyfikacja wymagań, raport przebiegu testów, zawierający informacje o wykonanych testach i ich rezultatach, oraz oszacowanie niezawodności oprogramowania i kosztów konserwacji. W przypadku wykrycia błędów, których usunięcie wymaga poprawy projektu, modelu lub specyfikacji wymagań, wykorzystywane mogą być oczywiście wszystkie możliwości narzędzi projektowych CASE, stosowanych w poprzednich fazach tworzenia aplikacji. Dr hab. inż. Barbara Dębska, prof. PWSZ

Dziękuję za uwagę Dr hab. inż. Barbara Dębska, prof. PWSZ