Inżynieria
oprogramowania

Część 6: Testowanie

oprogramowania

Zawartość



Testowanie wytwórcze



Wytwórstwo sterowane testami



Testowanie odbiorcze



Testowanie użytkownika

Testowanie
oprogramowania



Testowanie ma wykazać, że oprogramowanie
spełnia swoją specyfikację oraz wykryć błędy.



Testowanie polega na uruchomianiu
oprogramowania przy użyciu sztucznych danych.



Testowanie pozwala wykryć błędy, natomiast
nigdy nie gwarantuje że błędów nie ma.



Testowanie jest częścią procesu zatwierdzania
oprogramowanie, które może dodatkowo
korzystać ze statycznych metod weryfikacji.

Testowanie weryfikacyjne i
testowanie defektów



Testowanie weryfikacyjne



Wykazanie, że oprogramowanie spełnia
swoją specyfikację.



Test uznajemy za udany jeśli pokazuje, że
system działa w sposób zamierzony.



Testowanie defektów



Znalezienie defektów w oprogramowaniu.



Test uznajemy za udany jeśli pozwala
wykryć błąd.

Testowanie defektów -- model
czarnej skrzynki

System

Testowe dane

wejściowe

Wyniki wyjściowe

testów

Dane wejściowe

powodujące

anomalne zachowanie

Dane wyjściowe,
które umożliwiają
wykrycie defektów

Weryfikacja vs. walidacja



Weryfikacja

– czy właściwie budujemy

produkt?



Oprogramowanie powinno być zgodne ze
swoją specyfikacją.



Walidacja

– czy budujemy właściwy

produkt?



Oprogramowanie powinno być zgodne z
oczekiwaniami klienta.

Zaufanie do procesu
weryfikacji i walidacji



Stopień zaufania do procesu weryfikacji i

walidacji zależy od kilku czynników.



Od rodzaju oprogramowania: systemy

krytyczne wymagają bardzo rygorystycznego

standardu weryfikacji i walidacji.



Od oczekiwań klientów: klienci mogą

akceptować pewne usterki jeśli mimo to

używanie systemu jest dla nich opłacalne.



Od rynku: jeśli oprogramowanie będzie

dostępne na wolnym rynku, wytwórca może

pójść na pewne kompromisy, aby skrócić czas

wytwarzania lub obniżyć cenę produktu.

Kontrole oprogramowania vs.
testowanie



Kontrole oprogramowania



Mają charakter statyczny. Polegają na analizie
systemu, często przy użyciu automatycznych
narzędzi. Pojedyncza kontrola pozwala często
wykryć wiele defektów.



Testowanie



Ma charakter dynamiczny. Polega na uruchomianiu
systemu dla wybranych danych. W odróżnieniu od
kontroli oprogramowania, pojedynczy test pozwala
na ogół wykryć tylko pojedynczy defekt.

Kontrole oprogramowania
vs. testowanie

Kontrole

oprogramowania

Kontrole

oprogramowania

Testowanie

Prototyp
systemu

Specyfikacja

wymagań

Architektura

Projekt

System

Kontrole oprogramowania



Ponieważ nie wymagają wykonywania
programu, mogą być przeprowadzane przed
jego ukończeniem.



Mogą dotyczyć różnych bytów związanych z
oprogramowaniem: specyfikacji wymagań,
architektury, projektu, kodu źródłowego.



Praktyka pokazała, że kontrole
oprogramowania są efektywną techniką
wykrywania błędów.

Korzyści z kontroli
oprogramowania



W odróżnieniu od klasycznego testowania,

kontrola oprogramowania może wykryć

równocześnie wiele błędów.



Kontrola oprogramowania może dotyczyć

systemu w trakcie budowy.



Poza zwykłymi błędami, kontrola

oprogramowania może dotyczyć pewnych

atrybutów budowanego systemu, takich jak

przestrzeganie wymaganych standardów, czy

