Table Of Content

Wszelkie 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 powinien 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 aplikacji 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 sytuacji 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 projektu 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 produktu, 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 realizacji 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