Efektywne tworzenie oprogramowania 2008/2009

1. Efektywne tworzenie oprogramowania2008/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

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) • Nie można całkowicie przetestować • nie próbuj tego • wybierz najbardziej efektywne testy • Powtórne wykonywanie tego samego testu „aby się upewnić” – n i e • zabronić duplikowania testów • 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