łatwość pielęgnacji. Ponadto kontrola może

wykryć takie własności jak nieefektywność, czy

słaby styl programowania.

Testowanie vs. kontrole
oprogramowania



Testowanie i kontrole oprogramowania to techniki

uzupełniające się, a nie konkurujące ze sobą.



Obie te techniki powinny być używane w procesie

weryfikacji i walidacji oprogramowania.



Kontrola może stwierdzić niezgodność

oprogramowania z jego specyfikacją; nie może

stwierdzić zgodności budowanego systemu z

oczekiwaniami użytkownika.



Kontrole oprogramowania nie nadają się do

zweryfikowania wymagań niefunkcjonalnych, np.

łatwości użycia systemu.

Tradycyjny model
testowania

Zaprojektuj

przypadki

testowe

Przypad
ki

testowe

Przygotuj

dane

testowe

Dane

testowe

Wykonaj program
z danymi testowymi

Wyniki
testów

Porównaj z
przypadkami
testowymi

Raport z

testów

Rodzaje testowania



Testowanie wytwórcze



Testowanie w trakcie budowy systemu.



Testowanie odbiorcze



Zespół nie tworzący oprogramowania testuje cały
system przed oddaniem go do użycia.



Testowanie produkcyjne



Testowanie systemu w jego środowisku produkcyjnym
na rzeczywistych danych. (Środowisko produkcyjne --
sprzęt i oprogramowanie zainstalowane w siedzibie
użytkownika lub klienta, w którym system będzie 
działał.)

Testowanie wytwórcze



Testowanie wytwórcze dotyczy wszystkich
czynności związanych z testowaniem
oprogramowania przez zespół wytwórczy.



Testowanie jednostek

-- testowanie pojedynczych

jednostek programu lub klas obiektów. Testowanie to
powinno koncentrować się na wykrywaniu defektów danej
jednostki lub klasy.



Testowanie komponentów

–

kilka (kilkanaście) jednostek

łączy się w większe komponenty. Testowanie komponentów
koncentruje się na interfejsach komponentów.



Testowanie integracyjne

– Wszystkie lub niektóre

komponenty łączy się w całość. Testowanie integracyjne
koncentruje się na interakcji między komponentami.

Testowanie jednostek



Jednostki programowe testuje się w izolacji.



Celem jest wykrywanie błędów w
pojedynczych jednostkach.



Jednostką może być:



Pojedyncza funkcja (procedura) lub metoda w klasie
obiektów.



Klasa obiektów ze swoimi atrybutami i metodami.



Złożone komponenty realizujące jakąś
funkcjonalność.

Testowanie obiektów



Pełne testowanie obiektów obejmuje:



Oddzielne testowanie wszystkich operacji
związanych z obiektem.



Odczytywanie i ustalanie wszystkich atrybutów
obiektu.



Badanie obiektu we wszystkich możliwych stanach,
co oznacza, że należy zasymulować wszystkie
zdarzenia powodujące zmianę stanu obiektu.



Mechanizm dziedziczenia komplikuje proces
testowania obiektów, ponieważ informacje
podlegające testowaniu są rozproszone.

Interfejs obiektu stacja
meteorologiczna

Stacja meteorologiczna

Identyfikator

raport_pogodowy()
dostrój(przyrządy)
testuj()
uruchom(przyrządy)
wyłącz(przyrządy)

• Identyfikator to nazwa stacji. Należy sprawdzić,
czy został nadany.

• Należy sprawdzić przypadki testowe dla metod.
Najlepiej testować je w izolacji, ale czasami trzeba
niektóre z nich łącznie. Przetestowanie metody
wyłącz(przyrządy) wymaga przykładowo wcześniejszego
wykonania metody uruchom(przyrządy).

• Do testowania stanów stacji meteorologicznej można
wykorzystać diagram stanu.

Diagram stanu dla obiektu
stacja meteorologiczna

Podsumowywanie

Wyłączony

Oczekiwanie

