Przebranżowienie na testera

Część III Zastosowanie umiejętności w praktyce
Na urodziny dostałem nawilżasz i osuszacz… Wstawiłem je do jednego pokoju i zostawiłem, żeby się ze sobą rozprawiły.
Steven Wright, komik
Odkrycie polega na tym, że patrzy się na to samo co inni i myśli coś innego.
Albert Szent-Gyorgyi, laureat nagrody Nobla w medycynie i fizjologii w 1937 roku
W TEJ CZĘŚCI Testowanie konfiguracji Testowanie kompatybilności Testowanie różnych wersji językowych Testowanie łatwości korzystania Testowanie dokumentacji Testowanie witryn WWW

Rozdział 8 Testowanie konfiguracji
W TYM ROZDZIALE Przegląd testowania konfiguracji Jak podejść do zadania Jak zdobyć potrzebny sprzęt Jak zidentyfikować standardy sprzętu Testowanie konfiguracji innych typów sprzętu
Życie mogłoby być takie proste. Sprzęt komputerowy mógłby być tylko jednego rodzaju. Wszelkie oprogramowanie mogłoby być wytwarzane przez tylko jedną firmę. Nie byłoby wtedy tych wszystkich mylących przycisków do wyboru opcji do klikania i pól wyboru do wybierania. Wszystkie interfejsy pasowałyby od początku doskonale – dla każdego. Jakie nudne1.
W rzeczywistym świecie, w mających po kilka tysięcy metrów kwadratowych powierzchni supermarketach komputerowych, stoją do wyboru komputery, drukarki, monitory, karty komunikacyjne, modemy, skanery, kamery cyfrowe, urządzenia peryferyjne i setki innych komputerowcyh gadżetów – wszystkie dające się podłączyć do komuotera domowego!
Dla początkującego testera, jednym z pierwszych zadań może być testowanie konfiguracji: sprawdzenie, że oprogramowanie działa z jak największą ilością różnych kombinacji sprzętu. Również testując inne rodzaje systemów niż najpopularniejsze „pecety” i Macintosh‘e, zagadnienie konfiguracji trzeba wziąć pod uwagę. Umiejętności opisane w tym rozdziale z łatwością można dostosować do takiej sytuacji.
Pierwsza część rozdziału opisuje ogólne zasady testowania konfiguracji komputerów osobistych, a potem przechodzi się do szczegółów na temat testowania drukarek, kart wideo i kart dźwiękowych. Chociaż przykłady dotyczą komputerów osobistych, opisane metody można łatwo przenieść na prawie każde rodzaje testowania konfiguracji. Każdego dnia powstają nowe typy urządzeń i zadaniem testerów jest wymyślić sposoby ich testowania.
Najważniejsze punkty tego rozdziału: 1. Czemu testowanie konfiguracji jest konieczne 2. Czemu testowanie konfiguracji bywa ogromnie pracochłonne 3. Podstawowe sposoby testowania konfiguracji
1 Czytelnikom polskim należącym do troszeczkę starszego niż najmłodsze pokolenia przypominają się może czasy bardzo zbliżone do tego “ideału”. Wcale jednak nie było tak nudno…

4. Jak wejść w posiadanie potrzebnego sprzętu 5. Jak postępować testując inne rodzaje oprogramowania niż dla komputerów osobistych Przegląd testowania konfiguracji
Będąc z następną wizytą w sklepie komputerowym, warto przyjrzeć się pudełkom i poczytać opisy wymagań systemowych. Znajdzie się wśród nich takie jak PC z procesorem 486/66 MHz, Super VGA, 256-kolorowy ekran, 16-bitowa karta dźwiękowa, port MIDI dla gier itd. Testowanie konfiguracji to proces kontrolowania, czy testowane oprogramowanie działa z tymi wszystkimi rozmaitymi rodzajami sprzętu. Warto rozważyć różne możliwe konfiguracje standardowego komputera osobistego, jaki stoi w wielu domach i w prawie każdym biurze: 6. Komputer. Są dziesiątki znanych producentów: Compaq, Dell, Gateway, Hewlett-Packard, IBM i wielu innych. Każdy producent konstruuje i produkuje komputery osobiste albo z komponentów własnej konstrukcji, albo z części kupionych od innych producentów. Własne komputery osobiste produkuje też wielu mniej znanych, małych producentów; robią je nawet hobbyści-amatorzy. 7. Komponenty. Większość komputerów osobistych ma modułową budowę. Składają się z kart głównych, kart dodatkowych i rozmaitych urządzeń takich jak stacje dysków, stacje CDROM, wideo, dźwięk, modem, karty sięciowe (rysunek 8.1). Istnieją karty telewizyjne i wyspecjalizowane karty do nagrywania wideo, do automatyzacji urządzeń domowych itd. Istnieją nawet karty wejścia i wyjścia, które są w stanie zamienić komputer osobisty w jednostkę zdolną pokierować niewielką fabryką. Urządzenia wewnętrzne są wytwarzane przez setki różnych producentów.
stacja dyskietek stacja dysku twardego urządzenie dopasowujące I/O stacja CD-ROM adapter wyświetlacza zasilacz magistrala jednostka systemowa karta główna.
Rysunek 8.1 Liczne wewnętrzne komponenty składają się na konfigurację PC.

8. Urządzenia peryferyjne. Rysunek 8.2 pokazuje drukarki, skanery, mysz, klawiaturę, monitory, aparaty fotograficzne, kamery, joysticki i inne urządzenia, które podłącza się do komputera i które działają poza nim.
skaner drukarka joystick (manipulator) jednostka główna kamera cyfrowa mysz
Rysunek 8.2 Komputer osobisty można podłączyć do rozmaitych urządzeń peryferyjnych. 9. Interfejsy. Komponenty i urządzenia peryferyjne podłącza się do do komputera przez różne rodzaje złączy (rysunek 8.3). Interfejsy mogą być wewnętrzne albo zewnętrzne. Ich nazwy: ISA, PCI, USB, PS/2, RS/232, Firewire. Istnieje tak wiele różnych możliwości, że producenci niekiedy produkują to samo urządzenie pod różnymi nazwami. Na przykład ten sam model myszy można często kupić w trzech różnych konfiguracjach! 10.Opcje i pamięć. Wiele komponentów i urządzeń peryferyjnych można kupić z różnymi opcjami sprzętu i wielkościami pamięci. Drukarkę można uaktualnić, żeby obsługiwała więcej wzorów liter albo używała więcej pamięci, żeby drukowanie szło szybciej. Karty graficzne mające więcej pamięci potrafią obsługiwać dodatkowe kolory i grafikę o większej rozdzielczości. 11. Programy obsługi. Wszystkie komponenty i urządzenia peryferyjne komunikują się z systemem operacyjnym i z aplikacjami za pomocą procedur na niskim poziomie, zwanych programami obsługi. Często dostarczone są one przez producenta sprzętu i instaluje się je w trakcie procesu ustawiania sprzętu. Chociaż w sensię technicznym programy obsługi są oczywiście oprogramowaniem, z punktu widzenia testu zalicza się je do konfiguracji sprzętu.

Rysunek 8.3 Tył komputera osobistego zawiera liczne złącza do przyłączania urządzeń peryferyjnych.
Tester przygotowujący się do rozpoczęcia testowania konfiguracyjnego jakiegoś programu, powinien rozważyć jaka konfiguracja będzie najbardziej typowa dla tego programu. Gra komputerowa z mnóstwem efektów graficznych będzie wymagała zwrócenia uwagi na wideo i dźwięki. program do robienia kolorowych widokówek będzie szczególnie uzależniony od drukarek. program faksowy lub telekomunikacyjny należy przetestować z różnymi typami modemów i konfiguracji sięci.
Czemu właściwie miałoby to wszystko być konieczne? Istnieją przecież standardy, które dotyczą w jednakowym stopniu komputera osobistego kupowanego w supermerkecie i specjalnego komputera w szpitalu. Można chyba oczekiwac, że jeśli sprzęt został skonstruowany zgodnie ze standardami, to oprogramowanie powinno po prostu na nim działać bez żadnych kłopotów. W świecie idealnym pewnie by tak było, ale niestety - w rzeczywistości standardy nie zawsze są przestrzegane. Niektóre standardy są dość luźne – nazwijmy je zbiorami dobrowolnych reguł. Producenci kart i urządzeń peryferyjnych działają w sytuacji ostrej konkurencji i często naginają zasady, aby wcisnąc w swój produkt jeszcze jedną nową funkcję albo jeszcze odrobinę wyższą wydajność. Często programy obsługi do nowych urządzeń wrzuca się do pudełka niemal w momencie, gdy dostawy sprzętu zaczynają opuszczać bramy fabryki. W wyniku tego nie raż się zdarza, że oprogramowanie nie działa z niektórymi konfiguracjami sprzętu.
Lokalizacja błędów konfiguracji
Błędy konfiguracji mogą być naprawdę bolesne. Pamiętamy przecież jeszcze błąd „Króla Lwa” opisany w rozdziale 1-ym? To był typowy problem konfiguracji. Dźwięk programu nie działał na kilku zaledwie, ale bardzo popularnych konfiguracjach sprzętu. Ktokolwiek grał w grę komputerową albo posługiwał się aplikacja graficzną, kiedy kolory nagle oszalały, albo kawałki okna „odłupywały się” kiedy się je ciągnęlo, przypuszczalnie zetknął się z błędem programu obsługi karty graficznej. Ktokolwiek poświęcił długie godziny (albo dni!) usiłując zmusić stary program do działania z nową drukarką, też miał zapewne do czynienia z błędem konfiguracji.

