Testowanie oprogramowania w środowisku IBM Rational Software Architect



Podobne dokumenty
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Opis metodyki i procesu produkcji oprogramowania

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

Etapy życia oprogramowania

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Testowanie aplikacji mobilnych na platformie Android - architektura, wzorce, praktyki i narzędzia

Zasady organizacji projektów informatycznych

Spis treúci. 1. Wprowadzenie... 13

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Dni: 3. Opis: Adresaci szkolenia

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp Podziękowania...

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Luki w bezpieczeństwie aplikacji istotnym zagrożeniem dla infrastruktury krytycznej

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Tworzenie przypadków testowych

Cechy charakterystyczne tworzenia oprogramowania w Inżynierii Biomedycznej. Wykładowca Dr inż. Zofia Kruczkiewicz

Usługa: Audyt kodu źródłowego

Testowanie oprogramowania. Testowanie oprogramowania 1/34

Całościowe podejście do testowania automatycznego dla programistów. (TDD, BDD, Spec. by Example, wzorce, narzędzia)

Dlaczego testowanie jest ważne?

PRZEWODNIK PO PRZEDMIOCIE

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Jak opisać wymagania zamawiającego wybrane elementy

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski

UML w Visual Studio. Michał Ciećwierz

Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008

IBM Rational Software Architect uproszczona instrukcja użytkowania

Projektowanie systemów informatycznych. wykład 6

Szczegółowy plan szkolenia

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE

ŚcieŜki Certyfikacji Testera. Karol Mioduszewski - CORRSE

Analiza biznesowa a metody agile owe

ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager.

Maciej Oleksy Zenon Matuszyk

KARTA MODUŁU KSZTAŁCENIA

Testujemy dedykowanymi zasobami (ang. agile testers)

RUP. Rational Unified Process

Podstawy modelowania programów Kod przedmiotu

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

PRZEWODNIK PO PRZEDMIOCIE

WPROWADZENIE DO UML-a

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Projektowanie systemów informatycznych. Roman Simiński programowanie.siminskionline.pl. Cykl życia systemu informatycznego

TESTER OPROGRAMOWANIA STUDIA PODYPLOMOWE

E-ID1S-08-s5. Informatyka. I stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)

Narzędzia CASE dla.net. Łukasz Popiel

Jakość w procesie wytwarzania oprogramowania

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

Inżynieria oprogramowania (Software Engineering)

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Application Security Verification Standard. Wojciech Dworakowski, SecuRing

Wdrożenie technologii procesowej IBM BPM w EFL

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20

Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek

Inżynieria oprogramowania. Jan Magott

Wytwórstwo oprogramowania. michał możdżonek

Zwinna współpraca programistów i testerów z wykorzystaniem BDD i. by Example (JBehave/Spock/SpecFlow)

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

Całościowe podejście do testowania automatycznego dla programistów. /C#/PHP (TDD, BDD, Spec. by Example, wzorce, narzędzia)

Usługa: Testowanie wydajności oprogramowania

wbudowane October 7, 2015 KSEM WETI PG Komputery przemysłowe i systemy wbudowane Oprogramowanie systemów wbudowanych - wydajność Wydajność

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

Podstawy programowania III WYKŁAD 4

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Programowanie Zespołowe

E-1IZ3-06-s6. Inżynieria Programowania. Informatyka. I stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

PRZEWODNIK PO PRZEDMIOCIE

Analiza i projektowanie obiektowe w UML Kod przedmiotu

Inżynieria oprogramowania - opis przedmiotu

Testy poziom po poziomie

Techniki (automatyzacji) projektowania testów. Adam Roman WarszawQA, 24 II 2016

Dr Katarzyna Grzesiak-Koped

DLA SEKTORA INFORMATYCZNEGO W POLSCE

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą

Podejście zwinne do zarządzania projektami

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Szkolenie: Automatyzacja testowania

Szybkie prototypowanie w projektowaniu mechatronicznym

WOJSKOWA AKADEMIA TECHNICZNA

Analityk i współczesna analiza

Akademia testera oprogramowania i systemów IT Poziom I specjalista testowania (56 h) kurs dzienny

Egzamin / zaliczenie na ocenę*

Inżynieria Oprogramowania w Praktyce

Projektowanie oprogramowania

Wytwarzanie oprogramowania

Transkrypt:

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

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

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

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

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

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

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

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

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

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

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

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

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,.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pokrycie kodu testami

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

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

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

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

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

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