Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
OpublikowałJadzia Brzeski Został zmieniony 11 lat temu
1
Efektywne tworzenie oprogramowania 2008/2009 cvs.ii.uni.wroc.pl/eto2008
2
Testowanie Rodzaje testów Przypadki testowe Reguły i wzorce TDD
3
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
4
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
5
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
6
Testowanie Najtrudniejsza decyzja –Co nie testować?
7
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
8
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
9
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
10
Kto jest testerem? Twórcy –testują w czasie gdy tworzony jest kod –testują moduły Dedykowani testerzy –poziom systemu Potrzebni obaj
11
Cechy twórcy i testera TwórcaTester OptymistaPesymista KonstruktywnyDestruktywny Oczekuje, że kod działaWie, że kod zostanie złamany Wystarczy kilka testówWystarczy pełne pokrycie Nagradzany za napisanie kodu Nagradzany za jakość Nie wie jak testowaćWie jak testować
12
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ę
13
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 refaktoryzuj Rób to systematycznie
14
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ów 3.Al Capone uruchamiaj testy tam, gdzie błędy najprawdopodobniej wystąpią
15
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ść
16
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)
17
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)
18
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
19
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
20
Magiczne granice Ciekawe rzeczy dzieją się na rogach –Testuj więc po obu stronach granic
21
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
22
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
23
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
24
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?
25
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ę
26
Ćwiczenie 1 Piszesz podsystem zarządzania magazynem dla aplikacji e-commerce Jakich wzorców – zasad użyjesz? Napisz pytania dotyczące wymagań
27
Ć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ń
28
Ć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
29
Eleganckie testowanie - automatyzacja Wybierz narzędzie Zastosuj poznane zasady Są plusy i minusy Automatyzacja nie jest panaceum
30
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
31
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
32
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
33
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
34
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
35
Ćwiczenie 2 System 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
36
Ć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
37
Ć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
38
Ć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
39
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
40
Plusy i minusy Silna technika redukowania przypadków testowych Ogólnie łatwa do wykonania Można jednak, w kodzie, łatwo pominąć wyjątki
41
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
42
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
43
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
44
Ćwiczenie 4 Zdefiniować jedną jednostkę dla: waluty USA wieku (np. dla zniżki biletowej) daty ważności czasu
45
Ćwiczenie 4 - odpowiedzi Zdefiniować 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
46
Ć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
47
Ćwiczenie 5 - odpowiedzi Przypadki: -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)
48
Ćwiczenie 6 - Wyprzedaż Tylko jedno wymaganie: Jeśli kupisz za 10 lub więcej dolarów, to otrzymasz 10% zniżki
49
Ćwiczenie 6 - Odpowiedzi Przypadki: -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
50
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
51
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
52
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
53
TDD – przykład (2) public void testRating(){ Movie starWars = new Movie(Star Wars); starWars.addRating(3); starWars.addRating(5); assertEquals(Bad,4,starWars.getAverageRating()); };
54
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; }
55
Projekty Do 12.XI.2008 (godz 13:00) na stronie cvs.ii.uni.wroc.pl/eto2008 pojawi 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.)
Podobne prezentacje
© 2024 SlidePlayer.pl Inc.
All rights reserved.