plik

Dokumentacja testów systemu informatycznego

Spis treści

1. Wstęp

2. Badania prognostyczne
3. Weryfikacja i walidacja
4. Klasyfikacja błędów i rodzaje testów

4.1. Co podlega testowaniu;
4.2. Przypadki testowe i scenariusze;
4.3. Drzewo błędów;
4.4. Strategia białej i czarnej skrzynki;
4.5. Zespół oceniający i testy akceptacyjne;

5. Audyt
6. Wykorzystywane narzędzia
7. Podsumowanie

7.1. Przyszłe wersje

Status dokumentu

Zespół wytwórczy 9/2010/GB w składzie

Kierownik projektu / Zamawiający

Paulina Turlewicz

Zamawiający / Tester akceptacyjny

Piotr Szela

Analityk / Projektant

Piotr Surma

Analityk / Tester wewnętrzny

Maciej Zarzycki

Projektant / Tester wewnętrzny

Karol Pawłowski

Zmiany w stosunku do wersji poprzedniej

Wersja pierwsza.

Dokumentacja testów systemu informatycznego

1. Wstęp

Niniejszy dokument stanowi wprowadzenie do fazy testów systemu informatycznego dla biura

podróży  „Husajn”.  Definiuje  zarówno  testy  prognostyczne  realizowane  przez  kolejne  kroki  procesu
tworzenia  oprogramowania,  jak  i  testy  przeprowadzane  w  koocowej  fazie  implementacji.  Proces
wytwórczy  przebiega  w  modelu  V,  stąd  każdy  etap  posiada  własne  poziomy  testowania  i  system
oceniania.

Celem fazy testów jest znalezienie jak największej liczby błędów w systemie. Im bowiem

wyszukane będzie ich więcej, tym mniej pozostanie nie znalezionych. Niemniej jednak nie wolno
polegad na fakcie, że system będzie całkowicie pozbawiony błędów. Jest to podejście irracjonalne i
mogące stwarzad poważniejsze konsekwencje niż sam fakt istnienia błędu.

2. Badania prognostyczne

Już na etapie analizy i projektu, a nawet definiowania wymagao należy upewniad się o jakości

założeo i wywodów. Badania prognostyczne polegają na badaniu systemu bez wgłębiania się w kod
(którego może de facto jeszcze nie byd). Badania tego typu są stosunkowo tanie do przeprowadzenia
w porównaniu z testowaniem w późniejszych fazach. Testy te zwiększają prawdopodobieostwo
uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji błędów. Im bowiem usterka wykryta
zostanie wcześniej, tym łatwiej ją wyeliminowad i będzie odgrywad mniejszy wpływ na inne elementy
systemu.

Mimo wszystko do testów na tym etapie należy podchodzid z lekką rezerwą, gdyż polegają one na

badaniach modelu, co może zmniejszyd dokładnośd (potencjalna rozbieżnośd z właściwościami
implementacyjnymi), a nawet byd nie do kooca zgodne z modułami ostatecznie
zaimplementowanymi.

W projektowanym systemie badaniom prognostycznym podlegad będzie przede wszystkim

uwzględnienie  wszystkich  wymagao  funkcjonalnych  i  niefunkcjonalnych  (oraz  ich  zgodnośd  ze
specyfikacją)  w  fazie  analizy  i  projektu  oraz  stopniowe  ich  implementowanie.  Testy  polegają  na
eksperymentowaniu  z  kodem  pisanym  na  bieżąco,  rozpoznaniu  funkcjonalności  testowanego  kodu
oraz  zaprojektowaniu  koocowych  testów.  Sprawdzamy  także,  czy  nie  ma konfliktów  w  specyfikacji,
które uniemożliwiają zaimplementowanie funkcjonalności w sposób zgodny z wymaganiami.

Należy przebadad zarówno własności statyczne, jak i dynamiczne. Należy zwrócid uwagę na

wymianę informacji pomiędzy funkcjami, między którymi zaprojektowano przepływ informacji.
Trzeba sprawdzid też, czy nadmiarowe informacje nie są widoczne dla świata zewnętrznego.

Dokumentacja testów systemu informatycznego

3. Weryfikacja i walidacja

Weryfikując wykonujemy całośd przeglądów, inspekcji, sprawdzania i audytowania. Ustalamy i

