Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Piotr Malinowski Marian Mazurowski Michał Orzechowski

Podobne prezentacje


Prezentacja na temat: "Piotr Malinowski Marian Mazurowski Michał Orzechowski"— Zapis prezentacji:

1 Piotr Malinowski Marian Mazurowski Michał Orzechowski
Rodzaje testów oprogramowania Piotr Malinowski Marian Mazurowski Michał Orzechowski

2 Czym jest testowanie oprogramowania?
Unit testing Integration testing System testing System integration testing Czym jest testowanie oprogramowania? Testowanie oprogramowania to proces oceny jakości aplikacji. Jest to technika empiryczna zapewniająca interesariuszom śledzenie na bieżąco postępów w pracy nad jakością systemu. Proces ten zawiera, ale nie ogranicza się do wykonywania programu w celu wyszukania błędów. Ocena jakości nigdy nie jest bezwzględna. Jest zawsze zależna np. od osoby testującej czy intencji danego testu. Może odnosić się do konkurencyjnego oprogramowania lub opisu wymagań i jest to bardziej forma krytyki niż rzeczywistej oceny. Zależna jest również od tego do kogo kierowany jest produkt (gry komputerowe / system bankowy).

3 Software Quality Assurance
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Software Quality Assurance Rozpatrywana jest również jako cześć SQA (Software Quality Assurance), która jest metodologią biznesową i której model w postaci RUP-a poznaliśmy. W SQA specjaliści od inżynierii oprogramowania pracują nie tylko nad rozwojem aplikacji, ale też procesu jej powstawania, tak aby był on możliwie najefektywniejszy i przyczyniał się do redukcji błędów. Zasadniczą rolę odgrywa poziom tolerancji błędów (gra komputerowa symulująca lot samolotem, a oprogramowanie kontrolujące lot rzeczywistym samolotem).

4 Powstawanie błędów Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Powstawanie błędów Pomyłka programisty owocuje błędem w kodzie programu (bug), co może objawiać się nie działaniem danej funkcjonalności („wysypywanie się programu”) bądź błędnymi wynikami działania. Pewne błędy mogą również pojawiać się dopiero w pewnych środowiskach (system operacyjny) lub przy (nie)odpowiedniej konfiguracji sprzętowej. Problemem w odnajdowaniu błędów jest ich potencjalna ilość. Zazwyczaj niemożliwe jest przeprowadzenie testów wszystkich funkcjonalności dla wszystkich możliwych danych wejściowych we wszystkich środowiskach i konfiguracjach sprzętowych. Pewne cechy trudno jednoznacznie ocenić , np.: skalowalność, przenośność, niezawodność. Poziom zadowalający dla jednej osoby, dla innej może być nie do przyjęcia.

5 Błędy a testy Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Błędy a testy Statyczne testy to wszelkiego typu dozór, kontrola, przeglądy, badania i inspekcje w trakcie budowy aplikacji. Testy dynamiczne to uruchamianie programu na określonym poziomie rozwoju dla określonego zestawu ścieżek testowych. Weryfikacja – „tworzenie oprogramowania włąściwie” (np. zgodność ze specyfikacją). Walidacja – „tworzenie właściwego oprogramowania” (np. zgodność z wyobrażeniem i oczekiwaniami klienta).

6 Historia Testowanie oprogramowania Unit testing Integration testing
System testing System integration testing Historia 1950 – oficjalne wprowadzenie osobnego stanowiska testera oprogramowania. 1979 – oddzielenie debugging’u od testowania (Glenford J. Myers) 1988 – klasyfikacja faz i celów testowania oprogramowania na etapy (dr Dave Gelperin i dr William C. Hetzel): do 1956 – zorientowanie na debugging (brak rozróżnienia debugging’u od testowania) zorientowanie na demonstrację (pokazywanie, że aplikacja spełnia wymagania) zorientowanie na destrukcję (znajdowanie i eliminacja błędów) zorientowanie na wycenę (szacowanie i mierzenie jakości oprogramowania) zorientowanie na prewencję (zapobieganie powstawaniu błędów + wykazywanie spełniania specyfikacji)

