Automatyczne testowanie oprogramowania

Łukasz Juszkiewcz

Automatyczne testowanie jest jednym z głównych postulatów eXtreme

Programming (XP). Automatyzacja polega na użyciu oprogramowania do sterowania
wykonaniem testów, porównywania ich wyników z oczekiwanymi, czy raportowania.

Testowanie oprogramowania wymaga dostarczenia przypadku testowego (test

case) – częściej całego zestawu przypadków testowych dla testowanego systemu (test

case suite) – przez programistę, uruchomienia programu z użyciem przygotowanego
zestawu przypadków testowych i sprawdzeniu, czy przy danych wejściowych

pochodzących z przpadku testowego zachowanie programu jest zgodne z oczekiwanym.
Wszystkie te trzy aspekty testowania oprogramowania mogą zostać zautomatyzowane w

mniejszym lub większym stopniu.

Z powyższych aspektów, najprostszym do zautomatyzowania jest wykonanie

przypadków testowych. Dla aplikacji, które nie wchodzą w interakcję z użytkownikami
(lub ich interakcja ogranicza się do komend wpisywanych klawiaturą), łatwo jest napisać

mały program, nazywany skryptem testowym (test script), generujący odpowiednie dane
wejściowe. Nieco trudniej wykonać to dla programów z graficznym interfejsem, jednak

istnieją narzędzia pozwalające testować tego typu aplikacje. Potrafią one nagrywać
sekwencje wykonywanych operacji w testowanym programie, jednak podstawową wadą

tych narzędzi jest zależność wyniku testu od umiejscowienia poszczególnych
komponentów interfejsu na ekranie. W razie zmiany ich ułożenia lub usunięcia

istniejącego komponentu testy przestają działać poprawnie i należy je ponownie
zdefiniować.

Czasami także sprawdzenie, czy dane wyjściowe aplikacji są zgodne z

oczekiwanymi jest łatwe do zautomatyzowania – na przykład w programie wykonującym

jakieś matematyczne obliczenia na danych wejściowych i zapisującym ich rezultat w
pliku wyjściowym. Istnieje jednak wiele sytuacji, kiedy sprawdzenie zachowania

aplikacji nie jest możliwe poprzez zwykłe porównanie z oczekiwanymi danymi –
przykładowo, w programie do kompresji audio test prawidłowego działania aplikacji

polega na wysłuchaniu skompresowanej próbki i subiektywnej ocenie jej jakości.

Jednak w rozwoju sporej części oprogramowania automatyczne testowanie jest

powszechną praktyką, a narzędzia je wspomagające są szeroko dostępne, wiele z nich to
wolne czy otwarte oprogramowanie.

Automatycznie generowane przypadki testowe są jednak dużo bardziej złożonym

problemem i użycie takich automatycznie tworzonych przypadków testowych jest o

wiele rzadsze. Jednym ze sposobów generowania przypadków testowych jest
testowanie na poziomie modelu (model-based testing), gdzie model systemu jest

używany do automatycznego tworzenia przypadków testowych, jednak nie zakończono
badań nad sposobami realizacji tego zadania.

W książce Wzorce projektowe. Elementy oprogramowania obiektowego

wielokrotnego użytku John Vlissides, Ralph Johnson, Erich Gamma, Richard Helm
(“Banda Czworga” - “Gang of Four”) przedstawili wzorzec projektowy Model-Widok-

Kontroler (Model-View-Controler – MVC). Pokazuje on, jak separować warstwy aplikacji
odpowiedzialne za logikę (Model) od warstwy opisującej interfejs użytkownika (Widok,

Kontroler). Jak wiadomo, automatyczne testowanie aplikacji na poziomie Widoku
sprawia problemy, automatycznie testuje się głównie model aplikacji. Standardowa

metoda to stworzenie obiektu testowanej klasy (klas), wykonaine kilku metod i
sprawdzenie wyników ich działania. Dodatkowo powinny być spełnione następujące

warunki:

1. możliwośc uruchomienia poszczególnych testów z całego zestawu;

2. niezależne wykonywanie testów: wynik (np. niepowodzenie) jednego testu nie

powinno mieć wpływu na pozostałe – umożliwi to uzyskanie jak najawiększej ilości
informacji na temat działania całego systemu;

3. tworzenie raportów z wykonanych testów ze szczegółowymi danymi i statystykami

– np. w przypadku niepowodzenia powinny zawierać wartości oczekiwane i

otrzymane.

Testowanie w eXtreme Programming.

XP testy dzieli się na trzy rodzaje:

1. jednostkowe – służą do testowania pojedynczej klasy (modułu) odizolowanej od

pozostałych komponentów; pisane przez programistów;

2. akceptacyjne – opisują oczekiwania klienta wobec systemu; tworzone przez

klienta – z reguły w prostym języku skryptowym, rzadziej w języku naturalnym,

kodowane następnie przez programistę;

3. interaktywne – nieautomatyczne testy służące do wykrywania błędów wizualnych:

nieprawidłowego rozmieszczenia elementów interfejsu użytkownika, mało
estetycznego wyglądu komponentów; jeśli testy jednostkowe zostały dobrze

zaprojektowane, w testach interaktywnych nie powinny istnieć błędy modelu, jak
nieprawidłowe wyniki obliczeń, nieprawidłowa implementacja komunikacji z

pozostałymi komponentami systemu.

Standardowo, dodawanie nowej funkcjonalności do systemu jest realizacją

poniższego schematu (cyklu):

1. Zaprojektowanie i zdefiniowanie przypadków testowych dla wymagań – nie należy

od razu opisywać wszystkich cech: należy zacząć od najprostszych i najmniejszych
kroków, stopniowo zwiększając ich zakres. Na tym etapie kompilacja utworzonego

kodu zakończy się niepowodzeniem z powodu braku testowanych obiektów.

2. Opierając się na klasach i metodach opisanych w testach należy stworzyć szkielet

klas, które będą realizowały przypadki testowe. Przed dodaniem jakiejkolwiek
funkcjonalności należy uruchomić testy, aby sprawdzić, czy testy są wykonywane

(bez zdefiniowanych treści testowanych metod, testy zakończą się
niepowodzeniem).

3. Implementacja kolejnych wymagań. Po każdej zmianie należy uruchomić testy –

liczba błędów będzie maleć z każdą poprawną implementacją. Po pozytywnym

wykonaniu wszystkich testów można zdefiniować kolejne przypadki testowe,
bardziej kompleksowe.

Często podczas tworzenia czy rozwijania jakiegoś systemu klient nalega na zmianę

istniejącej już funkcjonalności. Jeśli na tym etapie pominie się stworzenie odpowiednich
testów, podczas modyfikacji kodu mogą powstać nowe, trudne do znalezienia i

poprawienia w późniejszym etapie błędy. Ab tego uniknąć, należy:

1. Poprawić testy, aby w pełni odzwierciedlały zmianę specyfikacji testwoanego

fragmentu aplikacji. Jeśli po uruchomieniu testów, nie występują błędy,
prawdopodobnie zmienione przypadki testowe nie są wykonywane.

2. Poprawiać implementację tak, by testy nie wykazywały już żadnych błędów. W

przypadku zmiany funkcjonalności wymaganej w innej części programu, przypadki

testowe uruchamiane w owym fragmencie systemu zakończą się niepowodzeniem,

co pozwoli uniknąć w dużej mierze psucia istniejącego kodu.

W razie, gdy znaleziono błąd, którego do tej pory nie uwzględniały żadne testy,

najpierw należy dodać przypadki testowe, które powinny go wykryć. Następnie trzeba

uruchomić testy, aby sprawdzić, czy nowy zestaw faktycznie wykrywa błąd. Poprawka
zostaje zakończona, gdy wszystkie testy kończą się sukcesem.

Narzędzia do automatycznego testowania.

Automatyczne testowanie, jako jeden z głównych postulatów XP, doczekał się

wielu narzędzi ułatwiających jego realizację podczas pracy z każdym językiem

(obiektowym). Oto najpopularniejsze rozwiązania dla wybranych języków.

Java – JUnit

JUnit jest najpopularniejszą biblioteką służącą do konstruowania testwów. Jej

popularność i powszechne użycie (w tym wypadku idące w parze z jakością) jest przede
wszystkim wynikiem popularności jej autorów, którymi są m. in. Kent Beck (jeden z

największych autorytetów eXtreme Programming) oraz Erich Gamma (Gang of Four) –
zresztą kostrukcja JUnit jest konsekwencją jej pochodzenia; Kent Beck napisał jej

piwerszą implementację w Smalltalk'u.

Mając wydzielony model aplikacji, można przygotować przypadki testowe.

Załóżmy, że należy napisać klasę operującą na napisach.

public class NapisTest extends TestCase

{

public void runTest()

{

Napis nDu = new Napis(

“du”

);

Napis nPa = new Napis(

“pa”

);

Napis nDupa = new Napis(

“dupa”

);

nDu.zloz(nPa);
assert(nDu.equals(nDupa));

}

}

Stworzona specjalna klasa testowa, która dziedziczy z klasy TestCase nalezącej

do JUnit. Metoda assert(), pochodząca z tej klasy, sprawdza czy wyrażenie będące
jej argumentem jest prawdą.

Napisana klasa zawiera tylko jeden test. Każdy następny wygląda podobnie:

1. stworzenie testowanych obiektów;

2. wykonanie wymaganych operacji;
3. zwolnienie zasobów (jeśli zostały jakieś pobrane).

Kod z podpunktów 1. i 2. może być współdzielony między wszystkimi testami.

Umieszcza się go w metodach odpowiednio setUp() i tearDown(). Zbiór testowanych
obiektów nazywany jest Fixture.

public class

NapisTest extends TestCase