dokumentujemy w  ten sposób  czy składowe, usługi i dokumenty zgadzają się z wyspecyfikowanymi
wymaganiami.  Musimy  określid,  czy  system  w  swoich  kolejnych  fazach  rozwoju  spełnia  warunki
zakładane podczas startu tej fazy, a przede wszystkim zakładane w fazie specyfikacji. Kolejne dalsze
punkty  wyszczególniają  poszczególne  potencjalne  błędy  i  testy.  W  skład  weryfikacji  wchodzą  także
badania prognostyczne.

Walidacją będziemy się zajmowad pod koniec procesu wytwórczego. W nim także ostatecznie

sprawdzimy zgodnośd z wymaganiami. Wynikiem tego procesu będzie atest systemu.

Ponieważ poszczególne elementy systemu informatycznego zaprojektowanego dla firmy „Husajn

Travel” są bardzo zróżnicowane, założenia, głównie funkcjonalne, muszą byd weryfikowane
oddzielnie, przez odpowiednią częśd zespołu oceniającego. Wszystkie wymagania (funkcjonalne,
niefunkcjonalne, dziedzinowe) zostały przedstawione w dokumentacji specyfikacji.

4. Klasyfikacja błędów i rodzaje testów

4.1. Co podlega testowaniu

a) Testowanie bazy danych

Tworzona baza danych zostanie przetestowana pod względem bezpieczeostwa oraz dbałości o

niski  poziom  redundancji  (nadmiarowości)  przechowywanych  danych.  Dostęp  do  wglądu  w  bazę
danych powinien mied tylko pracownik działu IT, który ma również możliwośd łatwej edycji zawartych
w  niej  rekordów.  W  celu  zabezpieczenia  przed  nieumyślnym  skasowaniem  danych  sprawdzamy
funkcjonalnośd  i  działanie  modułu  umożliwiającego  tworzenie  kopii  zapasowych.  Moduł  ten  ma
wbudowaną  funkcję  autowywoływania  przed  każdą  próbą  edycji  danych.  Kopię  można  ustawid  na
wykonywanie backupu całościowego lub przyrostowego. Naszym zadaniem jest zbadanie wszystkich
możliwości  obejśd  tego  modułu  oraz  miejsc  w  poszczególnych  aplikacjach,  które  łączą  się  z  bazą
danych, aby zapisane dane dostępowe do bazy były niedostępne do ewentualnego podglądu.

Wykorzystane zostanie także narzędzie do automatyzowania procesu wykonywania zapytao

testowych. W ten sposób system zarządzania bazą danych zostanie „zasypany” dużą liczbą zapytao.
Dzięki temu zbadamy nie tylko poprawnośd, ale także odpornośd systemu na duży ruch.

b) Testowanie aplikacji przeznaczonych dla pracowników

Dzięki aplikacji przeznaczonej dla pracownika, ma on możliwośd dodania oferty, przyjęcia

zamówienia. Testując sprawdzamy odpornośd formularzy na wprowadzane dane. Ewentualne błędy,
przy automatycznym zapisie do bazy danych, mogłyby spowodowad duże konsekwencje. Badamy

Dokumentacja testów systemu informatycznego

odpornośd na wprowadzanie  danych specyficznych, bądź danych, które w  dane  pole  wprowadzone
byd  nie  powinne.  Tego  typu  testy  dotyczą  każdej  aplikacji.  Należy  ponadto  sprawdzid,  czy  dane
przesyłane  między  biurem  a  centralą  nie  ulegają  zniekształceniu  bądź  przekłamaniu.  Tutaj  także
okazuje  się pomocna aplikacja do automatyzowania procesu testowania.

c) Testowanie aplikacji internetowej dla klientów

Klient ma możliwośd zamówienia oferty przez Internet. Jest to aplikacja najbardziej narażona na

ataki z zewnątrz, ponieważ jest dostępna dla praktycznie wszystkich użytkowników. Podobnie jak
przy aplikacji pracowniczej sprawdzaliśmy aplikację w przypadkach wprowadzania złośliwych danych,
które mogą spowodowad incydenty bezpieczeostwa.

Aplikacja WWW jest narażona na specyficzne ataki, chociażby wstrzyknięcia kodu HTML, JS w

formularz i zapisanie ich w bazie. Atak typu XSS (Cross Site Scripting) może dad początek phishingowi
poprzez podmianę strony bądź przekserowanie na stronę osoby atakującej. Sprawdzając każde pole
formularza zabezpieczamy klientów przez kradzieżą tożsamości internetowej, a nawet danych
dotyczących karty płatniczej.

