Wszelkie prawa zastrzeżone. Nieautoryzowane ...68 Testowanie oprogramowania. Podröcznik dla...

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 BurskaProjekt okładki: Studio Gravite/Olsztyn Obarek, Pokoński, Pazdrijowski, Zaprucki

Wydawnictwo HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: 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/szteopMożesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

ISBN: 978-83-246-9308-5

Copyright © Helion 2014

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

http://helion.pl/rt/szteophttp://helion.pl/rf/szteophttp://helion.pl/ro/szteophttp://helion.plhttp://ebookpoint.pl/r/4CAKF

Spis tre ciPrzedmowa ......................................................................................................... 5

Wst p ................................................................................................................. 7

Rozdzia 1. Ogólna teoria testowania ................................................................. 111.1. Techniki testowania ................................................................................................. 131.2. Miara jako ci oprogramowania ............................................................................... 171.3. rodowisko testowe i produkcyjne .......................................................................... 231.4. Replikacja b dów ................................................................................................... 281.5. U mnie b d nie wyst puje ...................................................................................... 301.6. Symulatory aplikacji oraz generatory danych .......................................................... 311.7. Dokumentowanie testów ......................................................................................... 341.8. Kontrola wersji oprogramowania ............................................................................ 351.9. Obs uga zg osze ..................................................................................................... 391.10. Testowanie obs ugi wyj tków w kodzie ................................................................ 431.11. Narz dzia wsparcia pracy testera ........................................................................... 511.12. Presja czasu ........................................................................................................... 521.13. Profil profesjonalnego testera ................................................................................ 541.14. Testowanie w oknie czasu ..................................................................................... 581.15. Jak wygl da realizacja projektu w praktyce? ......................................................... 601.16. Testowanie w cyklu ycia oprogramowania .......................................................... 62

Rozdzia 2. Poziomy wykonywania testów .......................................................... 652.1. Testy modu owe ...................................................................................................... 662.2. Testy integracyjne .................................................................................................... 672.3. Testy systemowe ...................................................................................................... 712.4. Testy akceptacyjne .................................................................................................. 72

Rozdzia 3. Typy testów ..................................................................................... 733.1. Testy funkcjonalne .................................................................................................. 733.2. Testy niefunkcjonalne .............................................................................................. 74

3.2.1. Testy wydajno ci ............................................................................................ 743.2.2. Testy bezpiecze stwa aplikacji ...................................................................... 913.2.3. Testy przeno no ci kodu — testy instalacji .................................................. 1173.2.4. Testy ergonomii systemu informatycznego .................................................. 118

3.3. Testy regresywne ................................................................................................... 125

Kup książkę Poleć książkę

http://helion.pl/rt/szteophttp://helion.pl/rf/szteop

4 Testowanie oprogramowania. Podr cznik dla pocz tkuj cych

Rozdzia 4. Wprowadzenie do projektowania testów ......................................... 1294.1. Projektowanie testu w oparciu o technik czarnej skrzynki ................................... 131

4.1.1. Warto ci brzegowe ....................................................................................... 1314.1.2. Przej cia pomi dzy stanami .......................................................................... 1344.1.3. Projektowanie testu w oparciu o przypadki u ycia ....................................... 135

4.2. Projektowanie testu w oparciu o technik bia ej skrzynki ..................................... 1364.3. Projektowanie testu w oparciu o do wiadczenie testera ........................................ 1404.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 ......................................................... 1657.1. Narz dzie SoapUI — klient us ugi sieciowej ........................................................ 1657.2. Symulator serwera us ug sieciowych — SoapUI Mock Services .......................... 1717.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



Rozdzia 2.

Poziomy wykonywaniatestów

Proces wytwarzania oprogramowania podzielony jest na fazy, w których wykonujesi specyficzne dla ka dego z etapów testy.

Testy dzieli si na poziomy:

testy modu owe (jednostkowe),

testy integracyjne wewn trzne,

testy systemowe,

testy integracyjne zewn trzne,

testy akceptacyjne (odbiorcze).

Rysunek 2.1 przedstawia piramid poziomu testów. Testy wykonywane s zgodniez oddoln interpretacj infografiki, tj. od testów modu owych a po testy akceptacyjne.

Rysunek 2.1.Piramidapoziomu testów




