INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

Transkrypt

1 INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

2 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 testowych (funkcja, transakcja, cecha, atrybut jakości lub element struktury). Specyfikacja warunków testowych ( Test Design Specification), regulowana jest przez standard IEEE (829 Standard for Software Test Documentation) Inne standardy: IEEE 1008, IEEE 1012, BS , BS

3 IEEE Test Plan dokument planowania zarządzania projektem, który składa się z informacji o tym, w jaki sposób będą prowadzone testy, kto będzie je przeprowadzał, co będzie testowane, jak długo potrwa cały proces oraz jaki będzie zakres testów. Test Design S. szczegóły na temat warunków testowania, oczekiwanych wyników a także kryteriach przejścia testu. Test Case S. specyfikuje dane testowe do użycia podczas wdrażania warunków testowania określonych w Test Design Specification. Test Procedure S. zawiera szczegóły na temat przeprowadzenia każdego testu włączając w to założenia oraz poszczególne kroki testów. Test Item Transmittal R. zawiera raporty na temat czasu przejścia testowanych fragmentów oprogramowania między etapami. Test Log informacje które przypadki testowania zostały użyte, kto je użył i w jakim porządku oraz informacje o ich powodzeniu. Test Incident R. informacje o testach zakończonych niepowodzeniem. Informacje o wynikach oraz dlaczego dany test nie powiódł się. Test Summary R. zawiera wszystkie istotne informacje ujawnione podczas zakończonych testów oraz wyceny jakości procesów testowania, jakości oprogramowania poddanego testowi, a także statystyki uzyskane z Incident Report. Raport referuje również do typów i czasu trwania wykonanych testów w celu usprawnienia wszelkich planów związanych z testami w przyszłości. Ostateczna forma dokumentu jest wykorzystywana w celach weryfikacji poprawności testowanego systemu względem wymagań zdefiniowanych przez zleceniodawców.

4 Ważne pojęcia (II) Przypadek testowy (test case) to zbiór: danych wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów końcowych warunków wykonania opracowany w określonym celu lub dla warunku testowego jak wykonanie pewnej ścieżki programu albo zweryfikowanie zgodności z pewnym wymaganiem

5 Ważne pojęcia (II) Istnieją 2 rodzaje przypadków testowych: przypadek testowy niskiego poziomu (low level test case) przypadek testowy z konkretnymi (na poziomie implementacji) wartościami wejściowymi i wynikami oczekiwanymi. Logiczne operatory z przypadków testowych wysokiego poziomu są zamieniane na konkretne wartości, które odpowiadają celom logicznych operatorów, przypadek testowy wysokiego poziomu (abstrakcyjny, high level test case) przypadek testowy bez konkretnych (poziom implementacji) wartości danych wejściowych i oczekiwanych rezultatów. Używane są operatory logiczne; rzeczywiste wartości nie są jeszcze zdefiniowane i/ lub dostępne.

6 Ważne pojęcia (II) WYMAGANE SKŁADOWE P.T. unikalny identyfikator, nazwa, krótki opis, warunki wstępne poszczególne kroki do wykonania, oczekiwany rezultat, warunek końcowy, OPCJONALNIE SKŁADOWE P.T. dane testowe środowisko testowe, identyfikator wymagania, którego dotyczy, kategoria, priorytet, autor, numer wersji Specyfikacja przypadków testowych ( Test Design Specification), regulowana jest przez standard IEEE-610

7 TESTY SYSTEMOWE

8 Testy systemowe Testy systemowe (system testing) testowanie całości zintegrowanego i zainstalowanego oprogramowania w określonym środowisku wykonawczym (system jako całość, brak wnikania w budowę). Sprawdzenie zgodności wszystkich istniejących funkcjonalności ze specyfikacją Weryfikacja właściwości określonych wymaganiami niefunkcjonalnymi Środowisko testowania powinno być maksymalnie podobne do środowiska użytkowania.

9 Testy systemowe

10 TESTY FUNKCJONALNE (functional testing) poprawność wykonania wszystkich funkcji systemu (przypadki użycia) TESTY WYDAJNOŚCIOWE (performance testing) działanie systemu przy nominalnym obciążeniu (np. czas przetwarzania), czas wykonania transakcji (odczyt, aktualizacja) sprawdzenie czy funkcje systemu są realizowane w czasie akceptowalnym przez użytkownika TESTY PRZECIĄŻENIOWE (stress testing) - działanie systemu przy przekroczonym założonym obciążeniu (np. czas przetwarzania) do granicy wyspecyfikowanych wymagań (load test) TESTY BEZPIECZEŃSTWA (security testing) skuteczność mechanizmów ochrony TESTY ODPORNOŚCI (recovery testing) działanie systemu w warunkach awarii (wyłączenie, restart, brak zasilania) TESTY ZGODNOŚCI (instalacyjne, konfiguracyjne, compatibility testing) możliwość pracy w różnych warunkach: Platformy sprzętowe Systemy operacyjne Zestawy oprogramowania u użytkownika Wersje systemu TESTY DOKUMENTACJI (documentation testing) zgodność działania z dokumentacją