Pewnym sposobem stwierdzenia, czy ma się do czynienia z błędem konfiguracji czy po prostu ze zwykłym błędem, jest powtórzenie dokładnie tego samego działania, krok po kroku, na innym komputerze z zupełnie odmienną konfiguracją. Jeśli awaria nie następuje, prawie na pewno mamy do czynienia z błędem konfiguracji. Jeśli awaria występuje na więcej niż jednej konfiguracji, to zapewne jest to „zwyczajny” błąd.
Przypuśćmy że testując program  na jakiejś szczególnej konfiguracji natrafiamy na problem. Kto teraż powinien naprawić błąd – zespół wytwarzający oprogramowanie czy też producent sprzętu? Może tu chodzić o miliony dolarów.
Przede wszystkim trzeba zlokalizować problem. Zwykle wiąże się to z dynamicznym testowaniem metodami szklanej skrzynki i wysiłkiem znajdowania i naprawiania błędu. Problem konfiguracyjny może wystąpić z wielu różnych powodów, z których każdy wymaga starannego przebadania kodu działającego w różnych konfiguracjach: 12.Oprogramowanie może mieć błąd występujący w wielu różnych konfiguracjach. Na przykład, program do produkcji kartek z życzeniami może działać z drukarkami laserowymi, ale nie z atramentowymi. 13.Oprogramowanie może mieć błąd pojawiający się tylko w jednej, szczególnej konfiguracji – na przykład nie działa na modelu „OkeeDoKee BR549 super drukarki atramentowej”. 14.Urządzenie albo jego program obsługi zawiera ukryty błąd, który powoduje awarię tylko jednego programu. Może ten program jest jedynym, który używa jakichś ustawień karty wideo? Taki program w połączeniu z wadliwym modelem karty powoduje awarię. 15.Urządzenie albo jego program obsługi zawiera błąd, który wprawdzie widoczny jest z wieloma programami, ale szczególnie rzuca się w oczy z jednym z nich. Przykładem może być program obsługi drukarki, który jako wartość domyślną zawsze wybiera jakość roboczą wydruku, więc aplikacja musi go do każdego wydruku przestawiać na tryb druku wysokiej jakości.
W dwóch pierwszych przykładach zespół projektu wytwarzającego oprogramowanie jest oczywiście odpowiedzialny za naprawienie błędu.

W obu następnych przykładach sytuacja nie jest już oczywista. Powiedzmy że błąd jest błędem drukarki i że ten model jest najpopularniejszy na świecie – ma dziesięć milionów użytkowników. Niewątpliwie, program musi działać z tą właśnie drukarką. Chociaż program nie zawiera żadnego błędu, ale przypuszczalnie naprawę – w postaci jakiegoś obejścia tego błędu – i tak wykona zespół wytwarzający aplikację.
Niezależnie od źródła problemu, odpowiedzialność i tak spada na producenta aplikacji. Klienci nie będą chcieli słuchać tłumaczeń, że to wadliwy sprzęt jest przyczyną błędu, będą po prostu chcieli, żeby aplikacja działała na ich konfiguracji.
O kartach dźwiękowych
W 1997 roku Microsoft wypuścił na rynek lalkę AntiMates Barney wraż z oprogramowaniem na CD, mające uczyć dzieci programowania. Oprogramowanie kontaktowało się z lalką za pomocą dwukierunkowego łącza radiowego, umieszczonego w lalce i w komputerze osobistym.
Radio w komputerze było podłączone do rzadko używanego interfejsu kart dźwiękowych, zwanego złączem MIDI. Tego interfejsu używa się do podłączania sprzętu muzycznego. Microsoft wyszedł z założenia, że to łącze jest dobrym wyborem, gdyż większość posiadaczy komputerów osobistych nia ma tego rodzaju sprzętu muzycznego. Karta miałaby więc to złącze wolne, dostępne do podłączenia radia do komunikacji z lalką.
Podczas testowania konfiguracyjnego odkryto typową ilość błędów. Jedne były problemami karty dźwiękowej, inne błędami w oprogramowaniu ActiMates. Jednak jednego błędu nie udało się nigdy zlokalizować. Wyglądało na to, że od czasu do czasu, losowo, komputer osobisty nagle się zawieszał i wymagał ponownego wystartowania. Problem występował tylko z jednym typem karty dźwiękowej – najpopularniejszej na rynku (oczywioście).
Kiedy w harmonogramie pozostało jeszcze tylko kilka tygodni, podjęto wzmożone wysiłki żeby rozwiązać problem. Po intensywnym testowaniu konfiguracyjnyem i poszukiwaniu błędu, udało się znaleźć jego przyczynę – winna była karta. Wyglądało na to, że zlącze MIDI tej karty zawsze miało ten błąd, tylko że używano je na tyle rzadko, że błąd nigdy nie został odkryty. Oprogramowanie ActiMates ujawniło go po raż pierwszy.

Zrobił się wielki bałagan, pełno zaprzeczania i wzajemnego wytykania się palcami, i wiele pracy późno w nocy. W końcu producent kart dźwiękowych przyznał, że problem istniał i obiecał znaleźć obejście błędu w nowych wersjach programu obsługi. Microsoft zainstalował poprawiony program obsługi na CD-ROM sprzedawanym z lalką ActiMate i dokonał pewnych zmian w programie tak, żeby błąd rzadziej powodował awarie. Mimo tych wszystkich wysiłków, te właśnie problemy z kompatybilnością karty dźwiękowej były najczęstszym powodem późniejszych telefonów do serwisu.
Dobór wielkości zadania
Testowanie konfiguracyjne może być wielkim przedsięwzięciem. Wyobraźmy sobie testowanie nowej gry, która ma być wykonywana na Microsoft Windows. Gra ma mnóstwo grafiki, dużo efektów dźwiękowych, pozwala wielu graczom zmierzyć się ze sobą przy pomocy połączeń telefonicznych oraz wykonywać wydruk szczegółów gry dla celów planowania strategii.
Testowanie konfiguracji należy zaplanować co najmniej z różnymi kartami graficznymi, dźwiękowymi, modemami i drukarkami. Asystent funkcji Windows Dodaj nowy sprzęt (rysunek 8.4) umożliwia wybranie sprzętu w każdej z tych kategorii – i jeszcz 25-ciu innych.
Rysunek 8.4 Okno dialogowe asystenta Dodaj Nowy Sprzęt umożliwia dodawanie nowych urządzeń do aktualnej konfiguracji PC.
W każdej kategorii sprzętu znajduje się lista różnych producentów i modeli (rysunek 8.5). Pamiętajmy, że to są tylko rodzaje sprzętu, dla którch programy obsługi są wbudowane bezpośrednio w system Windows. Wielu innych producentów sprzętu dostarcza wraż ze sprzętem własne dyski z potrzebnym oprogramowaniem.

Rysunek 8.5 Każdy rodzaj sprzętu ma wielu różnych producentów i wiele modeli.
Chcąc przeprowadzić pełny, obejmujący wszelkie możliwości test konfiguracji, kontrolujący wszelkie rodzaje i modele sprzętu, ma się olbrzymią robotę.
Istnieje w przybliżeniu 336 różnych kart graficznych, 210 kart dźwiękowych, 1500 modemów i 1200 drukarek. Ilość kombinacji testowych wynosi więc 336 x 210 x 1500 x 1200, co daje iloczyn rzędu miliardów – zbyt wiele by móc poważnie o tym myśleć !
Jeśli ograniczyć testowanie tak, by wykluczyć wszelkie kombinacje, tylko testować każdy rodzaj karty osobno, poświęcając około 30 minut na każdą konfigurację, byłoby się gotowym po upływie około roku. Pamiętajmy, wyliczenie dotyczny tylko jednego wykonania testów przez wszelkie kombinacje, a przecież często – uwzględniwszy dostawy z naprawami błędów – trzeba wykonać dwa lub trzy wykonania testów, dopóki produkt nie będzie ostatecznie wypuszczony na rynek.
Rozwiązaniem tego bałaganu jest – czego (należy mieć nadzieję) czytelnik już się domyśla – podział na klasy równoważności. Trzeba znaleźć sposób, jak ograniczyć olbrzymi zbiór wszelkich możliwych konfiguracji tak, aby pozostały tylko najważniejsze. Oczywiście nie testując wszystkiego trzeba będzie podjąć pewne ryzyko, ale przecież właśnie na tym polega test oprogramowania. Jak podejść do zadania
Proces podejmowania decyzji, które urządzenia należy przetestować i w jaki sposób jest w zasadzie nieskomplikowanym zastosowaniem podziału na klasy równoważności. Najważniejsze – kluczowe dla powodzenia projektu – jest znalezienie właściwej informacji przed podjęciem decyzji. Jeśli brak nam doświadczenia z rodzajem sprzętu, jaki testowany program wykorzystuje, trzeba się nauczyć samemu ile się da oraz poprosić innych, doświadczonych testerów i programistów o pomoc. Trzeba zadawać wiele pytań i upewnić się, czy propozycje zostały zaakceptowane.

