Inżynieria Oprogramowania 8. Weryfikacja i zatwierdzanie

Prezentacja na temat: "Inżynieria Oprogramowania 8. Weryfikacja i zatwierdzanie"— Zapis prezentacji:

1 Inżynieria Oprogramowania 8. Weryfikacja i zatwierdzanie
26/03/2017 Inżynieria Oprogramowania 8. Weryfikacja i zatwierdzanie Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW

2 Źródła Materiały dra Waldemara Karwowskiego, wykładowcy w poprzednich semestrach Ian Sommerville, Inżynieria Oprogramowania, WNT, Warszawa 2003

3 Plan Wstęp Treść  Podsumowanie

4 Informacje wstępne Zatwierdzanie: Czy budujemy odpowiedni produkt?
czy produkt odpowiada oczekiwaniom klienta: czy robi to, czego się oczekuje działanie ogólne Weryfikacja: Czy odpowiednio budujemy produkt? czy budujemy zgodnie ze specyfikacją: wymagania! działanie bardziej szczegółowe Mają miejsce w całym procesie tworzenia oprogramowania

5 Dwie możliwe metody W i Z
Kontrole (inspekcje) oprogramowania analiza i sprawdzenie reprezentacji systemu: wymagania, diagramy, kod, ... można częściowo realizować automatycznie to metoda statyczna system nie musi istnieć Testowanie oprogramowania uruchomienie implementacji dane testowe  badanie wyników badanie zachowania to metoda dynamiczna system musi działać

6 Dwie możliwe metody ... Kontrole to: Testowanie:
kontrole „oczne” programów automatyczna analiza kodu źródłowego analiza formalna nie można stwierdzić efektywności, niezawodności Testowanie: zawsze jest potrzebne, w jakimś zakresie obecnie nadal dominuje choć jest droższe i zawodne

7 Dwa rodzaje testów Testowanie defektów Testowanie statystyczne
aby znaleźć niezgodność ze specyfikacją testy przygotowane ze względu na wykrycie usterek, a nie symulację działania specjalne dane, np. rzadkie, skrajne Testowanie statystyczne aby zbadać efektywność i niezawodność, działanie w normalnych warunkach testy przygotowane tak, aby odzwierciedlały prawdziwe dane i ich częstotliwość mierzymy czas, liczymy awarie, ...

8 Poziom zaufania do oprogramowania
Funkcja oprogramowania jak bardzo krytyczny? Oczekiwania użytkowników akceptują (niestety) awarie pod warunkiem wyższości korzyści nad wadami jednak, tolerancja na wady maleje od ’90 Środowisko rynkowe konkurencja cena czas

9 Usuwanie błędów Ustalanie obecności defektów  usuwanie defektów
Wyniki testów Specyfikacja Przypadki testowe Zlokalizuj błąd Zaprojektuj sposób naprawy Napraw błąd Ponownie testuj program Nie znaleziono błędu Umiejętność złożona wiedza o dziedzinie, języku, dobór danych, ... powtarzanie awarii, śledzenie wykonania usterka często daleko od miejsca awarii naprawy są niepełne, usunięcie jednej usterki ujawnia inne, ...

10 Testowanie regresywne
Ponieważ usunięcie jednej usterki często ujawnia inne, należałoby po każdej naprawie powtarzać wszystkie testy Jest to testowanie regresywne W praktyce zbyt kosztowne w 100% Znając zależności między komponentami, można po naprawie testować tylko komponent poprawiony i zależne od niego

11 Im bardziej krytyczny system, tym więcej tego testowania
Planowanie W&Z W dużych systemach W&Z pochłania do 50% koszów – warto dobrze planować Planowanie: równowaga: statyczne  dynamiczne standardy, procedury kontroli, listy kontrolne plany testów ustalanie standardów, a nie opisy testów są to dokumenty dla managerów i inżynierów Im bardziej krytyczny system, tym więcej tego testowania

12 Elementy planu Proces testowania: Fazy
Wymagania: Każde testujemy oddzielnie Testowane byty: Co testujemy Harmonogram: Czas, zasoby, ludzie Procedury zapisu wyników Sprzęt i oprogramowanie Ograniczenia: Zasoby krytyczne

13 Struktura procesu: model V
Specyfikacja wymagań Specyfikacja systemu Projekt systemu Projekt szczegółowy Plan testów akceptacyjnych Plan testów integracji systemu Plan testów integracji podsystemu Testy modułów i jednostek Działanie Test akceptacyjny Test integracji systemu Test integracji podsystemu Plan testów jest dokumentem dynamicznym zmienia się wraz z rozwojem systemu osobom mające testować niegotowe elementy przydziela się inne zadania

14 Kontrole statyczne są efektywne
Kontrole nieformalne: >60% błędów Kontrole ścisłe, formalne: 90% błędów Testuje się także atrybuty nieformalne: standardy, przenośność, zdatność do pielęgnacji Jedna sesja kontroli – wykrycie wielu błędów w dynamicznym – zazwyczaj jednego Recenzenci znają typowe błędy