7 Metody Testowanie oprogramowania Unit testing Integration testing
System testing System integration testing Metody Czarna skrzynka – oprogramowanie traktowane jest jako „czarna skrzynka”, do której nie możemy zajrzeć i której sposobu działania nie analizujemy. Ma na celu sprawdzenie, czy funkcjonalność jest zgodna z wymaganiami. Tester musi potrafić ocenić czy dla określonych wprowadzonych danych wejściowych otrzymał odpowiednie dane wyjściowe, bądź czy reakcja systemy była właściwa (opis w ścieżkach testowych). Biała (szklana, przezroczysta) skrzynka – tester ma dostęp do wszystkich wewnętrznych struktur danych, kodu i algorytmów. Metody białej skrzynki umożliwiają uzupełnienie testów czarnej skrzynki dzięki przygotowaniu testów dla wszystkich (nawet najrzadziej używanych) funkcjonalności („pokrycie funkcjonalności”) i wszystkich linii kodu („pokrycie kodu”).

8 Dodatkowe metody Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Dodatkowe metody Szara skrzynka– coraz popularniejsza metoda mieszana. Dopuszcza wgląd do struktur danych i algorytmów w celu przygotowania odpowiednich testów, ale samo testowanie odbywa się na poziomie czarnej skrzynki. Metody specjalne – testowanie niefunkcjonalnych aspektów systemu, jak np. wydajności (ogromne ilości danych bądź użytkowników), użytkowalności (intuicyjność interfejsu), bezpieczeństwa (poufność danych, odporność na atak), lokalizacji (wielojęzyczność itp.).

9 Proces testowania Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Proces testowania Najpopularniejszymi praktykami są: rozpoczęcie fazy testów przez niezależną grupę testerów po zakończeniu prac nad wszystkimi funkcjonalnościami, a przed dostarczeniem produktu klientowi; rozpoczęcie testów wraz z rozpoczęciem prac nad systemem i kontynuowanie ich aż do zakończenia projektu. Niektóre metodologie i praktyki (np. programowanie ekstremalne) proponują pisanie testów poszczególnych jednostek programu przez programistów, jeszcze przed rozpoczęciem kodowania. Testy te z założenia początkowo się nie powodzą, ale z czasem jak aplikacja powstaje coraz więcej warunków jest spełnianych. Wraz z rozwojem programu rozwijają się jednak i testy – gdy jedne ścieżki testowe są już sprawdzone powstają nowe, które początkowo kończą się fiaskiem.

10 Cztery poziomy testów Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Cztery poziomy testów Testowanie jednostek – testowanie możliwie najmniejszych komponentów bądź modułów systemu. Każda podstawowa jednostka jest dokładnie testowana w celu sprawdzenia poprawności jej implementacji. W obiektowo zorientowanych środowiskach programistycznych odbywa się to zazwyczaj na poziomie klas. Testowanie spójności – ma na celu odnalezienie błędów w interfejsie oraz w interakcjach pomiędzy poszczególnymi jednostkami. Testowanie systemu – testowanie kompletnego systemu w celu sprawdzeniu zgodności z wymogami. Testowanie spójności systemu – sprawdzanie, czy system prawidłowo współgra z innymi systemami.

11 Inne popularne praktyki
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Inne popularne praktyki Testy alfa – testy przeprowadzane przez potencjalnych użytkowników/klientów lub niezależną grupę testerów, od strony twórców aplikacji. Testy beta – następują po testach alfa. „Beta wersja” oprogramowania dostarczana jest ograniczonej publice spoza zespołu programistycznego (w wyjątkowych sytuacjach udostępnia się ją publicznie), która korzystając z systemu w praktyce testuje go. Dopiero po testach alfa i beta system trafia do klienta. Testy regresji – po każdych zmianach w programie, czy to z powodu zmian funkcjonalności, czy też naprawy błędów, należy ponownie przejść wszystkie wcześniej zdane testy, aby upewnić się że zmiany nie spowodowały przypadkowych błędów tam, gdzie wcześniej ich nie było. Testy regresji często są automatyczne.