Gromadzenie

Transmitowanie

Testowanie

Dostrajanie

Działanie

uruchom()

wyłącz()

koniec
gromadzenia

zegar

raport_pogodowy()

podsumowanie gotowe

koniec transmisji

dostrój()

testuj()

koniec testu

Wyłączony-Oczekiwanie-Wyłączony
Oczekiwanie-Dostrajanie-Testowanie-Transmitowanie-Oczekiwanie
Oczekiwanie-Gromadzenie-Oczekiwanie-Podsumowywanie-Transmitowanie-Oczekiwanie

dostrojony

Testowanie automatyczne



Jeśli jest to tylko możliwe, należy dążyć do
automatycznego testowania jednostek, aby
wyeliminować ręczne testy.



Istnieją gotowe systemy wspomagające
automatyczne testowanie, np. JUnit.



Automatyczne systemy wspomagające testowanie
zawierają szereg generycznych przypadków
testowych, które należy dopasować do
testowanych jednostek.



Główną zaletą automatycznego testowania jest
jego szybkość.

Składniki systemu
wspomagającego automatyczne
testowanie



Część startowa, w której następuje inicjalizacja
przypadku testowego poprzez podanie danych
wejściowych i spodziewanych danych wyjściowych.



Część wywołująca, gdzie definiujemy jednostkę,
która ma zostać przetestowana.



Asercja, gdzie porównujemy dane wyjściowe testu
ze spodziewanymi danymi wyjściowymi. Ta część
może zawierać dodatkowo pewne asercje
(wyrażenia logiczne), które powinny mieć wartość
true.

Efektywność testowania
jednostek



Przypadki testowe powinny wykazać, że
testowana jednostka w czasie normalnej pracy
zachowuje się tak jak powinna.



Jeśli w testowanej jednostce są błędy, powinny
być wykryte.



To prowadzi do dwóch rodzajów testów jednostek:



Pierwszy dotyczy normalnego działania jednostki i ma
potwierdzić jej zgodność ze specyfikacją.



Drugi opiera się na doświadczeniu w znajdowaniu
defektów. W szczególności należy sprawdzić działanie
jednostki dla niepoprawnych danych.

Strategie testowania
jednostek



Dzielenie na klasy równoważności – dzielimy
dane wejściowe na grupy o wspólnych
właściwościach i testujemy reprezentanta każdej
grupy.



Testowanie oparte na regułach (ang. guideline-
based testing) – opracowujemy testy na
podstawie pewnych reguł opartych na
doświadczeniu w testowaniu podobnych
jednostek.

Przykład dzielenia na klasy
równoważności

Program pobiera od 4 do 10 danych wejściowych, które są
pięciocyfrowymi liczbami całkowitymi większymi od 10000.

Liczba wartości wejściowych

Mniej niż 4

Między 4 i 10

Więcej niż 10

3

4

7

10

11

Mniej niż 10 000

Między 10 000 i 99 999 Więcej niż 99 999

Wartości wejściowe

9000

10 000

50 000

99 999

100080

Przykład testowania
jednostek



Dla zadanych liczb całkowitych A, B i C znaleźć
wszystkie pierwiastki równania Ax

2

+ Bx + C =

0.



A=B=C=0



A=B=0, C≠0



A=0, B≠0, C≠0



A=0, B≠0, C=0



A≠0, B

2

̶ 4AC =0



A≠0, B

2

̶ 4AC > 0



A≠0, B

2

̶ 4AC < 0

Reguły dotyczące testowania
sekwencji (tablice, listy)



Przetestuj sekwencje jednoelementowe.
Programiści często wiążą z sekwencją kilka
elementów, co może powodować błąd dla
sekwencji jednoelementowej.



Używaj różnych sekwencji, o różnych długościach
w różnych testach. To zmiejszy szansę, że dla
specyficznych danych program z błędami
wyprodukuje poprawny wynik.