Należy zwrócid uwagę na ataki CSRF (Cross Site Request Forgery), które mogą doprowadzid do

nieświadomego przesyłania przez użytkownika do serwera żądania spreparowanego przez osoby o
wrogich zamiarach. Trzeba sprawdzid mechanizm potwierdzeo przy zamówieniach oraz poprawnośd
generowania tokenów (transparentnych dla użytkownika) przy każdorazowym żądaniu strony. Należy
ograniczyd metodę GET do przesyłania wrażliwych danych.

Trzeba ponadto sprawdzid podatnośd aplikacji Web na ataki Session Poisoning oraz Session

Fixation. Mogą one doprowadzid do przejęcia bądź uszkodzenia sesji użytkownika, a co za tym idzie
uzyskania dostępu do jego konta.

Szczególnie krytycznym z punktu widzenia aplikacji internetowej byłby błąd SQL Injection. Na

przetestowanie strony pod kątem podatności na niego należy przeznaczyd wiele czasu i możliwości.
Trzeba wykorzystad narzędzia wspomagające testy i automatyzujące tworzenie szkodliwych żądao.

Ponadto trzeba się upewnid, że wszystkie pliki, które nie mają byd bezpośrednio dostępne dla

użytkownika znajdują się poza katalogiem public_html serwera.

d) Testowanie modułu przelewów

Moduł przelewów jest jedną ze składowych aplikacji internetowej przeznaczonej dla klientów

oraz podwykonawców. Naszym zadaniem w tej fazie testów jest przetestowanie zabezpieczeo oraz
reakcje na różne dane, które zostaną wpisane nieprawidłowo. Należy także sprawdzid, czy system
banku prawidłowo reaguje na żądania projektowanego systemu, czy nie ma przekłamao w kwotach
przelewów ani przy rozpoznawaniu użytkownika zlecającego przelew.

e) Testowanie aplikacji dla podwykonawców

Dokumentacja testów systemu informatycznego

Natychmiastowy kontakt z podwykonawcą jest niezbędny do wykonywania koniecznych zadao

przy realizacji poszczególnych zamówieo. Sprawdzenie automatyzacji działania oraz zabezpieczenie
kanałów komunikacyjnych jest w tym wypadku głównym zadaniem. Musimy sprawdzid co się stanie
przy wyczerpaniu środków do realizacji zadania z jednej lub drugiej strony.

Należy także sprawdzid reakcje na dane niestandardowe oraz potencjalnie niebezpieczne. Trzeba

przetestowad moduł odpowiedzialny za komunikację, czy nie ma zmian w przesyłanych informacjach
oraz czy podwykonawcy mają dostęp tylko do tych danych, do których udzielono im dostępu.

4.2. Przypadki testowe i scenariusze

Przypadki testowe wyróżniamy na podstawie przypadków użycia. Definiują dane wejściowe oraz

wyjściowe  dla  danego  przypadku.  Dzięki  temu  można  zweryfikowad  poprawnośd  działania  funkcji
określonej  przypadkiem  użycia.  Wszelkie  nieoczekiwane  dane  wyjściowe  mogą  oznaczad  błąd.
Ponadto  uzyskujemy  pewien  obraz  w  sytuacjach  wprowadzenia  niestandardowych  danych  lub
warunków granicznych.

Scenariusze natomiast ustalają porządek. Przedstawiają sekwencję wykonywanych czynności w

celu sprawdzenia konkretnej części systemu. Dane wyjściowe jednego przypadku testowego są
danymi wejściowymi kolejnego w sekwencji.

a) Strona WWW i biuro

Nazwa

Wybór oferty

Stan początkowy

Dostępny formularz wyboru oferty

Dane wejściowe

Informacje o wycieczce (cel, transport, obiekty, wyżywienie)

Warunki testu

Kliknięcie przycisku „wyszukaj”

Dane wyjściowe

Identyfikatory pasujących ofert

Nazwa

Złożenie zamówienia

Stan początkowy

Lista ofert

Dane wejściowe

Identyfikator oferty

Warunki testu

Zalogowanie i kliknięcie „zamawiaj”

Dane wyjściowe

Potwierdzenie, informacje o płatności, identyfikator płatności

Nazwa

Opłacenie

Stan początkowy

Złożenie zamówienia

Dane wejściowe

Identyfikator płatności, kwota, bank zamawiającego

