Efektywne tworzenie oprogramowania 2008/2009

55
Efektywne tworzenie oprogramowania 2008/2009 cvs.ii.uni.wroc.pl/ eto2008

description

Efektywne tworzenie oprogramowania 2008/2009. cvs.ii.uni.wroc.pl/eto2008. Testowanie. Rodzaje testów Przypadki testowe Reguły i wzorce TDD. Liczba przypadków testowych. Ile przypadków testowych wystarczająco przetestuje program „trójkąt” - PowerPoint PPT Presentation

Transcript of Efektywne tworzenie oprogramowania 2008/2009

Page 1: Efektywne tworzenie oprogramowania 2008/2009

Efektywne tworzenie oprogramowania

2008/2009

cvs.ii.uni.wroc.pl/eto2008

Page 2: Efektywne tworzenie oprogramowania 2008/2009

Testowanie

• Rodzaje testów• Przypadki testowe• Reguły i wzorce• TDD

Page 3: Efektywne tworzenie oprogramowania 2008/2009

Liczba przypadków testowych

• Ile przypadków testowych wystarczająco przetestuje program „trójkąt”– wszystkie ważne dane; trójki wszystkich liczb

dodatnich– wszystkie niepoprawne dane

• Dla wielu nawet trywialnych programów, liczba możliwych przypadków testowych jest nieskończona

Page 4: Efektywne tworzenie oprogramowania 2008/2009

Cel testowania

• Udowodnienie, że program działa– Nie można tego zrobić; „testowanie nie

udowodni braku błędów, może tylko udowodnić istnienie błędów” (Dijkstra)

• Udowodnienie, że program nie działa– Wiedza o tym gdzie są błędy jest użyteczna

• Znalezienie wszystkich błędów• Informacja – może być pomocna dla

poprawy jakości

Page 5: Efektywne tworzenie oprogramowania 2008/2009

Cel testowania

• Ocena jakości systemu– implikuje pokrycie testami

• Ukierunkować wysiłki > podniesienie jakości– wykorzystanie gęstości wystąpienia błędów

• Redukcja zakresu ryzyka problemów

Page 6: Efektywne tworzenie oprogramowania 2008/2009

Testowanie

• Najtrudniejsza decyzja

– Co nie testować?

Page 7: Efektywne tworzenie oprogramowania 2008/2009

Istota testowania

• Metoda białej skrzynki– patrzysz na kod– wykorzystujesz wiedzę o implementacji– efektywna technika – inspekcja kodu

• Metoda czarnej skrzynki– oparcie na wymaganiach– brak wiedzy o implementacji

• Twórca oprogramowania a tester

Page 8: Efektywne tworzenie oprogramowania 2008/2009

Metoda czarnej skrzynki + i –

• Bazuje na doświadczeniu użytkownika• Można testować system jako całość• Można testować aspekty niefunkcjonalne

– moc, użyteczność• Łatwo opuścić rzeczy, takie jak przypadki

testowe• Często trzeba czekać na zakończenie

całego systemu

Page 9: Efektywne tworzenie oprogramowania 2008/2009

Metoda białej skrzynki + i –

• Można pokryć cały kod– i dostać się do niedostępnego kodu

• Może być wykorzystana bardzo szybko– w czasie kodowania

• Łatwo mierzyć postęp testowania• Testy pisane po napisaniu kodu• Nie można testować kodu, którego nie ma

Page 10: Efektywne tworzenie oprogramowania 2008/2009

Kto jest testerem?

• Twórcy– testują w czasie gdy tworzony jest kod– testują moduły

• Dedykowani testerzy– poziom systemu

• Potrzebni obaj

Page 11: Efektywne tworzenie oprogramowania 2008/2009

Cechy twórcy i testeraTwórca Tester

Optymista Pesymista

Konstruktywny Destruktywny

Oczekuje, że kod działa Wie, że kod zostanie złamany

Wystarczy kilka testów Wystarczy pełne pokrycie

Nagradzany za napisanie kodu

Nagradzany za jakość

Nie wie jak testować Wie jak testować

Page 12: Efektywne tworzenie oprogramowania 2008/2009

Test Driven Development

• Testowanie przez twórców pomaga ulepszyć jakość

• Nie można zastąpić całego testowania• TDD jest sposobem na testowanie przez

twórcę

Page 13: Efektywne tworzenie oprogramowania 2008/2009

Test Driven Development - przegląd

• Napisz test• Uruchom test• Napisz kod, aby zaimplementować test • Powtórz ostatnie 2 kroki dopóki wszystkie

testy nie będą działać• Jeśli potrzeba, to refaktoryzujRób to systematycznie

Page 14: Efektywne tworzenie oprogramowania 2008/2009