2.1. Testy modu oweTesty modu owe wykonuje si na etapie wytwarzania kodu. Uczestnikami tego ro-dzaju testów s najcz ciej programi ci, którzy w fazie implementacji poddaj weryfika-cji w asny kod. Wspomniane testy musz odnosi si do niewielkich i ci le wyizolowa-nych fragmentów kodu. Polegaj one na wykonywaniu wybranego fragmentu instrukcjiw celu zweryfikowania, czy realizuje ona swoj funkcj zgodnie z za o eniami. Pro-gramista przygotowa metod , która konwertuje numer NRB (Numer Rachunku Ban-kowego) na IBAN (ang. International Bank Account Number — pol. Mi dzynarodowyNumer Rachunku Bankowego). Wspomniana metoda b dzie wielokrotnie u ywanaw ró nych miejscach systemu. Test modu owy polega b dzie na wywo ywaniu owejmetody z podaniem jako parametru wej ciowego numeru NRB i weryfikacji otrzyma-nego wyniku. Wywo anie metody mo e odbywa si z poziomu rodowiska deweloper-skiego bez zastosowania GUI. Na tym koniec. Testy modu owe powinny odnosi sido ma ych podmiotów, a ich wynik powinien by zale ny od innych elementów, którepotencjalnie maj znale si w gotowej aplikacji. Testy modu owe nie powinny wnikaw szczegó y procesu biznesowego. Analizie i ocenie podlega jedynie ma y i wyizolowa-ny fragment kodu. W przypadku kiedy nabierzemy zaufania do testowanych frag-mentów kodu, mo emy rozpocz sk adanie ich do postaci gotowego produktu lubwi kszego komponentu.

Testy modu owe wykonuje si zwykle w rodowisku deweloperskim z dost pem dokodu ród owego. Wymaga to od testera — o ile nie jest programist — umiej tno ciczytania i wykonywania kodu oraz pisania w asnych skryptów (fragmentów kodu). By-wa, i przetestowanie pewnego modu u wymaga zaanga owania elementów pobocznych,np. symulatora us ugi sieciowej.

Dlaczego nale y wykonywa testy modu owe?B dy wykryte we wczesnej fazie produkcji oprogramowania kosztuj znacznie mniejani eli poprawa oraz usuwanie ich skutków w kolejnych fazach wytwarzania lubu ytkowania produkcyjnego aplikacji. Wykryte problemy usuwane s natychmiast,przez co minimalizuje si ryzyko propagacji negatywnego wp ywu wadliwego koduna pozosta e modu y np. poprzez odziedziczenie wady. B dy wykryte w tej fazie zwyklenie znajduj odzwierciedlenia w postaci formalnego zg oszenia, co przyspiesza udo-skonalanie kodu i nie niesie ze sob ryzyka krytycznych uwag osób trzecich. Jest tobardzo bezpieczna i efektywna forma testów w asnego kodu. Kompilator nie weryfikujeintencji programisty. Zatem pomimo i kod zosta skompilowany, nie mo na go uzna zapoprawny bez przeprowadzenia testu jednostkowego. Od o enie procesu testowaniado momentu z o enia w ca o wszystkich elementów niesie ze sob znaczne ryzyko, inie uda si uruchomi aplikacji lub pewnych funkcjonalno ci za pierwszym razem.B dy, które zostan ujawnione, mog mie przyczyn g boko ukryt w kodzie. Prze-szukiwanie „rozdmuchanych” róde w celu wyizolowania przyczyny problemu b dzieczasoch onne i zapewne irytuj ce. Testy modu owe pozwalaj na wyeliminowanie ty-powych problemów w podstawowej cie ce obs ugi systemu. Im mniej problemówzostanie przeniesionych z fazy implementacji do fazy formalnych testów, tym szybciejgotowy produkt zostanie przekazany do odbiorcy, a jego jako wzro nie.



Rozdzia 2. Poziomy wykonywania testów 67

2.2. Testy integracyjneU podstaw testów integracyjnych le y opieranie jednego procesu biznesowego na wieluró nych systemach, podsystemach i aplikacjach. Heterogeniczno ostatecznie ofero-wanego u ytkownikowi ko cowemu rozwi zania wymusza przeprowadzenie pe negotestu biznesu w oparciu o scalone rodowisko. Aby by o to mo liwe, uprzednio nale yzweryfikowa interakcj pomi dzy poszczególnymi modu ami. Zwie czenie sukce-sem owych prac stanowi podstaw do traktowania wszystkich modu ów jako jedensystem. Niezachwiane przekonanie o spójno ci systemu otwiera drog do pe nych testówfunkcjonalnych w ca o ciowym uj ciu obs ugi biznesu.

