Inżynieria
oprogramowania
Część 6: Testowanie
oprogramowania
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.