Testowanie
Testowanie
Oprogramowania
Oprogramowania
Wykład
Zakład Modelowania i Grafiki
Komputerowej
Testowanie
Testowanie
Oprogramowania
Oprogramowania
Wykład
Zakład Modelowania i Grafiki
Komputerowej
Pojęcie testowania
systemu / programu
Testowanie nie jest procesem potwierdzającym
poprawność programu i polegającym na wykazaniu,
że program nie ma błędów,
lecz
Testowanie
polega
na
wykonywaniu
programu w taki sposób, aby wykryć jak
najwięcej błędów.
Wykazanie obecności błędów, a nie
nieobecności błędów
Testowanie
oprogramowania
Jest integralną częścią wszystkich metodyk jego wytwarzania
•Pojęcia, strategie oraz techniki testowania
powinny być określone jako pojedynczy
kontrolowany proces.
•Takie podejście wspiera i ułatwia prace zespołu
testującego na każdym etapie, począwszy od
planowania testów aż do momentu oceny
wyników procesu testowania
Poziomy
Testowania
Testowanie oprogramowania wykonywane
jest zwykle na różnych poziomach podczas
procesu jego rozwijania i utrzymywania.
Test zgodnie z założeniami może się zmieniać
i może dotyczyć (zgodnie ze standardem
IEEE/EIA 12207.0):
• jednostek,
• pojedynczego modułu,
• grupy takich modułów (odpowiednio do celu,
wykorzystania, zachowywania się lub
struktury), lub
• całego systemu.
Cele – odniesienia
testowania
Pojęciowo mogą być rozważane trzy duże
etapy, mianowicie: grupa, integracja, i system.
Żaden model procesu nie jest sugerowany,
ani żaden z trzech procesów nie zakłada, iż jest
ważniejszy od dwóch pozostałych.
Istotne jest zarządzanie testami; szczególną
uwagę przywiązywać należy do: polityki
testowania firmy, użytych narzędzi oraz ludzi.
Testowanie jednostek
... polega na dowiedzeniu, iż poszczególne
komponenty działają poprawnie.
Na tym etapie jednostka testowana jest
niezależnie
Poziomy Testowania
–
Testowanie
grupy(modułu)
Test modułu weryfikuje w izolacji
funkcjonowanie kawałków oprogramowania,
testowane oddzielnie. W zależności od
kontekstu, mogą to być indywidualne
(oddzielne) podprogramy, lub większe
komponenty wykonane z ściśle powiązanych
jednostek (modułów).
Testowanie modułu –
grupy modułów
Test modułu jest definiowany bardziej
precyzyjnie w standardzie IEEE dla
Testowania modułu oprogramowania
(Software Unit Testing – IEEE1008-87), który
także opisuje zintegrowane podejście do
systematycznego dokumentowanego testowania
modułów.
Testowanie modułu następuje wraz z
dostępem do testowanego kodu i ze
wspomaganiem narzędzi debagujących, a
także może obejmować programistów, którzy
tworzyli kod.
Poziomy Testowania
–
Testowanie integrujące
Testowanie integrujące jest procesem
weryfikującym oddziaływanie
pomiędzy komponentami
oprogramowania. Klasyczne strategie
testowania integrującego, takie jak
„top-down” i „bottom_up”, stosowane
w tradycyjnym, hierarchicznie
skomponowanym oprogramowaniu.
Testowanie integrujące –
metody
•testowanie wstępujące; jedynymi modułami
testowanymi osobno są moduły terminalne (nie
wywołujące innych modułów); program jest
łączony i testowany od dołu do góry;
•testowanie zstępujące (czyli analityczne);
program jest łączony i testowany z góry na dół;
jedynym modułem testowanym osobno jest moduł
zajmujący szczytową pozycję w strukturze
programu;
•zmodyfikowane testowanie zstępujące;
wymaga się, aby przed włączeniem do programu
każdy moduł był przetestowany osobno – wymaga
sporządzenia modułów sterujących oraz
namiastek każdego modułu;
Testowanie integrujące –
metody
•testowanie „big-bang”; pierwszy krok
przetestowanie każdego modułu w izolacji od
pozostałych; następnie wszystkie moduły scala
się naraz;
•testowanie mieszane; zastosowanie
częściowego testowania zstępującego i
wstępującego;
•zmodyfikowane testowanie mieszane – patrz
testowanie zstępujące zmodyfikowane;
•integracja komponentów oprogramowania
lub podsystemów bazująca na
identyfikowanych funkcjonalnie wątkach;
•metoda ciągłej integracji (patrz ewolucyjne
metody projektowania)
Testowanie integrujące
Nowoczesne strategie systematycznej integracji
są raczej sterowane architekturą, które stosują
integrację komponentów oprogramowania lub
podsystemów bazujące na identyfikowanych
funkcjonalnie wątkach.
Integracyjne testowanie jest działalnością ciągłą
na każdym kroku, na którym inżynierowie
oprogramowania muszą abstrahować od
perspektyw niższego poziomu i równocześnie
koncentrować się na poziomie ich integracji.
Z wyjątkiem małych, prostych programów,
strategie systematycznego ciągłego testowania
integrującego są zwykle preferowane w odróżnieniu
od łączenia komponentów w całość jednocześnie,
zwanego testowaniem „big-bang”.
Testowanie systemu
Testowanie systemu wiąże się z zachowaniem
się całego systemu. Większość błędów
funkcjonalnych powinno zostać
zidentyfikowanych (rozpoznanych) podczas
testowania modułów i testowania integrującego.
Testowanie systemu zwykle rozpatrywane jest
stosownie dla porównania systemu do wymagań
systemu nie-funkcjonalnego, w tym
zabezpieczenie, prędkość, dokładność, i
niezawodność.
Na tym poziomie oceniane są interfejsy do
innych aplikacji, użyteczność, urządzenia
peryferyjne, lub inne otoczenie operacyjne.
Cele testowania
Testowanie jest połączone ze spojrzeniem na
specyficzne cele, stawiane bardziej lub mniej
otwarcie, i z różnym stopniem precyzji.
Stawiając precyzyjnie cele, wyrażenie
ilościowe pozwala sterować dla zapanowania nad
procesem testowania.
Cele testowania
Testowanie może zmierzać do weryfikacji różnych
właściwości.
Testowanie przypadków może zmierzać do
sprawdzenia czy specyfikacja funkcjonalna została
poprawnie zaimplementowana, co jest różnie
opisywane w literaturze jako conformance testing
(testowanie „dostosowawcze”), correctness
testing (testowanie „poprawności”), lub testowanie
funcjonalne (functional).
Jakkolwiek, różne inne nie-funkcjonalne
właściwości także mogą być testowane, włączając w
to osiągi (charakterystyki), niezawodność,
użyteczność, i wiele innych.
Cele testowania
Inne ważne cele (bez ograniczenia się tylko do
nich) obejmują niezawodność, wymiarowanie,
oszacowanie użyteczności, i akceptacji, dla których
zaproponowano różne podejścia.
Należy zwrócić uwagę, że cele testowania
zmieniają się z testowaniem celem odniesienia.
Ogólnie, różne cele są stawiane na różnych
poziomach testowania.
Niektóre rodzaje testowania są bardziej stosowne
do zestawu wykonywanego na zamówienie, na
przykład test instalacyjny, inne dla produktów
seryjnych podobne do testowania typu beta.
Cele testowania –
podział
1. testowanie akceptacyjne/kwalifikacyjne –
zestawienie zachowania się oprogramowania z
oczekiwaniami klienta;
2. testowanie instalacyjne – test jakości instalacji
w danym środowisku; testowane są również
wskazane procedury instalacyjne;
3. alpha and beta testing; trial testowany jest
przez grupę wewnętrznych użytkowników (alfa-
testing) lub zewnętrznych (beta-testing);
4. testowanie funkcjonalne (conformance
testing/correctness testing); porównanie
zachowania się systemu z zapisem specyfikacji;
5. spełnienie (poprawa) i wyznaczenie
niezawodności;
Cele testowania –
podział c.d.
6. testowanie regresji; selektywne re-testowanie
systemu lub podprogramu (modułu) dla
sprawdzenia, czy dokonane modyfikacje nie
spowodowały nieoczekiwanych efektów;
dokonywane najczęściej podczas integracji
systemu;
7. testowanie osiągów;
8. testowanie stresu;
9. back-to-back testing (testowanie
symetryczne); porównanie wyników testów
zrealizowanych na dwóch różnych
implementacjach programów;
Cele testowania –
podział c.d.
10.recovery testing (test odzyskiwania);
odzyskanie sprawności przez system po
„klęsce”;
11.test konfiguracji; testowanie programu przy
różnych konfiguracjach systemu;
12.test użyteczności;
13.test-driven development; testy nie dla
samego testowania, lecz dla kierowania
procesem projektowania;
Techniki
testowania
Jednym z celów testowania jest odsłonięcie, tak
wiele jak to możliwe, potencjalnych defektów,
Opracowano – rozwinięto wiele technik dla
tego celu, które usiłują przerwać („break”)
program podczas uruchomienia jednego lub
więcej przebiegów testowych odpowiadających
identyfikacji klas wykonań domniemanego
odpowiednika.
Wiodąca zasada podkreślająca takie techniki,
to być systematycznym jak to możliwe w
identyfikacji reprezentatywnego zbioru zachowań
programu;
– na przykład, rozpatrując podklasy dziedziny
wejściowej, scenariuszy, stanów, i przepływu
danych.
Techniki
testowania
Znalezienie jednorodnych podstaw dla
klasyfikacji wszystkich technik, – użyty tutaj jest
kompromisem.
Klasyfikacja jest oparta: na tym, jak testy są
generowane:
•z intuicji inżyniera oprogramowania,
•doświadczenia,
•specyfikacji,
•struktury kodu, dla wykrycia (rzeczywistych
lub sztucznych) błędów,
•obszaru wykorzystania, a w końcu, natury
aplikacji.
Techniki
testowania
Czasami te techniki są klasyfikowane jak biała
skrzynka, zwana także szklaną skrzynką, jeżeli
testy polegają na informacji na tym jak program
był projektowany lub kodowany, lub jak czarna
skrzynka jeżeli przypadki testu opierają się tylko
na zachowaniu wejście/wyjście (testowanie
funkcjonalne).
Ostatnia kategoria dotyczy użycia kombinacji
dwóch lub więcej technik. Oczywiście te techniki
nie są użyte dokładnie tak samo przez wszystkich
praktyków. Zawarte na poniższej liście powinny
być znane inżynierom oprogramowania.
Techniki oparte na
intuicji i doświadczeniu
inżynierów
oprogramowania
Testowanie Ad hoc
Może najszerzej praktykowaną
technika pozostaje testowanie ad hoc:
testy są dostarczane polegające na
umiejętności inżyniera oprogramowania,
intuicji, doświadczeniu w podobnych
programach.
Ad hoc testing może być użyteczny w
identyfikacji testów specjalnych, które
nie łatwo dają się uchwycić przez
techniki formalne.
Testowanie poszukujące
(exploratory testing)
Testowanie poszukujące definiowane jest jako
równoczesne uczenie, projektowanie testu i
wykonywanie testu;
•Testy nie są definiowane z góry (z wyprzedzeniem)
z założonym planie testowania, lecz są dynamicznie
projektowane, wykonywane i modyfikowane.
•Efektywność testowania poszukującego opiera się
na wiedzy inżyniera oprogramowania, która może
być dostarczana z różnych źródeł:
obserwacji zachowania się produktu podczas
testowania
, zaznajomienia się z aplikacją,
platformą, procesem defektu
, typami
możliwych błędów i defektów,
ryzyko związane
z poszczególnym produktem
, oraz podobne.
Techniki testowania
oparte na specyfikacji.
Ekwiwalentny podział
Dziedzina wejściowa zostaje podzielona na
kolekcję podzbiorów, lub równoważnych klas, które
są domniemanymi odpowiednikami odpowiednio do
specyficznych relacji, i reprezentatywny zbiór testów
(czasami tylko jeden) pobierany jest z każdej klasy.
Testowanie nazywane dzieleniem na klasy
równoważności polega na odnalezieniu wszystkich
wspomnianych klas, które w dalszej kolejności
posłużą do budowy przypadków testowych
Jeżeli istnieją wartości danych, które nie zostały
uwzględnione w żadnej klasie równoważności, mogą
być wykorzystane w tzw. Abnormal tests – testach
dzięki którym można sprawdzić zachowanie
programu dla nieoczekiwanych wartości wejściowych
Analiza wartości
brzegowych
Testowe przypadki są wybierane w oparciu o
bliskość brzegów dziedziny wejściowej
zmiennych, z podkreśleniem racjonalnym, że
wiele błędów skłania się do koncentracji w
pobliżu wartości ekstremalnych wejść.
Rozwinięciem tej techniki jest testowanie
„krzepkości” („robustness”), w którym przypadki
testowe są także wybierane spoza dziedziny
wejściowej zmiennych, dla testowania krzepkości
programu na nieoczekiwane lub błędne dane
wejściowe.
Tabela decyzji
Tabela decyzji przedstawia zależność
pomiędzy warunkami (zgrubnie,
wejściowe) a czynnościami (akcjami)
(zgrubnie, wyjściowe). Przypadki testowe
są systematycznie dostarczane przez
rozpatrywanie każdej możliwej
kombinacji warunków i czynności.
Odpowiednią techniką jest cause-effect
graphing (rysowanie efektu
przyczynowego).
Test oparty na
diagramie stanów
(Finite-state machine-
based)
Podczas modelowania programu jako automatu
stanów skończonych, testy mogą zostać wybrane
by pokryć stany i przejścia między nimi.
Testowanie oparte na
formalnej specyfikacji
Przedstawienie specyfikacji w języku formalnym
pozwala na automatyczne wyznaczanie
funkcjonalnych przypadków testowych, i , w tym
samym czasie, dostarczać odpowiednie wyjście,
wyrokując, dla sprawdzenia wyników testu. Metoda
stosowana w dostarczaniu przypadków testowych z
opartego na modelowaniu lub algebraicznej
specyfikacji.
Testowanie losowe
Testy generowane są w sposób czysto losowy, nie
mieszać z testowaniem statystycznym z
działającego profilu. Ta postać testowania podpada
pod tytuł podejście oparte na specyfikacji,
ponieważ musi być znana przynajmniej dziedzina
wejściowa, by umożliwić wybór losowy punktu
wewnątrz tej dziedziny.