Zasady testowania (Harrison)1. Nie można całkowicie przetestować

• nie próbuj tego• wybierz najbardziej efektywne testy

2. Powtórne wykonywanie tego samego testu „aby się upewnić” – n i e

• zabronić duplikowania testów3. Al Capone

• uruchamiaj testy tam, gdzie błędy najprawdopodobniej wystąpią

Page 15: Efektywne tworzenie oprogramowania 2008/2009

Gdzie są błędy?

• Gdzie z dużym prawdopodobieństwem wystąpią błędy?– nowy kod– granice– ograniczenia zasobów (pamięć, czas

rzeczywisty)– duża złożoność

Page 16: Efektywne tworzenie oprogramowania 2008/2009

Zasady testowania (Harrison) - 2

• Drzewo w lesie (jeśli padnie nikt nie słyszy)

– Czy jeśli jest błąd w kodzie i użytkownik go nie odkryje, to jest to błąd (bug)?

– Należy skoncentrować się bardziej na załamaniach (failures) niż usterkach (faults)

Page 17: Efektywne tworzenie oprogramowania 2008/2009

Załamania i usterki

• Usterka (fault): defekt w kodzie• Załamanie (failure): niezgodność między

tym co użytkownik oczekiwał a tym co robi oprogramowanie

• Usterki powodują błędy, ale:– nie wszystkie usterki powodują załamania

• Koncentrujmy się (częściej) na załamaniach (testowanie metoda czarnej skrzynki)

Page 18: Efektywne tworzenie oprogramowania 2008/2009

Myśl jak tester

• Wskazówki (wzorce), które pomagają myśleć trochę inaczej niż typowy twórca– wykorzystaj testy oparte na przypadkach

użycia (to nie są historyjki użytkownika)– tester pokrywa rozszerzenia przypadków

użycia– napisz testy z przypadków użycia (nie kodu,

który implementuje te przypadki) – najlepiej przed napisaniem kodu

Page 19: Efektywne tworzenie oprogramowania 2008/2009

Fragmenty funkcjonalności

• Nie można uruchomić wszystkich możliwych testów

• Podziel kod na fragmenty o równoważnej funkcjonalności– Testuj każdy równoważny fragment raz– Nazwij klasy równoważności

Page 20: Efektywne tworzenie oprogramowania 2008/2009

Magiczne granice

• Ciekawe rzeczy dzieją się na rogach– Testuj więc po obu stronach granic

Page 21: Efektywne tworzenie oprogramowania 2008/2009

Trójka – W (Wykonuj Wyjątki Wyczerpująco)

• Błędy skupiają się wokół nietypowych zachowań

• Łatwo o nich zapomnieć• Pisz testy pokrywające wyjątkowe

zachowania– określ wyniki przed uruchomieniem testów

Page 22: Efektywne tworzenie oprogramowania 2008/2009

Wzorce użytkownika• Użytkownicy – kreatywni idioci

– użytkownicy mogą robić rzeczy nieoczekiwane– dlatego sprawdź rzeczy, o których „wiesz”, że

użytkownicy nie zrobią• Uwaga

– Zwykle testujemy scenariusze „słoneczna droga”– Użytkownicy - kreatywni idioci oznacza

przypadkowe, nielegalne zachowanie

Page 23: Efektywne tworzenie oprogramowania 2008/2009

Niemożliwe

– Niemożliwe może być możliwe– Rozważ testowanie warunków niemożliwych

• Nie musisz testować ich wszystkich

– Koncentruj się na niemożliwych warunkach, włączając dane z innych systemów

– Pamiętaj, że częścią każdego testu jest oczekiwany wynik

Page 24: Efektywne tworzenie oprogramowania 2008/2009

Przepełnienie

• Czy są ograniczenia?– BD, użytkownicy, moc, itp…

• Jeśli tak, to testuj powyżej ograniczeń– Na pewno ktoś to spróbuje– Zachowanie może „zagwoździć” system

• Myśl o limitach swojej części (przy testach systemu)

• Co kod powinien robić w sytuacji przekroczenia zasobów?

Page 25: Efektywne tworzenie oprogramowania 2008/2009

Lepszy projekt

• Przed kodowaniem spędź trochę czasu projektując testy– Kluczowe pytanie: jaki powinien być wynik?

• Rozważ zachowanie specjalnie dla nietypowych przypadków

• Pomaga to myśleć o przypadkach, których w przeciwnym razie nie rozważyłoby się

Page 26: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 1

Piszesz podsystem zarządzania magazynem dla aplikacji e-commerce

• Jakich wzorców – zasad użyjesz?

• Napisz pytania dotyczące wymagań