Warunki testu

Przejście do strony banku

Dane wyjściowe

Potwierdzenie płatności, numer referencyjny od banku

Nazwa

Złożenie zamówienia specjalnego

Stan początkowy

Formularz zamówienia

Dane wejściowe

Informacje o wycieczce (cel, transport, obiekty, wyżywienie)

Warunki testu

Kliknięcie przycisku „zamawiaj”

Dane wyjściowe

Potwierdzenie, informacje o płatności, identyfikator płatności

Dokumentacja testów systemu informatycznego



Złożenie zamówienia



Złożenie zamówienia specjalnego

b) Centrala

Nazwa

Tworzenie oferty

Stan początkowy

Dostępny formularz tworzenia oferty

Dane wejściowe

Informacje o wycieczce (cel, transport, obiekty, wyżywienie)

Warunki testu

Kliknięcie przycisku „utwórz”

Dane wyjściowe

Identyfikatory nowotworzonej oferty

Nazwa

Rezerwacja fizyczna / finalizacja

Stan początkowy

Złożenie zamówieo specjalnych

Dane wejściowe

Identyfikator zamówienia specjalnego

Warunki testu

Kliknięcie przycisku „potwierdź”

Dane wyjściowe

Potwierdzenie, identyfikator zamówienia

Nazwa

Organizacja finansów dla podwykonawców

Stan początkowy

Zamówione usługi podwykonawców

Dane wejściowe

Identyfikator podwykonawcy, kwota, opis

Warunki testu

Kliknięcie przycisku „opład”

Dane wyjściowe

Potwierdzenie, numer referencyjny przelewu

c) Podwykonawcy

Nazwa

Uaktualnianie danych o środkach podwykonawców

Stan początkowy

Zmiana danych, formularz zmiany danych

Dane wejściowe

Dane dotyczące konkretnego podwykonawcy

Warunki testu

Połączenie z serwerem centrali

Dane wyjściowe

Potwierdzenie

Dokumentacja testów systemu informatycznego

Nazwa

Rezerwacja środków podwykonawców

Stan początkowy

Złożone zamówienia

Dane wejściowe

Identyfikator podwykonawcy, środek, czas, cena, inne

Warunki testu

Połączenie z serwerem centrali

Dane wyjściowe

Potwierdzenie, numer rezerwacji

Nazwa

Wymiana danych klientów

Stan początkowy

Złożenie zamówienia wymagającego wymiany danych

Dane wejściowe

Identyfikator wycieczki, podwykonawca, dane klientów (różne w zależności
od działalności i typy wycieczki)

Warunki testu

Połączenie z serwerem centrali, kliknięcie przycisku „wyślij”

Dane wyjściowe

Potwierdzenie



Komunikacja Centrala - Podwykonawcy

d) Zarząd

Nazwa

Zarządzanie pracownikami

Stan początkowy

Panel z wyborem / wyszukaniem pracownika

Dane wejściowe

Identyfikator pracownika, dane

Warunki testu

Wybranie metody dostępu

Dane wyjściowe

Potwierdzenie, dane stare / nowe

Nazwa

Zlecanie wypłat

Stan początkowy

Panel z wyborem / wyszukaniem pracownika

Dane wejściowe

Identyfikator pracownika, kwota

Warunki testu

Kliknięcie przycisku „wypład”

Dane wyjściowe

Potwierdzenie, numer referencyjny przelewu

Nazwa

Raporty / statystyki

Stan początkowy

Panel wyboru kryteriów

Dane wejściowe

Okres, usługa, pracownik, biuro, inne

Warunki testu

Kliknięcie przycisku „generuj”

Dane wyjściowe

Wygenerowany raport

Dokumentacja testów systemu informatycznego



Zarządzanie pracownikami

4.3. Drzewa błędów

Wiele błędów propaguje na kolejne elementy systemu. Takie błędy są jednymi z najbardziej

szkodliwych. Często trudno je zidentyfikowad, bo nie wiadomo na pierwszy rzut oka z czego wynikają.
Niemniej  prawidłowe  zdiagnozowanie  może  rozwiązad  inne  usterki,  które  zostały  przez  ten  błąd
wywołane. Dużo czasu należy  przeznaczyd na zdiagnozowanie  właśnie  tego typu błędów.  Przypadki
dla poszczególnych aplikacji przedstawiają poniższe  drzewa błędów.  Korzeniem drzewa jest jedna z
rozważanych niebezpiecznych sytuacji. Wierzchołkami są sytuacje pośrednie, które mogą prowadzid
do sytuacji odpowiadającej wierzchołkowi wyższego poziomu.

