Testowanie i Ciągła Integracja w Projektach Java Enterprise Edition
|
|
- Franciszek Sowa
- 8 lat temu
- Przeglądów:
Transkrypt
1 UNIWERSYTET JAGIELLOŃSKI W KRAKOWIE Praca magisterska Testowanie i Ciągła Integracja w Projektach Java Enterprise Edition Adam Perlik Pracę wykonano w Zakładzie Technologii Informatycznych pod kierunkiem Dr Katarzyny Grzesiak-Kopeć Wydział Fizyki, Astronomii i Informatyki Stosowanej Kraków 2009
2
3 Spis treści Wstęp 6 Motywacja... 6 Cel pracy... 8 Organizacja pracy... 8 Rozdział 1. Testowanie systemów informatycznych Czym jest testowanie systemów informatycznych? Testowanie metodą białej skrzynki Testowanie metodą czarnej skrzynki Wybrane typy testów Testy jednostkowe Wykrywanie błędów Łamanie wymagań Dokumentacja Testy integracyjne Model z góry na dół Model z dołu do góry Model hybrydowy Testy funkcjonalne Test niefunkcjonalne Wydajność Obciążenie Wytrzymałość Testowalność oprogramowania Operatywność Obserwowalność Sterowność Dekompozycja Prostota Stabilność Zrozumiałość
4 1.3. Ciągła integracja Utrzymywanie pojedynczego repozytorium kodu Automatyzacja budowy Samo-testowanie się systemu podczas budowy Każda zmiana w repozytorium kodu powinna wyzwalać proces integracji Częsta synchronizacja kodów źródłowych z repozytorium Wszyscy widzą co się dzieje Rozdział 2. Narzędzia wykorzystane do stworzenia platformy testowej Środowisko programistyczne Maven Cykl budowy aplikacji Zarządzanie zależnościami Repozytorium kodu źródłowego Subversion Eclipse Integrated Development Environment Biblioteki programistyczne Java i Java Enterprise Edition Springframework JUnit Mockito Narzędzia testujące Selenium Remote Control SoapUI Serwer ciągłej integracji Hudson Openfire Server Rozdział 3. Implementacja platformy testowej Przykładowa aplikacja Java Enterprise Edition Wymagania stawiane aplikacji Architektura systemu Proces budowy aplikacji Pokrycie testami poszczególnych części systemu Testy jednostkowe Testy integracyjne Testy funkcjonalne Testy wydajnościowe
5 Podsumowanie 61 Rozdział 4. Appendix Instalacja i uruchomienie platformy testowej Instalacja maszyny wirtualnej języka Java Instalacja i konfiguracja repozytorium Subversion Instalacja serwera Openfire oraz komunikatora PSI Instalacja i konfiguracja serwera Hudson Prezentacja procesu ciągłej integracji Spis tabel i rysunków 74 Bibliografia 76 5
6 Wstęp Motywacja W dzisiejszych czasach, w epoce Internetu trudno sobie wyobrazić jakąkolwiek gałąź gospodarki, która nie korzysta z dedykowanych systemów informatycznych. Banki udostępniają swoim klientom obsługę konta przez Internet lub telefon komórkowy, sieci handlowe oferują sprzedaż on-line, która pozwala na robienie zakupów bez wychodzenia z domu. Z perspektywy końcowego użytkownika wspomnianych wyżej aplikacji oferowane przez nie funkcje są proste i oczywiste. Przykładowo na stronie naszego operatora telefonicznego wybieramy opcję Przedłuż Umowę, podajemy swój numer telefonu, wybieramy plan taryfowy wraz z modelem nowego aparatu, zatwierdzamy i drukujemy gotową umowę. W rzeczywistości to, co użytkownik postrzega jako proste i przyjazne jest często bardzo skomplikowanym systemem informatycznym składającym się z setek tysięcy linii kodu źródłowego tworzonego przez wiele osób, nierzadko przez kilka lat. W przytoczonym przeze mnie przykładzie przedłużania umowy z operatorem telefonii komórkowej łatwo można wyróżnić szereg odrębnych aplikacji, których współpraca jest niezbędna do realizacji żądanego procesu biznesowego. Można tu przytoczyć na przykład system CRM zapewniający informacje o kliencie, ERP zapewniający informacje o dostępnych telefonach i planach taryfowych, systemy firm kurierskich dostarczających przesyłki, serwery poczty do wysyłania wymaganych potwierdzeń. Na każdym z etapów takiego procesu istnieje szereg różnych przypadków, które należy obsłużyć. A co się dzieje w przypadku, gdy klient zalega z płatnościami? Co gdy podczas realizacji zamówienia wyczerpał się zapas aparatów wybranych przez klienta? Jak widzimy sam proces biznesowy jest bardzo skomplikowany. Niestety podczas tworzenia oprogramowania realizującego ten proces złożoność wszystkich elementów tylko wzrasta, a każda nawet drobna pomyłka może wywołać poważne konsekwencje. W systemach działających pod 6
7 dużym obciążeniem nawet minuta niepoprawnego działania aplikacji może wygenerować milionowe straty. W celu minimalizacji błędów w oprogramowaniu wypracowane zostały przeróżne metodologie inżynierii oprogramowania, które usystematyzowały poszczególne etapy rozwoju systemów informatycznych, od zbierania wymagań klienta w stosunku do systemu, aż po ostateczne wdrożenie aplikacji. Dzięki technikom statycznej analizy i budowaniu prototypów dla poszczególnych komponentów można wychwycić błędne założenia w stosunku do systemu, jednak ogromne ryzyko niepoprawnej implementacji poprawnych wymagań wciąż jest obecne. Wykrycie tych pomyłek możliwe staje się dopiero na etapie uruchamiania oprogramowania. Na szczęście na pomoc twórcom systemów informatycznych przychodzi proces testowania. Wraz z rozwojem inżynierii oprogramowania ewoluowały też rodzaje testów i sposoby ich przeprowadzania. Opierając się na doświadczeniach z wcześniejszych projektów, programiści wyznaczali dobre praktyki pozwalające testować coraz więcej aspektów systemu. Niestety, ręczna obsługa wszystkich testów szybko okazała się problemem. W niektórych korporacjach powstały specjalne stanowiska menadżera testów, odpowiedzialnego za okresowe wykonywanie zestawów testów i sporządzanie raportów z ich przebiegu. O ile w metodologiach wytwarzania oprogramowania opartych o model wodospadu, gdzie etap testów jest na samym końcu procesu wytwórczego, nie stanowiło to problemu, to powstanie metodologii dzielących projekt na iteracje, rozwiązanie to było niewystarczające. Ciągła integracja polega na wykonywaniu testów przy każdej zmianie w systemie. W tym celu wykorzystywane są dedykowane narzędzia zintegrowane z repozytoriami kodu źródłowego oraz systemami raportowymi. Systemy ciągłej integracji okresowo sprawdzają repozytoria kodu w poszukiwaniu zmian, w przypadku znalezienia nowych wersji budują projekt, wykonują testy i w przypadku niepowodzenia któregoś z nich, wysyłają raport o tym co się nie udało do użytkowników odpowiedzialnych za wprowadzanie zmian oraz odnotowują niepowodzenie w systemach raportowych. Dzięki zastosowaniu takich narzędzi, błędy mogą być wykrywane na bardzo wczesnym etapie, kiedy to ich naprawienie jest zazwyczaj bardzo proste i nie wymaga dodatkowych nakładów, a tym samym nawet najbardziej skomplikowane funkcjonalności mogą być poprawnie implementowane. 7
8 Cel pracy Celem niniejszej pracy jest prezentacja nowoczesnego środowiska pracy programisty, którego wykorzystanie do tworzenia systemu informatycznego zbudowanego w oparciu o platformę Java Enterprise Edition pozwala na pełną automatyzację testów tworzonego oprogramowania. Zaproponowane środowisko ciągłej integracji zostało zbudowane w oparciu o narzędzia dostępne za darmo wraz z kodem źródłowym, takie jak: Maven, Hudson, Subversion, JUnit i Selenium Remote Control. Dzięki automatyzacji wykonywania testów przy każdej zmianie wykrytej w systemie zbudowano narzędzie do wczesnego wykrywania błędów. Ze względu na to, że wspomniane powyżej narzędzia stanowią odrębne projekty, nie zawsze tworzone z myślą o ewentualnej integracji w ramach pracy konieczna była również analiza pod kątem możliwości ich współdziałania. Wynikiem tej analizy było powstanie konfiguracji poszczególnych narzędzi tak aby utworzyły pełne środowisko ciągłej integracji. Organizacja pracy W rozdziale pierwszym pracy przedstawiono teorię testowania systemów informatycznych, poszczególne pojęcia związane z testowaniem, możliwe strategie testowania oraz zaprezentowana została koncepcja ciągłej integracji systemu. Rozdział drugi zawiera przegląd narzędzi użytych do stworzenia platformy testowej dla aplikacji napisanej w języku Java Enterprise Edition pozwalającej na automatyzację testów. Rozdział trzeci stanowi główną część pracy. Zawarto w nim opis aplikacji napisanej w oparciu o platformę Java Enterprise Edition, na której wykonywane są testy automatyczne, a także konfigurację poszczególnych komponentów składających się na środowisko ciągłej integracji. 8
9 Rozdział 1. Testowanie systemów informatycznych Niniejszy rozdział stanowi wprowadzenie do problematyki związanej z testowaniem systemów informatycznych. W kolejnych sekcjach tego rozdziału zdefiniowane zostały następujące zagadnienia: Wyjaśnienie na czym polega testowanie systemu Przedstawienie możliwych strategii testowania Charakterystyka różnych typów testów Opis cech wpływających na testowalność systemu Zdefiniowanie pojęcia ciągła integracja 1.1. Czym jest testowanie systemów informatycznych? Proces testowania systemów informatycznych najczęściej określany jest jako: uruchomienie programu z zamiarem znalezienia w nim błędów [1]. Określenie błąd w odniesieniu do programu komputerowego może mieć wiele znaczeń. Na poniższej liście przedstawiono kilka przykładów błędów możliwych do wykrycia za pomocą testów przeprowadzonych w systemie [1] : błędy w kodzie źródłowym aplikacji, brak implementacji wszystkich wymagań, niepoprawna implementacja wymagań, niewystarczająca wydajność systemu, niestabilność aplikacji. W celu wykrycia poszczególnych typów błędów stosowane są różne rodzaje testów, 9
10 przeprowadzanych na każdym z etapów rozwoju aplikacji od wczesnych wersji po końcowe fazy przejmowania systemu przez użytkowników. Każdy z testów koncentruje się na sprawdzeniu innej części aplikacji i ma inne cele. Jednak przyglądając się strategii ich wykonywania wyróżnić można dwie metody: białej i czarnej skrzynki Testowanie metodą białej skrzynki Metoda białej skrzynki [1] jest sposobem tworzenia i wykonywania testów z perspektywy osoby znającej wewnętrzną strukturę i sposób działania testowanej aplikacji. Testy takie skoncentrowane są na weryfikacji poprawności działania poszczególnych ścieżek przebiegu sterowania w systemie, a także jakości implementacji poszczególnych jednostek systemu. Z tą metoda mocno związane jest pojęcie pokrycia kodu źródłowego [1], które jest miarą tego, do jakiego stopnia tworzone oprogramowanie zostało przetestowane. W celu wyznaczenie wskaźnika pokrycia kodu następujące kryteria są brane pod uwagę: pokrycie funkcji - określające procent przetestowanych funkcji, pokrycie instrukcji określające procent przetestowanych linii kodu źródłowego, pokrycie gałęzi określające procent instrukcji warunkowych przetestowanych zarówno z warunkiem prawda jak i fałsz, pokrycie ścieżek określające procent przetestowanych ścieżek logicznych wiodących przez program. Całościowe przetestowanie aplikacji metodą białej skrzynki powinno dążyć do stuprocentowego pokrycia kodu systemu, a więc takiego, w którym każda jego linijka została wykonana przynajmniej raz. Niestety, często nawet w przypadku bardzo prostych programów jest ono niewykonalne. Może to wynikać zarówno z zakresu danych wejściowych poszczególnych komponentów, jak i z liczby ścieżek możliwych do przejścia w trakcie wykonania danej funkcji. Z tego powodu ta strategia wybierana jest do przetestowania wyłącznie najbardziej kluczowych sekcje programu. Niestety praktyka wybierania kodu do testów, może prowadzić do pomijania elementów, które programistom wydają się być oczywiste i w rezultacie do pominięcia ukrytych w nich błędów. 10
11 Testy metodą białej skrzynki są najbardziej pomocne we wczesnych fazach rozwoju systemu i ich wyniki pomagają programistom aplikacji w usunięciu błędów w tworzonych komponentach Testowanie metodą czarnej skrzynki W testach wykonywanych metodą czarnej skrzynki [1] testowany komponent lub system traktowany jest jako całość, bez dostępu do wewnętrznej struktury kodu programu i szczegółów jego implementacji. Testy te, ze względu na sposób ich przeprowadzania, są też określane jako sterowane danymi. Polegają one na przygotowaniu danych wejściowych i wyjściowych. Dane wyjściowe wprowadzane są do systemu, a odpowiadające im dane wyjściowe, przyrównywane są do tych, które zwróci aplikacja. Oczywiście, w zależności od rodzaju testu, dane wejściowe i wyjściowe przyjmują różne postaci. I tak dla testów funkcjonalnych są to dane wprowadzane do programu za pomocą interfejsu użytkownika, zaś dla testów wydajnościowych będą to czasy odpowiedzi systemu lub liczba obsłużonych transakcji. Testy metodą czarnej skrzynki stosowane są na różnych etapach rozwoju systemu. Jednak im system staje się większy (rośnie skrzynka), tym stają się one bardziej powszechne. Wykonaniem tych testów, w przeciwieństwie do metody białej skrzynki, mogą zajmować się osoby nie związane z implementacją systemu. Atutem wybierania testerów spośród osób nie posiadających wiedzy o programie jest to, że żadna kombinacja danych wejściowych nie jest dla nich oczywista i są one skłonni przetestować te scenariusze, które zostały pominięte przez programistów. Punktem wyjścia do tworzenia testów metodą czarnej skrzynki jest specyfikacja wymagań stawianych aplikacji. Jej szczegółowa znajomość jest wymagana w celu opracowania testów pokrywających wszystkie funkcje, które program powinien realizować. W związku z tym testy takie określane są jako funkcjonalne lub behawioralne. Duża część istniejących testów systemów informatycznych zaliczana jest do strategii czarnej skrzynki. Najczęściej spotykane pośród nich to testy funkcjonalne, testy wydajnościowe, testy obciążeniowe oraz testy systemowe. Należy jeszcze podkreślić, że zrealizowanie testów niefunkcjonalnych (np. wydajnościowych) możliwe jest jedynie przy zastosowaniu strategii czarnej skrzynki. 11
12 1.2. Wybrane typy testów W poprzedniej sekcji opisane zostały dwie strategie tworzenia testów systemów informatycznych. W oparciu o nie możliwy jest do zrealizowania szereg testów, które można pogrupować w cztery poniższe typy [2] : testy jednostkowe, testy integracyjne, testy funkcjonalne, testy niefunkcjonalne. Niestety nie wszystkie z powyższych testów mogą być zautomatyzowane. Na przykład do realizacji integracyjnych testów systemowych konieczna jest współpraca kilku systemów, za które odpowiedzialne mogą być odrębne organizacje. W kontekście niniejszej pracy ważne jest aby w sposób automatyczny sprawdzać funkcjonalności dodawane do realizowanego systemu i wykrywać powstałe przy tym błędy. Do tego celu najczęściej stosuje się automatyzację testów opisanych w kolejnych podrozdziałach Testy jednostkowe Testy jednostkowe (ang. unit tests) są realizacją strategii testowania metodą białej skrzynki. Są one tworzone w pierwszej kolejności i stanowią zazwyczaj największą pod względem liczebności, część testów budowanego oprogramowania. Oprócz wykrywania błędów, testy jednostkowe spełniają jeszcze dwie dodatkowe funkcje pozwalające zwiększyć jakość budowanego systemu oraz ułatwiające dalszy jego rozwój sprawdzając czy nie złamano wymagań. Testy takie dostarczają też swoistej dokumentacji i przykładów użycia poszczególnych jednostek kodu. Testy jednostkowe stosowane są we wszystkich istniejących językach programowania. Z czasem wykształciły się dedykowane biblioteki ułatwiające tworzenie i wykonywanie takich testów. Z powodu podobieństwa tych bibliotek zostały one określone mianem rodziny xunit. Przykładem takiej biblioteki dla języka Java jest JUnit zaprezentowany w Rozdziale 2. 12
13 Wykrywanie błędów Jak sama nazwa mówi testy jednostkowe skoncentrowane są na weryfikacji poprawnego działania poszczególnych jednostek kodu programu. Jako jednostkę rozumiemy tu najmniejszą testowalną [3] część aplikacji. W programowaniu proceduralnym jest to procedura lub funkcja, natomiast w językach obiektowych metoda klasy. Zgodnie z najlepszymi praktykami tworzenia testów jednostkowych dobry test to taki, który wykazuje następujące cechy: posiada wysokie prawdopodobieństwo wykrycia błędu, jego wykonanie jest szybkie, koncentruje się on jedynie na testowanej jednostce, elementy nie należące do danej jednostki są odizolowane. Właśnie w kontekście izolacji z testami jednostkowymi nierozerwalnie związane jest pojęcie obiektów zastępczych (ang. mock objects [3] ). Izolacja komponentów do testów jednostkowych jest trudna do osiągnięcia, ponieważ poszczególne jednostki kodu programu ze sobą współpracują. Często zdarza się, iż klasy współpracujące z testowaną istotnie wpływają na pewne elementy środowiska systemu. W takim wypadku autorzy testów rozszerzają kod testu również na zależności testowanej klasy, co powoduje że test z jednostkowego zamienia się w integracyjny lub funkcjonalny. Przykładem takiej sytuacji może być testowanie komponentu realizującego komunikację z bazą danych. Programista tworzący test zawiera w nim również komendy języka SQL wprowadzające dane do tabel w bazie, co w rzeczywistości stanowi testowanie interakcji z systemem zewnętrznym. W programowaniu obiektowym, realizację odseparowania klas na potrzeby testów umożliwia programowanie przez interfejsy oraz użycie obiektów zastępczych. Obiekty te imitują klasy wykorzystywane przez testowany komponent. Udostępniając identyczny interfejs, którego implementacja jest zazwyczaj pusta. W przytoczonym powyżej przykładzie zastąpiony mógłby zostać sterownik bazy danych, przez obiekt zawierający metody do wykonywania zapytań, jednak nie komunikujący się z rzeczywistą bazą. Realizację testów jednostkowych z użyciem obiektów zastępczych przedstawiono w rozdziale 4 w sekcji Testy jednostkowe. 13
14 Łamanie wymagań Dzięki testom jednostkowym w szybki sposób można określić czy wprowadzona w kodzie zmiana nie łamie wymagań stawianych poszczególnym komponentom. Jeżeli dla danego komponentu istnieje zestaw testów jednostkowych, mających za zadanie sprawdzenie czy spełnia on stawiane wymagania, to po wprowadzeniu do programu zmian łamiących te wymagania testy te przestaną się poprawnie wykonywać. W przypadku gdy testy wykonywały się poprawnie, a po wprowadzeniu zmian sygnalizują błędy, stanowią wtedy sposób wykrywania regresji w kodzie źródłowym i to ta właściwość jest najcenniejsza podczas automatycznego wykonywania testów w celach ciągłej integracji. Jednak uzyskanie takiego efektu wymaga odpowiednio dużego pokrycia testami kodu źródłowego aplikacji Dokumentacja Testy jednostkowe poszczególnych komponentów stanowią doskonałą dokumentację. Programiści, na podstawie testu jednostkowego danej klasy są w stanie uzyskać wiedzę na temat jej funkcjonalności. Często też zdarza się, że zmiany w kolejnych wersjach systemu nie są uwzględniane w formalnej dokumentacji. Z kolei testy jednostkowe same wymuszają konieczność aktualizacji, ponieważ w innym wypadku zgłaszają błędy Testy integracyjne Testy jednostkowe pozwalają zweryfikować zachowanie pojedynczych komponentów systemu. Jednak nawet jeżeli pracują one poprawnie w odosobnieniu, nie daje to pewności, że będą się poprawnie zachowywać współpracując ze sobą. Dzieje się tak dlatego, że do wykonywania stawianych im zadań, poszczególne moduły systemu 1 wykorzystują funkcjonalności dostarczane im przez inne moduły. Dlatego wymagane jest również wykonanie testów integracyjnych dla współpracujących ze sobą komponentów. Testy integracyjne są naturalnym rozszerzeniem testów jednostkowych i zazwyczaj wykonywane są przy użyciu tych samych narzędzi i bibliotek. Tym, co odróżnia je od testów jednostkowych jest zupełnie odmienne podejście do testowanych komponentów. Podczas testów integracyjnych najważniejsze jest zweryfikowanie czy współpraca pomiędzy poszczególnymi klasami i systemami zewnętrznymi przebiega w sposób 14
15 pożądany. Testy integracyjne są realizacją strategii testowania metodą czarnej skrzynki. Testy integracyjne mogą być realizowane na wiele sposobów, jednak najczęściej wykorzystywane są opisane poniżej trzy modele [1] : z góry na dół, z dołu do góry i hybrydowy. Przykłady realizacji testów integracyjnych dla systemu opartego o platformę Java Enterprise Edition zaprezentowano w Rozdziale Model z góry na dół W podejściu z góry na dół najpierw integrowane są moduły najwyższego poziomu a później wykorzystywane przez nie moduły zależne. Pozwala to w pierwszej kolejności testować logikę procesów aplikacji biznesowych oraz przepływ danych pomiędzy nimi. Niestety taki model wymaga intensywnego wykorzystania obiektów zastępczych ponieważ niektóre komponenty mogą nie być w danym momencie zaimplementowane. Występuje tu też ryzyko związane z relatywnie późnym integrowaniem elementów niskiego poziomu. Mimo, iż proces biznesowy wydaje się być obsługiwany poprawnie to zastąpienie obiektu zaślepki jednego z modułów niskiego poziomu może stać się niemożliwe do zaimplementowania, co z kolei wymusza zmianę w już utworzonych modułach. Zobrazować to można przykładem aplikacji korzystającej z bazy danych. Po zaimplementowaniu modułów wprowadzania danych może się okazać, iż niemożliwe jest zrealizowanie zapytań SQL w sposób jaki zakładano i koniecznym jest wprowadzania zmian w już zaimplementowanych modułach. Gdy opisana sytuacja zaistnieje pod koniec projektu zasoby potrzebne do realizacji zmian mogą już nie być dostępne Model z dołu do góry Podejście z dołu do góry wymusza testowanie i integrowanie elementów najniższego poziomu, to jest klas i ich metod, a następnie grupowanie przetestowanych elementów w moduły coraz to wyższego poziomu. Dzięki temu, podczas testów integracyjnych, zależności komponentów są już zaimplementowane i konieczność wykorzystywania obiektów zastępczych jest niewielka. Niestety, analogicznie do podejścia z góry na dół, pojawia się tu ryzyko związane z późnym testowaniem procesów wysokiego poziomu. Na przykład po dojściu do najwyższego poziomu może się okazać, iż współpraca poszczególnych modułów nie może przebiegać w sposób jaki zakładano i wymagane jest ponowne zaimplementowanie kilku z nich. Jeżeli taka sytuacja wystąpi w końcowych fazach projektu, może już nie być czasu na zmiany. 15
16 Model hybrydowy Model hybrydowy stara się wykorzystać zalety obu powyższych podejść i zminimalizować ich wady. Najpierw integrowane są moduły stanowiące interfejsy poszczególnych funkcjonalności przy użyciu modelu z góry na dół, a następnie funkcje wyjściowe tych modułów integrowane są w sposób z dołu do góry. W przykładowym systemie informatycznym mogłoby to odbywać się tak, iż najpierw zintegrowane zostałyby moduły odpowiedzialne za obsługę interfejsu użytkownika dla danej funkcjonalności, a następnie niskopoziomowe moduły realizujące komunikację z bazami danych i systemami zewnętrznymi Testy funkcjonalne Zestawy testów funkcjonalnych są odzwierciedleniem wymagań funkcjonalnych stawianych systemowi i tworzone są przy współpracy klientów biznesowych, analityków systemu, testerów i programistów. Język testów funkcjonalnych odzwierciedla domenę systemu. Operuje się w nim pojęciami takimi, jak na przykład konto w systemie bankowym czy przesyłka w systemie kurierskim, które powinny być definiowane przez przedstawicieli klienta, nazywanych potocznie ekspertami domeny [1]. Eksperci domeny posiadają niezbędną wiedzę na temat procesów biznesowych, które system ma realizować. Testy funkcjonalne to testy metodą czarnej skrzynki sterowane takimi danymi, które byłyby wprowadzane przez użytkowników końcowych aplikacji przez dedykowane im interfejsy. Stanowią narzędzie pozwalające przeprowadzać walidację tworzonego oprogramowania czyli sprawdzać: Czy budowany jest ten system co trzeba. Czy zrealizowane zostały wszystkie wymagania klienta. Czy system spełnia oczekiwania klienta. Tym samym, stanowią doskonały sposób na stwierdzenie kiedy dany przypadek użycia, a nawet cały system został w pełni oprogramowany wtedy kiedy wszystkie zdefiniowane dla niego testy funkcjonalne dają wynik pozytywny. Poprawne przejście zestawu testów funkcjonalnych stanowi zazwyczaj kryterium akceptacji odbioru systemu przez zamawiającego, dlatego testy takie często nazywane są testami akceptacyjnymi. 16
17 Testy te wykonywane są w środowisku odzwierciedlającym docelowe środowisko systemu z uwzględnieniem wszystkich wymagań aplikacji, takich jak dostępność zasobów softwarowych (np. zainstalowana przeglądarka internetowa) lub też sprzętowych (karta dźwiękowa, połączenie internetowe). Testy takie przeznaczone są do wykonywania przez testerów i ich realizacja w sposób umożliwiający automatyczne wykonywanie w procesie ciągłej integracji nie może być pominięta. Jednak dzięki zastosowaniu dostępnych narzędzi możliwe jest wykonanie testów funkcjonalnych w sposób automatyczny Test niefunkcjonalne Istnieje szereg oczekiwań stawianych przez klienta w stosunku do tworzonego oprogramowania, których nie da się w sposób jednoznaczny powiązać z dostarczaną funkcjonalnością. Przykładem takiego wymagania jest zachowywanie odpowiednich czasów przetwarzania danych wprowadzonych przez użytkowników i czasów odpowiedzi na poszczególne zapytania co możemy nazwać wydajnością systemu. Przetestowanie wymagań niefunkcjonalnych jest możliwe jedynie poprzez zastosowanie strategii czarnej skrzynki. W kolejnych podrozdziałach przedstawiono najczęściej występujące testy niefunkcjonalne. W Rozdziale 4 przedstawiono sposób realizacji testów wydajnościowych usługi sieciowej przy użyciu narzędzia SoapUI Wydajność Sformatowane: Punktory i numeracja Testy wydajnościowe pozwalają na wykrycie tych spośród komponentów systemu, które nie zachowują odpowiednich metryk wydajnościowych i wymagają optymalizacji. Służą również do identyfikacji potencjalnych wąskich gardeł, które obniżają sprawność systemu w przypadku zwiększonego obciążenia (np. komunikacja z systemami zewnętrznymi lub nadmierne zużycie pamięci) Obciążenie Sformatowane: Punktory i numeracja Testowanie obciążeniowe pozwala zweryfikować, czy nałożone wymagania wydajnościowe są spełniane w przypadku, gdy system używany jest równolegle przez zdefiniowaną liczbę użytkowników. 17
18 Wytrzymałość Sformatowane: Punktory i numeracja Testy wytrzymałościowe, powszechnie stosowane do wyznaczenia maksymalnej liczby użytkowników, których system jest w stanie jednocześnie obsłużyć. Jeżeli liczba ta jest mniejsza od określonej w wymaganiach, zachowanie systemu uznawane jest za błędne. W kryterium wytrzymałości zawiera się też weryfikacja spełnienia wymagań wydajnościowych w przypadku chwilowego, znacznie zwiększonego obciążenia systemu. Jest to szczególnie istotne podczas testowania systemów dostępnych publicznie, np. portali internetowych w których obciążenie może wzrosnąć drastycznie po opublikowaniu jakiejś wiadomości Testowalność oprogramowania W pracy przedstawione już zostały typy możliwych do wykonania testów. Jednak, aby ich uruchomienie przyniosło jakiekolwiek efekty, system, który jest sprawdzany musi być testowalny. Do głównych cech testowalnego oprogramowania należą: operatywność, obserwowalność, sterowność, dekompozycja, prostota, stabilność, zrozumiałość [1] Operatywność System ma niewiele błędów. Błędy nie blokują wykonania testów Obserwowalność Stany lub zmienne systemu są widoczne lub sprawdzalne podczas wykonania. Wszystkie czynniki wpływające na generowane wyniki są widoczne. Niepoprawne dane wyjściowe są w łatwy sposób identyfikowane. Błędy wewnętrzne są raportowane w sposób automatyczny. 18
19 Sterowność Im bardziej można sterować systemem, tym więcej testów może być przeprowadzone w sposób automatyczny. Wszystkie możliwe dane wyjściowe generowane są przez kombinacje danych wejściowych. Całość kodu systemu jest wykonana przez wprowadzanie kombinacji danych wejściowych. Testy mogą być dowolnie określane, automatyzowane i powtarzane Dekompozycja Kontrolując zakres testu można szybko izolować problemy. System zbudowany jest z niezależnych modułów. Poszczególne moduły mogą być testowane w sposób niezależny Prostota Prostota funkcjonalności system składa się z minimum funkcjonalności spełniających wymagania klienta. Prostota strukturalna architektura systemu jest modularna. Prostota kodu kod spełnia określone standardy ułatwiające inspekcję Stabilność Zmiany wprowadzane do systemu są kontrolowane. Wprowadzone zmiany nie łamią dotychczasowych testów Zrozumiałość Zależności pomiędzy komponentami systemu są dobrze zrozumiałe. Zmiany w projekcie są jasno komunikowane. Dokumentacja techniczna systemu jest dostępna. 19
20 1.3. Ciągła integracja Termin ciągła integracja w odniesieniu do systemów informatycznych wszedł do powszechnego użycia po opublikowaniu przez Martina Fowlera artykułu Continous Integration [4]. Pomimo mylnych opinii proces ciągłej integracji nie zastępuje testowania systemu informatycznego, a jest jedynie jego dopełnieniem pozwalającym znacznie zwiększyć efektywność testów poprzez ich częste, w pełni automatyczne wykonywanie. W swoim artykule Fowler przedstawia etap integracji dużego projektu informatycznego jako długi i nieprzewidywalny proces. Proces tym dłuższy i tym bardziej nieprzewidywalny, im dalej w czasie odwlekana jest integracja i testowanie projektu. Na bazie własnych doświadczeń oraz doświadczeń swoich współpracowników z firmy Thought Works, zdefiniował on szereg praktyk, którymi powinny się kierować projekty informatyczne w celu uproszczenia procesu integracji systemu i możliwości jego wykonania na żądanie w dowolnej chwili. Poniżej krótko scharakteryzowano najważniejsze z nich: Utrzymywanie pojedynczego repozytorium kodu Według Fowlera, narzędzia kontroli wersji są integralną częścią każdego, nawet najmniejszego projektu. Mnogość plików i częstotliwość zmian jakie w nich zachodzą wymusza stosowanie repozytorium kodu źródłowego w celu monitorowania modyfikacji jakim poddawana jest aplikacja i w razie konieczności przywracania poprawnie działających wersji. Oprócz utrzymywania historii poszczególnych plików repozytorium ma za zadanie ułatwienie nowym programistom rozpoczęcie pracy z projektem. Jednak aby to osiągnąć, systemy kontroli wersji powinny zawierać nie tylko kod źródłowy aplikacji, ale również wszystkie skrypty kompilacyjne, uruchomieniowe, a także biblioteki używane w projekcie Automatyzacja budowy Każdy system powinien być wyposażony w skrypt budujący poszczególne komponenty i składający je w całość (w postaci bibliotek lub plików wykonywalnych). Każdorazowe, ręczne wykonywanie procesu budowy poszczególnych elementów programu wprowadza niepotrzebny narzut czasowy oraz umożliwia popełnienie błędów. 20
Testowanie oprogramowania. Testowanie oprogramowania 1/34
Testowanie oprogramowania Testowanie oprogramowania 1/34 Testowanie oprogramowania 2/34 Cele testowania testowanie polega na uruchamianiu oprogramowania w celu wykrycia błędów, dobry test to taki, który
Bardziej szczegółowoUsługa: Testowanie wydajności oprogramowania
Usługa: Testowanie wydajności oprogramowania testerzy.pl przeprowadzają kompleksowe testowanie wydajności różnych systemów informatycznych. Testowanie wydajności to próba obciążenia serwera, bazy danych
Bardziej szczegółowoREFERAT PRACY DYPLOMOWEJ
REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany
Bardziej szczegółowoBudowa aplikacji webowej w oparciu o Maven2 oraz przykłady testów jednostkowych. Wykonał Marcin Gadamer
Budowa aplikacji webowej w oparciu o Maven2 oraz przykłady testów jednostkowych. Wykonał Marcin Gadamer Maven 2 podstawowe informacje Apache Maven jest narzędziem automatyzującym budowę oprogramowania
Bardziej szczegółowoProgram szkolenia: Continuous Integration i Git
Program szkolenia: Continuous Integration i Git Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Continuous Integration i Git tools-git-ci Narzędzia developerzy testerzy 2 dni 50%
Bardziej szczegółowoWeb frameworks do budowy aplikacji zgodnych z J2EE
Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida promotor: dr Dariusz Król Przypomnienie Celem pracy jest porównanie wybranych szkieletów programistycznych o otwartym kodzie źródłowym
Bardziej szczegółowoInstalacja SQL Server Express. Logowanie na stronie Microsoftu
Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy
Bardziej szczegółowoDariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki
Dariusz Brzeziński Politechnika Poznańska, Instytut Informatyki Język programowania prosty bezpieczny zorientowany obiektowo wielowątkowy rozproszony przenaszalny interpretowany dynamiczny wydajny Platforma
Bardziej szczegółowoXQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery
http://xqtav.sourceforge.net XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery dr hab. Jerzy Tyszkiewicz dr Andrzej Kierzek mgr Jacek Sroka Grzegorz Kaczor praca mgr pod
Bardziej szczegółowoTestowanie aplikacji mobilnych na platformie Android - architektura, wzorce, praktyki i narzędzia
Program szkolenia: Testowanie aplikacji mobilnych na platformie Android - architektura, wzorce, Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Testowanie aplikacji mobilnych na
Bardziej szczegółowoArchitektury Usług Internetowych. Laboratorium 2. Usługi sieciowe
Architektury Usług Internetowych Laboratorium 2. Usługi sieciowe Wstęp Celem laboratorium jest zapoznanie się z modelem usług sieciowych na przykładzie prostego serwera Apache Axis2. Apache Axis2 Apache
Bardziej szczegółowoPlatformy Technologiczne
i Platformy Technologiczne Laboratorium nr 5 Java: testy jednostkowe z biblioteką JUnit Projekt opracowany w ramach laboratorium nr 5 będzie wykorzystywany w czasie laboratorium nr 6 należy zachować przygotowaną
Bardziej szczegółowoTemat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych
PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoGalileo - encyklopedia internetowa Plan testów
Galileo - encyklopedia internetowa Plan testów Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Matek Sobierajski 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel..........................................
Bardziej szczegółowoUsługi analityczne budowa kostki analitycznej Część pierwsza.
Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.
Bardziej szczegółowoGrzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat
Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych
Bardziej szczegółowoBaza danych sql. 1. Wprowadzenie
Baza danych sql 1. Wprowadzenie Do tej pory operowaliście na listach. W tej instrukcji pokazane zostanie jak stworzyć bazę danych. W zadaniu skorzystamy z edytora graficznego struktury bazy danych, który
Bardziej szczegółowoCzym jest Java? Rozumiana jako środowisko do uruchamiania programów Platforma software owa
1 Java Wprowadzenie 2 Czym jest Java? Język programowania prosty zorientowany obiektowo rozproszony interpretowany wydajny Platforma bezpieczny wielowątkowy przenaszalny dynamiczny Rozumiana jako środowisko
Bardziej szczegółowoProblemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK
Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK Paweł Lenkiewicz Polsko Japońska Wyższa Szkoła Technik Komputerowych Plan prezentacji PJWSTK
Bardziej szczegółowoProgramowanie obiektowe - 1.
Programowanie obiektowe - 1 Mariusz.Masewicz@cs.put.poznan.pl Programowanie obiektowe Programowanie obiektowe (ang. object-oriented programming) to metodologia tworzenia programów komputerowych, która
Bardziej szczegółowoSzczegółowy opis przedmiotu umowy. 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów:
Rozdział I Szczegółowy opis przedmiotu umowy Załącznik nr 1 do Umowy Architektura środowisk SharePoint UMWD 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów: a) Środowisko
Bardziej szczegółowoSzablon Planu Testów Akceptacyjnych
Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia
Bardziej szczegółowoMichał Olejnik. 22 grudnia 2009
Continuous TDD Politechnika Wrocławska Informatyka 22 grudnia 2009 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoTester oprogramowania 2014/15 Tematy prac dyplomowych
Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven
Bardziej szczegółowoJUnit TESTY JEDNOSTKOWE. Waldemar Korłub. Platformy Technologiczne KASK ETI Politechnika Gdańska
JUnit TESTY JEDNOSTKOWE Waldemar Korłub Platformy Technologiczne KASK ETI Politechnika Gdańska Testy aplikacji 2 Ręczne testowanie Czasochłonne Powtarzalność trudna do uzyskania Nudne Testowanie automatyczne
Bardziej szczegółowoUniwersytet Łódzki Wydział Matematyki i Informatyki, Katedra Analizy Nieliniowej. Wstęp. Programowanie w Javie 2. mgr inż.
Uniwersytet Łódzki Wydział Matematyki i Informatyki, Katedra Analizy Nieliniowej Wstęp Programowanie w Javie 2 mgr inż. Michał Misiak Agenda Założenia do wykładu Zasady zaliczeń Ramowy program wykładu
Bardziej szczegółowoDokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor
Koszalin, 15.06.2012 r. Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor Zespół projektowy: Daniel Czyczyn-Egird Wojciech Gołuchowski Michał Durkowski Kamil Gawroński Prowadzący: Dr inż.
Bardziej szczegółowoMaciej Oleksy Zenon Matuszyk
Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu
Bardziej szczegółowoCałościowe podejście do testowania automatycznego dla programistów. (TDD, BDD, Spec. by Example, wzorce, narzędzia)
Program szkolenia: Całościowe podejście do testowania automatycznego dla programistów Ruby (TDD, BDD, Spec. by Example, wzorce, narzędzia) Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania:
Bardziej szczegółowoProduktywne tworzenie aplikacji webowych z wykorzystaniem Groovy i
Program szkolenia: Produktywne tworzenie aplikacji webowych z wykorzystaniem Groovy i Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Produktywne tworzenie aplikacji webowych z
Bardziej szczegółowo<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą
Bardziej szczegółowoProgramowanie MorphX Ax
Administrowanie Czym jest system ERP? do systemu Dynamics Ax Obsługa systemu Dynamics Ax Wyszukiwanie informacji, filtrowanie, sortowanie rekordów IntelliMorph : ukrywanie i pokazywanie ukrytych kolumn
Bardziej szczegółowoZarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
Bardziej szczegółowoDokument Detaliczny Projektu
Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej
Bardziej szczegółowoWykład I. Wprowadzenie do baz danych
Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles
Bardziej szczegółowoDariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki
Dariusz Brzeziński Politechnika Poznańska, Instytut Informatyki Object-oriented programming Najpopularniejszy obecnie styl (paradygmat) programowania Rozwinięcie koncepcji programowania strukturalnego
Bardziej szczegółowoPLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>
Załącznik nr 4.6 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA
Bardziej szczegółowoRozwiązanie Compuware dynatrace
Rozwiązanie Compuware dynatrace COMPUWARE DYNATRACE... 3 2 COMPUWARE DYNATRACE Narzędzie Compuware dynatrace oparte jest o unikatową technologię agentową, która pozwala na dogłębną analizę stanu aplikacji
Bardziej szczegółowoSzczegółowa specyfikacja funkcjonalności zamawianego oprogramowania.
Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania. Założenia projektowe systemu NETDOC. część 1: założenia ogólne i funkcjonalność rdzenia systemu Założenia ogólne Celem projektu jest
Bardziej szczegółowoKrótka Historia. Co to jest NetBeans? Historia. NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły. Paczki do NetBeans.
GRZEGORZ FURDYNA Krótka Historia Co to jest NetBeans? Historia Wersje NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły NetBeans Profiler Narzędzie do projektowania GUI Edytor NetBeans
Bardziej szczegółowoPHP: bazy danych, SQL, AJAX i JSON
1 PHP: bazy danych, SQL, AJAX i JSON SYSTEMY SIECIOWE Michał Simiński 2 Bazy danych Co to jest MySQL? Jak się połączyć z bazą danych MySQL? Podstawowe operacje na bazie danych Kilka dodatkowych operacji
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE
INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE Ważne pojęcia (I) Warunek testowy (test condition) to element lub zdarzenie modułu lub systemu, który może być zweryfikowany przez jeden lub więcej przypadków
Bardziej szczegółowoZałącznik 1 instrukcje instalacji
Załącznik 1 instrukcje instalacji W poniższym załączniku przedstawione zostaną instrukcje instalacji programów wykorzystanych w trakcie tworzenia aplikacji. Poniższa lista przedstawia spis zamieszczonych
Bardziej szczegółowoObiektowy PHP. Czym jest obiekt? Definicja klasy. Składowe klasy pola i metody
Obiektowy PHP Czym jest obiekt? W programowaniu obiektem można nazwać każdy abstrakcyjny byt, który programista utworzy w pamięci komputera. Jeszcze bardziej upraszczając to zagadnienie, można powiedzieć,
Bardziej szczegółowoWzorce projektowe i refaktoryzacja
Wzorce projektowe i refaktoryzacja Paweł Kozioł p.koziol@students.mimuw.edu.pl 18.01.2005 Moja praca magisterska Narzędzie dla środowiska Eclipse wspierające stosowanie wzorców projektowych J2EE Prowadzący:
Bardziej szczegółowoProcesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Bardziej szczegółowoTestowanie oprogramowania
Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój
Bardziej szczegółowoProgramowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat
Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Program, to lista poleceń zapisana w jednym języku programowania zgodnie z obowiązującymi w nim zasadami. Celem programu jest przetwarzanie
Bardziej szczegółowoUsługa: Audyt kodu źródłowego
Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności
Bardziej szczegółowoTestowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl
Testowanie według modelu (MBT) Bogdan Bereza, Victo MBT testowanie z modelu wersja 2.1 A 1 (48) Pozdrawiam Best regards Med vänliga hälsningar Bogdan Bereza bogdan.bereza@victo.eu +48 519 152 106 Skype:
Bardziej szczegółowoPlan. Wprowadzenie. Co to jest APEX? Wprowadzenie. Administracja obszarem roboczym
1 Wprowadzenie do środowiska Oracle APEX, obszary robocze, użytkownicy Wprowadzenie Plan Administracja obszarem roboczym 2 Wprowadzenie Co to jest APEX? Co to jest APEX? Architektura Środowisko Oracle
Bardziej szczegółowoAUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7
AUREA BPM HP Software TECNA Sp. z o.o. Strona 1 z 7 HP APPLICATION LIFECYCLE MANAGEMENT Oprogramowanie Application Lifecycle Management (ALM, Zarządzanie Cyklem życia aplikacji) wspomaga utrzymanie kontroli
Bardziej szczegółowoWprowadzenie do projektu QualitySpy
Wprowadzenie do projektu QualitySpy Na podstawie instrukcji implementacji prostej funkcjonalności. 1. Wstęp Celem tego poradnika jest wprowadzić programistę do projektu QualitySpy. Będziemy implementować
Bardziej szczegółowoProgramowanie obiektowe
Programowanie obiektowe Laboratorium 1. Wstęp do programowania w języku Java. Narzędzia 1. Aby móc tworzyć programy w języku Java, potrzebny jest zestaw narzędzi Java Development Kit, który można ściągnąć
Bardziej szczegółowoPytania i wyjaśnienia treści Specyfikacji Istotnych Warunków Zamówienia
Warszawa, 11 kwietnia 2013 r. Dotyczy: postępowania prowadzonego w trybie przetargu nieograniczonego na Usługi wsparcia technicznego, utrzymania oraz rozwoju systemu Soprano, Phoenix oraz Register Plus
Bardziej szczegółowoWykład 7. Projektowanie kodu oprogramowania
Wykład 7 Projektowanie kodu oprogramowania Treść wykładu cykl życiowy oprogramowania zagadnienia inżynierii oprogramowania tworzenie oprogramowania z gotowych elementów tworzenie niezawodnego oprogramowania
Bardziej szczegółowoJarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming
Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu
Bardziej szczegółowoZwinna współpraca programistów i testerów z wykorzystaniem BDD i. by Example (JBehave/Spock/SpecFlow)
Program szkolenia: Zwinna współpraca programistów i testerów z wykorzystaniem BDD i Spec Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Zwinna współpraca programistów i testerów
Bardziej szczegółowoProjekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie
Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie
Bardziej szczegółowoSpring Framework - wprowadzenie i zagadnienia zaawansowane
Program szkolenia: Spring Framework - wprowadzenie i zagadnienia zaawansowane Informacje ogólne Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Spring Framework - wprowadzenie i zagadnienia
Bardziej szczegółowoTestowanie I. Celem zajęć jest zapoznanie studentów z podstawami testowania ze szczególnym uwzględnieniem testowania jednostkowego.
Testowanie I Cel zajęć Celem zajęć jest zapoznanie studentów z podstawami testowania ze szczególnym uwzględnieniem testowania jednostkowego. Testowanie oprogramowania Testowanie to proces słyżący do oceny
Bardziej szczegółowoWarstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.
Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy
Bardziej szczegółowoTworzenie oprogramowania
Tworzenie oprogramowania dr inż. Krzysztof Konopko e-mail: k.konopko@pb.edu.pl 1 Tworzenie oprogramowania dla systemów wbudowanych Program wykładu: Tworzenie aplikacji na systemie wbudowanym. Konfiguracja
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoWstęp do Informatyki. Klasyfikacja oprogramowania
Wstęp do Informatyki Klasyfikacja oprogramowania Oprogramowanie komputerowe Funkcjonalność komputera jest wynikiem zarówno jego budowy, jak i zainstalowanego oprogramowania Komputer danej klasy znajduje
Bardziej szczegółowoDokument Detaliczny Projektu
Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej
Bardziej szczegółowoHurtownie danych - przegląd technologii
Hurtownie danych - przegląd technologii Problematyka zasilania hurtowni danych - Oracle Data Integrator Politechnika Poznańska Instytut Informatyki Robert.Wrembel@cs.put.poznan.pl www.cs.put.poznan.pl/rwrembel
Bardziej szczegółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoAutomatyzacja testowania oprogramowania. Automatyzacja testowania oprogramowania 1/36
Automatyzacja testowania oprogramowania Automatyzacja testowania oprogramowania 1/36 Automatyzacja testowania oprogramowania 2/36 Potrzeba szybkich rozwiązań Testowanie oprogramowania powinno być: efektywne
Bardziej szczegółowoPorównanie metod i technik testowania oprogramowania. Damian Ryś Maja Wojnarowska
Porównanie metod i technik testowania oprogramowania Damian Ryś Maja Wojnarowska Testy oprogramowania Testowanie oprogramowania jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów
Bardziej szczegółowoZdalne monitorowanie i zarządzanie urządzeniami sieciowymi
Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Infomatyki Stosowanej Piotr Benetkiewicz Nr albumu: 168455 Praca magisterska na kierunku Informatyka
Bardziej szczegółowoProjektowanie obiektowe Wzorce projektowe. Gang of Four Strukturalne wzorce projektowe (Wzorce interfejsów)
Projektowanie obiektowe Wzorce projektowe Gang of Four Strukturalne wzorce projektowe (Wzorce interfejsów) 1 Roadmap Adapter Bridge Composite Facade 2 Pojęcia obiekt interfejs typ klasa 3 Co to jest delegacja?
Bardziej szczegółowoBezpieczeństwo systemów komputerowych
Bezpieczeństwo systemów komputerowych Jak pisać poprawne programy? Aleksy Schubert (Marcin Peczarski) Instytut Informatyki Uniwersytetu Warszawskiego 6 listopada 2018 Na podstawie: David A. Wheeler Secure
Bardziej szczegółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowoIO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006
IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoAUREA BPM Oracle. TECNA Sp. z o.o. Strona 1 z 7
AUREA BPM Oracle TECNA Sp. z o.o. Strona 1 z 7 ORACLE DATABASE System zarządzania bazą danych firmy Oracle jest jednym z najlepszych i najpopularniejszych rozwiązań tego typu na rynku. Oracle Database
Bardziej szczegółowoWeb frameworks do budowy aplikacji zgodnych z J2EE. Jacek Panachida
Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida Cel pracy Analiza wybranych ram projektowych dostępnych dla platformy Java Warunki selekcji napisany z wykorzystaniem języka Java oraz
Bardziej szczegółowoModel referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami
Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary
Bardziej szczegółowoZarządzanie testowaniem wspierane narzędziem HP Quality Center
Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe
Bardziej szczegółowoPLAN WYNIKOWY PROGRAMOWANIE APLIKACJI INTERNETOWYCH. KL IV TI 6 godziny tygodniowo (6x15 tygodni =90 godzin ),
PLAN WYNIKOWY PROGRAMOWANIE APLIKACJI INTERNETOWYCH KL IV TI 6 godziny tygodniowo (6x15 tygodni =90 godzin ), Program 351203 Opracowanie: Grzegorz Majda Tematyka zajęć 2. Przygotowanie środowiska pracy
Bardziej szczegółowoDokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV
Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium
Bardziej szczegółowoZofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2
Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów
Bardziej szczegółowoWin Admin Replikator Instrukcja Obsługi
Win Admin Replikator Instrukcja Obsługi Monitoring Kopie danych (backup) E-mail Harmonogram lokalne i zewnętrzne repozytorium Logi Pamięć Procesor HDD Administracja sprzętem i oprogramowaniem (automatyzacja
Bardziej szczegółowoRozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ
Załącznik nr 2 do umowy nr 11/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU APLIKACJI CENTRALNEJ Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania realizacją umowy
Bardziej szczegółowoRok szkolny 2015/16 Sylwester Gieszczyk. Wymagania edukacyjne w technikum. ADMINISTROWANIE BAZAMI DANYCH kl. 4c
Wymagania edukacyjne w technikum ADMINISTROWANIE BAZAMI DANYCH kl. 4c Lp. 1 2 4 5 Temat Zasady dotyczące zarządzania projektem podczas prac związanych z tworzeniem bazy oraz cykl życiowy bazy Modele tworzenia
Bardziej szczegółowoTestowanie oprogramowania. Piotr Ciskowski
Testowanie oprogramowania Piotr Ciskowski TESTOWANIE testowanie o proces eksperymentalnego badania programu lub jego komponentu o próbne wykonanie w znanych warunkach o rejestrowanie wyników o ocena właściwości
Bardziej szczegółowoUniwersytet Mikołaja Kopernika. Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej
Uniwersytet Mikołaja Kopernika Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Marcin HENRYKOWSKI Nr albumu: 158069 Praca magisterska na kierunku Informatyka Archiwizacja
Bardziej szczegółowoDiagram wdrożenia. Rys. 5.1 Diagram wdrożenia.
Diagram wdrożenia Zaprojektowana przez nas aplikacja bazuje na architekturze client-server. W tej architekturze w komunikacji aplikacji klienckiej z bazą danych pośredniczy serwer aplikacji, który udostępnia
Bardziej szczegółowoSystem zarządzający grami programistycznymi Meridius
System zarządzający grami programistycznymi Meridius Instytut Informatyki, Uniwersytet Wrocławski 20 września 2011 Promotor: prof. Krzysztof Loryś Gry komputerowe a programistyczne Gry komputerowe Z punktu
Bardziej szczegółowoAutomatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.
Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.pl Obsługa wniosków kredytowych Potrzeba elastyczności
Bardziej szczegółowoJAVA. Java jest wszechstronnym językiem programowania, zorientowanym. apletów oraz samodzielnych aplikacji.
JAVA Java jest wszechstronnym językiem programowania, zorientowanym obiektowo, dostarczającym możliwość uruchamiania apletów oraz samodzielnych aplikacji. Java nie jest typowym kompilatorem. Źródłowy kod
Bardziej szczegółowoCurrenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3
Currenda EPO Instrukcja Konfiguracji Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji - wersja dokumentu 1.3-19.08.2014 Spis treści 1 Wstęp... 4 1.1 Cel dokumentu... 4 1.2 Powiązane dokumenty...
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoCzym jest jpalio? jpalio jpalio jpalio jpalio jpalio jpalio jpalio jpalio
Czym jest jpalio? jpalio to unikalna platforma technologiczna pozwalająca na stworzenie szeregu produktów dostosowanych do indywidualnych preferencji klienta. W naszej ofercie znajduje się m.in. system
Bardziej szczegółowoZapytanie ofertowe 13-09-2013
Zapytanie ofertowe W związku z realizacją projektu współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Działania 8.2 Programu Operacyjnego Innowacyjna Gospodarka 2007-2013,
Bardziej szczegółowo