Następne podrozdziały opisują ogólny proces planowania testowania konfiguracji.
Zdefiniowanie potrzebnych rodzajów sprzętu
Czy aplikacja robi wydruki? Jeśli tak, trzeba będzie przetestować drukarki. Jeśli ma efekty dźwiękowe, trzeba będzie testować karty dźwiękowe. Jeśli jest to program graficzny albo fotograficzny, pewnie przydadzą się skanery i cyfrowe aparaty fotograficzne. Warto uważnie poznać funkcje programu, aby upewnić się, czy niczego ważnego się nie pominąęło w trakcie planowania. Trzeba przez chwilę zastanowić się, czego ten program będzie potrzebował do działania.
Interakcyjna rejestracja
Przykładem funkcji, którą łatwo przeoczyć przy planowaniu, jaki sprzęt należy przetestować, jest rejestracja interakcyjna. Wiele programów umożliwia dzisiaj użytkownikom dokonanie rejestracji podczas instalacji przez modem. Użytkownik wpisuje swoje nazwisko, adres i inne dane, klika na przycisk, a modem dzwoni do komputera i producenta, który przesyła potrzebną informację i dokonuje rejestracji. Nawet jeśli program nie używa takiego połączenia  do żadnej innej pracy oprócz interakcyjnej rejestracji, trzeba zastanowić się, czy modemy mają być częścią testowania konfiguracyjnego.
Zadecydować jakie są dostępne marki, modele i programy obsługi urządzeń
Ten kto wytwarza ostry program graficzny, nie będzie chyba chciał testować jego wydruków na czarno-białej drukarce mozaikowej z roku 1987-ego (pamiętacie je jeszcze?). Listę sprzętu do testowania konfiguracji warto skompilować wspólnie ze sprzedawcami i z osobami zajmującymi się marketingiem. Jeśli nie mogą lub nie chcą pomóc, warto złapać kilka aktualnych i starszych numerów tydnika „PC” i zorientować się, jakie rodzaje sprzętu są dostępne i co było – i jest – popularne. Tego typu czasopisma często publikują różnego rodzaju listy i porównania drukarek, kart dźwiękowych i graficznych.
Warto się zorientować, które z tych urządzeń są klonami i dlatego naeżącymi do tej samej klasy równoważności co oryginał. Zdarza się, że producent drukarek sprzedaje swoje drukarki innej firmie, która następnie umieszcza na nich swoją etykietkę. Z punktu widzenia testowania konfiguracji, mamy do czynienia z tą samą drukarką.
Trzeba też wziąć pod uwagę, które programy obsługi wykorzystać podczas testowania. Do wyboru ma się zwykle program obsługi będący częścią systemu operacyjnego, program dostarczany razem z urządzeniem oraz najnowszą wersję programu obsługi dostępną na Internecie, na stronie producenta urządzenia lub systemu operacyjnego. Zwykle są to trzy różne programy. Trzeba sobie samemu zadać pytanie, co klienci mają lub będą mieć.
Zdefiniowanie możliwych cech, trybów pracy i opcji
Kolorowe drukarki potrafią drukować czarno-biało albo w kolorze, w różnych trybach jakości, mogą też mieć ustawienia dla drukowania fotografii albo tekstu. Karty graficzne, jak pokazano na rysunku 8.6, mogą użuwać różnych ustawień kolorów i różnej rozdzielczości.
Rysunek 8.6 Różne odmiany kolorów i inne właściwości ekranu to przykłady możliwych konfiguracji karty graficznej.
Każde urządzenie ma rozmaite opcje. Testowany program nie musi wykorzystywać wszystkich opcji urządzenia. Dobrym przykładem są gry komputerowe. Wiele z nich wymaga pewnej minimalnej ilości kolorów i pewnej minimalnej rozdzielczości, bez których nie będą działać.
Zmniejszenie liczby konfiguracji do dającej się opanować ilości
Przy założeniu, że nie ma się do dyspozycji czasu ani budżetu by przetestować wszystko, musi się zredukować tysiące możliwych konfiguracji do najważniejszych – tych które się rzeczywiście przetestuje.
Sposobem może być wprowadzenie wszelkich informacje na temat konfiguracji do arkusza kalkulacyjnego, gdzie kolumy oznaczają producenta, model, wersję programu obsługi i wartość opcji. Rysunek 8.7 pokazuje przykład tabeli, która opisuje różne konfiguracje drukarek. Zespól testowy lub jego szef może zapoznać się arkuszem i zdecydowac, jakie konfiuguracje chce się testować.

Popularność (1=największa, 10=najmniejsza)
Typ (laser/atramentowa)
Wiek (w latach)
Producent
Model
Wersja programu obsługi
Opcje
Opcje
1 Laser 3 XXX LDYI2000 1.0 Czarnobiały
Roboczy
Wysokiej jakości
5 Atramento wy
1 XXX IJDIY2000 1.0a Kolor Roboczy
Czarnobiały
Wysokiej jakości Roboczy Wysokiej jakości
5 Atramento wy
1 XXX IJDIY2000 2.0 Kolor Arytstyczny
Czarnobiały
Fotografia
Roboczy Wysokiej jakości
10 Laser 5 YYY LJ100 1.5 Czarnobiały
100 dpi
200 dpi 300 dpi

Atramento wy
2 YYY EasyPront 1.0 Auto 600 dpi

Rysunek 8.7 Warto wprowadzić dane na temat konfiguracji do arkusza kalkulacyjnego.
Warto zwrócić uwagę, że tabela na rysunku 8.7 ma także kolumny na informacje o popularności urządzenia, jego typie i wieku. Konstruując klasy równoważności, można np. podjąć decyzję, że będzie się testowało tyko najpopularniejsze rodzaje drukarek, albo tyko te modele, które mają mniej niż pięć lat. Na podstawie informacji o typie – w tym przykładzie, laserowa albo atramentowA – można zadecydować, że przetestuje się 75% drukarek laserowych i 25% - atramentowych.
Niestety, proces decyzyjny, gdzie dzieli się możliwe konfuguracje na mniejsze klasy równoważności, zależy od wyboru dokonanego przez zespół projektowy. Nie istnieje jedna, wyłącznie poprawna reguła. Każdy projekt wytwarzania oprogramowania jest inny i niełatwo będzie dobrać kryteria klasyfikacji. Wystarczy upewnić się, że każdy w zespole, a zwłaszcza kierownik projektu, zawiadomieni są o tym, co się testuje i w jaki sposób wybrane zostały testowe zmienne, których wartość zadecydowała o podziale.
Zidentyfikowanie tych szczególnych cech oprogramowania, których działanie zależy od konfiguracji sprzętu
Najważniejsze słowo w tytule to szczególne. Nie chodzi o to, by kompletnie przetestować całą aplikację na każdej możliwej konfiguracji. Wystarczy przetestować tylko te cechy, których działanie zależy od sprzętu.
Na przykład, testując program do przetwarzania tekstu taki jak WordPad (zob. rysunek 8.8), nie trzeba będzie np. testować zapisywania i ładowania plików w każdej z konfiguracji. Zapisywanie i ładowanie plików nie ma nic wspólnego z drukowaniem. Dobre dane testowe składałyby się z dokumentu, zawierającego rozmaite (wybrane – oczywiście – przy pomocy podziału na klasy równoważności) czcionki, wielkości, kolory, ilustracje w tekście i tak dalej. Ten dokument drukowałoby się na wszystkich konfiguracjach drukarek.
Rysunek 8.8 Do przetestowania konfiguracji drukarek można używać dokumentu zawierającego różne czcionki i style.

Wybranie funkcji zależnych od konfiguracji i sprzętu może być trudniejsze niż się wydaje na pierwszy rzut oka. Należy zacząc od techniki czarnej skrzynki i przetestować oczywiste pod tym względem funkcje. Potem warto porozmawiać z innymi osobami z zespołu, zwłaszcza z programistami, aby uzyskać obraż „szklanoskrzynkowy”. Nie raż zdziwimy się, odkrywając jak na pozór odległe funkcje w jakimś stopniu mogą zależeć od konfiguracji sprzętu.
Skonstruowanie zadań testowych do użycia na każdej konfiguracji
Jak pisać zadania testowe będzie tematem rozdziału 17-ego, „Pisanie i śledzenie zadań testowych”. Już teraż jednak warto zdać sobie sprawę, że trzeba będzie zanotować wszystkie kroki potrzebne do przetestowania każdej z konfiguracji. Może to być tak proste jak poniższa lista: 1. Wybrać i ustawić kolejną konfigurację z listy 2. Wystartować oprogramowanie 3. Załadować plik configtest.doc. 4. Potwierdzić, że wyślwietlony plik jest prawidłowy 5. Wydrukować dokument 6. Potwierdzic, że nie ma żadnych komunikatów o błędach i że wydrukowany dokument zgodny jest ze standardem 7. Wszelkie rozbieżności notować jako błędy
W rzeczywistości, te instrukcje byłyby znacznie bardziej skomplikowane, zawierające więcej szczgółów na temat tego, co dokładnie należy zrobić. W końcu przecież autor tej specyfikacji nie chciałby osobiście wykonywać tych testów w przyszłości.
Wykonanie testów na każdej konfiguracji
Trzeba wykonać zadania testowe i starannie zarejestrować wyniki i napisać na ich podstawie raport (zob. rozdział 18-y, „Raportowanie tego, co się znalazło”) dla zespołu, a w razie konieczności – także dla producenta. Jak już napisano wcześniej, często zidentyfikowanie źródła problemu z konfiguracją jest trudne i czasochłonne. Trzeba współpracować z programistami i testerami stosującymi metody szklanej skrzynki aby znalęźć przyczyny awarii i zdecydować, czy spowodował ją błąd oprogramowania, czy błąd sprzętu.

Jeśli przyczyną awarii jest błąd sprzętu, należy poszukać w portalu internetowym producenta sposobu raportowania błędów sprzętu. Pisząc raport, warto przedstawić się jako tester oprogramowania i podać nazwę swego pracodawcy. Wiele firm ma osobny personel, który udziela pomocy firmom piszącym oprogramowanie używające ich sprzętu. Dla ułatwienia lokalizacji przyczyny błędu, producent sprzętu może prosić o przesłanie kopii oprogramowania, zadań testowych i szczegółów na temat okoliczności zaistnienia awarii.
Ponowne wykonywanie zadań testowych aż do skutku
Często test konfiguracji ciągnie się przez cały czas trwania projektu. Początkowo próbuje się kilka konfiguracji, potem pełny zestaw, potem znów tylko wybrane konfiguracje dla zweryfikowania zrobionych poprawek. W końcu nadchodzi moment, kiedy nie ma już więcej znanych błędów, a pozostałe błędy występują w rzadkich i mało prawdopodobnych konfiguracjach. W tym momencie są podstawy, aby uznać testowanie konfiguracji za zakończone. Jak zdobyć potrzebny sprzęt
Nie mówiliśmy jeszcze dotąd jak wejść w posiadanie całego tego sprzętu. Nawet dokonując pracochłonnej – i ryzykownej – redukcji zestawu klas równoważności do niezbędnego minimum, nadal potrzebuje się dziesiątek różnych zestawów sprzętu. Kupić wszystko w sklepie jest kosztownym rozwiązaniem, zwłaszcza jeśli niektóre elementy sprzętu użyje się tylko raz. Oto kilka sposobów, aby rozwiązać ten kłopot: 16.Kupuje się tylko tę konfigurację, której się będzie używało najczęściej. Doskonałą metodą jest, aby każdy tester w zespole posługiwał się innym sprzętem. To może doprowadzić działy zaopetrzeniowy i administratorów systemu do szału (dla nich jest najlepiej, aby każdy przcownik posługiwał się identyczną konfiguracją), ale to bardzo skuteczny sposób, aby zawsze móc testować na różnych konfiguracjach. Nawet w małym zespole, mieć do dyspozycji trzy – cztery różne konfiguracje jest bardzo cenne.

