Dokumentacja i systemy jako±ci

Standardy testowania oprogramowania

Iwona Kocha«ska

KSEM WETI PG

January 15, 2016

Testowanie oprogramowania

I Testowanie - jeden z procesów zapewnienia jako±ci oprogramowania

I Testowanie ma na celu:

I werykacj¦ oprogramowania (czy wytwarzane oprogramowanie jest

zgodne ze specykacj¡?)
I walidacj¦ oprogramowania (czy wytwarzane oprogramowanie jest
zgodne z oczekiwaniami u»ytkownika?)

I Mo»e by¢ wdro»one w dowolnym momencie wytwarzania

oprogramowania (w zale»no±ci od wybranej metody).

I W podej±ciu klasycznym:
I po denicji wymaga«
I po zaimplementowaniu wszystkich zdeniowanych funkcjonalno±ci.
I Agile - du»o testów jednostkowych wykonywanych przez czªonków
zespoªu programistycznego, zanim oprogramowanie tra do
wªa±ciwego zespoªu testerów.
Testowanie oprogramowania

I Bª¡d (error) - niepoprawna konstrukcja w programie, która mo»e

doprowadzi¢ do niewªa±ciwego dziaªania tego programu.

I Bª¦dne wykonanie (failure) - niepoprawne dziaªanie systemu w

trakcie jego pracy.

I To samo bª¦dne wykonanie mo»e by¢ spowodowane ró»nymi

bª¦dami!

I Testowania umo»liwia wykrycie bª¦dów we wczesnych stadiach

rozwoju oprogramowania, co pozwala zmniejszy¢ koszty usuwania
tego bª¦du.

I Warto testowa¢ na ka»dym etapie tworzenia oprogramowania.

I estowa¢ nale»y jak najwcze±niej, poniewa» im pó¹niej wykryty

zostanie bª¡d tym wi¦kszy jest koszt jego usuni¦cia.
Rodzaje testów oprogramowania

I Testy funkcjonalne (testy czarnej skrzynki) - czy program

realizuje zaªo»on¡ funkcjonalno±¢?

I Osoba testuj¡ca nie ma dost¦pu do informacji na temat budowy

programu, który testuje.
I Wykonuj¡c testy nie opiera danych testowych na budowie
wewn¦trznej programu, lecz na zaªo»eniach funkcjonalnych, jakie
powinien speªnia¢ program zgodnie z dokumentacj¡

I Testy strukturalne (testy biaªej skrzynki)- analiza kodu

¹ródªowego oprogramowania.
Rodzaje testów oprogramowania

Testy manualne - testy wykonywane r¦cznie przez testera, który

przechodzi przez interfejs u»ytkownika zgodnie z okre±lon¡ sekwencj¡
kroków

I testy integracyjne pozwalaj¡ sprawdzi¢ jak wspóªpracuj¡ ze sob¡

ró»ne komponenty oprogramowania.

I testy systemowe dotycz¡ dziaªania aplikacji jako caªo±ci.

Testowanie wymaga« niefunkcjonalnych takich jak:

I szybko±¢ dziaªania,
I bezpiecze«stwo,
I niezawodno±¢, dobra wspóªpraca z innymi aplikacjami i sprz¦tem.

I testy regresyjne  sprawdzenie wpªywu nowych funkcjonalno±ci na

dziaªanie systemu
Rodzaje testów oprogramowania

Testy manualne - testy wykonywane r¦cznie przez testera, który

przechodzi przez interfejs u»ytkownika zgodnie z okre±lon¡ sekwencj¡
kroków

I testy akceptacyjne z udziaªem klienta  wykonywane w celu

sprawdzenia na ile oprogramowanie dziaªa zgodnie z wymaganiami
klienta

I testy dokumentacji - celem jest wykrycie niespójno±ci i

niezgodno±ci w dokumentacji analitycznej, technicznej oraz
dokumentacji u»ytkownika, sporz¡dzonej w ramach realizowanego
projektu informatycznego

I testy u»yteczno±ci - celem jest werykacja interfejsu u»ytkownika

w zakresie przyst¦pno±ci, wygody, szybko±ci oraz zgodno±ci z
oczekiwaniami przyszªych u»ytkowników.
Rodzaje testów oprogramowania

Testy automatyczne
I skutecznie przyspieszaj¡ proces tworzenia testów systemowych, ich
wykonywanie oraz analiz¦,

I pozwalaj¡ na wcze±niejsze wykrycie i wyeliminowanie bª¦dów w

aplikacjach.

I wykonywane s¡ w oparciu o wysokiej jako±ci oprogramowanie.

Standard IEEE 829-1998

