Tworzenie przypadków testowych



Podobne dokumenty
Zawód tester, czyli na czym polega testowanie. Katarzyna Łabinska Justyna Sacha - Gawlik

Testowanie oprogramowania. Testowanie oprogramowania 1/34

Przypadki bez przypadków. Jak dobierać scenariusze testowe.

Dlaczego testowanie jest ważne?

Rozdział 5: Zarządzanie testowaniem. Pytanie 1

Testujemy dedykowanymi zasobami (ang. agile testers)

Testy poziom po poziomie

Session Based Testing Czyli eksploracyjne testowanie w sesjach. Karolina Bilewska PapryQArz

Testowanie oprogramowania. Piotr Ciskowski

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

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

Testowanie I. Celem zajęć jest zapoznanie studentów z podstawami testowania ze szczególnym uwzględnieniem testowania jednostkowego.

Maciej Oleksy Zenon Matuszyk

Praktyka testowania dla początkujących testerów

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Wykład 8. Testowanie w JEE 5.0 (1) Autor: Zofia Kruczkiewicz. Zofia Kruczkiewicz

Automatyzacja testowania oprogramowania. Automatyzacja testowania oprogramowania 1/36

Wdrożenie technologii procesowej IBM BPM w EFL

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta

Projektowanie zorientowane na uŝytkownika

Testowanie oprogramowania w środowisku IBM Rational Software Architect

Testowanie i walidacja oprogramowania

Przeszukiwanie z nawrotami. Wykład 8. Przeszukiwanie z nawrotami. J. Cichoń, P. Kobylański Wstęp do Informatyki i Programowania 238 / 279

Zarządzanie konfiguracją produktu w całym cyklu Ŝycia. Aleksandra Grzywak-Gawryś Warsztaty Rola IRIS w branŝy kolejowej

Etapy życia oprogramowania

Zarządzanie Testowaniem Oprogramowania

Certyfikowany tester Pytania przykładowe do poziomu podstawowego

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 6 Modelowanie przypadków uŝycia i czynności. Materiały dla studentów

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

Politechnika Białostocka Wydział Elektryczny Katedra Automatyki i Elektroniki. ĆWICZENIE Nr 4 (3h) Przerzutniki, zatrzaski i rejestry w VHDL

Testowanie i walidacja oprogramowania

Microsoft Test Manager

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

Projekt: Narzędzia zarządzania testowaniem badanie narzędzia. Część 2.3 Badanie Synapse RT

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

Laboratorium przedmiotu Technika Cyfrowa

Opis metodyki i procesu produkcji oprogramowania

Automatyczne generowanie testów z modeli. Bogdan Bereza Automatyczne generowanie testów z modeli

ISO w Banku Spółdzielczym - od decyzji do realizacji

Pytania próbne ISTQB CTFL 1 110

Modelowanie testów. czyli po co testerowi znajomość UML

Najwyżej ocenione raporty dla Mr Buggy 4

Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

Inżynieria oprogramowania II

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

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Języki i metodyka programowania

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Porównanie metod i technik testowania oprogramowania. Damian Ryś Maja Wojnarowska

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.

Szablon Planu Testów Akceptacyjnych

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

1 Wprowadzenie do algorytmiki

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style

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

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Priorytetyzacja przypadków testowych za pomocą macierzy

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

Procesowa specyfikacja systemów IT

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

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

Drzewa Decyzyjne, cz.2

Projektowanie oprogramowania

Analityk i współczesna analiza

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

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

Diagramy przypadków uŝycia. związków między nimi

"Szara codzienność" analityka czyli jak ułatwić sobie pracę: Usecase

bo od managera wymaga się perfekcji

Technologie informacyjne - wykład 12 -

Elżbieta Kula - wprowadzenie do Turbo Pascala i algorytmiki

PROJEKT Z BAZ DANYCH

Fuzzing OWASP The OWASP Foundation Piotr Łaskawiec J2EE Developer/Pentester