12 Koszty błędów Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Koszty błędów Im wcześniej uda się wykryć błąd tym łatwiej go naprawić! Etap wprowadzenia błędu Etap wykrycia błędu Planowanie Projektowanie Programowanie Testy Po zakończeniu 1 3 5-10 10 10-100 15 25-100 10-25

13 Artefakty Testowanie oprogramowania Unit testing Integration testing
System testing System integration testing Artefakty Ścieżki testowe (test cases) – dokument składający się ze struktur zdarzenie-akcja-wejście-wyjście-spodziewany_wynik-rzeczywisty_wynik. Może być opisany na różnym poziomie szczegółowości (np. dla każdej ścieżki jedno zdanie albo dokładny opis poszczególnych kroków). Skrypt (test script) – kombinacja ścieżki testowej, opisu procedury i danych testowych. Pisane ręcznie, bądź generowane automatycznie. Komplet testów (test suite) – zestaw ścieżek testowych, często zawierający więcej bardziej szczegółowych instrukcji i celów każdej grupy ścieżek testowych. Plan testu (test plan) – specyfikacja, dokładny opis planowanego testu.

14 Na czym polega Unit testing?
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Na czym polega Unit testing? Testowanie jednostek jest to procedura, która rozstrzyga, czy dana jednostka testowanej aplikacji działa poprawnie. Przez jednostkę rozumiemy najmniejszą możliwą do testowania część aplikacji. W programowaniu proceduralnym może to być procedura, funkcja itp., w programowaniu obiektowym – metoda.

15 Na czym polega Unit testing?
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Na czym polega Unit testing? Przypadki testowe powinny być skonstruowane niezależnie. W celu zapewnienia ich izolacji można używać tzw. próbnych i sztucznych obiektów (mock and fake objects). Są to obiekty naśladujące działanie prawdziwych obiektów. Fake objects mają zaimplementowane prosto ten sam interfejs, co obiekt, który naśladują i zwracają z góry zaaranżowane wartości. Mock objects mają zaimplementowane metody, które symulują zachowanie właściwego obiektu w kontrolowanym kierunku.

16 Korzyści Testowanie oprogramowania Unit testing Integration testing
System testing System integration testing Korzyści Podzielenie programu na niezależne jednostki i przetestowanie ich pozwala na udowodnienie, że są one poprawnie skonstruowane. Wynika z tego szereg korzyści.

17 Korzyści – ułatwianie zmian
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Korzyści – ułatwianie zmian Jeżeli programista chce zmienić metody, procedury czy funkcje, testowanie jednostek pozwala na szybkie sprawdzenie czy aplikacja dalej działa poprawnie, a w przypadku stwierdzenia błędów, izolacja jednostek pozwala na szybkie znalezienie ich przyczyny.

18 Korzyści – upraszczanie integracji
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Korzyści – upraszczanie integracji Testowanie jednostek można używać jako styl testowania wstępującego. Testuje się wtedy najmniejsze jednostki, następnie ich sumę itd., co znacznie ułatwia przeprowadzenie testów spójności. Powstaje pytanie potrzeby fizycznego testowania spójności. Jest ono jednak potrzebne, ponieważ podczas testowania spójności mogą pojawić się dodatkowe aspekty, które mogą być udowodnione/wykryte tylko podczas tego procesu. W praktyce potrzeba taka zależy od charakterystyki produktu, i intencji twórców.

19 Korzyści – dokumentacja
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Korzyści – dokumentacja Testowanie jednostek dostarcza dużą część dokumentacji. Użytkownicy, którzy uczą się funkcjonalności systemu mogą skorzystać z przypadków testowych, które dokładnie opisują przykładowe wykorzystanie danych funkcjonalności wraz ze spodziewanymi wynikami. Plusami typowej dokumentacji są natomiast odejście od implementacji, wrażliwość na aktualizacje (np.. zmiana designu aplikacji, której przypadki testowe mogą nie uwględnić).

