rozdział 9

Rozdział 9 Testowanie kompatybilności
W TYM ROZDZIALE  Przegląd testowania kompatybilności  Różne platformy i wersje aplikacji  Standardy i normy  Kompatybilność wspólnych danych
W rozdziale ósmym poznaliśmy testowanie konfiguracji sprzętu i to, w jaki sposób można upewnić się, że oprogramowanie działa poprawnie ze sprzętem, dla którego zostało zaprojektowane. Obecny rozdział zajmuje się pokrewnym obszarem testowania interakcji – sprawdzaniem, czy oprogramowanie współpracuje poprawnie z innymi programami.
Testowanie czy program współgra z innymi programami zyskało na znaczeniu, odkąd konsumenci domagają się możliwości posługiwania się jednym zestawem danych przez programy różnych rodzajów od różnych dostawców, a także jednoczesnego posługiwania się kilkoma programami.
Dawniej każdy program działał jako oddzielna aplikacja. Wykonywało się go w znanym, zrozumiałym i życzliwym otoczeniu, z dala od wszelkich zagrażających oddziaływań. Dzisiaj program prawdopodobnie importuje i eksportuje dane z różnych innych programów, jest wykonywany na różnych systemach operacyjnych i na różnych przeglądarkach i musi współpracować z innymi programami wykonywanymi jednocześnie na tym samym komputerze. Zadaniem testowania kompatybilności oprogramowania jest sprawdzenie, czy to wszystko działa tak, jak oczekują użytkownicy.
Najważniejsze punkty tego rozdziału  to: 23.Co to znaczy, że oprogramowanie jest kompatybilne 24.Jak kompatybilność definiowana jest przez standardy 25.Co to są platformy i jakie mają znaczenie dla kompatybilności 26.Czemu możność przesyłania danych między różnymi aplikacjami jest kluczem do kompatybilności Przegląd testowania kompatybilności
Testowanie kompatybilności oprogramowania oznacza kontrolę, czy badany program współpracuje poprawnie z innymi programami i czy przepływ danych odbywa się prawidłowo. Takie współdziałanie zwykle ma miejsce między programami wykonywanymi na tym samym komputerze, albo nawet na różnych komputerach, połączonych przez Internet i odleglych od siebie o tysiące kilometrów. Współdziałanie może być też zupełnie proste – jak zapisanie danych na dyskietce i przeniesienie jej w ręku do innego komputera w tym samym pokoju.
Oto różne przykłady kompatybilności oprogramowania: 27.Wycięcie tekstu ze strony internetowej i wklejenie go do dokumentu otwartego w programie do przetwarzania tekstu 28.Zapisanie danych finansowych z jednego arkusza kalkulacyjnego i załadowanie ich do zupełnie innego arkusza kalkulacyjnego 29.Program do przetwarzania fotografii działający poprawnie na różnych wersjach tego samego systemu operacyjnego 30.Załadowanie nazwisk i adresów z elektronicznego kalendarza do programu do przetwarzania danych i wydrukowanie z niego serii imiennych zaproszeń i adresów na koperty 31.Uaktualnienie programu obsługi bazy danych i niezmieniony dostęp do danych ze starej bazy danych
Kompatybilność oznacza coś innego dla różnych programów, zależnie od poziomu kompatybilności opisanego w specyfikacji wymagań i od tego, jakie są wymagania systemu, na którym program będzie wykonywany. Zagadnienie kompatybilności nie istnieje dla oprogramowania urządzenia medycznego, mającego własny system operacyjny, zapisującego dane na własnych typach pamięci i niepodłączonego do żadnego innego urządzenia. Natomiast któraś z kolei wersja programu do przetwarzania tekstu (zob. rysunek 9.1), czytającego i piszącego różne pliki z innych programów przetwarzających tekst, pozwalającego na korzystanie za pośrednictwem Internetu przez wielu użytkowników jednocześnie, umożliwiającego włączanie wbudowanej grafiki lub arkuszy kalkulacyjnych z różnego rodzaju aplikacji - uwikładna jest w wielką ilość zagadnień kompatybilności.