SYSTEMY CZASU RZECZYWISTEGO STEROWNIK WIND. Dokumentacja projektu. Danilo Lakovic. Joanna Duda. Piotr Leżoń. Mateusz Pytel

Systemy zabezpieczeń

Testowanie oprogramowania

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

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

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela

Krótkie wprowadzenie do ModelSim i Quartus2

Zagadnienia. Podejścia do procesu testowania Testowanie typu black box Testowanie typu white box Weryfikacja statyczna - review

Technologia informacyjna

Dane wejściowe. Oracle Designer Generowanie bazy danych. Wynik. Przebieg procesu

MSF. Microsoft Solution Framework

PROLOG WSTĘP DO INFORMATYKI. Akademia Górniczo-Hutnicza. Wydział Elektrotechniki, Automatyki, Informatyki i Inżynierii Biomedycznej.

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Kod doskonały : jak tworzyć oprogramowanie pozbawione błędów / Steve McConnell. Gliwice, cop Spis treści. Wstęp 15.

Optymalizacja Automatycznych Testów Regresywnych

Usługa: Testowanie wydajności oprogramowania

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Weryfikacja i walidacja. Metody testowania systemów informatycznych

Wstęp do Techniki Cyfrowej... Teoria automatów

Jak efektywnie wykrywać podatności bezpieczeństwa w aplikacjach? OWASP The OWASP Foundation

Spis treści. Przedmowa Karolina Zmitrowicz, Adam Roman. Część I. Organizacja i procesy 1

Testowanie II. Cel zajęć. Pokrycie kodu

Przypadek testowy. Teoria i praktyka

Testowanie oprogramowania

ECDL Podstawy programowania Sylabus - wersja 1.0

Transkrypt:

Tworzenie przypadków testowych Prowadząca: Katarzyna Pietrzyk Agenda 1. Wprowadzenie 2. Wymagania 3. Przypadek testowy Definicja Schemat Cechy dobrego przypadku testowego 4. Techniki projektowania Czarnej skrzynki Białej skrzynki Oparte na doświadczeniu 5. Test scenariusze 6. Metryki

To juŝ było Testowanie Poziomy testów Rodzaje testów Wymagania Definiowane przez uŝytkowników Przetwarzane przez analityka Analizowane/Weryfikowane przez testera Implementowane przez developera Testowane przez testera

Testowalność [1/2] The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. [IEEE] Testowalność [2/2] Przegląd (ang.review) wymagań jest najbardziej efektywną drogą walidacji wymagań. Defekty, które nie będą znalezione podczas przeglądu wymagań będą wnoszone do kolejnych faz produkcji oprogramowania. Naprawienie defektów staje się coraz droŝsze. Cechy dobrze zdefiniowanych wymagań: jednoznaczność kompletność spójność modyfikowalność śledzalność uŝyteczność (wtórna) weryfikowalność

Przypadek testowy [1/2] (ang. Test case) Zbiór wejść, warunków początkowych oraz oczekiwanych wyników i warunków końcowych utworzony, aby wykonać określonąścieŝkę w programie albo aby zweryfikować zgodność z określonym wymaganiem. [IEEE 610] 1. Unikalny identyfikator, nazwa Przypadek testowy [2/2] 2. Opis, co sprawdza dany przypadek testowy (ang. Test case) 3. Warunki, jakie muszą zostać spełnione zanim przystąpimy do wykonywania przypadku testowego Id Opis Wykonywanej czynności Id: Nazwa Oczekiwane rezultaty Aktualny rezultat Status 4. Pojedyncza czynność, którą naleŝy wykonać 1 5. Spodziewane rezultaty wykonania czynności 2 6. Wynik poprawnego wykonania przypadku testowego

Cechy dobrego przypadku testowego Znajduje defekty (maksymalną ilość) Weryfikuje poprawność (działania) systemu/zgodność z wymaganiami Określa stabilność/wiarygodność systemu Minimalizuje koszty wsparcia (ang.support) i utrzymania (ang.maintenance) Szacuje/zapewnia jakość systemu Dopasowany do tego, co chcemy sprawdzić Techniki projektowania 1. Techniki czarnej szkrzynki (ang.black-box) 2. Techniki białej skrzynki (ang.white-box) 3. Techniki oparte na doświadczeniu (ang.experience based)