Testy integracyjne to szczególny rodzaj dzia a podejmowanych w celu zbadania ko-operacji oraz wzajemnego oddzia ywania dwóch lub wi cej modu ów systemu. Przezdesygnat „modu ” nale y rozumie zupe nie autonomiczny produkt lub fragment kodu,który ostatecznie jest ci le spojony z g ówn architektur systemu.

Testy integracyjne maj wykaza :

czy modu y poprawnie wspó pracuj , tj. czy nie wyst pi y przeszkody naturytechnologicznej oraz czy wzajemnie wiadczone us ugi spe niaj oczekiwania(logika);

jak zachowuj si poszczególne elementy w sytuacji awarii, b dówlub niestabilnej pracy w przypadku dysfunkcji jednego z nich (wzajemneoddzia ywanie);

czy kojarzone wzajemnie elementy realizuj za o ony proces biznesowy(logika biznesu);

czy infrastruktura techniczna zapewnia optymalne warunki pracydla skomplikowanego systemu (wielomodu owego);

czy nie ma luk w logice biznesu, tj. czy nie ujawni y si problemy i/lub potrzeby,które nie zosta y przewidziane na etapie projektowania rozwi zania.

Prace integracyjne rozpoczynaj si ju w momencie czenia kodu dwóch lub wi cejmodu ów tej samej aplikacji (integracja wewn trzna). Owe komponenty mog byprzygotowane przez zupe nie niezale nych programistów, a finalnie podlegaj integra-cji. Nadmienione elementy mog w mniejszym lub wi kszym stopniu ulega integra-cji. Rol testera jest zweryfikowanie relacji pomi dzy nimi. Zdarza si , i programistatkwi w przekonaniu, e integrowane elementy maj ladowy wp yw na prac pozo-sta ych fragmentów kodu. Niemniej jednak w uj ciu ca o ciowym b d w jednym z nichpowa nie rzutuje na prac ca ego systemu. Iluzoryczne przekonanie o nik ej zale no-ci lub wr cz przezroczysto ci kodu integrowanego z dotychczasowymi funkcjonal-

no ciami aplikacji bywa zgubne w skutkach. Takowe prace nale y podejmowa jaknajbli ej kodu, tj. na etapie prac programistycznych i testów wewn trznych. Rysunek 2.2przedstawia szkolny schemat blokowy modu ów jednej aplikacji. Programista X przy-gotowa blok B. Chc c wykona jego testy, musi zintegrowa go z blokiem A lub za-symulowa jego dzia anie. Programista Y wykona blok A, który z za o enia ma pra-cowa z blokami B i C. Modu owe testy integracyjne polegaj na czeniu ze sobfragmentów kodu, które wchodz w bezpo redni interakcj . Programista lub tester




Rysunek 2.2.Schemat wzajemnegooddzia ywania blokówjednej aplikacji

uruchomi blok A i sprawdzi, czy to, co „wysy a” do elementu C, jest poprawne. Inte-gruj c bloki A, B i C, weryfikujemy ich wzajemn kooperacj , mimo i nie realizujone pe nej funkcjonalno ci z punktu widzenia u ytkownika ko cowego.

Kolejnym momentem w procesie produkcji oprogramowania, w którym wykonywanes testy integracyjne, jest zestawianie odr bnych modu ów na etapie weryfikacji funkcjo-nalnej. Jest to arcyciekawa sytuacja z uwagi na to, i kod odpowiadaj cy za odr bnefazy obs ugi biznesu mo e by zrealizowany przez zupe nie niezale ne podmioty.Zwykle jako podstawa do przygotowania „wtyczki” dla obcego systemu musi wystar-czy dokumentacja dostarczona przez potencjalnego integratora, tj. klienta, który b -dzie „spina wszystko w ca o ”. Nadmieniony materia mo e zawiera definicj pli-ków wymiany danych (np. TXT, XML, CSV itp.), opis us ugi sieciowej, np. WSDL,schemat udost pnionych obiektów na bazie danych w postaci perspektyw, przyk adywywo ania upublicznionych procedur etc. Niezale nie od wybranego rozwi zania do-st p do niego bywa znacznie utrudniony lub wr cz niemo liwy. Oczywi cie owa sy-tuacja ju na etapie kodowania stanowi powa ne perturbacje, lecz prawdziwe trudno-ci ujawniaj si dopiero w momencie testów jako ciowych.