Wycinanie, kopiowanie, wklejanie
Zapis/ładowanie plików
Import/eksport plików
Program do przetwarzania tekstu z firmy U, działający na systemie operacyjnym W
Program do przetwarzania tekstu z firmy C, działający na systemie operacyjnym L
Import/eksport za pośrednictwem sieci
Arkusz kalkulacyjny z firmy L, działający na systemie operacyjnym N
Kopia zapasowa
Rysunek 9.1 Kopmatybilność wiążąca razem kilka różnych typów aplikacji szybko staje się bardzo skomplikowana.
Wykonując testowanie kompatybilności nowego oprogramowania, trzeba będzie sobie umieć odpowiedzieć na klika pytań: 32.Z jakimi innymi platformami (systemy operacyjne, przeglądarki internetowe i inne elementy środowiska) system został zaprojektowany jako kompatybilny? Jeśli testowane oprogramowanie samo jest platformą, jakie inne programy mają na nim być wykonywane? 33.Jakie standardy albo reguły kompatybilności muszą być przestrzegane? 34.Jakie rodzaje danych testowane oprogramowanie będzie używać do komunikowania się i posługiwania wspólnymi danymi z innymi programami?
Odpowiedzi na te pytania uzyskuje się przy pomocy zwykłego testowania statycznego – zarówno metodami czarnej jak i szklanej skrzynki. Analizuje się starannie specyfikację produktu i wszelką dodatkową dokumentację. Warto też wziąć pod uwagę rozmowy z programistami i analizę kodu, aby odkryć wszelkie połączenia od i do testowanego oprogramowania. W pozostałej części tego rozdziału przyjrzymy się tym zagadnieniom bliżej. Różne platformy i wersje aplikacji
 Wybór platformy dla aplikacji oraz programów z którymi ma być kompatybilna jest w gruncie rzeczy zadaniem dla marketingu. Ktoś dobrze znający klientów powinien podjąć decyzję, czy oprogramowanie jest przeznaczone dla określonego systemu operacyjnego, przeglądarki internetowej czy dla innej platformy. Ta sama osoba powinna podjąć decyzję, z jakimi wersjami dany produkt ma być kompatybilny. Na przykład, często widuje się takie opisy na opakowaniach albo na pierwszym wyświetlanym przez program ekranie:
Działa najlepiej z Netscape 4.0
Wymaga Windows 95 albo wyżej
Do użytku z jądrem Linuxa 2.2.16
Te informacje należą do specyfikacji i informują zespoły wytwarzający i testujący o tym, jakie są wymagania dotyczące kompatybilności. Każda platforma narzuca szczególne wymagania i z punktu widzenia kierownictwa projektu ważne jest, by ta lista była jak najkrótsza, ale nadal wystarczająca z punktu widzenia potrzeb klientów.
Kompatybilność wprzód i wstecz
Dwa powszechnie stosowane terminy to kompatybilność wstecz (z poprzednimi wersjami) oraz kompatybilność wprzód (z następnymi wersjami). Program kompatybilny wstecz działa z poprzednimi wersjami. Program kompatybilny wprzód działa z przyszłymi wersjami. Najprostszą ilustracją kompatybilności wstecz i wprzód są pliki typu .txt, czyli tekstowe. Rysunek 9.2 pokazuje, jak plik tekstowy zrobiony przy pomocy Notpad 98 w systemie Windows 98 jest kompatybilny wstecz aż do MS-DOS 1.0. Jest również kopmatybilny wprzód do Windows 2000 i prawdopodobnie pozostaniem takim również w kolejnych wersjach.

Editexe na MSDOS 1.0
NotePad na Windows 3.1
??? na OS ???
WordPad na Windows 2000
NotePad na Windows 95
NotePad 98 na Windows 98
Kompatybilność wstecz
Kompatybilność wprzód
Rysunek 9.2 Kompatybilność wstecz i wprzód określają, które wersje będą działać z programem lub plikami aktualnego programu.
Nie jest konieczne, by każde oprogramowanie i wszelkie pliki były kompatybilne wstecz i wprzód. Jest to decyzja do podjęcia dla projektu. Tester musi jednak wiedzieć, jak wiele pracy wymagać będzie przetestowanie kompatybilności wstecz i wprzód dla danego programu.
Skutki testowania różnych wersji
Testowanie, że rozmaite platformy i oprogramowania działaja razem prawidłowo może być dużym przedsięwzięciem. Weźmy pod uwagę test kompatybilności dla nowej wersji popularnego systemu operacyjnego. Programiści naprawili wiele błędów, podnieśli osiągi i dodali do kodu wiele nowych funkcji. Mogą istnieć dziesiątki albo nawet setki tysięcy programów dla aktualnej wersji systemu operacyjnego. Celem projektu jest zachowanie 100-procentowej kompatybilności ze wszystkimi. Spójrzmy na rysunek 9.3.
Jest to wielka praca, ale zarazem kolejny przykład, jak podział na klasy równoważności może pomóc zredukować ilość pracy.
 Programy do przetwarzania tekstu