17.Warto skontaktować się z producentami i spróbować pożyczyć czy wręcz dostać sprzęt. Jeśli wytłumaczyć, że testuje się nowe oprogramowanie i chce się upewnic, czy działa na ich sprzęcie, wielu producentów może się zgodzić. Oni są również zainteresowani wynikami, więc można im obiecać przekazanie wyników testów, a jak się da – również kopię gotowego oprogramowania. Warto stworzyć dobre relacje, zwłaszcza jeśli znalazło się błąd i potrzenbujemy u producenta kogoś, komu można przekazać informację o błędzie. 18.Można wysłać pocztę komputerową do wszystkich w swojej firmie, z pytaniem jakiego sprzętu używają w pracy, a nawet w domu, i czy pozwoliliby wykonać na nim kilka testów. Wykonując w ten sposób testowanie konfiguracji, trzeba będzie się najeździć, ale ileż to taniej niż kupowanie wszystkiego samemu.
Testowanie konfiguracji magnetowidu
Animowane lalki Microsoftu „ActiMates” miały intefejs nie tylko do PC, ale również do magnetowidu. Specjalne „pudełko” dołączone do magnetowidu odczytywało komendy i wysysłało je do lalki drogą radiową. Zespół testujący miał do dyspozycji wiele konfiguracji PC, ale żadnego magnetowidu.
Znaleziono dwa sposoby rozwiązania problemu:
 Poproszono ponad 300 pracowników, aby przynieśli do pracy swoje magnetowidy. Kierownik ogłosił drobne nagrody dla zachęcenia uczestników.
 Zapłacono kierownikowi w lokalnym sklepie z elektroniką , aby pozostał w pracy po godzinach. W tym czasie testerzy wyciągali z półki każdy magnetowid, podłączali sprzęt i wykonywali test. Każdy pożyczony magnetowid zostł dodatkwo odkurzony i oczyszczony, a kierownikowi który się na to zgodził zafundowano dobry obiad.
Kiedy wszystko było już gotowe, przetestwoano ponad 150 magnetowidów, które stanowiły dobrą  klasę równoważności dla magnetowidów posiadanych przez ludzi.
19.Kto dysponuje własnym budżetem, może spróbować wynająć do testowania zajmujące się zawodowo testowaniem kompatybilności i konfiguracjji laboratorium1. Te firmy zajmują się wyłącznie testowaniem konfiguracji i mają do dyspozycji wszelki znany ludzkości sprzęt PC. No, może nie aż tyle, ale prawie.
Taka firma często jest w stanie pomóc dokonać wyboru właściwego sprzętu, na którym przeprowadzi się testowanie. Następnie ma się do dyspozycji dwie opcje: albo samemu wykonuje się testowanie na sprzęcie firmy, albo można też zakupić pełną usługę. Klient dostarcza oprogramowanie, instrukcje testowanie oraz oczekiwane wyniki. Od tego miejsca pracę przejmuje firma, wykonuje testy i sporządza raporty, które zadania testowe przeszły, a które nie. Bywa to kosztowne, ale na pewno mniej kosztowne niż kupowanie całego sprzętu albo brak testowania i klienci znajdujący błędy. Jak zidentyfikować standardy sprzętu
Kto chciałby poświęcić nieco czasu analizie metodami czarnej skrzynki – to znaczy przejrzeć specyfikacje, używane przez firmy wytwarzające sprzęt komputerowy – może szukać w kilku miejscach. Znając nieco lepiej specyfikację sprzętu będziemy mogli dokonać bardziej świadomego wyboru najwłaściwszych klas równoważności.
Dla sprzętu Apple‘a trzeba zajrzeć na stronę http//:developer.apple.com/hardware. Znajdzie się tam dołączenia na temat wytwarzania i testowania sprzętu i programów obsługi dla komputerów Apple. Inne dołączenie Apple‘a, http://developer.apple.com/testing, zawiera wiadomości na temat testowania, a także dołączenia do laboratoriów zajmujących się testowaniem konfiguracji.
Dla komputerów osobistych, najlepsze dołączenie to http://www.pcdesignguide.org/. Tę witryne sponsorują wspólnie Intel i Microsoft. Znaleźć tam można wiadomości i dołączenia do standardów stosowanych do wytwarzania sprzętu i urządzeń peryferyjnych dla PC. Standardy podlegają corocznej rewizji i otrzymują nazwy PC99, PC2000 i tak dalej.
Micorsoft publikuje zestawienia standardów dla oprogramowania i sprzętu ubiegającego się o znak firmowy Windows. Ta informacja znajduje się na http://msdn.micorsoft.com/certification oraz na http://www.microsoft.com/hwtest. Testowanie konfiguracji innych typów sprzętu
1 Możliwość na razie niedostępna na rynku polskim (przyp. tłumacza).
Cóż więc począć, jeśli testuje się oprogramowanie na innych komputerach niż PC i Mac? Czy cały ten rozdział był marnowaniem czasu? W żadnym razie. Wszystko, czegośmy się tutaj nauczyli, daje się zastosować także do testowania własnych systemów firmowych. Nieważne, o jaki chodzi sprzęt i oprogramowanie, do czego podłączone. Jeśli coś podłączone jest do czegokolwiek innego, testowanie konfiguracji staje się potrzebne.
Testując oprogramowanie dla systemu wbudowanego, sieci, urządzenia medycznego czy systemu telefonicznego, należy sobie zadać te same pytania, co dla komputera osobistego: 20.Jaki zewnętrzny sprzęt będzie pracował z tym oprogramowaniem? 21.Jakie są dostępne modele i wersje tego sprzętu? 22.Jakie funkcje i opcje obsługuje dany sprzęt?
Należy najpierw stworzyć klasy równoważności przy pomocy wiadomości uzyskanych od osób pracujących na danym sprzęcie, kierowników projektów albo sprzedwaców. Następnie wytwarza się zadania testowe, gromadzi potrzebny sprzęt i wykonuje testy. Testopwanie konfiguracji stosuje się do tych samych zasad, których nauczyliśmy się już wcześniej. Podsumowanie
Ten rozdział nauczył nas myśleć na temat testowania konfiguracji. To zadanie często otrzymują do wykonania początkujący testerzy, ponieważ nietrudno je zdefiniować, jest dobrym wprowadzniem do podstawowych danych o firmie i do zastosowania podziału na klasy równoważności w praktyce. Ponadto to zadanie pozwoli na kontakt z wieloma innymi osobami z projektu, a kierownictwo bez trudu samo zweryfikuej jego wyniki. Ma też wadę – jest przygnebiająco rozległe.
Jeśli otrzymało się za zadanie test komnfiguracji w projekcie, należy wziąć głeboki oddech, ponownie przeczytać ten rozdział, uważnie zaplanować pracę i wykazać wiele cierpliwości. Kiedy wszystko będzie już gotowe, szef przyjdzie z kolejnym wyzwaniem: testowaniem kompatybilności, tematem kolejnego rozdziału. 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.Jaka jest różnica między komponentem a urządzeniem peryferyjnym? 2. Jak odróznić, czy błąd jest ogólnym problemem, czy też wyłącznie błędem konfiuracji? 3. Jak można zagwarentować, że program nigdy nie będzie miał błędów konfiguracji?
4. Prawda czy fałsz: klonowana karta dzwiękowa nie musi być poddana testowaniu konfiguracji. 5. Oprócz wieku oraz popularności, jakie inne kryteria można zastosować jako podstawę podziału na klasy równoważności? 6. Czy dopuszczalne jest wypuszczenie programu mającego błędy konfiguracji?