20 Odseparowanie jednostek
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Odseparowanie jednostek Przy testowaniu jednostek szczególną uwagę powinno się poświęcić na odseparowanie jednostek od siebie. Nie zawsze jest to oczywiste. Weźmy np. klasę, która korzysta z bazy danych. Testując tą klasę (jej metodę) nie powinno się ingerować w bazę danych. Dlatego w takich przypadkach tworzy się tzw. próbne i sztuczne obiekty (mock and fake objects), które naśladowałyby w tym przypadku bazę danych. Takie postępowanie znacznie zwiększa jakość testów.

21 Ograniczenia Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Ograniczenia Jak każdy rodzaj testów, testowanie jednostek nie dowodzi braku błędów w aplikacji a jedynie może dowieść istnienie błędu. Poprzez podzielenie aplikacji na małe jednostki po przeprowadzeniu testów jednostek możemy z dużym prawdopodobieństwem oczekiwać, że jednostki te nie zawierają błędów same w sobie. Nie wychwyci się jednak w ten sposób błędów spójności i innych wysokopoziomowych problemów. Testowanie jest najbardziej efektywne w połączeniu z innymi rodzajami testów.

22 Ograniczenia Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Ograniczenia Testowanie aplikacji jest bardzo złożonym procesem. Na każdą linię kodu przypadają średnio 3-5 linii „kodu” testów. Aby osiągnąć jak największe korzyści z testowania jednostek niezbędne jest zapisywanie każdego kroku/zmiany w kodzie aplikacji. W tym celu powinno się korzystać z systemu kontroli wersji. W przypadku, gdy przed zmianą kodu dana jednostka przeszła testy pozytywnie, a po zmianie test dał wynik negatywny, programista nie będzie miał problemu z wykryciem błędu ew. powrotem do poprzedniej wersji kodu.

23 eXtreme Programming Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing eXtreme Programming Testowanie jednostek jest częścią metodologii programowania Extreme Programming (XP). W paru słowach XP można opisać jako programowanie polegające na tworzeniu w procesie iteracji małych fragmentów kodu, opartych na przypadkach użycia (use cases), najczęściej generowanych na podstawie potrzeb określonych prze klienta. Dla programistów XP ważną częścią procesu tworzenia kodu jest testowanie - tworzenie na podstawie przypadków użycia szeregu testów, które dany fragment kodu (metoda, klasa, komponent a w końcu cała aplikacja) musi "zaliczyć". Jednocześnie otrzymuje się świadomość stworzenia produktu odpowiadającego potrzebom klienta, spełniającym wszelkie określone przez niego zadania.

24 Testowanie spójności Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Testowanie spójności Testowanie spójności (integration testing / integration and testing / I&T) jest to faza testowania oprogramowania, w której moduły łączy się w grupy i testuje interakcje między nimi. Następuje po testowaniu jednostek, a przed testowaniem systemu. Moduły przetestowane w fazie testowania jednostek grupuje się, łączy i testuje zgodnie z planem (patrz: artefakty) przygotowanym specjalnie dla testów spójności. Później łączone są kolejne grupy, aż otrzymujemy pełen system gotowy do kolejnej fazy – testowania systemu.

25 Metoda Testowanie oprogramowania Unit testing Integration testing
System testing System integration testing Metoda Interfejsy połączonych grup jednostek testuje się zazwyczaj metodą czarnej skrzynki. Współdzielenie danych oraz komunikację między procesami sprawdza się używając odpowiednich symulatorów, sztucznie wprowadzonych odpowiedników itp. W ścieżkach testowych zakłada się, że każda jednostka osobno została gruntownie przetestowana w fazie testowania jednostek i działa bezbłędnie. Testuje się więc np. czy prawidłowo działa wywołanie bądź aktywowanie obcej procedury/metody itp., a nie czy sama procedura/metoda działa właściwie.