Bazy danych
Programy edukacyjne
Gry
Programy do malowania i pisania
Arkusze kalkulacyjne
Nowa platforma komputerowa 2004
Rysunek 9.3 Testując kompatybilność nowej platformy, musi się skontrolować, że wszystkie istniejące aplikacje dziłają na niej prawidłowo.
Zaczynając testowanie kompatybilności, trzeba dokonać podziału wszelkich możliwych kombinacji oprogramowania na klasy równoważności, będące najmniejszymi, skutecznymi zbiorami weryfikującymi poprawną interakcję testowanego programu z programami należącymi do danej klasy.
Krótko mówiąc, skoro nie da się przetestować tysięcy różnych programów na nowej wersji systemu operacyjnego, trzeba zdecydować, które są najważniejsze. Kryteria kwalifikacji mogą być następujące: 35.Popularność. Trzeba użyć statysktyki sprzedaży i wybrać 100 do 1000 najważniejszych programów. 36.Wiek. Na przykład wybierze się tylko programy i wersje nie starsze niż trzyletnie. 37.Typ. Dzieli się programy na typy takie jak malowanie, pisanie, księgowość, bazy danych, komunikacja itd. Z każdej kategorii wybiera się program do przetestowania. 38.Wytwórca. Innym kryterium jest wybór programów na podstawie firmy, która je wyprodukowała.
Tak samo jak w testowaniu konfiguracji sprzętu, nie istnieje jedyna poprawna „podręcznikowa” odpowiedź. Zespół projektowy powinien podjąć decyzję, co jest najważniejsze i przy pomocy tego kryterium dokonać podziału na klasy równoważności.
Poprzedni przykład przedstawił testowanie kompatybilności nowego systemu operacyjnegop. Te same kwestie odnoszą się do testowania nowej aplikacji (rysunek 9.4). Trzeba podjąć decyzje, na jakich wersjach platformy i z jakimi innymi programami trzeba przetestwować aplikację.

Aplikacja #2
Aplikacja #1 Aplikacja #5
Apllikacja #4
Platforma 1.0
Aplikacja #3
Nowa aplikacja
Platforma 2.1Platforma 2.0 Rysunek 9.4 Testowanie kompatybilności nowej aplikacji może wymagać testowania na wielu platformach i z wieloma innymi aplikacjami. Standardy i normy
Dotąd w tym rozdziale uczyliśmy się, jak wybrać programy, które będzie się testować pod względem kompatybilności z własnym oprogramowaniem. Teraz przyjrzymy się, jak przystąpić do właściwego testowania. Pierwszym krokiem będzie zbadanie standardów i innych norm, które stosują się do testowanego oprogramowania lub platformy.
Te wymagania można w zasadzie podzielić na dwa rodzaje: wysokiego i niskiego poziomu. Standardy dotyczące wysokiego poziomu to te, które określają ogólną zgodność programu z obowiązującymi normami: wygląd jego interfejsu użytkownika, rodzaj funkcji itp. Standardy niskiego poziomu to szczegóły takie jak format plików albo protokoły komunikacyjne. Oba typy są istotne i muszą być przetestowane, aby zapewnić kompatybilność.
Standardy i normy wysokiego poziomu
Na jakim systemie operacyjnym oprogramowanie ma działać – na Windowsach, Macintosh‘u czy Linuxie? Czy to jest aplikacja Internetowa? Jeśli tak, na jakich przeglądarkach ma działać? Każda z tych platform ma swój własny zestaw standardów i norm, które muszą być przestrzegane, jeśli chce się móc twierdzić, że oprogramowanie jest kompatybilne z platformą.
Przykładem może być znak „Cerytfikowany dla Microsoft Windows” (rysunek 9.5). Aby otrzymać ten znak, oprogramowanie musi zaliczyć testy kompatybilności przeprowadzone przez niezależne laboratorium testujące. Celem jest sprawdzenie, że dane oprogramowanie funkcjonuje stabilnie i niezawodnie na tym systemie operacyjnym.