a) Składanie zamówienia (zarówno przez stronę WWW, jak i aplikację biura

Dokumentacja testów systemu informatycznego

b) Tworzenie ofert przez centralę

c) Błędy aplikacji podwykonawców

4.4. Strategia białej i czarnej skrzynki;

Wykorzystując strategię białej skrzynki sprawdzimy logikę wewnętrzną oprogramowania.

Wstawiamy kod diagnostyczny i dzięki debuggerom prześledzimy kod programu „krok po kroku”.
Trzeba też przygotowad różne dane testowe i dzięki programom usprawniającym testowanie
sprawdzid każdą procedurę poprzez wywoływanie jej z różnymi parametrami. Każdą możliwą ścieżkę
należy przetestowad przynajmniej jeden raz.

Należy wykorzystad także metodę czarnej skrzynki. Tak określa się sprawdzanie funkcji

oprogramowania  bez  zaglądania  do  środka  programu.  Testujący  traktuje  sprawdzany  moduł  jakby
wnętrze było niewidoczne. Tą strategią należy objąd cały zakres danych wejściowych. Warto podzielid
dane  wejściowe  w  „klasy  równoważności”,  co  do  których  można  mied  przypuszczenie,  że  będą
produkowad  te  same  błędy.  Wynikiem  będzie  analiza  danych  wyjściowych  –  czy  są  zgodne  z
oczekiwaniami.

Dokumentacja testów systemu informatycznego

4.5. Zespół oceniający i testy akceptacyjne

Zespół oceniający musi składad się z potencjalnych użytkowników każdego z interfejsów,

niezależnych specjalistów IT, zamawiających – przedstawicieli firmy Husajn Travel oraz kierownika i
sekretarza wykonawczej firmy KittyTeam.

Potencjalni użytkownicy będą oceniad interfejsy pod względem funkcjonalności dla właściwiej

dla siebie dziedziny, z uwzględnieniem zaawansowania technicznego jakim przyszli użytkownicy będą
dysponowad. W tej grupie wyznaczone zostaną po trzy osoby dla każdego z działów – IT, zarządu,
pracowników biur podróży, podwykonawców, centrali i użytkowników strony www.

Reprezentanci z działu IT to osoby z wyższym wykształceniem informatycznym, którym

można powierzyd zarówno możliwośd modyfikacji części kodu aplikacji jak i dostęp do bazy danych.
Będą oni badali odpowiednie funkcjonalności swojego działu, działanie bazy danych oraz
przejrzystośd i klarownośd kodu którym będą dysponowali.

Reprezentanci zarządu, pracowników biur podróży i centrali to osoby z wykształceniem

średnim i wyższym, niekoniecznie biegłe w obsłudze komputera. Będą badad czas jaki potrzebny jest
na naukę obsługi programu, jego łatwośd i przystępnośd oraz raportowad ewentualne błędy.

Częśd zespołu oceniającego działu podwykonawców również będzie się składała z trzech

osób, jednak będą to osoby z trzech różnych dziedzin – przykładowo transportu, wypoczynku i
ubezpieczeo. Będą oni badad spójnośd wersji programu przygotowanych dla ich dziedziny, zasadnośd
odpowiednich funkcji w zestawieniu z realiami, również czas potrzebny na naukę obsługi programu
oraz raportowad błędy.

Zespół oceniający użytkowników strony WWW będzie się składał z losowo wybranych,

niezwiązanych z firmami Husajn Travel, KittyTeam ani z żadną z firm podwykonawców trzech osób w
wieku  od  25  do  65  lat,  którzy  będą  badad  funkcjonalnośd  strony  WWW  i  jej  przystępnośd  dla
dowolnego  użytkownika  który  zechce  skorzystad  z  oferty  Husajn  Travel.  Będą  oni  mieli  za  zadanie
przetestowad  wszystkie  dostępne  funkcje  strony,  sprawdzid  czy  jest  wygodna  w  użytkowaniu,  czy
występują na niej jakieś błędy itp.

Dodatkowo w zespole oceniającym znajdzie się pięciu niezależnych specjalistów IT,

