21 września 2019, 15:11
Część IV Czym wesprzeć testowanie
Gdyby cała armia małp stukała w maszyny do pisania, mogłaby napisać wszystkie książki z Muzeum Brytyjskiego.
- Sir Arthur Eddington, brytyjski astronom i fizyk
W TEJ CZĘŚCI Testowanie automatyczne i narzędzia do testowania Polowanie na błędy i testowanie beta
Rozdział 14 Testowanie automatyczne i narzędzia do testowania
W TYM ROZDZIALE Pożytki z automatyzacji i narzędzi Narzędzia do testowania Automatyzacja testu oprogramowania Testowanie na chybił-trafił: małpy i goryle Użycie narzędzi i automatyzacja testowania w rzeczywistości
Testowanie oprogramowania to ciężka praca. Kto podczas lektury tej książki zajęty był także testowaniem, wie że samo wykonywanie testów to ciężka, fizyczna praca, która zajmuje wiele czasu i kosztuje wiele wysiłku. Oczywiście, można by włożyć jeszcze więcej wysiłku w zmniejszenie ilości klas równoważności, dzięki czemu ilość zadań testowych do wykonania też byłaby mniejsza, ale w ten sposób zwiększyłoby się również poziom ryzyka, zmniejszywszy pokrycie testowe i dokonując wyboru, że pewne - może istotne - funkcje nie zostaną przetestowane. Trzeba testować więcej, ale nie ma na to czasu. Co począć?
Rozwiązaniem jest zastosowanie metody znanej już od dawna z wielu innych dziedzin i przede wszystkim z przemysłu wytwórczego - wynaleźć i zastosować narzędzia, które uczynią pracę łatwiejszą i skuteczniejszą. O tym właśnie traktuje ten rozdział.
Najważniejsze punkty rozdziału: 1. Czemu użycie narzędzi do testowania i automatyzacja są konieczne 2. Przykłady prostych narzędzi 3. W jaki sposób zastosowanie narzędzi przeradza się w automatyzację 4. W jaki sposób karmić i dbać o „małpy” 5. Czemu automatyzacja testowania nie jest lekarstwem na wszystko Pożytki z automatyzacji i z narzędzi
Przypomnijmy sobie, co wiemy o wytwarzaniu oprogramowania. W większości modeli wytwarzania oprogramowania, pętla kodowanie - testowanie - poprawki powtarza się wielokrotnie przed ostatecznym wypuszczeniem oprogramowania. Oznacza to, że każdy test może trzeba będzie wykonać nie jeden raz, ale dziesiątki razy. Sprawdza się, czy błędy znalezione w czasie wykonywania poprzedniej serii testów rzeczywiście zostały naprawione i że nie pojawiły się żadne nowe błędy. Ten proces ponownego wykonywania tych samych zadań testowych nazywany jest testowaniem regresywnym1.
Mały projekt produkcji oprogramowania, mający kilka tysięcy zadań testowych do wykonania, może nie mieć nawet czasu aby wykonać je wszystkie choć jeden raz. Wielokrotne ich wykonywanie jest wobec tego niemożliwe, pomijając już to, że byłoby okropnie monotonne. Narzędzia do testowania i do automatyzacji rozwiązują ten problem stwarzając lepsze metody niż ręczne wykonywanie testów.
Oto najważniejsze zalety narzędzi i automatyzacji: 6. Szybkość. Wyobraźmy sobie, ile czasu zajęłoby ręczne wykonanie paru tysięcy zadań testowych dla Kalkulatora Windowsów. Tester może w najlepszym razie wykonywać jedno zadanie na, powiedzmy, pięć sekund. Automatyzacja może skrócić ten czas 10, 100 a nawet 1000 razy. 7. Skuteczność. Będąc zajętym wykonywaniem testów, nie robi się w tym czasie nic innego. Mając do dyspozycji narzędzie, które skraca czas potrzebny na wykonanie testowania, otrzymuje się więcej czasu do dyspozycji na planowanie i projektowanie zadań testowych. 8. Trafność i precyzja. Zrobiwszy to samo kilkaset razy, człowiek nie jest w stanie dłużej zachować tej samej koncentracji i ryzyko popełnienia błędu wzrasta. Narzędzie wykonuje testy i kontroluje wyniki równie dobrze za każdym razem. 9. Nieustępliwość. Narzędzia do testowania nigdy się nie męczą i nigdy nie rezygnują. Działają jak ten królik na bateryjki z reklamy telewizyjnej: chodzą w kółko i w kółko i…
1 Warto jest odróżniać zadania testowe wykonywane ponownie po to, by sprawdzić, że wykryty wcześniej błąd rzeczywiście został naprawiony od tych, które wykonuje się ponownie po to, by sprawdzić, czy funkcje działające uprzednio działają nadal. Niektóre standardy stosują określenie testowanie ponowne (re-testing) na pierwszy rodzaj, zaś testowanie regresywne (regression testing) wyłącznie na drugi rodzaj (przyp. tłumacza).
Wszystko to brzmi pięknie - można kazać narzędziom wykonać za nas całą pracę, uruchomić je i spokojnie czekać na wyniki. Niestety, nie jest aż tak dobrze. Domów nie da się budować automatycznie, chociaż cieśle mają do dyspozycji piły motorowe i pistolety do wbijania gwoździ. Narzędzia ułatwiają pracę i umożliwiają osiągnięcie lepszej jakości. Tak samo działają narzędzia do testowania.
Narzędzia do testowania nie zastąpią testerów - tylko pomogą testerom lepiej wykonywać swoją pracę.
Warto wziąć pod uwagę, że nie zawsze użycie narzędzi do testowania jest włściwym rozwiązaniem. Czasem nic nie zastąpi testowania ręcznego1. Na razie zapoznamy się z możliwościami i sposobem działania narzędzi, zastanawiając się przy tym, jak można by je zastosować do stojących przed nami zadań testowych. Na końcu rozdziału dowiemy się, jakie są ograniczenia i jak zachować ostrożność, zanim podejmie się próby użycia narzędzi w rzeczywistych projektach. Narzędzia do testowania
Tester oprogramowania spotyka się z wieloma różnymi rodzajami narzędzi. Co będzie przydatne w praktyce zależy od typu testowanego oprogramowania i od tego, czy wykonuje się testowanie metodami czarnej czy szklanej skrzynki.
Piękno narzędzi do testowania polega na tym, że nie zawsze trzeba być specjalistą od tego, jak one działają ani co dokładnie robią, by móc nimi skutecznie się posługiwać. Wyobraźmy sobie, że testuje się oprogramowanie sieći, które umożliwia komputerowi jednoczesny kontakt z milionem innych komputerów. Byłoby trudno lub wręcz niemożliwe przeprowadzić test miliona rzeczywistych połączeń. Mając do dyspozycj narzędzie pozwalające symulować takie połączenia - na przykład dzwoniąc na różne numery telefoniczne od jednego do miliona - dałoby się wykonać taki test bez potrzeby stosowania rzeczywistych scenariuszy. Nie musi się rozumieć, w jaki sposób takie narzędzie działa - wystarczy że działa. Oto testowanie czarnej skrzynki.
Z drugiej strony, można posłużyć się narzędziami do monitorowania i do modyfikowania protokołu komunikacyjnego - między tym milionem komputerów - na niskim poziomie. Aby skutecznie posługiwać się takim narzędziem, trzeba umieć stosować metody szklanej skrzynki i rozumieć działanie protokołu na niskim poziomie.
1 Jest popularne przysłowie - "automatyczny chaos to szybszy chaos" - bardzo stosowne w odniesieniu do automatyzacji testów oprogramowania (przyp. tłumacza).
W tym przykładzie spotykamy się z istotnym rozróżnieniem dwóch rodzajów narzędzi: nieintruzyjnych oraz intruzyjnych1. Jeśli narzędzie używane jest tylko do tego, by by monitorować i badać stan programu nie modyfikując go w żadnen sposób, uważa się je za nieintruzyjne. Jeśłi jednak narzędzie modyfikuje kod programu albo zmienia w jakiś sposób jego środowsiko, nazywa się je intruzyjnym. Można wyróżnić rozmaite stopnie itruzyjności. Testerzy zwykle usiłują posługiwać się narzędziami jak najmniej intruzyjnymi aby zmniejszyć możliwość wpływu narzędzia na uzyskiwane wyniki testów2.
Na kilku najbliższych stronach zostaną opisane najważniejsze rodzaje narzędzi do testowania i sposoby och zastosowania. Niektóre z opisanych narzędzi są zwykle częścią środowiska większości języków programowania, inne są sprzedawane osobno. Może się jednak zdarzyć, że wytwarzany sprzęt lub oprogramowania jest na tyle specyficzne, że potrzebne są specjalne narzędzia na zamówienie - albo wykonane samemu - dostosowane do tych potrzeb. Również te narzędzia dają się zwykle zaliczyć do jednej z opisanych dalej kategorii.
Analizatory i monitory
Analizatory albo monitory to narzędzia pozwalające obserwować szczegóły działania programu, których nie da się zobaczyć gołym okiem. W rozdziale 7-ym „Testowanie oprogramowania pod rentgenem” poznaliśmy analizatory pokrycia testowego, pozwalające na identyfikację wykonanych linii kodu, funkcji oraz ścieżek, przez które program przeszedł podczas wykonywania zadań testowych. Analizator pokrycia testowego jest jednym z przykładów analizatora. Większość analiazatorów pokrycia jest intruzyjnych ponieważ muszą by wkompilowane albo włączone w program, żeby mieć dostęp do dostarczanej informacji.
1 W oryginale non-invasive (nieintruzyjne) oraz invasive (intruzyjne). Częściej spotykane określenia to non-intrusive oraz odpowiednio intrusive (przyp. tłumacza).
2 Nie całkiem tak jest. Użycie narzędzi zwiększa skuteczność i szybkość testów, ale kosztem zastosowania intruzyjnych narzędzi, które powodują, że środowisko testowania różni się od operacyjnego. Celem jest osiągnięcie właściwej rónowagi między tymi dwoma przeciwstawnymi tendencjami oraz w miarę prezycyjne oszacowanie wpływu intruzyjności na wyniki testów (przyp. tłumacza).
Rysunek 14.1 pokazuje inny rodzaj analizatora - analizator komunikacyjny (określany też często angielskim słowem sniffer, „obwąchiwacz”). To narzędzie umożliwia obserwację danych przesyłanych przez sieć albo inne łącze komunikacyjne. Takie narzędzie po prostu podłącza się do linii komunikacyjnej, wychwytuje przesyłane pakiety danych i wyświetla je na innym komputerze. Testując taki system, wprowadziłoby się dane inicjujące zadanie testowe na komputerze nr 1, skontrolowało komunikację na komputerze nr 3 i sprawdziło poprawnośc wyniku na komputerze nr 2. Tym samym systemem posłużylibyśmy się w czasie poszukiowania źródła błędu po odkryciu awarii. Badając przesyłane dane, można by stwierdzić, czy źródłem problemu jest generowanie danych (komputer nr 1), czy też ich interpretacja (komputer nr 2). Ten rodzaj systemu jest nieintruzyjny względem oprogramowania.
Komputer nr 1 Testowane oprgramowanie
Komputer nr 2 Testowane oprgramowanie Łącze komunikacyjne
Podłączenie analizatora
Komputer nr 3 Analizator - narzędzie testowe
Rysunek 14.1 Analizator komunikacji umożliwia obserwowanie danych przesyłanych między dwoma systemami.
Programy śledzące dostępne razem z większością kompilatorów też taktuje się jako analizatory, ponieważ umożliwiają testerom posługującym się metodami szklanej skrzynki na dostęp do wartości zmiennych i śledzenie stanów programu. Każde narzędzie umożliwiające wgląd w dane programu, do których zwykły użytkownik nie ma dostępu, można zaklasyfikować jako analizator.
Sterowniki
Sterowniki to narzędzia stosowane do sterowania i kontrolowania testowanego oprogramowania. Najprostszym przykładem sterownika jest plik wsadowy (batch file), będący prostą listą sekwencyjnie wykonywanych programów lub komend. W czasach MS-DOS była to popularna wśród testerów metoda wykonywania programów testowych. Konstruowało się plik wsadowy zawierający nazwy programów testujących, puszczało się plik i szło do domu. Wpółczesne systemy operacyjne i języki programowania maja bardziej wyrafinowane metody wykonywania programów testowych. Na przylkład, w miejsce starego pliku wsadowego MS-DOS można zastosować skomplikowany skrypt w Perl‘u, zaś Widows Task Scheduler (program szeregujący, rysunek 14.2) można zastosować do puszczania różnych programów testowych o określonych porach dnia.
Rysunek 14.3 pokazuje inny rodzaj sterownika. Załóżmy że testopwane oprogramowanie wymaga wprowadzania wielkich ilości danych testowych. Przy pomocy nieco zmodyfikowanego sprzętu i paru narzędzi programowych, mozna zastąpić klawiaturę i mysz testowanego systemu przy pomocy dodatkowego komuptera, działającego jak strownik. Na tym komputerze można napisać proste programy, automatycznie generujące uderzenia klawiszy i ruchy myszy, które program przekazuje testowanemu oprogramowaniu.
Rysunek 14.2 Program szeregujący umożliwia wyznaczenie kolejności wykonywania programów lub plików komend.
Normalna konfiguracja
Kabel klawiatury
Sterownik testoów
Kabel myszy
Rysunek 14.3 Komputer może działac jako sterownik zastępujący klawiaturę i mysz w testowanym systemie.
Można zadać sobie pytanie, po co zawracać sobie głowę tak skomplikowaym ustawieniem? czemu po prostu nie uruchomić na pierwszym systemie programu, który wysyłalaby uderzenia klawiszy do testowanego oprogramowania? Są tutaj dwa możliwe problemy: 10.System operacyjny może nie być wielozadaniowy, co uniemożliwia jednoczesne wykonywanie obu programów. 11. Wysyłajac uderzenia klawiszy i ruchy myszy z osobnego komputera, stawarzamy system względnie nieintuzyjny. Kiedy zaś sterownik jest wykonywany na tym samym komputerze co testowaney program, jest to intruzyjne, co można uznać za niedozwolony sposób testowania.
Szukając sposobu sterowania testowanuym oprogramowaniem, trzeba wziąć pod uwagę wszelkie techniki zewnętrznego sterowania programem, a potem zacząć szukać sposobu, jak istniejącą kontrolę zastąpic czymś, co będzie automatycznie wprowadzać dane wejściowe.
Namiastki
Namiastki, tak jak sterowniki, zostały już wspomniana w rozdziale 7-ym, poświęconym technikom szkalnej skrzynki. Namiastki są dokładną odwrotnością sterowników w tym sensie, że że niczym nie kierują, tylko przyjmują i odpowiadają na dane, wysyłane przerz testowane oprogramowania. Rysunek 14.4 ilustruje tę sytuację.
Normalna konfiguracja
Konfiguracja namiastkowa
Rysunek 14.4 Komputer może działać jako namiastka, zastępując drukarkę i umożliwiając skuteczniejszą analizę danych wyjściowych z testów.
Testując oprogramowanie, które wysyła dane na drukarkę, można je przetestować rzeczywiście drukując dane na drukarce i kontrolując wydruk na papierze. Będzie to działać, ale dość wolno, nieefektywnie i będzie się narażonym na dowolność. Czy da się zauważyć, że brakuje jednego piksela albo minimalną różnicę w kolorze? Gdyby zamiast tego zastąpić drukarkę innym komputerem z programem (namiastką) czytającą i intrepretującą dane wysyłane do drukarki, dałoby się skontrolować wyniki znacznie szybciej i precyzyjniej.
Namiastki często używa się, gdy programowanie musi komunikować się z zewnętrznym sprzętem. W czasie wytwarzania oprogramowania często sprzęt jeszcze nie istnieje albo jest trudno go zdobyć. Użycie namiastki pozwala rozpocząć test oprogramowania zanim jeszcze powstał sprzęt, a ponadto czyni testowanie skuteczniejszym.
Czasem używa się terminu emulator na określenie urządzenia, które zastępuje inne urządzenie. Na przykład PC zastępujący drukarkę w ten sposób, że interpretuje kody wysyłane przez program do drukarki i odpowiada programowi tak jakby to robiła drukarka, jest właśnie emulatorem. Różnica między emulatorem a namiastką jest taka, że namiastka umożliwia także dostęp i analizę wysyłanych do niej danych.1
Narzędzia do testowania przeciążającgo i na obciążenie
Te narzędzia - jak sama nazwa wskazuje - służą do obciążania i przeciążania testowanego oprogramowania. Na przykład testowany program do przetwarzania tekstu działa poprawnie kiedy jest jedyną działającą na systemie w danej chwili aplikacją, z dostępem do całej pamięci i przestrzeni na dysku. Ale kiedy tych zasobów zacznie brakować w systemie, zwiększa się szansa awarii. Żeby to spowodować, można oczywiście skopiować na dysk wiele plików, żeby go zapełnić, albo uruchomić wiele programów jednocześnie, żeby wypełniły pamięć komputera, ale takie metody są mało skuteczne i nieprecyzyjne. Narzędzie specjalnie zaprojektowane do takiego testowania znacznie je ułatwia.
1 Różnica między emulatorem, symulatorem i namiastką to zawsze atrakcyjny temat do dsykusji w czasie przerw na kawę. Słowo namiastka (ang. stub) zwykle - inaczej niż w tej książce - używane jest na oznaczenie kodu (rutyny), która zstępuje kod jeszcze nie gotowy z trakcie integracji odgórnej.
Rysunek 14.5 przedstawia program Microsoft Stress, wchodzący w skład środowiska pracy dla programistów, tej samej firmy. Inne systemy operacyjne też mają podobne narzędzia. Program przeciążający pozwala ustawiać ilość pamięci wewnętrznej, powierzchni dysku, plików i innych zasobów dostępnych dla testowango programu.
Rysunek 14.5 Program Microsoft Stress umożliwia ustawianie ilości zasobów dostępnych dla testowanego oprogramowania.
Ustawienie wartości zasobów na poziom zerwoy lub bardzo niski wymusi na oprogramowaniu wykonywanie innych niż zwykle ścieżek, obsługujących sytuacje tego rodzaju ograniczeń. Oprogramowanie powinno w tej sytuacji działać bez awarii i bez utraty danych. Może pracować wolniej, wyświetlać komunikaty o braku zasobów itp, ale powinno działać poprawnie i degradacja funkcjonalności powinna następować w sposób kontrolowany.
Narzędzia obciążające są podobne do narzędzi przeciążających w tym sensie, że służą do stwarzania sytuacji trudno osiągalnych w inny sposób. Na przykład dostępne są w handlu programy do obciążania serwerów WWW symulujące wybraną ilość jednoczesnych sesji i trafień. Specyfikacja wymagań może żądać, by serwer był w stanie obsłużyć 10000 jednoczesnych użytkowników i 1 milion trafień dziennie bez widocznego wzrostu czasu odpowiedzi. Mając do dyspozycji narzędzie do obciążania, wystarczy wstukać żądany poziom obciążenia, przeprowadzić testy i skontrolować wyniki.
Generatory zaburzeń i szumu
Kolejną klasę narzędzi stanowią generatory zaburzeń i generatory szumu1. Podobne są w działaniu do narzędzi obciążających, ale funkcjonują bardziej losowo. Na przykład narzędzie przeciążające może mieć tryb działania losowo zmieniający ilość dostępnych zasobów. Testowany program może działać dobrze zarówno wtedy, kiedy dostępne jest dużo pamięci jak i wtedy, kiedy pamięci jest mało, ale zawodzić, jeśli ilość dostępnej pamięci nieustannie się zmienia. Ten rodzaj błędu mógłby zostać odkryty przez program przeciążający działający w trybie losowym.
Podobnie, dokonawszy małej zmiany w ustawieniu analizatora z rysunku 14.1 tworzy się konfigurację taką jak na rysunku 14.6. W tym ustawieniu analizator zastąpiony jest przez system (sprzęt plus oprogramowanie) który umożliwia nie tylko analizę danych przepływających łączem, ale także ich modyfikowanie. Takie ustawienie może służyc do symulowania wszelkiego rodzaju błędów w komunikacji polegających na gubieniu danych, szumie, wadliwych połączeniach itp.
Komputer nr 1 Testowane oprogramowanie
Komputer nr 2 Testowane oprogramowanie Łącze komunikacyjne
Rysunek 14.6 Generator zaburzeń podczepiony do łącza komunikacyjnego może służyć do testowania, jak oprogramowanie radzi sobie z błędami wynikającymi z szumu na łączu.
Przy podejmowaniu decyzji jak można zastosować generatory zaburzeń i szumu, bierze się pod uwagę jakie zewnętrzne warunki wpływają na testowane oprogramowanie, a następnie projektuje sposoby manipulacji tymi wpływami tak, żeby sprawdzić jak oprogramowanie sobie z nimi radzi.
Narzędzia analityczne
1 Klasyfikowanie narzędzi do testowania to zadanie, które - jak każdą klasyfikację - można przeprowadzić na wiele sposobów. W praktyce istnieje olbrzymia ilość różnych kombinacji funkcji narzędzi. Wiele dostępnych na rynku narzędzi łączy w sobie szereg zintegrowanych funkcji, a producenci często lansują specjalne nazwy dla tego typu agregatów. Dlatego dla ułatwienia orientacji najlepsze byłoby klasyfikowanie funkcji narzędzi, nie zaś samych narzędzi. Autor niestety wybrał wariant przeciwny i w tym podrozdziale opisuje wręcz sposób zastosowania narzędzi jako osobny "typ" narzędzia. Warto pamiętać, że na dobrą sprawę nie istnieje żadna powszechnie przyjęta terminologia w tej dziedzinie (przyp. tłumacza).
Do tej kategorii zaliczy się całą resztę narzędzi1. Wielu testerów ułatwia sobie pracę stosując powszechnie stosowane aplikacje. Nie zawsze są one tak wymyślne jak opisane dotąd, ale dobrze służą i oszczędzają wiele pracy i czasu. 12.Programy do przetwarzania tekstu 13.Arkusze kalkulacyjne 14.Bazy danych 15.Programy do porównywania ze soba plików 16.Programy do przechwytywania i porównywania zawartości ekranu 17.Programy śledzące 18.Kalkulatory binarne i heksadecymalne 19.Stopery 20.Magnetowid i kamera wideo
Oczywiście, złożoność i charakter istniejących programów zmienia się nieustannie. Każdą sytuację trzeba zanalizować oddzielnie, aby móc wybrać pasujące do niej narzędzia i najlepszy sposób ich zastosowania. Automatyzacja testu oprogramowania
Chociaż narzędzia do automatyzacji testowania to po prostu jeszcze jedna kategoria narzędzi do testowania, jednak zasługują one na specjalne potraktowanie. Narzędzia omówione dotąd są bardzo skuteczne, ale nadal wymagają bezpośredniej, ręcznej obsługi i obserwowania wyników. A gdyby tak dało się te narzędzia połączyć, uruchomić i posługiwać się nimi bez konieczności ludzkiej interwencji? Mogłyby wykonywać testy, szukać błędów, analizować i logować wyniki. To jest właśnie automatyzacja testowania.
W kilku następnych częściach tego rozdziału opisane są różne rodzaje automatyzacji, od najprostszej do najbardziej złożonej.
Nagrywanie i odtwarzanie
1 Rzeczywiście, autor wrzucił tutaj do jednego worka między innymi narzędzia używane do zarządzania testami (bazy danych, arkusze kalkulacyjne), do porównywania wyników testów z oczekiwanymi poprawnymi wynikami (komparatory) oraz rozmaite narzędzia do wyliczania oczekiwanych poprawnych wyników (tzw. wyrocznie, ang. oracle).
Najabrdziej podstawową formą automatyzacji testowania jest nagrywanie wszelkich czynności wykonywanych przy pomocy myszy i klawiatury w czasie pierwszego, ręcznego testowania, a następnie odtwarzanie tego nagrania, kiedy potrzeba wykonać te same testy ponownie. Jeśii testowanye oprogramowanie działa na systemie Windows lub na Micintoshu, nagrywanie i odgrywanie będzie bardzo proste. Na Macintoshu używa się QuicKeys; na Windows można posłużyć się otwartym programem Macro Magic1. Wiele tego typu narzędzi jest dostępnych, niektóre typu shareware (otwarte, darmowe).
Tego typu programy są rodzajem sterowników2. Jak juz było opisane, sterowniki są to narzędzia stosowane do kontrolowania i kierowania testowanym oprogramowaniem. To właśnie robi program nagrywający/odgrywający: nagrane działania są odgrywane, powtarzając to, co zostało wcześniej zrobione w celu przetestowania oprogramowania.
Rysunek 14.7 pokazuje ekran asystenta ustawień Macro3, porwadzącego użytkownika krok po proku przez wszystkie czynności potrzebne do skonfigurowania i nagrywania testowych sekwencji.
Rysunek 14.7 Aystent ustavień Macro umożliwia skonfigurowanie w jaki sposób nagrane makro jest wywoływane i odtwarzane (ilustracja za zgodą Iolo Technologies, www.iolo.com).
Asystent ustawień Macro pozwala na ustawienie następujących opcji:
1 Istnieją dziesiątki, jeśli nie setki tego typu programów (zwanych narzędziami nagrywania/odgrywania, ang. capture/playback albo capture/replay) - przyp. tłumacza.
2 Można tę definicję przyjąć wobec zastosowania narzędzia w trakcie odtwarzania, natomiast w trakcie nagrywania działają raczej jak analizator czy program śledzący z możliwością nagrywania zaobserwowanych zjawisk (przyp. tłumacza).
3 Macro - to nazwa programu nagrywania/odtwarzania Microsoftu. Ta myląca nazwa bierze się stąd, że nagranie zapisywane jest w postaci programu "makropoleceń", czyli po prostu programu w specjalnie do takich zastosowań dopasowanym języku (przyp. tłumacza).
Nazwa. Nadanie makroprogramowi nazwy pozwala na jego późniejszą identyfikację. Setki makroprogramów mogą być potrzebne nawet do przetestowania małego programu. 22.Powtórzenia. Testowanie powtórzeniami jest świetnym sposobem znajdowania błędów. Można ustawic ile razy makroprogram zostanie wykonany. 23.Wyzwalacze. Można ustawić, co spowoduje wykonanie makroprogramu. Może to być gorący klawisz (np. Ctrl+Shift+T), komenda (np. wykonaj makro 1), kliknięcie na skrót, pojawienie się jakiegoś okna (np. zawsze gdy wystartuje Kalkulator), albo jeśli system przez jakiś czas nie zanotował żadnej aktywności użytkownika. 24.Co ma być przechwytywane. Można wybrać, czy przechwytywane (i nagruwane) ma być tylko naciskanie klawiszy klawiatury, czy również czynności wykonywane myszą. 25.Szybkość odtwarzania. Makroprogram może być odgrywany od 20% do 500% szybkości oryginalnego nagrania. Jest to istotne jeśli szybkość działania testowanego programu jest zmienna. Co się stanie, jeśli program będzie wykonywany w zmienionych okolicznościach nieco wolniej i przyciks, na który makroprogram miał właśnie kliknąć, jeszcze nie pojawił się na ekranie? 26.Pozycja odtwarzania. Ta opcja określa, czy ruchy i kliknięcia myszy mają być bezwzględne czy w stosunku do wybranego okna na ekranie. Testując aplikację której położenie na ekranie może się zmienić, należy wybrać opcję aktywności myszy w sotsunku do okna tej aplikacji, w przeciwnym razie odtwarzany program może klikać w zupełnie inne elementy aplikacji (lub poza nią), niż w czasie nagrywania.
Teraz warto poćwiczyć torchę nagrywanie i odtwarzanie makroprogramów. Wystarczy w tym celu znaleźć i załadować jakiś program do nagrywania/odtwarzania i wypróbować go na prostej aplikacji, np. na Kalkulatorze albo na Notatniku. Ćwicząc, starajmy się myśleć jak testerzy!
Okaże się, że chociaż nagrane makroprogramy mogą wykonać za testera pewne testy automatycznie, co ułatwia i przyśpiesza testowanie, metoda nie jest jednak doskonała. Największy problem to brak weryfikacji. Makroprogramy nie potrafią skontrolować, czy uzyskane wyniki są poprawne1. Makroprogram potrafi wpisać do Kalkulatorz 100-99, ale nie potrafi skontrolować czy wynik jest 1 - nadal musi się to robić samemu. To oczywiście kłopot, ale wielu testerów ceni sobie nawet samo pozbycie się uciążliwego pisania i poruszania myszą. O wiele prościej jest tylko obserwować wykonywany makroprogram i sprawdzać, czy wyniki są zgodne z oczekiwanymi2.
Szybkość odwarzania to kolejna trudność z zastosowaniem makroprogramów. Nawet ustawiając szykbość odtwarzania nie zawsze uda się zachować synchronizację makroprogramu i testowanego programu. Na przykład strona WWW może raz załadować się w sekundę, a innym razem w 10 sekund. Można spowolnić makroprogramy dopasowując je do najgorszego wariantu, ale będą wtedy wykonywane powoli nawet jeśli oprogramowanie działa szybko. Jeśłi któregoś dnia dana strona ładowałaby się wyjątkowo powoli - całe 15 sekund - wtedy makroprogram i tak by się pogubił i klikał niewłaściwe elementy w nieodpowiednim czasie.
Trzeba zachować ostrożnośc nagrywając ruchy i klikanie myszą. Programy nie zawsze pojawiją się w tym samy miejscu na ekranie. Ustawienie pozycji odtwarzania względem okna programu zamiast całego ekranu oże rozwiązać tę trudność, ale nawet wówczas niewielka chocby ziana GUI może unieważnić całe wcześniejsze nagranie.
Mimo tych ograniczeń, nagrywanie i odtwarzanie makroprogramów jest popularną metoda automatyzacji prostszych zadań testowych. Jest to również dobry sposób rozpoczęcia nauki automatyzacji testowania.
Programowane makroprogramy
Programowanie to krok w górę w porównaniu z prostymi nagrywanymi makroprogramami. Programy testowe tworzy się nie nagywając ręczne testowanie, lecz programując. Prosty program mógłby wyglądać tak jak przykład na listingu 14.1. Ten rodzaj programu można - używając Asystenta Macro - zbudować wybierając poszczególne instrukcje z automatycznej listy - nie trzeba nawet ich pisać samemu.
Listing 14.1 Prosty makroprogram do wykonywania testu na Kalkulatorze Windows. 1: Test Kalkulatora nr 2 …
1 Natomiast doskonale potrafią to zrobić dostępne na rynku programy do nagrywania/odtwarzania.
2 Bardzo niebezpieczne rozwiązanie - taka połowiczna automatyzacja może uśpić czujność testerów i spowodować przepuszczenie większej ilości błędów niż przy testowaniu w całości ręcznym.
5: <<PROMPT:Wynik powoinien być 23>> …
Linijka 1-a jest komentarzem. Linijka 2-a wywołuje program calc.exe, Kalkulator w Windows. Linijka 3-a czeka do 5 sekund na wystartowanie kalkulatora. Progra zatrzymuje się dopóki na ekranie nie pojawi się okno ze słowem Kalkulator na swoim pasku tytułowym. Linijka 4-a wpisuje 123-100=. Linijka 5-a wyświetla infomrację, że wynik ma być 23. Linijka 6a zamuka Kalkulator i zakańcza test.
Zwróćmy uwagę jaką przewagę mają tego rodzaju programy nad nagrywanyi. Nadal nie da się dokonać weryfikacji poprawności wyników, można jednak wprowadzić przerwy i kazać testerowi potwierdzić poprawność (lub nie) wyniku (rysunek 14.8).
Rysunek 14.8 Proste programy testowe nie są w stanie zweryfikować wyników testów, ale mogą zażądać od testera potwierdzenia (rysunak za zgodą Iolo Technologies, www.iolo.com).
Możliwe jest również - zamiast stosowania ogólnego spowolnienia odtwarzania - zastosować synchronizację polegającą na oczekiwaniu na spełnienie zdefiniowanego warunku przez dalszy wykonywaniem programu. W podanym przykładzie z Kalkulatorem, program czeka na wystartowanie Kalkulatora - o wiele bardziej niezawodna metoda.
Jak na razie wszystko jest dobrze, posunęliśy się krok do przodu w stronę automatyzacji testowania. Ma się do dyspozycji prosty język programowania zawierający gotowe akrokomendy do sterowania testowanym programem i metodę prostego dialogu z testerem. Dla wielu zadań jest to najzupełniej wystarczające i niejedno można w ten sposób zautomatyzować.
Brakuje jednak nadal dwóch istotnych elementów, bez których niemożliwe jest wykonywanie bardziej skomplikowanych testów. Po pierwsze, takie programy są wyłącznie sekwencyjne - nie da się zaprogramować rozwidleń w przebiegu programu. Zmienne i instrukcje decyzyjne dostępne w ogólnych językach programowania nie są dostępne. I nadal nie ma się możności autoatycznego zweryfikowania wyników. Aby te możliwości uzyskć, trzeba sastosować bardziej zaawansowane narzędzie do automatycznego testowania.
W pełni programowalne automatyczne narzędzia do testowania
Gdyby tak mieć do dyspozycji pełny język programowania, połaćzony z makrokomendami ułatwiającymi sterowanie testowanym oprogramowaniem i z możliwościa dokonywania weryfikacji wyników? Miałoby się wtedy najdoskonalsze narzędzie do znajdowania błędów! Rysunek 14.9 pokazuje przykład takiego narzędzia.
Rysunek 14.9 Visual Test został skonstruowany przez Microsoft, obecnie zaś sprzedawany jest przez Rational Software, jest przykładem narzędzia które zawiera środowisko do programowania, makrokomendy i możliwości weryfikowania wyników złożone w jednen zintegrowany pakiet.
Automatyczne narzędzia do testowania, takie jak Visual Test, dają możliwośc tworzenia bardzo skutecznych testów. Wiele z nich ma język programowania oparty na języku BASIC, dzięki czemu nawet nieprogramiści mogą pisać kod do testowania.
Gdyby chcieć wypróbować pisanie ciągu znaków Hello World! 10000 razy, trzeba by napisać następujące linie kodu: FOR i=1 TO 10000 PLAY „Hello World!” NEXT I Chcąc zaś spowodować przesunięcie kursora yszy z górnego lewego rogu ekranu 640x480 i wykonać podwójne kliknięcie, możnaby to zrobić tak:
PLAY „{MOVETO 0,0}” PLAY „{OVETO 640, 480}” play „{DBLCLICK}” Ten język daje teżlepsze mozliwości niż klikanie w określony punkt ekranu albo wysyłanie pojedynczych naciśnięć klawisza. Na przykład, aby kl;iknąć na przycisk OK, ożna posłużyć się komnedą wButtonClick („OK”) Nie trzeba wiedzieć gdzie na ekranie znajduje się przycisk OK. Program testujący poszukałby go, znalazł i kliknął - tak samo jak użytkownik. Istnieją komendy tego saego rodzaju do obsługi menu, pól wyboru i tak dalej. Takie komendy zapewniaja wielką elastyczność w pisaniu programów testowych i zarazem czynią je łatwiejszyimi do zrozumienia i bardziej niezawodnymi.
Najważniejsza cecha takich automatycznych narzędzi to możliwość dokonywania weryfikacji, sprawdzania czy testowany program podał prawidłowy wynik lub wykonał prawidłową czynność. Można to robic na kilka sposobów: 27.Przechwycenie treści ekranu. Wykonując testy po raz pierwszy, można przechwycić i zapisać poprawne fragenty ekranu. W czasie odtwarzania testów, automatyczny program porównywałby zapisane fragmenty z aktualnym fragmentem ekranu. Znajdując różnicę, automatyczny program mógłby zasygnalizować prawdopodobny błąd. 28.Wartości kontrolne. Zamiast przechwytywać fragmenty ekranu, można sprawdzać wartość poszczególnych kontrolek w oknie testowanego oprogramowania. Testując Kalkulator, program mógłny odczytać wartość w polu wyświetlającym wynik i porównać ją z wartościa oczekiwaną. Daje się też skontrolować, czy przycisk był przyciśnięty, a pole wyboru - wybrane. Autoatyczne narzędzie pozwala dokonać tego przy pomocy programu. 29.Pliki i inne dane na wyjściu. Podobnie, jeśli testowany program zapisuje dane na pliku - na przykład program do przetwarzania tekstu - program testowy mógłby otowrzyc ten plik i porónać ze znanym o poprawnej zawartośći. Tę samą technikę możnaby zastosować wobec danych przesyłanych przez modem albo przez sieć. Program testowy mógłby odczytac te dane i porównać z oczekiwanyi.
Weryfikacja była ostatnią poważną przeszkodą na drodze to automatycznego testowania oprogramowania. Pokonawszy ją, można skonstruować program wykonujący niemal każde zadanie testowe1 - całkiem albo przynajmniej częściowo automatycznie.
Więcej danych a temat znanych programów do automatyzacji testowania można między innymi znaleźć na: 30.Mercury Interactive, www.merc-int.com 31.Rational Software Corporation, www.rational.com 32.Segue Software, www.segue.com
Takie oprogramowanie jest przeznaczone głównie dla zespołów programistów w przedsiębirstwach i dla osoby prywatnej jest raczej kosztowne. Można jednak spróbować dostać licencję - ograniczoną w czasie - dla wypróbowania, albo - będąc studente - zniżkę studencką. Wiele firm odnosi się do takich propozycji życzliwie w nadziei, że to dobry sposób reklamy. Testowanie na chybił-trafił: małpy i goryle
Poznane przez nas dotąd narzędzia i techniki miały na celu ułatwić pracę testerów i uczynić ją efektywniejszą. Miały uławtwić wykonywanie zadań testowych, a w najlepjej zautomatyzować je zupełnie.
Ten sposób użycia automatycznych narzędzi przyczynia się do znajdowania błędów. Narzędzia pracowicie wykonują testowanie regresyjne, a testerzy mają więcej czasu na planowanie pracy i na projektowanie nowych zadań testowych. Istnieje też inny rodzaj autoatycznego testowania, którego celem jest symulowanie tego, co z programem mogą zrobić użytkownicy. Ten rodzaj tesowania nazywany jest niekiedy testującą małpą.
Określenie testująca małpa bierze się ze starego pomysłu, że jeśli posadzić milion małp piszących na milionie maszyn do pisania przez milion lat, to statystycznie jest prawdopodobne, że napisane zostanie przez nie jakieś wielkie dzieło literackie. Waląc w klawiaturę na chybił-trafił, można przypadkowo trafić na właściwą kombinację liter i małpa przez chwilę mogłaby robic wrażenie niezwykle zdolnej - tak jak ta na rysunku 14.10.
1 Ściślej, każde zadanie testowe wykonywane za pośrednictwem GUI (przyp. tłumacza).
Rysunek 14.10 Małpy testujące będą testować tak długo, jak długo mają proąd i od czasu do czasu - banana.
Kiedy oprogramowanie zostanie rozpowszechnione, będzie miało tysiące, a może nawet miliony użytkowników walących w nie - czasem bez ładu i składu. Mimo najlepszych starań przy konstruowaniu i wyborze zadań testowych, niektóre błędy prześlizgną się przez sieć zastawioną przez testrów i zostaną znalezione przez użytkowników. A gdyby tak uzupełnić zadania testowe przy pomocy symulacji tego, co mogą zrobić użytkownicy? Można by w ten sposób znaleźć niekiedy błędy, które w przeciwnym razie by się nam wymknęły. Do tego właśnie służy małpa testująca.
Użycie testującej małpy do symulowania tego, co użytkownicy być może będą robić z programem nie jest insynuoacją, że użytkownicy komputerów są małpami.
Głupie małpy
Najprostszym rodzajem małpy testującej jest głupia małpa. „Głupia małpa” niczego nie wie o testowanym przez siebie programie; po prostu losowo wybiera klawisze i kliknięcia myszą. Listing 14.2 pokazuje przykład kodu w VisualTest który losowo klika i pisze tekst 10000 razy.
Listing 14-2 Kilka linijek kodu wystarcza, aby stworzyć „głupią małpę”. 1: RANDOMIZE TIER 2: FOR i=1 TO 10000 3: PLAY „{CLICK „+STR$(INT(RND*640)) +”, „+STR$(INT(RND*480)) +”}” 4: PLAY CHR$(RND*256) 5: NEXT i Linijka 1-a inicjalizuje liczby losowe. Linijka 2-a otwiera pętlę od 1 do 10000 razy. Linijka 3-a wybiera losowo punkt na ekranie między 0,0 a 640,480 (rozdzielczość VGA) i klika w niego. Linjka 4-a wybiera losowo znak między 0 a 255 i pisze go.
Testowany program nie odróżnia skutków działania takiego programu od pracy prawdziwego użytkownika - prócz tego że wykonanie jest o wiele szybsze. Na dość szybkim PC wykonanie całego programu zajmie ledwo kilka sekund. Łatwo sobie wyobrazić, ile losowych czynności dałoby się uzyskać, gdyby taki program pracował przez całą noc!
Zwróćmy uwagę, że ta „małpa” nie dokonuje żadnej weryfikacji. Ona tylko klika i wpisuje znaki aż do momentu, kiedy albo pętla się skończy, albo program czy system operacyjny ulegnie awarii.
Kto nie wierzy, że „głupia małpa” może znaleźć poważny błąd, niech zastosuje taki program na swojej ulubionej grze komputerowej. Najprawdopodobniej najpóźniej po paru godzinach nastąpi awaria.
Może wydawać się dziwne, że proste losowe klikanie i pisanie jest w stanie znaleźć błędy. Jednak tak jest - z następujących powodów: 33.Mając dość czasu i wykonując dostatecznie wielką ilość prób, losowe wprowadzanie danych w końcu trafi na ten ciąg czynnośći, o któym nie śniło się ani programistom, ani testerom. Może małpa wprowadzi jakieś dane a następnie natychiast je usunie, albo wpisze olbrzymi ciąg znaków tam, gdzie program oczekuje krótkeigo. Kto wie? Coś się na pewno znajdzie. 34.„Głupia małpa” przez samo nieustanne powtarzanie wprowadzania danych może ujawnić błędy - takie jak np. przecieki pamięci - które wychodzą na jaw dopiero po wielu godzinach czy nawet dniach użytkowania. Kto posługoiwał się programem, który stawał się coraz mniej stabilny im dłużej się go używało, spotkał się z problemem, który dałoby się odkryć stosując „głupią małpę”.
Półgłupie małby
„Głupie małpy” mgą być bardzo skuteczne. Łatwo je zaprogramować i mogą znajdować poważne błędy powodujące zupełną awarię programu. Jednak kilka dodatkowych funkcji mogłoby uczynić je jeszcze skuteczniejszymi. Dodanie tych funkcji podniesie odrobinę poziom inteligencji naszej małpy, czyniąc ją „półgłupią”.
Powiedzmy że małpa pracowała przez kilka godzin, aplikując tysiące losowych danych wejściowych, zanim program uległ awarii. Wiadmomo, że znalazło się jakiś problem, ale nie da się pokazać programiście, jak można ten problem odtworzyć. Można by powtórzyć odkładnie tę samą pracę małpy (z tymi samymi danymi losowymi, jeśli to możliwe), ale oznaczałoby to ponowne zmarnowanie kilku godzin. Rozwiązaniem jest dodanie do małpy logowania, tak że wszelkie wykonane czynności zostałyby zapisane na pliku. Kiedy małpa znajduje błąd, wystarczy zajrzeć do pliku logowego żeby zobaczyć, co poprzedziło awarię.
Warto też zaprogramować małpę tak, żeby działała tylko na testowanym oporogramowaniu. Jeśli małpa losowo klika po całym ekranie, w końcu trafi na komendę zakańczającą program. Ponieważ małpa nie wie, czy program działa, będzie pracowała dalej. Wyobraźmy sobie, co może się stać, jeśli małpa będzie klikała i pisała po całym ekranie komputera - oj! Na szczęście większość dających się zaprogramować narzędzi do automatycznego testowania pozwala ustawić testy na wybraną aplikację i przerwać pracę, kiedy aplikacja przestała działać.
Kolejną funkcją, która podniesie inteligencję małpy, jest rozpoznawanie awarii programu. Uruchomiwszy małpę na całą noc straci się wiele cennych godzin, jeśli program ulegnie awarii, ledwo się zamknie za sobą drzwi. Jeśli dodać do małpy możliwość rozpoznawania awarii i ponowngo uruchomienia programu w tej sytuacji, zwiększy się znacznie skuteczność jej działania.
Bystre małpy
Kolejnym krokiem na drabinie ewolucyjnej jest „bystra małpa”. Taka małpa dziedziczy po swoich mniej inteligentnych braciach korzyści testowania losowego, ale wspomaga je zrozumieniem trybu działania testowanej aplikacji. „Bystra małpa” nie wali już całkiem losowo w kalwiaturę - ona wali w nią celowo.
Naprawdę „bystra małpa” wie”: 35.gdzie jest 36.co tam można zrobić 37.dokąd można stamtąd pójść 38.gdzie była wcześniej 39.czy to co widać jest poprawne.
Brzmi to znajomo? Powinno. Bystra małpa zna mapę stanów programu - taką mapę jak opisana w rozdziale 5-ym „Testowanie oprogramowania z klapkami na oczach”. Jeśli cała informacja na temat stanów testowanego oprogramowania znana jest małpie, może ona posługiwać się programem podobnie jak użytkownik, tylko o wiele szybciej, po drodze weryfikując poprawność działań programu.
„Bystra małpa” testująca Kalkulator Windows (zob. rysunek 14.11) będzie wiedzieć, jakie przyciski można nacisnąć, jakie są dostępne wybory menu, gdzie można wpisywać liczby. Kliknąwszy opcję „O Kalkulatorze” z menu „Pomoc”, będzie wiedzieć, że jedynym sposobem wyjścia stamtąd jest kliknięcie przycisku OK albo Zamknij. Nie będzie więc losowo klikać po całym ekranie.
Rysunek 14.11 „Bystra małpa” wie, jak zamknąć okno dialogowe „O Kalkulatorze”.
„Bystra małpa” nie musi szukać tylko błędów powodujących zupełną awarię programu. Może również po drodze weryfikować dane, kontrolować wyniki i szukać różnic między wynikami rzeczywistymi a oczekiwanymi. Mając zaprogramowane zadania testowe, można polecić małpie ich losowe wykonywanie, szukanie błędów i logowanie wyników. Odlotowo!
Rysunek 14.12 pokazuje „bystrą małpę” imieniem Koko, ochrzczoną tak na pamiątkę goryla, którego nauczono posługiwania się językiem znaków. Aby zaprogramować Koko, wprowadza się w nią tablicę stanów programu, czynności dające się wykonać w każdym ze stanów oraz sposoby odróżniania poprawnych od niepoprawnych wyników działania programu.
Rysunek 14.12 „Bystra małpa” Koko daje się zaprogramować tak, że wie gdzie jest i co może zrobić.
Kiedy Koko działa, doprowadza testowany program do znanego stanu, a następnie wybiera losowo kolejną czynność na podstawie rozkładu prawdopodobieństwa rzeczywistego użycia1, wykonuje tę czynność i kontroluje jej wynik. Jeśli czynność powoduje zmianę stanu programu, Koko wie o tym i posługuje się nowym zestawem możliwych wyborów czynności, odpowiednim dla tego nowego stanu.
W taki sposób daje się symulować rzeczywisty sposób użytkowania testowanego oprogramowania, symulując tysiące godzin jego działania w ciągu kilku godzin. „Bystre małpy” to naprawdę maszyny do znajdowania błędów! Użycie narzędzi i automatyzacja testowania w rzeczywistości
Zanim jednak, zafascynowani nowymi możliwościami, rzucimy się, żeby zacząć stosować automatyzację w naszych testach, należy przeczytać ten podrozdział i wziąć sobie jego treść do serca. Automatyzacja testowania nie jest uniwersalnym lekiem na wszystko. Następujące trudności z automatyzacją testowania trzeba wziąć pod uwagę: 40.Oprogramowanie zmienia się. Specyfikacje nie są zamknięte. Nowe funkcje dodaje się pod koniec projektu. Nazwa produktu zmienia się w ostatniej chwili. Co będzie, jeśli zaprogramuje się tysiące makroprogramów aby móc wykonać wszystkie testy na tydzień przed wypuszczenie produktu i wtedy okaże się, że oprogramowanie zostało w ostatniej chwili zmodyfikowane tak, że wyświetla zaraz po starcie zupełnie nowy ekran? Wszystkie nagrane programy zawiodą, bo nie będą wiedzieć nic o istnienieu tego nowego ekranu. Dlatego automatyzację należy zaprojektować tak, aby była elastyczna i dawała się łatwo i szybko dostosować do takich zmian w oprogramowaniu. 41.Nic nie jest w stanie w pełni zastąpić ludzkiego oka i ludzkiej intuicji. „Bystre małpy” można uczynić bystrymi tylko do pewnej granicy. Mogą testować tylko to, do czego zostały zaprogramowane. Nigdy nie będą mogły powiedzieć „Oj, to dziwne. Musze sprawdzić to dokładniej”. Przynajmniej jeszcze nie dziś.
1 Koko realizuje w ten sposób strategię zwaną Statystcznym testowaniem (Statistical Usage-Based Testing), która w tej książce nie jest szczegółowo opisana (przyp. tłumacza).
42.Weryfikacja jest trudna. Testując interfejs użytkownika, najprostszym sposobem weryfikacji wyników jest przechytywanie, a następnie porównywanie całych ekranów. Ale przechwycone ekrany są olbrzymimi plikami, a poza tym wygląd i układ ekranów zwykle nieustannie się zmienia w trakcie projektu. Dlatego trzeba zaprogramować narzędzia tak, by weryfikowały tyko to co najważniejsze i żeby zmiany interfejsu dało się łatwo uwzględniać. 43.Nie należy zdać się wyłącznie na autoatyzację. Nigdy nie można zakładać, że ponieważ automatyczny program nie znajduje żadnych błędów, to nie a już żadnych błędów. One tam na pewno są - to opisany wcześniej „paradoks pestycydów”. 44.Poświęcając zbyt wiele czasu automatyzacji, można nie mieć już czasu na samo testowanie. Pisanie makroprogramów i programowanie „bystrej małpy” to świetna zabawa, ale to nie jest testowanie. Te narzędzia pomogą w pracy, ale trzeba zdążyć zastosować je na oprogramowaniu i wykonać rzeczywiste testowanie by móc znaleźć błędy. 45.Pisząc makroprogramy, budując narzędzia albo programując „małpę”, wykonuje się pracę będącą wytwarzaniem oprogramowania. Należy przy tym przestrzegać tych samych zasad i stosować te same metody co we właściwym projekcie. To, że się jest testerem, nie upoważnia do lekceważenia zasad metodyki. 46.Niektóre narzędzia są intruzyjne i mogą spowodować awarię testowanego oprogramowania. Kiedy znalazło się błąd w trakcie testów automatycznych, warto spróbować ponownie wywołać ten błąd - tym razem ręcznie. Może się czasem okazać, że błąd spowodowany był działaniem narzędzia do testowania.
Podsumowanie
Narzędzia do testowania i automatyzacja testowania daja się zastosować do każdego typu oprograowania. Większość przykładów w tym rozdziale dotyczyła testów interfejsu użytkownika, ale te same sposoby można zastosować do testowania kompilatorów albo serwerów WWW. Trzeba przypatrzyć się swoim testom pod kątem tego, jak użycie innych programów może je ułatwić.
Czasem używa się dłoni, czasem packi na muchy, a czasem (może niesłusznie) - młotka. Tester powinien wiedzieć, kiedy i jakie narzędzia warto zastosować. Lonstruowanie i używanie narzędzi i automatyzacja testowania może być swietną zabawą. Wgląda bojowo, kiedy komputer dzaiała sam, kursor lata po całym ekranie, a znaki wprowadzane są do testowanej aplikacji automatycznie. Jest wielką frajdą leżeć w domu w łożku albo popijajać kawę wiedząc, że automatyczny program pracuje w ty czasie za nas, znajdując błędy. Pytania
Pytania mają na celu ułatwienie zrozumienia. W aneksie A „Odpowiedzi na pytania” znajdują się prawidłowe rozwiązania – ale nie należy ściągać! 1. Wymień kilka korzyści stosowania narzędzi do testowania i automatyzacji testowania. 2. Jakie są możliwe wady automatyzacji i jakie możliwe trudności trzeba wziąć pod uwagę przy podejmowaniu decyzji o zastosowaniu narzędzi i o automatyzacji? 3. Jaka jest różnica między narzędziem a automatyzacją? 4. Jakie są podobieństwa i różnice między analizatorem a generatorem zaburzeń? 5. Prawda czy fałsz: narzędzie intruzyjne jest najlepsze, ponieważ działa najbliżej testowanego oprogramowania. 6. Jaki jest jeden z najprostszych, ale skutecznych, sposobów automatyzacji testowania? 7. Wymień kilka funcji, które warto dodać do rozwiązania opisanego jako odpowiedź na porzednie pytanie, aby uczynić automatyczne testy jeszcze skuteczniejszymi. 8. Na czym polega wyższość „bystrych małp” nad „głupimi małpami” i nad nagranymi automatycznie makroprogramami?