Rozwa my hipotetyczn sytuacj w oparciu o rysunek 2.3. Pe ny proces biznesowywymaga zaanga owania trzech aplikacji. Testy integracyjne b d odbywa y si na stykuproduktu C i B oraz B i A. Biznes (funkcjonalno ) natomiast b dzie weryfikowanyprzy u yciu wszystkich bloków A, B oraz C. Aplikacja C stanowi graficzny interfejsu ytkownika, posiadaj cy nik logik biznesow , a zarazem bardzo rozbudowanemo liwo ci prezentacji i obs ugi danych. G ówny mechanizm realizacji zadanego bizne-su spoczywa na programie B. Tym niemniej mog wyst pi sytuacje, w których podsys-tem B b dzie musia posi kowa si wsparciem programu A. Reasumuj c, w realizacjlogiki mog by zaanga owane bloki B oraz A. Natomiast aplikacja C jest inicjatoremprzetwarzania, a zarazem konsumentem wyniku, tj. prezentacji rezultatu. Systemyo z o onej architekturze najcz ciej poddawane s realnej próbie dopiero w rodowi-sku testowym zamawiaj cego. Odbiorca oprogramowania ma przewag nad wykonaw-cami poszczególnych komponentów w postaci nieskr powanego dost pu do wszyst-kich elementów. Drug kwesti jest pos ugiwanie si danymi bardzo zbli onymi dorzeczywistych np. poprzez w czenie w proces testowania kopii bazy z produkcji. Po-wy sze zabiegi urealniaj testy funkcjonalne (pe nego biznesu) poprzez pos ugiwaniesi niemal e faktycznymi danymi zgromadzonymi w du ym wolumenie. Obs uga pe nego




Rysunek 2.3.Schemat interakcjitrzech niezale nychaplikacji

procesu biznesowego w fazie prac integracyjnych lub ostatecznych testów odbior-czych mo e ujawni luki w opracowanej koncepcji. Zdarza si , i w wyniku testówzidentyfikowane s problemy, które nie by y przewidziane w projekcie. Owe problemymog prze o y si na zmian rozwi zania. Dok adniej rzecz ujmuj c: na jego dopra-cowanie, na przyk ad poprzez dopisanie drobnych funkcjonalno ci, modyfikacj za o ewst pnych etc. Testy integracyjne stanowi pierwszy etap weryfikacji, czy przyj terozwi zanie oraz jego implementacja zaspakajaj potrzeby biznesowe (w ca o ciowymuj ciu procesu).

Pierwszym, a zarazem najmniej k opotliwym scenariuszem jest integrowanie modu ów(ca ych programów), które wykonane s przez jednego producenta. W teorii wskaza-ne testy powinny by wykonane bez wi kszych problemów, a ewentualne przeszkodyw postaci b dów w implementacji lub niejasno ci w dokumentacji rozwi zane wewn trzorganizacji. Praktyka dowidzi, i niestety równie ten scenariusz naznaczony jestpewnymi zak óceniami w trakcie realizacji projektu testowego. Wynika to g ówniez organizacji pracy oraz nie do ko ca jasnej i zdrowej rywalizacji pomi dzy zespo amiwewn trz korporacji. Wskaza em korporacj , gdy poj cie klienta zewn trznego orazwewn trznego jest szeroko stosowane w du ych przedsi biorstwach. Poj cie samo w so-bie nie kryje niczego z ego, aczkolwiek zauwa alne s problemy w relacjach pomi dzyzespo ami wynikaj ce z zawi ej, a bywa, e i naci ganej interpretacji tego terminu.Generalnie idealizuj c, mo na przyj , i funkcjonuj ce procedury formalne w pe nizabezpieczaj potrzeb kooperacji ró nych zespo ów w celu osi gni cia ostatecznegorezultatu.

Nieco mniej przyjemn sytuacj jest nieposiadanie jednego lub wi cej komponentów„na w asno ”, kiedy s one udost pnione grzeczno ciowo przez klienta. Jest to sto-sunkowo dobre rozwi zanie, aczkolwiek uzale nione od dobrej woli wspó pracy. Pewn