Rozdział 7 Testowanie pod rentgenem
W TYM ROZDZIALE Dynamiczne testowanie metodami szklanej skrzynki Dynamiczne testowanie a lokalizowanie i usuwanie błędów Test komponentów Pokrycie danych Pokrycie kodu
Jak dotąd w części II-iej poznaliśmy trzy spośród czterech podstawowych technik testowania: statyczne testowanie metodami czarnej skrzynki (testowanie specyfikacji), dynamiczne testowanie metodami czarnej skrzynki (testowanie oprogramowania) i statyczne testowanie metodami szklanej skrzynki (badanie i analiza kodu źródłowego). W tym rozdziale zapoznamy się z czwartą podstawową techniką – dynamicznym testowaniem metodami szklanej skrzynki. Testując oprogramowanie, będziemy zaglądać do wnętrza „skrzynki” jakby przy pomocy rentgena.
Oprócz rentgenowskich okularów, trzeba też będzie wystąpić pod flagą programisty – o ile ma się do tego kompetencje. Jeśli komuś brak znajomości programowania, nie trzeba się zrażać. Podane w rozdziale przykłady nie są zanadto skomplikowane i przyłożywszy się, każdy jest w stanie je śledzić. Zrozumiawszy choć w części tę grupę technik testowych, można stać się o wiele skuteczniejszym testerm.
Jeśli ma się pewne doświadczenie w programowaniu, ten rozdział otwiera bardzo szerokie możliwości. Większość firm produkujących oprogramowanie zatrudnia testerów właśnie do testowanie na niskim poziomie. Poszukiwane są osoby mające umiejętności zarówno w programowaniu jak i w testowaniu, co jest rzadkim i często poszukiwanym połączeniem.
Najważniejsze punkty tego rozdziału: 157.Czym jest dynamiczne testowanie metodami szklanej skrzynki 158.Różnica między dynamicznym testowaniem metodami szklanej skrzynki a usuwaniem błędów z programu 159.Co to jest testowanie jednostkowe i testowanie integracyjne 160.Jak testować funkcje na niskim poziomie 161.Rodzaje danych które trzeba testować na niskim poziomie
162.Jak zmuszać program do wymaganego sposobu działania 163.Jakimi różnymi metodami można zmierzyć staranność testowania Dynamiczne testowanie metodami szklanej skrzynki
Znamy już na pewno bardzo dobrze pojęcia statyczny, dynamiczny, metody szklanej skrzynki i metody czarnej skrzynki, tak że wiedząc, że ten rozdział zajmie się testowaniem dynamicznym metodami szklanej skrzynki, powinniśmy się łatwo domyśleć jego treści. Skoro jest dynamiczne, to znaczy że program musi być uruchamiany, a skoro jest metodami szklanej skrzynki, to znaczy że zagląda się „do środka pudełka”, analizuje kod i obserwuje jak jest wykonywany. Testuje się jakby z rentgenem na oczach.
Dynamiczne testowanie metodami szklanej skrzynki posiłkuje się informacją zdobytą przez obserwowanie chodzącego kodu. Ta informacja jest wykorzystywana aby zadecydować co testować, czego nie testować, i w jaki sposób podejść do testowania. Inną powszechnie stosowaną nazwą na dynamiczne testowanie metodami szklanej skrzynki jest testowanie strukturalne, ponieważ widzi się przy nim i wykorzystuje strukturę kodu do konstruowania i do wykonywania zadań testowych.
Jakie pożytki mogą wynikać ze znajomości tego, co dzieje się „wewnątrz pudełka”, jak działa oprogramowanie? Spójrzmy na rysunek 7.1. Pokazane są na nim dwa pudełka, realizujące podstawowe operacje arytmetyczne: dodawanie, odejmowanie, mnożenie i dzielenie.
Rysunek 7.1 Wybrałoby się inne zadania testowe wiedząc, że pudełku jest komputer i inne, jeśli w pudełku siedziałby człowiek z papierem i ołówkiem.
Jeśli nie wie się, jak działa pudełko, wybrałoby się dynamiczne techniki czarnej skrzynki, które zostały opisane w rozdziale 5-ym, „Testowanie z klapkami na oczach”. Gdyby jednak zajrzeć do pudełek i zobaczyć, że jedno z nich zawiera komputer, a w drugim ukrywa się człowiek z ołówkiem i papierem, wybrałoby się przypuszczalnie dla nich zupełnie odmienne zestawy testów. Oczywiście, to bardzo uproszczony przykład, ale dobrze ilustruje jak znajomość sposobu działania programu wpływa na sposób testowania.
Dynamiczne testowanie metodami szklanej skrzynki oznacza więcej niz tylko oglądanie pracy kodu, może również oznaczać bezpośrednie testowanie i kontrolę oprogramowania. Dynamiczne testowanie metodami szklanej skrzynki obejmuje cztery obszary: 164.Bezpośrednie testowanie na niskim poziomie funkcji, procedur, rutyn i bibliotek. W Windowsach nazywane one są zwykle interfejsem programistycznym (API). 165.Testowanie oprogramowania na najwyższym poziomie, jako gotowy program, z tym że zadania testowe oparte są rónież na tym, co się wie o sposobach jego działania. 166.Uzyskanie dostępu do do zmiennych w kodzie i do informacji o jego stanie ułatwi sprzwdzenie, czy testy są właściwie skonstruowane. Również daje to możliwośc „zmuszenia” programu do innego działania , niż dałoby się osiągnąć testując tylko technikami czarnej skrzynki. 167.Pomiary, jaka część kodu i specyfikacji została rzeczywiście przetesowana – i uzupełnienie zestawu zadań testowych o nowe, jeśli nie idało się osiągnąć pożądanego pokrycia kodu.
Każdy z tych czterech obszarów będzie przedyskutowany w pozostałej części rozdziału. Warto to wziąć pod uwagę czytając dalej i zastanowić się, na ile te techniki przydałyby się do testowania programów. Dynamiczne testowanie a lokalizowanie i usuwanie będów
Nie należy mieszać dynamicznego testowania metodami szklanej skrzynki z lokalizacją i usuwaniem błędów. Kto zajmował się programowaniem, na pewno spędził wiele godzin lokalizując i usuwając błędy w napisanym przez siebie kodzie. Obie czynności wydaja się podobne, ponieważ obie zajmują się błędami w oprogramowaniu i obie „grzebią się” w kodzie, ale ich cele są zupełnie odmienne (rysunek 7.2).
Rysunek 7.2 Dynamiczne testowanie metodami szklanej skrzynki oraz lokalizowanie i usuwanie błędów mają różne cele, ale zazębiają się.
Celem testowania jest znajdowanie błędów. Celem lokalizacji i usuwania błędów jest ich likwidacja. Te rejony zazębiają się tam, gdzie staramy się błąd wyizolowac i zidentyfikować jego przyczynę. Dowiemy się na ten temat więcej w rozdziale 18-ym „Raportowanie wyników”, ale na razie przyjmijmy uproszczone wytłumaczenie. Tester oprogramowania ma za zadanie zawęzic problem do naprostszego możliwego testu, który wywołuje symptom poszukiwanego błędu. Testując metodami szklanej skrzynki, możemy często nawet zidentyfikować ”podejrzany” fragment kodu. Programista zajmujący się lokalizowaniem i usuwaniem błędu przejmuje pałeczkę w tym właśnie miejscu, ustala dokładnie przyczynę błędu i usiłuje ją usunąć.
Ważne jest umieć rozdzielić w praktyce pracę testera i programisty. Programiści piszą kod, testerzy szukają i znajdują błędy i czasem piszą nieco kodu do automatyzacji testów; programiści poprawiają błędy. Bez wyraźnego podziału, pewne zadania mogą zostać przez obie strony pominięte, albo – przeciwnie – jakaś praca zostanie wykonana dwa razy.
Testując na niskim poziomie w pobliżu kodu, używa się wielu tych samych narzędzi co programiści. Jeśli program jest kompilowany, tester również go kompiluje, ewentualnie z innymi ustawieniami dla umożliwienia łatwiejszego wykrywania błędów. Tester używa też prawdopodobnie tego samego programu śledzącego aby wykonywać program pojedynczymi krokami, obserwowac wartość zmiennych, ustawiać punkty zatrzymania itd. Często też pisze się własne programy, np. aby móc przetestować pojedyncze moduły. Testowanie kawałków
Przypomnijmy sobie z rozdziału 2-iego „Proces wytwarzania oprogramowania” różne modele wytwarzania oprogramowania. Model skokowy był najprostszy, ale też najbardziej chaotyczny. Wszystko łączy się ze sobą na raz, zaciska kciuki i można mieć nadziję, że powstanie z tego gotowy produkt. Łatwo się domyśleć, że testowanie przy tym trybie pracy jest bardzo trudne. Co najwyżej można przystąpić do testowania dynamicznego metodami czarnej skrzynki, biorąc program w jednym dużym kawałku i próbując, co też dałoby się znaleźć.
Nauczyliśmy się już że taka metoda jest bardzo kosztowna, ponieważ błędy znajduje się bardzo późno w procesie wytwórczym. Z punktu widzenia testu, istnieją dwie główne przyczyny tych wysokich kosztów: 168.Trudno – a czasem wręcz niemożliwe – jest zorientować się, co jest przyczyną awarii. Oprogramowanie jest jak zepsuty czarodziejski stolik – choć wypowiedziało się zaklęcie „stoliczku nakryj się”, żadne potrawy się nie pojawiły. Nie sposób zgadnąć, jaki drobiazg szwankuje i powoduje, że całość nie działa. 169.Jedne błędy mogą zasłaniać inne błędy. Zadanie testowe wywołuje awarię, programista spokojnie znajduje  i usuwa błąd, ale kiedy wykonuje się zadanie testowe ponownie, znów następuje awaria. Tak wiele różnych błędów nałożyło się jedne na drugie, że bardzo czasochłonne robi się dotarcie do pierwszej przyczyny.
Test komponentów i test integracyjny
Żeby wybrnąć z tego całego bałaganu, najlepiej do niego po prostu nie dopuścić. Jeśli kod powstaje i jest testowany po kawałku, a potem stopniowo składa się go w większe całości, nię będzie tylu niespodzianek, kiedy w końcu połączy się cały produkt (rysunek 7.3).
Program główny Moduł   Moduł …
Rysunek 7.3 Poszczególne fragmenty kodu buduje się i testuje pojedynczo, potem integruje ze sobą i testuje ponownie.
Testowanie na najniższym poziomie nazywane jest testowaniem jednostkowym&testowaniem komponentów albo testowaniem modułu1. Moduły są testowane, błędy w nich znajdowane i usuwane, po czym następuje integracja i test integracyjny grup modułów. Proces przyrostowego testowania przebiega stopniowo, łącząc ze sobą coraz więcej i więcej modułów, aż wreszcie cały produkt – a przynajmniej jego większa część – zostaje przetestowana w całości w ramach testowania systemu.
Kiedy stosuje się tę strategię testowania, identyfikacja i lokalizacja błędów stają się o wiele łatwiejsze. Problem znaleziony na poziomie modułu z reguły musi znajdować się w tym samym module. Jeśli następuje awaria podczas łączenia przedtem przetestowanych z osobna modułów, to jej źródłem jest przypuszczalnie interakcja między modułami. Zdarzają się wyjątki od tej zasady, ale ogólnie rzecz biorąc, testowanie i lokalizacja błędów przebiega wtedy znacznie sprawniej niż kiedy testuje się wszystko na raz.
Istnieją dwie główne metody integracji przyrostowej: oddolny i odgórny. W testowaniu oddolnym (rysunek 7.4) testerzy piszą własne procedury, zwane sterownikami, które przywołują testowany moduł. Podłącza się moduły dokładnie w ten sam sposób jak w pełnym programie. Sterowniki wysyłają dane testowe do testowanych modułów, odczytują wyniki i weryfikują, czy są poprawne. W ten sposób daje się zwykle przetestwoać oprogramowanie bardzo szczegółowo, przy użyciu bardzo różnorodnych danych testowych, nawet takich które trudno byłoby zastosować podczas testowania kompletnego systemu.
Rzeczywiste oprogramowanie
Temperatura Wyniki Moduł konwersji z oF na oC
Konfiguracja w świecie rzeczywistym
Oprogramowanie sterownika
Dane testowe     Wyniki Moduł konwersji z oF na oC
Konfiguracja sterownika testowego
Rysunek 7.4 Sterownik testowy może zastąpić część oprogramowania i przetestować bardzo dokładnie moduł niższego rzędu.

