Dokumentacja i systemy jako±ciStandardy 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 wery�kacj¦ oprogramowania (czy wytwarzane oprogramowanie jestzgodne ze specy�kacj¡?)

I walidacj¦ oprogramowania (czy wytwarzane oprogramowanie jestzgodne z oczekiwaniami u»ytkownika?)

I Mo»e by¢ wdro»one w dowolnym momencie wytwarzaniaoprogramowania (w zale»no±ci od wybranej metody).

I W podej±ciu klasycznym:

I po de�nicji wymaga«I po zaimplementowaniu wszystkich zde�niowanych funkcjonalno±ci.

I Agile - du»o testów jednostkowych wykonywanych przez czªonkówzespoªu programistycznego, zanim oprogramowanie tra� dowªa±ciwego zespoªu testerów.

Testowanie oprogramowania

I Bª¡d (error) - niepoprawna konstrukcja w programie, która mo»edoprowadzi¢ do niewªa±ciwego dziaªania tego programu.

I Bª¦dne wykonanie (failure) - niepoprawne dziaªanie systemu wtrakcie jego pracy.

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

I Testowania umo»liwia wykrycie bª¦dów we wczesnych stadiachrozwoju oprogramowania, co pozwala zmniejszy¢ koszty usuwaniatego bª¦du.

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

I estowa¢ nale»y jak najwcze±niej, poniewa» im pó¹niej wykrytyzostanie bª¡d tym wi¦kszy jest koszt jego usuni¦cia.

Rodzaje testów oprogramowania

I Testy funkcjonalne (testy czarnej skrzynki) - czy programrealizuje zaªo»on¡ funkcjonalno±¢?

I Osoba testuj¡ca nie ma dost¦pu do informacji na temat budowyprogramu, który testuje.

I Wykonuj¡c testy nie opiera danych testowych na budowiewewn¦trznej programu, lecz na zaªo»eniach funkcjonalnych, jakiepowinien 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óryprzechodzi 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 nadziaªanie systemu

Rodzaje testów oprogramowania

Testy manualne - testy wykonywane r¦cznie przez testera, któryprzechodzi przez interfejs u»ytkownika zgodnie z okre±lon¡ sekwencj¡kroków

I testy akceptacyjne z udziaªem klienta � wykonywane w celusprawdzenia na ile oprogramowanie dziaªa zgodnie z wymaganiamiklienta

I testy dokumentacji - celem jest wykrycie niespójno±ci iniezgodno±ci w dokumentacji analitycznej, technicznej orazdokumentacji u»ytkownika, sporz¡dzonej w ramach realizowanegoprojektu informatycznego

I testy u»yteczno±ci - celem jest wery�kacja interfejsu u»ytkownikaw zakresie przyst¦pno±ci, wygody, szybko±ci oraz zgodno±ci zoczekiwaniami przyszªych u»ytkowników.

Rodzaje testów oprogramowania

Testy automatyczne

I skutecznie przyspieszaj¡ proces tworzenia testów systemowych, ichwykonywanie oraz analiz¦,

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

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 8dokumentó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 Speci�cation � szczegóªy na temat:

I warunków testowania,

I oczekiwanych wyników,I kryteriach przej±cia testu.

Standard IEEE 829-1998

I Test Procedure Speci�cation � szczegóªy na tematprzeprowadzenia ka»dego testu (zaªo»enia i poszczególne kroki)

I Test Item Transmittal Report � raporty na temat czasu przej±ciatestowanych 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«czonychniepowodzeniem:

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«czonychtestó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 celachwery�kacji poprawno±ci testowanego systemu wzgl¦dem wymaga«zde�niowanych 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 wykorzystanienowoczesnych podej±¢ do testów.

I Cze±¢ 2: opis procesu testowego.

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

I Opisany na trzech warstwach: organizacyjnej, zarz¡dczej ioperacyjnej.

I Na ka»dym z tych poziomów s¡ zaproponowane odpowiednie zestawyprocesów.

Normy ISO/IEC 29119 - model warstwowy

I ORGANIZACYJNY PROCES TESTOWY � ma zazadaniede�niowa¢ proces budowania i utrzymania organizacyjnychspecy�kacji testowych (Polityka czy Strategia), procesów, procedur iinnych aktywów testowych.