15 Kontrole – przykład kontroli programu
(Nie tylko programy można kontrolować) Pierwsze sformalizowane kontrole: IBM ’70 Podstawowa literatura: M.E. Fagan, ’76, ’86; dalszy rozwój metodologii

16 Kontrole – Zespół kontrolny
osób – role uczestników mogą się pokrywać autor (właściciel) – usunie defekty kontroler – znajduje błędy, pominięcia, niespójności; również szersze zagadnienia pisarz – notuje rezultaty spotkania kontrolnego moderator – zarządza i ułatwia kontrolę naczelny moderator – odpowiada za proces, aktualizuje listy kontrolne, opracowuje standardy, ... (czytelnik – głośno interpretuje kod)

17 Przed kontrolą upewnij się, że...
Istnieje precyzyjna specyfikacja kodu Członkowie zespołu znają standardy firmowe Mamy poprawną składniowo wersję kodu Uwaga: współczesne kompilatory wykonują kontrolę automatyczną na poziomie odpowiadającym temu, jaki w latach ’90 wykonywały specjalne narzędzia (lint dla języka C, Unix) nie zaleca się wyłączać ostrzeżeń kompilatora (a już z pewnością nie błędów) poprawność składniowa  mniej błędów

18 Podczas kontroli... Przygotowania Faza przeglądu
spotkanie przygotowuje moderator, odpowiada za wybór osób, przygotowanie materiałów, miejsca Faza przeglądu autor kodu objaśnia, co program ma robić Indywidualne przygotowania członkowie studiują specyfikację i kod, szukają błędów Spotkanie kontrolne przedstawienie defektów – nie inne rozmowy Powtórne prace autor usuwa defekty Uzupełnienie moderator decyduje, czy powtórzyć kontrolę; jeśli nie, to aprobuje dokument do publikacji

19 Zalecenia Podstawą procesu jest lista kontrolna częstych błędów programistów, przygotowana z udziałem doświadczonego personelu, aktualizowana Osobne listy dla różnych języków Firmy robią własne listy

20 Przykładowa lista kontrolna
Usterki danych inicjacja zmiennych, stałe nazwane, rozmiary tablic (n-1?), możliwość przepełnienia buforów Usterki sterowania warunki, zakończenia pętli, nawiasy instrukcji złożonych, zupełność instrukcji wyboru, break; Usterki we-wy czy wszystkie dane są używane, czy każdy wynik ma przypisaną wartość, nieoczekiwane dane wejściowe Usterki interfejsu zgodność wywołań funkcji: liczba, typy, kolejność parametrów, organizacja pamięci dzielonej Usterki zarządzania pamięcią zgodność wiązań podczas zmian w strukturach wskaźnikowych, poprawność przydzielania pamięci, poprawność i zgodność zwalniania pamięci Usterki obsługi wyjątków obsługa wszystkich możliwych wyjątków

21 Wydajność kontroli Faza przeglądu Indywidualne przygotowania (1-2 h)
500 w/h Indywidualne przygotowania (1-2 h) 125 w/h Spotkanie (do 2 h) w/h Jednorazowo na kontrolę do 2 h – potem spadek wydajności Koszt kontroli ? 0.5 kosztu testowania (zależnie od liczby usterek)

22 Metoda Cleanroom Warunki ścisła specyfikacja formalna
znany profil działania Metoda polega na tworzeniu przyrostowym (prawie) bez defektów, dzięki elementom: wymagania po wyspecyfikowaniu zamraża się ściśle strukturalne programowanie, które jest formalnym przekształcaniem specyfikacji w kod, z uzasadnieniem poprawności ścisła weryfikacja formalna każdego przyrostu – nie ma testowania modułów statystyczne testowanie zintegrowanych przyrostów, na podstawie profilu działania Bardzo mała liczba błędów Koszty porównywalne z kosztami innych metod Bardzo duże wymagania względem zespołów

23 Organizacja i czynniki międzyludzkie
Jeśli menedżerowie są wrażliwi na zagadnienie, firmy rezygnują z dużej części testów Kontrole są bardziej publiczne, niż prywatne przeglądy menedżerowie muszą zapewnić jasny podział między wynikami kontroli a awansem wyniki kontroli nigdy nie mogą służyć do oceny inżynierów moderatorzy zespołów muszą być dobrze przeszkoleni w zarządzaniu procesem i tworzeniu kultury kontroli po wykryciu błędów należy oferować wsparcie, nie oskarżać w związku z wykrytymi błędami

24 Podsumowanie Weryfikacja: program spełnia specyfikację
Zatwierdzanie: program spełnia oczekiwania Plany testowania: opis testowanych bytów, harmonogram, procedury, zasoby, ograniczenia Weryfikacja statyczna: analiza kodu, stosowana jest razem z testowaniem Kontrole to skuteczna metoda; podstawa: kontrolna lista usterek Kod jest systematyczne sprawdzany przez niewielki zespół: moderator, autor, tester, (czytelnik) Nie wyłączaj ostrzeżeń i błędów kompilatora Konieczne jest budowanie kultury kontroli kodu Dla kodu krytycznego rozważ metodę Cleanroom

25 Dziękuję