Integracja odgórna brzmi trochę jak skokowa w mniejszej skali. W końcu jeśli gotowy jest główny program, musi być za późno brać się za testowanie modułów? Nie całkiem jest to prawdą. Spójrzmy na rysunek 7.5. W tym wypadku, moduł interfejsu na niskim poziomie zbiera dane o temperaturze z elektronicznego termometru. Moduł wyświetlacza umieszczony jest tuż ponad interfejsem, skąd czyta dane i wyświetla je na ekranie dla użytkownika. Aby przetestować górny moduł wyświetlacza na gotowym systemie, trzeba by posługiwać się palnikami, woda, lodem i zamrażarką, żeby spowodować zmiany temperatury czujnika, przekazywane do modułu wyświetlającego.
Zamiast jednak testować moduł wyświetlacza usiłując sterować temperaturą termometru, można napisać fragment kodu, zwany namiastką, który działa tak jak interfejs, podając temperatury - zapisane np. na pliku - wprost do modułu wyświetlającego. Moduł wyświetlający odczytuje przekazywane dane tak samo, jakby je czytał wprost z interfejsu prawdziwego termometru. Nie jest w stanie dostrzec żadnej różnicy. Używając namiastek, można – w tym wypadku – szybko przetestować moduł wyświetlacza przy użyciu wielkiej ilości danych testowych i dokonać walidacji tego modułu.
Moduł wyświetlacza temperatury
Moduł interfejsu termometru
Konfiguracja w świecie rzeczywistym
Testowany moduł wyświetlacza temperatury
Namiastka skonstruowana przez testera
Plik z danymi testowymi
Konfiguracja sterownika testowego
Rysunek 7.5 Namiastka testowa przesyła dane do góry, do testowanego modułu.
Przykład testu modułu
Funkcją dostępną w wielu językach programowania jest konwersja ciągu znaków ASCII w wartość całkowitoliczbową.
Ta funkcja przyjmuje ciąg cyfr, znaki ‘-‘ lub ‘+‘ oraz możliwe dodatkowe znaki jak spacja oraz litery, i przekształca je w wartość liczbową. Na przykład, ciąg znaków „12345” zostaje przekształcony w liczbę dwanaście tysięcy trzysta czterdzieści pięć. Tej funkcji używa się często do przetwarzania danych z okna dialogowego – na przykład czyjś wiek albo inne dane.

W języku C ta funkcja nazywa się atoi(), co jest skrótem nazwy „ASCII na liczbę całkowitą”1. Rysunek 7.6 pokazuje specyfikację tej funkcji. Kto nie jest programistą, nich się nie denerwuje. Oprócz pierwszej linijki, określającej jak funkcję się przywołuje, specyfikacja jest napisana w zwykłej polszczyźnie i można jej używać do opisu tej samej funkcji dla dowolnego języka programowania.
Co powinien zrobić tester, któremu przypadło zadanie wykonania dynamicznego testowania – metodami szklanej skrzynki – tego modułu?
int atoi (const char *string) Funkcja „z ASCII na liczbę całkowitą” przekłada ciąg znaków na liczbę całkowitą.
Wartość powrotna Funkcja zwraca wartość całkowitoliczbową, powstałą przez potraktowanie ciągu znaków na wejściu jako zapisu liczby. Wartość powrotna wynosi 0 jeśli dane z wejścia nie dadzą się przkształcić na liczbę całkowitą. Wartość powrotna jest niezdefiniowana w wypadku przepełnienia.
Parametr wejściowy ciąg znaków Ciąg znaków który ma być przekształcony.
Uwagi Ciąg znaków na wejściu jest sekwencją znaków, którą można zinterpretować jako wartość liczbową. Funkcja przestaje czytać ciąg znaków po natrafieniu na pierwszy znak, którego nie daje się zinterpretować jako części składowej liczby. Ten znak może być znakiem zerowym (`\0`) zakańczającym ciąg znaków.
Ciąg znaków dla tej funkcji ma postać: [pusty znak] [znak plus/minus] cyfry
Pusty znak może być spacją i/albo znakiem tabulacji, które są pomijane; znak plus/minus to albo plus (+), albo minus (-); cyfry to to jeden lub więcej cyfr dziesiętnych. Funkcja nie rozpoznaje punktu dziesiętnego, potęg ani żadnych innych, niewymienionych powyżej znaków. Rysunek 7.6 Specyfikacja funkcji atoi() w języku C. Wydaje się od razu, że ten moduł wygląda jak moduł na najniższym poziomie, taki który jest przywoływany przez inne moduły, ale sam niczego nie przywołuje. Można to ewentualnie potwierdzić, czytając kod modułu. Jeśli tak jest, to logiczną metodą będzie napisanie sterownika testowego, aby móc sprawdzać ten moduł niezależnie od reszty programu.
Sterownik testowy wysyłałby skonstruowane przez testera ciągi znaków do funkcji atoi(), odbierał wynik i porównywał go z oczekiwanym rezultatem. Najprawdopodobniej, sterownik testowy zostałby napisany w tym samym języku, co testowana funkcja – w tym wypadku, w języku C – ale daje się też pisać sterowniki w innych językach, byle miały one interfejs do języka, w którym napisany jest testowany moduł.
Sterownik testowy może przybierać różne kształty. Może to być proste okno dialogowe, jak na rysunku 7.7, którego używa się do wprowadzania ciągów znaków i do obserwacji wyników. Mógłby to być osobny program, czytający ciągi znaków i oczekiwane wyniki z pliku. Okno dialogowe, sterowane przez użytkownika, jest interakcyjne i bardzo elastyczne – można je udostępnić rónież testerowi stosującemu techniki czarnej skrzynki. Z drugiej strony, osobny program może działać o wiele szybciej, czytając dane testowe i zapisując wyniki bezpośrednio na pliku.
Rysunek 7.7 Sterownik testowy w postaci okna dialogowego może być zastosowany, aby posyłać zadania testowe testowanemu modułowi.
Następnie należałoby zanalizować specyfikację i zadecydować, jakie zadania testowe typu czarnej skrzynki warto wypróbować, a w końcu zastosować podział na klasy równoważności aby zmniejszyć ich ilość (przypomnijmy sobie rozdział 5-y). Tabela 7.1 pokazuje przykłady zadań testowych wraz z ciągami znaków stosowanych jako dane wejściowe oraz oczekiwanymi wynikami wyjściowymi. Tabela ta nie ma być wyczerpująca.
Tabela 7.1 Przykładowe zadania do testowania przekształcenia ciągu ASCII w liczbę całkowitą.
Ciąg znaków (na wejściu) Wartość na wyjściu „1” 1 „-1” -1 „+1” 1 „0” 0 „-0” 0 „+0” 0 „1.2” 1 „2-3” 2 „abc” 0 „a123” 0 i tak dalej

Wreszcie należałoby również rzucić okiem na kod źródłowy, zobaczyć z jaki sposób zrobiono implementację funkcji i wykorzystac tę „szkalnoskrzynkową” wiedzę na temat modułu, aby dodać lub usunąć zdania testowe.
Ważne, aby zadanie testowe typu „czarnoskrzynkowego”, oparte na specyfikacji, konstruować zanim zacznie się stosowac metody szklanej skrzynki. W ten sposób testuje się w pierwszy rzędzie to, co moduł powinien wykonywać. Jeśli natomiast zacząć od zadań testowych sporządzonych według metod szklanej skrzynki, to jest poprzez analizę kodu, łatwo zatracić bezstronność i konstruować zadania testowe na podstawie tego, jak moduł rzeczywiście działa. Jednak programista mógł przecież nie zrozumieć specyfikacji i wtedy zadania testowe skonstruowane przez testera będą tak samo błędne. Owszem, mogą być dokładne, znakomicie „testujące” moduł, ale nie będą trafne, ponieważ nie będą testować właściwego działania.
Dodawanie i odrzucanie zadań testowych przy użyciu wiedzy na temat kodu jest w istocie szczególnym zastosowaniem metody podziału na klasy równoważności przy zastosowaniu informacji „wewnętrznych”. Pierwotne zadania testowe mogły zakładać, że zadania takie jak „a123” i „z123” są istotnie różne. Analiza kodu mogłaby jednak ujawnić, że zamiast posługiwać się tabelą ASCII, programista ograniczyl się do poszukiwania znaków pustych, znaków ‘+‘ i ‘-‘ oraz cyfr. Mając tę informację, jedno z powyższych zadań testowych można spokojnie odrzucić, ponieważ oba znajdują się w tej samej klasie równoważności.
Inna sytuacja – dokładniejsza analiza kodu mogłaby na przykład ujawnić, że identyfikowanie znaków ‘+‘ i ‘-‘ wygląda trochę podejrzanie – może po prostu trudno jest je zrozumieć. W tej sytuacji, warto dla upewnienia się dodać kilka zadań testowych ze znakami ‘+‘ i ‘-‘ rozrzuconymi w różnych miejscach. Pokrycie danych Powyższy przykład testowania funkcji atoi() metodami szklanej skrzynki był znacznie uproszczony i pomijał wiele szczegółów na temat wpływu analizy kodu na dobór zadań testowych. W rzeczywistości analiza kodu jest czymś więcje niż źródłem dobrych poysłów, co testować, a czego nie warto.
Należy – tak samo jak to się robi w testowaniu metodami czarnej skrzynki – podzielić kod na dane i stany (albo przepływ sterowania). Stosując ten punkt widzenia, o wiele łatwiej odnieść uzyskaną informację na temat kodu do wcześniej skonstruowanych zadań testowych metodami czarnej skrzynki.
Weźmy najpierw pod uwagę dane. Do danych zaliczają się wszystkie zmienne, stałe, wektory, inne struktury danych, dane wejściowe z klawiatury i z myszy, dane wejściowe i wyjściowe z plików i z ekranu, wjeście/wyjście z innych urządzeń jak modemy, sieci i tak dalej.

