Diagram przepływu danych (DFD - Data Flow Diagrams)

● Poziomy modelu w diagramie hierarchicznym:

○ Diagram kontekstowy przedstawiony jako jeden proces (bez identyfikatora) z przepływami od/do zewnętrznych terminatorów.

○ Diagram “0” przedstawia ogólny główny opis systemu.

Diagram przejść przez stany (STD - State Transition DIagram)

● Opis w PDFie dr Unolda jest wystarczający...

● Bład na diagramie w PDFie polegał na tym, że jak jest jakiś błąd, anulowanie operacji czy coś, to nie zwraca karty, tylko od razu przechodzi do stanu wkładania nowej karty

Diagram związków encji (ERD - Entity Relationship Diagram)

● Konstruktory:

○ Encja - reprezentuje obiekty materialne i koncepcyjne, każda jest jednoznacznie nazwana; encje wzajemnie się wykluczają; encja silna zawiera atrybuty kluczowe, encja słaba nie ma własnych atrybutów kluczowych;

○ Atrybut - modeluje własności encji; mogą być wielowartościowe lub jednowartościowe; mogą być kluczowe (jednoznacznie identyfikują encję) i niekluczowe; obowiązkowe, opcjonalne, puste, niepuste;

○ Związek - relacja między zbiorami encji, o różnym stopniu (liczba wiązanych encji), typie asocjacji (one-to-one, many-to-many, one-to-many),

● Supertyp to taki obiekt, który ma pod sobą inne obiekty. Ich przynależność musi się wykluczać (tj. jeden supertyp może mieć powiązany tylko jeden z podległych obiektów).

Miary niezawodności oprogramowania:

● Prawdopodobieństwo wystąpienia błędnego wykonania podczas realizacji transakcji

Miara ta jest stosowana głównie w przypadku testowania systemów o charakterze transakcyjnym. Oznacza to, że operacje wykonywane w takim systemie mogą zakończyć się wyłącznie sukcesem bądź ich anulowaniem. Wyliczana jest na podstawie częstości występowania transakcji zakończonych niepowodzeniem z powodu błędu.

● Częstotliwość występowania błędnych wykonań

Miara ta dotyczy głównie systemów, które nie posiadają charakteru transakcyjnego. Określa ona przewidywaną liczbę błędnych wykonań w jednostce czasu.

● Średni czas między błędnymi wykonaniami

Jest to szacowany odstęp czasu miedzy wystąpieniem błędnych wykonań, czyli miara odwrotna dopoprzedniej.

● Dostępność systemu

Miara ta określa jakie jest prawdopodobieństwo, że system będzie w danej chwili dostępny dla użytkownika. Na miarę tą wpływają jedynie te błędne wykonania, które prowadzą do czasowej niedostępności systemu. Wartość tej miary zależy zarówno od liczby błędnych wykonań jak i od szybkości powrotu systemu do stanu normalnego.

Testy strukturalne

Testy strukturalne – znane są także jako testy białej lub szklanej skrzynki. Polegają na testowaniu programu poprzez podawanie na wejściu takich danych, aby program przeszedł przez każdą zaimplementowaną ścieżkę. Zasady te są definiowane przez kryteria pokrycia wszystkich pętli oraz wszystkich warunków. Testy białej skrzynki nie są w stanie wykazać braku implementacji funkcji, którą powinien posiadać system docelowy. Sprawdzają jednak dokładnie operacje wykonywane w zaimplementowanych metodach.

Nierzadko w trakcie testowania programu techniką szklanej skrzynki wprowadzane są do wnętrza programu sztucznie specjalnie spreparowane dane w celu dokładniejszego przetestowania reakcji. Ten sposób nazywamy metodą „Słonia w Kairze”.

Testy funkcjonalne

Testy funkcjonalne znane są także jako testy czarnej skrzynki, ponieważ osoba testująca nie ma dostępu do informacji na temat budowy programu, który testuje. Często testy takie są wykonywane przez inne osoby niż programiści tworzący program. Nierzadko są to osoby nie posiadające wiedzy z zakresu programowania. Osoba testująca program nie opiera danych testowych na budowie wewnętrznej programu, lecz na założeniach funkcjonalnych, jakie powinien spełniać program zgodnie z dokumentacją.

W przypadku braku implementacji funkcji wymaganych przez założenia, testy funkcjonalne wykryją błąd. Zakres badanych wartości jest zwykle inny niż w przypadku testów strukturalnych.

Testy czarnej skrzynki posiadają większą szansę wykrycia błędnych wykonań, ale jednocześnie nie dostarczają zazwyczaj precyzyjnej informacji na temat przyczyny wystąpienia błędu w programie. Ze względu na szeroki zakres do przetestowania w zaawansowanych systemach informacyjnych często określa się dane testowe na podstawie względnego podobieństwa danych (klas podobnych). Dzięki temu możliwe jest przetestowanie większego zakresu danych przy jednoczesnym zmniejszeniu liczby testów o bardzo podobnych przejściach przez program.

Testy statystyczne

Testy statystyczne mają na celu zebrać przyczyny najczęstszych błędów wykonań i sprawdzić (zmierzyć) niezawodność systemu. Schemat wykonania obejmuje, na wstępie, losowanie zestawu danych zgodnych z rozkładem prawdopodobieństwa tych danych, określenie wyników oczekiwanych jako poprawne oraz uruchomienie systemu i porównanie wyników. Tego typu testy możemy uruchamiać, by testować typowe sytuacje. Możemy je też zautomatyzować.

Testy statyczne

Testy statyczne są formą testowania oprogramowania bez uruchamiania programu podczas testów. Test polega na automatycznym i ręcznym sprawdzaniu kodu w celu znalezienia błędów. Najczęściej wykonywany jest przez twórców kodu jako pierwsze i podstawowe sprawdzenie każdego programu. Testowanie statyczne sprawdza podstawową poprawność kodu i pozwala ocenić, czy program jest gotowy na bardziej szczegółowe testowanie.

W testowaniu statycznym można wyróżnić podstawową analizę kodu i precyzyjne wyszukiwanie typowych błędów.

Testy dynamiczne

Testy dynamiczne polegają na testowaniu działania całości lub części programu poprzez uruchamianie i porównywanie danych wyjściowych z oczekiwanymi. Testy dynamiczne są najczęściej wykonywane po pozytywnym przejściu kodu przez testy statyczne.