trudno ci dla procesu integracji mog by ewentualne niedoci gni cia w kodzie podrugiej stronie, ale w a nie po to si wykonuje testy integracji, aby owe problemywyeliminowa . Generalnie „my” czy partner po przeciwnej stronie musimy czeka naewentualne modyfikacje kodu w celu kontynuowania procesu integracji. Niemniejjednak jest to dobra droga. Wymaga ona zaanga owania zasobów klienta jako po red-nika, lecz uzyskujemy warto dodan w postaci wczesnego rozminowania pola. Bujnawyobra nia podpowiada, co mo e si sta , je eli podejmiemy prób zintegrowaniadwóch programów bez wcze niejszego „docierania” ich razem.

Najtrudniejsz sytuacj jest konieczno wyprodukowania modu u klienckiego do obce-go systemu bez dost pu do tego zasobu. Zaiste gros trudno ci ujawni si w momen-cie uruchamiania kodu i testów funkcjonalnych. Du o zale y od roli, jak dla testowanejfunkcjonalno ci pe ni zewn trzny system. Bywa, i brak dost pu do drugiego pro-gramu w minimalnym stopniu ograniczy testy. Bywa równie , i zupe nie je unie-mo liwi. Za ó my, i testowana funkcjonalno realizuje jaki biznes zdefiniowanyw 10 logicznych krokach, gdzie kroki 2., 5. oraz 8. wymagaj po czenia z us ug sie-ciow w celu pobrania/przeliczenia jakich danych. W takich okoliczno ciach przete-stujemy tylko krok nr 1. Drugi ju wymaga interakcji z web service (WS). W tymmomencie wyklarowa a si potrzeba za lepienia wywo ywanej metody WS przez naszaplikacj , tak aby mog a ona przej do kroku nr 3 itd. Trzeba wyprodukowa symu-lator systemu zewn trznego. Temat za lepiania da do zewn trznych aplikacji b dzieomówiony szerzej w dalszej cz ci ksi ki.

Do typowych problemów (b dów) wykrywanych w procesie integracji nale y zaliczy :

Niespójno wysy anego schematu XML z oczekiwaniami klienta lub serweranp. w wyniku przygotowania klienta WS w oparciu o nieaktualny opis us ugi(WSDL) lub b d w kodzie.

Tre danych przekazywana w pliku wymiany danych zawiera znaki specjalne,na które negatywnie reaguje druga aplikacja. Przyk adowa nazwa jakiejorganizacji, fundacji mo e zawiera cudzys ów, który eksportowany jestdo tre ci pola. Dokumentacja opisuj ca pliki wymiany mo e nie opisywaszczegó ów lub wyj tków.

Zderzenie dwóch technologii lub nawet ró nych wersji tych samych serwerówmo e powodowa problemy natury integracyjnej.

Bywaj sytuacje, i w jakich okoliczno ciach jedna ze stron b dzie przekracza aczas odpowiedzi na danie (ang. time out).

Wyobrazi mo na sobie sytuacj , e obrót danymi odbywa si za pomoc plikuwymiany danych, w którym koniec linii ustalony jest na znak LF, a w wynikupo redniego dzia ania jakiego programiku, który kopiuje plik z miejsca A do B,zajdzie niejawna konwersja znaku ko ca linii na CRLF. Próba odczytania takiegozbioru zako czy si niepowodzeniem. Czy taki scenariusz mo na przewidziew testach funkcjonalnych? W praktyce jedna aplikacja wygeneruje poprawnie LF,a druga poprawnie odrzuci znak CRLF. Gdzie jest b d?! Mo e w jakim„starym” programiku, którego nie brali my pod uwag na etapie testów?




Testy integracyjne stanowi dobr okazj do masowego wczytywania plików,wymiany danych przez funkcje WS itp. Bywa, i b dy, np. przepe nieniebufora, przekroczenie zakresu zmiennej itp., ujawniaj si dopiero przy„ogromnej” ilo ci danych.

Integracja systemu ujawnia wszelkie ró nice w rozumieniu funkcji, jakie mape ni ka dy z elementów, w tym po której stronie maj by obs ugiwaneokre lone wyj tki.

Luki w opracowanej koncepcji rozwi zania, na podstawie której by a wykonanaimplementacja.

Wiele innych problemów…