IEEE 829-1998 (829 Standard for Software Test Documentation) -

podstawowy standard dla testowania oprogramowania. Okre±la format 8
dokumentów potrzebnych w ka»dej z faz testowania oprogramowania.
Jedna faza = 1 dokument wynikowy.

I Test Plan  dokument planowania zarz¡dzania projektem

I w jaki sposób b¦d¡ prowadzone testy?
I kto b¦dzie je przeprowadzaª?
I co b¦dzie testowane?
I jak dªugo potrwa caªy proces?
I jaki b¦dzie zakres testów?
I Test Design Specication  szczegóªy na temat:
I warunków testowania,
I oczekiwanych wyników,
I kryteriach przej±cia testu.
Standard IEEE 829-1998

I Test Procedure Specication  szczegóªy na temat

przeprowadzenia ka»dego testu (zaªo»enia i poszczególne kroki)

I Test Item Transmittal Report  raporty na temat czasu przej±cia

testowanych fragmentów oprogramowania mi¦dzy etapami.
I Test Log  zawiera informacje:
I które przypadki testowania zostaªy u»yte?,
I kto je u»yª?
I w jakim porz¡dku zostaªy u»yte?
I czy si¦ powiodªy?
I Test Incident Report  informacje o testach zako«czonych
niepowodzeniem:
I wyniki testu,
I dlaczego dany test si¦ nie powiódª?
Standard IEEE 829-1998

I Test Summary Report  raport zawieraj¡cy:

I wszystkie istotne informacje ujawnione podczas zako«czonych

testów,
I wyceny jako±ci procesów testowania,
I wyceny jako±ci oprogramowania poddanego testowi.
I statystyki uzyskane z Incident Report,
I ostateczna forma dokumentu jest wykorzystywana w celach
werykacji poprawno±ci testowanego systemu wzgl¦dem wymaga«
zdeniowanych przez zleceniodawców.

I Standard IEEE 829-1998 nie wymaga, aby wszystkie dokumenty

(fazy) byªy wykonane.
Normy ISO/IEC 29119

I Obejmuje kompletny proces testowy i pozwala¢ na wykorzystanie

nowoczesnych podej±¢ do testów.

I Cze±¢ 2: opis procesu testowego.

I Standardowy proces testowy, który nale»y dostosowa¢ do potrzeb

organizacji.
I Opisany na trzech warstwach: organizacyjnej, zarz¡dczej i
operacyjnej.
I Na ka»dym z tych poziomów s¡ zaproponowane odpowiednie zestawy
procesów.
Normy ISO/IEC 29119 - model warstwowy

I ORGANIZACYJNY PROCES TESTOWY  ma zazadanie

deniowa¢ proces budowania i utrzymania organizacyjnych
specykacji testowych (Polityka czy Strategia), procesów, procedur i
innych aktywów testowych.

I PROCES ZARZDZANIA TESTAMI  deniuje procesy

dotycz¡ce zarz¡dzania testami dla caªych projektów testowych,
poszczególnych faz czy typów testów (jak testy systemowe czy
wydajno±ciowe)

I OPERACYJNY PROCES TESTOWY  deniuje uniwersalne

procesy i procedury prowadzenia testów, które mog¡ by¢ stosowane
do:

I poszczególnych poziomów testów (np. sprawdzania wst¦pnego czy

akceptacyjnych)
I rodzajów testów (np. ci¡gªo±ci biznesowej czy migracji danych) w
ramach projektu testowego.

I Procesy te mo»na dostosowa¢ do dowolnego modelu wytwarzania

oprogramowania (równie» ju» istniej¡cego).
Normy ISO/IEC 29119 - model warstwowy
Normy ISO/IEC 29119 - sposób u»ycia procesów

I Procesy opisane w normie nie s¡ uªo»one liniowo, kaskadowo (co

zwykle stanowi du»y problem)

I Procesy s¡ wyzwalane zdarzeniami

I Jednocze±nie mo»e by¢ u»ywana nadrz¦dna i podrz¦dna instancja

procesu.

I Przykªad: proces Monitorowania i Kontroli mo»e jednocze±nie

dziaªa¢ dla
I caªego Programu (zestawu Projektów) - odpowiedzialny: Kierownik
Testów Programu
I instancja procesu dla aktualnie realizowanego Projektu -
odpowiedzialny: Lider Testów Projektu.
Normy ISO/IEC 29119 - sposób u»ycia procesów

I Kolejne wywoªania procesu mog¡ tworzy¢ bardziej szczegóªowe

dokumenty lub je aktualizowa¢.

I Przykªad: proces Planowania Testów

