Testowanie Oprogramowania Rafał Hryniów

Tło historyczne W roku 1947 komputery były wielkimi maszynami zajmującymi cały pokój, pracującymi na mechanicznych przekaźnikach i żarzących się lampach elektronowych. Szczytem techniki był wówczas komputer Mark II, olbrzym budowany na Uniwersytecie Harwardzkim. Technicy właśnie go uruchamiali po raz pierwszy, gdy nagle się zatrzymał. Rzucono się szukać przyczyny i znaleziono ćmę wciśniętą między dwa przekaźniki głęboko we wnętrzu komputera. Najwyraźniej zwabiona światłem i ciepłem wleciała do urządzenia i została zabita przez prąd, kiedy wylądowała na przekaźniku. Tak narodził się komputerowy BUG!!! 

Co to jest błąd ? Trzeba rozróżnić dwa poniższe pojęcia: Błąd (ang. fault, error) jest niepoprawną konstrukcją znajdującą się w programie, mogącą prowadzić do niewłaściwego działania. Błędne wykonanie (ang. failure) to niepoprawne działanie systemu w trakcie jego pracy. Błąd może prowadzić do wielu różnych błędnych wykonań. W wielu sytuacjach może jednak nie objawiać się błędnym wykonaniem. Takie same błędne wykonania mogą być spowodowane różnymi błędami.

Błąd – formalna definicja Błąd oprogramowania występuje, kiedy spełniony jest przynajmniej jeden z następujących warunków: Oprogramowanie nie wykonuje czegoś, co według specyfikacji powinno wykonywać. Oprogramowanie wykonuje coś, czego według specyfikacji nie powinno robić. Oprogramowanie robi coś, o czym specyfikacja w ogóle nie wspomina. Oprogramowanie nie wykonuje czegoś, o czym specyfikacja wprawdzie nie wspominna, ale nie powinna. Oprogramowanie jest trudne do zrozumienia, trudne do użycia, powolne albo – zdaniem testera – będzie w oczach użytkownika po prostu nieprawidłowe.

Skąd się biorą błędy ? Przeprowadzono wiele badań przedsięwzięć, małych do bardzo dużych i uzyskane wyniki są zawsze takie same. Główną przyczyną powstawania błędów jest specyfikacja.

Przyczyny powstawania błędów Specyfikacja – w wielu przypadkach nie została ona po prostu napisana, kiedy indziej nie była dostatecznie dokładna, albo nieustannie się zmieniała, albo nie była wystarczająco znana wszystkim osobom należącym do zespołu. Projekt produktu – tworzony zbyt pośpiesznie, niedbale, często zmieniający się lub jego treść jest nieprecyzyjnie przekazana innym. Błędy kodowania – duża złożoność programu, kiepska dokumentacja, stosowanie potencjalnie niebezpiecznych technik

Aksjomaty testowania Programu nie da się przetestować całkowicie. Testowanie oprogramowania jest ryzykowne. Test nie udowodni braku błędów. Im więcej błędów się znalazło, tym więcej błędów pozostaje. Paradoks pestycydów. Nie wszystkie błędy zostaną naprawione. Specyfikacje produktu nigdy nie są gotowe. Testerzy nie są najbardziej lubiani w zespole.

Testy w modelu V

Weryfikacja i Walidacja Powyższe nazwy często stosowane są zamiennie, ale mają naprawdę odmienne znaczenia. Ta różnica jest ważna w testowaniu oprogramowania. Weryfikacja (ang. verification) to potwierdzenie, że coś – oprogramowanie – spełnia wymogi swojej specyfikacji (czyli zdefiniowanymi w fazie określania wymagań). Walidacja, inaczej atestowanie (ang. validation) to potwierdzenie, że oprogramowanie spełnia rzeczywiste potrzeby użytkowników.

Metody „czarnej skrzynki” i „szklanej skrzynki” Stosując metody czarnej skrzynki, tester wie jedynie, co oprogramowanie ma robić – nie zagląda do „wnętrza skrzynki”, żeby zobaczyć jak to działa. Kiedy wprowadzi się pewne dane wejściowe, otrzyma się pewne dane wyjściowe. Stosując techniki szklanej skrzynki, tester ma dostęp do kodu programu i analizuje go w poszukiwaniu wskazówek, które pomogą w testowaniu. Może wytypować potencjalne niebezpieczeństwa i dostosować do nich swoje testy.