Uwzględniaj w testach pierwszy, środkowy i
ostatni element sekwencji.



Przeprowadzaj testy dla sekwencji o długości 0.

Ogólne reguły testowania
jednostek



Uwzględnij dane, które wymuszą od programu
wszystkie uwzględnione komunikaty o błędach.



Uwzględnij dane, które spowodują
przepełnienie bufora.



Powtórz niektóre testy.



Spróbuj znaleźć dane, które spowodują, że
wynik będzie za mały lub za duży.

Testowanie komponentów



Komponent składa się z kilku lub większej
liczby współpracujących ze sobą jednostek.



Komponent komunikuje się z innymi
komponentami poprzez swój interfejs.



Dlatego testowanie komponentu sprowadza się
do testowania jego interfejsu i ma za zadanie
wykrycie błędów wynikających z interakcji
jednostek. Na etapie testowania komponentu
możemy założyć, że testy jego składowych
(jednostek) zostały zakończone.

Testowanie interfejsu

Przypadki

testowe

A

B

C

A, B, C -- jednostki

Rodzaje interfejsów



Interfejsy parametryczne.

Dane lub odwołania do funkcji są

przekazywane od jednego komponentu do drugiego.



Interfejsy w pamięci dzielonej.

Blok pamięci jest dzielony

między podsystemami. Dane są umieszczane w tym bloku
przez jeden podsystem i pobierane stamtąd przez inny.



Interfejsy proceduralne.

Jeden podsystem obudowuje zbiór

procedur wywoływanych przez inne podsystemy. Interfejsy
tego rodzaju mają obiekty.



Interfejsy z przekazywaniem komunikatów.

Jeden podsystem

żąda usługi od innego wysyłając mu komunikat. Wyniki
usługi zawiera komunikat zwrotny. Tego typu interfejs mają
systemy klient-serwer.

Błędy w interfejsach



Niewłaściwe użycie interfejsu.



Komponent wywołujący inny komponent popełnia błąd
użycia tego interfejsu. na przykład w interfejsie
parametrycznym parametry zostały podane w niewłaściwej
kolejności.



Niezrozumienie interfejsu.



Twórcy komponentu wywołującego źle zrozumieli
specyfikację komponentu wywoływanego. Na przykład
podprogram binarnego przeszukiwania jest stosowany dla
nieuporządkowanej tablicy.



Błędy synchronizacji.



Występują w ystemach współbieżnych i rozproszonych. Na
przykład konsument pobiera po raz kolejny te same dane
producenta.

Reguły dotyczące testowania
interfejsów



Zanalizuj testowany kod i jawnie wypisz

wszystkie wywołania zewnętrznych

komponentów. Opracuj test, w których wartości

parametrów zewnętrznych komponentów leżą na

granicach zakresów.



Gdy przez interfejs przekazuje się wskaźniki

zawsze przetestuj ten interfejs z zerowymi

wartościami wskaźników.



Jeśli możliwe spróbuj opracować testy, które

spowodują awarię komponentu. Różniące się

założenia o awariach są jednym z najczęściej

występujących nieporozumień co do specyfikacji.

Reguły dotyczące testowania
interfejsów



W przypadku interfejsu z przekazywaniem
komunikatów wykonaj testy obciążeniowe.
Polegają one na przesyłaniu znacznie większej
liczby komunikatów niż wystąpi to w praktyce.



W przypadku kiedy występuje interakcja kilku
komponentów przez pamięć dzieloną, opracuj testy
różniące się uruchomiania tych komponentów.
Testy te mogą doprowadzić do wykrycia
niejawnych, przyjętych przez programistę założeń
dotyczących porządku produkcji i konsumpcji
dzielonych danych.

Testowanie integracyjne



Po odrębnym przetestowaniu komponentów

należy je zintegrować w gotowy lub częściowo

ukończony system.



Testowanie zintegrowanego systemu koncentruje

się na interakcjach między komponentami.



Testy integracyjne systemu opierają się na jego

