1 / 55

Efektywne tworzenie oprogramowania 2008/2009

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”

kynan
Download Presentation

Efektywne tworzenie oprogramowania 2008/2009

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related