Rysunek 9.5 Znak „Cerytfikowany dla Microsoft Windows” oznacza, że oprogramowanie spełnia wszystkie kryteria zdefiniowane przez zbiór norm.
Kilka przykładów wymagań dla otrzymania tego znaku: 39.Oprogramowanie funkcjonuje z myszą mającą więcej niż trzy przyciski 40.Oprogramowanie można zainstalować na stacjach dysków innych niż C: i D: 41.Oprogramowanie działa z długimi nazwami plików 42.Oprogramowanie nie czyta, nie pisze ani w żaden inny sposób nie używa starych plików systemowcyh win.ini, system.ini, autoexec.bat ani config.sys.
Te wymagania mogą się wydawać proste i oczywiste, ale to tylko cztery pozycje z dokumentu obejmującego 77 stron. Zajmuje sporo czasu upewnić się, czy oprogramowanie spełnia wszelkie wymagania dla otrzymania znaku, ale spełnienie ich jest gwarancją, że oprogramowanie jest o wiele bardziej kompatybilne.
Szczegóły na temat znaku Windows można znaleźć na http://msdn.microsoft.com/certification/. Szczegóły na temat uzyskania prawa użytkowania znaku dla Apple Macintosh`a znajdują się w http://developer.apple.com/mkt/maclogo.html.
Standardy i normy niskiego poziomu
Standardy niskiego poziomu są w pewnym sensię ważniejsze niż standardy wysokiego poziomu. Można na przykład stworzyć program działający na platformie Windows, ale nie mający wyglądu i sposobu działania innych programów w Windowsach. Taki program nie otrzyma znaku „Certyfikowany dla Microsoft Wiondows”. Użytkowanicy mogą nie być zachwyceni róznicami w porónaniu z innymi aplikacjami, ale produkt dałby się używać.
 Jeśli jednak produkt  jest programem graficznym, który zapisuje pliki na dysku jako pliki .pict (standardowy format Macintosha dla grafiki), ale nie spełnia wymagań standardu dla plików .pict, jego użytkownicy nie będa w stanie oglądać grafiki w żadnym innym programie. Taki program nie jest kompatybilny ze standardem i przypuszczalnie będzie miał krótki żywot.
Podobnie, protokoły komunikacyjne, składnia języków programowania i inne metody używane przez programy aby dzielić się informacją, muszą stosować się do powszechnie dostępnych standardów i norm.
Standardy niskiego poziomu często traktuje się jako oczywiste, ale z punktu widzenia testrów muszą być zdefiniowane. Standardy kompatybilności na niskim poziomie należy traktować jak przedłużenie specyfikacji wymagań. Jeśli według specyfikacji „oprogramowanie będzie zapisywać i ładować pliki graficzne w formatach .bmp, .jpg i .gif”, to trzeba będzie znaleźć standardy tych formatów i skonstruować testy, które potwierdzą, że oprogramowanie istotnie spełnia te wymagania. Kompatybilność wspólnych danych
Wspólne używanie danych przez rozmaite aplikacje jest tym, co naprawdę daje oprogramownaiu siłę. Dobrze napisany program, spełnijący opublikowane standardy i pozwalający użytkownikom łatwo przenosić dane do i z innych programów, jest wspaniałym, kompatybilym produktem.
Najpowszechniejsza metodą przenoszenia danych z jednego programu do drugiego jest zapisywanie i ładowanie plików. Jak zostało powiedziane w poprzednim akapicie, przestrzeganie standardów niskiego poziomu wobec dysków i formatów plików jest tym, co umożliwia taki podział. Inne metody również są traktowane jako oczywiste, ale też muszą być przetestowane pod względem kompatybilności. Oto kilka przykładów: 43.Zapis pliku i ładowanie pliku to najbardziej znany sposób wspólnego korzystania z danych. Dane zapisuje się na dyskietce (albo innym rodzaju pamięci sieciowej, magnetycznej czy optycznej), a następnie przenosi na inny komputer z innym oprogramowaniem. Format danych na pliku musi być zgodny ze standardem, aby funkcjonowły na obu komputerach. 44.Eksport i import plików to sposób stosowany przez wiele programów, aby zachować kompatybilność ze starszymi wersjami samych siębie i z innymi programami. Rysunek 9.6 pokazuje okno dialogowe Otworzyć Plik w programie Word Microsoftu – i kilka spośród 23 różnych formatów plików, które można importować do tego programu.