Techniki czarnej skrzynki (ang.black-box) Zakładana jest znajomość wymagań dla testowanej funkcjonalności. Wprowadzamy dane wejściowe i analizujemy wyniki otrzymywane na wyjściu. System jest traktowany jak czarna skrzynka, która działa w nieznany sposób. Dane wejściowe Czarna skrzynka Dane wyjściowe Klas równowaŝności (equivalence partitioning) Wartości granicznych (boundary value analysis) Technika oparta o przejścia stanów (state transition testing) Technika oparta o tabele decyzyjne (decision table testing) Technika oparta o przypadki uŝycia (use case testing) Technika klas równowaŝności Wszystkie moŝliwe wartości dzielone są na klasy (równowaŝności), takie Ŝe: Istnieje skończona ilość tych klas System zachowuje się analogicznie dla wartości z tej samej klasy Test dla jednego z kaŝdej klasy jest wystarczający Jeśli dla jednego przypadku wystąpi defekt, dla pozostałych przypadków równieŝ Zminimalizowanie liczby wykonywanych przypadków testowych Wybór właściwych przypadków testowych, aby pokryć wszystkie moŝliwe scenariusze Przykład: Parametr miesiąc w dacie.... -2-1 0 1... 12 13 14 15... -------------------- ------------------------- --------------------- niepoprawne wartości 1 poprawne wartości niepoprawne wartości 2

Technika wartości granicznych Badane jest zachowanie systemu dla wartości granicznych Technika ta jest często traktowana jako rozszerzenie poprzedniej techniki DuŜo większe prawdopodobieństwo niepoprawnego zachowania testowanej funkcjonalności na krańcach klas równowaŝności Krańce minimalne, maksymalne wartości Testujemy zarówno wartości poprawne jak i niepoprawne Przykład: W bazie rejestrowane są osoby w wieku 0-10 lat [-1,0,1,10,11] Technika oparta o przejście stanów [1/2] Przypadki testowe są projektowane tak, aby sprawdzić: kaŝde przejście pomiędzy stanami, sekwencję przejść, kaŝdy stan, typową sekwencję stanów.

Technika oparta o przejście stanów [2/2] Przykład: Maszyna pracuje zgodnie z prezentowanym diagramem stanów 0 1 1 Stan wej. 1 0 S1 S1 S2 S1 S2 S2 S2 S1 Tabela przejścia stanów 0 Diagram stanów Technika oparta o tabelę decyzyjną Metoda ta moŝe być stosowana, gdy zachowanie systemu zaleŝy od decyzji logicznych Kolumna tabeli odnosi się do jednej reguły biznesowej Przykład: C1 A1 Reguły 1 2 3 C2 A2 C1 C2 F T T T - F C3 negacja logiczne AND A3 C3 A1 A2 - - T T F F F T F A3 F F T Graf przyczynowo-skutkowy Tabela decyzyjna

Testowanie oparte o przypadki uŝycia Testy są tworzone na bazie przypadków uŝycia albo reguł biznesowych Przypadki uŝycia opisują interakcje pomiędzy aktorami (system, uŝytkownicy) Przypadki testowe stworzone na bazie przypadków uŝycia są najbardziej przydatne dla sprawdzenia błędów mogących pojawić się w codziennej pracy uŝytkowników (badają przepływy) Warunki początkowe Warunki końcowe Przydatne do tworzenia testów akceptacyjnych Zalety i wady Zalety testowania metodą czarnej skrzynki: testy są powtarzalne testowane jest środowisko, w którym przeprowadzane są testy zainwestowany wysiłek moŝe być uŝyty wielokrotnie Wady testowania metodą czarnej skrzynki: wyniki testów mogą być szacowane nazbyt optymistycznie nie wszystkie właściwości systemu mogą zostać przetestowane przyczyna błędu nie jest znana