2.3. Testy systemowePrzedmiotem testów systemowych jest ca a aplikacja lub jej samodzielny fragment,który znajduje odwzorowanie w projekcie, tj. wchodzi w zakres projektu. Najodpo-wiedniejsz form testów funkcjonalnych jest zastosowanie techniki czarnoskrzynko-wej. Niemniej jednak technika bia ej skrzynki z powodzeniem mo e by wykorzystywa-na jako uzupe nienie g ównego w tku testów. Kluczem do sukcesu jest prowadzenietestów w rodowisku testowym jak najbardziej zbli onym do produkcyjnych warun-ków funkcjonowania aplikacji. Weryfikacja aplikacji w warunkach mo liwie wiernieodwzorowuj cych docelowe rodowisko pracy zmniejsza ryzyko przeoczenia b dówi problemów, które mog wynika z ró nic w specyfice obu rodowisk. Wi cej infor-macji na temat rodowiska testów znajduje si w rozdziale po wi conym owej tema-tyce w niniejszej ksi ce.

Równie istotne jest to, kto wykonuje testy systemowe. Najlepiej by oby, aby czyni toniezale ny zespó testerów, tzn. taki, który zachowuje du autonomiczno wobeczespo u programistycznego w aspekcie rodowiska testów oraz zasobów ludzkich.

Testy systemowe (ang. system testing) winny ujmowa wymagania zarówno niefunk-cjonalne, jak i funkcjonalne. Jest to faza, w której ocenia si globalnie produkt beznadmiernego nacisku na zg bianie wewn trznej architektury i instrukcji kodu aplikacji.

Testy systemowe odnosz si do aplikacji w uj ciu ca o ciowym. Oznacza to, i zo-bowi zani jeste my do weryfikacji wszystkich funkcji wraz z analiz korelacji po-mi dzy nimi. Za ó my, i otrzymali my do testów aplikacj lub nowy modu , któryadministruje fakturami VAT. Testy systemowe wymagaj zweryfikowania wszystkichcie ek obs ugi owego dokumentu, m.in. wystawienia FV, korekty, wydruku, filtro-

wania, generowania do pliku PDF, akceptacji etc.

Tego rodzaju testy mog ujawni potrzeb zastosowania za lepek lub symulatorówzewn trznych systemów, z którymi nasza aplikacja b dzie wchodzi we wspó zale -no lub wyst powa jedynie jako klient.

Specyfika i zakres testów systemowych stawia ten rodzaj weryfikacji w roli bardzodobrego kandydata do automatyzacji czynno ci (testów).




Testy systemowe to:

testy funkcjonalne,

testy wydajno ciowe,

testy regresywne,

testy ergonomii,

testy instalacji,

testy bezpiecze stwa.

2.4. Testy akceptacyjneTesty odbiorcze wykonywane s bezpo rednio przez zamawiaj cego w oparciu o w asnezasoby lub poprzez zlecenie prac niezale nemu zespo owi testerskiemu. Testy te majpotwierdzi zgodno weryfikowanego produktu z zapisami w umowie i obowi zuj -cymi przepisami prawa. Celem testów akceptacyjnych jest weryfikacja i potwierdzenie,czy wszystkie zapisy w kontrakcie zosta y zrealizowane w sposób zaspokajaj cy ocze-kiwania. Pozytywne zamkni cie fazy testów odbiorczych stanowi podstaw do finan-sowego rozliczenia kontraktu. Testy akceptacyjne winny odnosi si do formalniespisanych kryteriów odbioru oprogramowania. Wspomniane kryteria zwykle uzgad-niane s na etapie negocjacji kontraktu. Nadmieniona powy ej sytuacja odnosi si dooprogramowania pisanego na zamówienie.

Nieco inaczej kreuje si sytuacja dla aplikacji „pude kowych”. Oprogramowaniez pó ki mo e by poddane dwóm typom testów akceptacyjnych: alfa i beta. Testy alfawykonywane s wewn trz organizacji, która wyprodukowa a oprogramowanie, aczkol-wiek weryfikacji dokonuje niezale ny zespó , tj. zespó , który nie bra udzia u w pro-cesie wytwarzania. Betatesty realizowane s poza organizacj wykonuj c kod przezgrup u ytkowników docelowych. Firmy produkuj ce oprogramowanie pude kowe sywo zainteresowane uzyskaniem informacji zwrotnej (potwierdzeniem) o wysokiej

jako ci w asnego produktu przed oficjalnym wprowadzeniem go na rynek.

Niezale nie od typu oprogramowania (pude kowe, na zamówienie) winno ono równieby poddane testom akceptacyjnym w aspekcie obowi zuj cych przepisów prawa.



