Weryfikacja i zatwierdzanie Przedstawienie weryfikacji i zatwierdzania oprogramowania ze szczególnym uwzględnieniem metod weryfikacji statycznej

Cele Poznać różnice między weryfikacją a zatwierdzaniem oprogramowania; znać kontrolę programu jako metodę wykrywania defektów w programach. Dowiedzieć, dlaczego analiza statyczna programów jest ważną metodą weryfikacji. Poznać metodę tworzenia programów Cleanroom.

Zawartość Planowanie weryfikacji i zatwierdzania Kontrole oprogramowania Automatyczna analiza statyczna Metoda Cleanroom tworzenia oprogramowania

Weryfikacja i zatwierdzanie To nazwy nadane procesom sprawdzania i analizy, których celem jest upewnienie się, że oprogramowanie odpowiada swojej specyfikacji i spełnia oczekiwania klientów płacących za to oprogramowanie. Weryfikacja i zatwierdzanie to proces trwający w trakcie całego cyklu życia. Zaczyna się od przeglądów wymagań, trwa w czasie przeglądów projektów i kontroli kodu, a kończy się testowaniem produktu. Czynności W i Z powinny występować w każdym kroku procesu tworzenia oprogramowania.

Różnice Weryfikacja i zatwierdzanie nie są tym samym. Weryfikacja: Czy budujemy produkt odpowiednio? Zatwierdzanie: Czy budujemy odpowiedni produkt? Rolą weryfikacji jest sprawdzenie, czy oprogramowanie jest zgodne ze swoją specyfikacją. Trzeba sprawdzić, czy system spełnia określone dla niego wymagania funkcjonalne i niefunkcjonalne. Zatwierdzanie jest bardziej ogólnym procesem. Trzeba upewnić się, że oprogramowanie odpowiada oczekiwaniom klienta.

Metody sprawdzania i analizy systemu Kontrole (inspekcje) oprogramowania polegają na analizie i sprawdzeniu przedstawień systemu, takich jak dokumentacja wymagań, diagramy projektowe i kod źródłowy programów. Można je wykonywać w każdym kroku procesu. Kontrole można uzupełnić automatyczną analizą kodu źródłowego systemu i innych dokumentów. Kontrole oprogramowania i automatyczne analizy to metody statyczne W i Z, ponieważ do ich wykonania nie trzeba działającego systemu. Testowanie oprogramowania polega na uruchamianiu implementacji oprogramowania.

Weryfikacja i zatwierdzanie dynamiczne i statyczne Kontrole oprogramowania Specyfikacja wymagań Projekt wysokiego poziomu Specyfikacja formalna Projekt szczegółowy Program Testowanie programów Prototyp

Rodzaje testów stosowanych w różnych fazach procesu tworzenia oprogramowania Testowanie defektów. Jego celem jest znalezienie niezgodności między programem i jego specyfikacją. Testy przygotowuje się w celu wykrycia obecności usterek systemu, a nie symulowania jego działania. Testowanie statyczne. Służy do zbadania efektywności i niezawodności programu oraz sprawdzenia, jak działa w warunkach normalnego użytkowania. Testy przygotowuje się tak, aby odzwierciedlały prawdziwe dane wejściowe użytkowników i ich częstotliwość.

Poziom zaufania Ostatecznym celem procesu W i Z jest osiągnięcie przekonania, że system oprogramowania „trafia do celu”. Nie oznacza to, że program w ogóle nie posiada usterek, a raczej, że jest wystarczająco dobry do zamierzonego użytkowania. Poziom wymaganego zaufania zależy od celu systemu, oczekiwań jego użytkowników i aktualnego środowiska rynkowego.

Czynniki poziomu zaufania Funkcja oprogramowania. Poziom wymaganego zaufania zależy od tego, jak bardzo krytyczny dla firmy jest ten system. Poziom wymaganego zaufania wobec oprogramowania sterującego systemem krytycznym dla bezpieczeństwa jest znacznie wyższy niż wobec prototypowego systemu oprogramowanego, który opracowano w celu prezentacji nowych pomysłów. Oczekiwania użytkowników. Tolerancja użytkowników wobec awarii systemu ustawicznie maleje. Obecnie dostarczenie zawodnego systemu spotyka się z mniejszą aprobatą, a zatem firmy budujące oprogramowanie muszą poświęcić więcej wysiłku na weryfikację i zatwierdzanie. Środowisko rynkowe. Gdy system jest sprzedawany na rynku, sprzedawcy muszą wziąć pod uwagę konkurencyjne programy, cenę, którą klienci są gotowi zapłacić, i wymagany harmonogram dostarczenia systemu.

Weryfikacja i zatwierdzanie, a usuwanie defektów. Weryfikacja i zatwierdzanie to proces ustalania obecności defektów w systemie oprogramowania. Usuwanie błędów to proces lokalizacji i usuwania defektów.

Proces usuwania błędów Przypadki testowe Wyniki testów Specyfikacja Zlokalizuj błąd Zaprojektuj sposób naprawy Napraw błąd Ponownie przetestuj program

Planowanie weryfikacji i zatwierdzania Weryfikacja i zatwierdzanie to kosztowne procesy. W wypadku niektórych wielkich systemów, takich jak systemy czasu rzeczywistego ze złożonymi ograniczeniami niefunkcjonalnymi, pół budżetu na produkcję przeznacza się na W i Z. Staranne planowanie jest niezbędne do panowania nad kosztami procesu weryfikacji i zatwierdzania.

Plany testowania jako pomost między tworzeniem a testowaniem Specyfikacja wymagań Specyfikacja systemu Projekt systemu Projekt szczegółowy Plany testów akceptacyjnych Plany testów integracji systemu Plany testów integracji podsystemów Kod i testy modułów i jednostek Działanie Test akceptacyjny Test integracji systemu Test integracji podsystemu

Struktura planu testów oprogramowania Proces testowania. Opis zasadniczych faz procesu testowania. Ślad wymagań Testowanie należy zaplanować tak, aby wszystkie wymagania sprawdzać oddzielnie. Testowane byty. Należy wskazać produkty procesu tworzenia oprogramowania, które podlegają testowaniu. Harmonogram testów. Ogólny harmonogram testowania i przydział zasobów do jego realizacji. Procedury zapisywania wyników testów. Wyniki poszczególnych testów muszą być systematycznie zapisywane. Wymagany sprzęt i oprogramowanie. Należy wskazać niezbędne narzędzia programowe i oszacowanie użycia sprzętu Ograniczenia. Należy określić przewidywane ograniczenia testowania, np. brak personelu.

Kontrole programów Kontrole programów to przeglądy, których celem jest wykrycie defektów. Zespół składający się z osób o różnej wiedzy powinien przeprowadzić staranny przegląd kodu źródłowego programu wiersz po wierszu. Zasadnicza różnica między kontrolami programów i innymi rodzajami przeglądów jakościowych polega na tym, że celem kontroli jest wykrycie defektów, a nie rozważanie szerszych zagadnień projektowych.

Kontrole programów c.d. Wykonanie kontroli oprogramowania nie wymaga uruchamiania programów, a zatem tę metodę weryfikacji można stosować, zanim powstanie implementacja programów. W trakcie kontroli można też zbadać model systemu oraz specyfikacje. Przy wykrywaniu błędów często korzysta się z wiedzy o budowanym systemie. Każdy błąd można rozważyć oddzielenie bez brania pod uwagę jego wpływu na zachowanie systemu. Zależności między błędami nie są istotne. Cały komponent można zweryfikować w trakcie trwania jednej sesji.

Skuteczność kontroli Kontrole okazały się skuteczną metodą wykrywania błędów. Wykrywanie błędów za pomocą kontroli jest tańsze niż za pomocą intensywnych testów. Ponad 60% błędów w programach można wykryć za pomocą nieformalnych kontroli programów. Formalne podejście z uwzględnieniem matematycznej weryfikacji może doprowadzić do wykrycia ponad 90% błędów w programie. Tę metodę stosuje się w procesie Cleanroom.

Przyczyny skuteczności kontroli oprogramowania Wiele rożnych defektów można wykryć w trakcie jednej sesji kontroli. Kłopot z testowaniem polega na tym, że często umożliwia wykrycie tylko jednego błędu w jednym teście, ponieważ defekty powodują katastrofę programu. Kontrole uwzględniają użycie wiedzy dziedzinowej i dotyczącej języka programowania. Np. kontrolerzy często znają już rodzaje błędów występujących przy stosowaniu konkretnego języka programowania. W trakcie analizy mogą się więc skoncentrować na takich rodzajach błędów.

Role członków komisji w procesie kontroli Autor. Programista lub projektant odpowiedzialny za opracowanie programu lub dokumentu. Odpowiada za usunięcie wykrytych defektów. Kontroler. Znajduje w programach i dokumentach błędy, pominięcia oraz niespójności. Czytelnik. Interpretuje kod lub dokument w trakcie spotkania kontrolnego. Pisarz. Odnotowuje rezultaty spotkania kontrolnego. Przewodniczący. Zarządza procesem i ułatwia kontrolę. Informuje o wynikach procesu. Naczelny moderator. Odpowiada za ulepszenie procesu kontroli i aktualizację list kontrolnych i opracowywanie standardów kontroli.

Zanim rozpocznie się kontrola, należy upewnić się, że: Istnieje precyzyjna specyfikacja kodu podlegającego kontroli. Bez pełnej specyfikacji nie uda się wykonać kontroli komponentu na poziomie szczegółowości wystarczającym do wykrywania defektów. Członkowie zespołu kontrolującego znają standardy firmowe. Jest dostępna aktualna, poprawna składniowo wersja kodu. Kontrola kodu “niemal ukończonego” nie ma sensu, nawet jeśli opóźnienie może spowodować niedotrzymanie harmonogramu.

Proces kontroli Planowanie Uzupełnienia Przegląd Powtórne prace Indywidualne przygotowania Spotkanie kontrolne

Sprawdzenie kontrolne Klasa usterek Sprawdzenie kontrolne Usterki danych Czy wszystkie zmienne programu zainicjowano przed użyciem ich wartości? Czy wszystkie stałe mają nazwy? Czy górna granica zakresu tablicy jest równa rozmiarowi tablicy, czy rozmiarowi minus jeden? Czy tam, gdzie użyto stałych napisowych, jawnie przypisano ogranicznik? Czy istnieje jakakolwiek możliwość przepełnienia buforów? Usterki sterowania Czy warunek każdej instrukcji warunkowej jest poprawny? Czy każda pętla na pewno się zakończy? Czy instrukcje złożone są poprawnie ujęte w nawiasy? Czy w instrukcjach wyboru uwzględniono wszystkie możliwości? Czy tam, gdzie jest konieczna instrukcja break w instrukcji wyboru, uwzględniono ją? Usterki Czy wszystkie zmienne wejściowe są używane? wejścia-wyjścia Czy wszystkie zmienne wyjściowe mają przypisywaną wartość, zanim staną się daną wyjściową? Czy nieoczekiwane dane wejściowe mogą spowodować uszkodzenia?

Sprawdzenia kontrolne – c.d. Klasa usterek Sprawdzenie kontrolne Usterki interfejsu Czy wszystkie wywołania funkcji i metod mają odpowiednią liczbę parametrów? Czy pasują do siebie typy parametrów formalnych i aktualnych? Czy parametry są podane w odpowiednim porządku? Czy komponenty korzystające z pamięci dzielonej zakładają ten sam model struktury pamięci dzielonej? Usterki zarządzania Czy po modyfikacji wskaźnikowej struktury danych wszystkie wiązania są pamięcią właściwie przełączane? Czy tam, gdzie korzysta się z dynamicznego przydziału pamięci, jest ona przydzielana poprawnie? Czy pamięć jest jawnie zwalniana, gdy już nie jest potrzebna? Usterki obsługi Czy wzięto pod uwagę wszystkie możliwe sytuacje błędne?

Przykładowy proces kontroli W trakcie fazy przeglądu można rozważyć około 500 wierszy kodu źródłowego na godzinę. W trakcie indywidualnych przygotowań można zbadać 125 wierszy kodu źródłowego na godzinę. W trakcie spotkania można poddać kontroli od 90 do 125 wierszy kodu źródłowego na godzinę.

Automatyczna analiza statyczna Analizatory statyczne programów to narzędzia programowe, które przeglądają kod źródłowy programu i wykrywają potencjalne usterki i anomalie. Nie wymagają uruchomienia programu, ale analizują składniowo tekst programu i rozpoznają różne rodzaje instrukcji. Mogą sprawdzić, czy instrukcje są poprawnie zbudowane, wnioskować o przepływie sterowania w programie i w wielu wypadkach wyznaczyć zbiór możliwych wartości danych programu. Stanowią uzupełnienie udogodnień do wykrywania błędów oferowanych przez kompilator języka.

Sprawdzania automatycznej analizy statycznej Klasa usterek Sprawdzanie analizy statycznej Usterki danych Zmienne używane przed inicjacją Zmienne zadeklarowane, ale nigdy nie użyte Zmienne, którym wartość przypisano dwukrotnie bez jej odczytu między przypisaniami Potencjalne przekroczenia zakresów tablic Niezadeklarowane zmienne Usterki sterowania Kod nieosiągalny Bezwarunkowe odgałęzienia w pętlach Usterki Zmienne wypisywane dwukrotnie bez przypisania im wartości między wejścia-wyjścia wypisywaniem Usterki interfejsu Niezgodność typów parametrów Niezgodność liczby parametrów Niewykorzystane wyników funkcji Nie wywołane funkcje i procedury Usterki zarządzania Wskaźniki, którym nie przypisano wartości pamięcią Arytmetyka wskaźników Sprawdzania automatycznej analizy statycznej

Kroki analizy statycznej Analiza przepływu sterowania Analiza użycia danych Analiza interfejsu Analiza przepływu informacji Analiza ścieżek

Np. język C Analizatory statyczne są szczególnie przydane, gdy korzysta się z języka programowania takiego jak C. Język C nie ma ścisłych reguł dotyczących typów, a zatem sprawdzenia, które może wykonać kompilator C, są bardzo ograniczone. Istnieje więc wiele możliwości błędów programistów, które można wykryć za pomocą automatycznego narzędzia analitycznego. Jest to szczególnie ważne, gdy język C jest używany do tworzenia systemów krytycznych. W takich wypadkach analiza statyczna może znacznie zmniejszyć koszty testowania.

Metoda Cleanroom tworzenia oprogramowania Tworzenie oprogramowania Cleanroom to filozofia tworzenia oprogramowania, której podstawą jest unikanie defektów oprogramowania dzięki rygorystycznemu procesowi kontroli. Celem tego podejścia do tworzenia oprogramowania jest oprogramowanie bez żadnych defektów. Nazwa Cleanroom pochodziło od nazwy pomieszczenia fabryki półfabrykatów. W pomieszczeniu czystym (cleanroom) unika się defektów przez tworzenie w sterylnej atmosferze.

Główne cechy podejścia Cleanroom Specyfikacja formalna Tworzenie przyrostowe Programowanie strukturalne Weryfikacja statyczna Testowanie statyczne systemu

Model procesu Cleanroom Wyspecyfikuj system formalnie Poprawianie błędów Zdefiniuj przyrosty oprogramowania Utwórz program strukturalny Zweryfikuj kod formalnie Zintegruj przyrost Opracuj profil działania Opracuj testy statyczne Przetestuj zintegrowany system

Tworzenie przyrostowe Zamrożona specyfikacja przyrostu Ustal wymagania Formalne specyfikowanie Opracuj przyrost oprogramowania Dostarcz oprogramowanie

Zespoły biorące udział w procesie Cleanroom Zespół specyfikujący. Ta grupa odpowiada za opracowanie i pielęgnację specyfikacji systemu. Zespół wytwarzający. Ten zespół odpowiada za utworzenie i zweryfikowanie oprogramowania. Zespół certyfikujący. Ten zespół jest odpowiedzialny za opracowanie zbioru testów statystycznych, za pomocą, których bada się oprogramowanie po jego stworzeniu.

Główne tezy Weryfikacja i zatwierdzanie to nie to samo. Celem weryfikacji jest wykazanie, że program spełnia specyfikację. Celem zatwierdzania jest wykazanie, że program robi to, czego wymaga użytkownik. Plany testowania powinny zawierać opis testowanych bytów, harmonogram testowania, procedury zarządzania procesem testowania, listę wymaganego sprzętu i oprogramowania oraz problemów, które mogą się pojawić. Metody weryfikacji statycznej obejmują badanie i analizę kodu źródłowego programu w celu wykrycia błędów. Należy stosować je razem z testowaniem programów jako części procesu W i Z. Kontrole programów są skutecznym sposobem wyszukiwania błędów w programach. Celem kontroli jest lokalizacja defektów. Proces kontroli powinien odbywać się na podstawie listy kontrolnej usterek.

Główne tezy Kod programu jest systematycznie sprawdzany przez niewielki zespół. Jego członkami są szef lub moderator, autor kodu, czytelnik prezentujący kod w trakcie kontroli i tester badający kod z punktu widzenia testowania. Analizatory statyczne to narzędzia programowe, które przetwarzają kod źródłowy programu i przyciągają uwagę do anomalii, takich jak nieużywane sekcje kodu i niezainicjowane zmienne. Takie anomalie mogą być wynikiem usterek w kodzie. Tworzenie oprogramowania Cleanroom to podejście do tworzenia oprogramowania, którego podstawą są metody weryfikacji statycznej programów i testy statystyczne do certyfikowania niezawodności. To podejście było z powodzeniem stosowane przy budowaniu systemów o wysokim poziomie niezawodności.