Przepływ danych
Badanie pokrycia przepływu danych polega na prześledzeniu całej drogi przez fragment programu jednego „kawałka” danych. Na poziomie testowania jednostkowego oznacza to przepływ danych przez pojedynczy moduł. Można także prześledzić drogę danych przez kilka zintegrowanych modułów albo nawet przez całe oprogramowanie – aczkolwoiek byłoby to bardzo czasochłonne.
Testując funkcję na tak niskim poziomie, używa się programu śledzącego i obserwuje wartości zmiennych w czasie wykonywania programu (rysunek 7.8). Stosując testowanie czarnej skrzynki, zna się tylko wartość zmiennej na początku i na końcu. Stosując dynamiczne testowanie szklanej skrzynki, można też sprawdzać wartości pośrednie podczas wykonywania programu. Biorąc pod owagą poczynione obserwacje, można zmodyfikować zadania testowe tak, aby wymusić przyjęcie przez zmienne interesujących czy ryzykownych wartości pośrednich.
Rysunek 7.8 Program śledzący i obserwacja zmiennych umożliwia śledzenie wartości zmiennych w czasie wykonywania programu.
Wewnętrzne wartości graniczne
Wewnętrzne wartości graniczne omawiane już były w rozdziale 5-ym w odniesieniu do wbudowanych tabel ASCII i do wartości potęgi dwójki. To są przypuszczalnie najczęściej spotykane wewnętrzne wartości graniczne powodujące błędy, ale każdy fragment kodu będzie też miał swoje własne, specjalne wewnętrzne wartości graniczne. Oto kilka przykładów: 170.Moduł służący do wyliczania podatków może przy progu podatkowym zmienić sposób naliczania z tabeli wartości na użycie arytmetycznego wyrażenia do obliczeń. 171.System operacyjny może zacząć przenosić dane do pamięci tymczasowej na dysku kiedy zaczyna brakować pamięci RAM. Wartość tej granicy nie musi być nawet ustalona z góry, może się zmieniać zależnie od tego, ile miejsca pozostało na dysku.

172.Dla uzyskania większej dokładności, złożony algorytm numeryczny może zmieniać użwaną formułę obliczeń zależnie od wielkości liczby.
Przy testowaniu metodami szkalnej skrzynki należy uważnie badać kod w poszukiwaniu wewnętrznych wartości granicznych, aby móc dorobić dla nich dodatkowe zadania testowe. Warto spytać programistę, który napisał kod, czy potrafi zidentyfikować takie miejsca, i zwrócić baczną uwagę na wewnętrzne tabele danych, które są szczególnie podatne na problemy wewnętrznych wartości granicznych.
Wzory i równania
Bardzo często wzory i równania ukryte są głęboko w kodzie i ich obecność ani skutki nie są oczywiste, kiedy się patrzy z zewnątrz. Program finansowy do obliczania procentu złożonego na pewno będzie gdzieś zawierał nastąpujący wzór:
A = P (1 + r/n)nt
gdzie P = suma wyjściowa r = roczna stopa procentowa n = ilość razy, kiedy w ciągu roku nalicza się procent t = ilość lat A = suma po upływie czasu t Dobry tester posługujący się metodami czarnej skrzynki wybrałby, należy mieć nadzieję, zadanie testowe gdzie n=0, ale tester stosujący metody szklanej skrzynki, zobaczywszy ten wzór w kodzie, na pewno zastosuje n=0, ponieważ spowoduje się w ten sposób awarię wzoru i błąd dzielenia przez zero. Cóż się jednak stanie, jeśli wartość n jest wynikiem innych obliczeń? Może program ustala wartość n na podstawie danych wprowadzanych przez użytkownika, albo algorytm wypróbowuje różne warotści n w celu znalezienia takiej, dla której wynik będzie najniższy. Należy zadać sobie pytanie, czy istnieje możliwość, że n kiedykoliwek otrzyma wartość zero i odkryć, jakie dane trzeba wprowadzic do programu aby to uzyskać.
Należy przeszukiwać kod w poszukiwaniu wzorów i równań, badać używane w nich zmienne i konstruować zadania testowe oparte na dodatkowych klasach równoważności, jako dodatek do klas równoważości dla danych wejściowych i wyjściowych programu.
Wymuszanie awarii
Ostatnim rodzajem omawianych w tym rozdziale testów opartych na danych jest wymuszanie awarii. Jeśli używa się programu śledzącego, można nie tylko obserwować warości zmiennych, ale również je modyfikować.
W omawianym przykładzie obliczania procentu złożonego, jeśli nie znajduje się sposobu nadania zmiennej n wartości zerowej, można nadać jej warość zero przy pomocy programu śledzącego. Program albo sobie z tym poradzi… albo nie.
Warto pamiętać, że przy pomocy programu śledzącego można stworzyć sytuację, która nigdy nie może zaistnieć przy normalnym użytkowaniu programu. Jeśli program kontroluje że warość n jest większa od zera na początku funkcji, a zmiennej n później do niczego co może zmienić jej wartość już się nie używa, to nadanie jej wartości zerowej i spowodowanie w ten sposób awarii programu jest niedozwolonym zadaniem testowym.
Wymuszanie awarii może być skuteczną metodą, o ile stosować ją ostrożnie i z namysłem, sprawdzając razem z programistami, że wybrane zadania testowe są dozwolone. Można w ten sposób wykonywac zadania testowe, w przeciwnym razie trudne lub niemożliwe do osiągnięcia.
Wymuszanie komunikatów o błędach
Wymuszanie awarii jest świetną techniką, aby wywołać pojawienie się wszelkich możliwych komunikatów o błędach, ukrytych w programie. Wiele programów stosuje wewnętrzne kody dla oznaczenia każdego komunikatu o awarii. Kiedy wewnętrzna flaga sygnalizująca błąd jest ustawiona, procedura obsługi błędu odczytuje zmienną zawierającą ten kod i wyświetla odpowiedni komunikat.
Wiele błędów trudno jest zaaranżować – jak na przykład podłączenie 2049 drukarek. Jeśli jednak chce się tylko skontrolować, że poprawny jest sam komunikat o błędzie, (ortografia, słownictwo, format itd), wymuszanie błędów może być bardzo skutecznym sposobem, żeby je wszystkie zobaczyć. Trzeba tylko pamiętać, że w ten sposób  testuje się kod wyświetlający komunikat o błędzie, a nie kod wykrywający błąd. Pokrycie kodu

Tak jak z testowaniem metodami czarnej skrzynki, testowanie danych to dopiero połowa bitwy. Dla osiągniecia wyczerpującego pokrycia należy również przetestować stany programu i przepływ kontroli między nimi. Trzeba sprawdzić wejścia i wyjścia każdego modułu, wykonać każdą linijke kodu, i prześledzić każdą ścieżkę przez program1. Badanie oprogramowania na tym poziomie nosi nazwę analizy pokrycia kodu.
Analiza pokrycia kodu jest dynamiczną techniką szklanej skrzynki, ponieważ wymaga pełnego dostępu do kodu, aby móc obserwować te fragmenty programu, przez które się przechodzi podczas wykonywania zadań testowych.
Najprostszą formą analizy pokrycia kodu jest zastosowanie programu śledzącego, by obserwować które linie kodu się przechodzi podczas jego wykonywania pojedynczymi krokami. Rysunek 7.9 pokazuje przykład programu śledzącego dla Visual Basic w działaniu.
Rysunek 7.9 Program śledzący umożliwia przyjście programu pojedynczymi krokami aby skontrolować, które linie kodu i które moduły przechodzi się podczas wykonywania zadań testowych.
Dla bardzo małych programów albo pojedynczych modułów ten sposób może być całkiem zadowalający. Jednak aby móc przeprowadzić analizę pokrycia kodu dla większości programów, trzeba się posługiwać specjalnym narzędziem, zwanym jako analizator pokrycia kodu. Rysunek 7.10 pokazuje przykład takiego narzędzia.
Analizator pokrycia kodu podłącza się do testowanego programu i jest egzekwowany w tle, kiedy wykonuje się zadania testowe. Kiedy wykonywanie przechodzi przez funkcję, linijkę kodu albo punkt decyzyjny, analizator zapisuje informację o tym. Po zakończonym wykonywaniu można uzyskać dane statystyczne, które identyfikują fragmenty kodu, przez które się przeszło i te, przez które się nie przeszło podczas testowania. Mając te dane wie się następujące rzeczy:
173.Które części kodu nie zostały pokryte przez zastosowane testy. Jeśli kod znajduje się w odrębnym module, którego się nigdy nie przeszło, wiadamo że trzeba się zabrać za tworzenie dodatkowych zadań testowych, aby przetestować działanie tego modułu.
 