I tworzy Gªówny Plan Testów (dla caªego Programu)
I w ramach kolejnej iteracji  tworzy proces Planów Testów
Projektu/Rodzaju (np. Planu Testów Regresji).
I Procesy mog¡ by¢ wywoªywane rekurencyjnie.

I Ten sam proces mo»e by¢ woªany wielokrotnie

I Przykªad: proces Wykonania Testów, który jest wywoªywany

iteracyjne dla ka»dego Scenariusza i Przypadku Testowego

I Przy wykorzystaniu czynno±ci opisanych w procesach zakªada si¦

mo»liwo±¢ nawrotów do wcze±niejszych czynno±ci, co nie jest
dodatkowo oznaczane na diagramach.
Normy ISO/IEC 29119 - metoda piramidek

I Wdra»aj¡c metodyk¦ testów opart¡ o norm¦ trzeba dopasowa¢ si¦

do istniej¡cych w organizacji procesów, które cz¦sto maj¡ charakter
kaskadowy, a norma w »aden sposób nie podpowiada jak to wykona¢.

I Metoda piramidek

I pokazuje model warstwowy w postaci ikony piramidki.

I na ikonie tej zaznacza si¦, które procesy mog¡ by¢ wywoªane na

danym etapie kaskadowego modelu wytwarzania oprogramowania.

I Przykªadowo ikona:

oznacza, »e na danym etapie mog¡ by¢ u»yte procesy:

I Planowanie Testów
I Monitorowanie i Kontrola Testów
I Projektowanie i Implementacja Testów.
Normy ISO/IEC 29119 - metoda piramidek

Przykªadowe mapowanie procesów z normy na model wdra»ania oprogramowania.

PLAN  planowanie projektu
ANALIZA  zbieranie i analiza wymaga«
PROJEKT  projektowanie rozwi¡zania, architektura
BUDOWA  budowa rozwi¡zania w tym prototypowanie
TESTY  testy ró»nego rodzaju, w tym testy akceptacyjne
WDRO›ENIE  w tym testy gotowo±ci operacyjnej organizacji
PRZEGLD  ko«cz¡ce projekt podsumowania, w tym ocena jako±ci pracy testów.
Normy ISO/IEC 29119 - opis procesów

I BPMN (Business Process Model and Notation) - Notacja i Model

Procesu biznesowego; standardowa notacja dla modeli procesów

I Norma ISO/IEC 29119 dostarcza uproszczone diagramy procesów,

które nale»y dostosowa¢ do danej organizacji.

I Procesy równie» zostaªy zdeniowane opisowo w dokumentach

tekstowych.
Normy ISO/IEC 29119 - opis procesów

Diagram Procesu Planowania Testów z normy

Normy ISO/IEC 29119 - opis procesów

Diagram Procesu Planowania Testów z implementacji metodyki u klienta

(wersja uproszczona)
Logi diagnostyczne

I Log diagnostyczny - plik, do którego w okre±lonych stanach

dziaªania systemu dokonuje si¦ wpisu
I Zwykle:
I logi diagnostyczne sªu»¡ deweloperom tworz¡cym kod
I programi±ci mog¡ reprodukowa¢ znaleziony bª¡d we wªasnym
±rodowisku.
I Jednak czasem:
I testowanie realizowane jest przez oddzielny dziaª przy u»yciu
wyspecjalizowanego sprz¦tu,
I nie jest mo»liwe wielokrotne powtarzanie (przez programistów)
niezaliczonego testu z u»yciem debuggera,
I poszukuj¡c bª¦du deweloperzy mog¡ bazowa¢ jedynie na logach
zebranych przez testera.
I Problem logowania w zªo»onych systemach
I testowanie poszczególnych moduªów mo»na przeprowadza¢ zwykle
przy u»yciu
I symulatorów
I odpowiednio przygotowanych ±rodowisk testowych
I integracja i testowanie akceptacyjne mo»e wymaga¢:
I specjalistycznych laboratoriów
I s¡ mo»liwe jedynie w systemie docelowym znajduj¡cym si¦ ju» u
Logi diagnostyczne

Zªo»ony system telekomunikacyjny

I wytwórca oprogramowania nie jest w stanie zbudowa¢ ±rodowiska
testowego o tak du-»ej zªo»ono±ci jak sie¢ kliencka.

I tworzy si¦ odpowiednio wyspecjalizowane sieci testowe

I model sieci rzeczywistej

I wysokie koszty budowy - jedno ±rodowisko w miar¦ mo»liwo±ci
wykorzystywane jest w wielu ró»nych projektach
I wymaga wykwalikowanego personelu
I testy wykonywane s¡ przez osobne dziaªy w rmie, cz¦sto poªo»one
w odlegªej geogracznie lokalizacji.
Logi diagnostyczne