specyfikacji.



Testowanie integracyjne należy rozpocząć

niezwłocznie po zakończeniu testowania

komponentów.

Testowanie integracyjne



W trakcie testowania integracyjnego łączy się
wytworzone komponenty z komponentami
wielokrotnego użycia (jeśli są wykorzystywane).



Testowanie integracyjne jest działalnością
zespołową, ponieważ w przypadku dużych systemów
poszczególne komponenty podlegające integracji są
na ogół budowane przez różne zespoły.



W niektórych firmach testowanie integracyjne
przeprowadza oddzielny zespół testujący.

Testowanie integracyjne



Największą trudnością testowania integracyjnego jest

lokalizowanie błędów wykrytych w trakcie tego procesu.



Aby ułatwić lokalizację błędu, należy stosować

przyrostowe podejście do integracji i testowania

systemu.



Na początku należy zintegrować pewną minimalną

konfigurację systemu i ją przetestować. Następnie

należy dodawać kolejne komponenty i testować po

każdym dodanym przyroście.



W testowaniu integracyjnym można wykorzystać

diagramy przypadków użycia.

Strategie testowania
integracyjnego



W przypadku dużych systemów pełne
przetestowanie integracyjne jest niemożliwe. W
związku z tym firma powinna opracować strategię
tego typu testowania.



Przykład strategii testowania integracyjnego:



Należy przetestować wszystkie funkcje systemu
wywoływane z menu.



Należy przetestować wszystkie możliwe kombinacje
funkcji znajdujących się w pojedynczym menu.



W przypadku kiedy usługa wymaga danych otrzymanych
od użytkownika, należy przetestować zarówno poprawne
jak i niepoprawne dane.

Wytwórstwo sterowane
testami (ang. test-driven
development)



Wytwórstwo sterowane testami (WST) jest technologią
budowy oprogramowania, gdzie testowanie i kodowanie
przeplatają się.



WST należy do przyrostowego modelu budowy
oprogramowania. Testy dotyczące kolejnego przyrostu
definiowane są przez napisaniem kodu realizującego ten
przyrost. Udane testy są konieczne, aby przejść do
kolejnego przyrostu.



WST powstało w kontekście programowania zwinnego
(szczególnie programowania ekstremalnego). Obecnie
technika ta jest również stosowana w zaplanowanym
modelu tworzenia oprogramowania.

Wytwórstwo sterowane
testami

Zdefiniuj nową
funkcjonalnoś
ć

Przygotuj

testy

Zaimplement

uj

funkcjonalnoś

ć

i

przeprowadź

refaktoryzacj

ę

Wykonaj

testy

OK?

NIE

Czynności procesu
wytwarzania sterowanego
testami



Zidentyfikuj przyrost funkcjonalności. Powinien być
mały – kilkanaście linii kodu.



Przygotuj automatyczne testy dla tej
funkcjonalności.



Zaimplementuj nową funkcjonalność i zintegruj ją z
dotychczasowym oprogramowaniem. Przeprowadź
ewentualnie faktoryzację.



Wykonaj testy przygotowane dla implementowanej
funkcjonalności oraz wszystkie testy zdefiniowane
wcześniej.



Kiedy wszystkie testy zakończą się powodzeniem,
identyfikuj następny przyrost funkcjonalności.

Zalety wytwórstwa
sterowanego testami.



Pełne pokrycie kodu testami



Z każdym (niewielkim) fragmentem kodu związany jest
przynajmniej jeden test. Zatem cały kod został wykonany w
procesie testowania.



Testowanie regresyjne



Zdefiniowane testy są wiele razy wykonywane w celu sprawdzenia,
że nowy przyrost nie doprowadził do błędów w dotychczasowej
wersji oprogramowania.



Łatwość lokalizowania błędów



Jeśli nowe testy nie zakończyły się powodzeniem, (a stare tak)
wiemy, że błąd wystąpił w aktualnym przyroście.