Page 27: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 1 - odpowiedzi• Wzorzec – części przypadków użycia• Magiczne granice – gdy brak jednostek• 3-W – załamanie b.d., przerwanie połączenia z

klientem• Niemożliwość – nielegalne zapytania, źle

sformatowane żądania• Powtarzanie – wielokrotne żądania tej samej

jednostki• Przepełnienie – maximum równoczesnych

żądań

Page 28: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 1 - odpowiedzi

Pytania dotyczące wymagań: co powinien zrobić kod, gdy:

• B.d. jest pełna• Wystąpi załamanie b.d.• Zostanie przerwane połączenie z klientem• Otrzyma złe żądanie• Nie ma jednostki towaru• Jest wiele współzawodniczących wątków

Page 29: Efektywne tworzenie oprogramowania 2008/2009

Eleganckie testowanie - automatyzacja

• Wybierz narzędzie• Zastosuj poznane zasady• Są plusy i minusy

Automatyzacja nie jest panaceum

Page 30: Efektywne tworzenie oprogramowania 2008/2009

Automatyzacja - korzyści

• Szybkie wykonywanie• Automatyczne zapisywanie wykonania

testów i wyników• Powtarzalne

– Dla twórców szukających błędów– Testowanie regresyjne

Page 31: Efektywne tworzenie oprogramowania 2008/2009

Automatyzacja - straty• Można testować źle szybko• Nie gwarantuje dobrego pokrycia

– Nawet z narzędziami analizy pokrycia• Rozrastają się zbiory testów

– Może być to połowa lub więcej kodu• Testy także są kodem

– Pielęgnacja (nakład, martwy kod)• Testy też mogą mieć błędy

Page 32: Efektywne tworzenie oprogramowania 2008/2009

Techniki projektowania testów

• Nie można testować wszystkiego• Testujmy inteligentnie

– gdzie jest największe prawdopodobieństwo wystąpienia błędów

– gdzie wpływ użytkownika jest największy– z minimalną zbędną duplikacją

• jak najmniej testów z jak największym pokryciem

Page 33: Efektywne tworzenie oprogramowania 2008/2009

Techniki projektowania testów – klasy równoważności

• Minimalizacja testów redundantnych• Gdy system zachowuje się tak samo dla

danego zbioru danych, to są one równoważne– więc korzystaj dla nich tylko z jednego testu

Page 34: Efektywne tworzenie oprogramowania 2008/2009

Techniki projektowania testów – klasy równoważności - kroki

• Zidentyfikuj grupy lub klasy danych dla których zachowanie jest takie samo

• Napisz jeden test dla każdej równoważnej klasy– nie zapomnij o oczekiwanym zachowaniu

Page 35: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 2System biletowy• Filmy wyświetlane pierwszy raz:

– wieczorem: 14,00– popołudniówka: 10,00

• Stare filmy:– wieczór: 12,00– zniżka: 9,00– popołudniówka: 8,00

Page 36: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 2 - odpowiedzi• Filmy po raz pierwszy, wieczór

– Przypadek testowy: Misja, 19:30, oczekiwane 14,00• Filmy po raz pierwszy, popołudniówka

– podobne przypadki testowe• Starsze, wieczór• Starsze, zniżka• Starsze, popołudniówka• Nielegalny/nierozpoznawalny typ filmu• Nielegalny czas filmu

– przypadek testowy: Misja, 24:30, oczekiwany „ERROR”

Page 37: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 3 Kraj i waluta:• EU vs. nie-EU

– kraje Unii Europejskiej• kraje EU: waluta

– UK: funt– Dania: korona– Inne kraje: euro

• kraje nie-EU:– ich własna waluta

• kraje nie rozpoznawane przez ten system

Page 38: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 3 – odpowiedzi:

• EU, UK• EU, Dania

– najlepiej: różny od EU, od testu UK– ponieważ: wartość konwersji inna niż UK

• EU waluta (podległych) państw• Kraje nie-EU

– najlepiej: 1 dla każdego państwa• Nielegalne lub nierozpoznawalne państwo

Page 39: Efektywne tworzenie oprogramowania 2008/2009

Klasy równoważności

• Stosujemy, gdy:– są to naturalne grupy

• i ich zachowanie jest takie samo– mamy ograniczone wykorzystanie zakresów

numerycznych• technicznie - mamy następny element

Page 40: Efektywne tworzenie oprogramowania 2008/2009

Plusy i minusy

• Silna technika redukowania przypadków testowych

• Ogólnie łatwa do wykonania• Można jednak, w kodzie, łatwo pominąć

wyjątki

Page 41: Efektywne tworzenie oprogramowania 2008/2009

Testowanie wartości granicznych

• Odpowiednie dla wartości numerycznych• Niejawnie zawiera klasy równoważności• Błędy mają tendencję występowania w

