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.