niezwiązanych z firmami Husajn Travel, KittyTeam ani z żadną z firm podwykonawców, którzy będą
badad kod programu oraz założenia niefunkcjonalne, starając się odpowiedzied na pytanie czy zostały
one zrealizowane, a także czy badany kod jest wystarczająco przejrzysty aby mógł byd przekazany do
przyszłego zespołu działu IT działającego z ramienia firmy Husajn Travel.

Przedstawiciele  firmy  Husajn  Travel  będą  badali  zgodnośd  systemu  z  wymaganiami  które  postawili
podczas  składania  zamówienia  na  system  informatyczny,  ze  szczególnym  uwzględnieniem
realizowania funkcji dziedzinowych. Kierownik i sekretarz z firmy KittyTeam będą nadzorowad prace
poszczególnych  części  zespołu  oceniającego,  notowad  wnioski  i  kierowad  do  reszty  zespołu
wykonawczego w celu poprawienia ewentualnych błędów w działaniu systemu lub jakiejś jego części.

Dokumentacja testów systemu informatycznego

5. Audyt

Projekt dla firmy Husajn Travel jest dużym systemem informatycznym, stąd występuje

koniecznośd zlecenia przeprowadzenia audytu. Ma on byd zgodny z normą ANSI/IEEE Std 1028-1988
„IEEE  Standard  for  Reviews  and  Audits”.  Jego  celem  jest  niezależny  przegląd  i  ocena  jakości
oprogramowania,  która  zapewnia  zgodnośd  z  wymaganiami  na  oprogramowanie,  a  także  ze
specyfikacją,  generalnymi  założeniami,  standardami,  procedurami,  instrukcjami,  kodami  oraz
kontraktowymi i licencyjnymi wymaganiami.

Aby zapewnid obiektywnośd, za jego przeprowadzenie odpowiedzialna będzie niezależna

organizacja, nie  mająca żadnych powiązao z firmą KittyTeam, ani z firmą Husajn Travel. Audytorem
bowiem będzie Polskie Stowarzyszenie Audytu.  Audytowi podlegad będzie nie tylko stan ukooczenia
projektu,  ale  przede  wszystkim  jego  zgodnośd  z  założeniami,  możliwości  (zasoby,  kompetencje,
metody,  standardy)  oraz  bezpieczeostwo  (czynnik  techniczny  oraz  czynnik  ludzki),  jak  i  wygoda
użytkowania. W audycie zostanie też wykazane czy wykonywane prace oraz sposób ich wykonywania
są  prawidłowe,  czy  użyte  techniki  oraz  opracowane  rozwiązania  są  prawidłowe  i  prawidłowo
stosowane oraz czy sposób zarządzania projektem umożliwi jego sukces.

Ponadto zostanie zbadana opinia Generalnego Inspektora Ochrony Danych Osobowych

odnośnie zgodności systemu z Ustawą z dnia 29.08.97 r. o Ochronie Danych Osobowych Dz. U. Nr 133
poz. 883. Kwestie związane płatnościami i ich poufnością będą także podlegały przedstawicielom
bankowym i sektora kartowego.

Nie planuje się dokonywania innych inspekcji, gdyż system nie ma charakteru specjalnego, a

koszta przeprowadzenia dodatkowej inspekcji są niewspółmierne do charakterystyki projektu.

6. Wykorzystane narzędzia

Przy wykonywaniu testów posłużymy się kilkoma narzędziami. Pozwolą one w znacznym stopniu

zautomatyzowad naszą pracę. Zmniejsza to czas przeznaczony na testy. Zastosowanie
zaawansowanych narzędzi, zaliczanych do tzw. warsztatu testera, minimalizuje możliwośd
przeoczenia niektórych błędów, co możliwe by było przez tzw. błąd ludzki.

W fazie testów wykorzystujemy m.in. analizator przykrycia kodu. Pozwala to na wykrycie

martwego  kodu,  kodu,  który  uruchamiany  jest  tylko  przy  niektórych,  bardzo  specyficznych  danych
oraz  kodu  wykonywanego  bardzo  często  (oznaka  wąskiego  gardła  w  programie).  Do
zautomatyzowania  testów  wykorzystujemy  środowisko  do  tworzenia  i  zarządzania  testami.  Na
wstępie w systemie kontroli udostępniamy dokumenty zawierające wymagania i scenariusze, pliki z
danymi używanymi do testowania i plan testów. Pozwala to nam na bieżąco orientowad się w sytuacji
oraz w znacznym stopniu zapobiega ewentualnemu chaosowi przy testowaniu aplikacji.

