W metodach weryfikacji oprogramowania. Miejsce weryfikacji wśród procesów wytwarzania oprogramowania. Planowanie weryfikacji i kwalifikacji
20. Weryfikacja i certyfikacja oprogramowanie
Weryfikacja i walidacja to procesy testowania i przeglądu, które sprawdzają, czy oprogramowanie spełnia swoje specyfikacje i wymagania klienta. Weryfikacja i certyfikacja obejmują pełny cykl życia oprogramowania – rozpoczynają się na etapie analizy wymagań, a kończą weryfikacją kodu programu na etapie testowania gotowego systemu oprogramowania.
Weryfikacja i certyfikacja to nie to samo, choć łatwo je pomylić. W skrócie różnicę między nimi można zdefiniować w następujący sposób:
Weryfikacja odpowiada na pytanie, czy system został poprawnie utworzony;
Certyfikacja odpowiada na pytanie, czy system działa prawidłowo.
Zgodnie z tymi definicjami weryfikacja sprawdza zgodność oprogramowania ze specyfikacją systemu, w szczególności z wymaganiami funkcjonalnymi i niefunkcjonalnymi. Certyfikacja jest procesem bardziej ogólnym. Podczas certyfikacji należy upewnić się, że oprogramowanie spełnia oczekiwania klienta. Certyfikacja następuje po weryfikacji mającej na celu określenie, jak dobrze system spełnia nie tylko specyfikacje, ale także oczekiwania klienta.
Jak wspomniano wcześniej, na wczesnych etapach tworzenia oprogramowania bardzo ważna jest certyfikacja wymagań systemowych. Błędy i pominięcia są częste w wymaganiach; w takich przypadkach produkt końcowy prawdopodobnie nie spełni oczekiwań klienta. Ale oczywiście walidacja wymagań nie jest w stanie zidentyfikować wszystkich problemów w specyfikacji wymagań. Czasami braki i błędy w wymaganiach odkrywane są dopiero po zakończeniu wdrożenia systemu.
W procesach weryfikacji i certyfikacji wykorzystywane są dwie główne techniki weryfikacji i analizy systemów.
1. Kontrola oprogramowania. Analizuj i weryfikuj różne reprezentacje systemu, takie jak dokumentacja specyfikacji wymagań, diagramy architektoniczne lub kod źródłowy programu. Inspekcja przeprowadzana jest na wszystkich etapach procesu tworzenia systemu oprogramowania. Można ją przeprowadzić równolegle z inspekcją automatyczna analiza kod źródłowy programów i powiązanych dokumentów. Inspekcja i analiza automatyczna to statyczne metody weryfikacji i walidacji, ponieważ nie wymagają systemu wykonywalnego.
2. Testowanie oprogramowania. Uruchom kod wykonywalny z danymi testowymi i sprawdź charakterystykę wyjściową i wydajnościową oprogramowania, aby sprawdzić, czy system działa poprawnie. Testowanie to dynamiczna metoda weryfikacji i certyfikacji stosowana w działającym systemie.
Na ryc. Rysunek 20.1 przedstawia miejsce kontroli i testowania w procesie tworzenia oprogramowania. Strzałki wskazują te etapy procesu rozwoju, na których można zastosować te metody. Według tego schematu inspekcję można przeprowadzić na wszystkich etapach procesu rozwoju systemu, a testowanie można przeprowadzić w przypadku, gdy powstał prototyp lub program wykonywalny.
Metody inspekcji obejmują: inspekcję programu, automatyczną analizę kodu źródłowego i weryfikację formalną. Metody statyczne mogą jednak jedynie sprawdzić zgodność programów ze specyfikacją; nie można ich używać do sprawdzania poprawności działania systemu. Ponadto cech niefunkcjonalnych, takich jak wydajność i niezawodność, nie można zweryfikować metodami statycznymi. Dlatego w celu oceny cech niefunkcjonalnych przeprowadza się testy systemu.
Ryż. 20.1. Weryfikacja i certyfikacja statyczna i dynamiczna
Pomimo powszechnego stosowania inspekcji oprogramowania, testowanie jest nadal dominującą metodą weryfikacji i certyfikacji. Testowanie to test działania programów z danymi zbliżonymi do rzeczywistych, które będą przetwarzane w trakcie działania systemu. Obecność defektów i niezgodności w programie wykrywana jest poprzez badanie danych wyjściowych i identyfikowanie wśród nich tych nieprawidłowych. Testowanie przeprowadzane jest na etapie wdrażania systemu (w celu sprawdzenia, czy system spełnia oczekiwania twórców) oraz po jego zakończeniu.
Na różnych etapach procesu tworzenia oprogramowania stosowane są różne rodzaje testów.
1. Testowanie defektów przeprowadzane w celu wykrycia niespójności pomiędzy programem a jego specyfikacją, które są spowodowane błędami lub defektami programów. Testy takie mają na celu identyfikację błędów w systemie, a nie symulację jego działania.
2. Testowanie statystyczne ocenia wydajność i niezawodność programów, a także działanie systemu w różnych trybach pracy. Testy mają na celu symulowanie rzeczywistego działania systemu przy użyciu rzeczywistych danych wejściowych. Niezawodność systemu ocenia się na podstawie liczby usterek odnotowanych w działaniu programów. Wydajność ocenia się poprzez pomiar całkowitego czasu wykonania operacji i czasu reakcji systemu podczas przetwarzania danych testowych.
Głównym celem weryfikacji i kwalifikacji jest zapewnienie, że system jest „odpowiedni do założonego celu”. Zgodność systemu oprogramowania z jego przeznaczeniem nie oznacza, że powinno być ono całkowicie wolne od błędów. System musi raczej służyć w miarę dobrze celom, dla których został przeznaczony. Poziom wymagany niezawodność zgodności zależy od przeznaczenia systemu, oczekiwań użytkowników i warunków na rynku oprogramowania.
1. Cel oprogramowania. Poziom zaufania do zgodności zależy od tego, jak krytyczne jest tworzone oprogramowanie według określonych kryteriów. Na przykład poziom ufności w przypadku systemów o krytycznym znaczeniu dla bezpieczeństwa powinien być znacznie wyższy niż poziom ufności w przypadku prototypowych systemów oprogramowania opracowanych w celu zademonstrowania nowych pomysłów.
2. Oczekiwania użytkowników. Ze smutkiem należy zauważyć, że obecnie większość użytkowników ma niskie wymagania dotyczące oprogramowania. Użytkownicy są tak przyzwyczajeni do awarii występujących podczas działania programów, że nie dziwi ich to. Są skłonni tolerować awarie systemu, jeśli korzyści z jego stosowania przeważają nad wadami. Jednak od początku lat 90-tych tolerancja użytkowników na awarie systemów oprogramowania stopniowo maleje. W ostatnim czasie tworzenie zawodnych systemów stało się praktycznie nie do przyjęcia, dlatego firmy tworzące oprogramowanie muszą zwracać coraz większą uwagę na weryfikację i certyfikację oprogramowania.
3. Warunki rynkowe oprogramowania. Oceniając system oprogramowania, sprzedawca musi znać konkurencyjne systemy, cenę, jaką kupujący jest skłonny zapłacić za system, oraz docelową datę wypuszczenia systemu na rynek. Jeżeli firma deweloperska ma kilku konkurentów, konieczne jest określenie daty wejścia systemu na rynek przed zakończeniem pełnych testów i debugowania, w przeciwnym razie konkurenci mogą jako pierwsi wejść na rynek. Jeśli klienci nie chcą kupować oprogramowania po wysokiej cenie, mogą być skłonni tolerować więcej awarii systemu. Wszystkie te czynniki należy wziąć pod uwagę przy ustalaniu kosztów procesu weryfikacji i certyfikacji.
Z reguły podczas weryfikacji i certyfikacji w systemie wykrywane są błędy. W systemie wprowadzane są zmiany mające na celu skorygowanie błędów. Ten proces debugowania Zwykle zintegrowane z innymi procesami weryfikacji i kwalifikacji. Jednak testowanie (lub bardziej ogólnie weryfikacja i certyfikacja) oraz debugowanie to różne procesy, które mają różne cele.
1. Weryfikacja i certyfikacja to proces wykrywania defektów w systemie oprogramowania.
2. Debugowanie to proces lokalizowania defektów (błędów) i ich korygowania (ryc. 20.2).
Ryż. 20.2. Proces debugowania
Nie ma prostych metod debugowania programów. Doświadczone debugery wykrywają błędy, porównując wzorce wyników testu z wynikami testowanych systemów. Zlokalizowanie błędu wymaga znajomości typów błędów, wzorców wyjściowych, języka programowania i procesu programowania. Wiedza na temat procesu tworzenia oprogramowania jest bardzo ważna. Debugerzy znają najczęstsze błędy programistów (na przykład te związane ze zwiększaniem wartości licznika). Pod uwagę brane są także błędy typowe dla niektórych języków programowania, np. te związane ze stosowaniem wskaźników w języku C.
Lokalizowanie błędów w kodzie programu nie zawsze jest łatwym procesem, ponieważ błąd niekoniecznie musi znajdować się w pobliżu miejsca w kodzie programu, w którym wystąpił problem. Aby zlokalizować błędy, programista debugera opracowuje dodatkowe testy oprogramowania, które pomagają zidentyfikować źródło błędu w programie. Może być konieczne ręczne śledzenie wykonywania programu.
Interaktywne narzędzia do debugowania są częścią zestawu narzędzi do obsługi języków, które są zintegrowane z systemem kompilacji kodu. Zapewniają specjalne środowisko wykonywania programu, za pośrednictwem którego można uzyskać dostęp do tabeli identyfikatorów, a stamtąd do wartości zmiennych. Użytkownicy często kontrolują wykonanie programu krok po kroku, przechodząc sekwencyjnie od instrukcji do instrukcji. Po wykonaniu każdej instrukcji sprawdzane są wartości zmiennych i identyfikowane są możliwe błędy.
Wykryty błąd w programie jest naprawiany, po czym konieczne jest ponowne sprawdzenie programu. Aby to zrobić, możesz ponownie sprawdzić program lub powtórzyć poprzednie testy. Ponowne testowanie ma na celu upewnienie się, że zmiany wprowadzone w programie nie spowodowały wprowadzenia nowych błędów do systemu, ponieważ w praktyce wysoki odsetek „poprawek błędów” albo całkowicie kończy się niepowodzeniem, albo wprowadza nowe błędy do programu.
W zasadzie podczas ponownego testowania po każdej poprawce wszystkie testy należy przeprowadzić ponownie, ale w praktyce takie podejście jest zbyt kosztowne. Dlatego planując proces testowania, określa się zależności pomiędzy częściami systemu i do każdej części przypisuje się testy. Możliwe jest wówczas śledzenie elementów oprogramowania za pomocą specjalnych przypadków testowych (danych testowych) dostosowanych do tych elementów. Jeśli wyniki śledzenia są udokumentowane, do przetestowania zmienionego elementu oprogramowania i jego zależnych komponentów można użyć tylko podzbioru całego zestawu danych testowych.
Weryfikacja (potwierdzenie poprawności) - polega na sprawdzeniu i udowodnieniu poprawności opracowanego programu w odniesieniu do zestawu stwierdzeń formalnych przedstawionych w specyfikacji oraz na całkowitym określeniu zależności pomiędzy danymi wejściowymi i wyjściowymi tego programu. W tym przypadku związek pomiędzy zmiennymi na wejściu i wyjściu programu jest analizowany nie w postaci wartości, jak w testowaniu, ale w formie opisów ich właściwości, które ujawniają się podczas dowolnego przetwarzania tych zmiennych kontrolowanych w programie.
Weryfikacja programu w zasadzie eliminuje potrzebę testowania i debugowania, ponieważ jednocześnie na wyższym poziomie koncepcji i opisów wszystkich zmiennych ustalana jest poprawność procesów, ich przetwarzania i transformacji.
Istotę każdego programu można przedstawić poprzez opis relacji pomiędzy danymi wejściowymi i wyjściowymi. Zależności te są sformalizowane przez jedną specyfikację oprogramowania. W rzeczywistych wydarzeniach formalizacja tych relacji nie jest zła, a niektóre relacje są wyjaśniane w procesie opracowywania programu. Takie nie do końca zdefiniowane nie są wystarczające do udowodnienia poprawności programów. Dopiero pełne i dokładne sformalizowanie wszystkich warunków i powiązań pomiędzy danymi wejściowymi i wyjściowymi umożliwi ich wykorzystanie do automatycznej weryfikacji.
Metoda twierdzeń indukcyjnych.
Aby zbadać tę metodę, program otrzymuje instrukcje dotyczące właściwości jego zmiennych w określonych punktach:
a) Zmienne wejściowe nie zmieniają się podczas wykonywania programu;
b) Opisano stany zmiennych w punktach pośrednich;
c) Zmienne wyjściowe są opisywane za pomocą relacji między zmiennymi po zakończeniu programu.
Weryfikacja polega na sekwencyjnym wykazaniu, że ze zmiennych wejściowych i przekształceń dokonanych w pierwszym kroku wynika prawdziwość twierdzenia utworzonego w kolejnym punkcie pośrednim.
Do weryfikacji programów wymagane są trzy języki:
· Język do pisania tekstów programowych;
· Język formułowania warunków weryfikacji;
· Język formacji i dowód poprawności.
Ponieważ języki te różnią się w znacznym stopniu, okoliczność ta jest jednym z zastosowań weryfikacji.
Dowód poprawności ma następujące zalety:
1. Reprezentuje jasno sformalizowany proces.
2. Wymaga analizy. Proces sprawdzania poprawności umożliwia sprawdzenie części programów, które w innym przypadku byłyby analizowane jedynie losowo.
3. wyjaśnia pośrednie wyniki obliczeń. Zapisywanie wyrażeń wymusza na programiście jasne sformułowanie założeń dotyczących wyników obliczeń w wybranych punktach programu.
4. Identyfikuje zależności. W procesie udowadniania programów zaczyna się rozumieć, jakie założenia dotyczące danych wejściowych nie są jawnie testowane w różnych częściach programu.
Wady metody:
1. Trudność; nawet dla małych proste programy Obliczenia są bardzo złożone, co może prowadzić do błędów.
2. Błędy Ze względu na złożoność metody łatwo jest popełnić błąd zarówno przy formułowaniu dowodzonych twierdzeń, jak i przy dowodzie.
3. Trudności w pracy z tablicami.
4. Brak potężnego aparatu matematycznego.
5. Wysoka pracochłonność Testowanie programu wymaga więcej pracy niż jego napisanie (2 do 6 razy).
6. Brak wyrazistości. Często nie jest łatwo sformułować opłacalne zestawienie tego, co intuicyjnie wydaje się bardzo prostym obliczeniem:
7. Trudności ze zrozumieniem.
8. Potrzeba szkoleń. Ta metoda wymaga intensywnego szkolenia i szkolenia.
Celem tego kursu jest przedstawienie kompleksowego spojrzenia na proces weryfikacji oprogramowania. Przedmiotem dyskusji są różne podejścia i metody stosowane w obszarze weryfikacji, a w szczególności testowania oprogramowania. Zakłada się, że tworzone oprogramowanie jest częścią czegoś więcej wspólny system. System taki obejmuje komponenty sprzętowe, informacyjne i organizacyjne (użytkownik, operator itp.), ewentualnie opracowane przez różne zespoły. Dlatego potrzebne są dokumenty rozwojowe, które definiują wymagania dla poszczególnych komponentów systemu i zasady ich interakcji. Ponadto zakłada się, że awarie systemu mogą prowadzić do konsekwencji o różnej wadze, dlatego podczas tworzenia oprogramowania wysiłki włożone w identyfikację ukrytych defektów są konieczne i uzasadnione. Przede wszystkim dotyczy to narzędzi i procedur weryfikacji oprogramowania. Kurs obejmuje szereg zajęcia praktyczne, ilustrujący na przykładzie prostego systemu techniki i metody weryfikacji oprogramowania w środowisku Microsoft Visual Studio 2005 Team Edition for Software Testers. Niniejsza publikacja stanowi część Biblioteki kursów, która jest opracowywana w ramach programu współpracy akademickiej MSDN Academic Alliance (MSDN AA).
Poniższy tekst został uzyskany poprzez automatyczne wyodrębnienie z oryginalnego dokumentu PDF i ma służyć jako podgląd.
Brak obrazów (zdjęć, wzorów, wykresów).
Ryż. 7 Testowanie, weryfikacja i walidacja Weryfikacja oprogramowania – więcej ogólna koncepcja niż testowanie. Celem weryfikacji jest upewnienie się, że weryfikowany element (wymagania lub kod programu) spełnia wymagania, jest zaimplementowany bez niezamierzonych funkcji oraz spełnia specyfikacje i standardy projektowe. Proces weryfikacji obejmuje inspekcje, testowanie kodu, analizę wyników testów, generowanie i analizę raportów o problemach. Dlatego ogólnie przyjmuje się, że proces testowania jest część integralna weryfikacji, to samo założenie przyjęto w tym szkoleniu. Walidacja systemu oprogramowania to proces, którego celem jest wykazanie, że w wyniku rozwoju systemu osiągnęliśmy cele, które planowaliśmy osiągnąć poprzez jego wykorzystanie. Inaczej mówiąc, walidacja polega na sprawdzeniu, czy system spełnia oczekiwania klienta. Kwestie związane z walidacją wykraczają poza ten zakres kurs treningowy i stanowią odrębny, interesujący temat do badań. Jeśli spojrzeć na te trzy procesy pod kątem pytań, na które odpowiadają, testowanie odpowiada na pytanie „Jak to się robi?” lub „Czy zachowanie opracowanego programu spełnia wymagania?”, weryfikacja – „Co zostało zrobione?” lub „Czy opracowany system spełnia wymagania?”, a walidacja brzmi: „Zrobił to, co musiał?” lub „Czy opracowany system spełnia oczekiwania klienta?” 1.7. Dokumentacja tworzona na różnych etapach cyklu życia Synchronizacja wszystkich etapów rozwoju następuje za pomocą dokumentów, które powstają na każdym etapie. Dokumentacja tworzona jest także po linii prostej koło życia– podczas tworzenia systemu oprogramowania i odwrotnie – podczas jego weryfikacji. Spróbujmy na przykładzie cyklu życia w kształcie litery V prześledzić, jakie rodzaje dokumentów powstają na każdym z segmentów i jakie zachodzą między nimi relacje (ryc. 8). Wynikiem etapu opracowania wymagań systemowych są sformułowane wymagania systemowe – dokument opisujący ogólne zasady działanie systemu, jego interakcja z „ środowisko» - użytkownicy systemu oraz oprogramowanie i sprzęt zapewniający jego działanie. Zwykle równolegle z wymaganiami systemowymi tworzony jest plan weryfikacji i definiowana jest strategia weryfikacji. Dokumenty te określają ogólne podejście tego, w jaki sposób będą przeprowadzane testy, jakie techniki zostaną zastosowane, jakie aspekty przyszłego systemu powinny zostać poddane dokładnym testom. Kolejnym zadaniem rozwiązywanym poprzez zdefiniowanie strategii weryfikacji jest określenie lokalizacji różnych procesów weryfikacji i ich powiązań z procesami rozwojowymi. 20 Proces weryfikacji pracy z wymaganiami systemowymi to proces walidacji wymagań i porównania ich z rzeczywistymi oczekiwaniami klienta. Patrząc w przyszłość, powiedzmy, że proces walidacji różni się od testów akceptacyjnych przeprowadzanych podczas przekazywania gotowego systemu klientowi, chociaż można go uznać za część takich testów. Walidacja to sposób na wykazanie nie tylko poprawności wdrożenia systemu z punktu widzenia klienta, ale także poprawności zasad leżących u podstaw jego rozwoju. Ryż. 8 Procesy i dokumenty w rozwoju systemów oprogramowania Wymagania systemowe są podstawą procesu opracowywania wymagań funkcjonalnych i architektury projektu. W trakcie tego procesu opracowywane są ogólne wymagania dotyczące oprogramowania systemowego oraz funkcji, jakie musi ono spełniać. Wymagania funkcjonalne często obejmują określenie wzorców zachowania systemu w sytuacjach normalnych i nienormalnych, zasady przetwarzania danych oraz definicje interfejsu użytkownika. Tekst wymagania z reguły zawiera słowa „musi, musi” i ma strukturę postaci „Jeżeli wartość temperatury na czujniku ABC osiągnie 30 stopni Celsjusza lub więcej, system musi przestać wydawać sygnał dźwiękowy. ” Wymagania funkcjonalne stanowią podstawę do opracowania architektury systemu – opisania jego struktury w ujęciu podsystemów i jednostek strukturalnych języka, w którym prowadzona jest implementacja – obszarów, klas, modułów, funkcji itp. Na podstawie wymagań funkcjonalnych pisane są wymagania testowe – dokumenty zawierające definicję kluczowych punktów, które należy sprawdzić, aby zapewnić poprawną realizację wymagań funkcjonalnych. Często wymagania testowe zaczynają się od słów „Test That” i zawierają odniesienia do odpowiadających im wymagań funkcjonalnych. Przykładowe wymagania testowe dla powyższego wymagania funkcjonalnego to „Sprawdź, czy gdy temperatura na czujniku ABC spadnie poniżej 30 stopni Celsjusza, system emituje sygnał ostrzegawczy” oraz „Sprawdź, czy gdy wartość temperatury na czujniku ABC przekroczy 30 stopni Celsjusza stopni Celsjusza”, system nie emituje sygnału dźwiękowego. 21 Jednym z problemów pojawiających się przy pisaniu wymagań testowych jest zasadnicza nietestowalność niektórych wymagań, np. wymagania „Interfejs użytkownika musi być intuicyjny” nie da się zweryfikować bez jasnego zdefiniowania, co stanowi interfejs intuicyjny. Takie niespecyficzne wymagania funkcjonalne są zwykle później modyfikowane. Cechy architektoniczne systemu mogą również służyć jako źródło do tworzenia wymagań testowych, które uwzględniają cechy implementacji oprogramowania systemu. Przykładem takiego wymagania jest np. „Sprawdź, czy wartość temperatury na czujniku ABC nie przekracza 255”. Na podstawie wymagań funkcjonalnych i architektury pisany jest kod systemu, a w celu jego weryfikacji przygotowywany jest plan testów w oparciu o wymagania testowe - opis sekwencji przypadków testowych sprawdzających zgodność implementacji systemu z wymaganiami. Każdy przypadek testowy zawiera konkretny opis wartości podanych na wejście systemu, wartości oczekiwane na wyjściu oraz opis scenariusza wykonania testu. W zależności od obiektu testów plan testów można przygotować albo w formie programu w jakimś języku programowania, albo w formie pliku danych wejściowych dla zestawu narzędzi, który uruchamia testowany system i przekazuje do niego wartości określone w planie testów lub w formie instrukcji dla systemu użytkownika, która opisuje niezbędne działania, które należy wykonać, aby przetestować różne funkcje systemu. W wyniku wykonania wszystkich przypadków testowych zbierane są statystyki dotyczące powodzenia testów - odsetek przypadków testowych, dla których rzeczywiste wartości wyjściowe pokrywały się z oczekiwanymi, tzw. testy zaliczone. Nieudane testy stanowią wstępne dane do analizy przyczyn błędów i ich późniejszej korekty. Na etapie integracji poszczególne moduły systemu składane są w jedną całość i wykonywane są przypadki testowe sprawdzające całą funkcjonalność systemu. NA ostatni etap Gotowy system dostarczamy do klienta. Przed wdrożeniem specjaliści klienta wraz z programistami przeprowadzają testy akceptacyjne - sprawdzają funkcje krytyczne dla użytkownika zgodnie z wcześniej zatwierdzonym programem testów. Jeżeli testy zakończą się pomyślnie, system zostaje przekazany klientowi, w przeciwnym razie zostaje wysłany do przeglądu. 1.8. Rodzaje procesów testowania i weryfikacji oraz ich miejsce w różnych modelach cyklu życia 1.8.1. Testy jednostkowe Małe moduły (procedury, klasy itp.) podlegają testom jednostkowym. Testując stosunkowo niewielki moduł o wielkości 100-1000 linii, można sprawdzić, jeśli nie wszystkie, to przynajmniej wiele gałęzi logicznych w implementacji, różne ścieżki na wykresie zależności danych i wartości graniczne parametrów. Zgodnie z tym konstruowane są kryteria pokrycia testów (uwzględniane są wszystkie operatory, wszystkie gałęzie logiczne, wszystkie punkty graniczne itp.). . Testowanie jednostkowe jest zwykle przeprowadzane na każdym niezależnym module oprogramowania i jest prawdopodobnie najpowszechniejszym rodzajem testów, szczególnie w przypadku małych i średnich systemów. 1.8.2. Testy integracyjne Sprawdzenie poprawności wszystkich modułów niestety nie gwarantuje poprawnego działania systemu modułów. W literaturze czasami omawia się 22 „klasyczny” model niewłaściwej organizacji testowania systemu modułów, nazywany często metodą „wielkiego skoku”. Istota metody polega na tym, aby najpierw przetestować każdy moduł z osobna, następnie połączyć je w system i przetestować cały system. W przypadku dużych systemów jest to nierealne. Dzięki takiemu podejściu dużo czasu zostanie poświęcone na lokalizowanie błędów, a jakość testów pozostanie niska. Alternatywą dla „wielkiego skoku” są testy integracyjne, gdy system buduje się etapowo, stopniowo dodawane są grupy modułów. 1.8.3. Testowanie systemu W pełni wdrożone oprogramowanie podlega testom systemowym. Testera na tym etapie nie interesuje prawidłowe wdrożenie poszczególnych procedur i metod, ale cały program jako całość, tak jak widzi go końcowy użytkownik. Testy opierają się na Ogólne wymagania do programu, obejmujące nie tylko poprawną realizację funkcji, ale także wydajność, czas reakcji, odporność na awarie, ataki, błędy użytkownika itp. W przypadku testowania systemów i komponentów stosowane są określone typy kryteriów pokrycia testów (na przykład, czy uwzględnione są wszystkie typowe scenariusze pracy, wszystkie scenariusze z sytuacjami nietypowymi, zestawienie scenariuszy parami itp.). 1.8.4. Testowanie obciążeniowe Testy obciążeniowe dostarczają nie tylko danych predykcyjnych dotyczących wydajności systemu pod obciążeniem, które pomagają w podejmowaniu decyzji dotyczących architektury, ale także dostarczają informacji operacyjnych zespołom pomocy technicznej, a także menedżerom projektów i konfiguracji, którzy są odpowiedzialni za tworzenie najbardziej produktywnych konfiguracji sprzętu i oprogramowania. Testowanie obciążenia umożliwia zespołowi programistów podejmowanie bardziej świadomych decyzji mających na celu opracowanie optymalnych kompozycji architektonicznych. Klient ze swojej strony otrzymuje możliwość przeprowadzenia testów akceptacyjnych w warunkach zbliżonych do rzeczywistych. 1.8.5. Inspekcje formalne Inspekcje formalne to jeden ze sposobów weryfikacji dokumentów i kodu programu powstającego w procesie tworzenia oprogramowania. Podczas kontroli formalnej zespół specjalistów samodzielnie sprawdza zgodność kontrolowanych dokumentów z oryginałami. Niezależność kontroli zapewnia fakt, że przeprowadzają ją inspektorzy, którzy nie uczestniczyli w opracowywaniu kontrolowanego dokumentu. 1.9. Weryfikacja certyfikowanego oprogramowania Podajmy kilka definicji, które określają struktura ogólna proces certyfikacji oprogramowania: Certyfikacja oprogramowania to proces ustalenia i oficjalnego uznania, że rozwój oprogramowania został przeprowadzony zgodnie z określonymi wymaganiami. W procesie certyfikacji zachodzi interakcja pomiędzy Wnioskodawcą, Jednostką Certyfikującą i Organem Nadzorującym. Wnioskodawcą jest organizacja składająca wniosek do odpowiedniej Jednostki Certyfikującej o otrzymanie certyfikatu (zgodności, jakości, przydatności itp.) danej organizacji. produkt. Jednostka certyfikująca to organizacja, która rozpatruje wniosek Wnioskodawcy o Certyfikację Oprogramowania i samodzielnie lub w drodze powołania specjalnej komisji przeprowadza zestaw procedur mających na celu przeprowadzenie procesu Certyfikacji Oprogramowania Wnioskodawcy. 23 Organ nadzorczy – komisja specjalistów monitorująca procesy rozwojowe Wnioskującego o certyfikację System informacyjny oraz opiniowanie zgodności tego procesu z określonymi wymaganiami, które przedkładane jest do rozpatrzenia Instytucji Certyfikującej. Certyfikacja może mieć na celu uzyskanie certyfikatu zgodności lub certyfikatu jakości. W pierwszym przypadku efektem certyfikacji jest uznanie zgodności procesów rozwojowych z określonymi kryteriami, a funkcjonalności systemu z określonymi wymaganiami. Przykładem takich wymagań mogą być wytyczne Służba federalna w sprawie kontroli technicznej i eksportu w zakresie bezpieczeństwa systemów oprogramowania. W drugim przypadku efektem jest uznanie zgodności procesów rozwojowych z określonymi kryteriami, które gwarantują odpowiedni poziom jakości wytwarzanego produktu i jego przydatność do stosowania w określonych warunkach. Przykładem takich standardów jest szereg międzynarodowych norm jakości ISO 9000:2000 (GOST R ISO 9000-2001) czy normy lotnicze DO-178B, AS9100, AS9006. Testowanie oprogramowania podlegającego certyfikacji ma dwa uzupełniające się cele: Pierwszym celem jest wykazanie, że oprogramowanie spełnia stawiane mu wymagania. Drugim celem jest wykazanie z dużą pewnością, że podczas procesu testowania identyfikowane są błędy, które mogą prowadzić do niedopuszczalnych sytuacji awaryjnych, zgodnie z definicją zawartą w procesie oceny bezpieczeństwa awarii systemu. Na przykład DO-178B wymaga, aby spełnić cele testowania oprogramowania: Testy muszą opierać się głównie na wymaganiach oprogramowania; Testy powinny być zaprojektowane tak, aby weryfikować prawidłowe działanie i ujawniać potencjalne błędy. Analiza kompletności testów w oparciu o wymagania oprogramowania powinna określić, które wymagania nie są testowane. Analiza kompletności testów na podstawie struktury kodu programu powinna określić, które struktury nie zostały wykonane podczas testowania. Norma ta mówi również o testowaniu opartym na wymaganiach. Stwierdzono, że strategia ta jest najskuteczniejsza w identyfikowaniu błędów. Wytyczne dotyczące wyboru przypadków testowych w oparciu o wymagania są następujące: Aby osiągnąć cele testowania oprogramowania, należy przeprowadzić dwie kategorie testów: testy dla sytuacji normalnych i testy dla sytuacji nienormalnych (niespełniających wymagań, odpornych). Należy opracować konkretne przypadki testowe dla wymagań oprogramowania i źródeł błędów nieodłącznie związanych z procesem tworzenia oprogramowania. Celem testów w normalnych sytuacjach jest wykazanie zdolności oprogramowania do reagowania na normalne dane wejściowe i warunki zgodnie z wymaganiami. 24 Celem testów sytuacji nietypowych jest wykazanie zdolności oprogramowania do odpowiedniego reagowania na nietypowe dane wejściowe i warunki, innymi słowy, nie powinno ono powodować awarii systemu. Kategorie awarii systemu ustala się poprzez określenie powagi sytuacji awarii statku powietrznego i jego pasażerów. Każdy błąd w oprogramowaniu może spowodować awarię, która przyczynia się do sytuacji awaryjnej. Zatem poziom integralności oprogramowania wymagany do bezpiecznej pracy jest powiązany z sytuacjami awaryjnymi systemu. Istnieje 5 poziomów sytuacji awaryjnych, od nieistotnych do krytycznie niebezpiecznych. Zgodnie z tymi poziomami wprowadzono pojęcie poziomu krytyczności oprogramowania. Poziom krytyczności determinuje skład dokumentacji dostarczanej jednostce certyfikującej, a co za tym idzie głębokość procesów rozwoju i weryfikacji systemu. Na przykład liczba typów dokumentów i ilość prac związanych z rozwojem systemu wymaganych do certyfikacji na najniższy poziom krytyczności DO-178B może różnić się o jeden lub dwa rzędy wielkości od liczby i objętości wymaganych do certyfikacji na najbardziej wysoki poziom. Konkretne wymagania określa norma, według której planowana jest certyfikacja. 25 TEMAT 2. Testowanie kodu programu (wykłady 2-5) 2.1. Zadania i cele testowania kodu programu Testowanie kodu programu to proces wykonywania kodu programu, mający na celu identyfikację istniejących w nim defektów. Przez defekt rozumie się tu fragment kodu programu, którego wykonanie w określonych warunkach prowadzi do nieoczekiwanego zachowania systemu (tj. zachowania niespełniającego wymagań). Nieoczekiwane zachowanie systemu może prowadzić do nieprawidłowego działania i awarii; w tym przypadku mówią o znaczących defektach w kodzie programu. Niektóre defekty powodują drobne problemy, które nie zakłócają funkcjonowania systemu, ale nieco utrudniają pracę z nim. W tym przypadku mówią o średnich lub drobnych wadach. Zadaniem testowania przy tym podejściu jest określenie warunków, w jakich pojawiają się defekty systemu i zarejestrowanie tych warunków. Zadania testowe zazwyczaj nie obejmują identyfikowania konkretnych wadliwych sekcji kodu programu i nigdy nie obejmują poprawiania defektów - jest to zadanie debugowania wykonywane na podstawie wyników testów systemowych. Celem stosowania procedury testowania kodu programu jest minimalizacja liczby defektów, zwłaszcza tych istotnych, w produkcie końcowym. Same testy nie mogą zagwarantować całkowita nieobecność defekty w kodzie systemu. Jednakże w połączeniu z procesami weryfikacji i walidacji mającymi na celu wyeliminowanie niespójności i niekompletności dokumentacja projektu(w szczególności wymagania wobec systemu), dobrze zorganizowane testowanie gwarantuje, że system spełnia wymagania i zachowuje się zgodnie z nimi we wszystkich zamierzonych sytuacjach. Przy opracowywaniu systemów o zwiększonej niezawodności, np. lotniczych, gwarancje niezawodności osiąga się poprzez przejrzystą organizację procesu testowania, określenie jego powiązania z innymi procesami cyklu życia oraz wprowadzenie cech ilościowych, które pozwalają ocenić powodzenie testów. Co więcej, im wyższe są wymagania dotyczące niezawodności systemu (jego poziomu krytyczności), tym wymagania są bardziej rygorystyczne. Dlatego przede wszystkim bierzemy pod uwagę nie konkretne wyniki testowania konkretnego systemu, ale ogólna organizacja procesu testowania, stosując podejście „dobrze zorganizowany proces daje wynik wysokiej jakości”. Podejście to jest wspólne dla wielu międzynarodowych i branżowych standardów jakości, które zostaną omówione bardziej szczegółowo na końcu tego kursu. Jakość opracowanego systemu przy takim podejściu jest konsekwencją zorganizowanego procesu rozwoju i testowania, a nie niezależnym, niekontrolowanym wynikiem. Ponieważ współczesne systemy oprogramowania są dość duże, podczas testowania kodu programu stosuje się metodę rozkładu funkcjonalnego. System jest podzielony na osobne moduły (klasy, przestrzenie nazw itp.), których funkcjonalność i interfejsy są określone przez wymagania. Następnie każdy moduł jest testowany osobno – przeprowadzane są testy jednostkowe. Następnie poszczególne moduły są składane w większe konfiguracje – przeprowadzane są testy integracyjne, a na koniec testowany jest system jako całość – przeprowadzane są testy systemowe. Z kodowego punktu widzenia testy jednostkowe, integracyjne i systemowe mają ze sobą wiele wspólnego, dlatego w tym temacie skupimy się na testach jednostkowych, a cechy integracji i testowania systemowego omówimy później. 26 Podczas testów jednostkowych każdy moduł jest testowany zarówno pod kątem zgodności z wymaganiami, jak i pod kątem braku problematycznych obszarów kodu programu, które mogłyby powodować awarie i nieprawidłowe działanie systemu. Moduły z reguły nie działają poza systemem – odbierają dane z innych modułów, przetwarzają je i przesyłają dalej. Aby z jednej strony odizolować moduł od systemu i wyeliminować wpływ potencjalnych błędów systemu, a z drugiej strony zapewnić modułowi wszystkie niezbędne dane, wykorzystywane jest środowisko testowe. Zadaniem środowiska testowego jest stworzenie środowiska uruchomieniowego dla modułu i emulacja wszystkich zewnętrznych interfejsów, do których moduł uzyskuje dostęp. Funkcje organizacji środowiska testowego zostaną omówione w tym temacie. Typowa procedura testowa składa się z przygotowania i wykonania przypadków testowych (zwanych także po prostu testami). Każdy przykład testowy sprawdza jedną „sytuację” w zachowaniu modułu i składa się z listy wartości przekazywanych na wejście modułu, opisu uruchomienia i wykonania przetwarzania danych – skryptu testowego oraz listy wartości, jakich oczekuje się na wyjściu modułu, jeśli zachowuje się on poprawnie. Skrypty testowe są kompilowane w taki sposób, aby wykluczać dostęp do wewnętrznych danych modułu; wszelka interakcja powinna odbywać się wyłącznie poprzez jego zewnętrzne interfejsy. Wykonanie przypadku testowego jest wspierane przez środowisko testowe, które obejmuje programową implementację skryptu testowego. Wykonanie rozpoczyna się od przekazania danych wejściowych do modułu i uruchomienia skryptu. Rzeczywiste dane wyjściowe otrzymane z modułu w wyniku wykonania skryptu są zapisywane i porównywane z oczekiwanymi. Jeśli są zgodne, test uważa się za zaliczony; w przeciwnym razie uznaje się go za niezaliczony. Każdy nieudany test oznacza defekt w testowanym module, w środowisku testowym lub w opisie testu. Zbiór opisów przypadków testowych tworzy plan testów – główny dokument definiujący procedurę testowania modułu oprogramowania. Plan testów określa nie tylko same przypadki testowe, ale także kolejność ich występowania, co również może być istotne. Struktura i cechy planów testów zostaną omówione w tym temacie; problemy związane z kolejnością przypadków testowych zostaną omówione w temacie „Powtarzalność testowania”. Podczas testowania często konieczne jest uwzględnienie nie tylko wymagań systemowych, ale także struktury kodu programu testowanego modułu. W tym przypadku testy są zaprojektowane w taki sposób, aby wykryć typowe błędy programistów spowodowane błędną interpretacją wymagań. Stosuje się kontrole warunków brzegowych i kontrole klas równoważności. Brak możliwości w systemie, które nie są określone w wymaganiach, gwarantują różne szacunki pokrycia kodu programu testami, tj. oszacowanie, jaki procent niektórych konstrukcji językowych zostanie ukończonych w wyniku wykonania wszystkich przykładów testowych. Wszystko to zostanie omówione na końcu tego tematu. 2.2. Metody badań 2.2.1. Czarna skrzynka Główną ideą testowania systemu jako czarnej skrzynki jest to, że wszystkie materiały dostępne testerowi stanowią wymagania dla systemu, opisujące jego zachowanie i sam system, z którym może on pracować jedynie poprzez zastosowanie pewnych czynników zewnętrznych jego danych wejściowych i obserwując wyniki, pewne rezultaty. Wszystkie wewnętrzne cechy wdrożenia systemu są ukryte przed testerem, dlatego system jest „czarną skrzynką”, której prawidłowe zachowanie w stosunku do wymagań należy zweryfikować. 27 Z punktu widzenia kodu oprogramowania czarną skrzynką może być zbiór klas (lub modułów) ze znanymi interfejsami zewnętrznymi, ale niedostępnymi kodami źródłowymi. Głównym zadaniem testera jest Ta metoda testowanie polega na konsekwentnym sprawdzaniu, czy zachowanie systemu spełnia wymagania. Dodatkowo tester musi sprawdzić działanie systemu w sytuacjach krytycznych – co się stanie w przypadku podania nieprawidłowych wartości wejściowych. W idealnej sytuacji wszystkie warianty sytuacji krytycznych powinny być opisane w wymaganiach systemowych, a tester może wymyślić jedynie konkretne testy tych wymagań. Jednak w rzeczywistości w wyniku testów identyfikowane są zwykle dwa rodzaje problemów systemowych: 1. Niezgodność zachowania systemu z wymaganiami 2. Niewłaściwe zachowanie systemu w sytuacjach nieprzewidzianych przez wymagania. Obydwa typy problemów są zgłaszane i zgłaszane programistom. Jednocześnie problemy pierwszego rodzaju powodują najczęściej zmiany w kodzie programu, znacznie rzadziej – zmiany wymagań. Zmiana wymagań w w tym przypadku mogą być wymagane ze względu na ich niespójność (kilka różnych wymagań opisuje różne modele zachowania systemu w tej samej sytuacji) lub niepoprawność (wymagania nie odpowiadają rzeczywistości). Problemy drugiego typu wyraźnie wymagają zmiany wymagań ze względu na ich niekompletność - wymagania wyraźnie pomijają sytuację prowadzącą do niewłaściwego zachowania systemu. W tym przypadku niewłaściwe zachowanie można rozumieć jako całkowite załamanie się systemu, lub ogólnie każde zachowanie nieopisane w wymaganiach. Testowanie czarnej skrzynki nazywane jest także testowaniem wymagań, ponieważ... jest to jedyne źródło informacji potrzebnych do zbudowania planu testów. 2.2.2. Szklane (białe) pudełko Testując system jako szklane pudełko, tester ma dostęp nie tylko do wymagań stawianych systemowi, jego wejść i wyjść, ale także do jego wewnętrznej struktury - widzi jego kod programu. Dostępność kodu programu rozszerza możliwości testera w tym sensie, że może on zobaczyć zgodność wymagań z fragmentami kodu programu i tym samym sprawdzić, czy istnieją wymagania dla całego kodu programu. Kod programu, dla którego nie ma wymagań, nazywany jest kodem nieobjętym wymaganiami. Taki kod jest potencjalnym źródłem niewłaściwego zachowania systemu. Dodatkowo przejrzystość systemu pozwala na pogłębienie analizy jego obszarów, które powodują problemy - często jeden problem neutralizuje drugi i nigdy nie występują one jednocześnie. 2.2.3. Testowanie modelowe Testowanie modelowe różni się nieco od klasycznych metod weryfikacji oprogramowania. Przede wszystkim wynika to z faktu, że przedmiotem badań nie jest sam system, ale jego model, zaprojektowany środkami formalnymi. Jeśli pominiemy kwestie sprawdzenia poprawności i stosowalności samego modelu (uważa się, że jego poprawność i zgodność z oryginalnym systemem można wykazać środkami formalnymi), to tester ma do dyspozycji dość potężne narzędzie do analizy ogólną integralność systemu. Pracując z modelem, można stworzyć sytuacje, których nie da się stworzyć w laboratorium testowym dla prawdziwego systemu. Pracując z modelem kodu programu systemu, można analizować jego właściwości oraz takie parametry systemu jak optymalność algorytmów czy jego stabilność. 28 Jednakże testowanie modeli nie rozpowszechniło się właśnie z powodu trudności napotkanych przy opracowywaniu formalnego opisu zachowania systemu. Jednym z nielicznych wyjątków są systemy komunikacji, których aparat algorytmiczny i matematyczny jest dość dobrze rozwinięty. 2.2.4. Analiza kodu programu (inspekcja) W wielu sytuacjach przetestowanie zachowania systemu jako całości jest niemożliwe - poszczególne sekcje kodu programu mogą nigdy nie zostać wykonane, ale zostaną objęte wymaganiami. Przykładem takich sekcji kodu są procedury obsługi wyjątków. Jeśli np. dwa moduły przekazują sobie wartości liczbowe, a w obu modułach działają funkcje sprawdzania wartości, to funkcja sprawdzania modułu odbiorczego nigdy nie zostanie uruchomiona, ponieważ wszystkie błędne wartości zostaną w przetworniku obcięte. W tym przypadku przeprowadzana jest ręczna analiza kodu programu pod kątem poprawności, zwana także przeglądami lub inspekcjami kodu. Jeżeli w wyniku kontroli zostaną zidentyfikowane obszary problematyczne, informacja o tym zostanie przekazana programistom w celu korekty wraz z wynikami regularnych testów. 2.3. Środowisko testowe Większość testów niemal każdego złożonego systemu jest zwykle wykonywana w trybie automatycznym. Ponadto testowany system jest zwykle podzielony na osobne moduły, z których każdy jest testowany najpierw oddzielnie od pozostałych, a następnie jako całość. Oznacza to, że w celu przeprowadzenia testów należy stworzyć środowisko, które zapewni uruchomienie i wykonanie testowanego modułu, przekaże do niego dane wejściowe oraz zbierze rzeczywiste dane wyjściowe uzyskane w wyniku działania systemu na podane dane wejściowe. Następnie środowisko musi porównać rzeczywiste dane wyjściowe z oczekiwanymi i na podstawie tego porównania wyciągnąć wniosek o zgodności zachowania modułu z określonym (rys. 9). Sterownik testowy Oczekiwany wynik Testowane przetwarzanie Moduł wyników danych wejściowych Rzeczywiste dane wyjściowe Stubs Ryc. 9 Uogólniony schemat środowiska testowego Środowisko testowe można również wykorzystać do oddzielenia poszczególnych modułów systemu od całego systemu. Oddzielenie modułów systemu na wczesnych etapach testów pozwala na dokładniejszą lokalizację problemów pojawiających się w kodzie ich programu. Aby wspierać działanie modułu w izolacji od systemu, środowisko testowe musi symulować zachowanie wszystkich modułów, do których funkcji lub danych uzyskuje dostęp testowany moduł. 29
Terminy weryfikacja i walidacja kojarzą się ze sprawdzaniem jakości oprogramowania. Używamy tych terminów w naszych artykułach i raportach. Wielokrotnie słyszeliśmy różne uwagi i argumenty na temat tego, czy analizę statyczną kodu źródłowego programu należy klasyfikować jako weryfikację i walidację oraz jaka jest różnica pomiędzy tymi pojęciami. Generalnie można odnieść wrażenie, że każdy podpisuje pod tymi pojęciami swoje własne pojęcia, a to prowadzi do wzajemnego niezrozumienia.
Postanowiliśmy zrozumieć terminologię, aby zachować jak najbardziej poprawną interpretację tych pojęć. Podczas badań znaleźliśmy pracę V.V. Kulyamin „Metody weryfikacji oprogramowania”. Zawiera szczegółowy opis tych terminów, dlatego postanowiliśmy w dalszym ciągu opierać się na definicjach podanych w tej pracy. Oto kilka fragmentów tej pracy związanych z weryfikacją i walidacją.
Weryfikacja i walidacja to działania mające na celu monitorowanie jakości oprogramowania i wykrywanie w nim błędów. Mając wspólny cel, różnią się źródłami właściwości, zasad i ograniczeń testowanych w trakcie ich trwania, których naruszenie uznawane jest za błąd.
W celu dalszego wyjaśnienia musimy wprowadzić termin „artefakt cyklu życia oprogramowania”. Artefakty cyklu życia oprogramowania to różne jednostki informacyjne, dokumenty i modele utworzone lub wykorzystywane podczas tworzenia i konserwacji oprogramowania. Artefaktami są zatem specyfikacje techniczne, opis architektury, model Tematyka w dowolnym języku graficznym, kodzie źródłowym, dokumentacji użytkownika itp. Różnorodne modele stosowane przez poszczególnych programistów podczas tworzenia i analizowania oprogramowania, ale nie zapisane w formie dokumentów dostępnych dla innych osób, nie mogą być uważane za artefakty.
Weryfikacja sprawdza zgodność niektórych artefaktów powstałych podczas rozwoju i konserwacji oprogramowania z innymi artefaktami utworzonymi wcześniej lub wykorzystanymi jako dane wejściowe, a także zgodność tych artefaktów i procesów ich rozwoju z zasadami i standardami. Weryfikacja sprawdza w szczególności zgodność pomiędzy normami, opisem wymagań ( zakres obowiązków) do oprogramowania, rozwiązań projektowych, kodu źródłowego, dokumentacji użytkownika i funkcjonowania samego oprogramowania. Ponadto sprawdza się, czy wymagania, rozwiązania projektowe, dokumentacja i kod zostały opracowane zgodnie z normami i standardami przyjętymi w danym kraju, branży i organizacji przy tworzeniu oprogramowania, a także czy podczas ich tworzenia wszystkie operacje określone w standardy zostały wykonane w wymaganej kolejności. Błędy i wady wykryte podczas weryfikacji to rozbieżności lub sprzeczności pomiędzy kilkoma wymienionymi dokumentami, pomiędzy dokumentami i prawdziwa praca programu, pomiędzy standardami a rzeczywistymi procesami tworzenia i utrzymania oprogramowania. Jednocześnie podjęcie decyzji, który dokument podlega korekcie (a może i oba), to już osobne zadanie.
Walidacja sprawdza zgodność wszelkich artefaktów powstałych lub wykorzystanych podczas opracowywania i utrzymywania oprogramowania z potrzebami i wymaganiami użytkowników i klientów tego oprogramowania, biorąc pod uwagę prawa obowiązujące w obszarze tematycznym oraz ograniczenia kontekstu użycia oprogramowania . Te potrzeby i wymagania najczęściej nie są dokumentowane – po zarejestrowaniu stają się opisem wymagań, jednym z artefaktów procesu wytwarzania oprogramowania. Dlatego walidacja jest działaniem mniej sformalizowanym niż weryfikacja. Prowadzona jest zawsze z udziałem przedstawicieli klientów, użytkowników, analityków biznesowych czy ekspertów merytorycznych – takich, których opinie można uznać za wystarczająco dobry wyraz rzeczywistych potrzeb i wymagań użytkowników, klientów i innych zainteresowanych stron. Metody jego realizacji często wykorzystują specyficzne techniki pozwalające na rozpoznanie wiedzy i rzeczywistych potrzeb uczestników.
Różnicę między weryfikacją a walidacją pokazano na rysunku 1.
Podane definicje uzyskano poprzez pewne rozszerzenie definicji z normy IEEE 1012 dotyczącej procesów weryfikacji i walidacji. W standardowym słowniku terminów inżynierii oprogramowania IEEE 610.12 z 1990 r. definicja weryfikacji jest w przybliżeniu taka sama, jednak definicja walidacji jest nieco inna - mówi, że walidacja powinna sprawdzać zgodność oprogramowania uzyskanego w wyniku rozwoju z oryginałem wymagania dla niego. W tym przypadku walidacja byłaby szczególnym przypadkiem weryfikacji, o czym nie wspomina się nigdzie w literaturze inżynierii oprogramowania, dlatego też, a także dlatego, że została poprawiona w normie IEEE 1012 z 2004 roku, definicję tę należy uznać za nieprecyzyjną. Częste używanie sformułowania B. Boehma:
Weryfikacja odpowiada na pytanie „Czy produkujemy właściwy produkt?”, a walidacja odpowiada na pytanie „Czy produkujemy właściwy produkt?”
dodaje również zamieszania, ponieważ aforyzm tego stwierdzenia niestety łączy się z dwuznacznością. Jednak liczne prace jego autora sugerują, że przez weryfikację i walidację miał na myśli w przybliżeniu te same pojęcia, które zdefiniowano powyżej. Rozbieżności te można prześledzić także w treści standardów inżynierii oprogramowania. Zatem norma ISO 12207 traktuje testowanie jako rodzaj walidacji, a nie weryfikacji, co najwyraźniej jest konsekwencją zastosowania nieprecyzyjnej definicji ze słownika standardowego.
Podsumowując, chciałbym zauważyć, że zgodnie z powyższymi definicjami analiza statyczna kodu źródłowego programu odpowiada weryfikacji oprogramowania, czyli sprawdzeniu zgodności kodu programu z różnymi standardami kodowania. Analiza statyczna sprawdza zgodność wyników etapu projektowania systemu oprogramowania z wcześniej sformułowanymi wymaganiami i ograniczeniami.
Bibliografia
- V.V. Kulyamin „Metody weryfikacji oprogramowania”. Instytut Programowania Systemowego RAS 109004, Moskwa, ul. B. Kommunistyczna, nr 25.
http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf - Standard IEEE 1012-2004 dotyczący weryfikacji i walidacji oprogramowania. IEEE, 2005.
- IEEE 610.12-1990 Standardowy glosariusz terminologii inżynierii oprogramowania, wydanie poprawione. IEEE, luty 1991.
- B. W. Boehm. Inżynieria oprogramowania; Trendy badawczo-rozwojowe i potrzeby obronne. W R. Wegner, wyd. Badania. Kierunki w technologii oprogramowania. Cambridge, MA: MIT Press, 1979.
- ISO/IEC 12207 Inżynieria systemów i oprogramowania – Procesy cyklu życia oprogramowania. Genewa, Szwajcaria: ISO, 2008.
Testowanie białej skrzynki
Test użyteczności
A) Testowanie obciążenia
Test wydajności
Testy funkcjonalności
Testowanie oprogramowania
Testowanie to proces wykonywania programu (lub części programu) z zamiarem (lub celem) znalezienia błędów.
Istnieje kilka kryteriów, według których zwyczajowo klasyfikuje się rodzaje testów. Zazwyczaj identyfikuje się następujące objawy:
I) Przez obiekt testowy:
(ustalanie lub zbieranie wskaźników wydajności i czasu reakcji oprogramowania i sprzętu systemu lub urządzenia w odpowiedzi na żądanie zewnętrzne w celu ustalenia zgodności z wymaganiami dla danego systemu)
b) Testy warunków skrajnych
(ocenia niezawodność i stabilność systemu w przypadku przekroczenia granic normalnej pracy.)
c) Testowanie stabilności
4) Testowanie interfejsu użytkownika
5) Testowanie bezpieczeństwa
6) Testowanie lokalizacji
7) Testowanie kompatybilności
II) Dzięki znajomości systemu:
1) Testowanie czarnej skrzynki
(bada się obiekt, którego struktura wewnętrzna jest nieznana)
(sprawdzana jest wewnętrzna struktura programu, dane testowe uzyskuje się analizując logikę programu)
III) Według stopnia automatyzacji:
1) Testowanie ręczne
2) Testowanie automatyczne
3) Testowanie półautomatyczne
IV) Według stopnia izolacji komponentów:
1) Testowanie komponentowe (jednostkowe).
2) Testowanie integracyjne
3) Testowanie systemu
V) Testując czas:
1) Testy alfa– zamknięty proces testowania programu przez pełnoetatowych programistów lub testerów. Produkt alfa jest najczęściej ukończony tylko w 50%; kod programu jest obecny, ale brakuje znacznej części projektu.
2) Testy beta– intensywne użytkowanie prawie gotowej wersji programu w celu identyfikacji maksymalnej liczby błędów w jego działaniu w celu ich późniejszej eliminacji przed ostatecznym wypuszczeniem na rynek, dla masowego odbiorcy. Do testów rekrutowani są ochotnicy spośród zwykłych przyszłych użytkowników.
Weryfikacja oprogramowania jest pojęciem bardziej ogólnym niż testowanie. Celem weryfikacji jest upewnienie się, że weryfikowany element (wymagania lub kod programu) spełnia wymagania, jest zaimplementowany bez niezamierzonych funkcji oraz spełnia specyfikacje i standardy projektowe ( ISO 9000-2000). Proces weryfikacji obejmuje inspekcje, testowanie kodu, analizę wyników testów, generowanie i analizę raportów o problemach. Dlatego ogólnie przyjmuje się, że proces testowania jest integralną częścią procesu weryfikacji.