11 TESTY AKCEPTACYJNE

12 Testowanie akceptacyjne Testowanie oprogramowania w formie dostarczanej użytkownikowi w docelowym środowisku pracy. Sprawdzenie zgodności z wymogami (i potrzebami!) użytkownika (biznesowe przypadki użycia) Sposób przeprowadzenie testów może być bardzo zbliżony do testów systemowych, ale celem nie jest znajdowanie defektów, a zademonstrowanie możliwości i zatwierdzenie produktu (ewentualne dostosowanie do rzeczywistych potrzeb)

13 Testowanie akceptacyjne TESTY TE PRZEPROWADZA UŻYTKOWNIK (PRZYNAJMNIEJ W TEORII W PRAKTYCE ROBI TO WYKONAWCA POD OKIEM UŻYTKJOWNIKA) 1. Użytkownik zatwierdza scenariusze testowania (część składowa dokumentacji testów) 2. Użytkownik nadzoruje poprawność (wiarygodność) testowania 3. Błędy są raportowane i usuwane w ustalonym umową terminem (II termin zaliczenia)

14 Testowanie akceptacyjne TEST JAKO KONTROLOWANA EKSPLOATACJA (OPROGRAMOWANIE DLA MASOWEGO ODBIORCY) W siedzibie wytwórcy (testy a) U wybranej grupy użytkowników lub dystrybutorów (testy b) Błędy raportowane i usuwane przed wypuszczeniem finalnej wersji.

15 Testowanie akceptacyjne Etapy testów akceptacyjnych Testy funkcjonalne dopasowanie funkcjonalności do potrzeb biznesowych Testy operacyjne działanie funkcji i uprawnień administratora systemu Testy niefunkcjonalne identycznie jak w systemowych

16 Testowanie produkcyjne 1. Ocena modułu lub systemu w jego środowisku produkcyjnym. 2. Forma testowania akceptacyjnego przez administratorów systemu

17

18 Metryki Miarą jakości testów systemowych jest stopień pokrycia wymagań przypadkami testowymi. Zaleta: wysoka akceptowalność przez użytkowników (odzwierciedlenie testami ich zachowań). Wada: Ale co to jest pokrycie wymagania? Jaki jest standard?

19 Pokrycie wymagań (requirements coverage) Pokrycie błędów (error coverage)

20 Metryki Testowanie przypadków użycia Pokrycie testami biznesowych przypadków użycia Pokrycie testami (scenariuszami przypadków testowych) systemowych przypadków użycia Niskie wartości metryk świadczą o niskiej wydajności testowania

21 Metryki oceny jakości oprogramowania Liczba wykrytych defektów Liczba defektów komponentu Częstość defektów Procent defektów poprawionych

22 Jak zgłaszać błędy? szybko (by błąd nie umknął pamięci), dokładnie (by był zrozumiały dla odbiorcy), precyzyjnie (przypisać mu zdefiniowane i ustalone cechy) jeszcze bardziej precyzyjnie (przypisać osobę odpowiedzialną za zgłoszenie), czytelnie (dołączyć ewentualne rysunki, grafy, logi, które mogą być pomocne przy analizie zgłoszenia), całościowo (powiązać zgłoszenie z przypadkami testowymi i wymaganiami, których dotyka).

23 Przykładowe zgłoszenie

24 Nomenklatura błędów IEEE (IEEE Standard Glossary of Software Engineering Terminology) Awaria odchyłka modułu lub systemu od oczekiwanego zachowania lub rezultatu działania, Błąd (pomyłka) działanie człowieka powodujące powstanie nieprawidłowego rezultatu, Defekt (pluskwa, problem, usterka) wada modułu lub systemu, która może spowodować, że moduł lub system nie wykona zakładanej czynności, np. niepoprawne wyrażenie lub definicja danych. Defekt, który wystąpi podczas uruchomienia programu, może spowodować awarię modułu lub systemu, Incydent (odchylenie) każde zdarzenie wymagające omówienia Niezgodność niespełnienie konkretnego wymagania Wyjątek zdarzenie, które powoduje zawieszenie lub przerwanie działania programu.

25 Ku pamięci

26 Ku pamięci.2 Czego nie da się powiedzieć, tego nie da się też zrobić. (przysłowie angielskie)