Rysunek 9.6 Word Microsoftu może importować 23 rożne formaty plików.
Aby przetestować funkcje importowania, należałoby stworzyć dokumenty we wszystkich kompatybilnych formatach – przypuszczalnie przy użyciu oryginalnego programu, który zapisuje dane w tym formacie. Te dokumenty muszą mieć próbki – wybrame przy pomocy podziału na klasy rownoważności – tekstu i formatowania, aby móc sprawdzić, czy importowanme dane są poprawnie porzełożone na nowy format. 45.Wycinanie, kopiowanie i wklejanie są nabardziej znanymi sposobami wspólnego korzystania z danych przez różne programy bez potrzeby zapisywania danych na dysku. W tym wypadku, transfer danych dokonuje się w pamięci przez pośredniczący program zwany Schowkiem. Rysunek 9.7 pokazuje, jak taki transfer się odbywa.
Rysunek 9.7 Schowek Systemowy służy do tymczasowego przechowywania różnych typów danych, które kopiuje się z jednego programu do drugiego.
Schowek jest zaprojektowany tak, by móc przechowywać kilka różnych rodzajów danych. Częst spotykane w Windowsach typy danych to teksty, grafika i dźwięk. Te typy danych też mogą występować w różnych formatach – na przykład tekst może być zwykłym tekstem ASCII, HTML, albo tekstem wzbogaconym. Grafika może być w formie map bitowych, metaplików albo plików .tif.
Gdy użytkownik wykonuje wycinanie albo kopiowanie, wybrane dane umieszczane są w Schowku. Kiedy wykonuje się wklejanie, dane są kopiowane ze schowka do programu docelowego.
 Testując kompatybilność programu, trzeba się również upewnić, czy jego dane są prawidłowo kopiowane poprzez Schowek do innych programów. Tej funkcji uzywa się tak często, że łatwo zapomnieć, że kryje się za nią wiele kodu potrzebnego, by wszystko to działało i było kompatybilne z wieloma różnymi programami. 46.DDE (wymawia się „didi-i”) i OLE (wymawia się oł-lej) to metody, których Windows używa w celu przekazywania danych między dwiema aplikacjami. DDE oznacza Dynamiczna Wymianę Danych (Dynamic Data Exchange), a OLE – Łączenie i Wbudowywanie Obiektów (Object Linking and Embedding). Na innych platformach znajdują się podobne metody.
W tej książce nie musimy wchodzić w szczegóły tych technik, ale główną różnicą między nimi a użyciem Schowka jest to, że przy pomocy DDE i OLE dane przepływają z jednego programu do drugiego w czasie rzeczywistym. Wycinanie i kopiowanie to operacja ręczna. Przy użyciu DDE i OLE, transfer dokonywany jest automatycznie.
Przykładem zastosowania może być pisemny raport wykonany w programie do przetwarzania tekstu, zawierający wykres wykonany przez arkusz kalkulacyjny. Gdyby autor dokumentu skopiował i wkleił wykres do raportu, byłby on statycznym zrzutem migawkowym danych. Jeśli jednak włączyć wykres do raportu jako obiekt, zmieni się on automatycznie jeśli zmienią się liczby, które ilustruje.
To wszystko jest pomysłowe, to prawda, ale rownież stanowi wyzwanie dla testera, jak upewnić się, że łączenie i wbudowywanie obiektów funkcjonuje poprawnie. Podsumowanie
Ten rozdział był wstępem do testowania kompatybilności. Tak naprawde można by na ten temat napisać osobną książkę, i jeden rozdział nie jest w stanie oddać całości tematyki. Każda platforma i każda aplikacja jest szczególna, a zagadnienie kompatybilności na jednym systemie może być zupełnie odmienne niż na innym systemie.
Początkujący tester oprogramowania może często otrzymać zadanie przetestowania kompatybilności programu. Może się to wydać dziwne, zważywszy złożoność i wielkość zadania, ale też zwykle pojedynczy tester otrzymuje tylko fragment całej pracy do wykonania. Jeśli projekt wytwarza nową wersję systemu operacyjnego, pojedynczy tester może na przykład otrzymać zadanie testowania kompatybilności tylko programów do przetwarzania tekstu albo graficznych. Jeśli projekt wytwarza jakąś aplikację, tester może otrzymać zadanie przetestowania jej kompatybilności na kilku różnych platformach.
 Z każdym z tych zadań można sobie poradzić, jeśli przystąpić do nich pamiętając o trzech rzeczach: 47.Należy podzielić zbiór wszystkich możliwych typów oprogramowania na dającą się zastosować w praktyce ilość klas równowazności. Oczywiście, kierownik projektu powinien zaakceptować dokonaną selekcję i zdawać sobie sprawe z ryzyka związanego z tym, że nie testuje się wszystkiego. 48.Należy zbadać standady i normy, zarówno na wysokim jak i na niskim poziomie, i potrakotować je jako przedłużenie specyfikacji wymagań. 49.Trzeba przetestować rożne drogi, jakimi dane przepływają między testowanymi programami. Taka funkcjonująca wymiana danych stanowi o kompatybilności programów. 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.Prawda czy fałsz: każde oprogramowanie musi być w jakimś stopniu poddane testownaiu kompatybilności. 2.Prawda czy fałsz: Kompatybilność jest cechą produktu, która może być spełniona w różnym stopniu 3.Jak należy podejśc do zadania przetestowania kompatybilności wszystkich formatów plików dla danego produktu? 4.W jaki sposób testuje się kompatybilność wprzód (z kolejnymi, następnymi wersjami programu)?