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

2 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). Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

3 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). Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

4 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

5 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). Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

6 Historia 1950 – oficjalne wprowadzenie osobnego stanowiska testera oprogramowania – oddzielenie debuggingu 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 debuggingu 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) Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

7 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). Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

8 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.). Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

9 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

10 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

11 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

12 Koszty błędów Etap wprowadzenia błędu Etap wykrycia błędu PlanowanieProjektowanieProgramowanieTestyPo zakończeniu Planowanie Projektowanie Programowanie Im wcześniej uda się wykryć błąd tym łatwiej go naprawić! Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

13 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

14 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

15 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

16 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

17 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

18 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

19 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ć). Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

20 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

21 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

22 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

23 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

24 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

25 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

26 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

27 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

28 Testowanie systemu Testowanie oprogramowania Unit testing Integration testing System testing System integration testing 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 GUI software testing Usability testing Performance testing Compatibility testing Error handling testing Load testing Volume testing Stress testing User help testing i inne Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

30 GUI software testing Testowanie oprogramowania Unit testing Integration testing System testing System integration 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 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: o Analiza UI w celu poznania możliwych operacji o Zdefiniowanie stanu początkowego (SP) o Zdefiniowanie stanu końcowego (SK) o Zdefiniowanie ścieżki od SP do SK – staje się planem testowania Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

32 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ć! Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

33 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

34 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

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

36 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

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

38 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ń Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

39 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

40 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

41 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

42 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: o Poufność – sprawdzenie czy nie ma wycieków poufnych danych do użytkowników, którym nie daliśmy prawa do ich czytania o Integralność – pomiar sprawdzający czy dane przychodzące nie zostały zmienione po drodze przez nieuprawnionych użytkowników Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

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

44 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

45 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

46 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

47 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

48 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

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

50 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: o Czasu jaki minął od wywołania operacji sabotażu do momentu pojawienia się błędów w systemie o Czasu jaki zajmuje naprawienie błędów o Ocenie niezawodności systemu dokonywanej na podstawie średniego czasu między kolejno ujawniającymi się problemami w systemie Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

51 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ć Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

52 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: o Preventive maintenance – wprowadza zmiany w systemie, aby zminimalizować ryzyko awarii systemu Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

53 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

54 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 Testowanie oprogramowania Unit testing Integration testing System testing System integration testing

55 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. Testowanie oprogramowania Unit testing Integration testing System testing System integration testing


Pobierz ppt "Piotr Malinowski Marian Mazurowski Michał Orzechowski."

Podobne prezentacje


Reklamy Google