26 Big Bang Testowanie oprogramowania Unit testing Integration testing
System testing System integration testing Big Bang Big Bang to typ testowania spójności w którym wszystkie, bądź większość modułów, łączy się do razu w kompletny system lub przynajmniej jego główną część i testuje w takiej postaci. Metoda ta pozwala oszczędzić czas, ale ścieżki testowe muszą zostać bardzo dobrze przygotowane specjalnie do takiej formy testów. W przeciwnym razie może zakończyć się to jedynie komplikacjami i chaosem spowodowanym problemami z określeniem przyczyn błędów.

27 Z dołu do góry Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Z dołu do góry Wszystkie moduły, procedury i funkcje z najniższego poziomu są łączone i testowane. Następnie tworzy się kolejne poziomy wszystkich modułów i za każdym razem testuje ich spójność. Takie podejście nosi nazwę testowania z dołu do góry (Bottom Up). Jest ono przydatne jedynie gdy mamy gotowe wszystkie (lub przynajmniej większość) modułów na tym samym poziomie. Metoda ta pomaga również określać poziom rozwoju systemu i czyni łatwiejszym raportowanie postępu w pracy.

28 Testowanie systemu Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Testowanie systemu Jest to testowanie gotowego systemu pod kątem jego zgodności z wymaganiami Jest to testowanie typu black box Test wykonywany jest na komponentach które pozytywnie przeszły test integracji Celem jest znalezienie niespójności między jednostkami tworzącymi system albo samym systemem i sprzętem na którym on pracuje Testowanie przeprowadza się w zakresie wymagań funkcjonalnych oraz systemowych, choć często uwzględnia się też wymagania poza funkcjonalne Testuje nie tylko zaprojektowanie i zachowanie systemu, ale nawet to w jakim stopniu będzie on spełniał oczekiwania klienta Testowanie systemu ma często charakter destrukcyjny

29 Rodzaje testów systemu
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Rodzaje testów systemu GUI software testing Usability testing Performance testing Compatibility testing Error handling testing Load testing Volume testing Stress testing User help testing i inne

30 GUI software testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing GUI software testing Jest to testowanie systemów używających graficznego interfejsu użytkownika Stworzenie przypadków użycia i przetestowanie programu, uciążliwe i szczególnie trudne przy tzw. testowaniu regresywnym (regression testing) Wielość operacji np. WordPad ma 325 GUI operacji Problem prześledzenia sekwencji wykonywania działań – złożoność wykładnicza Np. żeby otworzyć plik: File Menu->Open, używamy okna dialogowego do wpisania nazwy pliku, przełączyć obsługę do nowo otwartego okna itd. Zawodność testów przy częstych zmianach oprogramowania – ścieżka śledzenia wykonania polecenia może nie działać właściwie, gdy np. button w nowej wersji programu znajduje się w innym położeniu

31 Podejście do testowania GUI
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Podejście do testowania GUI Wykorzystanie sztucznej inteligencji do rozwiązania problemu Skupienie się na 4 stanach : początkowym, docelowym, operacjach do wykonania, obiekty na których będziemy operować Kroki: Analiza UI w celu poznania możliwych operacji Zdefiniowanie stanu początkowego (SP) Zdefiniowanie stanu końcowego (SK) Zdefiniowanie ścieżki od SP do SK – staje się planem testowania

32 Automatyczne generowanie przypadków użycia GUI
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Automatyczne generowanie przypadków użycia GUI Automatyczne generowanie przypadków użycia jest lepsze – nie ma ryzyka pisania testów dla błędnego przypadku użycia Generuje poprawną sekwencyjność operacji Daje czytelny obraz systemu skupiając się na znaczących przypadkach użycia, dzięki temu wiemy co testować, a nie zastanawiamy się jak testować!

33 Usability testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Usability testing Jest to test wykonywany przez użytkowników Mierzy użyteczność i łatwość obsługi systemu Prosty sposób na odkrycie wad systemu oraz niedociągnięć i braków w funkcjonalności

34 Cele usability testing:
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Cele usability testing: Wydajność – ile czasu zajmuje użytkownikom wykonywanie operacji Łatwość obsługi – czy użytkownicy z łatwością poruszają się po systemie Intuicyjność – czy użytkownik po długim czasie nie używania systemu jest w stanie z łatwością się w nim poruszać Przyjazność – jak użytkownik czuje się używając systemu

