Wstęp do systemów informatycznych Testowanie oprogramowania.

Prezentacja na temat: "Wstęp do systemów informatycznych Testowanie oprogramowania."— Zapis prezentacji:

1 Wstęp do systemów informatycznych Testowanie oprogramowania

2 Agenda  Założenia testowania  Testy statyczne i dynamiczne  Black Box, Grey Box, White Box  Wymagania niefunkcjonalne  Narzędzia do testowania - przykłady

3 Założenia It’s hard enough to find an error in your code when you’re looking for it; its even harder when you’ve ASSUMED your code is ERROR-FREE. Steve McConnell

4 Założenia  Testowanie nie pozwoli nam udowodnić poprawności systemu  nie możemy udowodnić, że produkt działa poprawnie w każdych warunkach  możemy pokazać, że program działa poprawnie w konkretnych warunkach  Główny cel - wykrywanie błędnych wykonań (failures) w oprogramowaniu

5 Defekt vs Błędne wykonanie  Defekt – błąd w kodzie, który może, ale nie musi prowadzić do błędnego wykonania  Błędne wykonanie – sytuacja, w której system podaje błędne wyniki  pad systemu też jest błędnym wynikiem ;)

6 Źródła defektów  nierozpoznane wymagania  błędy w kodzie  problemy z kompatybilnością  …

7 Testowanie statyczne i dynamiczne Software and cathedrals are much the same – first we build them, then we pray.

8 Testowanie statyczne  badanie  kodu  dokumentów projektowych  innych artefaktów  bez uruchamiania systemu

9 Testowanie statyczne  Przeglądy kodu  Przejścia  Inspekcje

10 Przeglądy kodu  systematyczne zbadanie kodu źródłowego  zazwyczaj przez innego członka zespołu  ma pomóc znaleźć i poprawić błędy

11 Przeglądy kodu  Over-the-shoulder  Email pass-around  Pair Programming  wspomagane oprogramowaniem

12 Przejścia i inspekcje  Sformalizowana wersja przeglądów kodu  Wykorzystywana w krytycznych projektach  albo w istotnych fragmentach normalnych

13 Testy dynamiczne  badanie odpowiedzi systemu na dane wejściowe  uruchamiamy system  podajemy dane wejściowe  sprawdzamy, czy wyjście jest zgodne z oczekiwaniami

14 Testy dynamiczne  Testy jednostkowe  Testy integracyjne  Testy systemu  Testy akceptacyjne

15 Testy jednostkowe  testujemy najmniejsze komponenty oprogramowania  sprawdzamy, czy implementacja jest godna z założeniami  w wypadku programów w językach obiektowych - testujemy metody klas

16 Testy integracyjne  Szukamy błędów na styku już przetestowanych mniejszych modułów  Testujemy coraz większe grupy komponentów

17 System Tests  Testujemy cały system  Sprawdzamy zgodność funkcjonalności ze specyfikacją  Sprawdzamy wymagania niefunkcjonalne  Sprawdzamy jego współpracę z systemami zewnętrznymi

18 Testy akceptacyjne  Testy (black box) przed przyjęciem przez klienta  Przeprowadzane przez klienta lub we współpracy z nim

19 Testy regresyjne  Zautomatyzowane  Uruchamiane po modyfikacji oprogramowania  Testują cały system  Sprawdzają, czy poprawka nie wprowadziła nowych błędów

20 Black Box, Grey Box, White Box Programming can be fun, so can cryptography; however they should not be combined. Kreitzberg and Shneiderman

21 Trzy podejscia  Black Box  White Box  Grey Box

22 Black Box  Traktujemy system jako „czarne pudełko” - bez wiedzy o implementacji systemu  equivalence partitioning  boundary value analysis  fuzz testing  exploratory testing

23 Equivalence partitioning  Algorytm zachowuje się podobnie dla danych z jakiegoś zakresu  dzielimy dane na odpowiednie zakresy  wybieramy przykłady danych testowych z każdego  przykłady - rozwiązywanie równania kwadratowego, liczenie podatku dla różnych wartości dochodu...

24 Boundary value analysis  Sprawdzamy działanie dla wartości granicznych  wykrywanie błędów typu „one off”

25 Fuzz testing  Testowanie systemu z losowymi danymi  sprawdzamy reakcję na „nieprzewidziane” dane wejściowe

26 Exploratory testing  Style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project

27 Exploratory testing  Siadamy i testujemy  Efektywność zależy od kreatywności i doświadczenia testera

