Testowanie oprogramowania w środowisku IBM Rational Software Architect

Transkrypt

1 Testowanie oprogramowania w środowisku IBM Rational Software Architect Software Development 2008 Michał Wolski m.wolski@modesto.pl

2 szkolenia: inżynierii oprogramowania zarządzania projektami usługi doradcze audyt dokumentacji i modeli projektowych, zarządzanie projektami, zarządzanie procesami wytwórczymi oprogramowania, prowadzenie projektów informatycznych modelowanie procesów biznesowych, projektowania w zunifikowanym języku modelowania UML 2

3 Agenda Wprowadzenie do Rational Software Architect Charakterystyka środowiska Zasady przeprowadzania testów Testowanie oprogramowania statyczna analiza kodu dynamiczna analiza kodu podsumowanie 3

4 IBM Software Development Platform kompletne, otwarte, modularne i sprawdzone środowisko Analyst Architect Developer Tester Model, simulate, assemble, and monitor processes Visually model applications and data Rapidly construct, transform, integrate and generate code Design, create, and execute tests Deployment Manager Provision, configure, tune and troubleshoot applications Project Manager Follow a common proces s Manage and measure projects and portfolios Manage requirements Manage change and as s ets Manage quality Executive Align inves tments with business objectives Analyze and monitor project portfolios 4

5 IBM Software Development Platform kompletne, otwarte, modularne i sprawdzone środowisko Analyst Architect Developer Tester Requirements & Analysis Deployment Manager Design & Construction Software Quality Deployment Management Customer Extensions Project Manager Executive 3rd Party ISV Tools Software Configuration Management Process and Portfolio Management 5

6 Artefakty fazy testowania Specyfikacja wymagań Specyfikacja systemu Plan testów akceptacyjnych Przekazanie do wdrożenia i eksploatacji Projekt systemu Plan testów integracyjnych systemu Test akceptacyjny Projekt szczegółowy Plan testów integracyjnych podsystemów Test integrac. systemy Test modułów Test integr. podsystemów 6

7 Testowanie programu Wykazuje obecność błędów a nie ich brak Dobry przypadek testowy niosący duże prawdopodobieństwo wykrycia nowego błędu Udany test test odkrywający nowy błąd 7

8 Zasady dobrego testowania(1) Całkowite przetestowanie systemu jest niemożliwe Testowanie należy oprzeć na specyfikacji wymagań Konieczne jest zrozumienie, co system ma robić, jakie są jego ograniczenia Należy dogłębnie poznać dziedzinę problemową Testowanie bazuje na ryzyku Nie można zidentyfikować wszystkich możliwych zagrożeń Ocena ryzyka wskazuje, ile testować i na czym się skupić Czas i zasoby są ograniczone unikaj testów nie wnoszących nic nowego Wykorzystaj efektywne zasoby narzędzia wspomagające testowanie, specjalistów od testowania ( zespół testowy być może z zewnątrz) 8

9 Zasady dobrego testowania(2) Testowanie należy zaplanować Specyfikację testów należy przygotować tak wcześnie, jak to możliwe, ale nie wcześniej Testy można przygotowywać w trakcie definiowania wymagań Wczesne przygotowanie testów pogłębia zrozumienie wymagań Pomiar i śledzenie zaawansowania testowania jest sprawą kluczową Konieczna jest świadomość, które części systemu (wymagań, projektu, kodu) zostały przetestowane, a które nie Złożone oprogramowanie jest zbyt skomplikowane, by można go było całkowicie przetestować bez systematycznego pomiaru procesu testowania 9

10 Dane testowe i przypadki testowe Dane testowe dane przygotowane do przetestowania systemu Przypadek testowy dane testowe oraz spodziewane wyniki systemu, jeśli zadziała zgodnie ze specyfikacją 10

11 Analiza statyczna Statyczna Analiza programu pozwala na: zwiększenie wydajności i stabilności poprzez zasady oparte na dobrych praktykach, unikniecie typowych błędów podczas programowania, dostarczenie struktury do zarządzania standardami kodu. wymuszenie własnych zasad pisania kodu 11