I Zdarza si¦ te», i» pomimo posiadania przez rm¦ sieci testowej nie
ma mo»liwo±ci symulowania odpowiednio dobrze:

I nieprzewidywalnych zale»no±ci czasowych,

I obci¡»enia,
I du»ych waha« liczby u»ytkowników,
I zmienno±ci warunków radiowych,
I awarii sprz¦tu,

I Cz¦±¢ testów wykonywana dopiero w fazie wdro»enia u klienta

ko«cowego.

I w przypadku znalezienia bª¦du programi±ci nie maj¡ mo»liwo±ci jego

reprodukcji w dost¦pnym dla nich ±rodowisku i musz¡ w peªni
polega¢ na raporcie dostarczonym przez testerów b¡d¹ wdra»aj¡cych
system in»ynierów wsparcia technicznego.
Logi diagnostyczne

Po co testerom logi?

I pozwalaj¡ na identykacj¦ komponentu, w którym wyst¡piª bª¡d,

I uªatwiaj¡ zrozumienie jak dziaªa testowany system i jakie wyst¦puj¡

w nim zale»no±ci czasowe,

I uªatwiaj¡ napisanie skryptów automatycznych do wykrywania

zdarze« w systemie,

I s¡ ±wietnym narz¦dziem do wskazania programistom, »e zaistniaªa

sytuacja jest rzeczywistym bª¦dem a nie problemem ze ±rodowiskiem
testowym
Logi diagnostyczne

I W zªo»onych systemach ka»dy z komponentów oprogramowania

posiada wªasny log

I wymusza to na osobie analizuj¡cej takie logi konieczno±¢ ich

synchronizacji.
I ka»dy z wpisów musi posiada¢ precyzyjnie okre±lony czas utworzenia.
I w zale»no±ci od rodzaju systemu wymagania dotycz¡ce dokªadno±ci
to mili- czy mikrosekundy, albo wr¦cz pojedyncze takty procesora.
Logi diagnostyczne

Dobre praktyki dotycz¡ce systemu logowania:

I ka»dy wpis powinien zawiera¢ dat¦ i dokªadn¡ godzin¦

wygenerowania oraz nazw¦ komponentu ¹ródªowego,

I warto ka»demu wpisowi nada¢ poziom istotno±ci (czy jest to wpis

diagnostyczny, informacyjny czy te» zgªoszenie bª¦du),

I nie nale»y zmienia¢ raz ustalonego formatu wpisu w logach. Mo»e to

spowodowa¢ bª¦dne werdykty w testach, które bazuj¡ na tych
wpisach,

I nale»y uwa»a¢, aby nie ujawnia¢ w logach zbyt wielu informacji na

temat architektury systemu b¡d¹ sposobu dziaªania algorytmów.
Logi diagnostyczne - rejestr zdarze«

Rejestr zdarze«
I Najcz¦±ciej stosowanym logiem, a w wi¦kszo±ci rozwi¡za« tak»e
jedynym zaimplementowanym sposobem logowania.
I Zwykle - chronologiczny zapis charakterystycznych momentów w
systemie, takich jak:
I podª¡czenie si¦ nowego u»ytkownika do serwisu,
I uruchomienie jakiej± procedury,
I zmiana parametrów konguracyjnych,
I przeprowadzenie testu wewn¦trznego
I uruchomienie procedury obsªugi bª¦du.

I Najcz¦±ciej w postaci plików tekstowych.

I Dane:
I dokªadny czasu wygenerowania
I nazwa komponentu raportuj¡cego
I poziom istotno±ci (przykªadowo: debug, info, warning lub
error).

I Do dziaªa« rutynowych nale»y zwykle sprawdzenie po ka»dym te±cie

(nawet zaliczonym), czy w rejestrze zdarze« nie zostaª
zaraportowany bª¡d.
Logi diagnostyczne - rejestr zdarze«
Logi diagnostyczne - rejestr zdarze«
Logi diagnostyczne - zrzuty pami¦ci

Zrzuty pami¦ci
I Gdy informacja zawarta w rejestrze zdarze« jest niewystarczaj¡ca

I Zrzuty pami¦ci wykonywane tu» po wyst¡pieniu defektu

I Automatyczne generowanie zrzutu pami¦ci do pliku w pami¦ci ash -

na przykªad w momencie uruchomienia pro cedury obsªugi
krytycznego wyj¡tku.

I Zwykle uzyskane w ten sposób dane nie s¡ zrozumiaªe dla testera;

wymagaj¡ znajomo±ci:

I kodu programu,
I znaczenia wszystkich zmiennych
I ich odczyt wymaga posiadania mapy pami¦ci, która przewa»nie
zmienia si¦ wraz z ka»d¡ wersj¡ kodu.

I Programista potra je zinterpretowa¢

Logi diagnostyczne - zrzuty diagnostyczny caªego systemu

Zrzut diagnostyczny caªego systemu

I Umo»liwia klientowi lub testerowi samodzielnego wygenerowanie
raportu do celów diagnostycznych.

I Raport taki mo»e zawiera¢:

I wszystkie pliki konguracyjne,

I zrzuty pami¦ci kluczowych komponentów
I ostatnie tysi¡c wpisów dziennika zdarze«.

I Ka»dy z komponentów tworzonego systemu powinien posiada¢ bufor

cykliczny o okre±lonej wielko±ci przeznaczony na logi, zapis ostatnich
warto±ci zmiennych itp.

I w momencie generowania raportu diagnostycznego zawarto±¢ tych

buforów jest zamra»ana i doª¡czana do raportu.
I spotyka si¦ tak»e rozwi¡zania, w których raport zawiera zrzuty stanu
wszystkich obiektów, co pozwala na pó¹niejsze zaªadowanie go do
systemu
Logi diagnostyczne - podgl¡d warto±ci zmiennych

Podgl¡d warto±ci zmiennych

I Gdy werykacja poprawno±ci dziaªania danego komponentu czy
systemu wymaga znajomo±ci wielu parametrów wej±ciowych,
po±rednich i wyj±ciowych, które to z kolei mog¡ zmienia¢ si¦ w
sposób ci¡gªy.

I Zapis przebiegu w czasie wszystkich parametrów oraz wyliczonych

wska¹ników.

I Odwzorowanie jedynie wybranych warto±ci, ale za to wraz z ich

przebiegiem w dziedzinie czasu.

I Analiza tego typu logów wymaga specjalistycznej wiedzy na temat

zaimplementowanego algorytmu.

I Tester mo»e odczyta¢ z przebiegu warto±ci zmiennych przyczyny

sytuacji awaryjnej ,
Logi diagnostyczne - rady dla programistów

I Staraj si¦ skonstruowa¢ system logowania w taki sposób, aby± nie

musiaª go rozbudowywa¢ na potrzeby znalezienia konkretnego bª¦du.

I Okre±l jasno, jakie logi s¡ potrzebne by prze±ledzi¢ dziaªanie

komponentu, który tworzysz. W razie potrzeby napisz instrukcj¦
zbierania nietypowych logów

I Staraj si¦ informowa¢ testera o wynikach analiz logów. Im lepiej

pozna architektur¦ systemu i metody analizy jego dziaªania, tym
bardziej efektywnie w przyszªo±ci b¦dzie mógª identykowa¢
komponent odpowiedzialny za bª¡d.
Logi diagnostyczne - rady dla testerów

I Do zgªoszenia bª¦du doª¡czaj wszystkie logi, jakie tylko jeste± w

stanie zebra¢. Uªatwia to poszukiwania pomyªki w kodzie i cz¦sto
pozwala unikn¡¢ niepotrzebnych retestów,

I Przed zaraportowaniem bª¦du warto zapyta¢ programistów, jakich

dokªadnie logów b¦d¡ potrzebowa¢ do poszukiwa« bª¦du w danym
komponencie,

I Je±li programi±ci analizuj¡c logi komunikuj¡ si¦ w formie pisemnej

(e-mail, forum), ±led¹ te dyskusje i pro± o wyja±nienia. Uªatwi to
Twoj¡ prac¦, gdy napotkasz podobny bª¡d w przyszªo±ci,

I Dokonuj¡c wst¦pnej analizy logów staraj si¦ doj±¢ do przyczyny

wyst¡pienia tego bª¦du.

I Przejrzyj wpisy poprzedzaj¡ce usterk¦ i zwerykuj widoczne

parametry systemu.
I To, i» jaki± komponent raportuje bª¡d nie jest jednoznaczne z tym,
»e zawiera usterk¦ w swoim kodzie - system mo»e dziaªa¢ w
warunkach, dla których nie jest przeznaczony.
I Bª¡d w kodzie: parametry wej±ciowe s¡ poprawne a komponent
zachowuje si¦ w sposób niezgodny ze specykacj¡.
Literatura

https://www.cs.odu.edu/~zeil/cs333/latest/Public/bbtesting/IEEE%20829-
2008.pdf
http://www.inectra.com/Partners/Articles/
SoftwareDeveloperJournal_SpiraTeamALM_Softlab_PL.pdf