SkorowidzA

administracja rodowiskiem testów, 27adres URL, 109adresowanie IP, 180algorytm SHA, 188algorytmy walidacyjne, 33analizator ruchu sieciowego, 195API, Application Programming Interface, 76architektura wielowarstwowa, 36arkusze kalkulacyjne, 52atak

Blind SQL-Injection, 102, 103SQL-Injection, 96, 99, 104typu XSS, 93

autodiagnoza, 161automatyzacja testów, 183

Bbaza danych, 76bezpiecze stwo, 92Blind SQL-Injection, 102, 103blokowanie spamu, 92b d, 11

etap symulacji, 29potencjalne przyczyny, 30replikacja, 29

b dna obs uga wyj tku, 44b dy

blokuj ce, 12krytyczne, 12projektowe, 145sterownika JDBC, 77wewn trzne, 42w koncepcji, 145w operacji mno enia, 141w procesie integracji, 70zewn trzne, 40

Ccertyfikat ISTQB, 58cykl ycia oprogramowania, 62czas wykonania zapytania, 83, 85

Ddebugowanie, 12dokumentacja, 13dokumentowanie testów, 34do wiadczenie testera, 140drzewo

MockService, 174wyników, 83

Eedytory tekstu, 52emulatory, 52ergonomia

komunikatów walidacyjnych, 121przycisków akcji, 122systemów informatycznych, 122

Ffiltrowanie danych, 97formularz do adowania telefonu, 94, 107funkcja zwracaj ca wersj , 36

Ggenerator

danych, 32danych testowych, 197, 200

CSV, 201, 203SQL, 201XML, 201




generatorcertyfikatów SSL, 51MockService, 173sumy kontrolnej, 51, 187

GIT, 35graf przep ywu sterowania, 138, 139GUI, 15GUI dgMaster, 205

IICT, Information and Communication

Technologies, 92IEEE, 13implementacja monitora TCP, 178informacja o znaku ko ca linii, 187informacje

o nazwie serwera, 113o systemie, 111o wersji serwera, 113zwrotne, 18

instrukcjaIF, 15instrukcja INSERT INTO, 80

intensywno testów, 53interfejs u ytkownika, 15interpretacja projektu, 149

Jjako oprogramowania, 17, 20, 63, 163JDBC, 80j zyk

WADL, 166WSDL, 166

Kklauzula UNION, 99, 100klient

MockService, 176us ugi sieciowej, 165

kod JavaScript, 95kodowanie znaków, 52konfiguracja

nas uchu, 178nowej instrukcji, 85po czenia JDBC, 79programu Fiddler, 114TCPMon, 180testu dla aplikacji, 87zapytania SQL, 80

dania, 88

kontrolajako ci, 46, 52wersji oprogramowania, 35

krok po redni, 109kryterium ilo ciowe, 17

Llogowanie b dów, 45, 50

MManifest Zwinnego Wytwarzania

Oprogramowania, 64mened er plików, 51metoda

bia ej skrzynki, 14czarnej skrzynki, 13

metodyki zwinne, 64metryka pakietu Oracle, 37miara jako ci oprogramowania, 17migracja danych, 48model

kaskadowy, 63V, 64

modyfikacjakodu, 115kodu formularza, 117tre ci strony, 112

monitor TCP, 177monitorowanie jako ci, 21

Nnag ówek HTTP, 113narz dzia automatyzacji testów, 52, 186narz dzie

Apache JMeter, 51, 52, 199Apache TCPMon, 177, 178, 180, 181dgMaster, 203Eclipse, 51Fiddler, 105–108, 111–117Fiddler2, 51Firebug, 51, 106JMeter, 76–90KeyStore Explorer, 51Membrane Monitor, 51Membrane SOAP Monitor, 189–93NetBeans IDE, 51Notepad++, 51Oracle OpenScript, 52PL/SQL Developer, 51PuTTY, 51Selenium, 52



Skorowidz 211

SoapUI, 51, 165–176, 180Spawner Data Generator, 203TCPMon, 51Total Commander, 51VNC, 51WebScarab, 105WinSCP, 51Wireshark, 51, 195, 196

Oobs uga

b dów wewn trznych, 42b dów zewn trznych, 40wyj tków, 43zg osze , 39

ogólna teoria testowania, 11opis kodu ród owego, 38oprogramowanie