12 Analiza strukturalna w RSA Wykrycie antywzorców projektowych przeciwdziałanie złym praktykom Kontrola architektury Odkrywanie architektury: Analiza zależności pomiędzy komponentami a modelem projektu 12

13 Antywzorce projektowe Antywzorce projektowe: Wspólne, powtarzalne złe praktyki w projektowaniu i implementacji Mogą być odkrywane podczas analizy kodu Mogą być znajdowane podczas odkrywania architektury Przykładowe antywzorce: Tangle, Local Hub, Global Hub, Local Breakable,.

14 Odkrywanie architektury Pozwala na: Wizualizację krytycznych elementów architektury Wykrycie ważnych wzorców projektowych Zakładka Diagram Navigator zawiera: Design patterns OO Design patterns Structural patterns System patterns

15 Analiza statyczna przykład (1) KROK 1 Uruchomienie projektu KROK 2 uruchomienie narzędzia przeglądu kodu (ang. Code Review Tool) 15

16 Analiza statyczna przykład (2) KROK 3 Wybór odpowiedniego testu 16

17 Analiza statyczna przykład (3) KROK 4 Analiza wyników 17

18 Analiza statyczna przykład (4) KROK 5 Naprawa kodu (automatyczna?) Jeśli dla danego problemu Rational Software Architect jest w stanie odnaleźć sugerowane rozwiązanie, problem ten jest oznaczany ikoną żarówki. 18

19 Analiza dynamiczna Analiza dynamiczna pozwala na zrozumienie zachowania komponentów programowych dzięki danym zebranym podczas wykonywania się tego komponentu. Dzięki niej można wyciągnąć wnioski co do: wydajności, wycieków pamięci, obecności hazardów w wielowątkowych aplikacjach. 19

20 Przebieg analizy dynamicznej Weryfikacja gotowości do testów Przygotowanie i uruchomienie profilu testów Obserwacje testów Interpretacja wyników

21 Przygotowanie testów W celu przeprowadzenia analizy dynamicznej musimy sie upewnić, że: Kod źródłowy jest stabilny Kod przechodzi testy komponentowe środowisko pracy jest stabilne jednostka komputerowa na której wykonywany będzie test spełnia minimum wymagań sprzętowych Rational Agent Controller (RAC) komponent niezbędny do wykonania profili i testów RAC jest usługą zarządzającą uzyskiwanymi wynika w trakcie testów

22 Przygotowanie i uruchomienie profilu testów Celem jest wybranie odpowiednich testów w profilu Properties Tab

23 Profile Basic Memory Analysis wizualizacja zużycia pamięci Execution Time Analysis czas wykonania metod obciążenie CPU Method Code Coverage pokrycie kodu testami Probe Insertion pozwala na załadowanie fragmentów kodu w trakcie testów

24 Widok monitora profili Monitor profili (Profiling Monitor) wskazuje na zestaw testów, jakie zostały umieszczone w profilu testów

25 Historia testów Widoki Performance Call Graph i Method Detail: przepływy diagram śladowy interakcji statystyki

26 Śladowy diagram sekwencji diagram zawiera: klasy obiekty komunikaty istnieje możliwość filtrowania wyników 26

27 Analiza pamięci Badane obszary: tworzone instancje działanie poszczególnych instancji rozmiar

28 Pokrycie kodu testami

29 Analiza dynamiczna przykład (1) KROK 1 Przygotowanie aplikacji do testów KROK 2 Przygotowanie profilu KROK 3 Uruchomienie testów 29

30 Analiza dynamiczna przykład (2) KROK 3 Przegląd wyników - Basic Memory Analysis (Memory Statistics) 30

31 Analiza dynamiczna przykład (3) KROK 4 Przegląd wyników - Execution Time Analysis (Execution Statistics) 31

32 Analiza dynamiczna przykład (4) KROK 5 Przegląd wyników - Method Code Coverage (Coverage Statistics) 32

33 Podsumowanie Rational Software Architect umożliwia: przeprowadzenie testów statycznych antywzorce architektura systemu wykonanie testów dynamicznych obciążenie systemu pokrycie kodu testami śladowe diagramy sekwencji 33

34 Dziękuję za uwagę Testowanie oprogramowania w środowisku IBM Rational Software Architect Software Development