Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00080 021204 17030817 na godz. na dobę w sumie
Testowanie oprogramowania. Podręcznik dla początkujących - ebook/pdf
Testowanie oprogramowania. Podręcznik dla początkujących - ebook/pdf
Autor: Liczba stron: 216
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-0139-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook, audiobook).

Testuj programy i śpij spokojnie!

Testowanie oprogramowania jest niesłychanie ważnym czynnikiem, wręcz decydującym o sukcesie lub porażce systemu, aplikacji czy sieci. Bezlitośni użytkownicy wykryją najdrobniejszy błąd, skutkujący choćby niewielkim spowolnieniem działania programu… i nie omieszkają wyrazić swojej opinii w internecie. Jeśli chcesz uniknąć takich niespodzianek, a ponadto zależy Ci na jak najszybszym ukończeniu realizowanego projektu i wypuszczeniu perfekcyjnego produktu, musisz natychmiast zacząć go testować!

Ta książka pomoże Ci zorientować się w metodach i technikach testowania. Jej autor, praktyk z wieloletnim doświadczeniem, zawarł w niej informacje o narzędziach i procesach, opisał również własne doświadczenia związane z konkretnymi projektami. Dowiesz się między innymi, jak radzić sobie na kolejnych etapach weryfikacji jakości oprogramowania — wybrać odpowiedni typ testu i przejść przez proces jego projektowania — a także jak uporać się ze znużeniem nieustannym testowaniem. Odkryjesz też, do czego służy automatyzacja i jak przejrzyście dokumentować całe przedsięwzięcie. Usuń błędy, zanim zaczną sprawiać Ci kłopoty!