Dokumentacja systemu



Zbiór testów można traktować jako rodzaj dokumentacji systemu.

Testowanie regresyjne



Testowanie regresyjne pozwala stwierdzić, że
nowe zmiany nie wprowadziły błędów we
wcześniej napisanym kodzie.



Przy testowaniu ręcznym testowanie regresyjne
jest uciążliwe. W przypadku testowania
automatycznego nie ma problemu. Każda zmiana
kodu powoduje wykonanie wszystkich testów.



Wszystkie testy muszą wykonać się pozytywnie
zanim oprogramowanie będzie dalej rozszerzane.

Testowanie odbiorcze



Testowanie odbiorcze polega na ostatecznym
przetestowaniu systemu przed ostatecznym oddaniem
go do eksploatacji.



Na ogół produkt programistyczny oddawany jest
klientowi, który produkt zamówił. Czasami jednak, w
przypadku kiedy nasze oprogramowanie jest częścią
wielkiego systemu, odbiorcą być inny zespół wytwórczy.



W przypadku oprogramowania otwartego odbiorcą jest
na ogół kierownictwo firmy wytwórczej, które
przygotowuje produkt do sprzedaży na wolnym rynku.

Testowanie odbiorcze



Podstawowym celem testowania odbiorczego jest
przekonanie wytwórcy, że zbudowany produkt
nadaje się do eksploatacji.



Testowanie odbiorcze ma zatem pokazać, że system
realizuje swoją funkcjonalność, zachowuje się w
spodziewany sposób oraz spełnia wymogi niezawodności.



Testowanie odbiorcze jest realizowane przy użyciu
modelu czarnej skrzynki, czyli testy przygotowuje
się na podstawie specyfikacji testowanego
systemu.

Testowanie odbiorcze i
testowanie integracyjne



Testowanie odbiorcze jest podobne do
testowania integracyjnego.



Istotne różnice:



Za testowanie odbiorcze powinien odpowiadać
zewnętrzny zespół, który nie tworzył testowanego
oprogramowania.



Testowanie integracyjne powinno koncentrować się
na znajdowaniu błędów. Celem testowania
odbiorczego jest wykazanie, że system dziła zgodnie
ze swoją specyfikacją i nadaje się do eksploatacji.

Testowanie odbiorcze
sterowane wymaganiami



Testowanie sterowane wymaganiami polega na
wykonaniu testu dla każdego wymagania
związanego z testowanym oprogramowaniem.



Celem tego testowania jest wykazanie, że
system spełnia wszystkie wymagania.



System wspomagający kliniki:



Jeśli pacjent ma alergię na dane lekarstwo,
przepisanie go powinno skutkować odpowiednim
komunikatem.



Jeśli lekarz zignoruje ostrzeżenie, musi podać
uzasadnienie tego kroku.

Przykłady testów
wymaganiowych



Stwórz kartę pacjenta, o którym nie wiadomo, że ma alergię.
Przepisz lekarstwo, które może powodować alergię. Nie
powinien pojawić się komunikat o alergii.



Stwórz kartę pacjenta, o którym wiadomo, że ma alergię.
Przepisz lekarstwo, na które pacjent jest uczulony. Sprawdź, że
pojawi się komunikat.



Stwórz kartę pacjenta uczulonego na dwa leki. Sprawdź, że
przepisanie każdego z nich prowadzi do odpowiedniego
komunikatu.



Jak poprzednio, ale zapisz oba leki jednocześnie. Powinny
pojawić się dwa komunikaty.



Stwórz kartę pacjenta i przepisz lek na który jest uczulony.
Zignoruj ostrzeżenie. Sprawdź, że system zażąda napisania
uzasadnienia tego kroku.

Testowanie na podstawie
scenariusza



Jest to rodzaj testowania odbiorczego. Polega
na zdefiniowaniu scenariuszy opisujących
użycie systemu i przygotowania testów dla
każdego z tych scenariuszy.



