Testowanie automatyczne nie znajduje defektów?

Artykuł ten w dużej mierze oparty jest na pytaniu zadanym na grupie Testowanie Oprogramowania przez Macieja Kusza i na odpowiedziach osób uczestniczących w dyskusji.

Przede wszystkim powinniśmy określić, co rozumiemy pod szerokim pojęciem testowania automatycznego. Można wyróżnić dwie ogólne definicje.

1. Najpopularniejszą interpretacją testowania automatycznego jest symulowanie przez narzędzie zachowania pojedynczego użytkownika operującego na interfejsie. Mówimy tu zazwyczaj o testowaniu pewnych funkcji. W tym przypadku rzeczywiście zdolność oprogramowania do wykrycia nowych defektów jest praktycznie zerowa. Wynika to z tego, że skrypty są kopią jeden do jednego wcześniej uruchomionych testów manualnych. Wszystkie defekty mogły być już wcześniej znalezione, a znajdywane są jedynie defekty regresji.

2. Testowanie automatyczne jest również interpretowane jako szereg czynności, które pomagają testować inne interfejsy niż GUI i inne typy testów (np. wydajność). Często mówimy również o tym, że testy automatyczne nie mogą (lub nie powinny) być wykonane ręcznie ze względu na koszty lub czas.

Zdolność do wykrywania defektów pojawi się wraz z automatycznym dołączeniem pewnej losowości w testach np. poprzez uruchomienie testów w strategii sterowanej przez dane, gdzie mamy jeden skrypt testowy i duże zbiory danych wejściowych (mogą być również generowane).

To właśnie w tej grupie znajdziemy wiele przykładów, gdzie automatyzacja prowadzi do wykrycia nowych defektów.

• Testy wydajności - jest to symulowanie dużej liczby zapytań / transakcji generowanych przez użytkowników. Łatwiej jest więc powielić wielokrotnie skrypty przygotowane do weryfikacji funkcjonalnej i obserwować system pod obciążeniem. Znajdywane defekty wynikają zazwyczaj ze złej konfiguracji lub architektury rozwiązania.

• Testy jednostkowe (unit tests) - testy, których nie da się łatwo uruchomić ręcznie, ale jednocześnie są bardzo łatwe do automatyzacji, ponieważ operują bezpośrednio na kodzie. Znajdują one defekty związane z jakością kodu.

• Testy oprogramowania wbudowanego (embedded) - tutaj często dochodzi do bardzo złożonych zależności czasowych i test musi być wykonany z dokładnością do milisekund. Nie da się tego zrobić bez automatu. Znajdywane są defekty bezpośrednio powiązane z czasem.

• Posiew defektów - celowe i automatyczne dodawanie znanych defektów do modułów lub systemu w celu monitorowania efektywności ich wykrywania i usuwania oraz szacowania liczby defektów. Realnie nie jest to testowanie, a jedynie technika wspierająca testy.

  • Na poziomie modułowym mówimy o testowaniu mutacyjnym. Jest to technika badania jak dokładnie testy jednostkowe sprawdzają kod programu. Polega na automatycznym wprowadzaniu małych, losowych defektów w testowanym programie i uruchamianiu testów jednostkowych, które powinny te defekty wykryć.

• Fuzzing - metoda testowania oprogramowania polegająca na automatycznym wprowadzeniu do programu niepoprawnych, nieoczekiwanych lub losowych danych oraz obserwowania zachowania programu w oczekiwaniu na ujawnienie defektu. Inną nazwą jest testowanie oparte o dane.

Jest też zbiór wielu czynności, które jedynie wspierają testowanie i są efektywniejsze, gdy wykonywane są automatycznie. Mogą to być:

• przygotowanie środowisk testowych,
• przygotowanie warunków wstępnych uruchomienia testu,
• przygotowanie danych testowych,
• zasilenie baz danych środowiska testowego,
• generowanie losowego ruchu, który tworzy tło do wykonywania testów,
• monitorowanie produkcji,
• automatyczne opracowywanie wyników.

Zapraszamy do zapoznania się z całym wątkiem na facebookowej grupie Testowanie Oprogramowania.