I PROCES ZARZ�DZANIA TESTAMI � de�niuje procesydotycz¡ce zarz¡dzania testami dla caªych projektów testowych,poszczególnych faz czy typów testów (jak testy systemowe czywydajno±ciowe)

I OPERACYJNY PROCES TESTOWY � de�niuje uniwersalneprocesy i procedury prowadzenia testów, które mog¡ by¢ stosowanedo:

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

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

I Procesy te mo»na dostosowa¢ do dowolnego modelu wytwarzaniaoprogramowania (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 (cozwykle stanowi du»y problem)

I Procesy s¡ wyzwalane zdarzeniami

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

I Przykªad: proces Monitorowania i Kontroli mo»e jednocze±niedziaªa¢ dla

I caªego Programu (zestawu Projektów) - odpowiedzialny: KierownikTestó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óªowedokumenty 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ªywanyiteracyjne 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 jestdodatkowo 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¡ charakterkaskadowy, 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 nadanym etapie kaskadowego modelu wytwarzania oprogramowania.

I Przykªadowo ikona:

oznacza, »e na danym etapie mog¡ by¢ u»yte procesy:I Planowanie TestówI Monitorowanie i Kontrola TestówI 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 projektuANALIZA � zbieranie i analiza wymaga«PROJEKT � projektowanie rozwi¡zania, architekturaBUDOWA � budowa rozwi¡zania w tym prototypowanieTESTY � testy ró»nego rodzaju, w tym testy akceptacyjneWDRO�ENIE � w tym testy gotowo±ci operacyjnej organizacjiPRZEGL�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 ModelProcesu 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 zde�niowane opisowo w dokumentachtekstowych.

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 stanachdziaªania systemu dokonuje si¦ wpisu

I Zwykle:I logi diagnostyczne sªu»¡ deweloperom tworz¡cym kodI programi±ci mog¡ reprodukowa¢ znaleziony bª¡d we wªasnym±rodowisku.

I Jednak czasem:I testowanie realizowane jest przez oddzielny dziaª przy u»yciuwyspecjalizowanego 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 logachzebranych przez testera.

I Problem logowania w zªo»onych systemachI testowanie poszczególnych moduªów mo»na przeprowadza¢ zwykleprzy u»yciu

I symulatorówI odpowiednio przygotowanych ±rodowisk testowych

I integracja i testowanie akceptacyjne mo»e wymaga¢:I specjalistycznych laboratoriówI s¡ mo»liwe jedynie w systemie docelowym znajduj¡cym si¦ ju» u

klienta

Logi diagnostyczne

Zªo»ony system telekomunikacyjny

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

I tworzy si¦ odpowiednio wyspecjalizowane sieci testowe

I model sieci rzeczywistejI wysokie koszty budowy - jedno ±rodowisko w miar¦ mo»liwo±ciwykorzystywane jest w wielu ró»nych projektach

I wymaga wykwali�kowanego personeluI testy wykonywane s¡ przez osobne dziaªy w �rmie, cz¦sto poªo»onew odlegªej geogra�cznie lokalizacji.

Logi diagnostyczne

I Zdarza si¦ te», i» pomimo posiadania przez �rm¦ sieci testowej niema 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 klientako«cowego.

I w przypadku znalezienia bª¦du programi±ci nie maj¡ mo»liwo±ci jegoreprodukcji w dost¦pnym dla nich ±rodowisku i musz¡ w peªnipolega¢ na raporcie dostarczonym przez testerów b¡d¹ wdra»aj¡cychsystem in»ynierów wsparcia technicznego.

Logi diagnostyczne

Po co testerom logi?

I pozwalaj¡ na identy�kacj¦ 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 wykrywaniazdarze« w systemie,

I s¡ ±wietnym narz¦dziem do wskazania programistom, »e zaistniaªasytuacja jest rzeczywistym bª¦dem a nie problemem ze ±rodowiskiemtestowym

Logi diagnostyczne

I W zªo»onych systemach ka»dy z komponentów oprogramowaniaposiada wªasny log

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

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±cito 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 wpisdiagnostyczny, informacyjny czy te» zgªoszenie bª¦du),