Każdy scenariusz powinien opisywać konkretne
użycie systemu przez konkretnego
użytkownika.



Jeśli scenariusze były używane w procesie
definiowania wymagań, mogą być użyte w
procesie testowania.

Scenariusz (sieć klinik)



Anna jest pielęgniarką pracującą w klinice dla pacjentów z
problemami psychicznymi. Jednym z jej obowiązków jest
odwiedzanie pacjentów w domu, aby sprawdzić skuteczność
terapii oraz czy zapisane lekarstwa nie powodują u pacjenta
skutków ubocznych.



W dniu wizyt domowych Anna loguje się do systemu i
drukuje plan wizyt na ten dzień. W swoim laptopie
umieszcza historie chorób odwiedzanych pacjentów.
Ponieważ informacje te są poufne, muszą zostać
zaszyfrowane. W tym celu Anna musi podać swój klucz
szyfrujący.

Scenariusz (sieć klinik)



Jednym z pacjentów odwiedzanych przez Annę jest Jan, który
cierpi na depresję. Jan narzeka, że lekarstwo, które bierze
powoduje trudności ze snem. Anna sprawdza informację o
Janie na swoim laptopie. Aby ją odszyfrować musi podać swój
klucz szyfrujący. Okazuje się, że lekarstwo, które bierze Jan
może mieć efekt uboczny powodujący bezsenność. Zapisuje
ten fakt w karcie chorobowej Jana i sugeruje wizytę w klinice,
aby zmienić lekarstwo. Jan się zgadza i Anna zapisuje w jego
karcie, aby umówić termin wizyty z lekarzem. System szyfruje
kartę chorobową Jana.



Po zakończeniu wizyt Anna wraca do kliniki i umieszcza
zmodyfikowane karty chorób odwiedzanych pacjentów w
ogólnej bazie danych. System generuje listę pacjentów, dla
których należy zamówić wizyty w klinice.

Funkcjonalności wynikające
ze scenariusza



Autoryzacja na podstawie logowania do systemu.



Pobieranie z systemu do laptopa i wysyłanie z

lptopa do systemu informacji o pacjentach.



Szyfrowanie i deszyfrowanie informacji o

pacjentach.



Kalendarz wizyt domowych.



Obsługa informacji o pacjentach na laptopie.



Obsługa bazy danych zawierającej informacje o

efektach ubocznych leków.



Obsługa telefonicznego przypominania o

wizytach w klinice.

Testy wydajnościowe



Częścią testowania odbiorczego może być
testowanie wydajnościowe.



Testy wydajnościowe powinny symulować profil
używania systemu.



Testowanie wydajnościowe polega na serii
testów, z których kolejne coraz bardziej obciążają
system. Sprawdza się przy jakim obciążeniu
zachowanie systemu staje się nieakceptowalne.



Testowanie przewyższające znacznie obciążenie
systemu nazywa się testowaniem stresowym.

Testowanie produkcyjne



Testowanie produkcyjne polega na testowaniu
systemu w jego środowisku produkcyjnym na
rzeczywistych danych.



Testowanie produkcyjne jest kluczowe nawet jeśli
testowanie wytwórcze i odbiorcze zostały bardzo
solidnie przeprowadzone.



Wynika to z faktu, że praca systemu w rzeczywistym
środowisku pozwala właściwie ocenić jego niezawodność,
wydajność, odporność na błędy, czy łatwość użycia. Tych
własności nie da się dobrze ocenić w środowisku
testowym.

Rodzaje testowanie
produkcyjnego



Testowanie alfa



Użytkownicy oprogramowania razem z zespołem
wytwórczym testuję system na terenie firmy wytwórczej.



Testowanie beta



Wstępne wydanie systemu udostępnione zostaje
użytkownikom, od których oczekuje się opinii na temat
systemu.



Testowanie akceptacyjne



Testowanie przeprowadzane przez przedstawicieli klienta,
którego celem jest podjęcie decyzji, czy zaakceptować
system.