{

Napis nDu;

Napis nPa;

protected void setUp()

{

nDu = new Napis(

“du”

);

nPa = new Napis(

“pa”

);

}

protected void tearDown()

{

/* brak zasobów do zwolnienia */

}

public void testZloz()

{

Napis nDupa = new Napis(

“dupa”

);

nDu.zloz(nPa);

assert(nDu.equals(nPa));

}

public void testPodnapis()

{

Napis wynik = new Napis(

“p”

);

nDu = nPa.podnapis(0,1);

assert(nDu.equals(wynik));

}

}

W celu uruchomienia kodu, należy skonstruować instancje testów z podanymi

nazwami metod z testem. Metoda run(), korzystając z refleksji w Javie, wywołuje
odpowiednią metodę testową.

TestResult result = (new NapisTest(

"testZloz"

)).run();

TestResult result = (new NapisTest(

"testPodnapis"

)).run();

Domyślna implementacja metody suite() tworzy zbiór testów na podstawie nazw
metod klasy testowej - wybierane są wszystkie zaczynające się od "test". Przed każdą

metodą testową wykonywany jest kod metody setUp(), a zaraz po zakończeniu metody
testowej wykonywana jest metoda tearDown(). Dzięki temu przypadki testowe są

odizolowane od siebie i wykonanie jednego nie ma wpływu na pozostałe.

Po przygotowaniu kilku przypadków testowych, można je pogrupować w zbiory

przypadków testowych.

public static Test suite()

{

TestSuite suite= new TestSuite();

suite.addTest(new NapisTest(

"testZloz"

));

suite.addTest(new NapisTest(

"testPodnapis"

));

return suite;

}

Python - PyUnit

PyUnit to bazujący na JUnit moduł do testwoania kodu napisanego w Pythonie,

będący integralną częścią standardowej biblioteki Pythona 2.1.

Podobnie jak JUnit, PyUnit używa klasy TestCase z modułu unittest

reprezentującej przypadki testowe i tak jak w JUnit, aby napisać własne testy, trzeba

rozszerzyć tę klasę. Przykładowa klasa testowa pochodzi z dokumentacji PyUnit:

import unittest

class DefaultWidgetSizeTestCase(unittest.TestCase):

def runTest(

self

):

widget = Widget(

"The widget"

)

assert widget.size() == (50,50),

'incorrect default size'

Aby utworzyć instancję tak zdefiniowanego przypadku testowego, trzeba wywołać

konstruktor stworzonej klasy testowej bez argumentów:

testCase = DefaultWidgetSizeTestCase()

Analogicznie do JUnit tworzy się kod odpowiedzialny za tworzenie testowanych

obiektów, zwalnianie zasobów i implementuje część Fixtures:

import unittest

class WidgetTestCase(unittest.TestCase):

def setUp(

self

):

self.widget = Widget(

"The widget"

)

def tearDown(

self

):

self.widget.dispose()
self.widget =

None

def testDefaultSize(

self

):

assert self.widget.size() == (50,50),

'incorrect default size'

def testResize(

self

):

self.widget.resize(100,150)

assert self.widget.size() == (100,150), \

'wrong size after resize'

Stworzenie instancji testów w PyUnit wygląda następująco:

defaultSizeTestCase = WidgetTestCase(

"testDefaultSize"

)

resizeTestCase = WidgetTestCase(

"testResize"

)

Tak zdefiniowane testy można dodać do zbioru przypadków testowych:

widgetTestSuite = unittest.TestSuite()

widgetTestSuite.addTest(WidgetTestCase(

"testDefaultSize"

))

widgetTestSuite.addTest(WidgetTestCase(

"testResize"

))

Wygodnie jest stworzyć obiekt zwracający zestaw testów z wcześniej zdefiniowanych

przypadków testowych:

def suite():
suite = unittest.TestSuite()

suite.addTest(WidgetTestCase(

"testDefaultSize"

))

suite.addTest(WidgetTestCase(

"testResize"

))

return suite

Podsumowanie

Jak widać na przykładach, automatyczne testowanie nie jest zadaniem

wymagającym ponadprzeciętnych zdolności programistycznych, zwłaszcza, gdy używa

się narzędzi testujących dla używanego języka, bazujących na JUnit – wówczas
tworzenie testów polega na stosowaniu tego samego, powszechnego schematu z

uwzględnieniem jedynie składni danego języka.

Podstawowym “mankamentem” jest zwiększona ilość kodu potrzebna na dodanie

nowej funkcjonalności (każdorazowe tworzenie przypadków testowych przed
implementacją poszczególnych założeń specyfikacji). Jednak ów “mankament” zostanie

niejednokrotnie wynagrodzony dzięki uniknięciu wielu godzin poszukiwania i naprawiania
błędów, które dzięki automatyzacji testowania są natychmiastowo wyłapywane.

Dodatkowo programowanie ukierunkowane testami (Test-Driven Development –

TDD) opierające się na technice automatycznego testowania, nie jest jedynie “kolejnym

sposobem samego programowania”, ale jest także swego rodzaju sposobem
projektowania systemu i gwarantem spełniania przez niego założonej specyfikacji, która

jest zdefiniowana w przypadkach testowych.