of 207/207
Testowanie oprogramowania Dr inż. Andrzej Grosser

Wykład - Testowanie oprogramowania

  • View
    224

  • Download
    0

Embed Size (px)

Text of Wykład - Testowanie oprogramowania

  • Testowanie oprogramowaniaDr in. Andrzej Grosser

  • Literatura Andy Hunt, Dave Thomas JUnit.

    Pragmatyczne testy jednostkowe w Javie Helion 2006

    Srinivasan Desikan; Gopalaswamy Ramesh Software Testing: Principles and Practices Pearson Education India 2006

    Bogdan Wiszniewski, Bogdan Bereza-Jarociski Teoria i praktyka testowania programw PWN 2009

  • Aksjomaty testowania Programu nie da si przetestowa cakowicie Testowanie jest ryzykowne Test nie udowodni braku bdw Im wicej bdw znaleziono, tym wicej

    bdw pozostao do znalezienia Nie wszystkie znalezione bdy zostan

    naprawione Trudno powiedzie, kiedy bd jest bdem Specyfikacje produktw nigdy nie s gotowe

  • Definicja bdu

    Oprogramowanie nie robi czego co zostao wymienione w jego specyfikacji

    Oprogramowanie wykonuje co czego wedug specyfikacji nie powinno robi

    Oprogramowanie robi co o czym specyfikacji nie wspomina

  • Definicja bdu Oprogramowanie nie wykonuje czego o czym

    specyfikacja nie wspomina mimo e powinno to by wymienione jako istotn czci systemu.

    Oprogramowanie jest trudne do zrozumienia, powolne lub skomplikowane.

  • Poziomy testowania oprogramowania

    Testy jednostkowe (moduowe) Testy integracyjne Testy funkcjonalne Testy systemowe Testy akceptacyjne Testy w fazie utrzymywania systemu

  • Testowanie w cyklu ycia oprogramowania

    W modelu kaskadowym testowanie jest wydzielone jako osobna faza (ostatnia)

    Metodyki zwinne uwzgldniaj testowanie jako jedna z najwaniejszych faz cyklu ycia oprogramowania

  • Koszty bdw

    Specyfikacja Projekt Kodowanie Testowanie Wdraanie

  • Modele programu Modelowanie przez opis przepyww

    sterowania i danych Model skadniowy Model decyzyjny Model aksjomatyczny

  • Testowanie metod biaej skrzynki Wgld do kodu rdowego Systematyczny sprawdzanie elementw tego

    kodu. Mona przeprowadzi w sposb statyczny

    (statyczna analiza kodu znajdujca rda potencjalnych problemw w programie, zwana rwnie analiz strukturaln) lub dynamiczny (z wykonaniem programu).

  • Formalna analiza kodu Proces sterujcy testowaniem metod biaej

    skrzynki Elementy wyrniajce - identyfikacja

    problemw (znalezienie bdw i brakujcych elementw), postpowanie wedug narzuconych z gry zasad (np. liczba wierszy kodu podlegajcego przegldowi, ilo czasu na przegld), przygotowanie do przegldu (np. podzia uczestnikw na role, jakie bd peni w czasie przegldu) oraz tworzenie raportw (podsumowanie wynikw przegldu)

  • Standardy i reguy kodowania Standardy narzucaj ustalone, sztywne

    zestawy wymaga (zazwyczaj nie dopuszczaj wyjtkw od takich zasad), okrelaj jakich instrukcji naley uywa a jakich nie powinno si uywa.

    Reguy kodowania to sugerowane, praktyczne wskazwki, rekomendacje i zalecenia.

  • Standardy i reguy kodowania Powody narzucania standardw i regu

    kodowania: podnosi si niezawodno oprogramowania, -

    standardy nie dopuszczaj kiepsko udokumentowanych trikw, narzucaj rwnie sprawdzone techniki programistyczne

    atwiej czyta, zrozumie i modyfikowa oprogramowanie.

    uatwiona przenono pomidzy rnymi platformami systemowymi.

  • Analiza pokrycia kodu Analiza dynamiczna w testowaniu metod biaej

    skrzynki Pozwala ona na przetestowanie stanu

    programu i przepyww sterowania pomidzy tymi stanami

    Sprawdza si wejcie i wyjcie kadej jednostki programu, dy si do wykonania kadego wiersza programu i kadej moliwej cieki programu.

  • Analiza pokrycia kodu Umoliwia znalezienie wielu bdw - podczas

    projektowania i implementowania funkcji najwicej bdw powstaje w fragmentach, ktre s najrzadziej wykonywane.

    Przypadki szczeglne czsto nie s wychwytywane przez projektantw.

    Fragmenty programu, ktre miay by w zamierzeniach wykonywane niezwykle rzadko mog by w rzeczywistoci odwiedzane bardzo czsto.

  • Analiza pokrycia kodu Programy ledzce - umoliwiaj wgld w jaki

    sposb s wykonywane kolejne wiersze kodu podczas przetwarzania danych testowych.

    Analizatory pokrycia kodu, pozwalaj ponadto na sporzdzenie szczegowych statystyk dotyczcych wykonania testowanego programu. Umoliwia to uzyskanie informacji, ktre czci kodu nie zostay pokryte przez zastosowane testy.

  • Analiza pokrycia kodu Pokrycie kodu wykonywane jest przez:

    analiz pokrycia instrukcji (zwan rwnie pokryciem wiersza kodu) - wykonanie przynajmniej jednokrotne kadej instrukcji w programie

    pokrycie rozgazie programu (testowanie cieek) - wykonanie jak najwikszej liczby moliwych cieek programu, testowanie rozgazie

    analiz pokrycia warunkw logicznych - uwzgldnienie zoonych warunkw logicznych instrukcji warunkowej.

  • Testowanie mutacyjne Testowanie polega na generowaniu skadniowo

    poprawnych mutantw testowanego programu. Mutant w tym przypadku to program wolny od

    bdw skadniowych, rnicy si od oryginau drobnymi szczegami rnych instrukcji.

    Zmienione programy (mutanty) s generowane automatycznie. Ten sposb testowania jest nazywany (od strukturalnego testowania ukadw elektronicznych) zasiewem bdw.

  • Testowanie mutacyjne W pierwszym kroku generowane s kolejne

    mutanty testowanego programu. Nastpnie mutanty wraz z oryginalnym

    programem s rwnoczenie wykonywane dla tych samych danych wejciowych zadawanych przez testera lub losowo.

    Celem usunicie z puli jak najwikszej liczby mutantw. Usuwane s takie mutanty, dla ktrych mona zaobserwowa rnic w dziaaniu lub inny wynik ni w przypadku programu testowane

  • Testowanie metod czarnej skrzynki Koncentruje si na wymaganiach

    funkcjonalnych stawianych tworzonemu oprogramowaniu.

    Pozwala na sprawdzenie zgodnoci programu z wymaganiami uytkownika.

    Stosuje si go najczciej pod koniec testowania systemu.

    Ma na celu wykrycie pominitych lub niepoprawnie zaimplementowanych funkcjonalnoci ze specyfikacji uytkownika.

  • Testowanie danych warunki graniczne

    Zakada si, e realizowany przez program algorytm i jego implementacja s poprawne, za pojawiajce si bdy wynikaj z ogranicze zwizanych z platform sprztow, uytym jzykiem programowania.

    Celem testowania jest tutaj zaprojektowanie przypadkw testowych sprawdzajcych wartoci graniczne i unikatowe zwizane z architektur komputera na ktrej bdzie uruchamiany testowany program, jzykiem implementacji i realizowanym algorytmem.

  • Wartoci specjalne i transcendentne Problem doboru takich wartoci:

    Dla operacji arytmetycznych mona dobra maksymalne i minimalne wartoci operandw, elementy jednostkowe i zerowe.

    Dla tablic dobr takich wartoci mgby dotyczy pustej tablicy, wykraczajcych poza zakres tablicy indeksw i poprawnych wartoci indeksw.

    Dla bardziej skomplikowanych struktur danych tak jak listy i drzewa mog to by puste wskaniki (odniesienia), jednoelementowe, zawierajce wiele elementw i listy z tak zwanym zerwanym wskanikiem.

  • Metoda klas rwnowanoci Metoda ta pozwala na ograniczenie, czsto

    ogromnego zbioru zada testowych do mniejszej, cile okrelonej klasy danych testowych.

    Klas rwnowanoci jest tutaj okrelany zbir zada testowych, ktre sprawdzaj sprawdzaj aplikacj (fragment aplikacji) pod ktem tego samego bdu.

    Jedna klasa rwnowanoci zawiera zwykle wiele zestaww testowych, zgodnych (lub niezgodnych) z pewnymi warunkami wejciowymi.

  • Metoda Monte Carlo i metody genetyczne

  • Metoda Monte Carlo i metody genetyczne

    Algorytm genetyczny jest wykonywany cyklicznie.

    W pierwszym cyklu populacja jest dobierana losowo.

    W kadym nastpnym cyklu wykonywane s operacje krzyowania (wymiana czci pomidzy wektorami bitowymi), mutacji (losowy bit w wektorze bitowym ulega zmianie) i reprodukcji na populacji danych testowych.

  • Metody Monte Carlo i metody genetyczne

    Elementy biorce udzia w tworzeniu nowej populacji s wybierane na podstawie wartoci tak zwanej funkcji dopasowania, ktra opisuje wasnoci populacji.

    Sposb pozwala na zmniejszenie liczby danych testowych, wymaga jednak dodatkowego kosztu zwizanego z przeksztaceniem danych wejciowych do wektorw bitowych (tzw. chromosomw).

  • Testy jednostkowe Test jednostkowy fragment kodu

    sprawdzajcy dziaanie pewnego, niewielkiego, dokadnie okrelonego obszaru funkcjonalnoci testowanego kodu

    Zadaniem testw jednostkowych jest udowodnienie, e kod dziaa zgodnie z zaoeniami programisty

  • Testy jednostkowe Waciwoci poprawnych testw jednostkowych

    Automatyzacja Kompletno Powtarzalno Niezaleno Profesjonalizm

  • Automatyzacja Testy jednostkowe musz by wykonywane w

    automatyczny sposb Automatyzacja dotyczy tutaj uruchamiania

    testw i sprawdzania ich wynikw Testy s wykonywane wielokrotnie, dlatego ich

    uruchamianie musi by proste

  • Kompletno Testy musz testowa wszystko co moe

    zawie Dwa podejcia:

    testowanie kadego wiersza kodu i kadego rozgazienia sterowania

    Testowanie fragmentw najbardziej naraonych na bdy

    Narzdzia umoliwiajce sprawdzenie jaka cz testowanego kodu jest w rzeczywistoci wykonywana

  • Powtarzalno Testy powinny by niezalene nie tylko od

    siebie, ale rwnie od rodowiska wielokrotne wykonywanie testw, nawet w rnej kolejnoci, powinno da te same wyniki

    Obiekty imitacji pozwalaj odseparowa testowane metody od zmian zachodzcych w rodowisku

  • Niezaleno Testy powinny si koncentrowa na testowanej

    w danym momencie metodzie oraz by niezalene od rodowiska i innych testw

    Testy musz testowa jeden aspekt dziaajcego kodu sprawdza dziaanie pojedynczej metody lub niewielkiego zestawu takich metod, ktre wsppracujc ze sob dostarczaj jak funkcjonalno

    Przeprowadzenie testu nie moe zalee od wyniku innego testu

  • Profesjonalizm Kod testujcy powinien spenia te same

    wymagania co kod produkcyjny Musz by przestrzegane zasady poprawnego

    projektowania np. hermetyzacja, regua DRY. Brak testw dla fragmentw, ktre nie s

    istotne np. proste metody dostpowe Liczba wierszy kodu testujcego porwnywalna

    z liczb wierszy kodu produkcyjnego

  • Obszary testowania Czy wyniki s poprawne? Czy warunki brzegowe s okrelone

    poprawnie? Czy mona sprawdzi relacje zachodzce w

    odwrotnym kierunku? Czy mona uzyska wyniki korzystajc z

    alternatywnego sposobu? Czy mona wymusi warunki zachodzenia

    bdu? Czy efektywno jest poprawna?

  • Poprawno wynikw Wyniki dziaania kodu znajduj si czsto w

    specyfikacji wymaga W przypadku braku dokadnej specyfikacji -

    zaoenie wasnych wymaga odnonie wynikw metod

    Weryfikacja zaoe w wsppracy z uytkownikami

    Dla zestawu testw wymagajcych duej liczby danych wejciowych uywanie plikw

  • Warunki brzegowe Typowe warunki brzegowe:

    Wprowadzenie bdnych lub niespjnych danych wejciowych Nieprawidowy format danych wejciowych Nieodpowiednie wartoci Dane przekraczajce znacznie oczekiwania

    Pojawienie si duplikatw na listach Wystpienie list nieuporztkowanych Zakcenie typowego porzdku zdarze

  • Warunki brzegowe Poszukiwanie warunkw brzegowych:

    Zgodno (z oczekiwanym formatem) Uporzdkowanie (poprawne uporzdkowanie zbioru

    wartoci) Zakres (poprawny zakres danych wejciowych) Odwoanie (do zewntrznych obiektw

    znajdujcych si poza kontrol kodu) Istnienie (warto istnieje) Liczno (dokadnie tyle wartoci ile jest

    oczekiwanych) Czas zdarzenia zachodz w oczekiwanej

    kolejnoci

  • Odwrcenie relacji Dziaanie niektrych funkcji mona

    przetestowa stosujc logik dziaania w odwrotnym kierunku (pierwiastkowanie podnoszenie do kwadratu)

    Zalecana ostrono implementacje obu funkcji mog zawiera podobne bdy

  • Kontrola wynikw na wiele sposobw

    Wyniki dziaania testowanych metod mona sprawdza na wiele sposobw zazwyczaj istnieje wicej ni jeden sposb wyznaczania wartoci

    Implementacja kodu produkcyjnego z wykorzystaniem najefektywniejszego algorytmu, inne algorytmy mona uy do sprawdzenia czy wersja produkcyjna daje te same wyniki.

  • Wymuszanie warunkw powstawania bdw

    Rzeczywisty system naraony jest na rnego rodzaju zewntrzne bdy np. brak miejsca na dysku, awarie infrastruktury zewntrznej sieci, problemy z rozdzielczoci ekranu, przecieniem systemu

    Przekazywanie niepoprawnych parametrw, symulacje zewntrznych bdw z wykorzystaniem obiektw imitacji

  • Charakterystyka efektywnociowa Charakterystyka efektywnociowa sposb

    zmiany efektywnoci kodu w odpowiedzi na rosnc liczb danych, rosnc komplikacj problemu.

    Zmiany efektywnoci programu w zalenoci od wersji kodu

    Testy sprawdzajce czy krzywa efektywnoci jest stabilna w rnych wersjach programu

  • Obiekty imitacji Dziaanie kodu moe zalee od wielu

    czynnikw niezalenych od kodu oraz innych czci systemu

    Testy bd musiay inicjowa wiele komponentw systemu trudne w sytuacji cigle zmienicego si systemu

    Te problemy mona rozwiza stosujc namiastki rzeczywistych obiektw obiekty imitacji

  • Obiekt imitacji

    Obiekty imitacji s uywane, gdy: Obiekt rzeczywisty zachowuje si

    niedeterministycznie (wynik jego dziaania jest nieprzewidywalny

    Obiekt rzeczywisty jest trudny do skonfigurowania

    Trudno wywoa istotne z punktu widzenia testowania zachowanie obiektu rzeczywistego

  • Obiekt imitacji Dziaanie obiektu rzeczywistego jest powolne Obiekt rzeczywisty ma graficzny interfejs

    uytkownika lub jest czci graficznego interfejsu uytkownika

    Test musi uzyska informacje o sposobie uycia rzeczywistego obiektu

    Obiekt rzeczywisty jeszcze nie istnieje (czsty problem podczas czenia kodu z innymi podsystamami)

  • Obiekty imitacji Etapy testowania przy uyciu obiektw imitacji:

    Stworzenie interfejsu do opisu obiektu Implementacja interfejsu dla kodu produkcyjnego Implementacja interfejsu przez obiekt imitacji dla

    potrzeb testowania

  • Puapki testowania Ignorowanie testw jednostkowych, gdy kod

    dziaa Testy ognia Program dziaa na komputerze programisty Problemy arytmetyki zmiennoprzecinkowej Testy zajmuja zbyt wiele czasu Testy cigle zawodz Testy zawodz na niektrych maszynach

  • Kod dziaa poprawnie nie przechodzi testw

    Kod dziaa poprawnie, ale nie przechodzi testw jednostkowych

    Mona sprbowa zignorowa test, ale: Kod moe w kadej chwili przesta dziaa Zmarnowany wysiek powicony na pisanie testw

    Najlepsz strategi przyjcie zaoenia, e kod zawiera bdy

  • Testy ognia Testy ognia zaoenie, e metoda nie zawiera

    bdw, gdy wykona swj kod bez bdw Takie testy zawieraj zwykle jedn asercj na

    kocu kodu testujcego assertTrue(true) sprawdza to czy sterowanie doszo do koca kodu

    Za mao nie sprawdzono adnych danych ani zachowania kodu

    Testy powinny polega na sprawdzaniu wynikw

  • Arytmetyka zmiennoprzecinkowa Komputer umoliwia jedynie skoczon

    dokadno reprezentacji liczb zmiennoprzecinkowych i operacji na nich

    Problemy z reprezentacj liczb dziesitnych w systemie dwjkowym

    Konieczna pewna dokadno z jak porwnywane s wyniki

  • Testy zajmuj zbyt wiele czasu Testy jednostkowe powinny by wykonywane

    szybko s robione wiele razy Wyodrbni testy wykonywane zbyt wolno,

    obniajce efektywno testowania Testy wykonywane wolno powinny by

    wykonywane rzadziej, np. raz dziennie

  • Testy cigle zawodz Rne testy kocz si stale niepomylnym

    wynikiem Niewielkie zmiany w kodzie powoduj, e cz

    testw przestaje przechodzi pomylnie testowanie

    Najczciej oznaka zbyt duego powizania z zewntrznymi danymi lub innymi czciami systemu

  • Testy zawodz na niektrych maszynach

    Testy s wykonywane poprawnie jedynie na wikszoci komputerw

    Najczstszym problemem rne wersje systemu operacyjnego, bibliotek, wersji kompilatora, sterownikw, konfiguracji, wydajnoci i architektury maszyny

    Zaoenie, e testy powinny by wykonywane poprawnie na wszystkich maszynach

  • U mnie dziaa Program dziaa poprawnie na komputerze

    programisty Bdy ze rodowiskiem, w ktrym dziaa

    program: Kod nie zosta wprowadzony do systemu kontroli

    wersji Niespjne rodowisko programowania Prawdziwy bd, ktry jest ujawniony w okrelonych

    warunkach Testy musz by wykonywane z sukcesem na

    wszystkich maszynach

  • rodowiska testowania jednostkowego

    Java JUnit TestNG

    C# framework Microsoft NUnit

  • Biblioteki do budowy obiektw imitacji

    Java Easy Mock JMock

    C# Moq Rhino Mocks

  • JUnit Framework o otwartych rdach przeznaczony

    do testowania jednostkowego kodw napisanych w jzyku Java

    Integracja z popularnymi rodowiskami programistycznymi Eclipse, NetBeans, IntelIiJ

    Wersja 4 korzysta z mechanizmu adnotacji

  • Testowanie z JUnit Umoliwia odseparowanie testw co pozwala

    na uniknicie efektw ubocznych Adnotacje @Before, @BeforeClass, @After i

    @AfterClass umoliwiaj inicjowananie i odzyskiwanie zasobw

    Zbir metod assert umoliwia awe sprawdzanie wynikw testowanie

  • Prosty testimport static org.junit.Assert.*;import org.junit.Test;public class AddTest {@Testpublic void TestAdd() {double result = 10 + 20;assertEquals(30, result, 0);}}

  • Kompilacja i uruchamianie z konsoli

    Kompilacja: javac -cp /opt/junit4.8/junit-4.8.jar *.java

    Uruchamianie testu z konsoli Java -cp .:/opt/junit4.8/junit-4.8.jar

    org.junit.runner.JUnitCore AddTest

  • Parametryzowanie testw[]@RunWith(value=Parameterized.classpublic class ParameterizedTest { private double expected, valueOne, valueTwo; @Parameters public static Collection getTestParameters() { return Array.asList(new Integer[][] {2,1,1},{3,1,2},{3,2,1}});}

  • Parametryzowanie testwpublic ParameterizedTest(double exp, double vo, double vT) { expected = exp; valueOne = vo; valueTwo = vT;}@Testpublic void sumTest() { assertEquals(expected, valueOne + valueTwo, 0);}} //class

  • Testowanie rzucania wyjtkw Framework JUnit umoliwia sprawdzanie czy

    dany wyjtek zosta wyrzucony w okrelonej sytuacji

    @Test(expected=RuntimeException.class)public void testExceptionMethod(){//...}

  • Testowanie czasu wykonania JUnit umoliwia sprawdzanie czasu wykonania

    danego fragmentu kodu. Parametr timeout pozwala na ustawienie czasu,

    ktrego przekroczenie spowoduje, e test nie zostanie zaliczony. Wprowadzona bariera czasowa jest zapisywana w milisekundach

    @Test(timeout = 120)public void testTimeMethod(){//...}

  • Ignorowanie testw Czasami istniej powody, eby zignorowa

    wyniki niektrych testw np. w sytuacji, gdy do koca nie wiadomo, jaki bdzie trzeba ustali limit czasowy.

    Junit pozwala na ignorowanie wynikw niektrych testw za pomoc adnotacji @Ignore

    @Test

    @Ignore(value=Zignorowany do ustalenia czasu)

    public void testIgnore(){}

  • Testy jednostkowe w .NET public class ClassTest

    {

    //Wykonywane raz przed wszystkimi testami klasy

    [ClassInitialize()]

    public void methodClassInitialize(){}

    //Wykonywane raz po wszystkich testach klasy

    [ClassCleanup()]

    public void methodClassCleanup(){}

  • Testy jednostkowe w .NET//Wykonywane przed ka dym testem

    [TestInitialize()]

    public void methodTestInitialize(){}

    //Wykonywane po ka dym te cie

    [TestCleanup()]

    public void methodTestInitialize(){}

    //Metoda testuj ca[TestMethod()]

    public void testMethod(){}

    }

  • Testy jednostkowe w .NET Asercje s zdefiniowane w przestrzeni nazw:

    Microsoft.VisualStudio.TestTools.UnitTesting Klasami asercji Assert, StringAssert,

    CollectionAssert Przykadowe metody: Assert.AreEqual,

    Assert.AreSame, Assert.Fail, Assert.IsTrue, StringAssert.Matches, CollectionAssert.AreEquivalent

    Asercje mog zwraca Pass, Fail i Inconclusive (Assert.Inconlusive)

  • Testy jednostkowe w .NET ExpectedExceptionAtribute zaznacza, e

    dany wyjtek jest spodziewany w czasie wywoania metody testowej[TestMethod()][ExpectedException=typeof(MyException)]

    TimeoutAttribute okrela okres czasowy dla wykonania testu jednostkowego[TestMethod()][Timeout = 120]

  • EasyMock EasyMock jest bibliotek dostarczajc klas dla

    obiektw imitacji. Pozwala na korzystanie z atrap bez ich pisania Biblioteka generuje obiekty imitacji (atrapy) za

    pomoc mechanizmu proxy (dostpnego w Javie od wersji 1.3).

    Obiekt sterujcy imitacj umoliwia wczenie trybu nagrywania i trybu odtwarzania.

  • EasyMock Utworzy obiekt imitacji dla interfejsu, ktry ma

    by symulowany Zapisa spodziewane zachowanie dla metod

    interfejsu (mog by tylko wybrane metody interfejsu)

    Przeczy obiekt imitacji w tryb odtwarzania

  • EasyMockimport static org.easymock.EasyMock.*;import org.junit.*;public interface Interface1 {public int method1(); public void method2();}class TestClass {Interface1 mock; @Before public void setUp() {//Krok 1 mock = createMock(Interface1.class);}

  • [email protected] void test() { // Krok 2 mock.method2(); expect(mock.method1()).andReturn(2); // Krok 3

    replay(mock);//...

    verify(mock);}

  • Moq Biblioteka wspierajca tworzenie obiektw

    imitacji Prosta w uyciu nie ma trybw zapisu i

    odgrywania (record/replay) Korzysta z wyrae lambda (.NET 3.5)

  • Moq Tworzenie obiektu imitacjivar mock = new Mock();

    Konfiguracja zalepkimock.Setup(foo => foo.method1("foo")).Returns(true);

    Odwoanie do obiektu imitacjimock.Object.method1("foo");

    Weryfikacja obiektu imitacjimock.VerifyAll();

  • Testowanie wydajnoci Niska wydajno lub brak dostpu do usugi

    moe powodowa znaczne straty finansowe (np. klienci przenios si do konkurencji)

    Wysokowydajne systemy (serwery, cza o duej przepustowoci) s kosztowne

    Konieczna jest rwnowaga pomidzy tymi dwoma czynnikami

  • Testowanie wydajnoci Testowanie wydajnoci:

    jest skomplikowane i kosztowne zwizku z iloci zasobw jakich wymaga oraz czasu jakiego naley na nie powici.

    nie jest jednoznaczne rne osoby mog mie inne oczekiwania co do wydajnoci

    dua liczba defektw odsonitych podczas testowania moe wymaga zmiany projektu systemu

  • Testowanie wydajnoci Wykonywane w celu zapewnienia, e aplikacja:

    Przetwarza okrelon liczb transakcji w zaoonym przedziale czasu

    Jest dostpna i ma moliwo uruchomienia w rnych warunkach obcieniowych

    Umoliwia wystarczajco szybk odpowied w rnych warunkach obcieniowych

    Umoliwia dostp do zasobw w zalenoci od potrzeb aplikacji

    Jest porwnywalna pod wzgldem parametrw wydajnociowych od konkurencyjnych aplikacji

  • Parametry wydajnoci Przepustowo

    liczba transakcji/da obsugiwanych przez system w okrelonym przedziale czasu

    mierzy ile transakcji moe by przetwarzanych w okrelonym przedziale czasu przy zadanym obcieniu (np. liczbie wykonywanych transakcji, liczbie korzystajcych z systemu klientw)

    przepustowo optymalna to maksymalna liczba wykonywanych transakcji

  • Parametry wydajnoci Czas odpowiedzi

    opnienie pomidzy momentem wysania dania a pierwsz odpowiedzi serwera

    Opnienie nie kady duszy czas oczekiwania na odpowied

    jest spowodowany dziaaniem aplikacji zwoka spowodowana przez aplikacj, system

    operacyjny, rodowisko uruchomieniowe

  • Metodyka testowania wydajnociowego

    Zbieranie wymaga Zapis przypadkw testowych Automatyzacja przypadkw testowych Wykonanie przypadkw testowych Analiza otrzymanych wynikw Wykonanie benchmarkw Dostrajanie wydajnoci Rekomendacja waciwej konfiguracji dla

    klienta (planowanie obcienia)

  • Zbieranie wymaga Wymagane wyniki mog zalee od ustawie

    rodowiska, mog rwnie nie by znane z gry

    Wymagania powinny by moliwe do przetestowania

    Wymagania musz jasno okreli jakie parametry maj by mierzone i ulepszane

    Wymagania testowe musz by skojarzone z podanym stopniem ulepszenia wydajnoci aplikacji

  • Zapis przypadkw testowych Definiowanie przypadku testowego:

    Lista operacji lub transakcji przewidzianych do testowania

    Opis sposobu wykonania tych operacji Lista produktw oraz parametrw wpywajcych na

    wydajno Szablon obcienia Spodziewany wynik Porwnanie wynikw z poprzednimi

    wersjami/konkurencyjnymi aplikacjami

  • Automatyzacja przypadkw testowych

    Testy wydajnoci s wielokrotnie powtarzane Testy wydajnoci musz by

    zautomatyzowane,w najgorszym przypadku niemoliwe jest testowanie bez tego uatwienia

    Testy wydajnoci musz dawa dokadne informacje, rczne przeliczanie moe wprowadza dodatkowy bd pomiaru

  • Automatyzacja przypadkw testowych

    Testowanie wydajnoci jest uzalenione od wielu czynnikw. Mog one wystpowa w rnych kombinacjach, ktre trudno wyprowadzi rcznie.

    Analiza wynikw wymaga dostarczenia wielu informacji pomocniczych logw, sposobw wykorzystania zasobw w okrelonych przedziaach czasu, co jest trudne lub niemoliwe do uzyskania rcznie

  • Wykonanie przypadkw testowych Zapis czasu pocztku i koca testu Zapis plikw zawierajcych informacje o

    produkcie i systemie operacyjnym, wanych dla powtarzalnoci testw i przyszego debugowania

    Zuycie zasobw (CPU, pami, obcienie sieci)

    Zapis konfiguracji testowej zawierajcy wszystkie czynniki rodowiskowe

    Zbieranie informacji o wymaganych parametrach

  • Analiza otrzymanych wynikw Obliczenia statystyczne dla otrzymanych

    wynikw rednia i odchylenie standardowe Usunicie szumu informacyjnego i ponowne

    obliczenie statystyk Zrnicowanie wynikw uzyskanych z cache od

    wynikw bezporednio uzyskanych od aplikacji Odrnienie wynikw testowania uzyskanych w

    sytuacji, gdy wszystkie zasoby byy dostpne od wynikw, gdy byy uruchomione dodatkowe usugi w tle

  • Analiza otrzymanych wynikw Czy zachowana jest wydajno testowanego

    systemu, gdy testy s wykonywane wielokrotnie?

    Jaka wydajno moe by spodziewana w zalenoci od rnych konfiguracji (np. dostpnych zasobw)?

    Jakie parametry wpywaj na wydajno? Jaki jest efekt scenariuszy z udziaem kilku

    rnych operacji dla czynnikw wydajnociowych?

  • Analiza otrzymanych wynikw Jaki jest wpyw technologii (np. zastosowanie

    cache) na testy wydajnociowe? Jaki jest optymalny czas

    odpowiedzi/przepustowo dla rnego zbioru czynnikw wpywajcych na system obcienie, liczba zasobw i innych parametrw?

    Jakie obcienie jest jeszcze moliwe do zaakceptowania i w jakich okolicznociach dochodzi do zaamania wydajnoci?

  • Analiza otrzymanych wynikw Czy wymagania wydajnociowe s spenione i

    jak wyglda wydajno w porwnaniu z poprzednimi wersjami lub spodziewanymi wynikami?

    Gdy nie ma jeszcze dostpu do wysokowydajnych konfiguracji, mona na podstawie dostpnych wynikw przewidzie rezultaty na takich maszynach

  • Dostrajanie wydajnoci Dostrajanie wydajnoci:

    forkowanie procesw w celu umoliwienia rwnolegych transakcji,

    wykonywanie operacji w tle powikszenie cache i pamici operacyjnej dostarczenie wyszego priorytetu dla czsto

    uywanych operacji, zmiana sekwencji operacji

  • Wykonywanie benchmarkw Identyfikacja transakcji/scenariuszy i

    konfiguracji testowych Porwnanie wydajnoci rnych produktw Dostrajanie parametrw porwnywanych

    produktw w celu uzyskania najlepszej wydajnoci

    Publikacja wynikw testw

  • Planowanie obcienia Wyszukiwanie jakie zasoby i konfiguracja jest

    konieczna w celu osignicia najlepszych rezultatw

    Ustalenie jak wydajno osignie klient przy aktualnie dostpnych zasobach zarwno sprztowych jak i softwerowych.

  • Narzdzia do testowania wydajnociowego

    Narzdzia do testowania funkcjonalnego zapis i odtwarzanie operacji w celu uzyskania parametrw wydajnociowych

    Narzdzia do testowania obcieniowego symulacja warunkw obcieniowych bez potrzeby wprowadzania wielu uytkownikw lub maszyn

    Narzdzia do mierzenia zuycia zasobw

  • Testowanie regresyjne Testowanie regresyjne jest wykonywane w celu

    upewnienia si, e wprowadzone nowe elementy lub naprawa defektw nie wpyna niekorzystnie na zbudowane wczeniej elementy systemu

  • Typy testw regresyjnych Regularne testy regresyjne wykonywane

    pomidzy cyklami testowania w celu zapewnienia, e po wprowadzonych poprawkach elementy aplikacji testowane wczeniej nadal dziaaj poprawnie

    Kocowe testy regresyjne wykonywane w celu walidacji ostatniej wersji aplikacji przed jej wypuszczeniem na rynek. S uruchamiane na pewien okres czasu, poniewa niektre defekty ujawniaj si dopiero po pewnej chwili (np. wycieki pamici)

  • Wybr momentu testowania regresyjnego

    Znaczca liczba wstpnych testw zostaa ju przeprowadzona

    Zostaa wprowadzona dua liczba poprawek Poprawki mogy wprowadzi efekty uboczne

  • Testowanie regresyjne

  • Metodyka testowania regresyjnego Wykonanie pocztkowych testw smoke lub

    sanity Zrozumienie kryteriw wyboru przypadkw

    testowych Klasyfikacja przypadkw testowych pod

    wzgldem rnych priorytetw

  • Metodyka testowania regresyjnego Metodyka selekcji przypadkw testowych Ponowne ustawianie przypadkw testowych do

    wykonania Podsumowanie cyklu regresyjnego

  • Smoke test Testy dymne (ang. smoke test) skadaj si z:

    Identyfikacji podstawowej funkcjonalnoci jak musi spenia przygotowywany produkt

    Przygotowanie przypadku testowego w celu zapewnienia, e podstawowa funkcjonalno dziaa i dodanie go do zestawu testw

    Zapewnienie, e ten zestaw przypadkw testowych bdzie wykonywany po kadej budowie systemu

    W przypadku niepowodzenia tego testowania poprawienie lub wycofanie zmian

  • Zrozumienie wyboru przypadkw testowych

    Wymaga informacji na temat: Wprowadzonych poprawek i zmian do biecej

    wersji aplikacji Sposobw testowania wprowadzonych zmian Wpywu jaki mog mie wprowadzone poprawki na

    reszt systemu Sposobu testowania elementw, na ktre mogy

    mie wpyw wprowadzone poprawki

  • Klasyfikacja przypadkw testowych Podzia ze wzgldu na priorytet dla uytkownika

    Priorytet 0 Testy sprawdzaj podstawow funkcjonalno. Najwaniejsze z punktu widzenia uytkownika i twrcw systemu

    Priorytet 1 Testy uywaj podstawowych i normalnych ustawie dla aplikacji. Wane z punktu widzenia uytkownika i twrcw systemu

    Priorytet 2 Testy dostarczaj pogldowych wartoci odnonie projektu.

  • Metodyka wyboru przypadkw testowych

    Gdy wpyw wprowadzonych poprawek na reszt kodu jest may mona wybra tylko wybrane testy z zbioru przypadkw testowych. Mona wybra testy o priorytecie 0, 1 lub 2.

    Gdy wpyw wprowadzonych poprawek jest redni naley wybra wszystkie testy o priorytecie 0 i 1. Wybr testw o priorytecie 2 jest moliwy, lecz nie jest konieczny

    Gdy wpyw wprowadzonych poprawek jest duy naley wybra wszystkie testy o priorytecie 0 i 1 oraz starannie wybrane testy o priorytecie 2.

  • Ustawianie przypadkw testowych Jest wykonywane gdy:

    Wystpiy due zmiany w produkcie Nastpia zmiana w procedurze budowania

    wpywajca na system Wystpuj due cykle wprowadzania kolejnych

    wersji, podczas ktrych pewne przypadki testowe nie byy wykonywane przez duszy czas

    Produkt jest w finalnej wersji z kilkoma wybranymi przypadkami testowymi

    Wystpia sytuacja, gdy spodziewane wyniki testw s zupenie inne w porwnaniu z poprzednim cyklem

  • Ustawianie przypadkw testowych Przypadki testowe bdce w relacji z

    wprowadzonymi poprawkami mog by usunite, gdy kolejne wersje nie powoduj zgaszania bdw

    Usunito z aplikacji jak funkcjonalno, przypadki testowe powizane z ni rwnie powinny by usunite

    Przypadki testowe kocz si za kadym razem wynik pozytywnym

    Przypadki testowe powizane z kilkoma negatywnymi warunkami testowymi (nie powodujcymi wykrywanie defektw) mog by usunite

  • Podsumowanie cyklu regresyjnego Przypadek testowy zakoczy si sukcesem w

    poprzedniej wersji i niepowodzeniem przy obecnej regresja zakoczona niepowodzeniem

    Przypadek testowy zakoczy si niepowodzeniem w poprzedniej wersji i przeszed pomylnie test w obecnej wersji mona zaoy, e wprowadzone poprawki rozwizay problem

  • Podsumowanie cyklu regresyjnego Przypadek testowy koczy si niepowodzeniem

    w obu wersjach (poprzedniej i obecnej) przy braku wprowadzonych poprawek dla tego przypadku testowego mona oznacza, e test nie powinien by wliczany do wynikw testowania. Moe rwnie oznacza, e naley dany przypadek testowy usun.

    Przypadek testowy koczy si niepowodzeniem w poprzedniej wersji a w obecnej dziaa z dobrze udokumentowanym obejciem problemu, to regresj mona uzna za zakoczon sukcesem

  • Porady dotyczce testowania regresyjnego

    Regresje mog by uywane ze wszystkimi wersjami (wprowadzajcymi poprawki, now funkcjonalno)

    Powizanie problemu z przypadkiem testowym zwiksza jako regresji

    Testy regresyjne powinny by wykonywane codziennie

    Lokalizacja i usunicie problemu powinna ochroni produkt przed wpywem problemu i poprawki

  • Testowanie dorane Wymagania zmieniaj si wraz ze ewolucj

    oprogramowania Planowane test wymagaj dostosowania do

    zmian w produkcie mudne i czasochonne Planowane testy mog pomija istotne

    elementy, ktre pojawiy si w czasie tworzenia oprogramowania

  • Przyczyny testowania Brak dokadnie wyspecyfikowanych wymaga

    testy wprowadzone wczeniej nie bior pod uwag dowiadcze zdobytych w procesie tworzenia oprogramowania

    Brak umiejtnoci niezbdnych do wykonania testw testy napisane wczeniej nie bior pod uwag wzrostu umiejtnoci testerw

    Brak czasu na projektowanie testw mona pomin istotne z punktu widzenia systemu perspektywy

  • Testowanie dorane Analiza istniejcych przypadkw testowych Planowanie testw Wykonanie testw Generowanie raportw z testw Projektowanie przypadku testowego

  • Planowanie testw doranych Po wykonaniu pewnej liczby zaplanowanych

    testw mog by uzyskane nowe sposoby spojrzenia na produkt a take mog by odsonite nowe defekty

    Przed zaplanowanymi testami w celu zdobycia lepszego spojrzenia na wymagania i osignicia z gry lepszej jakoci produktu

  • Wady testowania doranego Trudnoci z zapewnieniem, e wiedza zdobyta

    w czasie testowania doranego bdzie uyta w przyszoci

    Brak pewnoci, czy zostay pokryte przez testy dorane najwaniejsze aspekty systemu

    Trudnoci z ledzeniem krokw potrzebnych do powtrzenia testu

    Brak danych do analizy metrycznej

  • Metody testowania ad hoc Testowanie losowe Testowanie koleeskie Testowanie parami Testowanie badawcze Testowanie iteracyjne Testowanie zwinne i ekstremalne Zasiew defektw

  • Testowanie koleeskie Dwaj czonkowie zespou (zazwyczaj

    programista i tester) pracuj nad identyfikacj i usuniciem problemu w oprogramowaniu

    Sprawdza si np.: standardy kodowania, definicje zmiennych, kontrole bdw, stopie udokumentowania kodu

    Uywa si testw biaej i czarnej skrzynki

  • Testowanie parami Wykonywane przez dwch testerw na tej

    samej maszynie Celem jest wymiana pomysw pomidzy

    osobami, lepsze zrozumienie wymaga stawianych projektowi, zwikszenie umiejtnoci testowania oprogramowania

    Podzia na role tester i skryba jedna osoba wykonuje testy, druga robi notatki

  • Testowanie badawcze Na podstawie poprzednich dowiadcze z

    technologi, podobnymi systemami wnioskuje si jakie bdy program moe zawiera

    Technika uyteczna szczeglnie w przypadku systemw nieprzetestowanych wczeniej, nieznanych albo niestabilnych

    Uywana, gdy nie do koca wiadomo jakie testy naley jeszcze dooy do istniejcej bazy testw

  • Techniki testowania badawczego Zgadywanie na podstawie wczeniejszych

    dowiadcze z podobnymi produktami tester zgaduje, ktra cz programu zawiera najwicej bdw

    Uycie diagramw architektonicznych i przypadkw uycia tester uywa do testowania diagramw architektoniczne przedstawiaj jak wygldaj powizania pomidzy moduami, przypadki uycia natomiast dostarczaj informacji o systemie z punktu widzenia uytkownika

  • Techniki testowania badawczego Studiowanie poprzednich defektw pozwala

    na ustalenie jakie czci systemu s najbardziej naraone na defekty

    Obsuga bdw system po wykonaniu niepoprawnej operacji uytkownika moe by niestabilny. Obsuga bdw powinna dostarcza czytelnych komunikatw diagnostycznych i/lub sposobw zaradzenia problemowi. Testuje si sytuacje, w ktrych dochodzi do tego bdw.

  • Techniki testowania badawczego Dyskusja szczegy implementacyjne

    uyteczna dla testowania systemu s omawiane na spotkaniach

    Uycie kwestionariuszy i wykazw odpowiedzi na pytania (np. jak, gdzie, kto i dlaczego) pozwalaj ustali jakie obszary naley przebada w systemie

  • Testowanie iteracyjne Uywany, gdy dodawane s wymagania

    systemowe z kad wersj oprogramowania (np. model spiralny)

    Ma zapewnia, e zaimplementowana wczeniej funkcjonalno nadal jest testowana wymagane powtarzalne testy

    Zmiany w testach wykonywane w kadej iteracji Nie wszystkie rodzaje testw s wykonywane w

    wczeniejszych iteracjach (np. testy wydajnociowe)

  • Testowanie zwinne i ekstremalne Ma na celu zapewnienie, e wymagania

    uytkownika s spenione w odpowiednim czasie

    Uytkownik jest czci zespou przygotowujcego oprogramowanie (rozprasza wszelkie wtpliwoci, odpowiada na pytania)

    Podobnie jak w poprzednim modelu oprogramowanie rozwija si w iteracjach

  • Testowanie zwinne i ekstremalne Testerzy nie s traktowani jako osobna grupa

    wykonujca swoje zadania Testerzy nie musz wysya raportw i czeka

    na odpowied innych czonkw zespou Testerzy traktowani jako pomost pomidzy

    programistami (znajcymi technologie i sposoby implementacji pomysw) a uytkownikami (znajcymi swoje wymagania) wyjaniaj rne punkty widzenia

  • Zasiew bdw Zazwyczaj polega na tym, e cz czonkw

    zespou wprowadza do programu bdu, ktre pozostaa cz zespou prbuje zidentyfikowa

    Wprowadzane bdy s podobne do rzeczywistych defektw

    W czasie wyszukiwania zasianych bdw mona zidentyfikowa rwnie bdy, ktre nie byy wprowadzone celowo

  • Zasiew bdw Moe by wskazwk efektywnoci procesu

    testowania, moe mierzy liczb usunitych bdw i pozostajcych w kodzieliczukb = (liczbz / liczbwzb) * liczwab liczukb liczba ukrytych bdw liczbz liczba bdw zasianych liczbwzb liczba wykrytych zasianych bdw liczwab liczba wykrytych autentycznych bdw

  • Specyfika systemw obiektowych Znaczne powizanie danych z metodami

    dziaajcymi na tych danych Operacje wykonywane jedynie z

    wykorzystaniem publicznego interfejsu, ukrywanie informacji

    Dziedziczenie umoliwia definiowanie nowych klas z ju istniejcych. Istotne take ze wzgldu na wizanie dynamiczne i polimorfizm

  • Testowanie systemw obiektowych Testowanie jednostkowe klas Testowanie wsppracy klas ze sob (testy

    integracyjne klas) Testowanie systemowe Testy regresyjne

  • Testowanie klas Klasy s zaprojektowane do czstego

    uywania. Bdy w kodzie mog by odczuwalne w kadej instancji klasy.

    Wiele bdw pojawio si w kodzie klasy od razu jak zostaa zdefiniowana. Zwoka w wykryciu tych bdw bdzie skutkowaa tym, e oprogramowanie korzystajce z klasy bdzie naraone na ich skutki.

    Klasy maj dostarczaj rnych funkcjonalnoci, oprogramowanie moe korzysta z rnych funkcjonalnoci

  • Testowanie klas Klasa jest kombinacj danych i metod. Jeli

    dane i metody nie s ze sob zsynchronizowane na potrzeby testw jednostkowych, moe to powodowa pojawienie si cikich do wykrycia bdw

    Systemy obiektowe korzystaj z dodatkowych wasnoci np. dziedziczenia, ktre powoduj dodawanie nowego kontekstu do budowanych blokw kodu. Moe to powodowa powstawanie bdw w przyszoci

  • Metody uyteczne w testowanie klas Prawie kada klasa posiada zmienne, ktre

    mog by efektywnie testowane z wykorzystaniem analizy wartoci granicznych, metody klas rwnowanoci

    Nie wszystkie metody s jednoczenie wykonywane przez oprogramowanie klienckie, testowanie pokrycia kodu jest uyteczne do zapewnienia, e kada metoda jest przetestowana

  • Metody uyteczne w testowaniu klas Kada klasa moe posiada metody, ktre

    posiadaj logik proceduraln, ktre testowanie z wykorzystaniem pokrycia rozgazie kodu, pokrycia warunkw i zoonoci kodu

    Poniewa obiekty klas mog by tworzone wielokrotnie przez rne oprogramowanie klienckie, wic mog by uyteczne rnego rodzaju testy obcieniowe

  • Zaoenia dla testowania klas Testowanie obiektu w caym jego okresie ycia

    od utworzenie a do zniszczenia Testowanie bardziej skomplikowanych metod

    po testach metod prostych Testowanie metod od prywatnych do

    publicznych Wysyanie komunikatw do kadej metody

    przynajmniej raz

  • Zaoenia do testowania klas Testowanie na pocztku konstruktorw

    gdy istnieje wiele sposobw inicjowania obiektw powinny by rwnie przetestowane

    Testowanie metod dostpowych Testowanie metod modyfikujcych pola

    skadowe klasy Testowanie niszczenia obiektu

    wszystkie zasoby przydzielone przez obiekt powinny by zwolnione

  • Testowanie integracyjne Systemy obiektowe s budowane z wielu

    maych komponentw testy integracyjne s dlatego bardzo istotne

    Komponenty systemw obiektowych s opracowywane rwnolegle wysza potrzeba testw integracyjnych

    Biorc pod uwag rwnoleg prac na komponentami systemu naley rwnie przetestowa dostpno klas podczas testw integracyjnych

  • Testy systemowe i wspdziaania Klasy mog skada si z wielu czci, ktre

    nie s uruchamiane w jednym czasie. Uycie danej czci moe powodowa bdy dopiero pniej

    Klasy mog by w rny sposb zestawiane przez oprogramowanie klienckie co moe prowadzi do nowych bdw

    Obiekt moe nie zwalnia wszystkich zasobw, problemy z tym zwizane mog by uwidocznione dopiero w czasie testw systemowych

  • Enkapsulacja i dziedziczenie Wprowadza dodatkowy kontekst, ktry naley

    uwzgldni w czasie testowania aplikacji Wykorzystywane testowanie inkrementacyjne

    Klasy abstrakcyjne Wymagaj ponownego przetestowania przy kadej

    zmianie interfejsu

  • Testowanie wasnoci klas Polimorfizm

    Kada metoda noszca t s sam nazw powinna by testowana oddzielnie

    Kopoty z utrzymaniem kodu Wizanie dynamiczne

    Konwencjonalne metody testowania pokrycia kodu zmodyfikowane na potrzeby testowania wizania dynamicznego

    Wysza moliwo powstawania pniejszych bdw

  • Testy waciwoci klas Komunikacja wewntrzna z wykorzystaniem

    komunikatw sekwencje komunikatw diagramy sekwencji

    Ponowne uycie obiektw i rwnolega implementacja klas czstsze testy integracyjne i regresyjne testy integracyjne i jednostkowe poczone ze sob potrzeba testowania interfejsw

  • Testowanie uytecznoci i dostpnoci

    Testy uytecznoci s subiektywne Postrzeganie dobrej uytecznoci zaley od

    uytkownika Interfejs uytkownika moe by stworzony w

    czasie projektowania systemu tworzenie interfejsu uytkownika nie wpywa jednak w bezporedni sposb na wymagania funkcjonalne stawiane aplikacji

  • Testowanie uytecznoci Uyteczno testuje si z punktu widzenia

    uytkownikw Sprawdza czy produkt jest atwy do uycia

    przez rne grupy uytkownikw Jest procesem sprawdzajcym rozbienoci

    pomidzy zaprojektowanym interfejsem a oczekiwaniami uytkownika

  • Testowanie uytecznoci atwo uycia

    moe by rna dla rnych grup uytkownikw Szybko dziaania

    zaley od wielu czynnikw np. systemowych czy sprztowych

    Estetyka aplikacji zalena od postrzegania aplikacji przez

    uytkownika

  • Testowanie uytecznoci Testowanie uytecznoci obejmuje

    aplikacj pozytywne i negatywne testowanie

    dokumentacj programu komunikaty aplikacji media z jakich korzysta aplikacja

  • Podejcia do uytecznoci Czynniki obiektywne w testowaniu uytecznoci

    np.: liczba klikni myszy liczba klawiszy do nacinicia liczba menu do przejcia liczba polece potrzebnych do wykonania zadania

  • Dopasowanie uytkownikw Dwie grupy najbardziej przydatne do

    testowania uytecznoci Typowi przedstawiciele aktualnej grupy

    uytkownikw umoliwiaj wyodrbnienie wzorcw korzystania z aplikacji

    Nowi uytkownicy nieposiadajcy przyzwyczaje mog zidentyfikowa problemy z uytecznoci niedostrzegalne przez uytkownikw korzystajcych z aplikacji duszy czas

  • Moment wykonania testw uytecznoci

    Planowanie Uwzgldnienie testw uytecznoci w planie testowania

    Projektowanie Projektowanie walidacji uytecznoci

    Kodowanie Testowanie uytecznoci

  • Projektowanie uytecznoci Arkusze stylw

    grupuj elementy interfejsu uytkownika zapewniaj spjno interfejsu uytkownika

    Prototypy ekranw aplikacji s projektowane tak jak bd wyglday dla

    uytkownika, bez poczenia z funkcjonalnoci produktu umoliwia odrbne testowanie

    symuluj wykonywanie rnych cieek programu wywietlanie komunikatw i okien

  • Projektowanie uytecznoci Projektowanie na papierze

    projekt okien aplikacji, ukadu elementw, menu narysowany na papierze jest wysyany do uytkownika w celu akceptacji

    Projektowanie layoutu pomocne przy ukadaniu rnorodnych elementw

    aplikacji na ekranie zmiana ukadu elementw aplikacji moe prowadzi

    do bdw uytkownika

  • Problemy z testowaniem uytecznoci

    Grupy uytkownikw posiadajce niezgodne ze sob wymagania

    Uytkownicy mog nie by w stanie wyrazi uycia produktu prowadzcych do problemw

    Rne grupy uytkownikw eksperci mog znajdowa obejcia istniejcych

    problemw pocztkujcy nie maj jeszcze odpowiedniej

    wiedzy o uyciu produktu

  • Testowanie uytecznoci Obserwacja wzorcw zachowania

    uytkownikw W jaki sposb uytkownicy wykonuj operacje w

    celu osignicia okrelonego zadania? Ile im zajmuje to czasu? Czy czas odpowiedzi systemu jest

    satysfakcjonujcy? W jakich okolicznociach napotykaj na problemy? Jak je omijaj? Jakie zachowania aplikacji powoduj zmieszanie

    uytkownika?

  • Czynniki jakoci uytecznoci Czytelno

    produkt i jego dokumentacja posiada prost i logiczn struktur

    operacje s grupowane na podstawie scenariuszy uzyskanych od uytkownika

    czsto wykonywane operacje s bardziej widoczne w interfejsie uytkownika

    komponenty programu uywaj terminologii uytkownika

  • Czynniki jakoci uytecznoci Spjno

    z uznanymi standardami wygldem aplikacji dla okrelonej platformy poprzednimi wersjami aplikacji innymi produktami danego producenta

    Nawigowalno atwo wyboru rnych operacji wykonywanych

    przed produkt np. minimalizacja liczby klikni myszy potrzebnych

    do wykonania operacji

  • Czynniki jakoci uytecznoci Czas odpowiedzi aplikacji

    szybko reakcji produktu na dania uytkownika rne od wydajnoci aplikacji

    np. wizualizacja ile procent danych zostao przetworzonych przez aplikacj

  • Testowanie estetyki Czsto subiektywne, zalene od odczu

    uytkownika Dotyczy wszelkich aspektw aplikacji

    zwizanych z jej wygldem kolorw, okien, komunikatw i obrazw

    Nie kady produkt musi by dzieem sztuki, wystarczy, e bdzie miy dla oka

  • Testowanie dostpnoci Oznacza testowanie aplikacji przez

    niepenosprawnych uytkownikw Dostarczanie dla tej grupy uytkownikw

    alternatywnych sposobw wykonywania operacji narzdzia wspierajce te operacje

    Podzia na: Podstawow dostpno dostarczana przez

    system operacyjny i sprzt Dostpno produktu

  • Planowanie testowania Wybr zakresu testowania wraz z identyfikacj

    co powinno by przetestowane a co mona nie testowa

    Wybr sposobu wykonania testw podzia zadania na mniejsze zadania i przyjcie strategii przeprowadzenia zadania

    Wybr zasobw jakie naley przetestowa zarwno komputerowe jak i te zwizane z ludmi

  • Planowanie testowania Przyjcie ram czasowych, w ktrych bd

    wykonywane testy Ocena ryzyka jakie musi by podjte z

    wykonaniem wczeniej wymienionych zada, wraz z odpowiednim planem awaryjnym i migracyjnym

  • Zasig testowania

    Wyodrbnienie podstawowych skadowych kocowego produktu

    Podzia produktu na zbir podstawowych skadowych

    Ustawienie priorytetw testw dla rnych aspektw oprogramowania

    Zadecydowanie co naley testowa a co nie Estymacja liczby zasobw potrzebnych do

    testowania na podstawie zebranych wczeniej danych

  • Wybr priorytetw Cechy, ktre s nowe i krytyczne dla nowego

    wydania produktu Spenienie oczekiwa uytkownika Spodziewane w nowym kodzie wiele nowych

    bdw Cechy, ktrych nieprawidowe dziaanie moe

    spowodowa katastrofalne skutki np. mechanizm odzyskiwania bazy danych

  • Wybr priorytetw Cechy oprogramowania, dla ktrych

    spodziewane jest skomplikowane testowanie Cechy, ktre s rozszerzeniem mechanizmw

    z obecnej wersji oprogramowania, ktre byy rdem wielu bdw

    Wymienione cechy rzadko mona zidentyfikowa jako wystpujce samodzielne, czciej spotykane s w rnych kombinacjach

  • Wybr strategii testowania Wybr testw potrzebnych do przetestowania

    funkcjonalnoci produktu Wybr konfiguracji i scenariuszy potrzebnych

    do testowania funkcjonalnoci produktu Wybr testw integracyjnych, koniecznych do

    sprawdzenie czy zestawienie elementw prowadzi do poprawnej ich pracy

    Wybr potrzebnej walidacji lokalizacji produktu Wybr koniecznych testw niefunkcjonalnych

  • Ustanowienie kryteriw testowania Wybr jasnych kryteriw dla danych testowych

    i dla spodziewanych wynikw Wybr warunkw, w ktrych testy powinny

    zosta wstrzymane Wykryto szereg bdw Napotkano na problem, ktry uniemoliwia dalsze

    testowanie Wydano now wersj, ktra ma na celu

    naprawienie bdw w obecnej wersji

  • Identyfikacja zakresu obowizkw, personelu i wymaga szkoleniowych Testowanie wymaga wymaga inynierw

    testowania, prowadzcych testy i managerw testowania

    Wyznaczenie: Obowizkw w celu wykonania okrelonego

    zadania Jasnej listy obowizkw dla czonkw personelu Wzajemnego uzupeniania zada personelu

    Szkolenia w razie braku odpowiednich umiejtnoci potrzebnych do wykonywania testw

  • Identyfikacja wymaga odnonie zasobw

    Wymagania sprztowe dla przeprowadzenie testw

    Liczby konfiguracji systemowych dla testowanego produktu

    Koszty oglne narzdzi potrzebnych do automatyzacji testw

    Narzdzia wspierajce kompilatory, generatory danych testowych itd

    Wymagana liczba licencji narzdzi potrzebnych do wykonania zadania

  • Identyfikacja dostarczanych wynikw testowania

    Planowanie samych testw Identyfikacja przypadkw testowych Przypadki testowe wraz z ich automatyzacj Logi wyprodukowane przez wykonane testy Raporty podsumowujce testy

  • Ocena rozmiaru i wysiku koniecznego do wykonania testw

    Ocena rozmiaru oszacowanie liczby koniecznych do wykonania testw rozmiar produktu przeznaczonego do testowania

    liczba linii kodu liczba punktw funkcyjnych liczba ekranw, raportw i transakcji

    zakres wymaganej automatyzacji liczba platform i rodowisk koniecznych do

    rozwaenia

  • Struktura podziau pracy Liczba przypadkw testowych Liczba scenariuszy testowych Liczba konfiguracji do przetestowania Czynniki wpywajce:

    Dane dotyczce produktywnoci Moliwoci ponownego uycia testw Odporno procesu

    Dobrze udokumentowane standardy, sprawdzone sposoby wykonania operacji, obiektywne metody mierzenia efektywnoci

  • Podzia i planowanie dziaa Identyfikacja zewntrznych i wewntrznych

    zalenoci Ustalenie kolejnoci dziaa bazujc na

    spodziewanym czasie trwania dziaania Identyfikacja czasu dla kadego dziaania Monitorowanie postpu zarwno pod wzgldem

    czasu jak i wykonanego wysiku Jeli konieczne zmiana planw i zasobw

  • Zarzdzanie ryzykiem Identyfikacja potencjalnego ryzyka Pomiar potencjalnego ryzyka

    Prawdopodobiestwo wystpienia Potencjalny wpyw

    Planowanie sposobw zagodzenia ryzyka Odpowied na realnie wystpujce ryzyko

  • Problemy Niejasne wymagania Zalenoci pomidzy zadaniami w planie Niewystarczajcy czas dla testowania Wystpowanie defektw blokujcych prac Obecno testerw z odpowiednimi

    umiejtnociami i motywacj Brak narzdzi automatyzujcych testowanie

  • Zarzdzanie testami Wybr standardw

    Konwencje nazewnictwa Standardy dokumentowania testw Standardy kodowania i raportowania testw

    Zarzdzanie infrastruktur testw baza danych przypadkw testowych, repozytorium bdw, narzdzia konfiguracyjne

    Zarzdzanie ludmi Synchronizacja testw z planami wydania

  • Proces testowania Specyfikacja przypadku testowego

    Cel testu Elementy testowane Konieczne rodowisko uruchomieniowe Dane wejciowe dla testu Kroki potrzebne do wykonania testu Spodziewane wyniki Kroki potrzebne do porwnania wynikw z

    spodziewanymi wynikami Relacje pomidzy testem a innymi testami

  • Proces testowania Aktualizacja macierzy ledzenia Identyfikacja potencjalnych kandydatw dla

    automatyzacji Zaprogramowanie i przyczenie przypadkw

    testowych Wykonanie przypadkw testowych Zbieranie i analiza metryk Przygotowanie raportu podsumowywujcego

  • Raporty z testw Raporty wykonania testu Raporty z cyklw testowania Raporty podsumowujce testowanie

    Zalene od fazy testowania, tworzone po wykonaniu kadej fazy testowania

    Raporty kocowe

  • Automatyzacja testw Automatyzacja pozwala zaoszczdzi czas

    testy mog by uruchamiane i wykonywane szybciej. Umoliwia to: zaprojektowanie dodatkowych przypadkw

    testowych umoliwiajcych np. lepsze pokrycie kodu

    wykonanie bardziej skomplikowanych testw np. testw doranych

    przeprowadzenie dodatkowe testy manualne

  • Automatyzacja testw Automatyzacja uwalnia testerw od

    przyziemnych zada i pozwala wykorzysta zaoszczdzony czas na bardziej produktywne zajcia

    Testowanie automatyczne moe by bardziej wiarygodne Wiksza moliwo powstawania pomyek przy

    rcznym uruchomieniu testw

  • Automatyzacja testw Automatyzacja pomaga w bezporednim

    testowaniu Nie ma duej przerwy pomidzy programowaniem

    a testami Automatyzacja pozwala ochroni organizacj

    przed wypaleniem zawodowym inynierw testowania Lepszy transfer umiejtnoci pomidzy testerami Testy staj si mniej zalene od konkretnych

    testerw

  • Automatyzacja testw Automatyzacja otwiera moliwo lepszego

    wykorzystania globalnych zasobw Testy mog by uruchamiane przez wikszo

    czasu w rnych strefach czasowych Niektre testy nie mog by uruchomione

    bez automatyzacji np. testy obcieniowe i wydajnociowe systemu

    wymagajcego zalogowania tysicy uytkownikw

  • Automatyzacja testowania Nagrywanie i odtwarzanie

    Nagrywanie czynnoci uytkownika kliknicia mysz, akcje wykonywane klawiatur i ich pniejsze odtwarzanie w tej samej kolejnoci atwe nagrywanie i odtwarzanie skryptw Skrypty mog by odtwarzane wielokrotnie Wartoci wprowadzane rcznie moe by trudne

    uzyskanie oglnych skryptw

  • Automatyzacja skryptw Testy sterowane danymi

    Metoda pozwala na generowanie testw na podstawie zestaww danych wejciowych i wyjciowych

    Testy sterowane akcjami Wszystkie akcje jakie mog by wykonane przez

    aplikacje s generowane automatycznie na podstawie zbioru kontrolek jakie zostay zdefiniowane do testowania

  • Identyfikacja testw podatnych na automatyzacj

    Testowanie wydajnoci, niezawodnoci, obcieniowe Testy wymagajce wielu uytkownikw i duego

    czasu przeznaczonego na ich wykonanie Testowanie regresyjne

    Powtarzalne, uruchamiane wielokrotnie Testowanie funkcjonalne

    Moe wymaga skomplikowanych przygotowa automatyzacja umoliwi uruchamianie przygotowanych przez ekspertw testw mniej dowiadczonym testerom

  • Automatyzacja testowania Automatyzacja powinna by rozwaana przede

    wszystkim dla elementw, ktre nie zmieniaj si lub zmieniaj si rzadko

    Automatyzacja testw, ktre odnosz si do zgodnoci z standardami np. czy dane oprogramowanie spenia wymagania stawiane jakiemu ustandaryzowanemu protokoowi

  • Architektura dla automatyzacji testowania

    Moduy zewntrzne Baza przypadkw testowych Baza bdw

    Moduy plikw konfiguracyjnych i scenariuszy Scenariusze informacja jak uruchomi okrelony

    test Pliki konfiguracyjne zawieraj zbir zmiennych

    uywanych w automatyzacji

  • Architektura dla automatyzacji oprogramowania

    Moduy przypadkw testowych i frameworku testowego Przypadki testowe wzite z bazy przypadkw

    testowych Przypadki testowe s wykonywane dla innych

    moduw, nie przeprowadzaj adnych interakcji Framework testowy czy przypadek testowy

    z sposobem jego wykonania Framework testowy jest rdzeniem architektury

    automatyzacji testowania

  • Architektura dla automatyzacji oprogramowania

    Moduy narzdzi i wynikw Narzdzia wspieraj proces tworzenia przypadkw

    testowych Wyniki s zachowywane w celu dalszej analizy,

    umoliwiaj rwnie przygotowanie przypadkw testowych dla dalszych faz tworzenia oprogramowania

    Moduy generacji raportw i metryk Generowanie raportw podsumowujcych dan

    faz testowania oprogramowania

  • Wymagania stawiane testom Brak ustawionych na sztywno wartoci dla

    zestaww testowych Zestawy testowy powinny mie moliwo

    dalszej rozbudowy Dodany test nie powinien wpywa na inne

    przygotowane wczeniej testy Dodanie nowego testu nie powinno wymaga

    ponownego przeprowadzenia ju przeprowadzonych testw

    Dodanie zestawu testowego nie powinno wpywa na inne zestawy testowe

  • Wymagania stawiane testom Zestawy testowe powinny mie moliwo

    ponownego uycia Test powinien robi jedynie to co jest spodziewane,

    e robi Testy powinny by modularne

    Automatyczne ustawianie i czyszczenie po tecie

    Niezaleno przypadkw testowych

  • Wymagania stawiane testom Izolacja testw w czasie wykonania

    Elementy rodowiska mog wpywa na wyniki testw blokowanie niektrych zdarze

    Standardy kodowania i struktury katalogowej Uatwia zrozumienie nowy pracownikom

    przypadkw testowych Uatwia przenoszenie kodu pomidzy platformami Wymuszenie struktury katalogowej moe uatwi

    zrwnoleglenie testw

  • Wymagania stawiane testom Selektywne wykonanie przypadkw testowych

    Uatwienie w wyborze z: Wiele zestaww testowych wielu programw testujcych wielu przypadkw testowych

    Losowe wykonanie przypadkw testowych Wybr niektrych testw z zestawu przypadkw

    testowych Rwnolege wykonanie przypadkw testowych

  • Wymagania stawiane testom Zaptlenie przypadkw testowych

    Testy wykonywane iteracyjnie dla znanej z gry liczby iteracji

    Testy wykonywane w okrelonym przedziale czasu Grupowanie przypadkw testowych

    Umoliwia wykonanie testw w przedefiniowanej kombinacji scenariuszy

    Wykonanie przypadkw testowych w oparciu na wczeniejsze wyniki

  • Wymagania stawiane testom Zdalne wykonanie przypadkw testowych

    Testy mog wymaga wicej ni jednej maszyny do ich uruchomienia

    Umoliwienie uruchomienia testw, zbieranie logw, informacji o postpie testw

    Automatyczne zachowywanie danych testowych

    Schematy raportowania Jakie informacje maj by uwzgldnione w

    raportcie

  • Wymagania stawiane testom Niezaleno od jzyka

    Framework testowy niezaleny od jzyka programowania

    Framework powinien dostarcza interfejsw dla najpopularniejszych jzykw

    Przenono na rne platformy sprztowe, systemowe

  • Metryki przydatne przy testowaniu Metryki wyprowadzaj informacje z surowych

    danych w celu uatwienia podejmowanie decyzji Relacje pomidzy danymi Przyczyny i efekty korelacji pomidzy

    zaobserwowanymi danymi Wskaniki jak dane mog by uyte w dalszym

    planowaniu i ulepszaniu produktu

  • Metryki Odpowiednie parametry musz by mierzone,

    parametry dotyczce produktu lub procesu jego tworzenia.

    Waciwa analiza musi by wykonana na mierzonych danych w celu wyprowadzenia poprawnych konkluzji dotyczcych poprawnoci produktu lub procesu

    Wyniki analizy musz by zaprezentowane w odpowiedniej formie dla zainteresowanych stron w celu podjcia waciwych decyzji

  • Metryki Wysiek czas spdzony na jakiej czciowej

    aktywnoci lub fazie. Kroki w zdobywaniu metryki programu

    Identyfikacji tego co naley zmierzy Transformacja tego co zostao zmierzone do

    metryki Podjcie decyzji co do wymaga operacyjnych Wykonanie analiz metryk Wybr i wykonanie akcji Sprecyzowanie miar i metryk

  • Wybr miar To co jest mierzone powinno by dobrane

    odpowiednio do zamierzonych celw (wysiek powicony na testowanie, liczba przypadkw testowych, liczba raportowanych bdw).

    Mierzone wielkoci powinny by naturalne i nie powinny powodowa nadmiernych kosztw.

    To co jest mierzone powinno by na waciwym poziomie ziarnistoci w celu osignicia celw dla ktrych pomiar jest dokonywany.

  • Przydatno metryk w testowaniu Mierzenie postpu w testowaniu

    Produktywno wykonywanych testw Data zakoczenia testw (oszacowana)

    Na podstawie ilorazu liczby testw do wykonania przez liczb testw wykonywanych na dzie

    Liczba dni potrzebnych na usunicie bdw (liczba bdw do usunicia + liczba przewidywanych

    bdw) / zdolno usuwania bdw

  • Przydatno metryk w testowaniu Oszacowanie daty wydania finalnej wersji

    Max (liczba dni potrzebnych na testy, liczba dni potrzebnych do usunicia bdw)

    Oszacowanie jakoci wydanego oprogramowania Wybr elementw jakie powinny by wzite pod

    uwag w planowaniu wydania oprogramowania

  • Typy metryk Metryki projektu jak projekt jest planowany

    i wykonywany Metryki postpu ledzce jak wyglda postp

    w rnych rodzajach dziaalnoci zwizanych z projektem Aktywno zwizana z programowaniem Aktywno zwizana z testowaniem

    Metryki produktywnoci zbierajce rnego rodzaju miary, ktre maj wpyw na planowanie testowania

  • Typy metryk Metryki projektu

    Wariancja woonego wysiku Wariancja harmonogramu Rozkad wysiku

    Metryki postpu Wskanik odnalezionych bdw Wskanik naprawionych bdw Wskanik pozostajcych bdw Wskanik priorytetu pozostajcych bdw

  • Typy metryk Trend bdw Waony trend bdw

    Metryki produktywnoci Liczba bdw na 100 godzin testowania Liczba przypadkw testowych na 100 godzin

    testowania Liczba zaimplementowanych przypadkw

    testowania na 100 godzin Liczba bdw na 100 przypadkw testowych

  • Metryki projektu Rnego rodzaju aktywnoci, podstawowy

    wkad do projektu i harmonogram prac s wejciem dla pocztku projektu

    Aktualny wkad i czas powicony na dziaalno s dodawane w miar jak jest rozwijany projekt.

    Skorygowany wkad i harmonogram ponownie obliczane, gdy jest to potrzebne

  • Wariancja wysiku Podstawowa estymacja wysiku, uaktualniona

    estymacja wysiku i aktualny wysiek Wariancja % = (Aktualny wysiek

    Uaktualniony oszacowany wysiek)/Uaktualniony oszacowany wysiek * 100

    Wariancja wiksza od 5 % oznacza, e naley poprawi estymacj

    Moe by ujemna w przypadku przesacowania

  • Wariancja harmonogramu Zgodno wykonywanych zada z

    harmonogramem Podobnie jak poprzednia metryka jest

    odchyleniem aktualnego harmonogramu od harmonogramu oszacowanego

    Akceptowalny poziom to 0 5 %

  • Metryki postpu Pozwalaj oceni jak wyglda sprawa postpu

    w spenianiu wymaga jakoci oprogramowania Gwnym wskanikiem jakoci oprogramowania

    liczba bdw oprogramowania znalezionych i oszacowanych, e pozostaj w oprogramowaniu

    Pozwalaj oceni jak bdy wpywaj na oprogramowanie

  • Metryki postpu

    Dotkliwo bdu Co miara oznacza1 Dotyka podstawowej funkcjonalnoci2 Niespodziewany bd lub niepracujca

    funkcjonalno3 Dotyka mniej znaczcej funkcjonalnoci4 Problem kosmetyczny

    Priorytet Co miara oznacza1 Najwyszy poziom (przed nastpn

    wersj)2 Wysoki poziom(przed nastpnym cyklem

    testowania)3 redni poziom (jeli czas pozwoli

    usunicie przed wydaniem produktu)4 Niski poziom (mona odoy usunicie)

  • Metryki produktywnoci cz kilka miar i parametrw z wysikiem

    woonym w powstawanie produktu Pomagaj w:

    Estymacji czasu pojawienia si produktu Estymacji liczby bdw Estymacji jakoci Estymacji kosztw

  • Metryki produktywnoci Pozwalaj sprawdzi:

    efektywno testowania czy wzrasta jako produktu czy czas powicony na testowanie nie jest

    marnowany

    Slajd 1Slajd 2Slajd 3Slajd 4Slajd 5Slajd 6Slajd 7Slajd 8Slajd 9Slajd 10Slajd 11Slajd 12Slajd 13Slajd 14Slajd 15Slajd 16Slajd 17Slajd 18Slajd 19Slajd 20Slajd 21Slajd 22Slajd 23Slajd 24Slajd 25Slajd 26Slajd 27Slajd 28Slajd 29Slajd 30Slajd 31Slajd 32Slajd 33Slajd 34Slajd 35Slajd 36Slajd 37Slajd 38Slajd 39Slajd 40Slajd 41Slajd 42Slajd 43Slajd 44Slajd 45Slajd 46Slajd 47Slajd 48Slajd 49Slajd 50Slajd 51Slajd 52Slajd 53Slajd 54Slajd 55Slajd 56Slajd 57Slajd 58Slajd 59Slajd 60Slajd 61Slajd 62Slajd 63Slajd 64Slajd 65Slajd 66Slajd 67Slajd 68Slajd 69Slajd 70Slajd 71Slajd 72Slajd 73Slajd 74Slajd 75Slajd 76Slajd 77Slajd 78Slajd 79Slajd 80Slajd 81Slajd 82Slajd 83Slajd 84Slajd 85Slajd 86Slajd 87Slajd 88Slajd 89Slajd 90Slajd 91Slajd 92Slajd 93Slajd 94Slajd 95Slajd 96Slajd 97Slajd 98Slajd 99Slajd 100Slajd 101Slajd 102Slajd 103Slajd 104Slajd 105Slajd 106Slajd 107Slajd 108Slajd 109Slajd 110Slajd 111Slajd 112Slajd 113Slajd 114Slajd 115Slajd 116Slajd 117Slajd 118Slajd 119Slajd 120Slajd 121Slajd 122Slajd 123Slajd 124Slajd 125Slajd 126Slajd 127Slajd 128Slajd 129Slajd 130Slajd 131Slajd 132Slajd 133Slajd 134Slajd 135Slajd 136Slajd 137Slajd 138Slajd 139Slajd 140Slajd 141Slajd 142Slajd 143Slajd 144Slajd 145Slajd 146Slajd 147Slajd 148Slajd 149Slajd 150Slajd 151Slajd 152Slajd 153Slajd 154Slajd 155Slajd 156Slajd 157Slajd 158Slajd 159Slajd 160Slajd 161Slajd 162Slajd 163Slajd 164Slajd 165Slajd 166Slajd 167Slajd 168Slajd 169Slajd 170Slajd 171Slajd 172Slajd 173Slajd 174Slajd 175Slajd 176Slajd 177Slajd 178Slajd 179Slajd 180Slajd 181Slajd 182Slajd 183Slajd 184Slajd 185Slajd 186Slajd 187Slajd 188Slajd 189Slajd 190Slajd 191Slajd 192Slajd 193Slajd 194Slajd 195Slajd 196Slajd 197Slajd 198Slajd 199Slajd 200Slajd 201Slajd 202Slajd 203Slajd 204Slajd 205Slajd 206Slajd 207