Table Of ContentWszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości
lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione.
Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie
książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie
praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi
bądź towarowymi ich właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte
w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej
odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne
naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION
nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe
z wykorzystania informacji zawartych w książce.
Redaktor prowadzący: Ewelina Burska
Projekt okładki: Studio Gravite/Olsztyn
Obarek, Pokoński, Pazdrijowski, Zaprucki
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: [email protected]
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/szteop_ebook
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
ISBN: 978-83-283-0139-9
Copyright © Helion 2014
Poleć książkę na Facebook.com Księgarnia internetowa
Kup w wersji papierowej Lubię to! » Nasza społeczność
Oceń książkę
Więcej na: www.ebook4all.pl
Spis treści
Przedmowa ........................................................................................................5
Wstęp ................................................................................................................7
Rozdział 1. Ogólna teoria testowania ................................................................11
1.1. Techniki testowania ..................................................................................................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 danych ..........................................................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 testera ............................................................................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. Testy modułowe .......................................................................................................66
2.2. Testy integracyjne .....................................................................................................67
2.3. Testy systemowe .......................................................................................................71
2.4. Testy akceptacyjne ...................................................................................................72
Rozdział 3. Typy testów ....................................................................................73
3.1. Testy funkcjonalne ...................................................................................................73
3.2. Testy niefunkcjonalne ...............................................................................................74
3.2.1. Testy wydajnoś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 regresywne ....................................................................................................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 stanami ...........................................................................134
4.1.3. Projektowanie testu w oparciu o przypadki użycia .......................................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 TCPMon .........................................................................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
Przedmowa
Niniejsza publikacja skierowana jest do wszystkich, którzy w sposób świadomy chcą
odnaleźć się w roli testera oprogramowania. W momencie powzięcia decyzji o napi-
saniu tej książki założyłem, że powinna ona wstępnie ukształtować jednostkę w mate-
rii kontroli jakości oprogramowania. Książkę kieruję do osób myślących o rozpoczę-
ciu pracy w zawodzie testera. Studiując tę publikację, Czytelnik powinien wynieść
wystarczającą ilość wiedzy, która otworzy mu drogę do dalszego samokształcenia
i kształtowania własnych poglądów w obszarze kontroli jakości oprogramowania. Istotą
współczesnej edukacji jest zaszczepienie potrzeby nieustannego rozwijania potencjału
intelektualnego, a system edukacji oprócz przekazania elementarnej wiedzy powi-
nien nauczyć jednostkę, jak ma się sama uczyć. Pokładam nadzieję, że w niniejszej
publikacji zostanie dostrzeżona taka wartość.
Osoby, które regularnie uczestniczą w projektach testowych, studiując tę książkę, będą
mogły zweryfikować i usystematyzować własną wiedzę. Nierzadko spojrzenie z innej
perspektywy na znane problemy może okazać się katalizatorem zmian.
Książka nie stanowi typowego podręcznika dydaktycznego. Stworzona została w oparciu
o doświadczenia wyniesione z uczestnictwa w projektach, własne spostrzeżenia, przemy-
ślenia i proces twórczy autora. Nie stanowi ona odpowiedzi na program kursu ISTQB ani
nie omawia standardów IEEE dotyczących testowania oprogramowania. Według
mnie — autora — to wartość dodana publikacji, gdyż pozwala na wychylenie się po-
za obszar pracy odtwórczej i złamanie szablonowego podejścia do tytułowej proble-
matyki. Jednak od elementarza się nie ucieknie, dlatego też pewna partia materiału
może znaleźć swoje odzwierciedlenie w powyżej wymienionych dokumentach.
Drogi Czytelniku! W przypadku kiedy znajdziesz błąd w niniejszej publikacji, przyjmij
moje szczere gratulacje. Właśnie postawiłeś pierwszy krok w zawodzie testera! Błąd
zgłoś do redakcji wydawnictwa Helion. Proces testowania rozpoczyna się już na etapie
pisania dokumentacji.
6 Testowanie oprogramowania. Podręcznik dla początkujących
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 decyzje 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).
Wstęp 9
Rysunek W.1. Hipotetyczny przebieg realizacji projektu produkcji oprogramowania
Zespół testów wewnętrznych (testy modułowe) rozpoczął pracę w momencie, kiedy
faktycznie aplikacja powinna być już weryfikowana na etapie ostatecznych testów ja-
kościowych (punkt B). Zatem faza, w której decyduje się o oficjalnym wydaniu pro-
duktu, rozpoczęła się niemalże przed datą finalnego zakończenia projektu (punkt C).
Osiągnięcie punktu C stanowi moment krytyczny, gdyż pojawia się realna groźba
utraty części zysku na skutek pokrycia kar umownych za niedotrzymanie terminu re-
alizacji umowy. Nietrudno sobie wyobrazić, że powstanie konflikt interesów pomię-
dzy kierownikiem projektu (ang. Project Manager — PM) a zespołem testów. Każdy
z uczestników będzie bronił partykularnych interesów. O tym, jak się zachować w takiej
sytuacji, będzie mowa w dalszych częściach książki.
Istnieje zasada kumulowania się błędów. Oznacza to, że większość wykrytych pro-
blemów znajduje swoje źródło w niewielkiej liczbie modułów. W aspekcie praktycznym
duża „błędogenność” określonego fragmentu kodu wygeneruje większość błędów w ca-
łościowym ujęciu aplikacji.
10 Testowanie oprogramowania. Podręcznik dla początkujących
