Dokumentacja i systemy jako±ci Standardy testowania oprogramowania Iwona Kocha«ska KSEM WETI PG January 15, 2016
Testowanie oprogramowania Testowanie - jeden z procesów zapewnienia jako±ci oprogramowania Testowanie ma na celu: werykacj oprogramowania (czy wytwarzane oprogramowanie jest zgodne ze specykacj?) walidacj oprogramowania (czy wytwarzane oprogramowanie jest zgodne z oczekiwaniami u»ytkownika?) Mo»e by wdro»one w dowolnym momencie wytwarzania oprogramowania (w zale»no±ci od wybranej metody). W podej±ciu klasycznym: po denicji wymaga«po zaimplementowaniu wszystkich zdeniowanych funkcjonalno±ci. 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 Bª d (error) - niepoprawna konstrukcja w programie, która mo»e doprowadzi do niewªa±ciwego dziaªania tego programu. Bª dne wykonanie (failure) - niepoprawne dziaªanie systemu w trakcie jego pracy. To samo bª dne wykonanie mo»e by spowodowane ró»nymi bª dami! Testowania umo»liwia wykrycie bª dów we wczesnych stadiach rozwoju oprogramowania, co pozwala zmniejszy koszty usuwania tego bª du. Warto testowa na ka»dym etapie tworzenia oprogramowania. 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 Testy funkcjonalne (testy czarnej skrzynki) - czy program realizuje zaªo»on funkcjonalno±? Osoba testuj ca nie ma dost pu do informacji na temat budowy programu, który testuje. 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 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 testy integracyjne pozwalaj sprawdzi jak wspóªpracuj ze sob ró»ne komponenty oprogramowania. testy systemowe dotycz dziaªania aplikacji jako caªo±ci. Testowanie wymaga«niefunkcjonalnych takich jak: szybko± dziaªania, bezpiecze«stwo, niezawodno±, dobra wspóªpraca z innymi aplikacjami i sprz tem. 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 testy akceptacyjne z udziaªem klienta wykonywane w celu sprawdzenia na ile oprogramowanie dziaªa zgodnie z wymaganiami klienta 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 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 skutecznie przyspieszaj proces tworzenia testów systemowych, ich wykonywanie oraz analiz, pozwalaj na wcze±niejsze wykrycie i wyeliminowanie bª dów w aplikacjach. 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. Test Plan dokument planowania zarz dzania projektem w jaki sposób b d prowadzone testy? kto b dzie je przeprowadzaª? co b dzie testowane? jak dªugo potrwa caªy proces? jaki b dzie zakres testów? Test Design Specication szczegóªy na temat: warunków testowania, oczekiwanych wyników, kryteriach przej±cia testu.
Standard IEEE 829-1998 Test Procedure Specication szczegóªy na temat przeprowadzenia ka»dego testu (zaªo»enia i poszczególne kroki) Test Item Transmittal Report raporty na temat czasu przej±cia testowanych fragmentów oprogramowania mi dzy etapami. Test Log zawiera informacje: które przypadki testowania zostaªy u»yte?, kto je u»yª? w jakim porz dku zostaªy u»yte? czy si powiodªy? Test Incident Report informacje o testach zako«czonych niepowodzeniem: wyniki testu, dlaczego dany test si nie powiódª?
Standard IEEE 829-1998 Test Summary Report raport zawieraj cy: wszystkie istotne informacje ujawnione podczas zako«czonych testów, wyceny jako±ci procesów testowania, wyceny jako±ci oprogramowania poddanego testowi. statystyki uzyskane z Incident Report, ostateczna forma dokumentu jest wykorzystywana w celach werykacji poprawno±ci testowanego systemu wzgl dem wymaga«zdeniowanych przez zleceniodawców. Standard IEEE 829-1998 nie wymaga, aby wszystkie dokumenty (fazy) byªy wykonane.
Normy ISO/IEC 29119 Obejmuje kompletny proces testowy i pozwala na wykorzystanie nowoczesnych podej± do testów. Cze± 2: opis procesu testowego. Standardowy proces testowy, który nale»y dostosowa do potrzeb organizacji. Opisany na trzech warstwach: organizacyjnej, zarz dczej i operacyjnej. Na ka»dym z tych poziomów s zaproponowane odpowiednie zestawy procesów.
Normy ISO/IEC 29119 - model warstwowy ORGANIZACYJNY PROCES TESTOWY ma zazadanie deniowa proces budowania i utrzymania organizacyjnych specykacji testowych (Polityka czy Strategia), procesów, procedur i innych aktywów testowych. 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) OPERACYJNY PROCES TESTOWY deniuje uniwersalne procesy i procedury prowadzenia testów, które mog by stosowane do: poszczególnych poziomów testów (np. sprawdzania wst pnego czy akceptacyjnych) rodzajów testów (np. ci gªo±ci biznesowej czy migracji danych) w ramach projektu testowego. 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 Procesy opisane w normie nie s uªo»one liniowo, kaskadowo (co zwykle stanowi du»y problem) Procesy s wyzwalane zdarzeniami Jednocze±nie mo»e by u»ywana nadrz dna i podrz dna instancja procesu. Przykªad: proces Monitorowania i Kontroli mo»e jednocze±nie dziaªa dla caªego Programu (zestawu Projektów) - odpowiedzialny: Kierownik Testów Programu instancja procesu dla aktualnie realizowanego Projektu - odpowiedzialny: Lider Testów Projektu.
Normy ISO/IEC 29119 - sposób u»ycia procesów Kolejne wywoªania procesu mog tworzy bardziej szczegóªowe dokumenty lub je aktualizowa. Przykªad: proces Planowania Testów tworzy Gªówny Plan Testów (dla caªego Programu) w ramach kolejnej iteracji tworzy proces Planów Testów Projektu/Rodzaju (np. Planu Testów Regresji). Procesy mog by wywoªywane rekurencyjnie. Ten sam proces mo»e by woªany wielokrotnie Przykªad: proces Wykonania Testów, który jest wywoªywany iteracyjne dla ka»dego Scenariusza i Przypadku Testowego 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 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. Metoda piramidek pokazuje model warstwowy w postaci ikony piramidki. na ikonie tej zaznacza si, które procesy mog by wywoªane na danym etapie kaskadowego modelu wytwarzania oprogramowania. Przykªadowo ikona: oznacza,»e na danym etapie mog by u»yte procesy: Planowanie Testów Monitorowanie i Kontrola Testów 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 BPMN (Business Process Model and Notation) - Notacja i Model Procesu biznesowego; standardowa notacja dla modeli procesów Norma ISO/IEC 29119 dostarcza uproszczone diagramy procesów, które nale»y dostosowa do danej organizacji. 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 Log diagnostyczny - plik, do którego w okre±lonych stanach dziaªania systemu dokonuje si wpisu Zwykle: logi diagnostyczne sªu» deweloperom tworz cym kod programi±ci mog reprodukowa znaleziony bª d we wªasnym ±rodowisku. Jednak czasem: testowanie realizowane jest przez oddzielny dziaª przy u»yciu wyspecjalizowanego sprz tu, nie jest mo»liwe wielokrotne powtarzanie (przez programistów) niezaliczonego testu z u»yciem debuggera, poszukuj c bª du deweloperzy mog bazowa jedynie na logach zebranych przez testera. Problem logowania w zªo»onych systemach testowanie poszczególnych moduªów mo»na przeprowadza zwykle przy u»yciu symulatorów odpowiednio przygotowanych ±rodowisk testowych integracja i testowanie akceptacyjne mo»e wymaga : specjalistycznych laboratoriów s mo»liwe jedynie w systemie docelowym znajduj cym si ju» u
Logi diagnostyczne Zªo»ony system telekomunikacyjny wytwórca oprogramowania nie jest w stanie zbudowa ±rodowiska testowego o tak du-»ej zªo»ono±ci jak sie kliencka. tworzy si odpowiednio wyspecjalizowane sieci testowe model sieci rzeczywistej wysokie koszty budowy - jedno ±rodowisko w miar mo»liwo±ci wykorzystywane jest w wielu ró»nych projektach wymaga wykwalikowanego personelu testy wykonywane s przez osobne dziaªy w rmie, cz sto poªo»one w odlegªej geogracznie lokalizacji.
Logi diagnostyczne Zdarza si te», i» pomimo posiadania przez rm sieci testowej nie ma mo»liwo±ci symulowania odpowiednio dobrze: nieprzewidywalnych zale»no±ci czasowych, obci»enia, du»ych waha«liczby u»ytkowników, zmienno±ci warunków radiowych, awarii sprz tu, Cz ± testów wykonywana dopiero w fazie wdro»enia u klienta ko«cowego. 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? pozwalaj na identykacj komponentu, w którym wyst piª bª d, uªatwiaj zrozumienie jak dziaªa testowany system i jakie wyst puj w nim zale»no±ci czasowe, uªatwiaj napisanie skryptów automatycznych do wykrywania zdarze«w systemie, s ±wietnym narz dziem do wskazania programistom,»e zaistniaªa sytuacja jest rzeczywistym bª dem a nie problemem ze ±rodowiskiem testowym
Logi diagnostyczne W zªo»onych systemach ka»dy z komponentów oprogramowania posiada wªasny log wymusza to na osobie analizuj cej takie logi konieczno± ich synchronizacji. ka»dy z wpisów musi posiada precyzyjnie okre±lony czas utworzenia. 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: ka»dy wpis powinien zawiera dat i dokªadn godzin wygenerowania oraz nazw komponentu ¹ródªowego, warto ka»demu wpisowi nada poziom istotno±ci (czy jest to wpis diagnostyczny, informacyjny czy te» zgªoszenie bª du), 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, 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«najcz ±ciej stosowanym logiem, a w wi kszo±ci rozwi za«tak»e jedynym zaimplementowanym sposobem logowania. Zwykle - chronologiczny zapis charakterystycznych momentów w systemie, takich jak: podª czenie si nowego u»ytkownika do serwisu, uruchomienie jakiej± procedury, zmiana parametrów konguracyjnych, przeprowadzenie testu wewn trznego uruchomienie procedury obsªugi bª du. Najcz ±ciej w postaci plików tekstowych. Dane: dokªadny czasu wygenerowania nazwa komponentu raportuj cego poziom istotno±ci (przykªadowo: debug, info, warning lub error). 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 Gdy informacja zawarta w rejestrze zdarze«jest niewystarczaj ca Zrzuty pami ci wykonywane tu» po wyst pieniu defektu Automatyczne generowanie zrzutu pami ci do pliku w pami ci ash - na przykªad w momencie uruchomienia pro cedury obsªugi krytycznego wyj tku. Zwykle uzyskane w ten sposób dane nie s zrozumiaªe dla testera; wymagaj znajomo±ci: kodu programu, znaczenia wszystkich zmiennych ich odczyt wymaga posiadania mapy pami ci, która przewa»nie zmienia si wraz z ka»d wersj kodu. Programista potra je zinterpretowa
Logi diagnostyczne - zrzuty diagnostyczny caªego systemu Zrzut diagnostyczny caªego systemu Umo»liwia klientowi lub testerowi samodzielnego wygenerowanie raportu do celów diagnostycznych. Raport taki mo»e zawiera : wszystkie pliki konguracyjne, zrzuty pami ci kluczowych komponentów ostatnie tysi c wpisów dziennika zdarze«. 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. w momencie generowania raportu diagnostycznego zawarto± tych buforów jest zamra»ana i doª czana do raportu. 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 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. Zapis przebiegu w czasie wszystkich parametrów oraz wyliczonych wska¹ników. Odwzorowanie jedynie wybranych warto±ci, ale za to wraz z ich przebiegiem w dziedzinie czasu. Analiza tego typu logów wymaga specjalistycznej wiedzy na temat zaimplementowanego algorytmu. Tester mo»e odczyta z przebiegu warto±ci zmiennych przyczyny sytuacji awaryjnej,
Logi diagnostyczne - rady dla programistów Staraj si skonstruowa system logowania w taki sposób, aby± nie musiaª go rozbudowywa na potrzeby znalezienia konkretnego bª du. 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 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 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, Przed zaraportowaniem bª du warto zapyta programistów, jakich dokªadnie logów b d potrzebowa do poszukiwa«bª du w danym komponencie, 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, Dokonuj c wst pnej analizy logów staraj si doj± do przyczyny wyst pienia tego bª du. Przejrzyj wpisy poprzedzaj ce usterk i zwerykuj widoczne parametry systemu. 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. 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