Rysunek 7.10 Analizator pokrycia kodu dostarcza szczegółowych danych o skuteczności zastosowanych zadań testowych (rysunek jest własnością i został wydrukowany za zezwolenienm Bullseye Testing Technology.) 174.Które zadania testowe są zbędne. Jeśli wykonanie serii zadań testowych nie zwiększa stopnia pokrycia kodu, to przypuszczalnie należą wszystkie one do tej samej klasy równoważności. 175.Jakie nowe zadania testowe trzeba skonstruować aby osiągnąć lepsze pokrycie. Należy zanalizować fragmenty kodu gdzie pokrycie jest słabe, zrozumieć jego działanie i sporządzić nowe zadania testowe, które wykorzystają ten kod.
Osiąga się także wyczucie jakości testowanego oprogramowania. Jeśli pokrycie kodu wynosi 90% i nie znajduje się wielu błędów, oprogramowanie jest zapewne w dobrym stanie. Jeśli, przeciwnie, testy osiągnęły ledwo 50% pokrycia kodu i nadal znajduje się błędy, trzeba spodziewać się jeszcze wiele pracy.
Pokrycie linii kodu
Najprostszą formą pokrycia kodu jest tak zwane pokrycie instrukcji albo pokrycie linii kodu. Monitorowanie pokrycia instrukcji w trakcie testowania oznacza zwykle, że celem jest wykonanie choć raz każdej instrukcji w programie. Dla krótkiego programu, jak ten na wydruku 7.1, 100% pokrycia instrukcji oznacza wykonanie linii od 1-ej do 4-ej.
Wydruk 7.1 Bardzo łatwo jest przetestować każdą linię tego prostego programu PRINT „Czołem, Świecie”
PRINT „Dzisiejsza data: „; Date$ PRINT „Jest godzina: „; Time$ END Nietrudno ulec złudzeniu, że 100% pokrycia instrukcji oznacza, że program został przetestowany całkowicie. Celem i sygnałem do zaprzestania testów byłoby osiągniecie 100% pokrycia. Niestety, to tylko złudzenie. Przetestowanie każdej instrukcji programu nie oznacza, że przetestowało się również wszystkie możliwe ścieżki przez program.
Pokrycie rozgałęzień programu
Testowanie w celu pokrycia jak największej ilości możliwych ścieżek przez program nazywane jest testowaniem ścieżek. Najprostszą formą testowania ścieżek jest testowanie rozgałęzień. Spójrzmy na program pokazany na wydruku 7.2.
Wydruk 7.2 Instrukcja IF stwarza rozgałęzienie w kodzie PRINT „Czołem Świecie„ IF Date$ = „2000-01-01” THEN PRINT „Dosiego Roku!” ENDIF PRINT „Dzisiejsza data: „; Date$ PRINT „Jest godzina: „; Time$ END Jeśli ma się na celu osiągnąć 100% pokrycia instrukcji, wystarczy jedno zadanie testowe, gdzie zmienna Date$ ma wartość 1 stycznia 2000. Program wykona wówczas następującą ścieżkę:
Linie 1, 2, 3, 4, 5, 6, 7
Analizator pokrycia kodu określiłby, że przetestowana została każda instrukcja i że osiągnięto 100% pokrycia. No to jesteśmy gotowi z testowaniem, prawda? Nieprawda! Przetestowana została każda instrukcja, ale nie każde rozgałęzienie.
Instynkt podpowiada, że należałoby jeszcze wykonać zadanie testowe z datą inną niż 1-y stycznia 2000. Wówczas program wykona inną ścieżkę:
Linie 1, 2, 5, 6, 7
Większość analizatorów pokrycia podaje osobno wyniki pokrycia instrukcji i pokrycia rozgałęzień, co pozwala sobie wytworzyć o wiele lepsze pojęcie o skuteczności testowania.
Pokrycie warunków logicznych
Kiedy juz myśleliśmy, że wszystko gotowe, pojawia się nowa trudnośc w testowaniu ścieżek. Wydruk 7.3 jest odmianą wydruku 7.2. Dodany został nowy warunek do instrukcji IF w drugiej linii, kontrolujący zarówno czas jak i datę. Testowanie warunków logicznych uwzględnia złożone warunki logiczne w instrukcji warunkowej.
Wydruk 7.3 Złożony warunek w instrukcji IF powoduje, że pojawia się więcej różnych ścieżek przez kod PRINT „Czołem Świecie„ IF Date$ = „2000-01-01” AND Time$ = „00:00:00” THEN PRINT „Dosiego Roku!” ENDIF PRINT „Dzisiejsza data: „; Date$ PRINT „Jest godzina: „; Time$ END Aby uzyskać pełne pokrycie warunków logicznych w tym przykładowym programie, potrzebne są cztery grupy danych testowych, jak pokazano w tabeli 7.2. Te dane gwarantują pokrycie wszelkich możliwości w instrukcji IF.
Tabela 7.2 Zadania testowe potrzebne dla osiągnięcia pełnego pokycia warunku IF ze złożonym warunkiem logicznym
Date$ Time$ Wykonanie linii 0000-01-01 11:11:11 1,2,5,6,7 0000-01-01 00:00:00 1,2,5,6,7 2000-01-01 11:11:11 1,2,5,6,7
2000-01-01 00:00:00 1,2,3,4,5,6,7
Jeśli interesuje nas tylko pokrycie rozgałęzień, trzy pierwsze grupy danych nie będą interesujące i mozna je połączyć w jedną klasę równoważności i w jedno zadanie testowe. Kiedy jednak stosuje się miarę pokrycia warunków logicznych, wszystkie cztery zadania są istotne, ponieważ reprezentują cztery różne warunki logiczne.
Analizatory pokrycia kodu mogą zwykle zostać skonfigurowane tak, by pokazywały również pokrycie warunków przy raportowaniu wyników. Kiedy się osiąga pokrycie warunków logicznych, osiąga się zarazem pokrycie rozgałęzień i pokrycie instrukcji.
Nawet jeśli przetestuje się każdą instrukcję, każde rozgałęzienie i każdy warunek logiczny (co jest możliwe tylko dla najmniejszych programów), nadal jeszcze nie przetestowało się wszystkiego. Zwróćmy np. uwagę, że wszysktkie błędy danych, opisane na początku tego rozdziału, nadal są możliwe. Przepływ kontroli i przepływ danych łącznie stwarzają działające oprogramowanie. Podsumowanie
W tym rozdziale dowiedzieliśmy się, jak dostęp do kodu źródłowego w czasie wykonywania programu otwiera cały nowy rozdział testowania oprogramowania. Dynamiczne testowanie metodami szklanej skrzynki upraszcza pracę testera, dając mu wgląd w ukrytą informację, co warto jest przetestować. Poznawszy szczegóły kodu, można eliminować zbędzne zadania testowe i dodawać nowe zadania w miejscach, których istnienia nawet się z początku nie podejrzewało. I jedno, i drugie poprawi wydajnośc testowania.
W rozdziałach 4 – 7 ponaliśmy podstawowe zasady testu oprogramowania: 176.Statyczne testowanie metodami czarnej skrzynki, polegające na badaniu specyfikacji i wyszukiwaniu problemów zanim jeszcze zostaną wpisane w kod programu. 177.Dynamiczne testowanie metodami czarnej skrzynki, polegające na testowaniu oprogramowania bez znajomości wewnętrznych mechanizmów jego działania. 178.Stayczne testowanie metodami szklanej skrzynki, polegające na badaniu szczegółów kodu źródłowego w postaci formalnych przeglądów i inspekcji. 179.Dynamiczne testowanie metodami szklanej skrzynki, gdzie obserwuje się działanie wewnętrznych mechanizów programu i dopasowuje zadania testowe do otrzymanej tą drogą informacji.
W pewnym sensie, te cztery rozdziały obejmują wszystko, co najważniejsze w testowaniu oprogramowania. Oczywiście, przeczytać w książce a umieć zastosować w praktyce to zupełnie co innego. Trzeba wiele zaangażowania i ciężkiej pracy, żeby zostać dobrym testerem. Żeby umieć zastosować te podstawowe techniki w praktyce, wiedzieć która pasuje najlepiej w jakiej sytuacji, trzeba wiele praktyki i doświadczenia.
W części 3-ej „Zastosowanie umiejętności w praktyce” poznamy różne dziedziny testowania i zastosowanie umiejętności z „czernej skrzynki” i ze „szklanej skrzynki” do rozmaitych rzeczywistych scenariuszy. Pytania
Pytania mają na celu ułatwienie zrozumienia. W aneksie A „Odpowiedzi do pytań” znajdują się prawidłowe rozwiązania – ale nie należy ściągać! 1.W jaki sposób znajomość wewnętrznych mechanizmów działania programu wpływa na to, jak i co należy przetestować? 2.Czy jest różnica między dynamicznym testowaniem metodami szklanej skrzynki, a lokalizowaniem i usuwaniem błędów? 3.Jakie są dwa główne powody, dla których testowanie jest niemal niewykonalne w modelu skokowym wytwarzania oprogramowania? Jak można im zaradzić? 4.Prawda czy fałsz: jeśli projektowi brakuje czasu, można przeskoczyć testowanie modułów (jednostkowe) i przystąpić od razu do tesowania integracyjnego. 5.Jaka jest różnica między namiastką testową a sterownikiem testowym? 6.Prawda czy fałsz: zawsze należy najpierw skonstruować zadania testowe metodami czarnej skrzynki. 7.Która jest najlepsza spośród trzech opisanych w tym rozdziale metod pomiaru pokrycia? Dlaczego? 8.Jaka jest najpoważniejsza trudność testowania metodami szklanej skrzynki, zarówno statycznego jak i dynamicznego?