Testowanie

1. Organizacja Przedsięwzięć Programistycznych Testowanie Grzegorz Jachimko Grzegorz.Jachimko@cs.put.poznan.pl

2. Cytat dnia „Kiedy zawiesza się program konkurencji, to jest awaria. Kiedy zawiesza się własny program to jest ‘drobiazg’. Często po awarii pojawia się komunikat typu ID 02. ID to skrót od Idiotyczny drobiazg, a następująca po nim liczba wskazuje, przez ile miesięcy produkt informatyczny powinien być testowany.” - Guy Kawasaki, ‘The Macintosh Way’

3. Plan wykładu • Co to jest błąd? • Po co testować? • Kiedy testować • Jak testować? • Testy modułowe – narzędzia • Podsumowanie

4. Co to jest błąd? • Słynne (i kosztowne) błędy • Lądownik NASA na Marsie – 1999 – koszt: kilkaset milionów $ • Błąd dzielenia w procesorach PENTIUM – 1994 – koszt: 400.000.000 $ • Błąd roku 2000 – 1974 – koszt: kilkaset miliardów $

5. Co to jest błąd - definicja Błąd oprogramowania występuje gdy: • Oprogramowanie nie wykonuje czegoś, co wg specyfikacji powinno wykonywać; • Oprogramowanie robi coś, czego wg specyfikacji robić nie powinno; • Oprogramowanie wykonuje coś o czym specyfikacja w ogóle nie wspomina;

6. Co to jest błąd - definicja Błąd oprogramowania występuje gdy (c.d.): 4. Oprogramowanie nie wykonuje czegoś, o czym specyfikacja wprawdzie nie wspomina, ale powinna 5. Oprogramowanie jest trudne do zrozumienia, trudne do użycia, powolne, albo zdaniem testera – będzie w oczach użytkownika po prostu nieprawidłowe

7. Po co testować? • Projektanci nie chcą aby ich system zawiódł • Bo to się opłaca – wymiana wadliwego oprogramowania jest droższa (pieniężnie i marketingowo) niż kilkadziesiąt dni pracy testerów • Główne cele testowania • Usunięcie błędów • Określenie niezawodności systemu

8. Kiedy testować? • Im wcześniej, tym lepiej !

9. Kiedy testować? • Im wcześniej, tym lepiej !!

10. Jak testować? Aksjomaty testowania • Programu nie da się przetestować całkowicie4 instrukcje warunkowepętla wykonywana do 20 razykilka poleceńliczba ścieżek: 520 + 519 + ...+ 51 = 1014 czas: 1 bln lat przy 5 min. na test!!

11. Jak testować? Aksjomaty testowania • Testowanie jest ryzykowne1+1,1+2,....1+99, 2+1,.... a co jeśli 1+100 zawiedzie? • Test nie udowodni braku błędów • Im więcej błędów znaleziono – tym więcej pozostało • Nie wszystkie błędy zostaną poprawione • Trudno powiedzieć kiedy błąd jest błędem

12. Jak testować? • Testy statycznedotyczy artefaktów, które nie są wykonywane – np. testowanie specyfikacji, projektu, przeglądy kodu • Testy dynamiczne wykonywanie i użytkowanie programu

13. Jak testować? Metoda czarnej skrzynki Testowanie, które abstrahuje od wewnętrznej struktury programu i jest ukierunkowane na znalezienie warunków, w których program zachowuje się niezgodnie z zadaną specyfikacją

14. Jak testować? Techniki czarnej skrzynki • wymagana znajomość specyfikacji • wartości graniczne • testowanie pozytywne/negatywne • klasy równoważności • głupi użytkownik • szukać błędy tam gdzie już je znaleziono • słuchać intuicji

15. Jak testować? Metoda białej skrzynkitestowanie, które polega na utworzeniu przypadków testowych na drodze analizy logiki zawartej w kodzie programu (metryki pokrycia)

16. Jak testować? Techniki białej skrzynki • formalne przeglądy • kontrole koleżeńskie • ręczny sprawdzian • inspekcje • standardy i reguły programowania • listy kontrolne

17. Wymagania Wymagania Wymagania Testy akceptacyjne Testy akceptacyjne Testy akceptacyjne Specyfikacja Specyfikacja Specyfikacja Testy systemowe Testy systemowe Testy systemowe Projekt systemowy Projekt systemowy Projekt systemowy Testy integracyjne Testy integracyjne Testy integracyjne Projekt szczegółowy Projekt szczegółowy Projekt szczegółowy Testy modułowe Testy modułowe Testy modułowe Program Program Program Jak testować? Testy regresyjne

18. Jak testować? Analiza wyników • wymagana jest gruntowna analiza wyników, w p.p. błąd może pozostać niezauważony!! • należy zwracać uwagę na efekty uboczne testów