Testowanie statyczne i dynamiczne Testowanie statyczne dotyczy czegoś, co nie jest wykonywane – np. kodu lub specyfikacji weryfikowanych za pomocą analizy lub inspekcji. Testowanie dynamiczne polega na wykonaniu i używaniu (fragmentu) programu i porównywaniu uzyskanych wyników z poprawnymi.

Testowanie specyfikacji (TS) Znalezienie błędów w tak wczesnej fazie projektu może zaoszczędzić bardzo dużo czasu i pieniędzy. Testowanie specyfikacji jest statycznym testowaniem metodą czarnej skrzynki. Specyfikacja to dokument, nie program do wykonania, więc uważa się ją za statyczną. Jest zbudowana na podstawie danych z wielu różnych źródeł: badań nad użytecznością, badań preferencji klientów, marketingu. Nie trzeba dokładnie wiedzieć, w jaki sposób dane zostały zgromadzone – wystarczy, że zostały spisane w postaci specyfikacji wymagań.

(TS) Ogólny przegląd Walidacja specyfikacji wymagań Zbadanie kim jest klient/użytkownik Zorientowanie się w dziedzinie działania Zbadanie zgodności standardów i reguł Terminologia i konwencje danego przedsiębiorstwa Wymagania branżowe Standardy państwowe Graficzny interfejs użytkownika (GUI) Standardy sprzętowe i sieciowe Przegląd i zbadanie podobnego oprogramowania

(TS) Techniki szczegółowe Kontrolna lista atrybutów specyfikacji Kompletna Dokładna Precyzyjna, jednoznaczna, przejrzysta Spójna Istotna Wykonalna Wolna od szczegółów realizacji Dająca się przetestować Kontrolna lista terminologii Zawsze, każdy, wszystkie, żaden, nigdy Niewątpliwie, dlatego, jasne, oczywiste, niewątpliwe Niektóre, czasami, często, zwykle, normalnie, najczęściej, większość, głównie. Itd., i tak dalej, i temu podobne, takie jak Dobry, szybki, tani, wydajny, stabilny Opracować, przetworzyć, odrzucić, pominąć, wyeliminować „Jeśli...to” (z pominięciem „w przeciwnym razie”)

Test pozytywny, test negatywny Testy pozytywne – kontrolują jedynie, czy oprogramowanie funkcjonuje poprawnie na swego rodzaju minimalnym poziomie. Nie testuje się zbyt daleko, nie szuka się sposobów wywołania awarii za wszelką cenę. Testy negatywne – projektowanie i wykonywanie zadań testowych, których głównym zadaniem jest złamanie programu – wymuszenie awarii, mają one zmusić nawet dobrze ukryte błędy do ujawnienia się.

Metoda klas równoważności Klasa równoważności – zbiór zadań testowych, które testują to samo albo ujawniają ten sam błąd Identyfikując klasy równoważności, warto rozważyć, jak pogrupować podobne dane wejściowe, podobne dane wyjściowe i podobne działania programu. Te grupy mogą być stosownymi klasami równoważności

Zastosowanie klas równoważności Warunki graniczne Puste zbiory danych Niedozwolone dane

Analiza kodu (AK) Badanie projektu konstrukcji i kodu Formalne przeglądy Standardy i reguły programowania Lista kontrolna do przeglądów kodu

(AK) Formalne przeglądy Elementy: Identyfikacja problemów – celem przeglądu jest znalezienie błędów i braków Postępowanie według zasad – muszą być określone ścisłe procedury działania Przygotowanie – każdy uczestnik ma inną rolę i musi być do niej przygotowany Pisanie raportu – musi być sporządzony i rozpowszechniony raport o wynikach przeglądu

(AK) Standardy i reguły programowania Skąd wziąć standardy ??? American National Standard Institute (ANSI) – www.ansi.org International Engineering Consortium (IEC) – www.iec.org International Organisation for Standardisation (ISO) – www.iso.org National Committee for Information Technology Standards (NCITS) – www.ncits.org Association for Computing Machinery (ACM) – www.acm.org Institute of Electrical and Electronics Engineers, Inc (IEEE) – www.ieee.org Strony na których można znaleźć standardy w dziedzinie języków programowania i technologii informatycznych. Dokumentacje reguł programowania i opisy najlepszych praktyk.

(AK) Lista kontrolna przeglądu kodu Błędy w odwołaniach do zmiennych Błędy w deklarowaniu zmiennych Błędy obliczeniowe Błędy w porównaniach Błędy przepływu sterowania Błędy w parametrach procedur Błędy wejścia/wyjścia