Proces testowania
akceptacyjnego

Zdefiniuj
kryteria
akceptacji

Zaplanuj

testy

akceptacyjn

e

Zdefiniuj

testy

akceptacyjn

e

Wykonaj

testy

akceptacyjn

e

Negocjuj

wyniki

testu

Akceptuj

lub

odrzuć

Kryteria

testu

Plan

testu

Test

Wyniki

testu

Raport

z testu

Etapy testowania
akceptacyjnego



Zdefiniuj kryteria akceptacji.



Kryteria akceptacji powinny być zdefiniowane jak
najwcześniej. Idealnie, jeśli są częścią kontraktu. W
praktyce jest to trudne, ponieważ szczegółowe wymagania
mogą jeszcze nie być ustalone i ponadto mogą się zmienić
w trakcie budowy systemu.



Zaplanuj testy akceptacyjne



Należy przede wszystkim zaplanować harmonogram testów
i przeznaczony na nie budżet. Plan powinien również
określić wymagane pokrycie wymagań przez testy oraz
kolejność w jakiej wymagania są testowane.

Etapy testowania
akceptacyjnego



Zdefiniuj testy akceptacyjne



Testy akceptacyjne definiuje się na podstawie
kryteriów akceptacji. Testy powinny obejmować
zarówno wymagania funkcjonalne, jak i
niefunkcjonalne. Idealnie jeśli testy pokrywają
wszystkie wymagania, chociaż w praktyce może to
być bardzo trudne.



Wykonaj testy akceptacyjne



Wykonywane są wcześniej zdefiniowane testy. Jeśli
tylko możliwe, testy te powinny być wykonane w
rzeczywistym środowisku na rzeczywistych danych.

Etapy testowania
akceptacyjnego



Negocjuj wyniki testu



W praktyce test akceptacyjny wykaże pewne usterki
systemu. W takiej systuacji klient i wytwórca muszą
negocjować, czy mimo to system można
zaakceptować.



Akceptuj/odrzuć system



Klient podejmuje ostateczną decyzję, czy system jest
akceptowalny. Jeśli nie, system musi zostać
poprawiony.

Testy akceptacyjne w
wytwórstwie zwinnym



W programowaniu zwinnym przedstawiciel klienta
członkiem zespołu wytwórczego i odpowiada za
podejmowanie decyzji związanych z
akceptowalnością produktu.



Dlatego w programowaniu zwinnym nie ma
oddzielnego testowania akceptującego.



Głównym problemem związanym z testowaniem w
wytwórstwie zwinnym jest reprezentatywność
przedstawiciela klienta, jeśli produktu jest
faktycznie tworzony dla kilku klientów.

Podsumowanie



Testowanie pomaga wykryć błędy. Nigdy nie

gwarantuje, że błędów nie ma.



Testowanie wytwórcze realizuje zespół budujący

system. Inny zespół powinien odpowiadać za

testowanie odbiorcze, czyli testowanie całego

oprogramowania przed oddaniem go do eksploatacji.



Testowanie wytwórcze zawiera testowanie jednostek,

gdzie testuje się niewielkie jednostki programowe,

testowanie komponentów, gdzie testuje się kilka

(kilkanaście) powiązanych jednostek, oraz testowanie

systemu, gdzie testuje się częściowy lub cały system.

Podsumowanie



Ważną rolę w testowaniu odgrywają reguły

tworzenia przypadków testowych oparte na

doświadczeniu.



Jeśli możliwe, należy tworzyć testy automatyczne.

Mogą być one efektywnie powtarzane po

zdefiniowaniu kolejnego przyrostu.



Wytwórstwo sterowane testami polega na

opracowaniu testów przed projektem i

implementacją.



Testowanie akceptacyjne jest to testowanie

wykonywane przez odbiorcę oprogramowania w

celu podjęcia ostatecznej decyzji o jego akceptacji.