rogach– testujemy tam– powyżej, poniżej

Page 42: Efektywne tworzenie oprogramowania 2008/2009

Kroki

• Identyfikujemy klasy równoważności• Dla każdej granicy (numerycznej)

– piszemy test poniżej jej– piszemy test powyżej jej– jeśli odpowiednie, to dokładnie dla granicy

Page 43: Efektywne tworzenie oprogramowania 2008/2009

Co oznacza „bezpośrednio”?

• O 1 jednostkę dalej– Dla jednostki, którą używamy

• całkowite: proste• zmiennopozycyjne: trudne

– może zależeć od kompilatora– na ogół: sami decydujemy o sensownej dokładności

Page 44: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 4

Zdefiniować „jedną jednostkę” dla:• waluty USA• wieku (np. dla zniżki biletowej)• daty ważności• czasu

Page 45: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 4 - odpowiedziZdefiniować „jedną jednostkę” dla:• waluty USA

– jeden cent• wieku (np. dla zniżki biletowej)

– jeden rok• daty ważności

– jeden dzień• Czasu

– zależy od tego do czego to będzie wykorzystane

Page 46: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 5 – ceny biletów

• Poniżej 5: bezpłatnie• Dzieci w wieku 5 do 12: 5,00• Uczniowie w wieku 13 do 18: 7,50• Starsi w wieku 18 do 64: 10,00• Seniorzy w wieku 65 do 80: 7,00

Page 47: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 5 - odpowiedziPrzypadki:• -1 (błąd)• 0 (bezpłatnie)• 4 (bezpłatnie)• 5 (5,00)• 12 (5,00)• 13 (7,50)• 18 (niejednoznaczna specyfikacja)• 64 (10,00)• 65 (7,00)• 80 (7,00)• 81 (brak w specyfikacji)

Page 48: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 6 - Wyprzedaż

• Tylko jedno wymaganie: Jeśli kupisz za 10 lub więcej dolarów, to otrzymasz 10% zniżki

Page 49: Efektywne tworzenie oprogramowania 2008/2009

Ćwiczenie 6 - OdpowiedziPrzypadki:• -0,01 (błąd)• 0,00 (nie ma sprzedaży)• 0,01 (0,01)• 9,99 (9,99)• 10,00 (9,00)• 10,04 (9,00)• 10,05 (9,01 – niejednoznaczna specyfikacja)• Czy jest maksimum? Ograniczenie przez

rozmiar danych w komputerze

Page 50: Efektywne tworzenie oprogramowania 2008/2009

Siła Test Driven Development

• Naprzód piszemy test• Automatyzujemy testy – proste• Często wykonujemy testy

– Systematycznie pokrywamy – Systematycznie rozpatrujemy błędne

przypadki– Niewielkie testy – dobry projekt – minimum

refaktoryzacji

Page 51: Efektywne tworzenie oprogramowania 2008/2009

Kroki w TDD

• Projektuj przypadki testowe w oparciu o:– przypadki użycia– klasy równoważności, wartości graniczne– wykorzystaj zasady/wzorce jako przewodniki

• Wykorzystuj przypadki testowe jako przewodnik projektowania

• Implementuj test i koduj jak zwykle– Można rozważać więcej niż jeden test

Page 52: Efektywne tworzenie oprogramowania 2008/2009

Krótki przykład public void testRating()

{ assertEquals(”Bad”,4,starWars.getAverageRating());

};

Ustawiamy stan, aby asercja zachodziła

public void testRating(){ starWars.addRating(3); starWars.addRating(5); assertEquals(”Bad”,4,starWars.getAverageRating()); };

• D. Astels, TDD, Prentice hall, 2003

gurbiel
Page 53: Efektywne tworzenie oprogramowania 2008/2009

TDD – przykład (2)public void testRating(){ Movie starWars = new Movie(”Star Wars”); starWars.addRating(3); starWars.addRating(5); assertEquals(”Bad”,4,starWars.getAverageRating()); };

Page 54: Efektywne tworzenie oprogramowania 2008/2009

TDD – przykład (3)public void testRating(){ Movie starWars = new Movie(”Star Wars”); starWars.addRating(3); starWars.addRating(5); assertEquals(”Bad”,4,starWars.getAverageRating()); };

public void addRating(int newRating){}

public void getAvarageRating(){ return 0;}

Page 55: Efektywne tworzenie oprogramowania 2008/2009

Projekty

Do 12.XI.2008 (godz 13:00) na stronie cvs.ii.uni.wroc.pl/eto2008pojawi się informacja o nazwie zespołu i

adresie strony projektu.Na stronie projektu znajdą się podstawowe

informacje (skład zespołu, dzienniki, adresy, plan, temat projektu itp.)