Testowanie interfejsu użytkownika Cechy dobrego interfejsu użytkownika: Zgodność ze standardami Intuicyjność Spójność Elastyczność Wygoda Poprawność Użyteczność

Testowanie dokumentacji (1) Znaczenie testowania dokumentacji: Poprawia użyteczność Zwiększa niezawodność Zmniejsza koszty serwisu

Testowanie dokumentacji (2) Lista kontrolna do testowania dokumentacji: Odbiorcy Terminologia Treść i zawartość Same fakty Krok po kroku Rysunki i ekrany Próbki i przykłady Pisownia i gramatyka

Uwagi (1) Jeśli użytkownik zostanie wprowadzony w błąd mylnymi instrukcjami instalacyjnymi albo nieprawidłowymi komunikatami o błędach, będzie to dla niego równoznaczne z błędami oprogramowania, które powinni byli znaleźć testerzy. Dla testera oprogramowania dokumentacja zasługuje na tyle samo uwagi i wysiłku co kod programu. Stanowią one dla użytkownika całość.

Uwagi (2) Dokumentację najlepiej testować tak samo, jak będzie się nią posługiwał użytkownik, niezależnie od tego, na ile jest statycznym tekstem, a na ile kodem. Należy ją starannie przeczytać, wykonać każdą z opisanych czynności, sprawdzić każdy rysunek i wypróbować każdy przykład. W ten sposób znajdzie się błędy zarówno w programie, jak i w dokumentacji.

Testowanie witryn WWW (1) Metoda czarnej skrzynki (tekst, łącza, grafika, formularze, obiekty i inne elementy złożone) Metoda szarej skrzynki (częściowe zerkanie) Metoda szklanej skrzynki

Testowanie witryn WWW (2) Testowanie konfiguracji i kompatybilności Wprowadzenie automatyzacji: http://www.net-mechanic.com http://websitegarage.netscape.com

Testowanie automatyczne i narzędzia do testowania (1) Analizatory i monitory Sterowniki Namiastki Narzędzia do testowania przeciążającego (Microsoft Stress)

Testowanie automatyczne i narzędzia do testowania (2) Automatyzacja testu oprogramowania: Nagrywanie i odtwarzanie Programowane makroprogramy W pełni programowalne automatyczne narzędzia do testowania (Visual Test)

Testowanie automatyczne i narzędzia do testowania (3) Testowanie na chybił-trafił: małpy i goryle Głupie małpy Półgłupie małpy Bystre małpy

Polowanie na błędy i testowanie beta Podział testowania Testowanie beta Uwaga! Jednym z największych zagrożeń w projekcie wytwarzania oprogramowania jest próba potraktowania testowania beta jako namiastki prawdziwych testów. Nie wolno tego robić! Zlecanie testowania innej firmie

Planowanie testowania Cele planowania testów (Standard ANSI/IEEE 829/1983) Określenie zakresu, metodyki, zasobów i harmonogramu testowania, zidentyfikowanie przedmiotów testowania, funkcji do przetestowania, czynności, które trzeba wykonać, osób odpowiedzialnych za każdą z nich oraz ryzyka związanego z planem.

Cele planowania zadań testowych Organizacja Powtarzalność Zarządzanie Dowód przeprowadzenia testów

Testowanie ad hoc Testowanie ad hoc polega na tym, że oprogramowanie testuje się bez planu, nie ma żadnych zadań testowych ani nawet planu testowania. Tester zasiada przed komputerem i zaczyna naciskać klawisze. Robi to zwykle wrażenie i może być cennym uzupełnieniem planowanych testów, np.. W czasie zmasowanego „ataku na błędy” ale nie jest zorganizowane, nie daje się powtórzyć, nie daje się tymi działaniami zarządzać, a po zakończeniu, nie ma żadnego dowodu, że tego typu testowanie rzeczywiście przeprowadzono.

Systemy śledzenia błędów (1) Raport o incydencie (Standard ANSI/IEEE 829) Identyfikator Streszczenie Opis wydarzenia Skutki

Systemy śledzenia błędów (2) Ręczne raportowanie i śledzenie błędów (papierowe raporty) Automatyczne raportowanie o błędach i śledzenie ich (bazodanowe aplikacje)

Testy jednostkowe Pozwalają na automatyzację testów Służą przede wszystkim testowaniu zachowania Mogą być uruchamiane cyklicznie bez konieczności ich ręcznego wyzwalania

Testy jednostkowe Podstawowe elementy Testów jednostkowych TestCase TestSuite Metody testowe setUp tearDown