28 White Box  Tester ma dostęp do kodu źródłowego i może go modyfikować w razie potrzeby  code coverage  fault injection methods  static testing

29 Code coverage  Sprawdzamy stopień, w jakim kod jest pokryty przez testy  Zwykle z użyciem narzędzi

30 Code Coverage  Function coverage - czy każda funkcja została wykonana?  Statement coverage - czy każda linia kodu została wykonana?  Decision coverage - czy każda konstrukcja decyzyjna została zewaluowana do true i false?  Condition coverage - czy każdy warunek logiczny został zewaluowany do true i false?  Path coverage - czy przeszliśmy kod każdą możliwą ścieżką?  Entry/exit coverage - czy każde możliwe wywołanie funkcji i return z funkcji były wykonane?

31 Fault injection  wstawiamy błędy w losowych miejscach kodu  sprawdzamy, czy wstawienie tych błędów ma jakieś efekty (powinno mieć)

32 Grey Box  Znamy kod źródłowy, ale prowadzimy testy na poziomie black-box

33 Testowanie wymagań niefunkcjonalnych Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.

34 Testowanie wymagań niefunkcjonalnych  testowanie wydajności - czy system może obsłużyć duże ilości danych lub użytkowników?  testowanie użyteczności - czy interfejs jest prosty w użyciu?  testowanie bezpieczeństwa - czy oprogramowanie jest dobrze zabezpieczone?  ….

35 Narzędzia do testowania Q: How many software engineers does it take to change a lightbulb? A: Just one. But the house falls down. Andrew Siwko

36 Narzędzia do testowania  Testowanie pokrycia kodu  Narzędzia do testów jednostkowych  Debuggery  Loggery  Profilery  …

37 JUnit

38  Testy jednostkowe dla Javy  Używa anotacji i asercji do opisu testów  Wspierane m.in. przez Eclipse  Bardzo popularna

39 JUnit  test JUnit - metoda zawarta w klasie używanej tylko do testów  metoda anotowana @org.junit.Test  używa metod JUnit do sprawdzenia, czy otrzymaliśmy poprawny wynik

40 JUnit @Test public void multiplicationOfZeroIntegersShouldReturnZero() { // MyClass is tested MyClass tester = new MyClass(); // Tests assertEquals("10 x 0 must be 0", 0, tester.multiply(10, 0)); assertEquals("0 x 10 must be 0", 0, tester.multiply(0, 10)); assertEquals("0 x 0 must be 0", 0, tester.multiply(0, 0)); }

41 Annotations AnnotationDescription @Test public void method() The @Test annotation identifies a method as a test method. @Test (expected = Exception.class)Fails if the method does not throw the named exception. @Test(timeout=100)Fails if the method takes longer than 100 milliseconds. @Before public void method() This method is executed before each test. It is used to prepare the test environment (e.g., read input data, initialize the class). @After public void method() This method is executed after each test. It is used to cleanup the test environment (e.g., delete temporary data, restore defaults). It can also save memory by cleaning up expensive memory structures. @BeforeClass public static void method() This method is executed once, before the start of all tests. It is used to perform time intensive activities, for example, to connect to a database. Methods marked with this annotation need to be defined as static to work with JUnit. @AfterClass public static void method() This method is executed once, after all tests have been finished. It is used to perform clean-up activities, for example, to disconnect from a database. Methods annotated with this annotation need to be defined asstatic to work with JUnit. @IgnoreIgnores the test method. This is useful when the underlying code has been changed and the test case has not yet been adapted. Or if the execution time of this test is too long to be included.

42 Asserts StatementDescription fail(String)Let the method fail. Might be used to check that a certain part of the code is not reached or to have a failing test before the test code is implemented. The String parameter is optional. assertTrue([message], boolean condition)Checks that the boolean condition is true. assertFalse([message], boolean condition)Checks that the boolean condition is false. assertEquals([String message], expected, actual) Tests that two values are the same. Note: for arrays the reference is checked not the content of the arrays. assertEquals([String message], expected, actual, tolerance) Test that float or double values match. The tolerance is the number of decimals which must be the same. assertNull([message], object)Checks that the object is null. assertNotNull([message], object)Checks that the object is not null. assertSame([String], expected, actual)Checks that both variables refer to the same object. assertNotSame([String], expected, actual)Checks that both variables refer to different objects.

43 Dziękuję za uwagę Pytania?