Materiały do wykładu "Jakość oprogramowania" - e

Transkrypt

Jakość Oprogramowania
czyli
co zrobić aby program nie tylko działał
ale robił to co chcą użytkownicy
Materiały przygotowane w ramach projektu „Uruchomienie unikatowego kierunku studiów
Informatyka Stosowana odpowiedzią na zapotrzebowanie rynku pracy” ze środków Programu
Operacyjnego Kapitał Ludzki współfinansowanego ze środków Europejskiego Funduszu Społecznego
nr umowy UDA – POKL.04.01.01-00-011/09-00
Początki są zawsze trudne…
Właściciela Tulskiej Fabryki Broni, Korniłowa Białogłazowabić batem i zesłać na roboty do Monastyru ponieważ
podlec ośmielił się dostarczyć Wojsku Ruskiemu muszkiety złej jakości. Niech Nadzorcy Wojskowi i ich pomocnicy
pilnie baczą, jak kontrola pieczęć stawia. Jeśli będą mieli wątpliwości, sami niech sprawdzają przez przegląd i
strzelanie z dwóch muszkietów co miesiąc. Strzelać mają dopóki się nie zepsują. Jeżeli pomimo to wojsko dostanie
złą broń psującą się podczas bitwy, nie oszczędzając bić batami:
–Właściciela fabryki 25 batów i karę pieniężną po jednym czerwieńcu od każdej sztuki,
–Nadzorcę uczynić pisarzem, a jego pomocnika pozbawić niedzielnej porcji wódki na okres jednego roku.
– Nowemu właścicielowi Fabryki Broni, Demidowowi Nakazuję urządzać nadzorcom i ich pomocnikom
pomieszczenia nie gorsze niż jemu samemu. Jeżeli będą gorsze, niech się Demidownie uraża, każę obciąć mu głowę
Podpisano
Pan na Piotrogrodzie
Piotr I Wielki
Car Wszechrusi
(C) Uniwersytet Ekonomiczny w Krakowie (autor: Dariusz Dymek)
Jakość oprogramowania
2
Zamiast wprowadzenia:
Jakość? Co to jest?
3
Plan wykładu
4
Plan wykładu
• Pojęcie jakości i zarządzania jakością
• Jakość oprogramowania:
– Właściwości opisujące jakość: ISO 9126/250xx
• Zarządzanie jakością oprogramowania:
– Jakość procesów wg. ISO i CMM
• Błędy:
– Zapobieganie, wykrywanie, lokalizacja
5
JAKOŚĆ -PODSTAWOWE POJĘCIA
6
Garść definicji…
• zdolność do zaspokajania potrzeb danego
użytkownika
• zgodność z wzorcem, normami lub modelem
• dający się wyodrębnić zespół cech istotny dla
danego produktu lub usługi [Juran]
• zgodność z wymaganiami [Crosby]
• stopień jednorodności i niezawodności produktu
przy możliwie niskich kosztach i maksymalnym
dopasowaniu do wymagań rynku [Deming]
7
Garść definicji…
• ogół cech i właściwości produktu lub usługi,
które decydują o zdolności produktu lub usługi
do zaspokajania potrzeb [ISO 8402]
• zdolność produktu, systemu lub procesu – o
określonym zestawie właściwości, do spełniania
wymagań klienta i wymagań stron
zainteresowanych [ISO 9000:2000]
• Jakość jest to relacja między potrzebami i
oczekiwaniami, a własnościami produktu
[Mazur]
8
Elementy definicji
Relacja pomiędzy właściwościami, a
oczekiwaniami, potrzebami i wymaganiami:
-Podejście deskrypcyjne: zdolność do zaspokojenia
-Podejście wartościujące: stopień zaspokojenia
9
Rodzaje Jakości:
• Jakość techniczna
– Jakość typu
• Właściwości prototypu, „koncepcji produktu”
– Jakość wykonania
• Przy produkcji seryjnej
• Jakość marketingowa
– profil sensoryczny
• sposób w jaki produkt czy usługa jest postrzegany przez
konsumenta
10
Zarządzanie jakością
• Proces zarządzania jakością jest sekwencją
celowych i świadomych działań podejmowanych
w celu utrzymania lub wzmocnienia pozycji
rynkowej poprzez uzyskanie i utrzymanie wysokiej
jakości produktu.
• Fazy zarządzania jakością:
–
–
–
–
planowanie /określenie celów i sposobów działania/
organizowanie /ramy działania/
realizacji /uruchomienie/
kontrola i ocena /sterowanie/
11
Systemy zarządzania jakości
• kontrola techniczna
– bierna kontrola restrykcyjna (produktu)
• kontrola jakości
– czynna kontrola odbiorczo-profilaktyczna
(produktu)
• sterowanie jakością
– kontrola procesu
• kompleksowe zarządzanie jakością (TQM)
– zarządzanie przez jakość
12
Oprogramowanie jako produkt
JAKOŚĆ OPROGRAMOWANIA
13
Specyfika oprogramowania jako
produktu
• niematerialny:
– program komputerowy jako taki nie jest
produktem materialnym
• unikalny:
– każdy program komputerowy jest produktem
jednostkowym, poszczególne egzemplarze to
wierne (identyczne) kopie
• abstrakcyjny:
– jest zapisem pewnego modelu rzeczywistości
• złożony
14
Abstrakcyjny charakter
oprogramowania
Rzeczywistość
obserwacja
Zasady i
schematy
Schemat procesu
pozyskiwania
wiedzy
uogólnienie
eksperyment
Weryfikacja
modelu
Model
sytuacji
Modelowanie
Rzeczywistość
Schemat procesu
tworzenia
oprogramowania
Model
Eksploatacja
Implementacja
Oprogramowanie
15
Odwzorowanie rzeczywistości
Specjaliści z danej
dziedziny
Model
Definiowany i rozumiany
przez
Kod Źródłowy +
Struktury Danych
Kod Wykonywalny
+ Dane
Projektanci,
programiści,...
Rozumiany i wykonywany
przez
KOMPUTER
16
Model Dromey’a
• Zasady dekompozycji:
– każdy program jest zbudowany z jednostek
– jednostki mogą być proste i złożone
– każda jednostka złożona jest zbudowana z jednostek
prostych
– jednostki proste są definiowane na bazie podstawowych
konstrukcji języków programowania
– podział na jednostki jest podziałem hierarchicznym i
wielopoziomowym
– różnego rodzaju dane zarówno proste jak i złożone, które
są przekazywane pomiędzy jednostkami programu oraz
które są dostarczane do programu lub przez niego
generowane są traktowane jako osobne jednostki proste
lub złożone
17
Model Dromey’a
• Jednostki proste są bezkontekstowe
• Jednostki złożone mogą zależeć od dziedziny
wykorzystania
• Jednostki, ich struktura oraz wzajemne
współdziałanie określają właściwości
oprogramowania czyli sposób zachowania się
oprogramowania
• Właściwości oprogramowania:
– właściwości rzeczywiste (mierzalne)
– właściwości abstrakcyjne
18
Struktura oprogramowania
19
Podział funkcjonalny jednostek
złożonych
20
Właściwości oprogramowania
• właściwości niskiego poziomu – właściwości
pierwotne
– mają charakter techniczny
– opisują zarówno jednostki proste jak i złożone
– można na nie wpływać bezpośrednio
• właściwości wysokiego poziomu – właściwości
określające jakość
– opisują tylko jednostki złożone
– są odzwierciedleniem punktu widzenia
użytkownika
21
Właściwości oprogramowania
Relacja między elementami modelu
22
Właściwości pierwotne
• Mają charakter techniczny, dzielą się na:
– właściwości ogólne
• opisują jednostki proste i złożone
– właściwości specyficzne
• opisują tylko jednostki proste
• Można na nie wpływać bezpośrednio
• Widoczne na poziomie „kodu”
23
Właściwości pierwotne
24
Właściwości pierwotne – przykład
jednostka prosta
25
Właściwości pierwotne – przykład
jednostka złożona
26
Właściwości wysokiego poziomu
• Podział funkcjonalny
– właściwości użytkowe
• Funkcja-Wykonywana-Przez-Program(DANE) →WYNIK
– właściwości techniczne
• Funkcja-Wykonywana-Przez-Użytkownika(PROGRAM)
→WYNIK
• Inne podziały:
– specyficzne dla produktu
– specyficzne dla języka programowania
– specyficzne dla obszaru zastosowania
27
Właściwości wysokiego poziomu
28
Właściwości wysokiego poziomu –
przykład jednostka prosta
29
Właściwości wysokiego poziomu –
przykład jednostka prosta
30
Główne problemy
• Identyfikacja jednostek strukturalnych
– Wiele języków oprogramowania, różna struktura
• Identyfikacja właściwości
– Co determinuje jakość? Na co zwracać uwagę?
• Identyfikacja i kwantyfikacja relacji między
właściwościami pierwotnymi i właściwościami
wysokiego poziomu
– Brak modelu formalnego zawęża zakres metod
• Mierzenie właściwości
– Czy da się określić zależności na poziomie ilościowym?
31
Mierzenie jakości
ISO 9126 / ISO 25010
32
Od ISO 9126 do ISO 250nn
33
ISO 9126 - Model jakości
34
ISO 9126 - Model jakości
• Właściwości techniczne (wewnętrzne i zewnętrzne):
– 6 kategorii (podzielonych na 27 podkategorii)
• Właściwości użytkowe:
– 4 kategorie (podzielne na 15 podkategii)
35
ISO 9126 - Właściwości techniczne
36
ISO 9126 - Właściwości użytkowe
37
ISO 9126 - Typy miar (metryk)
• Metryki typu A/B
– np. Dokładność obliczeniowa (Computational accuracy) X=A/B, gdzie A- liczba funkcji, które są
zaimplementowane zgodnie z wymaganiami dokładności, B - liczba wszystkich funkcji, co do
których zostały określone wymagania dokładności
• Metryki typu 1-A/B
– np. Adekwatność funkcjonalna (Functional adequacy) Porównać liczbę funkcji odpowiednich
do wykonania określonych zadań względem liczby funkcji ocenianych, X=1-A/B gdzie A- liczba
funkcji, w których wykryto problemy przy ocenie, B- liczba ocenianych funkcji
• Metryki typu T
– np. Łatwość uczenia się (Learnability) X=T, gdzie T- średni czas, jaki zajmuje użytkownikowi
nauczenie się korzystania z programu
• Metryki typu A/T
– np. Dokładność (Accuracy) Przeprowadzić serię testów typu blackbox i policzyć przypadki, w
których wyniki różniły się od rozsądnie oczekiwanych w stopniu nieakceptowalnym, X=A/T
gdzie, A- liczba przypadków, w których wyniki różniły się od oczekiwanych w stopniu
nieakceptowalnym, T - czas badania
• Inne metryki
38
ISO 14598 – proces oceny jakości
39
ISO 9126 i ISO 14598
40
ISO 9126 i ISO 14598 - problemy
• Dwie odrębne serie częściowo się dublujące
• Brak całościowego postrzegania jakości (np.
nie obejmuje wymagań funkcjonalnych)
• Niezbędne zewnętrzne przewodniki do
skutecznego wykorzystania
41
Struktura ISO 250XX
• Software product Quality Requirements and Evaluation (SQuaRE)
42
Modele jakości ISO 25010
43
Mapowanie do ISO 250XX
44
Właściwości techniczne (ISO 250XX)
45
Właściwości użytkowe (ISO 250XX)
46
A co z wymaganiami?
47
Struktura wymagań jakościowych
48
Od produktu do procesu…
ZARZĄDZANIE JAKOŚCIĄ PROCESU
WYTWÓRCZEGO
49
Zarządzanie jakością procesu
wytwórczego
• Planowanie
– określenie celów i sposobów działania
• Organizowanie
– ramy działania
• Realizacja
– uruchomienie
• Kontrola i ocena
– sterowanie
50
Aby się nie wydawało że to łatwe…
51
CMM – Capability Maturity Model
52
CMM – Struktura modelu
53
Hierarchia elementów
54
Podnoszenie poziomu dojrzałości
55
Poziomy dojrzałości
56
Poziomy dojrzałości – wizja działania
57
Poziomy dojrzałości – wizja działania
58
Do czego zmierzamy…
59
ACQ / DEV / SVC CMM
60
ISO 15504 - Software Process Improvement
and Capability Determination (SPICE)
• 1993 - Software Process Improvement and Capability
Evaluation – początek prac
• 1994 - Software Process Improvement and Capability
Determination – zmiana nazwy
• 2000 – pierwsza publikowana wersja (DTR)
• 2004 – publikacja pierwszych części normy
• Prace nad kolejnymi częściami normy ciągle trwają
61
ISO 15504 – Information technology –
Proces assessment
•
•
•
•
•
•
•
•
•
•
ISO/IEC 15504-1:2004 — Part 1: Concepts and vocabulary
ISO/IEC 15504-2:2003/cor 1: 2004 — Part 2: Performing an assessment
ISO/IEC 15504-3:2004 — Part 3: Guidance on performing an assessment
ISO/IEC 15504-4:2004 — Part 4: Guidance on use for process
improvement and process capability determination
ISO/IEC 15504-5:2012 — Part 5: An exemplar Process Assessment Model
ISO/IEC TR 15504-6:2013 — Part 6: An exemplar system life cycle process
assessment model ( oparty na ISO/IEC 12207:2008 - Systems and software
engineering - Software life cycle processes)
ISO/IEC TR 15504-7:2008 — Part 7: Assessment of organizational maturity
(oparty na ISO/IEC 15288:2008 - Systems and software engineering System life cycle processes)
ISO/IEC PDTR 15504-8:2012 — Part 8: An exemplar process assessment
model for IT service management
ISO/IEC TS 15504-9:2011 — Part 9: Target process profiles
ISO/IEC TS 15504-10:2011 — Part 10: Safety extension
62
ISO 15504 - struktura
• Dwa podstawowe wymiary:
– Wymiar procesu (process dimention) podzielony na 5 kategorii
•
•
•
•
•
customer/supplier
engineering
supporting
management
organization
– Wymiar kompetencji (capability dimention) podzielony na 6
poziomów kompetencji (im wyższy tym lepiej)
•
•
•
•
•
•
5
4
3
2
1
0
Optimizing process
Predictable process
Established process
Managed process
Performed process
Incomplete process
63
ISO 15504 - struktura
• Kompetencje procesu (process capability) są mierzone w oparciu o 9
atrybutów procesu (process atributes)
–
–
–
–
–
–
–
–
–
1.1 Process Performance
2.1 Performance Management
2.2 Work Product Management
3.1 Process Definition
3.2 Process Deployment
4.1 Process Measurement
4.2 Process Control
5.1 Process Innovation
5.2 Process Optimization
• Każdy atrybut procesu jest oceniany w 4 stopniowej skali:
–
–
–
–
N - Not achieved (0 - 15%)
P - Partially achieved (>15% - 50%)
L - Largely achieved (>50%- 85%)
F - Fully achieved (>85% - 100%)
64
Atrybuty procesu
i poziomy kompetencji
65
Proces oceny
66
ISO 15504 – kategorie procesów
67
Poziomy kompetencji
68
Wybrane normy ISO mające zastosowanie
w Inżynierii Oprogramowania
69
Wykorzystanie w praktyce – co, gdzie i jak?
• Stosowanie standardów należy zacząć od ich zrozumienia –
wdrażanie tylko dla wdrożenia (certyfikatu) nie da
pożądanych rezultatów
• Najczęściej popełniane błędy:
– Brak całościowego spojrzenia i próby punktowego wdrażania (na
poziomie pojedynczych jednostek organizacyjnych lub
projektów, bez wsparcia i zaangażowanie reszty organizacji)
– Wybieranie pojedynczych elementów ze standardów i pomijanie
części działań (wybiórcze stosowanie)
– Próby wdrażania standardów „dosłownie” bez ich dostosowanie
do organizacji i jej specyfiki – każda norma zawiera zasady jej
dostosowania do specyfiki organizacji z zachowaniem zgodności
z normą (nie jest to tożsame z wybiórczym stosowaniem)
70
BŁĘDY – JAK ICH UNIKNĄĆ
71
Co to jest błąd?
•
•
•
•
•
„Błąd oprogramowania to usterka programu komputerowego powodująca jego
nieprawidłowe działanie, wynikająca z błędu człowieka na jednym z etapów tworzenia
oprogramowania, zwykle podczas tworzenia kodu źródłowego, lecz niekiedy także na
etapie projektowania” (wikipedia - pl)
„A software bug is an error, flaw, failure, or fault in a computer program or system that
causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
Most bugs arise from mistakes and errors made by people in either a program's source
code or its design, or in frameworks and operating systems used by such programs, and a
few are caused by compilers producing incorrect code” (wikipedia – ang)
„A software bug is a problem causing a program to crash or produce invalid output. The
problem is caused by insufficient or erroneous logic. A bug can be an error, mistake,
defect or fault, which may cause failure or deviation from expected results. Most bugs are
due to human errors in source code or its design” (techopedia – ang)
Potocznie „niezgodność ze specyfikacją”, „niezgodność z wymaganiami, oczekiwaniami,
potrzebami klienta”, … Błąd jest postrzegany jako przeciwieństwo jakości (co pozwala
wykorzystać definicję jakości oprogramowania do zdefiniowanie błędu”)
Niezależnie od formalnej definicji błędu, nikt ich nie chce (!)
72
Błędy: źródła i rodzaje
73
Błędy – trochę statystyki
74
Błędy: co możemy zrobić?
• Zapobieganie:
– Najtańsze i najbardziej efektywne, ale najtrudniejsze do
realizacji
– Środowisko pracy
– Metody pracy (np. Cleanroom)
– Wykorzystanie gotowego kodu (ang. reuse)
• Wykrywanie błędów
– Metody statyczne, dynamiczne, formalne i nieformalne
• Lokalizacja błędów
– Krokowe wykonanie programu (debuging)
– Śledzenie symboliczne
• Poprawianie błędów
75
Wykrywanie błędów: metody nieformalne
• Charakterystyka:
– nazwa pochodzi od tego, że nie wykorzystują
formalizmów matematycznych
– opierają się na subiektywnej ocenie i rozumieniu osób
uczestniczących w działaniach
– można z nich korzystać praktycznie we wszystkich
fazach projektu (wyjątkiem jest test Turinga)
• Przykłady:
– Audyt wewnętrzny i zewnętrzny
– Inspekcje i Przeglądy
– Test Turinga
76
Audyt wewnętrzny i zewnętrzny
• Celem jest ocena stanu, głównie w zakresie formalnej
zgodności z założonymi normami i celami.
• Przeważnie prowadzony jest po zakończeniu prac lub we
wcześniej zaplanowanych Punktach Kontrolnych.
• Obejmuje całość procesów i produktów w projekcie
• Przykładowy zakres audytu:
– Ustawa o Rachunkowości
– Ustawa o Ochronie Danych Osobowych
– Rekomendacja D GINB: Zasady Zarządzania Ryzykiem w
Bankowości Elektronicznej (opracowane przez Komitet
Bazylejski)
– norma BS 7799 (ISO 17799)
– metodologia COBIT
77
Inspekcje i Przeglądy
• Opierają się na zasadzie zorganizowanych
spotkań z precyzyjnie zaplanowanym
przebiegiem i rolą wszystkich uczestników.
– Inspekcje:
• dotyczą konkretnych zagadnień
• uczestniczą w nich tylko osoby bezpośrednio związane z
wytworzeniem produktu oraz zapewnieniem jakości
– Przeglądy (walkthrough,review):
• mają szerszy zakres
• uczestniczą również osoby z kierownictwa projektu oraz
spoza projektu np. przedstawiciele klienta
78
Inspekcja Fagana
• Założenia ogólne:
– ma na celu znalezienie błędów w dowolnym rezultacie /produkcie/
prac projektowym (cel)
– kontroli podlega każdy produkt każdej pojedynczej operacji procesu
tworzenia, dla której zdefiniowane są kryteria zakończenia (zasady
uruchamiania inspekcji)
– zakres kontroli zależy od rodzaju produktu i wewnętrznych standardów
w zakresie tworzenia oprogramowania (uwarunkowania organizacyjne
–dostosowanie)
– cały proces podlega stałej kontroli i ocenie niezależnego zespołu ZJ
(SQA) celem uniknięcia niepożądanych zjawisk takich jak rutyna
• Rodzaje inspekcji wg. produktów podlegających procesowi:
– wymagania systemowe, wymagania funkcjonalne, projekt architektury,
projekt szczegółowy, kod źródłowy, plan testów, realizacja testów
79
Elementy (etapy) inspekcji Fagana (wg. NASA)
• Kryteria wejściowe
• Stany realizacji:
– planowanie: weryfikacja kryteriów wejściowych, skład produktu,
skład zespołu, harmonogram i zasady dystrybucji wyników
– wykonanie: przygotowanie, spotkanie, dodatkowe spotkanie,
klasyfikacja błędów
– trzecia godzina: z założenia inspekcja trwa do 2 godzin –trzecia
godzina jest wyjątkiem i stanowi odrębny stan
– poprawki: kontrola realizacji wyników i ewentualna ponowna
inspekcja
– zakończenie: warunki zamknięcia inspekcji
• Dostosowanie (ang. customization)
• Wymagania szkoleniowe
80
Inspekcja Fagana: skład zespołu
• autorzy produktu
• moderatorzy (kierują inspekcją)
• prezenter (przedstawia produkt i dostarcza danych
dodatkowych)
• rejestrator (dokumentuje proces)
• eksperci (osoby zajmujące się tym samym co autorzy, ale
spoza projektu)
• przedstawiciele zespołów z poprzedniego i następnego
etapu prac
• przedstawiciele zespołu integracyjnego
• przedstawiciele zespołów pracujący nad produktami
powiązanymi („styki”)
• przedstawiciele użytkowników
81
Inspekcja Fagana - rezultaty
• NASA
– spadek liczby błędów wykrywanych w fazie integracji
o 30-90%, przy wskaźnikuROI na poziomie 7:1
• IBM
– dwukrotne zwiększenie wydajności /liczonej w KLOC/
– spadek gęstości błędów o 2/3
– koszt inspekcji to 15% kosztów projektu, przy
jednoczesnym zmniejszeniu kosztów projektu o 25%
82
Test Turinga
• Stosowny głównie w zagadnieniach związanych z
symulacją komputerową
• Zasady wykonania:
– Grupa ekspertów otrzymuje dwa zestawy danych:
rzeczywiste i będące wynikiem symulacji
– ich zadanie polega na rozpoznaniu źródła danych,
znalezieniu ewentualnych różnic i wskazaniu przyczyny
ich powstania
– niemożność poprawnego rozpoznania źródła danych,
oznacza pozytywne zakończenie testu
• Sprawdza głównie model symulacyjny, a nie samo
oprogramowanie
83
Wykrywanie błędów – metody formalne
• Charakterystyka:
– oparte na formalnych modelach matematycznych (stąd
nazwa)
– najrzadziej stosowane, choć uważane za najskuteczniejsze,
ze względu na bardzo wysokie koszty ich użycia
– wykorzystywane przeważnie w tzw. zastosowaniach
krytycznych
• Przykłady:
–
–
–
–
–
indukcja matematyczna
dedukcja logiczna
rachunek Lambda
rachunek predykatów
dowód poprawności
84
Wykrywanie błędów – metody statyczne
• Charakterystyka
– są ukierunkowane na badanie modeli statycznych i kodu
źródłowego
– nie wymagają uruchamiania programu, choć dopuszczają
wyobrażenie sobie jego pracy
– powszechnie stosowane
• Przykłady:
–
–
–
–
–
–
–
analiza syntaktyczna (np. kompilator)
analiza semantyczna
analiza sterowania
analiza danych
analiza strukturalna
rachunek symboliczny
brazowanie przyczynowo-skutkowe
85
Wybrane metody statyczne
• Analiza syntaktyczna:
– składnia języka,
– zgodność ze standardami kodowania
• Analiza sterowania:
–
–
–
–
analiza wywołań
analiza procesów równoległych
analiza przepływu sterowania
analiza stanów
• Analiza danych:
– analiza przepływu danych
– analiza zależności między danymi
86
Wykrywanie błędów – metody dynamiczne
• Charakterystyka
– podstawą metod dynamicznych jest uruchomienie
oprogramowania oraz analiza sposobu i skutków
jego działania
– mogą wymagać ingerencji w kod źródłowy lub/i
wykonywania programu w specjalnym środowisku
– są powszechnie stosowane, choć często w sposób
nieformalny
– wykrywają błędy w gotowym produkcie
– potocznie utożsamiane z testowaniem
87
Rodzaje testów
• testy strukturalne (white, glass-box)
– dane testowe muszą być tak dobrane aby sprawdzona była
każda możliwa ścieżka wykonania programu (w tym
procedury obsługi błędów)
• testy wartości specjalnych
– dane testowe muszą obejmować wszystkie graniczne
wartości danych wejściowych, w tym wartości błędne
• testy funkcjonalne (black-box)
– sprawdzają zgodność pomiędzy danymi wejściowymi,
danymi wyjściowymi a wartościami oczekiwanymi –
kluczowym problemem jest konstrukcja zbioru danych
testowych, o jakości testów decyduje nie liczba danych ale
ich jakość, w tym ich rozkład, wartości graniczne /analiza
czułości/
88
Rodzaje testów
• testy alfa
– testy prowadzone przez zespół projektowy mające symulować
normalną eksploatację oprogramowania
• testy beta
– testy prowadzone przez osoby z poza zespołu projektowego mające
symulować normalną eksploatację oprogramowania
• testy akceptacyjne
– test mający na celu odpowiedzieć na pytanie czy oprogramowania
spełnia założenia specyfikacji wymagań i użytkowników –stanowi
postawę akceptacji oprogramowania przez użytkownika: sposób
przeprowadzenia testów akceptacyjnych powinien być zawarty w
umowie
• testy zgodności
– test zgodności z zewnętrznymi normami, np. certyfikacja producenta
S.O. czy mechanizmów bezpieczeństwa
89
Rodzaje testów
• testy eksploatacyjne
– uruchomienie oprogramowania w docelowym środowisku
eksploatacyjnym (symulacja działania), przy jednoczesnym zachowaniu
dotychczasowych sposobów działania
• testy modułowe i integracyjne
– testy pojedynczych (lub grupy) modułów oprogramowania
• testy częściowe
– testy wybranych elementów funkcjonalnych oprogramowania
• testy wydajnościowe
– monitorowanie pracy programu, wykorzystania środowiska, czasów
przetwarzania, komunikacji z otoczeniem
• krokowe wykonanie kodu
• śledzenie symboliczne
– monitorowanie wartości zmiennych, wyrażeń (z lub bez modyfikacji
kodu)
90
Rodzaje testów
• testy wstępujące
– realizowane wg. zasady od szczegółu do ogółu,
wykorzystywane głównie w trakcie tworzenia
oprogramowania
• testy zstępujące
– realizowane wg. zasady od ogółu do szczegółu,
wykorzystywane głównie do lokalizacji błędów
• testy porównawcze
– polegają na porównaniu wyników pracy dwóch lub
większej liczby programów o identycznej lub zbliżonej
funkcjonalności , metoda wykorzystywana również w
trakcie eksploatacji jako tzw. metoda plebiscytu
91
Wykorzystanie metod dynamicznych
• Metody dynamiczne działają na różnych
poziomach: od pojedynczych fragmentów
kodu źródłowego do całego systemu
• Żadna pojedyncza metoda nie pozwala na
realizację postawionych celów – konieczne jest
planowane wykorzystywanie co najmniej kilku
z nich
• Systematyczne (sformalizowane) podejście do
wykorzystywanie tych metod pozwala uniknąć
wielu błędów i zapewnia ich efektywność
92
Zasady testowania
• Proces testowania powinien obejmować następujące
etapy:
– określenie rodzaju testu, warunków i sposobu jego
przeprowadzenia oraz zasad interpretacji wyników
– przygotowanie środowiska testowego
– przygotowanie danych testowych
• liczba danych testowych /dane wejściowe i wynikowe/
• warunki brzegowe
– przeprowadzenie testów
– analiza wyników
• Każdy etap powinien być formalnie zaplanowany, brak
któregoś z elementów może podważyć sensowność i
wyniki całego procesu
93
Zasady testowania
• Testów nie powinien przeprowadzać twórca
kodu – jego wiedza na temat produktu może
wpłynąć na ich efektywność
• Etap, w którym programista sprawdza
działanie swojego kodu, bezpośrednio po jego
napisaniu nie jest traktowane jako testowanie
– jest to uruchamianie kodu
• Aby uniknąć wpływu programisty na testy, w
niektórych metodach zakłada się, że nie ma on
prawa nawet kompilować własnego kodu
94
Testowanie - posumowanie
„Celem testowania nie jest wykazanie że
program nie ma błędów, lecz wręcz
przeciwnie, wykazanie że program zawiera
błędy.”
„Nieważne jakich metod używasz, ważne żeby
nie było błędów – tak, ale brak metody
kontroli już sam w sobie jest błędem”
95
Podsumowanie
Efektywne wykorzystanie metod unikania,
wykrywania i lokalizacji błędów możliwe jest
tylko wtedy, gdy wykorzystujemy właściwie
dobrany zestaw tych metod i metody te są
integralną częścią całego procesu tworzenia
oprogramowania, mającą silne oparcie w
strukturze organizacji.
96
DZIĘKUJE ZA UWAGĘ
Materiały zostały przygotowane w oparciu o wiele źródeł internetowych. Większość
schematów i rysunków w języku angielskim jest wzorowane lub oparte na materiałach
dostępnych w Internecie
97
Literatura
• G.J.Myers at all, „Sztuka testowania
oprogramowania”, HELION 2005
• R.Pawlak, „Testowanie oprogramowania”,
HELION 2014
• Normy ISO (250xx i 15504)
• Standard CMMI (www.cmu.sei.com)
98

Materiały do wykładu "Jakość oprogramowania" - e

Transkrypt

Podobne dokumenty