Techniki białej skrzynki (ang. White-box) Testy białej (ang. white box), które zakładają znajomość sposobu implementacji testowanych funkcji i są opracowywane na podstawie sprawdzania kody źródłowego. Dane wejściowe Biała skrzynka If (a = 1) print a is 1 else print a is not 1 Dane wyjściowe pokrycie instrukcji kodu pokrycie decyzji/rozgałęzień Pokrycie instrukcji kodu (ang. Statement coverage) Przypadki testowe są przygotowywane w taki sposób, aby pokryć instrukcje. Przykład: (1) (2) (3) (4) (5) (6) (7) (8) TC 1. 2. if (a = 3) else End if (b = 7) End print a is 3 print a is not 3 print b is 7 Wejście a = 3; b = 7 a = 7; b = 7 Pokrycie instrukcji: 100% TC1: a=3; b=7 TC2: a=7; b=7 Instrukcja (1) (2) (5) (6) (7) (8) (1) (3) (4) (5) (7) (8) Wyjście a is 3 b is 7 a is not 3 b is 7

Pokrycie rozgałęzień (ang. Branch coverage) Przypadki testowe są przygotowywane w taki sposób, aby pokryć pętle. Przykład: (1) (2) (3) (4) (5) (6) (7) (8) if (a = 3) else End if (b = 7) End print a is 3 print a is not 3 print b is 7 TC1: a=3; b=7 TC2: a=7; b=7 TC Wejście Id decyzji 1. a = 3; b = 7 (1)True (6)True 2. a = 7; b = 7 (1) False(6) True Pokrycie rozgałęzień: 75% Wyjście a is 3 b is 7 a is not 3 b is 7 Zalety i wady Zalety testowania metodą białej skrzynki: poniewaŝ wymagana jest znajomość struktury kodu, łatwo jest określić jaki typ danych wejściowych/wyjściowych jest potrzebny, aby efektywnie przetestować aplikację oprócz głównego zastosowania testów pomaga zoptymalizować kod aplikacji pozwala dokładnie określić przyczynę i miejsce w którym znajduje się błąd. Wady testowania metodą białej skrzynki: poniewaŝ wymagana jest znajomość struktury kodu, do przeprowadzenia testów potrzebny jest tester ze znajomością programowania co podnosi koszty. prawie niemoŝliwym jest przejrzenie kaŝdej linii kodu w poszukiwaniu ukrytych błędów, co moŝe powodować błędy po fazie testów.

Techniki oparte na doświadczeniu (ang. experience based) Zgadywanie błędów przypadki testowe są tworzone na bazie intuicji testera oraz jej/jego doświadczenia z podobnych sytuacji. Testowanie eksploracyjne przypadki testowe są tworzone równolegle z wykonywaniem testów. Przydatne w przypadku braku dokumentacji w projekcie oraz w przypadku presji czasowej. Scenariusz testowy Scenariusz testowy określa: sekwencję wykonywanych czynności ustawia przypadki testowe w określonym porządku (kolejności) w celu sprawdzenia konkretnej części systemu TC3:nazwa3 TC11: nazwa11 TC16: nazwa16

Metryki Postęp tworzenia przypadków testowych Efektywność tworzenia przypadków testowych Jakość przypadku testowego Stopień pokrycia wymagań Narzędzia TestLink QA Track Mercury Test Director IBM Rational ClearQuest IBM Rational Test Manager

Podsumowanie Brak jednej prostej recepty/najbardziej właściwej metody na wygenerowanie dobrego przypadku testowego Czynniki decydujące o wyborze metody: Cel testów Wymagania na system/dostępność dokumentacji Typ testów Poziom i typ ryzyka Czas i budŝet Metoda prowadzenia projektu IT Następne spotkanie UŜyteczność- testowanie i nie tylko

? Dziękuję Zadanie 1. Zbadać testowalność przypadku uŝycia 2. Przeprowadzić analizę testową przypadku uŝycia 3. Wybrać technikę przygotowania przypadków testowych 4. Na podstawie przypadku uŝyciu przygotować przypadki testowe.