W dalszej kolejności opracowujemy reguły pracy związane z wystąpieniem różnego rodzaju

zdarzeo. Mamy ustalid do kogo należy konkretne zadanie w sytuacjach newralgicznych. Do takich

Dokumentacja testów systemu informatycznego

sytuacji  na  pewno  można  zaliczyd  przypadek  błędu  i  skierowania  informacji  o  tym  do  osoby
przedzielającej  zadanie  usunięcia  usterki.  Informacja  o  poprawieniu  oprogramowania  trafia  do
zespołu  testującego.  Zespół,  na  zmodyfikowanej  wersji  aplikacji,    ponownie  uruchamia  skrypty
testowe.

Do zarządzania i dokumentowania testów wykorzystujemy między innymi TestManager'a. Do

budowy  skryptów  automatycznych  program  Robot.  Zaimplementowane  w  Robot  skrypty
uruchamiamy  w  skonstruowanych  w  programie  TestFactory  testach  automatycznych.  Oczywiście
bardzo  ważne  w  fazie  testów  jest  sprawdzenie  zgodności  dostarczonej  do  testów  wersji  aplikacji  z
wymaganiami wypracowanymi we wcześniejszych fazach budowy aplikacji. Purify nadaje się do tego
celu  idealnie.  Pozwala  nam  to  wykryd  ewentualne  nieścisłości,  które  narosły  w  trakcie  pracy  nad
kolejnymi etapami.

7. Podsumowanie

Jeśli mielibyśmy rozważyd kryterium zakooczenia testowania, to takiego nie ma. Testowanie

nigdy  nie  jest  zakooczone,  gdyż  od  pierwszej  instalacji  prototypu  oprogramowanie  testowane  jest
przez  użytkownika.  Wiele  błędów  będzie  zgłaszanych  właśnie  po  wdrożeniu.  Wtedy  „test”  będzie
przeprowadzad  największa  grupa  „testerów”.  Testy  zamknięte  mają  zapewnid  to,  że  po  wdrożeniu
minimalizujemy  ryzyko  wystąpienia  usterki  o  charakterze  krytycznym.  Praktyczne,  zamknięte  testy
musimy  zakooczyd  do  kooca  grudnia  (zgodnie  z  harmonogramem  implementacji  w  Dokumentacji
Projektowej).

7.1. Przyszłe wersje

W przypadku dokonywanych testów zwracamy szczególną uwagę na najważniejsze funkcje

naszej  aplikacji.  Za  kryterium  ważności  przyjmujemy  ocenę  modelowego  użytkownika  oraz
przewidywaną  częstotliwośd  używania  danej  funkcji  w  stosunku  do  innych.  Wybrane  przez  nas
funkcje musiały byd jak najlepiej przetestowane i  to na nich trzeba skupid największą uwagę. Ma to
ogromne  znaczenie,  ponieważ  przy  każdej  następnej  wersji  programu,  szkielet  najważniejszych
funkcji pozostanie z pewnością taki sam. Nasz zespół testując aplikację, przygotowuje kolejne wersje
oprogramowania. W każdej kolejnej wersji testowej aplikacji zwracamy szczególną uwagę właśnie na
te najważniejsze funkcje, aby użytkownik nie był zdziwiony błędami pojawiającymi się przy używaniu
poznanej z poprzednich wersji funkcjonalności.

Do takich ważnych funkcji zaliczyliśmy moduł składania zamówieo przez Internet oraz

dokonywania  płatności.  Cały  proces  zamówienia,  w  każdej  wersji  programu  jest  sprawdzany  od
początku  do  kooca.  Sprawdzamy  go  dla  różnych  danych,  dla  ich  braku  i  danych  podawanych
ewidentnie źle. Wyobrażamy sobie najbardziej absurdalne pomysły, które mogłyby przyjśd do głowy,
lub po prostu zostad wprowadzone przez użytkownika do formularza zgłoszeniowego. W przyszłych
wersjach programu byd może moduł składania zamówienia będzie się zmieniał, a nawet jeśli się nie
zmieni  należy  go  przetestowad.  Jest  on  zbyt  ważny  i  ma  zbyt  dużo  powiązao  w  całej  aplikacji.
Sprawdzenie wprowadzanych danych oraz wyniku finalizacji zamówienia w bazie danych powinno w
przyszłych testach byd minimum jakie należy wykonad.