35 Performance testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Performance testing Testy wydajności Mają na celu przetestowanie szybkości działania systemu, jego niezawodności, kompatybilności z innymi systemami itp.

36 Kroki przy testowaniu wydajności
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Kroki przy testowaniu wydajności Identyfikacja środowiska pracy (hardware, software, sieć) Zdefiniowanie celu (operacja do wykonania, planowany czas wykonania) Zdefiniowanie scenariusza wykonania (dane, zmienne itp.) Przygotowanie środowiska do testów (odpowiedni system, biblioteki itp.) Przygotowanie testu Wykonanie testu Analiza uzyskanych rezultatów

37 Compatibility testing
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Compatibility testing Bada kompatybilność systemu z: Innymi aplikacjami Systemem operacyjnym Siecią internetową Przeglądarkami internetowymi Bazami danych Sprzętem komputerowym itd.

38 Load testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Load testing Polega na obciążeniu systemu dużą ilością danych i zbadaniu szybkości jego odpowiedzi W tym testowaniu liczą się jedynie realne wyniki uzyskane podczas testów, a nie te uzyskane z teoretycznych wyliczeń

39 Load testing – przykłady:
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Load testing – przykłady: Nawiązanie wielu połączeń z systemem typu klient/serwer Wczytanie wielkiego pliku graficznego do przeglądarki graficznej Genracja w arkuszu kalkulacyjnym raportów na temat sprzedaży z kilku lat

40 Volume testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Volume testing To testowanie systemu dla ściśle określonych rozmiarów danych Np. testowanie działania systemu dla bazy o 1000 rekordach lub testowanie operacji odczytu/zapisu na pliku o rozmiarze 10MB.

41 Stress testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Stress testing To testowanie stabilności systemu Polega na przeładowaniu systemu danymi i obserwowaniu jego zachowania Skupia się na sprawdzeniu wytrzymałości systemu, jego stabilności oraz umiejętności radzenia sobie z błędami Głównym celem jest sprawdzenie czy system poradzi sobie przy niewystarczających zasobach systemowych (pamięć, przestrzeń na dysku) lub czy przetrzyma np. atak typu DOS

42 Security testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Security testing Ma na celu sprawdzenie czy system chroni dane i pozostaje tak funkcjonalny jak to zaplanowano Sfery podawane próbie w tym teście to: Poufność – sprawdzenie czy nie ma wycieków poufnych danych do użytkowników, którym nie daliśmy prawa do ich czytania Integralność – pomiar sprawdzający czy dane przychodzące nie zostały zmienione po drodze przez nieuprawnionych użytkowników

43 Security testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Security testing Autentyfikacja – czy system poprawnie weryfikuje źródło pochodzenia informacji jej typ oraz rodzaj transmisji Autoryzacja – sprawdzenie czy użytkownik wywołujący daną operację jest uprawniony do otrzymania danych lub wykonania polecenia Dostępność – system musi zapewniać dostępność informacji i usług wtedy kiedy jest to wymagane Monitorowanie aktywności – przetestowanie funkcji pozwalających na śledzenie poczynań użytkowników w systemie i operacji przez nich wykonywanych

44 Scalability testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Scalability testing To test polegający na mierzeniu sklowalności systemu, czyli jego umiejętności do powiększania się i radzenia sobie z większymi ilościami danych, obsługą nowych zadań itp. Np. dodanie nowych plansz w grze, trybów rogrywki, przeciwników i obłsugiwanych przez gre platform

45 Sanity testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Sanity testing Jest to forma szybkiego sprawdzenia poprawności wykonywanych operacji Polega na zgrubnym przejrzeniu funkcji systemu i sprawdzeniu czy działają one zgodnie z założeniami Jest to faza poprzedzająca bardziej wnikliwe formy testów systemu

