• Artykuły
  • Forum
  • Ciekawostki
  • Encyklopedia
  • Testy integracyjne

    Przeczytaj także...
    Wymagania funkcjonalne w inżynierii oprogramowania i inżynierii systemów, definiują funkcję systemu lub jego składnik, którym jest dokładnie opisany w specyfikacji zachowań pomiędzy wejściem i wyjściem. Wymagania funkcjonalne mogą obejmować obliczenia, szczegóły techniczne, manipulację i przetwarzanie danych oraz inne specyficzne funkcje, które określają, co system ma osiągnąć. Wymagania funkcjonalne określają konkretne wyniki systemu. Należy temu przeciwstawić wymagania niefunkcjonalne, które określają ogólne cechy, takie jak koszt i niezawodność. Wymagania funkcjonalne kierują architekturą aplikacji systemu, podczas gdy wymagania niefunkcjonalne kierują architekturą techniczną systemu. Weryfikacja i walidacja oprogramowania znana jest również jako kontrola jakości oprogramowania. Do kryterium weryfikacji należy zakwalifikowanie produktu, czy spełnia lub pasuje do właściwego jego wykorzystania (wysoki poziom kontroli) – czy jest on wbudowany w odpowiedni produkt.
    Testowanie oprogramowania – proces związany z wytwarzaniem oprogramowania. Jest to jeden z procesów zapewnienia jakości oprogramowania. Testowanie ma na celu weryfikację oraz walidację oprogramowania. Weryfikacja oprogramowania ma na celu sprawdzenie, czy wytwarzane oprogramowanie jest zgodne ze specyfikacją. Walidacja sprawdza, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika. Testowanie oprogramowania może być wdrożone w dowolnym momencie wytwarzania oprogramowania (w zależności od wybranej metody). W podejściu klasycznym największy wysiłek zespołu testerskiego następuje po definicji wymagań oraz po zaimplementowaniu wszystkich zdefiniowanych funkcjonalności. Nowsze metody wytwarzania oprogramowania (np. Agile), skupiają się bardziej na jednostkowych testach wykonywanych przez członków zespołu programistycznego, zanim oprogramowanie trafi do właściwego zespołu testerów.

    Testy integracyjne – jeden z etapów testowania oprogramowania, wykonywany w celu wykrycia defektów w interfejsach i interakcjach pomiędzy modułami lub systemami.

    Testy integracyjne są przeprowadzane w celu oceny zgodności systemu lub komponentu z określonymi wymaganiami funkcjonalnymi.

    Występują po testach jednostkowych, jednakże przed testami walidacyjnymi. Współczesne aplikacje składają się przeważnie z wielu współpracujących systemów, należy więc sprawdzić czy komunikacja pomiędzy nimi nie jest zakłócona.

    Test jednostkowy (ang. unit test) – w programowaniu metoda testowania tworzonego oprogramowania poprzez wykonywanie testów weryfikujących poprawność działania pojedynczych elementów (jednostek) programu – np. metod lub obiektów w programowaniu obiektowym lub procedur w programowaniu proceduralnym. Testowany fragment programu poddawany jest testowi, który wykonuje go i porównuje wynik (np. zwrócone wartości, stan obiektu, wyrzucone wyjątki) z oczekiwanymi wynikami – tak pozytywnymi, jak i negatywnymi (niepowodzenie działania kodu w określonych sytuacjach również może podlegać testowaniu).

    Testy integracyjne wykorzystają moduły przetestowane jednostkowo, grupując je w większe agregaty. Kolejnym etapem jest zastosowanie testów zdefiniowanych dla tych agregatów w planie testów integracji. Efektem testów jest zintegrowany system gotowy na testy systemowe.

    Podejścia[ | edytuj kod]

    Wyróżnia się kilka najpopularniejszych testów integracyjnych: top-down (od góry do dołu), bottom-up, Big Bang i mieszane (ang. sandwich). Inne schematy integracji to: integracja współpracy, integracja szkieletu, integracja warstw, integracja klient-serwer, integracja usług rozproszonych i integracja wysokiej częstotliwości.

    W podejściu typu Big Bang większość opracowanych modułów jest łączonych ze sobą, tworząc kompletny system oprogramowania lub większą część systemu, który jest następnie wykorzystywany do testowania integracji. Metoda ta pozwala na efektywne wykorzystywanie czasu w procesie testowania integracji. Jednakże jeśli jednak przypadki testowe i ich wyniki nie zostaną poprawnie zarejestrowane, cały proces integracji będzie bardziej skomplikowany i może uniemożliwić zespołowi testującemu osiągnięcie celu testowania integracji. Testowanie systemu jako całość powoduje, że błędy występujące w interfejsach komponentów wykrywane są w bardzo późnej fazie procesu testowego. Trudno również określić przyczynę występowania błędu oraz miejsce jego występowania. Testowanie za pomocą Big Bang niesie spore ryzyko niewykrycia krytycznych błędów, które mogą ujawnić się dopiero w wersji produkcyjnej systemu. Trudno upewnić się, czy wszystkie przypadki z poziomu testów integracyjnych są pokryte testami.

    Testowanie bottom-up jest podejściem do zintegrowanego testowania, w którym najpierw testowane są komponenty najniższego poziomu, a następnie są wykorzystywane do ułatwienia terowania komponentów wyższego poziomu. Proces powtarza się, dopóki komponenty najwyższego poziomu nie zostaną przetestowane. Wszystkie dolne lub niskopoziomowe moduły, procedury lub funkcje są integrowane, a następnie testowane. Analogiczne integracje i testowanie przechodzą wszystkie poziomy systemu. Podejście bottom-up jest efektywne tylko wtedy, gdy wszystkie lub większość modułów tego samego poziomu jest gotowa. Zaletą tego podejścia jest możliwość określenia poziomów opracowania oprogramowania oraz łatwość raportowania postępu testów w formie wartości procentowej.

    Podejście top-down jest podejściem do zintegrowanego testowania, w którym najpierw testowane są komponenty najwyższego poziomu. Następnie gałąź poszczególnych modułów jest testowana krok po kroku aż do najniższego poziomu.

    Testowanie mieszane (ang. sandwich – kanapkowe) to podejście łączące testowanie bottom-up z podejściem top-down. Jednym z ograniczeń tego typu testów jest warunek określenia ich w specyfikacji testów integracyjnych. Testy te skupiają się na potwierdzeniu działania określonych funkcjonalności projektu. Elementy, które nie zostały zaplanowane do przetestowania na ogół nie zostaną przetestowane przy wykorzystaniu tego podejścia.

    Przypisy[ | edytuj kod]

    1. ISO/IEC/IEEE International Standard – Systems and software engineering. ISO/IEC/IEEE 24765:2010(E), 2010, s. vol., no., s. 1–418, 15 Dec. 2010.
    2. Martyn A Ould & Charles Unwin (ed), Testing in Software Development, BCS (1986), p71. Dostęp 31 Października 2014.
    3. Binder, Robert V.: Testing Object-Oriented Systems: Models, Patterns, and Tools. Addison Wesley 1999. ​ISBN 0-201-80938-9​.
    4. Rohit Khurana: Software Engineering, BCS (2012), p131-132. Dostęp 8 Czerwca 2019.
    5. William R. Simpson & John W. Sheppard, System Test and Diagnosis, BCS (1999), p.44-50. Dostęp 8 czerwca 2019.
    6. Ashwin Dhakal, Software Engineering, BCS(2017) ISBN:978-9937-0-3279-7. Dostęp 8 Czerwca 2019.




    Reklama

    Czas generowania strony: 0.009 sek.