Postaw na jakość! To się opłaca! 

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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: helion@helion.pl 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 Moż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ść Spis tre(cid:264)ci Przedmowa ......................................................................................................... 5 Wst(cid:246)p ................................................................................................................. 7 Rozdzia(cid:228) 1. Ogólna teoria testowania ................................................................. 11 1.1. Techniki testowania ................................................................................................. 13 1.2. Miara jako(cid:286)ci oprogramowania ............................................................................... 17 1.3. (cid:285)rodowisko testowe i produkcyjne .......................................................................... 23 1.4. Replikacja b(cid:225)(cid:266)dów ................................................................................................... 28 1.5. U mnie b(cid:225)(cid:261)d nie wyst(cid:266)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(cid:225)uga zg(cid:225)osze(cid:276) ..................................................................................................... 39 1.10. Testowanie obs(cid:225)ugi wyj(cid:261)tków w kodzie ................................................................ 43 1.11. Narz(cid:266)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(cid:261)da realizacja projektu w praktyce? ......................................................... 60 1.16. Testowanie w cyklu (cid:298)ycia oprogramowania .......................................................... 62 Rozdzia(cid:228) 2. Poziomy wykonywania testów .......................................................... 65 2.1. Testy modu(cid:225)owe ...................................................................................................... 66 2.2. Testy integracyjne .................................................................................................... 67 2.3. Testy systemowe ...................................................................................................... 71 2.4. Testy akceptacyjne .................................................................................................. 72 Rozdzia(cid:228) 3. Typy testów ..................................................................................... 73 3.1. Testy funkcjonalne .................................................................................................. 73 3.2. Testy niefunkcjonalne .............................................................................................. 74 3.2.1. Testy wydajno(cid:286)ci ............................................................................................ 74 3.2.2. Testy bezpiecze(cid:276)stwa aplikacji ...................................................................... 91 3.2.3. Testy przeno(cid:286)no(cid:286)ci kodu — testy instalacji .................................................. 117 3.2.4. Testy ergonomii systemu informatycznego .................................................. 118 3.3. Testy regresywne ................................................................................................... 125 Kup książkęPoleć książkę 4 Testowanie oprogramowania. Podr(cid:246)cznik dla pocz(cid:241)tkuj(cid:241)cych Rozdzia(cid:228) 4. Wprowadzenie do projektowania testów ......................................... 129 4.1. Projektowanie testu w oparciu o technik(cid:266) czarnej skrzynki ................................... 131 4.1.1. Warto(cid:286)ci brzegowe ....................................................................................... 131 4.1.2. Przej(cid:286)cia pomi(cid:266)dzy stanami .......................................................................... 134 4.1.3. Projektowanie testu w oparciu o przypadki u(cid:298)ycia ....................................... 135 4.2. Projektowanie testu w oparciu o technik(cid:266) bia(cid:225)ej skrzynki ..................................... 136 4.3. Projektowanie testu w oparciu o do(cid:286)wiadczenie testera ........................................ 140 4.4. Przypadki testowe w uj(cid:266)ciu praktycznym ............................................................... 140 Rozdzia(cid:228) 5. Psychologiczne aspekty procesu testowania ................................... 149 Rozdzia(cid:228) 6. Syndrom zniech(cid:246)cenia testami ....................................................... 153 Rozdzia(cid:228) 7. Testowanie us(cid:228)ug sieciowych ......................................................... 165 7.1. Narz(cid:266)dzie SoapUI — klient us(cid:225)ugi sieciowej ........................................................ 165 7.2. Symulator serwera us(cid:225)ug sieciowych — SoapUI Mock Services .......................... 171 7.3. Monitor TCP — Apache TCPMon ........................................................................ 177 Rozdzia(cid:228) 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 Kup książkęPoleć książkę Rozdzia(cid:228) 2. Poziomy wykonywania testów Proces wytwarzania oprogramowania podzielony jest na fazy, w których wykonuje si(cid:266) specyficzne dla ka(cid:298)dego z etapów testy. Testy dzieli si(cid:266) na poziomy: (cid:141) testy modu(cid:225)owe (jednostkowe), (cid:141) testy integracyjne wewn(cid:266)trzne, (cid:141) testy systemowe, (cid:141) testy integracyjne zewn(cid:266)trzne, (cid:141) testy akceptacyjne (odbiorcze). Rysunek 2.1 przedstawia piramid(cid:266) poziomu testów. Testy wykonywane s(cid:261) zgodnie z oddoln(cid:261) interpretacj(cid:261) infografiki, tj. od testów modu(cid:225)owych a(cid:298) po testy akceptacyjne. Rysunek 2.1. Piramida poziomu testów Kup książkęPoleć książkę 66 Testowanie oprogramowania. Podr(cid:246)cznik dla pocz(cid:241)tkuj(cid:241)cych 2.1. Testy modu(cid:228)owe Testy modu(cid:225)owe wykonuje si(cid:266) na etapie wytwarzania kodu. Uczestnikami tego ro- dzaju testów s(cid:261) najcz(cid:266)(cid:286)ciej programi(cid:286)ci, którzy w fazie implementacji poddaj(cid:261) weryfika- cji w(cid:225)asny kod. Wspomniane testy musz(cid:261) odnosi(cid:252) si(cid:266) do niewielkich i (cid:286)ci(cid:286)le wyizolowa- nych fragmentów kodu. Polegaj(cid:261) one na wykonywaniu wybranego fragmentu instrukcji w celu zweryfikowania, czy realizuje ona swoj(cid:261) funkcj(cid:266) zgodnie z za(cid:225)o(cid:298)eniami. Pro- gramista przygotowa(cid:225) metod(cid:266), która konwertuje numer NRB (Numer Rachunku Ban- kowego) na IBAN (ang. International Bank Account Number — pol. Mi(cid:266)dzynarodowy Numer Rachunku Bankowego). Wspomniana metoda b(cid:266)dzie wielokrotnie u(cid:298)ywana w ró(cid:298)nych miejscach systemu. Test modu(cid:225)owy polega(cid:252) b(cid:266)dzie na wywo(cid:225)ywaniu owej metody z podaniem jako parametru wej(cid:286)ciowego numeru NRB i weryfikacji otrzyma- nego wyniku. Wywo(cid:225)anie metody mo(cid:298)e odbywa(cid:252) si(cid:266) z poziomu (cid:286)rodowiska deweloper- skiego bez zastosowania GUI. Na tym koniec. Testy modu(cid:225)owe powinny odnosi(cid:252) si(cid:266) do ma(cid:225)ych podmiotów, a ich wynik powinien by(cid:252) zale(cid:298)ny od innych elementów, które potencjalnie maj(cid:261) znale(cid:296)(cid:252) si(cid:266) w gotowej aplikacji. Testy modu(cid:225)owe nie powinny wnika(cid:252) w szczegó(cid:225)y procesu biznesowego. Analizie i ocenie podlega jedynie ma(cid:225)y i wyizolowa- ny fragment kodu. W przypadku kiedy nabierzemy zaufania do testowanych frag- mentów kodu, mo(cid:298)emy rozpocz(cid:261)(cid:252) sk(cid:225)adanie ich do postaci gotowego produktu lub wi(cid:266)kszego komponentu. Testy modu(cid:225)owe wykonuje si(cid:266) zwykle w (cid:286)rodowisku deweloperskim z dost(cid:266)pem do kodu (cid:296)ród(cid:225)owego. Wymaga to od testera — o ile nie jest programist(cid:261) — umiej(cid:266)tno(cid:286)ci czytania i wykonywania kodu oraz pisania w(cid:225)asnych skryptów (fragmentów kodu). By- wa, i(cid:298) przetestowanie pewnego modu(cid:225)u wymaga zaanga(cid:298)owania elementów pobocznych, np. symulatora us(cid:225)ugi sieciowej. Dlaczego nale(cid:298)y wykonywa(cid:252) testy modu(cid:225)owe? B(cid:225)(cid:266)dy wykryte we wczesnej fazie produkcji oprogramowania kosztuj(cid:261) znacznie mniej ani(cid:298)eli poprawa oraz usuwanie ich skutków w kolejnych fazach wytwarzania lub u(cid:298)ytkowania produkcyjnego aplikacji. Wykryte problemy usuwane s(cid:261) natychmiast, przez co minimalizuje si(cid:266) ryzyko propagacji negatywnego wp(cid:225)ywu wadliwego kodu na pozosta(cid:225)e modu(cid:225)y np. poprzez odziedziczenie wady. B(cid:225)(cid:266)dy wykryte w tej fazie zwykle nie znajduj(cid:261) odzwierciedlenia w postaci formalnego zg(cid:225)oszenia, co przyspiesza udo- skonalanie kodu i nie niesie ze sob(cid:261) ryzyka krytycznych uwag osób trzecich. Jest to bardzo bezpieczna i efektywna forma testów w(cid:225)asnego kodu. Kompilator nie weryfikuje intencji programisty. Zatem pomimo i(cid:298) kod zosta(cid:225) skompilowany, nie mo(cid:298)na go uzna(cid:252) za poprawny bez przeprowadzenia testu jednostkowego. Od(cid:225)o(cid:298)enie procesu testowania do momentu z(cid:225)o(cid:298)enia w ca(cid:225)o(cid:286)(cid:252) wszystkich elementów niesie ze sob(cid:261) znaczne ryzyko, i(cid:298) nie uda si(cid:266) uruchomi(cid:252) aplikacji lub pewnych funkcjonalno(cid:286)ci za pierwszym razem. B(cid:225)(cid:266)dy, które zostan(cid:261) ujawnione, mog(cid:261) mie(cid:252) przyczyn(cid:266) g(cid:225)(cid:266)boko ukryt(cid:261) w kodzie. Prze- szukiwanie „rozdmuchanych” (cid:296)róde(cid:225) w celu wyizolowania przyczyny problemu b(cid:266)dzie czasoch(cid:225)onne i zapewne irytuj(cid:261)ce. Testy modu(cid:225)owe pozwalaj(cid:261) na wyeliminowanie ty- powych problemów w podstawowej (cid:286)cie(cid:298)ce obs(cid:225)ugi systemu. Im mniej problemów zostanie przeniesionych z fazy implementacji do fazy formalnych testów, tym szybciej gotowy produkt zostanie przekazany do odbiorcy, a jego jako(cid:286)(cid:252) wzro(cid:286)nie. Kup książkęPoleć książkę Rozdzia(cid:228) 2. (cid:105) Poziomy wykonywania testów 67 2.2. Testy integracyjne U podstaw testów integracyjnych le(cid:298)y opieranie jednego procesu biznesowego na wielu ró(cid:298)nych systemach, podsystemach i aplikacjach. Heterogeniczno(cid:286)(cid:252) ostatecznie ofero- wanego u(cid:298)ytkownikowi ko(cid:276)cowemu rozwi(cid:261)zania wymusza przeprowadzenie pe(cid:225)nego testu biznesu w oparciu o scalone (cid:286)rodowisko. Aby by(cid:225)o to mo(cid:298)liwe, uprzednio nale(cid:298)y zweryfikowa(cid:252) interakcj(cid:266) pomi(cid:266)dzy poszczególnymi modu(cid:225)ami. Zwie(cid:276)czenie sukce- sem owych prac stanowi podstaw(cid:266) do traktowania wszystkich modu(cid:225)ów jako jeden system. Niezachwiane przekonanie o spójno(cid:286)ci systemu otwiera drog(cid:266) do pe(cid:225)nych testów funkcjonalnych w ca(cid:225)o(cid:286)ciowym uj(cid:266)ciu obs(cid:225)ugi biznesu. Testy integracyjne to szczególny rodzaj dzia(cid:225)a(cid:276) podejmowanych w celu zbadania ko- operacji oraz wzajemnego oddzia(cid:225)ywania dwóch lub wi(cid:266)cej modu(cid:225)ów systemu. Przez desygnat „modu(cid:225)” nale(cid:298)y rozumie(cid:252) zupe(cid:225)nie autonomiczny produkt lub fragment kodu, który ostatecznie jest (cid:286)ci(cid:286)le spojony z g(cid:225)ówn(cid:261) architektur(cid:261) systemu. Testy integracyjne maj(cid:261) wykaza(cid:252): (cid:141) czy modu(cid:225)y poprawnie wspó(cid:225)pracuj(cid:261), tj. czy nie wyst(cid:261)pi(cid:225)y przeszkody natury technologicznej oraz czy wzajemnie (cid:286)wiadczone us(cid:225)ugi spe(cid:225)niaj(cid:261) oczekiwania (logika); (cid:141) jak zachowuj(cid:261) si(cid:266) poszczególne elementy w sytuacji awarii, b(cid:225)(cid:266)dów lub niestabilnej pracy w przypadku dysfunkcji jednego z nich (wzajemne oddzia(cid:225)ywanie); (cid:141) czy kojarzone wzajemnie elementy realizuj(cid:261) za(cid:225)o(cid:298)ony proces biznesowy (logika biznesu); (cid:141) czy infrastruktura techniczna zapewnia optymalne warunki pracy dla skomplikowanego systemu (wielomodu(cid:225)owego); (cid:141) czy nie ma luk w logice biznesu, tj. czy nie ujawni(cid:225)y si(cid:266) problemy i/lub potrzeby, które nie zosta(cid:225)y przewidziane na etapie projektowania rozwi(cid:261)zania. Prace integracyjne rozpoczynaj(cid:261) si(cid:266) ju(cid:298) w momencie (cid:225)(cid:261)czenia kodu dwóch lub wi(cid:266)cej modu(cid:225)ów tej samej aplikacji (integracja wewn(cid:266)trzna). Owe komponenty mog(cid:261) by(cid:252) przygotowane przez zupe(cid:225)nie niezale(cid:298)nych programistów, a finalnie podlegaj(cid:261) integra- cji. Nadmienione elementy mog(cid:261) w mniejszym lub wi(cid:266)kszym stopniu ulega(cid:252) integra- cji. Rol(cid:261) testera jest zweryfikowanie relacji pomi(cid:266)dzy nimi. Zdarza si(cid:266), i(cid:298) programista tkwi w przekonaniu, (cid:298)e integrowane elementy maj(cid:261) (cid:286)ladowy wp(cid:225)yw na prac(cid:266) pozo- sta(cid:225)ych fragmentów kodu. Niemniej jednak w uj(cid:266)ciu ca(cid:225)o(cid:286)ciowym b(cid:225)(cid:261)d w jednym z nich powa(cid:298)nie rzutuje na prac(cid:266) ca(cid:225)ego systemu. Iluzoryczne przekonanie o nik(cid:225)ej zale(cid:298)no- (cid:286)ci lub wr(cid:266)cz przezroczysto(cid:286)ci kodu integrowanego z dotychczasowymi funkcjonal- no(cid:286)ciami aplikacji bywa zgubne w skutkach. Takowe prace nale(cid:298)y podejmowa(cid:252) jak najbli(cid:298)ej kodu, tj. na etapie prac programistycznych i testów wewn(cid:266)trznych. Rysunek 2.2 przedstawia szkolny schemat blokowy modu(cid:225)ów jednej aplikacji. Programista X przy- gotowa(cid:225) blok B. Chc(cid:261)c wykona(cid:252) jego testy, musi zintegrowa(cid:252) go z blokiem A lub za- symulowa(cid:252) jego dzia(cid:225)anie. Programista Y wykona(cid:225) blok A, który z za(cid:225)o(cid:298)enia ma pra- cowa(cid:252) z blokami B i C. Modu(cid:225)owe testy integracyjne polegaj(cid:261) na (cid:225)(cid:261)czeniu ze sob(cid:261) fragmentów kodu, które wchodz(cid:261) w bezpo(cid:286)redni(cid:261) interakcj(cid:266). Programista lub tester Kup książkęPoleć książkę 68 Testowanie oprogramowania. Podr(cid:246)cznik dla pocz(cid:241)tkuj(cid:241)cych Rysunek 2.2. Schemat wzajemnego oddzia(cid:225)ywania bloków jednej aplikacji uruchomi blok A i sprawdzi, czy to, co „wysy(cid:225)a” do elementu C, jest poprawne. Inte- gruj(cid:261)c bloki A, B i C, weryfikujemy ich wzajemn(cid:261) kooperacj(cid:266), mimo i(cid:298) nie realizuj(cid:261) one pe(cid:225)nej funkcjonalno(cid:286)ci z punktu widzenia u(cid:298)ytkownika ko(cid:276)cowego. Kolejnym momentem w procesie produkcji oprogramowania, w którym wykonywane s(cid:261) testy integracyjne, jest zestawianie odr(cid:266)bnych modu(cid:225)ów na etapie weryfikacji funkcjo- nalnej. Jest to arcyciekawa sytuacja z uwagi na to, i(cid:298) kod odpowiadaj(cid:261)cy za odr(cid:266)bne fazy obs(cid:225)ugi biznesu mo(cid:298)e by(cid:252) zrealizowany przez zupe(cid:225)nie niezale(cid:298)ne podmioty. Zwykle jako podstawa do przygotowania „wtyczki” dla obcego systemu musi wystar- czy(cid:252) dokumentacja dostarczona przez potencjalnego integratora, tj. klienta, który b(cid:266)- dzie „spina(cid:225) wszystko w ca(cid:225)o(cid:286)(cid:252)”. Nadmieniony materia(cid:225) mo(cid:298)e zawiera(cid:252) definicj(cid:266) pli- ków wymiany danych (np. TXT, XML, CSV itp.), opis us(cid:225)ugi sieciowej, np. WSDL, schemat udost(cid:266)pnionych obiektów na bazie danych w postaci perspektyw, przyk(cid:225)ady wywo(cid:225)ania upublicznionych procedur etc. Niezale(cid:298)nie od wybranego rozwi(cid:261)zania do- st(cid:266)p do niego bywa znacznie utrudniony lub wr(cid:266)cz niemo(cid:298)liwy. Oczywi(cid:286)cie owa sy- tuacja ju(cid:298) na etapie kodowania stanowi powa(cid:298)ne perturbacje, lecz prawdziwe trudno- (cid:286)ci ujawniaj(cid:261) si(cid:266) dopiero w momencie testów jako(cid:286)ciowych. Rozwa(cid:298)my hipotetyczn(cid:261) sytuacj(cid:266) w oparciu o rysunek 2.3. Pe(cid:225)ny proces biznesowy wymaga zaanga(cid:298)owania trzech aplikacji. Testy integracyjne b(cid:266)d(cid:261) odbywa(cid:225)y si(cid:266) na styku produktu C i B oraz B i A. Biznes (funkcjonalno(cid:286)(cid:252)) natomiast b(cid:266)dzie weryfikowany przy u(cid:298)yciu wszystkich bloków A, B oraz C. Aplikacja C stanowi graficzny interfejs u(cid:298)ytkownika, posiadaj(cid:261)cy nik(cid:225)(cid:261) logik(cid:266) biznesow(cid:261), a zarazem bardzo rozbudowane mo(cid:298)liwo(cid:286)ci prezentacji i obs(cid:225)ugi danych. G(cid:225)ówny mechanizm realizacji zadanego bizne- su spoczywa na programie B. Tym niemniej mog(cid:261) wyst(cid:261)pi(cid:252) sytuacje, w których podsys- tem B b(cid:266)dzie musia(cid:225) posi(cid:225)kowa(cid:252) si(cid:266) wsparciem programu A. Reasumuj(cid:261)c, w realizacj(cid:266) logiki mog(cid:261) by(cid:252) zaanga(cid:298)owane bloki B oraz A. Natomiast aplikacja C jest inicjatorem przetwarzania, a zarazem konsumentem wyniku, tj. prezentacji rezultatu. Systemy o z(cid:225)o(cid:298)onej architekturze najcz(cid:266)(cid:286)ciej poddawane s(cid:261) realnej próbie dopiero w (cid:286)rodowi- sku testowym zamawiaj(cid:261)cego. Odbiorca oprogramowania ma przewag(cid:266) nad wykonaw- cami poszczególnych komponentów w postaci nieskr(cid:266)powanego dost(cid:266)pu do wszyst- kich elementów. Drug(cid:261) kwesti(cid:261) jest pos(cid:225)ugiwanie si(cid:266) danymi bardzo zbli(cid:298)onymi do rzeczywistych np. poprzez w(cid:225)(cid:261)czenie w proces testowania kopii bazy z produkcji. Po- wy(cid:298)sze zabiegi urealniaj(cid:261) testy funkcjonalne (pe(cid:225)nego biznesu) poprzez pos(cid:225)ugiwanie si(cid:266) niemal(cid:298)e faktycznymi danymi zgromadzonymi w du(cid:298)ym wolumenie. Obs(cid:225)uga pe(cid:225)nego Kup książkęPoleć książkę Rozdzia(cid:228) 2. (cid:105) Poziomy wykonywania testów 69 Rysunek 2.3. Schemat interakcji trzech niezale(cid:298)nych aplikacji procesu biznesowego w fazie prac integracyjnych lub ostatecznych testów odbior- czych mo(cid:298)e ujawni(cid:252) luki w opracowanej koncepcji. Zdarza si(cid:266), i(cid:298) w wyniku testów zidentyfikowane s(cid:261) problemy, które nie by(cid:225)y przewidziane w projekcie. Owe problemy mog(cid:261) prze(cid:225)o(cid:298)y(cid:252) si(cid:266) na zmian(cid:266) rozwi(cid:261)zania. Dok(cid:225)adniej rzecz ujmuj(cid:261)c: na jego dopra- cowanie, na przyk(cid:225)ad poprzez dopisanie drobnych funkcjonalno(cid:286)ci, modyfikacj(cid:266) za(cid:225)o(cid:298)e(cid:276) wst(cid:266)pnych etc. Testy integracyjne stanowi(cid:261) pierwszy etap weryfikacji, czy przyj(cid:266)te rozwi(cid:261)zanie oraz jego implementacja zaspakajaj(cid:261) potrzeby biznesowe (w ca(cid:225)o(cid:286)ciowym uj(cid:266)ciu procesu). Pierwszym, a zarazem najmniej k(cid:225)opotliwym scenariuszem jest integrowanie modu(cid:225)ów (ca(cid:225)ych programów), które wykonane s(cid:261) przez jednego producenta. W teorii wskaza- ne testy powinny by(cid:252) wykonane bez wi(cid:266)kszych problemów, a ewentualne przeszkody w postaci b(cid:225)(cid:266)dów w implementacji lub niejasno(cid:286)ci w dokumentacji rozwi(cid:261)zane wewn(cid:261)trz organizacji. Praktyka dowidzi, i(cid:298) niestety równie(cid:298) ten scenariusz naznaczony jest pewnymi zak(cid:225)óceniami w trakcie realizacji projektu testowego. Wynika to g(cid:225)ównie z organizacji pracy oraz nie do ko(cid:276)ca jasnej i zdrowej rywalizacji pomi(cid:266)dzy zespo(cid:225)ami wewn(cid:261)trz korporacji. Wskaza(cid:225)em korporacj(cid:266), gdy(cid:298) poj(cid:266)cie klienta zewn(cid:266)trznego oraz wewn(cid:266)trznego jest szeroko stosowane w du(cid:298)ych przedsi(cid:266)biorstwach. Poj(cid:266)cie samo w so- bie nie kryje niczego z(cid:225)ego, aczkolwiek zauwa(cid:298)alne s(cid:261) problemy w relacjach pomi(cid:266)dzy zespo(cid:225)ami wynikaj(cid:261)ce z zawi(cid:225)ej, a bywa, (cid:298)e i naci(cid:261)ganej interpretacji tego(cid:298) terminu. Generalnie idealizuj(cid:261)c, mo(cid:298)na przyj(cid:261)(cid:252), i(cid:298) funkcjonuj(cid:261)ce procedury formalne w pe(cid:225)ni zabezpieczaj(cid:261) potrzeb(cid:266) kooperacji ró(cid:298)nych zespo(cid:225)ów w celu osi(cid:261)gni(cid:266)cia ostatecznego rezultatu. Nieco mniej przyjemn(cid:261) sytuacj(cid:261) jest nieposiadanie jednego lub wi(cid:266)cej komponentów „na w(cid:225)asno(cid:286)(cid:252)”, kiedy s(cid:261) one udost(cid:266)pnione grzeczno(cid:286)ciowo przez klienta. Jest to sto- sunkowo dobre rozwi(cid:261)zanie, aczkolwiek uzale(cid:298)nione od dobrej woli wspó(cid:225)pracy. Pewn(cid:261) Kup książkęPoleć książkę 70 Testowanie oprogramowania. Podr(cid:246)cznik dla pocz(cid:241)tkuj(cid:241)cych trudno(cid:286)ci(cid:261) dla procesu integracji mog(cid:261) by(cid:252) ewentualne niedoci(cid:261)gni(cid:266)cia w kodzie po drugiej stronie, ale w(cid:225)a(cid:286)nie po to si(cid:266) wykonuje testy integracji, aby owe problemy wyeliminowa(cid:252). Generalnie „my” czy partner po przeciwnej stronie musimy czeka(cid:252) na ewentualne modyfikacje kodu w celu kontynuowania procesu integracji. Niemniej jednak jest to dobra droga. Wymaga ona zaanga(cid:298)owania zasobów klienta jako po(cid:286)red- nika, lecz uzyskujemy warto(cid:286)(cid:252) dodan(cid:261) w postaci wczesnego rozminowania pola. Bujna wyobra(cid:296)nia podpowiada, co mo(cid:298)e si(cid:266) sta(cid:252), je(cid:298)eli podejmiemy prób(cid:266) zintegrowania dwóch programów bez wcze(cid:286)niejszego „docierania” ich razem. Najtrudniejsz(cid:261) sytuacj(cid:261) jest konieczno(cid:286)(cid:252) wyprodukowania modu(cid:225)u klienckiego do obce- go systemu bez dost(cid:266)pu do tego(cid:298) zasobu. Zaiste gros trudno(cid:286)ci ujawni si(cid:266) w momen- cie uruchamiania kodu i testów funkcjonalnych. Du(cid:298)o zale(cid:298)y od roli, jak(cid:261) dla testowanej funkcjonalno(cid:286)ci pe(cid:225)ni zewn(cid:266)trzny system. Bywa, i(cid:298) brak dost(cid:266)pu do drugiego pro- gramu w minimalnym stopniu ograniczy testy. Bywa równie(cid:298), i(cid:298) zupe(cid:225)nie je unie- mo(cid:298)liwi. Za(cid:225)ó(cid:298)my, i(cid:298) testowana funkcjonalno(cid:286)(cid:252) realizuje jaki(cid:286) biznes zdefiniowany w 10 logicznych krokach, gdzie kroki 2., 5. oraz 8. wymagaj(cid:261) po(cid:225)(cid:261)czenia z us(cid:225)ug(cid:261) sie- ciow(cid:261) w celu pobrania/przeliczenia jakich(cid:286) danych. W takich okoliczno(cid:286)ciach przete- stujemy tylko krok nr 1. Drugi ju(cid:298) wymaga interakcji z web service (WS). W tym momencie wyklarowa(cid:225)a si(cid:266) potrzeba za(cid:286)lepienia wywo(cid:225)ywanej metody WS przez nasz(cid:261) aplikacj(cid:266), tak aby mog(cid:225)a ona przej(cid:286)(cid:252) do kroku nr 3 itd. Trzeba wyprodukowa(cid:252) symu- lator systemu zewn(cid:266)trznego. Temat za(cid:286)lepiania (cid:298)(cid:261)da(cid:276) do zewn(cid:266)trznych aplikacji b(cid:266)dzie omówiony szerzej w dalszej cz(cid:266)(cid:286)ci ksi(cid:261)(cid:298)ki. Do typowych problemów (b(cid:225)(cid:266)dów) wykrywanych w procesie integracji nale(cid:298)y zaliczy(cid:252): (cid:141) Niespójno(cid:286)(cid:252) wysy(cid:225)anego schematu XML z oczekiwaniami klienta lub serwera np. w wyniku przygotowania klienta WS w oparciu o nieaktualny opis us(cid:225)ugi (WSDL) lub b(cid:225)(cid:261)d w kodzie. (cid:141) Tre(cid:286)(cid:252) danych przekazywana w pliku wymiany danych zawiera znaki specjalne, na które negatywnie reaguje druga aplikacja. Przyk(cid:225)adowa nazwa jakiej(cid:286) organizacji, fundacji mo(cid:298)e zawiera(cid:252) cudzys(cid:225)ów, który eksportowany jest do tre(cid:286)ci pola. Dokumentacja opisuj(cid:261)ca pliki wymiany mo(cid:298)e nie opisywa(cid:252) szczegó(cid:225)ów lub wyj(cid:261)tków. (cid:141) Zderzenie dwóch technologii lub nawet ró(cid:298)nych wersji tych samych serwerów mo(cid:298)e powodowa(cid:252) problemy natury integracyjnej. (cid:141) Bywaj(cid:261) sytuacje, i(cid:298) w jakich(cid:286) okoliczno(cid:286)ciach jedna ze stron b(cid:266)dzie przekracza(cid:225)a czas odpowiedzi na (cid:298)(cid:261)danie (ang. time out). (cid:141) Wyobrazi(cid:252) mo(cid:298)na sobie sytuacj(cid:266), (cid:298)e obrót danymi odbywa si(cid:266) za pomoc(cid:261) pliku wymiany danych, w którym koniec linii ustalony jest na znak LF, a w wyniku po(cid:286)redniego dzia(cid:225)ania jakiego(cid:286) programiku, który kopiuje plik z miejsca A do B, zajdzie niejawna konwersja znaku ko(cid:276)ca linii na CRLF. Próba odczytania takiego zbioru zako(cid:276)czy si(cid:266) niepowodzeniem. Czy taki scenariusz mo(cid:298)na przewidzie(cid:252) w testach funkcjonalnych? W praktyce jedna aplikacja wygeneruje poprawnie LF, a druga poprawnie odrzuci znak CRLF. Gdzie jest b(cid:225)(cid:261)d?! Mo(cid:298)e w jakim(cid:286) „starym” programiku, którego nie brali(cid:286)my pod uwag(cid:266) na etapie testów? Kup książkęPoleć książkę Rozdzia(cid:228) 2. (cid:105) Poziomy wykonywania testów 71 (cid:141) Testy integracyjne stanowi(cid:261) dobr(cid:261) okazj(cid:266) do masowego wczytywania plików, wymiany danych przez funkcje WS itp. Bywa, i(cid:298) b(cid:225)(cid:266)dy, np. przepe(cid:225)nienie bufora, przekroczenie zakresu zmiennej itp., ujawniaj(cid:261) si(cid:266) dopiero przy „ogromnej” ilo(cid:286)ci danych. (cid:141) Integracja systemu ujawnia wszelkie ró(cid:298)nice w rozumieniu funkcji, jakie ma pe(cid:225)ni(cid:252) ka(cid:298)dy z elementów, w tym po której stronie maj(cid:261) by(cid:252) obs(cid:225)ugiwane okre(cid:286)lone wyj(cid:261)tki. (cid:141) Luki w opracowanej koncepcji rozwi(cid:261)zania, na podstawie której by(cid:225)a wykonana implementacja. (cid:141) Wiele innych problemów… 2.3. Testy systemowe Przedmiotem testów systemowych jest ca(cid:225)a aplikacja lub jej samodzielny fragment, który znajduje odwzorowanie w projekcie, tj. wchodzi w zakres projektu. Najodpo- wiedniejsz(cid:261) form(cid:261) testów funkcjonalnych jest zastosowanie techniki czarnoskrzynko- wej. Niemniej jednak technika bia(cid:225)ej skrzynki z powodzeniem mo(cid:298)e by(cid:252) wykorzystywa- na jako uzupe(cid:225)nienie g(cid:225)ównego w(cid:261)tku testów. Kluczem do sukcesu jest prowadzenie testów w (cid:286)rodowisku testowym jak najbardziej zbli(cid:298)onym do produkcyjnych warun- ków funkcjonowania aplikacji. Weryfikacja aplikacji w warunkach mo(cid:298)liwie wiernie odwzorowuj(cid:261)cych docelowe (cid:286)rodowisko pracy zmniejsza ryzyko przeoczenia b(cid:225)(cid:266)dów i problemów, które mog(cid:261) wynika(cid:252) z ró(cid:298)nic w specyfice obu (cid:286)rodowisk. Wi(cid:266)cej infor- macji na temat (cid:286)rodowiska testów znajduje si(cid:266) w rozdziale po(cid:286)wi(cid:266)conym owej tema- tyce w niniejszej ksi(cid:261)(cid:298)ce. Równie istotne jest to, kto wykonuje testy systemowe. Najlepiej by(cid:225)oby, aby czyni(cid:225) to niezale(cid:298)ny zespó(cid:225) testerów, tzn. taki, który zachowuje du(cid:298)(cid:261) autonomiczno(cid:286)(cid:252) wobec zespo(cid:225)u programistycznego w aspekcie (cid:286)rodowiska testów oraz zasobów ludzkich. Testy systemowe (ang. system testing) winny ujmowa(cid:252) wymagania zarówno niefunk- cjonalne, jak i funkcjonalne. Jest to faza, w której ocenia si(cid:266) globalnie produkt bez nadmiernego nacisku na zg(cid:225)(cid:266)bianie wewn(cid:266)trznej architektury i instrukcji kodu aplikacji. Testy systemowe odnosz(cid:261) si(cid:266) do aplikacji w uj(cid:266)ciu ca(cid:225)o(cid:286)ciowym. Oznacza to, i(cid:298) zo- bowi(cid:261)zani jeste(cid:286)my do weryfikacji wszystkich funkcji wraz z analiz(cid:261) korelacji po- mi(cid:266)dzy nimi. Za(cid:225)ó(cid:298)my, i(cid:298) otrzymali(cid:286)my do testów aplikacj(cid:266) lub nowy modu(cid:225), który administruje fakturami VAT. Testy systemowe wymagaj(cid:261) zweryfikowania wszystkich (cid:286)cie(cid:298)ek obs(cid:225)ugi owego dokumentu, m.in. wystawienia FV, korekty, wydruku, filtro- wania, generowania do pliku PDF, akceptacji etc. Tego rodzaju testy mog(cid:261) ujawni(cid:252) potrzeb(cid:266) zastosowania za(cid:286)lepek lub symulatorów zewn(cid:266)trznych systemów, z którymi nasza aplikacja b(cid:266)dzie wchodzi(cid:252) we wspó(cid:225)zale(cid:298)- no(cid:286)(cid:252) lub wyst(cid:266)powa(cid:252) jedynie jako klient. Specyfika i zakres testów systemowych stawia ten rodzaj weryfikacji w roli bardzo dobrego kandydata do automatyzacji czynno(cid:286)ci (testów). Kup książkęPoleć książkę 72 Testowanie oprogramowania. Podr(cid:246)cznik dla pocz(cid:241)tkuj(cid:241)cych Testy systemowe to: (cid:141) testy funkcjonalne, (cid:141) testy wydajno(cid:286)ciowe, (cid:141) testy regresywne, (cid:141) testy ergonomii, (cid:141) testy instalacji, (cid:141) testy bezpiecze(cid:276)stwa. 2.4. Testy akceptacyjne Testy odbiorcze wykonywane s(cid:261) bezpo(cid:286)rednio przez zamawiaj(cid:261)cego w oparciu o w(cid:225)asne zasoby lub poprzez zlecenie prac niezale(cid:298)nemu zespo(cid:225)owi testerskiemu. Testy te maj(cid:261) potwierdzi(cid:252) zgodno(cid:286)(cid:252) weryfikowanego produktu z zapisami w umowie i obowi(cid:261)zuj(cid:261)- cymi przepisami prawa. Celem testów akceptacyjnych jest weryfikacja i potwierdzenie, czy wszystkie zapisy w kontrakcie zosta(cid:225)y zrealizowane w sposób zaspokajaj(cid:261)cy ocze- kiwania. Pozytywne zamkni(cid:266)cie fazy testów odbiorczych stanowi podstaw(cid:266) do finan- sowego rozliczenia kontraktu. Testy akceptacyjne winny odnosi(cid:252) si(cid:266) do formalnie spisanych kryteriów odbioru oprogramowania. Wspomniane kryteria zwykle uzgad- niane s(cid:261) na etapie negocjacji kontraktu. Nadmieniona powy(cid:298)ej sytuacja odnosi si(cid:266) do oprogramowania pisanego na zamówienie. Nieco inaczej kreuje si(cid:266) sytuacja dla aplikacji „pude(cid:225)kowych”. Oprogramowanie z pó(cid:225)ki mo(cid:298)e by(cid:252) poddane dwóm typom testów akceptacyjnych: alfa i beta. Testy alfa wykonywane s(cid:261) wewn(cid:261)trz organizacji, która wyprodukowa(cid:225)a oprogramowanie, aczkol- wiek weryfikacji dokonuje niezale(cid:298)ny zespó(cid:225), tj. zespó(cid:225), który nie bra(cid:225) udzia(cid:225)u w pro- cesie wytwarzania. Betatesty realizowane s(cid:261) poza organizacj(cid:261) wykonuj(cid:261)c(cid:261) kod przez grup(cid:266) u(cid:298)ytkowników docelowych. Firmy produkuj(cid:261)ce oprogramowanie pude(cid:225)kowe s(cid:261) (cid:298)ywo zainteresowane uzyskaniem informacji zwrotnej (potwierdzeniem) o wysokiej jako(cid:286)ci w(cid:225)asnego produktu przed oficjalnym wprowadzeniem go na rynek. Niezale(cid:298)nie od typu oprogramowania (pude(cid:225)kowe, na zamówienie) winno ono równie(cid:298) by(cid:252) poddane testom akceptacyjnym w aspekcie obowi(cid:261)zuj(cid:261)cych przepisów prawa. Kup książkęPoleć książkę Skorowidz A administracja (cid:286)rodowiskiem testów, 27 adres URL, 109 adresowanie IP, 180 algorytm SHA, 188 algorytmy walidacyjne, 33 analizator ruchu sieciowego, 195 API, Application Programming Interface, 76 architektura wielowarstwowa, 36 arkusze kalkulacyjne, 52 atak Blind SQL-Injection, 102, 103 SQL-Injection, 96, 99, 104 typu XSS, 93 autodiagnoza, 161 automatyzacja testów, 183 B baza danych, 76 bezpiecze(cid:276)stwo, 92 Blind SQL-Injection, 102, 103 blokowanie spamu, 92 b(cid:225)(cid:261)d, 11 etap symulacji, 29 potencjalne przyczyny, 30 replikacja, 29 b(cid:225)(cid:266)dna obs(cid:225)uga wyj(cid:261)tku, 44 b(cid:225)(cid:266)dy blokuj(cid:261)ce, 12 krytyczne, 12 projektowe, 145 sterownika JDBC, 77 wewn(cid:266)trzne, 42 w koncepcji, 145 w operacji mno(cid:298)enia, 141 w procesie integracji, 70 zewn(cid:266)trzne, 40 C certyfikat ISTQB, 58 cykl (cid:298)ycia oprogramowania, 62 czas wykonania zapytania, 83, 85 D debugowanie, 12 dokumentacja, 13 dokumentowanie testów, 34 do(cid:286)wiadczenie testera, 140 drzewo MockService, 174 wyników, 83 E edytory tekstu, 52 emulatory, 52 ergonomia komunikatów walidacyjnych, 121 przycisków akcji, 122 systemów informatycznych, 122 F filtrowanie danych, 97 formularz do(cid:225)adowania telefonu, 94, 107 funkcja zwracaj(cid:261)ca wersj(cid:266), 36 G generator danych, 32 danych testowych, 197, 200 CSV, 201, 203 SQL, 201 XML, 201 Kup książkęPoleć książkę 210 Testowanie oprogramowania. Podr(cid:246)cznik dla pocz(cid:241)tkuj(cid:241)cych generator certyfikatów SSL, 51 MockService, 173 sumy kontrolnej, 51, 187 GIT, 35 graf przep(cid:225)ywu sterowania, 138, 139 GUI, 15 GUI dgMaster, 205 I ICT, Information and Communication Technologies, 92 IEEE, 13 implementacja monitora TCP, 178 informacja o znaku ko(cid:276)ca linii, 187 informacje o nazwie serwera, 113 o systemie, 111 o wersji serwera, 113 zwrotne, 18 instrukcja IF, 15 instrukcja INSERT INTO, 80 intensywno(cid:286)(cid:252) testów, 53 interfejs u(cid:298)ytkownika, 15 interpretacja projektu, 149 J jako(cid:286)(cid:252) oprogramowania, 17, 20, 63, 163 JDBC, 80 j(cid:266)zyk WADL, 166 WSDL, 166 K klauzula UNION, 99, 100 klient MockService, 176 us(cid:225)ugi sieciowej, 165 kod JavaScript, 95 kodowanie znaków, 52 konfiguracja nas(cid:225)uchu, 178 nowej instrukcji, 85 po(cid:225)(cid:261)czenia JDBC, 79 programu Fiddler, 114 TCPMon, 180 testu dla aplikacji, 87 zapytania SQL, 80 (cid:298)(cid:261)dania, 88 kontrola jako(cid:286)ci, 46, 52 wersji oprogramowania, 35 krok po(cid:286)redni, 109 kryterium ilo(cid:286)ciowe, 17 L logowanie b(cid:225)(cid:266)dów, 45, 50 M Manifest Zwinnego Wytwarzania Oprogramowania, 64 mened(cid:298)er plików, 51 metoda bia(cid:225)ej skrzynki, 14 czarnej skrzynki, 13 metodyki zwinne, 64 metryka pakietu Oracle, 37 miara jako(cid:286)ci oprogramowania, 17 migracja danych, 48 model kaskadowy, 63 V, 64 modyfikacja kodu, 115 kodu formularza, 117 tre(cid:286)ci strony, 112 monitor TCP, 177 monitorowanie jako(cid:286)ci, 21 N nag(cid:225)ówek HTTP, 113 narz(cid:266)dzia automatyzacji testów, 52, 186 narz(cid:266)dzie Apache JMeter, 51, 52, 199 Apache TCPMon, 177, 178, 180, 181 dgMaster, 203 Eclipse, 51 Fiddler, 105–108, 111–117 Fiddler2, 51 Firebug, 51, 106 JMeter, 76–90 KeyStore Explorer, 51 Membrane Monitor, 51 Membrane SOAP Monitor, 189–93 NetBeans IDE, 51 Notepad++, 51 Oracle OpenScript, 52 PL/SQL Developer, 51 PuTTY, 51 Selenium, 52 Kup książkęPoleć książkę Skorowidz 211 SoapUI, 51, 165–176, 180 Spawner Data Generator, 203 TCPMon, 51 Total Commander, 51 VNC, 51 WebScarab, 105 WinSCP, 51 Wireshark, 51, 195, 196 O obs(cid:225)uga b(cid:225)(cid:266)dów wewn(cid:266)trznych, 42 b(cid:225)(cid:266)dów zewn(cid:266)trznych, 40 wyj(cid:261)tków, 43 zg(cid:225)osze(cid:276), 39 ogólna teoria testowania, 11 opis kodu (cid:296)ród(cid:225)owego, 38 oprogramowanie Bugzilla, 39 JIRA, 39 Mantis Bug Tracker, 39 SVN, 35 P plik wynikowy CSV, 203 podgl(cid:261)d odpowiedzi, 114 podmienianie warto(cid:286)ci, 105 polecenie DESC, 96 porty, 180 poziomy wykonywania testów, 65 presja czasu, 151 procentowy rozk(cid:225)ad zg(cid:225)osze(cid:276), 21 proces integracji, 70 obs(cid:225)ugi b(cid:225)(cid:266)dów, 40, 42 testowania, 149 projekt REST, 170 projektowanie testu, 129 do(cid:286)wiadczenie testera, 140 technika bia(cid:225)ej skrzynki, 136 technika czarnej skrzynki, 131 protokó(cid:225) REST, 168 przebieg realizacji projektu, 9, 53 rejestracji b(cid:225)(cid:266)dów, 22, 23 przechwycenie sesji, 108 przej(cid:286)cia pomi(cid:266)dzy stanami, 134 przekazywanie zmian w kodzie, 39 przyczyny b(cid:225)(cid:266)dów, 30 zniech(cid:266)cenia, 156 przypadek testowy, 12 przypadki u(cid:298)ycia, 135 R realizacja projektu, 60 regu(cid:225)y odpowiedzi, 175 rejestracja b(cid:225)(cid:266)dów, 22, 23 rekonesans, 111 replikacja b(cid:225)(cid:266)dów, 28 REST, Representational State Transfer, 165 retest, 11 równomierne obci(cid:261)(cid:298)enie prac(cid:261), 54 S scenariusz testów, 13 serwer poczty, 52 SHA, Secure Hash Algorithm, 188 skrypt JS, 95 skutki zniech(cid:266)cenia, 159 SOAP, Simple Object Access Protocol, 165 specyfikacja, 13 spójno(cid:286)(cid:252) nazewnictwa, 121 SQL-Injection, 96, 99, 104 SSL, Secure Socket Layer, 166 standardy, 13 Subversion, SVN, 35 suma kontrolna, checksum, 187 sygnatura wersji, 103 symulacja b(cid:225)(cid:266)du, 29 symulator aplikacji, 31 serwera us(cid:225)ug sieciowych, 171 syndrom zniech(cid:266)cenia, 153 system kontroli wersji, 35 GIT, 35 Subversion, 35 (cid:286)rodowisko deweloperskie, 30 produkcyjne, 25 testów, 23, 27, 28 (cid:263) T tabela, 81 technika bia(cid:225)ej skrzynki, 136 czarnej skrzynki przej(cid:286)cia pomi(cid:266)dzy stanami, 134 przypadki u(cid:298)ycia, 135 warto(cid:286)ci brzegowe, 131 techniki testowania, 13 Kup książkęPoleć książkę 212 Testowanie oprogramowania. Podr(cid:246)cznik dla pocz(cid:241)tkuj(cid:241)cych teoria testowania, 11 tester oprogramowania, 54 aspekty psychologiczne, 149 syndrom zniech(cid:266)cenia, 153 testowanie aplikacji internetowej, 86 bazy danych, 76 bezpiecze(cid:276)stwa aplikacji, 91 ergonomii systemu informatycznego, 118 instalacji, 117 instrukcji, 136 migracji danych, 47 obs(cid:225)ugi wyj(cid:261)tków, 43 przej(cid:286)(cid:252) pomi(cid:266)dzy stanami, 134 przeno(cid:286)no(cid:286)ci kodu, 117 us(cid:225)ug sieciowych, 89, 165 testy akceptacyjne, 72 decyzyjne, 138 funkcjonalne, 73 ilo(cid:286)ciowe, 197 integracyjne, 67 jako(cid:286)ciowe, 8 modu(cid:225)owe, 66 niefunkcjonalne, 74 obci(cid:261)(cid:298)eniowe, 75 przeci(cid:261)(cid:298)eniowe, 75 regresywne, 125 systemowe, 71 bezpiecze(cid:276)stwa, 72 ergonomii, 72 funkcjonalne, 71 instalacji, 72 regresywne, 72 wydajno(cid:286)ciowe, 71 w cyklu (cid:298)ycia oprogramowania, 62 w oknie czasu, 58 wewn(cid:266)trzne, 8 wydajno(cid:286)ci, 74, 76 trywialno(cid:286)(cid:252) wykrycia b(cid:225)(cid:266)du, 12 tworzenie symulatora WS, 172 typy testów, 73 U us(cid:225)ugi sieciowe, 165 W WADL, Web Application Description Language, 166 walidacja dopuszczalnych znaków, 144 pól dla kwot, 147 walidatory, 52 warto(cid:286)ci brzegowe, 131 wersje oprogramowania, 35 wra(cid:298)liwe informacje, 109 WSDL, Web Services Description Language, 166 wstrzykni(cid:266)cie kodu JS, 95 wyj(cid:261)tki, 43 wykres testu aplikacji, 89 wy(cid:225)(cid:261)czenie cz(cid:266)(cid:286)ci kodu, 104 wymaganie, 13 wytwarzanie oprogramowania, 64 wywo(cid:225)anie monitora TCP, 179 wywo(cid:225)ywanie funkcji MockService, 176 procedury, 84 X XSS, Cross Site Scripting, 93 Z zasada kumulowania si(cid:266) b(cid:225)(cid:266)dów, 9 zastosowanie opcji disabled, 117 ORDER BY, 102 SELECT UNION, 99, 101 z(cid:225)amanie zasad ergonomii, 122 zniech(cid:266)cenie, 153 przyczyny, 156 skutki, 159 (cid:273) (cid:296)ród(cid:225)a pliku WSDL, 166 (cid:296)ród(cid:225)o zmodyfikowanej strony, 116 (cid:275) (cid:298)(cid:261)danie REST, 171 Kup książkęPoleć książkę
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Testowanie oprogramowania. Podręcznik dla początkujących
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: