RSS
 

Archiwum dla kategorii ‘4. Weryfikacja walidacja i testowanie’

Przeglądy i zależności między pojęciami

17 lis

Przegląd (ang. review) to proces, podczas którego produkt, tj. pewien artefakt procesu wytwórczego, jest prezentowany zespołowi projektowemu, menedżerom, użytkownikom, klientom i innym interesariuszom w celu zaopiniowania lub zatwierdzenia.

Ze względu na stopień sformalizowania przeglądy można podzielić na:
- nieformalne – opracowane sytuacyjnie (ad hoc),
- sformalizowane – ich przebieg opisany jest przez konkretne reguły, zasady, procedury lub standardy, mają zdefiniowane zasoby projektowe, cele, odpowiedzialności, ich artefaktem jest dokument o ściśle określonej strukturze.

Inspekcja to zdyscyplinowana technika analizy statyczne, polegająca na wizualnym przeglądzie, tj. ocenie produktów procesu wytwórczego, tj.: kod źródłowy, dokumentacja projektowa, w celu wykrycia anomalii, w tym błędów oraz odstępstw od standardów i specyfikacji.

Do podstawowych celów przeprowadzania inspekcji należy zaliczyć:
- wykrywanie, identyfikację i usunięcie defektów w produktach procesu wytwórczego,
- potwierdzenie jakości produktu procesu wytwórczego,
- doskonalenie procesu wytwórczego za pomocą analizy przyczyn zarejestrowanych defektów,
- promowanie projakościowych praktyk działania.

Inspekcja jest przeprowadzana przez zespół, w którym każda z osób odgrywa jedną lub więcej ról.

ROLE W PROCESIE INSPEKCJI
Role w procesie inspekcji

Fazy procesu inspekcji
I faza: Planowanie (ang. planning) – moderator podejmuje decyzję, który artefakt należy poddać inspekcji, dobiera członków zespołu, określa dokumenty niezbędne do przeprowadzenia inspekcji, definiuje warunki jej zakończenia

II faza: Inicjalizacja (ang. overview) – wyjaśnienie członkom zespołu zasad inspekcji, jej harmonogramu, celów oraz przydziału ról

III faza: Przygotowanie (ang. preparation) – kontrolerzy indywidualnie przeglądają analizowany artefakt w celu znalezienia defektów

IV faza: Kontrola (ang. inspection meeting) – spotkanie wszystkich członków zespołu, podczas którego opracowywana jest spójna lista defektów wykrytych we wcześniejszej fazie przez inspektorów. Spotkanie jest prowadzone przez moderatora, rezultaty praz wykonanych w fazie III są odczytywane przez prezentera. Moderator oraz kontrolerzy w trakcie odczytywania wskazują niezgodności i sugerują poprawki, jakie autor powinien wprowadzić do artefaktu. Opinie te są zapisywane przez sekretarza

V faza: Naprawa (ang. rework) – autor wprowadza modyfikacje, zgodnie z sugestiami

VI faza: Sprawdzenie (ang. follow-up) – moderator sprawdzam czy autor dokonał odpowiednich poprawek. Decyzja o zakończeniu inspekcji jest podejmowana przez lidera przy wykorzystaniu kryteriów zakończenia zdefiniowanych w fazie planowania.

Zależności między pojęciami
Testowanie, weryfikacja oraz walidacja mają ten sam cel główny, którym jest zapewnienie oprogramowaniu jak najwyższej jakości, lecz odmienne cele szczegółowe, związane z zapewnieniem jakości:
- testowanie
– zapewnienie jakości kodu,
- weryfikacja – zapewnienie jakości poszczególnych faz procesu wytwórczego oraz ich produktów,
- walidacja – zapewnienie jakości produktu z perspektywy odbiorcy.

Walidacja stanowi bezpośrednie sprzężenie każdego z artefaktów procesu wytwórczego z wymaganiami użytkownika. Weryfikacja to proces sprawdzenia zgodności specyfikacji z implementacją, realizowany dla każdego z artefaktów. Testowanie oraz przeglądy to jedyne formy realizacji weryfikacji i walidacji.

 

Proces testowania oprogramowania

16 lis

Podział testów ze względu na obszar, który podlega testowaniu:
- jednostkowe (modułów),
- integracyjne (scalenie),
- systemowe,
- akceptacyjne.

Proces testowania oprogramowania przebiega od ogółu do szczegółu – jest to podejście bottom-up. W przeprowadzaniu testów oprogramowania przydatne są specjalistyczne narzędzia do testowania.

PROCES TESTOWANIA OPROGRAMOWANIA – ZESTAWIENIE PRZEGLĄDOWE
Proces testowania oprogramowania - zestawienie przeglądowe

Testowanie regresyjne – służy potwierdzeniu skuteczności dokonanych modyfikacji mających na celu usunięcie wykrytych wcześniej błędów.

 

Testowanie i metody testowania

15 lis

Testowanie jest podstawową metodą analizy dynamicznej, stanowi proces wykonywania programu w celu wykrycia błędów. Czynność ta koncentruje się na sprawdzeniu poprawności wewnętrznej struktury oraz sposobu funkcjonowania programu.

Zasady projektowania dobrych testów:
- od szczegółu do ogółu – testowanie rozpoczyna się od pojedynczych modułów, a kończy na testach całego systemu,
- zgodność produktu z wymaganiami klienta,
- projekt i plan testów – powinny być przygotowane przed implementacją kodu, projekt testów można opracować po sporządzeniu specyfikacji wymagań, szczegółowy zestaw testów po zakończeniu fazy projektowania,
- zasada Pareto – 80% błędów związane jest z 20% dostarczanego oprogramowania,
- testowanie przez osoby z zewnątrz – pozwala wykryć więcej błędów niż testowanie przez twórców systemu.

Metody testowania
Metody projektowania testów można podzielić na dwie podstawowe kategorie:
- metoda białej skrzynki (ang. white box testing), zwana inaczej testowaniem struktury (ang. structural testing),
- metoda czarnej skrzynki (ang. black box testing), zwana też jako testowanie funkcyjne (ang. functional testing).

Metoda białej skrzynki polega na testowaniu wewnętrznej struktury programu – analizie kodu źródłowego. Metoda ta pozwala na takie zaprojektowanie testu, aby objął on:
- każdą linię kodu źródłowego,
- każdą niezależną ścieżkę w module,
- wszystkie warianty decyzji logicznych,
- wszystkie pętle,
- wszystkie wewnętrzne struktury danych.

Można wyróżnić następujące prawidłowości:
- liczba błędów logicznych jest odwrotnie proporcjonalna do częstości wykonywania danego fragmentu kodu – im rzadziej funkcja czy przepływ są wykonywane, tym bardziej prawdopodobne jest, iż zawierają błędy,
- programiści popełniają błędy literowe, nie wszystkie z nich są wykrywane przez kompilatory czy też analizatory składni.

Metoda białej skrzynki pozwala na wykrycie nieprawidłowego użycia:
- operatorów logicznych,
- typów danych,
- wyrażeń arytmetycznych,
- definicji warunków logicznych,
- zagnieżdżeń pętli,
- warunków brzegowych pętli,
- konwersji typów.

Metoda białej skrzynki jest przydatna przy projektowaniu testów jednostkowych oraz integracyjnych. Najczęściej wykorzystywanych wariantem metody białej skrzynki jest zaprojektowana przez McCabe metoda ścieżek podstawowych, polegająca na testowaniu głównych, bazowych ścieżek logicznych w ramach struktur programu.

Metoda czarnej skrzynki służy do kompletnego testowania zgodności programu z wymaganiami funkcyjnymi. W tej metodzie wnętrze systemu, tj. wewnętrzna struktura programu, jego kod źródłowy, jest dla testującego nieznany niczym czarna skrzynka, a nawet nieistotny. Metoda czarnej skrzynki pozwala na wykrycie błędów związanych z:
- źle zaimplementowaną funkcjonalnością,
- niedostarczeniem pewnej funkcjonalności,
- niewłaściwymi zachowaniami systemu,
- problemami wydajnościowymi.

Testowanie funkcyjne koncentruje się na sferze informacyjnej funkcjonowania systemu informatycznego. Tak więc dla każdego przypadku testowego określa się dane wejściowe oraz oczekiwane rezultaty, które powinny zostać zwrócone przez oprogramowanie. Rezultaty rozbieżne z oczekiwaniami stanowią błędy, które powinny być usunięte.

WARIANTY METODY CZARNEJ SKRZYNKI
Warianty metody czarnej skrzynki

 

Weryfikacja i walidacja

14 lis

Błędem jest każde niepożądane lub nieoczekiwane zachowanie produktu programistycznego wykryte przed przekazaniem go jego odbiorcom.

Błędy, których w trakcie procesu wytwórczego nie wykryto, ulegają wzmocnieniu – ujawniają się, gdy oprogramowanie jest już używane przez odbiorcę. Mogą one prowadzić do awarii oprogramowania, czyli zachowań produktu niezgodnych z oczekiwaniami określonymi na etapie formułowania wymagań.

Każda anomalia działania gotowego produktu, powstałą wskutek niewykrycia błędów przed przekazaniem oprogramowania do eksploatacji, jest usterką.

Aby zapewnić oprogramowaniu jak największą jakość, proces wytwórczy oprogramowania powinien obejmować, oprócz procesów podstawowych, procesy wspomagające, tj. weryfikację, walidację oraz testowanie.

Weryfikacja to proces oceny zgodności artefaktów danej fazy procesu wytwarzania oprogramowania z założeniami przyjętymi na jej początku.

Walidacja, zwana również jako zatwierdzenie, to proces oceny zgodności artefaktów danej fazy cyklu wytwórczego, zwłaszcza gotowego produktu, z wymaganiami klienta.

Weryfikacja stanowi próbę odpowiedzi na pytanie, czy produkuje się produkt taj, jak trzeba, natomiast walidacja pozwala rozstrzygnąć, czy buduje się ten produkt, co trzeba.

Pięć kategorii weryfikacji i walidacji:
- przeglądy (ang. reviews) – stosowanie takich technik, jak przeglądy nieformalne, kontrole drobiazgowe (ang. walkthroughs), inspekcje oraz audyty artefaktów wszystkich faz procesu wytwórczego,
- dowody poprawności (ang. proof of correctness) – znane również jako weryfikacja formalna, polegająca na dowodzeniu tezy, że program jest poprawny, za pomocą formalnego aparatu matematycznego,
- śledzenie wymagań (ang. requirements tracing) – sprawdzenie, czy wszystkie wymagania klienta są zaspokojone oraz przetestowane, tj. skojarzenie każdego z wymagań z odpowiednim przypadkiem testowym i modułem oprogramowania implementującym je,
- testowanie – uruchamianie programu, wprowadzenie danych wejściowych w celu wykrycia nieprawidłowych zachowań programu w określonych warunkach,
- symulacje oraz prototypowanie (ang. simulation and prototyping) – stosowane w celu sprawdzenia specyfikacji produktu pod kątem realizacji wymagań klienta przy założeniu poprawności prototypu oraz symulacji.

Przedstawione techniki weryfikacji i walidacji koncentrują się wokół dwóch zagadnień – struktur oraz dynamiki tworzonego oprogramowania.

Analiza statyczna – przegląd, dowód poprawności, śledzenie wymagań, przedmiotem analizy jest specyfikacja wymagań, projekt systemu, kod źródłowy, gotowy produkt.

Analiza dynamiczna – testowanie, prototypowanie oraz symulacje, przedmiotem analizy jest kod źródłowy.