19. Jak testować? Opis błędu • Zawiera stan początkowy i sekwencję kroków • Każdy krok ma komentarz: co było OK, czego się spodziewano, co się stało, co było źle • Sekwencja jest minimalna • Zawiera alternatywne sekwencje • Zawiera podobne sekwencje, które działają • Specyfikuje specjalne warunki (np. konkretny komputer) • Wskazuje na uszkodzone dane • NIE zawiera osobistych komentarzy w stronę programistów • Zawiera wyjaśnienia dlaczego błąd jest ważny dla użytkownika (przekonywujące i rzeczywiste konsekwencje) • Zawiera pytania a nie definitywne twierdzenia (łatwiejsze do akceptacji przez programistów) • NIE zawiera prób rozwiązania problemu

20. Jak testować?

21. Testy modułowe - narzędzia xUnit x = JAVA, C++, C#, ... autorzy: Erich Gamma i Kent Beck framework testowy interfejs graficzny i tekstowy prostota, łatwość obsługi, automatyzacja

22. Testy modułowe - narzędzia Przepis na udane testowanie: • stwórz klasę, którą chcesz testować class RodzajTrojkata { private int m_krawedzie[]; public RodzajTrojkata(){} public String SprawdzRodzajTrojkata(int kr[]) throws Exception { m_krawedzie = kr; if (kr == null) throw new Exception("blad"); if (kr[0] == kr[1] && kr[1] == kr[2]) return "rownoboczny"; if (kr[0]==kr[1] || kr[0]==kr[2] || kr[1]==kr[2]) return "rownoramienny"; return "roznoboczny"; } };

23. Testy modułowe - narzędzia • Przepis na udane testowanie dodaj przypadki testowe public class TrojkatTest extends TestCase { private RodzajTrojkata m_rt; protected void setUp() //tutaj dodaj inicjalizację zmiennych { m_rt = new RodzajTrojkata(); } protected void tearDown() //tutaj możesz posprzątać po teście { m_rt = null; } //funkcja testująca jeden przypadek public void testRownoboczny() throws Exception { System.out.print(„sprawdzam czy trójkąt jest równoboczny”); int kr[] = new int[3]; kr[0] = kr[1] = kr[2] = 10; string res = m_rt.SprawdzRodzajTrojkata( kr ); assertEquals(„rownoboczny”, res); //OK. jeśli się zgadza } }

24. Testy modułowe - narzędzia • Przepis na udane testowanie zbierz przypadki testowe w zbiór public class TrojkatTest extends TestCase { ..... //Klasa TestSuite implementuje interfejs Test public static Test TrojkatSuite() { //jako parametr przekaż klasę TrojkatTest return new TestSuite(TrojkatTest.class); } }

25. Testy modułowe - narzędzia • Przepis na udane testowanie przekaż zbiór testów ‘testerowi’ public class TrojkatTest extends TestCase { ..... public static Test TrojkatSuite() { ... } public static void main( String[] args ) { //stwórz zbiór testów TestSuite suite = new TestSuite(); //dodaj jeden lub więcej zbiorów suite.addTest( TrojkatSuite() ); //wykonaj testy w trybie tekstowym TestResult result = junit.textui.TestRunner.run( suite ); } }

26. Testy modułowe - narzędzia • Przepis na udane testowanie TESTUJ! skompiluj: javac –classpath c:\junit\junit.jar; *.java uruchom: java TrojkatTest sprawdź:

27. Testy modułowe - narzędzia • xUnit – najważniejsze metody assertEquals, assertFalse, assertTrue, assertNull, assertNotNull, assertSame, assertNotSame, fail

28. Testy modułowe - narzędzia • Problem - Jak testować funkcje, które generują wyjątki? public testExcpetion() { try { int x, y, z; y = 10; z = 0; x = y/z; // dzielenie przez 0 !! fail( „oczekiwano wyjątku” ); } catch (Exception err) { // OK., tego oczekiwaliśmy } }

29. Podsumowanie • Najlepszym sposobem na unikanie błędów jest tworzenie dokładnych i przemyślanych specyfikacji i projektów, a następnie ich częste przeglądy – im wcześniej błąd zostanie wykryty, tym jest to tańsze • Dopasować dostępne metody testowania do wymagań organizacyjnych • Tworzyć przypadki testowe najwcześniej jak to jest możliwe

30. Podsumowanie • Przygotowanie planu testów ułatwia późniejsze testowanie • Znalezione błędy powinny być dokumentowane • Korzystaj z narzędzi !!

31. Literatura, informacje • Ron Patton, Testowanie Oprogramowania, Warszawa, czerwiec 2002 • Marick B., The Craft of Software Testing, Prentice Hall, 1995 • JUnit http://www.junit.org/index.htm

32. Ocena wykładu 1. Wrażenie ogólne (1 - 6) 2. Za szybko czy za wolno? 3. Czy dowiedziałeś się czegoś ważnego? 4. Co i jak poprawić?