Koncepcje związane z narzędziami testowymi
Z AmberPlace
Narzędzia testowe mogą znacznie poprawić efektywność i dokładność testowania, ale tylko wtedy, gdy odpowiednie narzędzia zostaną zastosowane w odpowiedni sposób. Narzędziami testowymi trzeba zarządzać tak jak każdym aspektem dobrze prowadzonej organizacji. Automatyzacja testów jest często uważana za synonim wykonywania testów, ale większość ręcznej pracy przy testach poddaje się różnym formom automatyzacji. Oznacza to, że większość obszarów testowania może zostać do pewnego stopnia zautomatyzowana, pod warunkiem posiadania odpowiednich narzędzi.
Każda z wersji narzędzi testowych, skryptów testowych oraz sesji testowej powinna podlegać (tak jak podstawa testów) zarządzaniu konfiguracją i powinna być powiązana z wersją oprogramowania na której została użyta. Każde z narzędzi testowych jest ważnym elementem testaliów i powinno być odpowiednio zarządzane, to znaczy należy:
- stworzyć architekturę przed utworzeniem narzędzia testowego
- zapewnić odpowiednie zarządzanie konfiguracją skryptów, wersji narzędzi, łat itp., włączając w to informację o wersji
- utworzenie i utrzymanie bibliotek (reużycie podobnych koncepcji w ramach przypadków testowych), udokumentowanie wdrożenia narzędzi testowych (np. proces wykorzystywania narzędzia przez organizację)
- planowanie pod kątem przyszłości przez strukturalizowanie przypadków tostowych w celu ułatwienia przyszłego rozwoju np. przez takie ich utworzenie, żeby były rozszerzalne i utrzymywalne
9.2.1 Koszty, zyski i ryzyko narzędzi testowych i automatyzacji
Analiza kosztów i zysków powinna zostać przeprowadzona w każdym przypadku i powinna wykazać znaczący zwrot z inwestycji. Analiza kosztów i zysków powinna zawierać porównanie następujących grup kosztów związanych z pracą ręczną i wspomaganą narzędziami (roboczogodziny wyrażone jako koszt, koszty bezpośrednie, koszty jednorazowe i cykliczne):
- koszty początkowe
- zdobycie wiedzy (krzywa uczenia się narzędzia)
- ewaluacja (porównanie narzędzi), tam gdzie jest to potrzebne
- integracja z innymi narzędziami
- wstępne koszty nabycia, adaptacji lub rozwoju narzędzia
- koszty cykliczne
- koszt posiadania narzędzia (utrzymanie, opłaty licencyjne, opłaty serwisowe, utrzymanie poziomu wiedzy)
- przenaszalność
- dostępność i zależności (jeżeli brak)
- ciągła ocena kosztów
- doskonalenie jakości w celu zapewnienia optymalnego użycia wybranych narzędzi
Uzasadnienia biznesowe oparte jedynie o projekty pilotażowe często pomijają ważne elementy kosztów takie jak koszt utrzymania, uaktualniania i rozszerzania skryptów przy zmianach systemu. Wytrzymałość[1] przypadków testowych mówi o tym jak długo przypadek testowy pozostaje aktualny bez ingerencję w niego. Czas potrzebny na zaimplementowanie pierwszej wersji automatycznego skryptu testowego często znacznie przekracza czas wykonania ich ręcznego, ale umożliwia tworzenie następnych podobnych skryptów dużo szybciej i łatwe rozszerzanie zbiorów dobrych przypadków testowych. Dodatkowo znacząco polepszy się pokrycie testowe i efektywność testów podczas użycia automatyzacji później po fazie implementacji. Uzasadnienie biznesowe wdrażania narzędzi testowych musi mieć oparcie w długoterminowych zyskach biznesowych.
Celowość automatyzacji musi być przeanalizowana dla każdego z przypadków testowych na każdym z poziomów testowania. Wiele projektów automatyzacji polega na implementacji już gotowych ręcznych przypadków testowych bez rozpatrzenia, czy automatyzacja konkretnych przypadków testowych przyniesie jakkolwiek korzyści. Najprawdopodobniej każdy zbiór przypadków testowych (zestaw testowy) będzie zawierał testy ręczne, półautomatyczne i zautomatyzowane.
Następujące aspekty powinny zostać rozważone ponad te, które zostały przedstawione w sylabusie poziomu podstawowego:
- czas wykonania[2] automatycznych testów staje się bardziej przewidywalny
- w końcowej fazie projektu testowanie regresyjne i walidacja usterek[3] jest szybsza i bezpieczniejsza, jeżeli testy są zautomatyzowane
- używanie narzędzi do automatyzacji może podnieść status i wspomóc rozwój techniczny testerów i zespołu testowego
- automatyzacja może zostać wykorzystana w równoległym, iteracyjnym i inkrementalnym rozwoju oprogramowania do lepszego testowania regresywnego każdego buildu
- pokrycie pewnych typów testów, które nie może zostać osiągnięte ręcznie (np. testy wydajnościowe i testy niezawodności)
Dodatkowe obszary ryzyka:
- niekompletne lub nieprawidłowe testy ręczne zostają zautomatyzowane bez zmian
- występują trudności w utrzymaniu testaliów, gdyż wymagane jest wiele zmian gdy testowane oprogramowanie się zmieni
- następuje zmniejszenie zaangażowania testerów w wykonanie testów ponieważ tylko zautomatyzowane, oskryptowane testy są wykonywane, co może zmniejszyć wykrywalność defektów
9.2.2 Strategie narzędzi testowych
Narzędzia testowe są zwykle przeznaczone do wykorzystania więcej niż jednym projekcie. W zależności od wielkości inwestycji i długości projektu, odpowiedni zwrot z inwestycji może nie zostać w danym projekcie osiągnięty, ale mógłby być osiągnięty w kolejnych wersjach oprogramowania. Na przykład, biorąc pod uwagę, że faza utrzymania często wymaga wielu testów (dla każdej poprawki należy wykonać duży zestaw testów regresywnych), może opłacać się automatyzacja testów systemu, który jest w tej fazie pod warunkiem że długość życia systemu jest wystarczająca. Na przykład również, łatwo jest się pomylić wykonując testy ręczne (np. robiąc literówki), więc korzystne może być zautomatyzowanie wprowadzania danych oraz porównania danych wyjściowych z danymi z wyroczni (porównanie wyniku rzeczywistego z oczekiwanym).
Firmy, które korzystają i są zależne od wielu narzędzi (w wielu fazach i dla różnych celów), powinny posiadać długoterminową strategię narzędzi testowych wspierającą podejmowanie decyzji wdrażania i wycofywania różnych wersji narzędzi i wsparcia dla nich. W większych firmach, intensywnie korzystających z narzędzi, powinny istnieć wytyczne co do zakupu narzędzi, strategii oraz użycia paradygmatów narzędzi i języków skryptowych.
9.2.3 Integracja i wymiana informacji pomiędzy narzędziami
Zwykle w procesie testowania (i rozwoju oprogramowania) używane jest więcej niż jedno narzędzie. Weźmy pod uwagę przykład firmy używającej równolegle narzędzi do analizy statycznej, do zarządzania testami i raportowania, do zarządzania konfiguracją, do zarządzania incydentami oraz do wykonywania testów. Ważne jest rozważenie tego, czy te narzędzia mogą wymieniać między sobą informacje w sposób dający korzyści. Na przykład, przydatne byłoby raportowanie przez narzędzie do wykonywania testów statusu testów wprost do narzędzia do zarządzania testami i w ten sposób natychmiastowe uaktualnianie postępu testów oraz umożliwienie śledzenia powiązań pomiędzy wymaganiami a konkretnym przypadkiem testowym. Trzymanie skryptów testowych zarówno w bazie zarządzania testami oraz systemie do zarządzania konfiguracją jest bardziej pracochłonne i narażone na błędy. Jeżeli tester chce utworzyć raport incydentu w środku wykonywania przypadku testowego, narzędzia do zarządzania testami i do śledzenia defektów muszą być zintegrowane. Chociaż narzędzie do analizy statycznej może nie być połączone z innymi narzędziami, byłoby dużo wygodniej, gdyby mogło raportować incydenty, ostrzeżenia i wyniki analizy wprost do systemu zarządzania testami.
Nabycie zestawu narzędzi testowych od jednego dostawcy, nie oznacza automatycznie, że pracują one w ten sposób, ale jest to rozsądnym wymaganiem. Należy ocenić wszystkie aspekty, od kosztu automatyzacji wymiany informacji do ryzyka fałszowania lub utraty informacji przy przenoszeniu ręcznym, zakładając że organizacja może sobie pozwolić na pracę jakiej to będzie wymagać.
Nowe koncepcje takie jak zintegrowane środowiska deweloperskie (takie jak Eclipse) mają na celu ułatwienie integracji i używania różnych narzędzi w tym samym środowisku przez udostępnienie wspólnego interfejsu dla narzędzi deweloperskich i testowych. Dostawca narzędzia może stać się "zgodny" z Eclipse przez utworzenie wtyczki do Eclipsa i nadanie mu tego samego wyglądu i sposobu działania jaki ma każde inne narzędzie. Jest to korzystne dla użytkownika. Zauważ, że podobieństwo interfejsów użytkownika pomiędzy narzędziami nie oznacza automatycznie ich integracji i wymiany informacji między nimi.
9.2.4 Języki automatyzacji: skrypty, języki skryptowe
Skrypty i języki skryptowe są czasami używane aby lepiej zaimplementować lub rozwinąć warunki testowe lub przypadki testowe. Na przykład w testowaniu aplikacji webowych, można użyć skryptu do pominięcia interfejsu użytkownika i lepszego przetestowania samego API[4]. Innym przykładem może być automatyzacja testów interfejsu użytkownika, w celu wprowadzenia wszystkich kombinacji danych wejściowych co byłoby niewykonalne przy użyciu testów ręcznych.
Możliwości języków skryptowych bardzo się różnią. Należy zauważyć, że języki skryptowe mogą być zarówno normalnymi językami programowania jak i bardzo wyspecjalizowanymi standardami notacji (np. TTCN-3).
9.2.5 Wyrocznie testowe
Wyrocznie testowe są głównie używane do ustalenia wyników oczekiwanych. Jako takie więc wykonują te same funkcje co testowane oprogramowanie i są rzadko dostępne. Jednakże mogą być używane, gdy stary system jest zastępowany nowym realizującym te same funkcje. W takich przypadkach stary system może być wyrocznią testową. Wyroczni można używać również. gdy jest problem z wydajnością dostarczanego systemu. Może zostać zbudowana lub użyta wolnodziałająca wyrocznia do testów funkcjonalnych wysokowydajnego systemu, który jest dostarczany.
9.2.6 Wdrażanie narzędzi testowych
Każde z narzędzi testowych jest samo w sobie programem i może posiadać programowe lub sprzętowe zależności. Narzędzie powinno być udokumentowane i przetestowane niezależnie od tego czy zostało kupione, adaptowane, czy wytworzone lokalnie. Niektóre narzędzia są bardziej zintegrowane ze środowiskiem, natomiast inne lepiej pracują pojedynczo.
W przypadkach gdy testowany system działa na własnym sprzęcie, systemie operacyjnym, oprogramowaniu osadzonym lub używa niestandardowej konfiguracji, może być konieczne utworzenie (rozwój) narzędzi lub dostosowanie narzędzi do konkretnego środowiska. Zawsze należy przeprowadzić analizę korzyści i kosztów, w której należy zawrzeć zarówno koszty implementacji, jak i długoterminowego utrzymania.
W czasie wdrożenia narzędzi do automatyzacji testów nie zawsze dobrym rozwiązaniem jest automatyzacja przypadków testowych w takiej formie w jakiej już istnieją, ale raczej przeprojektowanie ich tak, żeby się lepiej nadawały do automatyzacji. Oznacza to zmianę formatowania przypadków testowych, rozważenie reużycia wzorców, rozszerzenie wejścia przez użycie zmiennych zamiast ustalonych wartości oraz wykorzystanie zalet narzędzia testowego, które może trawersować, powtarzać, zmieniać kolejność w połączeniu z lepszą analizą i raportowaniem. W przypadku wielu narzędzi do automatyzacji testów, do stworzenia skutecznych i efektywnych skryptów testowych konieczne jest posiadanie umiejętności programistycznych. Często zdarza się, że duże zestawy testów są trudne do uaktualniania i zarządzania, o ile nie zostały zaprojektowane z uwagą. Do pełnego wykorzystania zalet narzędzi bardzo wskazane są odpowiednie szkolenia z narzędzi testowych oraz technik programowania i projektowania.
Nawet jeżeli ręczne przypadki testowe zostały zautomatyzowane, bardzo ważne jest wykonywanie ich co jakiś czas manualnie, aby przypomnieć sobie jak test działa i sprawdzić czy działa poprawnie.
Kiedy narzędzie wchodzi w szersze użycie i liczba skryptów rośnie, może zajść potrzeba wykorzystania funkcji oferowanych przez inne narzędzia. Nie zawsze jest to możliwe, ponieważ nie wszystkie narzędzia posiadają otwarte interfejsy i czasami wykorzystują własne niestandardowe języki skryptowe. Mądrze jest używać narzędzi posiadających wtyczki do otwartych platform lub API. To zagwarantuje lepszą możliwość wykorzystania skryptów do testów w przyszłości.
Dla każdego narzędzia, niezależnie od fazy w której ma być użyte, rozważ niżej wymienione cechy. Cechy te można wykorzystać przy ocenie narzędzi oraz podczas tworzenia własnych narzędzi. W każdym z tych obszarów narzędzie może być mocne lub słabe. Taka lista jest użyteczna przy porównywaniu podobnych narzędzi.
- analiza (zrozumienie koncepcji, wejścia, informacje dostarczane ręcznie lub automatycznie)
- projektowanie (ręczne, generowanie automatycznie)
- wybór (ręczny, przypadki testowe wybierane automatycznie według różnych kryteriów np. pokrycia)
- wykonanie (ręczne, automatyczne, sterujące, restartujące itp.)
- ocena (np. wyrocznia testowa) i prezentacja - nazywane też często logowaniem i raportowaniem (ręczne, automatyczne np. porównawcze, według formy, standardu, wygenerowane według kryteriów)
9.2.7 Użycie otwartych narzędzi otwartych
Narzędzia używane do testów systemów krytycznych ze względu na bezpieczeństwo muszą posiadać certyfikaty zgodności z odpowiednimi standardami. Nie należy używać narzędzi otwartych do testowania systemów krytycznych ze względu na bezpieczeństwo, chyba że posiadają odpowiednie certyfikaty.
Jakość otwartych narzędzi zależy od ilości użytkowników, historii oraz użytkowania i nie powinny być uważane za bardziej (ani mniej) dokładne od narzędzi komercyjnych.
Dla każdego narzędzia testowego należy wykonać ocenę jakości, aby poznać jego dokładność. W przypadku niektórych narzędzi łatwiej jest pomylić pozytywną ocenę wyników testów z błędem w wykonaniu testów (np. narzędzie pominęło wykonanie testu i nie zaraportowało pominięcia). Powinno się dokładnie przyjrzeć opłatom licencyjnym. Może też istnieć oczekiwanie, że modyfikacje wykonane w celu ulepszenia narzędzia zostaną udostępnione publicznie.
9.2.8 Rozwój własnych narzędzi
Wiele narzędzi testowych powstaje by zaspokoić potrzeby pojedynczego testera lub projektanta i przyspieszyć jego pracę. Innymi powodami rozwoju własnych narzędzi testowych może być brak odpowiednich narzędzi komercyjnych lub wykorzystywanie własnego sprzętu lub środowiska testowego. Narzędzie takie często efektywnie wykonuje zadania do których zostało stworzone, ale też często zależy od osoby twórcy. Powinno ono zostać udokumentowane tak, żeby mogło być utrzymywane przez innych. Ważne jest również rozważenie celowości, korzyści oraz możliwych problemów przed rozszerzeniem jego użycia w organizacji. Dla takich narzędzi często pojawiają się nowe wymagania i są rozwijane daleko poza początkowy sposób użycia, co może nie być korzystne.
9.2.9 Klasyfikacja narzędzi testowych
Oprócz podziału narzędzi według zadań które wspierają (taki podział wykorzystany jest w sylabusie poziomu podstawowego), istnieją inne sposoby klasyfikacji narzędzi testowych:
- według poziomu testów (modułowe, integracyjne, systemowe, akceptacyjne)
- według rodzaju awarii, które rozpoznają i wspierają
- według podejścia do testowania lub techniki testowania (patrz dyskusja poniżej)
- według celów (pomiary, drajwery testowe, logowanie, porównywanie)
- według dziedziny (symulacja sygnalizacji i ruchu, sieci, protokoły, transakcje, ekrany TV, systemy eksperckie)
- według wspieranego obszaru testowania (wprowadzanie danych, środowisko, konfiguracja i inne)
- według sposobu wdrożenia (z półki, platformy do adaptacji, wtyczki, standardowe lub certyfikacyjne zestawy testów, wytworzone lokalnie)
I na koniec narzędzia mogą być pogrupowane według ich użytkowników, takich jak kierownicy testów, analitycy testowi i techniczni analitycy testowi. To grupowanie, które odzwierciedla moduły tego sylabusa jest używane przez dalszą część tego rozdziału. Sylabus poziomu podstawowego zawiera rozdział rozpatrujący narzędzia testowe. Poniższe sekcje zawierają dodatkowe aspekty narzędzi.