I nie nale»y zmienia¢ raz ustalonego formatu wpisu w logach. Mo»e tospowodowa¢ bª¦dne werdykty w testach, które bazuj¡ na tychwpisach,

I nale»y uwa»a¢, aby nie ujawnia¢ w logach zbyt wielu informacji natemat 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»ejedynym zaimplementowanym sposobem logowania.

I Zwykle - chronologiczny zapis charakterystycznych momentów wsystemie, takich jak:

I podª¡czenie si¦ nowego u»ytkownika do serwisu,I uruchomienie jakiej± procedury,I zmiana parametrów kon�guracyjnych,I przeprowadzenie testu wewn¦trznegoI uruchomienie procedury obsªugi bª¦du.

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

I dokªadny czasu wygenerowaniaI nazwa komponentu raportuj¡cegoI 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ªugikrytycznego 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 zmiennychI ich odczyt wymaga posiadania mapy pami¦ci, która przewa»niezmienia 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 wygenerowanieraportu do celów diagnostycznych.

I Raport taki mo»e zawiera¢:

I wszystkie pliki kon�guracyjne,I zrzuty pami¦ci kluczowych komponentówI ostatnie tysi¡c wpisów dziennika zdarze«.

I Ka»dy z komponentów tworzonego systemu powinien posiada¢ buforcykliczny o okre±lonej wielko±ci przeznaczony na logi, zapis ostatnichwarto±ci zmiennych itp.

I w momencie generowania raportu diagnostycznego zawarto±¢ tychbuforów jest �zamra»ana� i doª¡czana do raportu.

I spotyka si¦ tak»e rozwi¡zania, w których raport zawiera zrzuty stanuwszystkich obiektów, co pozwala na pó¹niejsze �zaªadowanie� go dosystemu

Logi diagnostyczne - podgl¡d warto±ci zmiennych

Podgl¡d warto±ci zmiennych

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

I Zapis przebiegu w czasie wszystkich parametrów oraz wyliczonychwska¹ników.

I Odwzorowanie jedynie wybranych warto±ci, ale za to wraz z ichprzebiegiem w dziedzinie czasu.

I Analiza tego typu logów wymaga specjalistycznej wiedzy na tematzaimplementowanego 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± niemusiaª go rozbudowywa¢ na potrzeby znalezienia konkretnego bª¦du.

I Okre±l jasno, jakie logi s¡ potrzebne by prze±ledzi¢ dziaªaniekomponentu, który tworzysz. W razie potrzeby napisz instrukcj¦zbierania nietypowych logów

I Staraj si¦ informowa¢ testera o wynikach analiz logów. Im lepiejpozna architektur¦ systemu i metody analizy jego dziaªania, tymbardziej efektywnie w przyszªo±ci b¦dzie mógª identy�kowa¢komponent odpowiedzialny za bª¡d.

Logi diagnostyczne - rady dla testerów

I Do zgªoszenia bª¦du doª¡czaj wszystkie logi, jakie tylko jeste± wstanie zebra¢. Uªatwia to poszukiwania pomyªki w kodzie i cz¦stopozwala unikn¡¢ niepotrzebnych retestów,

I Przed zaraportowaniem bª¦du warto zapyta¢ programistów, jakichdokªadnie logów b¦d¡ potrzebowa¢ do poszukiwa« bª¦du w danymkomponencie,

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 toTwoj¡ prac¦, gdy napotkasz podobny bª¡d w przyszªo±ci,

I Dokonuj¡c wst¦pnej analizy logów staraj si¦ doj±¢ do przyczynywyst¡pienia tego bª¦du.

I Przejrzyj wpisy poprzedzaj¡ce usterk¦ i zwery�kuj widoczneparametry 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¢ wwarunkach, dla których nie jest przeznaczony.

I Bª¡d w kodzie: parametry wej±ciowe s¡ poprawne a komponentzachowuje si¦ w sposób niezgodny ze specy�kacj¡.

Literatura

https://www.cs.odu.edu/~zeil/cs333/latest/Public/bbtesting/IEEE%20829-2008.pdf

http://www.in�ectra.com/Partners/Articles/

SoftwareDeveloperJournal_SpiraTeamALM_Softlab_PL.pdf