Bugzilla, 39JIRA, 39Mantis Bug Tracker, 39SVN, 35

Pplik wynikowy CSV, 203podgl d odpowiedzi, 114podmienianie warto ci, 105polecenie DESC, 96porty, 180poziomy wykonywania testów, 65presja czasu, 151procentowy rozk ad zg osze , 21proces

integracji, 70obs ugi b dów, 40, 42testowania, 149

projekt REST, 170projektowanie testu, 129

do wiadczenie testera, 140technika bia ej skrzynki, 136technika czarnej skrzynki, 131

protokó REST, 168przebieg

realizacji projektu, 9, 53rejestracji b dów, 22, 23

przechwycenie sesji, 108przej cia pomi dzy stanami, 134przekazywanie zmian w kodzie, 39przyczyny

b dów, 30zniech cenia, 156

przypadek testowy, 12przypadki u ycia, 135

Rrealizacja projektu, 60regu y odpowiedzi, 175rejestracja b dów, 22, 23rekonesans, 111replikacja b dów, 28REST, Representational State Transfer, 165retest, 11równomierne obci enie prac , 54

Sscenariusz testów, 13serwer poczty, 52SHA, Secure Hash Algorithm, 188skrypt JS, 95skutki zniech cenia, 159SOAP, Simple Object Access Protocol, 165specyfikacja, 13spójno nazewnictwa, 121SQL-Injection, 96, 99, 104SSL, Secure Socket Layer, 166standardy, 13Subversion, SVN, 35suma kontrolna, checksum, 187sygnatura wersji, 103symulacja b du, 29symulator

aplikacji, 31serwera us ug sieciowych, 171

syndrom zniech cenia, 153system kontroli wersji, 35

GIT, 35Subversion, 35

rodowiskodeweloperskie, 30produkcyjne, 25testów, 23, 27, 28

Ttabela, 81technika

bia ej skrzynki, 136czarnej skrzynki

przej cia pomi dzy stanami, 134przypadki u ycia, 135warto ci brzegowe, 131

techniki testowania, 13




teoria testowania, 11tester oprogramowania, 54

aspekty psychologiczne, 149syndrom zniech cenia, 153

testowanieaplikacji internetowej, 86bazy danych, 76bezpiecze stwa aplikacji, 91ergonomii systemu informatycznego, 118instalacji, 117instrukcji, 136migracji danych, 47obs ugi wyj tków, 43przej pomi dzy stanami, 134przeno no ci kodu, 117us ug sieciowych, 89, 165

testyakceptacyjne, 72decyzyjne, 138funkcjonalne, 73ilo ciowe, 197integracyjne, 67jako ciowe, 8modu owe, 66niefunkcjonalne, 74obci eniowe, 75przeci eniowe, 75regresywne, 125systemowe, 71

bezpiecze stwa, 72ergonomii, 72funkcjonalne, 71instalacji, 72regresywne, 72wydajno ciowe, 71

w cyklu ycia oprogramowania, 62w oknie czasu, 58wewn trzne, 8wydajno ci, 74, 76

trywialno wykrycia b du, 12tworzenie symulatora WS, 172typy testów, 73

Uus ugi sieciowe, 165

WWADL, Web Application Description

Language, 166walidacja

dopuszczalnych znaków, 144pól dla kwot, 147

walidatory, 52warto ci brzegowe, 131wersje oprogramowania, 35wra liwe informacje, 109WSDL, Web Services Description Language, 166wstrzykni cie kodu JS, 95wyj tki, 43wykres testu aplikacji, 89wy czenie cz ci kodu, 104wymaganie, 13wytwarzanie oprogramowania, 64wywo anie monitora TCP, 179wywo ywanie

funkcji MockService, 176procedury, 84

XXSS, Cross Site Scripting, 93

Zzasada kumulowania si b dów, 9zastosowanie

opcji disabled, 117ORDER BY, 102SELECT UNION, 99, 101

z amanie zasad ergonomii, 122zniech cenie, 153

przyczyny, 156skutki, 159

ród a pliku WSDL, 166ród o zmodyfikowanej strony, 116

danie REST, 171



http://program-partnerski.helion.pl

Wszelkie prawa zastrzeżone. Nieautoryzowane ...68 Testowanie oprogramowania. Podröcznik dla...

Documents

Transcript of Wszelkie prawa zastrzeżone. Nieautoryzowane ...68 Testowanie oprogramowania. Podröcznik dla...