Testowanie oprogramowania

  • View
    43

  • Download
    0

Embed Size (px)

DESCRIPTION

Testowanie oprogramowania. Marcin Jerzak Piotr Fisz. Testowanie oprogramowania. Jest to proces związany z wytwarzaniem oprogramowania. Celem testowania jest wykrywanie błędów oraz badanie niezawodności systemu. - PowerPoint PPT Presentation

Text of Testowanie oprogramowania

  • Testowanie oprogramowaniaMarcin Jerzak Piotr Fisz

  • Testowanie oprogramowaniaJest to proces zwizany z wytwarzaniem oprogramowania. Celem testowania jest wykrywanie bdw oraz badanie niezawodnoci systemu.

    Weryfikacja (verification) - testowanie zgodnoci systemu z wymaganiami zdefiniowanymi w fazie okrelenia wymaga.

    Atestowanie (validation) - ocena systemu lub komponentu podczas lub na kocu procesu jego rozwoju na zgodnoci z wyspecyfikowanymi wymaganiami. Atestowanie jest wic weryfikacj kocow.

  • Cele testowania:Oprogramowanie testujemy gwnie majc na uwadze wykrycie i pozbycie si bdw w systemie oraz ocena niezawodnoci oprogramowania.

  • BdyBd (failure, error) jest to niepoprawna konstrukcja znajdujca si w programie, ktra moe doprowadzi do niewaciwego dziaania.

    Bdne wykonanie (failure) - niepoprawne dziaanie systemu w trakcie jego pracy.

    Naley mie na uwadze, e te samo bdne wykonanie programu moe by spowodowane przez rne bdy pracy oprogramowania.

  • WeryfikacjaWeryfikacja ma na celu sprawdzenie czy produkt w danej fazie rozwoju spenia zaoenia powstae podczas startu danej fazy.

    Przy weryfikacji moemy wykorzysta: Przegldy, inspekcje, testowanie, sprawdzanie, audytowanie.

  • PrzegldyPrzegldem nazywamy spotkanie, w czasie ktrego produkt lub jego czci s prezentowane kierownictwu, uytkownikom, klientom lub innym osobom majcym kontakt z produktem w celu uzyskania opinii i wskazwek.

    Rozrniamy przegldu formalne i nieformalne.

  • PrzegldPrzegldy formalne mog mie posta: - przegldu technicznego (ocena zgodnoci postpu prac wzgldem planu). - przej (ocena dokumentw, modeli, projektw i kodu w celu znalezienia i naprawy bdw). - audytu (potwierdzenie zgodnoci z zaoeniami, dokumentami itp. Przez osoby z zewntrz firmy).

  • AudytJest to przegld i ocena jakoci oprogramowania, ktra zapewnia zgodno ze standardami i specyfikacjami oraz daje obraz o stanie caego projektu.

    Dla zapewnienia lepszych wynikw audyt powinien by wykonany przez osoby z zewntrz.

  • InspekcjeJest to technika polegajca na badaniu kodu przez osoby lub grup osb nie bdcych autorami programu w celu znalezienia bdw.

    rednia skuteczno wynosi 60%.

    Jest to technika rzadko stosowana poniewa wymagane s planowanie oraz kompetentni ludzie. Dodatkowym minusem jest utrudniona analiza kosztw i zyskw.

  • InspekcjeCechy inspekcji: - Sesje s zaplanowane i przygotowane - Bdy i problemy s notowane - wykonywane przez technikw dla technikw

    Korzyci inspekcji: - Wzrost produktywnoci od 30% do 100% - Skrcenie czasu projektu od 10% do 30% - Skrcenie kosztu i czasu wykonywania testw od 5 do 10 razy

  • Rodzaje testwWykrywanie bdw znajdowanie jak najwikszej iloci bdw

    Testy statystyczne wykrywanie najczciej statystycznie wystpujcych bdw oraz ocena niezawodnoci systemu

    Testy dynamiczne wykonywanie kawakw programu i porwnywanie wynikw z poprawnymi

    Testy statyczne analiza kodu

  • Fazy testowaniaTesty moduwTesty systemuTesty akceptacjiWydajno systemuInterfejs systemuWasnoci operacyjne systemuTesty zuycia zasobwZabezpieczenie systemuPrzenoszalno systemuNiezawodno programuOdtwarzalno oprogramowania

  • Fazy testowaniaBezpieczestwo oprogramowaniaKompletno i jako zaoonych funkcji systemuNie przekraczanie ograniczeModyfikowalno oprogramowaniaObcialno oprogramowaniaSkalowno systemuAkceptowalno systemuJako dokumentacji

  • Testowanie na zasadzie czarnej skrzynkiMetoda polega na testowaniu bez sprawdzania wntrza programu

    Powinno si testowa dla caego zakresu danych

    Dane powinno si podzieli na takie, ktre mog dawa podobne bdy

    Plusem jest moliwoci pokazania brakujcych funkcji

  • Testowanie na zasadzie biaej skrzynkiMetoda polega na testowaniu wewntrznej logiki po przez dobranie odpowiednich danych wejciowych, co umoliwia przetestowanie wszystkich cieek.

    Czsto jest wymagane przygotowanie danych testowych speniajcych nasze wymagania

    Minusem jest brak moliwoci pokazania brakujcych funkcji

  • Okrelenie niezawodnoci oprogramowaniaPrawdopodobiestwo bdnego wykonania podczas realizacji tranzakcji. Miar nazywamy czsto wystpienia bdnych tranzakcji.Czstotliwo wystpowania bdnych wykona.redni czas midzy bdami.Dostpno. Jest to prawdopodobiestwo dostpnoci systemu w danej chwili.

  • Oszacowanie niezawodnociMa duy wpyw na koszt konserwacji oprogramowania.Pozwala oszacowa koszt serwisu, liczb personelu, liczb zgosze bdw.Pozwala oceni i polepszy proces wytwarzania.

  • Wykrywanie bdwTesty funkcjonalne zakadaj znajomo wymaga wobec testowanej funkcji. System traktujemy jak czarn skrzynk, ktra realizuje funkcje w nieznany sposb.

    Testy strukturalne zakadaj znajomo sposobu implementacji testowanych funkcji

  • Testy funkcjonalneUniemoliwiaj przetestowanie rzeczywistego systemu ze wzgldu na liczb kombinacji danych wejciowych.

    Zakada si, e jeli dana funkcja dziaa dla kilku danych wejciowych poprawnie to i dla reszty te tak bdzie.

  • Testy strukturalneDane wejciowe dobiera si na podstawie analizy struktury programu realizujcego dan funkcj.

    Wyrniamy kryterium pokrycia wszystkich instrukcji, czyli dane wejciowe s tak dobrane by kada instrukcja wykonaa si co najmniej raz oraz kryterium pokrycia warunkowego czyli istnieje moliwo, e dla danych wejciowych nie bd spenione ich wymagania.

  • Co uywamy do testowania:Programy uruchamiajce (debuggers)

    Analizatory przykrycia kodu

    Programy porwnujce

  • Testy statyczneTesty statyczne polegaj na analizie kodu bez jego uruchamiania.

    Dowody poprawnoci praktycznie nie uywane

    Metody nieformalne jest to analiza kodu prze programistw. Pozwala znale bdy takie jak: niezainicjowanie zmiennych, przepenienie tabeli, nieprawidowe urzucie kursorw i wskanikw itp.

  • Testy systemuTestowanie wstpujce najpierw testujemy moduy niszego poziomu a potem wyszego.

    Testowanie zstpujce najpierw testujemy moduy wyszego poziomy a potem niszego.

  • Testy pod obcieniem i odpornocioweTesty obcieniowe umoliwiaj zbadanie zachowania, wydajnoci i niezawodnoci systemu podczas pracy pod penym lub nadmiernym obcieniem.

    Testy odpornociowe pokazuj jak zachowuje si system w przypadku np. zaniku prdu, wprowadzenie niepoprawnych danych itp.

  • Testy akceptacyjneTesty akceptacyjne polegaj na przekazaniu oprogramowania klientom docelowym w celu zatwierdzenia. Jeeli oprogramowanie jest realizowane na zamwienie system przekazywany jest do przetestowania przyszemu uytkownikowi po stronie zleceniodawcy. Takie testy s nazywane testami alfa. Dla oprogramowania sprzedawanego rynkowo przewidziane s testy polegajce na nieodpatnym przekazaniu pewnej liczby kopii systemu grupie uytkownikw. Testy te s nazywane testami beta.

  • Czynniki sukcesuNa czynniki sukcesu wpywa:Okrelenie fragmentw o szczeglnej niezawodnociWaciwa motywacja testerwPoprawa znalezionych bdwOszacowanie niezawodnoci i kosztw konserwacji.

  • Standardy w testowaniuPodstawowym standardem dla testowania oprogramowania jest IEEE 829 1998 (829 Standard for Software Test Documentation). Jest to standard okrelajcy form zbioru 8 dokumentw potrzebnych w kadej z faz testowania oprogramowania. W efekcie kadej z tych faz tworzony jest 1 dokument wynikowy. Standard ten okrela dokadnie format dokumentw, jednak nie wymaga aby wszystkie byy wykonane. Nie zawiera take informacji o tym co dokadnie maj zawiera.

  • Standardy w testowaniuTest Plan dokument planowania zarzdzania projektem, ktry skada si z informacji o tym, w jaki sposb bd prowadzone testy, kto bdzie je przeprowadza, co bdzie testowane, jak dugo potrwa cay proces oraz jaki bdzie zakres testw.Test Design Specification szczegy na temat warunkw testowania, oczekiwanych wynikw a take kryteriach przejcia testu.Test Case Specification specyfikuje dane testowe do uycia podczas wdraania warunkw testowania okrelonych w Test Design Specification.Test Procedure Specification zawiera szczegy na temat przeprowadzenia kadego testu wczajc w to zaoenia oraz poszczeglne kroki testw.Test Item Transmittal Report zawiera raporty na temat czasu przejcia testowanych fragmentw oprogramowania midzy etapami.Test Log zawiera informacje o tym, ktre przypadki testowania zostay uyte, kto je uy i w jakim porzdku oraz informacje o ich powodzeniu.Test Incident Report zawiera informacje o testach zakoczonych niepowodzeniem. Informacje o wynikach oraz dlaczego dany test nie powid si.Test Summary Report raport ten zawiera wszystkie istotne informacje ujawnione podczas zakoczonych testw oraz wyceny jakoci procesw testowania, jakoci oprogramowania poddanego testowi, a take statystyki uzyskane z Incident Report. Raport referuje rwnie do typw i czasu trwania wykonanych testw w celu usprawnienia wszelkich planw zwizanych z testami w przyszoci. Ostateczna forma dokumentu jest wykorzystywana w celach weryfikacji poprawnoci testowanego systemu wzgldem wymaga zdefiniowanych przez zleceniodawcw.

  • Test plan - zawartoOpisOdwzorowanie testw na wymagania (ang. requirements traceability)Weryfikacja pokrycia wymaga

    Wyszczeglnienie co bdzie podlega testowaniu

    Plan czasowyProcedury przeprowadzania testwZachowywanie wynikw testw

    Wymagania sprztowe i programoweZnane ograniczenia

  • PodsumowanieWeryfikacja != walidacjaCel testowania: stwierdzenie bdw w systemieTestowanie musi by uwzgldnione od pocztku w planach projektuRwnie w alokacji zasobw do projektuTest plan niezbdny dokument projektowy