46 Smoke testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Smoke testing Kolekcja testów systemu dotykająca szerokiego spektrum jego działania, ale nie zagłebiająca się w szczegóły Odpowiada na najbardziej podstawowe pytania: „czy aplikacja w ogóle się uruchamia?”, „czy otwiera się w okienku?”, „Czy przyciśnięcie przycisku wywołuje jakąś reakcję” itp. Przejście tego testu jest warunkiem koniecznym rozpoczęcia jakichkolwiek innych testów systemu

47 Ad hoc testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Ad hoc testing Testy wykonywane bez planu i dokumentacji Zazwyczaj wykonywane jednorazowo, chyba, że zostanie znaleziony błąd Cechują się improwizacyjnym podejściem do testowania, a znalezienie błędu często zależy od umiejętności i podejścia do problemu przez testującego system Są szybkie, ale raczej nie testują obiektywnie i gruntownie sytemu, dlatego powinny być używane jako uzupełnienie innych testów

48 Regression test Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Regression test Testowanie nastawione na poszukiwanie odkrytych już wcześniej błędów Ten typ testowania dotyczy programów, które działały poprawnie, ale na skutek modyfikacji przestały działać zgodnie z wymaganiami Wykryte błędy są zapamiętywane i testowanie pod kątem ich obecności jest wykonywane dla każdej kolejnej wersji systemu

49 Regression test Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Regression test Typy regresji: Lokalne (local) – zmiany w systemie powodują powstanie nowych błędów Zdekonspirowane (unmasked) – zmiany w systemie ujawniają poprzednio istniejące błędy Zdalne (remote) – zmiana jednej części systemu powoduje powstanie błędów w innej części

50 Recovery testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Recovery testing Test ten sprawdza jak szybko system jest w stanie odzyskać pełną sprawność po wystąpieniu błędów lub awarii sprzętowych Testowanie polega na celowym wywołaniu awarii i zmierzeniu: Czasu jaki minął od wywołania operacji sabotażu do momentu pojawienia się błędów w systemie Czasu jaki zajmuje naprawienie błędów Ocenie niezawodności systemu dokonywanej na podstawie średniego czasu między kolejno ujawniającymi się problemami w systemie

51 Recovery testing - przykłady
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Recovery testing - przykłady Restart systemu podczas jego działania i sprawdzenie integralności danych po jego ponownym uruchomieniu Odłączenie kabla sieciowego podczas pobierania danych z sieci, potem podłączenie go ponownie i sprawdzenie czy ściąganie danych jest kontynuowane od miejsca przerwania Zrestartowanie systemu z kilkoma otwartymi sesjami przeglądarki internetowej i sprawdzenie czy system jest w stanie je przywrócić

52 Maintenance testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Maintenance testing Są to okresowe testy mające dać informacje o stanie systemu Jest to niejako przegląd techniczny Typy działań dla których możemy przeprowadzać testy typu maintenance: Preventive maintenance – wprowadza zmiany w systemie, aby zminimalizować ryzyko awarii systemu

53 Maintenance testing Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Maintenance testing Corrective maintenance – poprawia problemy, które pojawiły się podczas działania systemu Perfective maintenance – udoskonalenia w zakresie bezpieczeństwa, niezawodności, wydajności itp. systemu Adaptive maintenance – działania mające na celu sprostanie wymaganiom stawianym przez środowisko, rynek itp.

54 Accessibility Testowanie oprogramowania Unit testing
Integration testing System testing System integration testing Accessibility Należy przetestować zgodność aplikacji/systemu/strony www ze standardami może to się wiązać np. z przepuszczeniem danego dokumentu przez walidator itp. Trzeba zadbać o opcje ułatwiające obsługę systemu przez ludzi z dysfunkcjami ruchowymi

55 Na czym polega System Integration Testing?
Testowanie oprogramowania Unit testing Integration testing System testing System integration testing Na czym polega System Integration Testing? Jest to procedura testowania współdziałania aplikacji z innymi aplikacjami. Polega ona na zebraniu wielu aplikacji (wcześniej przetestowanych „wewnętrznie”) i przebadaniu ich interakcji.


Pobierz ppt "Piotr Malinowski Marian Mazurowski Michał Orzechowski"

Podobne prezentacje


Reklamy Google