Pawlak R. - Testowanie. Oprogramowania Podręcznik Dla Początkujacych.pdf

(4566 KB) Pobierz
Rafał Pawlak
TESTOWANIE
OPROGRAMOWANIA
Podręcznik dla początkujących
Testuj program y i śpij spokojnie!
* Ogólna teoria testowania,
czyli po co nam testy i jak sobie z nimi radzić
* Projekt a proces testowania,
czyli kiedy zacząć testować i jak to robić z głową
* Automatyzacja i dokumentacja,
czyli jak ułatw ić sobie pracę podczas testowania
Helion
Spis treści
Przedmowa ................................................................................................................. 5
W stęp..........................................................................................................................7
Rozdział 1. Ogólna teoriatestowania ...................................................................... 11
1.1. Techniki testow ania..........................................................................................................13
1.2. Miara jakości oprogramowania ...................................................................................... 17
1.3. Środowisko testowe i produkcyjne ................................................................................ 23
1.4. Replikacja błędów ........................................................................................................... 28
1.5. U mnie błąd nie występuje ............................................................................................. 30
1.6. Symulatory aplikacji oraz generatory d anych............................................................... 31
1.7. Dokumentowanie testów .................................................................................................34
1.8. Kontrola wersji oprogramowania ...................................................................................35
1.9. Obsługa zgłoszeń..............................................................................................................39
1.10. Testowanie obsługi wyjątków w kodzie ..................................................................... 43
1.11. Narzędzia wsparcia pracy te ste ra................................................................................. 51
1.12. Presja czasu .................................................................................................................... 52
1.13. Profil profesjonalnego testera .......................................................................................54
1.14. Testowanie w oknie czasu ............................................................................................ 58
1.15. Jak wygląda realizacja projektu w praktyce?..............................................................60
1.16. Testowanie w cyklu życia oprogramowania...............................................................62
Rozdział 2. Poziomy wykonywania testów ..............................................................65
2.1.
2.2.
2.3.
2.4.
Testy
Testy
Testy
Testy
modułowe ...............................................................................................................66
integracyjne............................................................................................................ 67
systemowe...............................................................................................................71
akceptacyjne .......................................................................................................... 72
Rozdział 3. Typy testów ...........................................................................................73
3.1. Testy funkcjonalne .......................................................................................................... 73
3.2. Testy niefunkcjonalne......................................................................................................74
3.2.1. Testy w ydajności....................................................................................................74
3.2.2. Testy bezpieczeństwa aplikacji ............................................................................ 91
3.2.3. Testy przenośności kodu — testy instalacji.......................................................117
3.2.4. Testy ergonomii systemu informatycznego ...................................................... 118
3.3. Testy regresyw ne............................................................................................................125
4
Testowanie oprogramowania. Podręcznik dla początkujących
Rozdział 4. Wprowadzenie do projektowania testów ............................................ 129
4.1. Projektowanie testu w oparciu o technikę czarnej skrzynki...................................... 131
4.1.1. Wartości brzegowe ...............................................................................................131
4.1.2. Przejścia pomiędzy stanam i.................................................................................134
4.1.3. Projektowanie testu w oparciu o przypadki u ży cia...........................................135
4.2. Projektowanie testu w oparciu o technikę białej skrzynki ........................................ 136
4.3. Projektowanie testu w oparciu o doświadczenie testera ............................................140
4.4. Przypadki testowe w ujęciu praktycznym.....................................................................140
Rozdział 5. Psychologiczne aspekty procesu testowania...................................... 149
Rozdział 6. Syndrom zniechęcenia testami ........................................................... 153
Rozdział 7. Testowanie usług sieciowych ..............................................................165
7.1. Narzędzie SoapUI — klient usługi sieciowej ............................................................. 165
7.2. Symulator serwera usług sieciowych — SoapUI Mock Services .............................171
7.3. Monitor TCP — Apache T C P M on.............................................................................. 177
Rozdział 8. Wprowadzenie do automatyzacji testów ............................................. 183
Dodatek A Generowanie sumy kontrolnej ............................................................. 187
Dodatek B Membrane SOAP Monitor .................................................................... 189
Dodatek C Wireshark — analizator ruchu sieciowego .........................................195
Dodatek D Generowanie danych testowych ......................................................... 197
O autorze ................................................................................................................207
Skorowidz ..............................................................................................................209
Wstęp
Testowanie oprogramowania to proces zapewnienia jakości oprogramowania. „Ja­
kość” to termin określający stopień zgodności implementacji kodu z oczekiwaniami,
potrzebami i założonymi wymaganiami postawionymi przez zamawiającego. Jakość
to miara określająca, w jakim stopniu oprogramowanie spełnia wymagania biznesowe
oraz zaspokaja oczekiwania klienta. Jakość oprogramowania można opisywać poprzez
jego atrybuty, które zostaną wstępnie omówione w rozdziale 1.2.
Testowanie to proces obejmujący wszelkie czynności mające na celu potwierdzenie
zgodności zaproponowanych rozwiązań ze specyfikacją wymagań. Celem testowania jest
wykrywanie i raportowanie błędów. Za błąd należy uważać pomyłkę programisty, której
skutkiem jest niepożądane zachowanie aplikacji. Proces testowania ujawnia odchyle­
nia od założonego działania systemu poprzez porównanie otrzymanego wyniku testu
z oczekiwanym rezultatem. Błąd w wykonywanym kodzie znajdzie swoje odwzoro­
wanie w postaci niepoprawnego zachowania programu.
Na potrzeby niniejszej publikacji przyjmijmy uogólnienie, że błąd to nieoczekiwane
zachowanie systemu na skutek pomyłki programisty. Jako błąd traktujmy rozbieżno­
ści w działaniu systemu w porównaniu z wyspecyfikowanymi wymaganiami. Błędem
będziemy nazywać widoczny skutek, a nie przyczynę (wadę kodu). Oczywiście jedno
wynika z drugiego. Niemniej jednak w tej publikacji oba pojęcia mogą się delikatnie
przenikać. Notabene jest to odmienne podejście od prezentowanego w ramach kursu
ISTQB, gdzie błędem jest pomyłka człowieka, która wywołuje defekt w programie,
a wykonanie kodu z defektem zwykle skutkuje awarią.
Intencją testowania oprogramowania jest zmniejszenie ryzyka wystąpienia błędu w śro­
dowisku produkcyjnym. Wczesne wykrycie błędu zmniejsza koszty jego naprawy oraz
minimalizuje potencjalne konsekwencje. Wystąpienie niepożądanego zdarzenia w śro­
dowisku produkcyjnym wiąże się z wysokimi kosztami poprawy oraz generowaniem
strat w postaci utraconych korzyści biznesowych (np. czasowa blokada możliwości
realizowania zakupów w sklepie internetowym realnie wpłynie na wyniki finansowe
przedsiębiorstwa). Do negatywnych skutków błędów produkcyjnych należy również
zaliczyć ujmę w wizerunku oraz obniżenie zaufania do podmiotu (np. operatora, który
czasowo stracił zdolność do obsługiwania transakcji kartą).
8
Testowanie oprogramowania. Podręcznik dla początkujących
Testowanie oprogramowania umożliwia zmierzenie jakości produktu. Wskaźnikiem
oceny jest liczba wykrytych błędów. Jeżeli w całym projekcie testowym znaleziono
mało błędów, tym samym podnosi się zaufanie do wytworzonego kodu. Testy winny
być zaprojektowane w sposób miarodajny. Luki w pokryciu testami aplikacji mogą za­
fałszować ostateczną ocenę stanu systemu. Zgodnie z nauką ISTQB samo testowanie
nie podnosi jakości oprogramowania. Jakość systemu wzrasta dopiero wtedy, gdy owe
problemy zostaną rozwiązane.
Podstawowa prawda o testowaniu mówi, że testy nie są w stanie udowodnić, iż w aplika­
cji błędów nie ma. Testy wykrywają błędy, ale nie udowadniają bezbłędności programu,
nawet jeżeli wszystkie założone przypadki testowe zostaną zakończone pozytywnie.
Podjęcie testów powinno nastąpić tak wcześnie, jak jest to możliwe. Rozpoczęcie czyn­
ności dopiero po etapie kodowania jest bardzo ryzykowne i stanowczo spóźnione. Testy
powinny rozpocząć się już na etapie analizy i projektowania. Materiałem podlegającym
weryfikacji będzie powstała dokumentacja. Testerzy w oparciu o rzeczywiste doświad­
czenia mogą wychwycić błędne założenia, których skorygowanie na etapie specyfiko-
wania uchroni przedsięwzięcie od dodatkowych kosztów. Implementacja wadliwie
zaprojektowanych rozwiązań podniesie kilkukrotnie koszty naprawienia błędu. Czynno­
ści testowe muszą być rozpoczynane we wczesnych fazach cyklu życia oprogramowania.
Druga prawda o testowaniu mówi, że testy powinny kiedyś się zakończyć, mimo że
nigdy nie nabierzemy przekonania o bezbłędności programu. Decyzja o przerwaniu
testów uzależniona jest od poziomu ryzyka, prawdopodobieństwa wystąpienia sytu­
acji niepożądanych oraz płynących z owych zdarzeń konsekwencji. Testy gruntowne
— tj. uwzględnienie wszystkich warunków wstępnych i kombinacji danych wejścio­
wych — są niemożliwe. Ograniczenia ekonomiczne oraz brak uzasadnienia praktycz­
nego negują potrzebę kontynuowania testów w nieskończoność. Kluczem do sukcesu
jest trafne wytypowanie momentu zakończenia testów. Warunkiem koniecznym jest
zamknięcie wszystkich przypadków testowych z wynikiem pozytywnym. Niestety
nad wymienionym kryterium często biorą górę tak zwane decyzj e polityczne maj ące na
celu skrócenie terminu przekazania produktu klientowi (świadome przekazywanie
produktu z ujawnionymi i niepoprawionymi błędami, emisja bez przeprowadzenia
pełnych testów). Zamknięcie przypadków testowych uwiarygodnia pogląd, że cel pro­
jektu został osiągnięty. Istotą sukcesu jest optymalne zaplanowanie testów i prawi­
dłowe zaprojektowanie przypadków testowych. Ta tematyka będzie analizowana w ko­
lejnych rozdziałach książki.
Trzecia prawda o testowaniu mówi, że zespół kontroli jakości może być postrzegany
jako czynnik blokujący wydanie produktu klientowi w momencie, kiedy cały projekt
osiągnął punkt krytyczny (datę końcową). Otóż „twórca” przedsięwzięcia polegającego
na wyprodukowaniu oprogramowania zgodnego z oczekiwaniami klienta i w zadanym
harmonogramie powołał grupy i powierzył im ściśle określone zadania. Ostateczne
testy jakościowe wykonywane są jako jeden z ostatnich etapów w cyklu produkcji.
Niestety często występującym zjawiskiem jest przekazywanie produktu do testów ja ­
kościowych ze znaczącym opóźnieniem. Rysunek W.1 ilustruje hipotetyczną sytuację,
w której zespół programistów skonsumował własny czas, czas przypisany na testy
wewnętrzne oraz fragment czasu zarezerwowanego na testy jakościowe (punkty A i B
grafiki).

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin