20. Weryfikacja i kwalifikacja oprogramowanie
Weryfikacja i walidacja odnosi się do procesów weryfikacji i przeglądu, które sprawdzają, czy oprogramowanie jest zgodne ze specyfikacją i wymaganiami klienta. Weryfikacja i kwalifikacja obejmuje pełne koło życia Oprogramowanie – rozpoczynają się na etapie analizy wymagań, a kończą weryfikacją kodu programu na etapie testowania gotowego systemu oprogramowania.
Weryfikacja i atestacja to nie to samo, choć łatwo je pomylić. Krótko mówiąc, różnicę między nimi można zdefiniować w następujący sposób:
Weryfikacja odpowiada na pytanie, czy system jest prawidłowo zaprojektowany;
Certyfikacja odpowiada na pytanie, czy system działa poprawnie.
Zgodnie z tymi definicjami weryfikacja polega na sprawdzeniu zgodności oprogramowania ze specyfikacją systemu, w szczególności z wymaganiami funkcjonalnymi i niefunkcjonalnymi. Certyfikacja – więcej ogólny proces. Podczas walidacji musisz upewnić się, że oprogramowanie spełnia oczekiwania klienta. Walidacja przeprowadzana jest po weryfikacji w celu określenia na ile system spełnia nie tylko specyfikację, ale również oczekiwania klienta.
Jak wspomniano wcześniej, walidacja wymagań systemowych jest bardzo ważna na wczesnych etapach tworzenia oprogramowania. W wymaganiach często występują błędy i pominięcia; w takich przypadkach finalny produkt prawdopodobnie nie spełni oczekiwań klienta. Ale oczywiście walidacja wymagań nie może ujawnić wszystkich problemów w specyfikacji wymagań. Czasami luki i błędy w wymaganiach są wykrywane dopiero po zakończeniu wdrożenia systemu.
Procesy weryfikacji i walidacji wykorzystują dwie główne techniki sprawdzania i analizowania systemów.
1. Inspekcja oprogramowania. Analiza i weryfikacja różnych reprezentacji systemu, takich jak dokumentacja specyfikacji wymagań, diagramy architektoniczne czy kod źródłowy programu. Kontrola odbywa się na wszystkich etapach procesu tworzenia oprogramowania. Równolegle z inspekcją można przeprowadzić automatyczną analizę kodu źródłowego programów i powiązanych dokumentów. Inspekcja i automatyczna analiza to statyczne metody weryfikacji i walidacji, ponieważ nie wymagają systemu wykonywalnego.
2. Testowanie oprogramowania. Uruchamianie kodu wykonywalnego z danymi testowymi oraz badanie wyników i wydajności Produkt oprogramowania aby sprawdzić poprawność działania systemu. Testowanie jest dynamiczną metodą weryfikacji i walidacji, ponieważ jest stosowane do działającego systemu.
Na ryc. Rysunek 20.1 przedstawia miejsce kontroli i testowania w procesie tworzenia oprogramowania. Strzałki wskazują etapy procesu rozwoju, na których można zastosować te metody. Zgodnie z tym schematem inspekcja może być wykonywana na wszystkich etapach procesu rozwoju systemu, a testowanie - podczas tworzenia prototypu lub programu wykonywalnego.
Metody inspekcji obejmują: inspekcję programu, automatyczną analizę kodu źródłowego oraz weryfikację formalną. Jednak metody statyczne mogą jedynie sprawdzić zgodność programów ze specyfikacją, nie można ich użyć do sprawdzenia poprawności działania systemu. Ponadto niefunkcjonalne cechy, takie jak wydajność i niezawodność, nie mogą być testowane metodami statycznymi. Dlatego w celu oceny charakterystyk niefunkcjonalnych przeprowadza się testowanie systemu.
Ryż. 20.1. Weryfikacja i atestacja statyczna i dynamiczna
Pomimo powszechnego stosowania inspekcji oprogramowania, testowanie jest nadal dominującą metodą weryfikacji i certyfikacji. Testowanie to weryfikacja działania programów z danymi zbliżonymi do rzeczywistych, które będą przetwarzane podczas działania systemu. Obecność w programie defektów i niezgodności z wymaganiami jest wykrywana poprzez badanie danych wyjściowych i identyfikowanie wśród nich anomalii. Testowanie odbywa się na etapie wdrożenia systemu (w celu sprawdzenia, czy system spełnia oczekiwania programistów) oraz po zakończeniu jego wdrożenia.
Na różnych etapach procesu tworzenia oprogramowania stosowane są różne rodzaje testów.
1. Testowanie wad przeprowadzane w celu wykrycia niezgodności między programem a jego specyfikacją, które wynikają z błędów lub wad w programach. Takie testy mają na celu wykrycie błędów w systemie, a nie symulację jego działania.
2. Testy statystyczne ocenia wydajność i niezawodność programów, a także działanie systemu w różnych trybach pracy. Testy mają na celu naśladowanie rzeczywistego działania systemu z rzeczywistymi danymi wejściowymi. Niezawodność systemu ocenia się na podstawie liczby awarii odnotowanych w pracy programów. Wydajność jest oceniana przez pomiar całkowitego czasu działania i czasu odpowiedzi systemu podczas przetwarzania danych testowych.
Głównym celem weryfikacji i kwalifikacji jest upewnienie się, że system jest „odpowiedni do celu”. Przydatność systemu oprogramowania do zamierzonego celu nie oznacza, że powinien on być całkowicie wolny od błędów. System powinien być raczej odpowiednio dostosowany do celów, do których został przeznaczony. Wymagany ważność zgodności zależy od przeznaczenia systemu, oczekiwań użytkowników i warunków rynkowych dla oprogramowania.
1. Cel oprogramowania. Poziom niezawodności zgodności zależy od tego, jak krytyczne jest opracowane oprogramowanie według określonych kryteriów. Na przykład poziom ufności dla systemów krytycznych dla bezpieczeństwa powinien być znacznie wyższy niż ten sam poziom ufności dla prototypów. systemy oprogramowania rozwijane, aby zademonstrować kilka 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, które pojawiają się podczas działania programów, że nie są tym zaskoczeni. Są gotowi tolerować awarie systemu, jeśli korzyści z jego używania przewyższają wady. Jednak od początku lat 90. tolerancja użytkowników na awarie systemów oprogramowania stopniowo spada. W ostatnim czasie tworzenie zawodnych systemów stało się prawie nie do zaakceptowania, dlatego firmy tworzące oprogramowanie muszą zwracać coraz większą uwagę na weryfikację i walidację oprogramowania.
3. Warunki rynkowe oprogramowania. Oceniając system oprogramowania, sprzedawca musi znać konkurujące systemy, cenę, jaką kupujący jest gotów zapłacić za system, oraz oczekiwany czas wprowadzenia tego systemu na rynek. Jeśli firma deweloperska ma kilku konkurentów, konieczne jest określenie daty wejścia systemu na rynek przed zakończeniem pełnego testowania i debugowania, w przeciwnym razie konkurenci mogą być pierwszymi, którzy wejdą na rynek. Jeśli klienci nie chcą kupować oprogramowania po wysokiej cenie, mogą chcieć tolerować więcej awarii systemu. Przy ustalaniu kosztów procesu weryfikacji i kwalifikacji należy uwzględnić wszystkie te czynniki.
Z reguły podczas weryfikacji i atestacji znajdują się błędy w systemie. W systemie wprowadzane są zmiany w celu poprawienia błędów. Ten proces debugowania zwykle zintegrowane z innymi procesami weryfikacji i atestacji. Jednak testowanie (lub ogólniej, weryfikacja i walidacja) oraz debugowanie to różne procesy, które mają różne cele.
1. Weryfikacja i walidacja to proces wykrywania defektów w systemie oprogramowania.
2. Debugowanie - proces lokalizowania defektów (błędów) i ich naprawiania (ryc. 20.2).
Ryż. 20.2. Proces debugowania
Nie ma prostych metod debugowania programów. Doświadczeni debugerzy znajdują błędy, porównując wzorce wyników testów 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. Bardzo ważna jest znajomość procesu tworzenia oprogramowania. Debugery są świadome najczęstszych błędów programistycznych (takich jak zwiększanie licznika). Uwzględnia również błędy typowe dla niektórych języków programowania, na przykład te związane z użyciem wskaźników w języku C.
Lokalizowanie błędów w kodzie programu nie zawsze jest prostym procesem, ponieważ błąd niekoniecznie znajduje się w pobliżu punktu w kodzie programu, w którym nastąpiła awaria. Aby wyizolować błędy, debuger 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 obsługi języka, które są zintegrowane z systemem kompilacji kodu. Zapewniają one specjalne środowisko wykonywania programu, dzięki któremu można uzyskać dostęp do tabeli identyfikatorów, a stamtąd do wartości zmiennych. Użytkownicy często kontrolują wykonywanie programu krok po kroku, przechodząc kolejno od instrukcji do instrukcji. Po wykonaniu każdego zestawienia sprawdzane są wartości zmiennych i identyfikowane są ewentualne błędy.
Błąd znaleziony w programie zostaje poprawiony, po czym konieczne jest ponowne sprawdzenie programu. Aby to zrobić, możesz ponownie sprawdzić program lub powtórzyć poprzedni test. Ponowne testowanie ma na celu upewnienie się, że zmiany wprowadzone w programie nie wprowadzają nowych błędów do systemu, ponieważ w praktyce duży odsetek „naprawek” albo nie kończy się całkowicie, albo wprowadza nowe błędy do programu.
W zasadzie konieczne jest ponowne uruchomienie wszystkich testów podczas ponownego testowania po każdej poprawce, ale w praktyce takie podejście jest zbyt kosztowne. Dlatego podczas planowania procesu testowania określa się zależności pomiędzy częściami systemu i przypisuje testy do każdej części. Następnie możliwe jest prześledzenie elementów programu za pomocą specjalnych przypadków testowych (danych kontrolnych) wybranych dla tych elementów. Jeśli wyniki śledzenia są udokumentowane, to tylko podzbiór całego zestawu danych testowych może być użyty do przetestowania zmienionego elementu programu i jego zależnych komponentów.
Celem tego kursu jest przedstawienie kompleksowego obrazu procesu weryfikacji oprogramowania. Przedmiotem dyskusji są różne podejścia i metody stosowane w dziedzinie weryfikacji, aw szczególności testowania oprogramowania. Zakłada się, że tworzone oprogramowanie jest częścią większej wspólny system. Taki system obejmuje komponenty sprzętowe, informacyjne i organizacyjne (człowiek użytkownika, człowiek-operator itp.) opracowane prawdopodobnie przez różne zespoły. Dlatego potrzebne są dokumenty rozwojowe, które określają wymagania dla różnych komponentów systemu i zasady ich interakcji. Ponadto zakłada się, że awarie systemu mogą prowadzić do konsekwencji o takiej lub innej wadze, więc przy tworzeniu oprogramowania wysiłki poświęcone na identyfikację ukrytych wad są konieczne i uzasadnione. Przede wszystkim dotyczy środków i procedur weryfikacji oprogramowania. Kurs obejmuje szereg praktycznych ćwiczeń ilustrujących techniki i metody weryfikacji oprogramowania w środowisku Microsoft Visual Studio 2005 Team Edition for Software Testers na przykładzie prostego systemu. Niniejsza publikacja jest częścią Biblioteki programów nauczania, która jest opracowywana przez program współpracy akademickiej MSDN Academic Alliance (MSDN AA).
Poniższy tekst jest automatycznie wyodrębniany z oryginalnego dokumentu PDF i służy wyłącznie do podglądu.
Brakuje obrazów (zdjęć, wzorów, wykresów).
Ryż. 7 Testowanie, weryfikacja i walidacja Weryfikacja oprogramowania jest pojęciem bardziej ogólnym niż testowanie. Celem weryfikacji jest uzyskanie pewności, że weryfikowany obiekt (wymagania lub kod programu) jest zgodny z wymaganiami, jest zaimplementowany bez niezamierzonych funkcji oraz spełnia specyfikacje i normy projektowe. Proces weryfikacji obejmuje inspekcje, testy kodu, analizę wyników testów, generowanie i analizę raportów o problemach. Dlatego ogólnie przyjmuje się, że proces testowania jest: część integralna proces weryfikacji, to samo założenie jest wykonane w tym samouczku. Walidacja systemu informatycznego to proces, którego celem jest udowodnienie, że w wyniku rozwoju systemu osiągnęliśmy cele, które zaplanowaliśmy poprzez jego wykorzystanie. Innymi słowy walidacja to weryfikacja zgodności systemu z oczekiwaniami klienta. Kwestie związane z walidacją są poza zakresem tego kurs treningowy i stanowią osobny interesujący temat do nauki. Jeśli spojrzysz na te trzy procesy pod kątem pytania, na które odpowiadają, to 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 to „Czy zrobił to, co powinien?” lub „Czy opracowany system spełnia oczekiwania klienta?”. 1.7. Dokumentacja tworzona na różnych etapach cyklu życia Synchronizacja wszystkich etapów rozwoju odbywa się za pomocą dokumentów, które powstają na każdym etapie. Jednocześnie dokumentacja powstaje zarówno w bezpośrednim segmencie cyklu życia – podczas tworzenia systemu oprogramowania, jak i odwrotnie – podczas jego weryfikacji. Spróbujmy na przykładzie cyklu życia w kształcie litery V prześledzić, jakie typy dokumentów są tworzone na każdym z segmentów i jakie relacje między nimi istnieją (rys. 8). Wynikiem etapu opracowywania wymagań systemowych są sformułowane wymagania dla systemu - dokument opisujący ogólne zasady działania systemu, jego interakcję z " środowisko» - użytkowników systemu oraz oprogramowania i sprzętu zapewniającego jego działanie. Zwykle równolegle z wymaganiami dla systemu tworzony jest plan weryfikacji i definiowana jest strategia weryfikacji. Dokumenty te określają ogólne podejście do sposobu przeprowadzania testów, jakie metodologie zostaną zastosowane, jakie aspekty przyszłego systemu powinny zostać poddane rygorystycznym testom. Kolejnym zadaniem rozwiązywanym przez zdefiniowanie strategii weryfikacji jest określenie miejsca różnych procesów weryfikacyjnych i ich relacji z procesami rozwojowymi. 20 Proces weryfikacji współpracujący z wymaganiami systemowymi to proces walidacji wymagań, porównywania ich z rzeczywistymi oczekiwaniami klienta. Patrząc w przyszłość, powiedzmy, że proces walidacji różni się od testów akceptacyjnych wykonywanych w momencie przekazania gotowego systemu do klienta, chociaż można go uznać za część takich testów. Walidacja jest sposobem na udowodnienie 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 rozwoju oprogramowania Wymagania systemowe są podstawą procesu tworzenia wymagań funkcjonalnych i architektury projektu. W trakcie tego procesu opracowywane są ogólne wymagania dotyczące oprogramowania systemu, dotyczące funkcji, które musi spełniać. Wymagania funkcjonalne często obejmują definicję wzorców zachowania systemu w normalnych i sytuacje awaryjne , reguły przetwarzania danych i definicje interfejsu użytkownika. Treść wymagania z reguły zawiera słowa „powinien, 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. ” Podstawą do opracowania architektury systemu są wymagania funkcjonalne – opis jego struktury w zakresie podsystemów i jednostek strukturalnych języka, w którym realizowana jest implementacja – obszary, klasy, moduły, funkcje itp. Na podstawie wymagań funkcjonalnych pisane są wymagania testowe – dokumenty zawierające definicję kluczowych punktów, które należy sprawdzić, aby upewnić się, że implementacja wymagań funkcjonalnych jest prawidłowa. Wymagania testowe często zaczynają się od słów „Sprawdź co” i zawierają linki do odpowiadających im wymagań funkcjonalnych. Przykładowe wymagania testowe dla powyższego wymagania funkcjonalnego to „Sprawdź, czy jeśli temperatura na czujniku ABC spadnie poniżej 30 stopni Celsjusza, system wyda dźwięk ostrzegawczy” oraz „Sprawdź, czy jeśli temperatura na czujniku ABC przekroczy 30 stopni Celsjusza, system nie emituje sygnału dźwiękowego." 21 Jednym z problemów pojawiających się podczas pisania wymagań testowych jest fundamentalna nietestowalność niektórych wymagań, na przykład wymagania „Interfejs użytkownika musi być intuicyjny” nie może być testowane bez jasnego zdefiniowania, czym jest 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 uwzględniających 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 programu systemu, a do jego weryfikacji na podstawie wymagań testowych przygotowywany jest plan testów – opis sekwencji przypadków testowych sprawdzających zgodność systemu wdrożenie z wymaganiami. Każdy przypadek testowy zawiera konkretny opis wartości dostarczanych jako dane wejściowe do systemu, wartości, które są oczekiwane jako dane wyjściowe oraz opis scenariusza wykonania testu. W zależności od przedmiotu testowania plan testów może być przygotowany albo jako program w języku programowania, albo jako plik danych wejściowych do narzędzia, które wykonuje testowany system i przekazuje mu wartości określone w planie testów, lub jako instrukcje dla użytkownika systemu, które opisują niezbędne kroki, które należy podjąć w celu przetestowania różnych funkcji systemu. W wyniku wykonania wszystkich przypadków testowych gromadzone są statystyki dotyczące pomyślnego zaliczenia testu - procent przypadków testowych, dla których rzeczywiste wartości wyjściowe pokrywały się z oczekiwanymi, tzw. zaliczone testy. Nieudane testy są wstępnymi danymi do analizy przyczyn błędów i ich późniejszej korekty. Na etapie integracji poszczególne moduły systemu łączone są w jedną całość i wykonywane są przypadki testowe sprawdzające pełną funkcjonalność systemu. Na ostatnim etapie gotowy system dostarczany jest do klienta. Przed wdrożeniem specjaliści klienta wraz z programistami przeprowadzają testy akceptacyjne – sprawdzają funkcje krytyczne dla użytkownika zgodnie z wcześniej zaakceptowanym programem testowym. Po pomyślnym zakończeniu testów system jest przekazywany do klienta, w przeciwnym razie jest przesyłany do rewizji. 1.8. Rodzaje procesów testowania i weryfikacji oraz ich miejsce w różnych modelach cyklu życia 1.8.1. Testowanie jednostkowe Małe jednostki (procedury, zajęcia itp.) poddawane są 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 w grafie zależności danych, wartości graniczne parametrów. Zgodnie z tym konstruowane są kryteria pokrycia testami (objęte są wszystkie operatory, wszystkie gałęzie logiczne, wszystkie punkty graniczne itp.). . Testy jednostkowe są zwykle wykonywane dla każdego niezależnego moduł oprogramowania i jest prawdopodobnie najczęstszym rodzajem testowania, zwłaszcza dla 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 bywa omawiany „klasyczny” model nieprawidłowej organizacji testowania systemu modułów, zwany często metodą „dużego skoku”. Istotą metody jest najpierw przetestowanie każdego modułu z osobna, a następnie połączenie ich w system i przetestowanie całego systemu. W przypadku dużych systemów jest to nierealne. Dzięki takiemu podejściu dużo czasu spędzimy na lokalizacji błędów, a jakość testów pozostanie niska. Alternatywą dla „wielkiego skoku” są testy integracyjne, gdy system jest budowany etapami, grupy modułów dodawane są stopniowo. 1.8.3. Testowanie systemu W pełni zaimplementowany produkt oprogramowania jest poddawany testom systemowym. Na tym etapie testera nie interesuje poprawność wykonania poszczególnych procedur i metod, ale cały program jako całość, tak jak widzi to użytkownik końcowy. Podstawą testów są: Ogólne wymagania do programu, w tym nie tylko poprawność implementacji funkcji, ale także wydajność, czas reakcji, odporność na awarie, ataki, błędy użytkownika itp. W przypadku testowania systemowego i modułowego stosowane są określone typy kryteriów pokrycia testów (na przykład objęte są wszystkie typowe scenariusze pracy, wszystkie scenariusze z nietypowymi sytuacjami, sparowane kompozycje scenariuszy itp.). 1.8.4. Testy obciążeniowe Testy obciążeniowe nie tylko dostarczają danych predykcyjnych dotyczących wydajności systemu pod obciążeniem, które koncentrują się na podejmowaniu decyzji dotyczących architektury, ale także dostarczają informacji operacyjnych zespołom wsparcia technicznego, a także kierownikom projektów i konfiguracji, którzy są odpowiedzialni za tworzenie najbardziej produktywnych konfiguracje sprzętowe i programowe. Testowanie obciążenia pozwala zespołowi programistów na 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 Inspekcja formalna to jeden ze sposobów weryfikacji dokumentów i kodu programu powstałego podczas procesu tworzenia oprogramowania. Podczas kontroli formalnej grupa specjalistów samodzielnie sprawdza zgodność skontrolowanych dokumentów z dokumentami oryginalnymi. Niezależność weryfikacji zapewnia fakt, że przeprowadzają ją inspektorzy, którzy nie brali udziału w opracowaniu kontrolowanego dokumentu. 1.9. Weryfikacja certyfikowanego oprogramowania Podajmy kilka definicji, które definiują: ogólna struktura Proces certyfikacji oprogramowania: Certyfikacja oprogramowania to proces ustalania i formalnego uznania, że rozwój oprogramowania został przeprowadzony zgodnie z określonymi wymaganiami. W trakcie procesu certyfikacji dochodzi do interakcji Wnioskodawcy, Instytucji Certyfikującej i Organu Nadzoru Wnioskodawca jest organizacją, która składa wniosek do odpowiedniej Instytucji Certyfikującej o uzyskanie certyfikatu (zgodność, jakość, odpowiedniość itp.) produkt. Jednostka Certyfikująca – organizacja, która rozpatruje wniosek Wnioskodawcy o Certyfikację Oprogramowania i samodzielnie lub w formie specjalnej komisji opracowuje zestaw procedur mających na celu przeprowadzenie procesu Certyfikacji Oprogramowania Wnioskodawcy. 23 Organ nadzorczy – komisja specjalistów nadzorująca procesy opracowania przez Wnioskodawcę certyfikowanego System informacyjny oraz opiniowanie zgodności tego procesu z określonymi wymaganiami, która jest przekazywana do rozpatrzenia Jednostce Certyfikującej. Certyfikacja może mieć na celu uzyskanie certyfikatu zgodności lub certyfikatu jakości. W pierwszym przypadku wynikiem certyfikacji jest uznanie zgodności procesów rozwojowych z określonymi kryteriami oraz funkcjonalności systemu z określonymi wymaganiami. Przykładem takich wymagań mogą być dokumenty z wytycznymi. Służba Federalna w sprawie kontroli technicznej i eksportowej w zakresie bezpieczeństwa systemów oprogramowania. W drugim przypadku efektem jest uznanie zgodności procesów rozwojowych z określonymi kryteriami, co gwarantuje odpowiedni poziom jakości wytwarzanego produktu i jego przydatności 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) lub norm lotniczych DO-178B, AS9100, AS9006. Testowanie certyfikacji oprogramowania ma dwa uzupełniające się cele: Pierwszym celem jest wykazanie, że oprogramowanie spełnia jego wymagania. Drugim celem jest wykazanie z wysokim poziomem pewności, że błędy, które mogą prowadzić do niedopuszczalnych sytuacji awaryjnych, określonych w procesie oceny bezpieczeństwa systemu, są identyfikowane podczas procesu testowania. Na przykład, zgodnie z wymaganiami normy DO-178B, aby spełnić cele testowania oprogramowania, konieczne jest: Testy przede wszystkim muszą być oparte na wymaganiach oprogramowania; Testy powinny być zaprojektowane tak, aby zweryfikować poprawność działania i stworzyć warunki do identyfikacji potencjalnych błędów. Przeglądanie kompletności testów na podstawie wymagań oprogramowania powinno 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 testów. Ten standard mówi również o testowaniu opartym na wymaganiach. Stwierdzono, że strategia ta jest najskuteczniejsza w wykrywaniu błędów. Wytyczne dotyczące wyboru przypadków testowych w oparciu o wymagania obejmują: Aby osiągnąć cele testowania oprogramowania, należy przeprowadzić dwie kategorie testów: testy dla sytuacji normalnych i testy dla sytuacji nienormalnych (niewymaganych, odpornych). Należy opracować konkretne przypadki testowe dla wymagań oprogramowania i źródeł błędów 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 w nietypowych sytuacjach jest wykazanie zdolności oprogramowania do adekwatnej reakcji na nietypowe dane wejściowe i warunki, innymi słowy, nie powinno to powodować awarii systemu. Kategorie sytuacji awaryjnych dla systemu są ustalane poprzez określenie niebezpieczeństwa sytuacji awaryjnej dla statku powietrznego i jego pasażerów. Każdy błąd w oprogramowaniu może spowodować awarię, która przyczyni się do sytuacji awarii. Zatem poziom integralności oprogramowania wymagany do bezpiecznej pracy związany jest z sytuacjami awaryjnymi systemu. Istnieje 5 poziomów sytuacji awaryjnych, od drobnych do krytycznych. Zgodnie z tymi poziomami wprowadzono pojęcie poziomu krytyczności oprogramowania. Poziom krytyczności determinuje skład dokumentacji przedłożonej jednostce certyfikującej, a co za tym idzie głębokość procesów rozwoju i weryfikacji systemu. Na przykład liczba rodzajów dokumentów i ilość prac rozwojowych systemu wymaganych do certyfikacji dla najniższego poziomu 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 dla najbardziej wysoki poziom. Szczegółowe wymagania określa norma, zgodnie z którą planuje się przeprowadzić certyfikację. 25 TEMAT 2. Testowanie kodu programu (wykłady 2-5) 2.1. Zadania i cele testowania kodu programu Testowanie kodu programu to proces wykonania kodu programu mający na celu zidentyfikowanie w nim istniejących defektów. Defekt jest tu rozumiany jako fragment kodu programu, którego wykonanie w określonych warunkach prowadzi do nieoczekiwanego zachowania systemu (tj. zachowania, które nie spełnia wymagań). Nieoczekiwane zachowanie systemu może prowadzić do awarii w jego działaniu i awarii, w tym przypadku mówi o znaczących defektach w kodzie programu. Niektóre usterki powodują drobne problemy, które nie zakłócają funkcjonowania systemu, ale nieco utrudniają pracę z nim. W tym przypadku mówimy 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 zwykle nie obejmują identyfikowania określonych wadliwych sekcji kodu programu i nigdy nie obejmują naprawiania defektów - jest to zadanie debugowania, które jest wykonywane na podstawie wyników testów systemowych. Celem zastosowania procedury testowania kodu programu jest zminimalizowanie liczby defektów, szczególnie znaczących, w produkcie końcowym. Samo testowanie nie może zagwarantować całkowitego braku defektów w kodzie systemu. Jednak 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 dla systemu), dobrze zorganizowane testowanie zapewnia, że system spełnia wymagania i zachowuje się zgodnie z nimi we wszystkich przewidywanych sytuacjach. Przy opracowywaniu systemów o podwyższonej niezawodności, np. lotniczej, gwarancje niezawodności uzyskuje się poprzez jasną organizację procesu testowania, określanie jego powiązania z innymi procesami cyklu życia, wprowadzanie charakterystyk ilościowych, które pozwalają ocenić powodzenie testowania. Jednocześnie im wyższe wymagania dotyczące niezawodności systemu (jego poziomu krytyczności), tym bardziej rygorystyczne są wymagania. Dlatego przede wszystkim bierzemy pod uwagę nie konkretne wyniki testowania konkretnego systemu, ale ogólna organizacja proces testowania, stosując podejście „dobrze zorganizowany proces daje wynik jakościowy”. Takie podejście 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 wynikiem zorganizowanego procesu rozwoju i testowania, a nie niezależnego niezarządzanego wyniku. Ponieważ nowoczesne systemy oprogramowania są bardzo duże, podczas testowania kodu programu stosowana jest metoda dekompozycji funkcjonalnej. System podzielony jest na osobne moduły (klasy, przestrzenie nazw itp.), które mają funkcjonalność i interfejsy zdefiniowane przez wymagania. Następnie każdy moduł jest indywidualnie testowany – wykonywane są testy jednostkowe. Następnie poszczególne moduły są składane w większe konfiguracje – wykonywane są testy integracyjne, a na końcu testowany jest system jako całość – wykonywane są testy systemowe. Z punktu widzenia kodu programu testy jednostkowe, integracyjne i systemowe mają ze sobą wiele wspólnego, dlatego w tym temacie skupimy się na testowaniu jednostkowym, cechy testowania integracyjnego i systemowego zostaną omówione później. 26 Podczas testów jednostkowych każdy moduł jest testowany zarówno pod kątem zgodności z wymaganiami, jak i braku problematycznych fragmentów kodu programu, które mogą powodować awarie i awarie w systemie. Z reguły moduły nie działają poza systemem - odbierają dane z innych modułów, przetwarzają je i przekazują dalej. Aby z jednej strony odizolować moduł od systemu i wykluczyć wpływ potencjalnych błędów systemowych, a z drugiej zapewnić modułowi wszystkie niezbędne dane, wykorzystywane jest środowisko testowe. Zadaniem środowiska testowego jest stworzenie środowiska uruchomieniowego modułu, aby emulować wszystkie zewnętrzne interfejsy, do których moduł uzyskuje dostęp. O cechach organizacji środowiska testowego zostaną omówione w tym temacie. Typowa procedura testowa polega na przygotowaniu i wykonaniu przypadków testowych (nazywanych również po prostu testami). Każdy przypadek testowy sprawdza jedną „sytuację” w zachowaniu modułu i składa się z listy wartości przekazanych na wejście modułu, opisu uruchomienia i wykonania przetwarzania danych – scenariusz testowy oraz listy wartości, które są oczekiwane na wyjściu modułu w przypadku jego prawidłowego zachowania. Scenariusze testowe są zestawiane w taki sposób, aby wykluczyć dostęp do wewnętrznych danych modułu, wszelkie interakcje powinny 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 się zgadzają, test uznaje się za zdany, w przeciwnym razie nie jest zdany. Każdy nieudany test wskazuje albo na defekt w testowanej jednostce, albo w środowisku testowym, albo w opisie testu. Zbiór opisów przypadków testowych to plan testów - główny dokument określający procedurę testowania modułu programu. Plan testów określa nie tylko same przypadki testowe, ale także kolejność ich wykonywania, co również może mieć znaczenie. Struktura i cechy planów testów zostaną omówione w tym temacie, problemy związane z kolejnością przypadków testowych - w temacie "Testowanie powtarzalności". Podczas testowania często konieczne jest uwzględnienie nie tylko wymagań stawianych systemowi, ale także struktury kodu programu testowanego modułu. W takim przypadku testy projektowane są w taki sposób, aby wykryć typowe błędy programistów spowodowanych błędną interpretacją wymagań. Stosowane są kontrole warunków brzegowych, kontrole klasy równoważności. Brak w systemie możliwości, które nie są określone wymaganiami, gwarantuje różne szacunki pokrycia kodu programu przez testy, tj. szacuje, jaki procent niektórych konstrukcji językowych jest wykonywany w wyniku wykonania wszystkich przypadkó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 dla testera to wymagania dla systemu opisujące jego zachowanie i sam system, z którymi może pracować tylko poprzez zastosowanie pewnych zewnętrznych wpływów do jego nakłady i obserwacja wyników przynosi pewien skutek. Wszystkie wewnętrzne cechy wdrożenia systemu są ukryte przed testerem, dzięki czemu system jest „czarną skrzynką”, której poprawność zachowania w odniesieniu do wymagań ma być sprawdzana. 27 Z punktu widzenia kodu programu czarna skrzynka może być zbiorem klas (lub modułów) ze znanymi interfejsami zewnętrznymi, ale niedostępnymi tekstami źródłowymi. Głównym zadaniem testera tej metody testowania jest konsekwentne sprawdzanie, czy zachowanie systemu spełnia wymagania. Dodatkowo tester musi przetestować system w sytuacjach krytycznych – co się stanie, jeśli zostaną podane nieprawidłowe wartości wejściowe. W idealnej sytuacji wszystkie warianty sytuacji krytycznych powinny być opisane w wymaganiach dla systemu, a tester może wymyślić tylko konkretne sprawdzenia tych wymagań. Jednak w rzeczywistości w wyniku testowania zwykle ujawniają się dwa rodzaje problemów systemowych: 1. Niezgodność zachowania się systemu z wymaganiami 2. Nieadekwatne zachowanie się systemu w sytuacjach nieprzewidzianych wymaganiami. Zgłoszenia obu typów problemów są dokumentowane i udostępniane programistom. Jednocześnie problemy pierwszego typu zwykle powodują zmianę w kodzie programu, znacznie rzadziej - zmianę wymagań. Zmiana wymagań w tym przypadku może być wymagana 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ę, która prowadzi do nieodpowiedniego zachowania systemu. Jednocześnie nieodpowiednie zachowanie można rozumieć jako całkowite załamanie systemu lub ogólnie każde zachowanie, które nie jest opisane w wymaganiach. Testowanie czarnoskrzynkowe jest również nazywane testowaniem wymagań. jest to jedyne źródło informacji do budowy planu testów. 2.2.2. Szklana (biała) skrzynka Testując system jak skrzynka szklana, tester ma dostęp nie tylko do wymagań dotyczących systemu, jego wejść i wyjść, ale także do jego struktury wewnętrznej – widzi kod programu. Dostępność kodu programu rozszerza możliwości testera o to, że może on zobaczyć zgodność wymagań z sekcjami kodu programu i tym samym zobaczyć, czy istnieją wymagania dla całego kodu programu. Kod programu, dla którego nie ma wymagań, nazywany jest kodem bez wymagań. Taki kod jest potencjalnym źródłem niewłaściwego zachowania systemu. Dodatkowo przejrzystość systemu pozwala pogłębić analizę jego obszarów, które powodują problemy – często jeden problem neutralizuje inny i nigdy nie występują jednocześnie. 2.2.3. Testowanie modelu Testowanie modelu jest nieco oddalone od klasycznych metod weryfikacji oprogramowania. Przede wszystkim wynika to z faktu, że przedmiotem testowania nie jest sam system, ale zaprojektowany w sposób formalny jego model. Jeśli odłożyć na bok kwestie sprawdzania poprawności i stosowalności samego modelu (uważa się, że jego poprawność i zgodność z oryginalnym systemem można udowodnić środkami formalnymi), to tester ma do dyspozycji dość potężne narzędzie do analizy ogólna integralność systemu. Pracując z modelem, możesz tworzyć sytuacje, których nie można stworzyć w laboratorium testowym dla rzeczywistego 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 testowanie modelowe nie stało się szeroko rozpowszechnione właśnie ze względu na trudności napotkane w opracowaniu formalnego opisu zachowania systemu. Jednym z nielicznych wyjątków są systemy komunikacyjne, których aparat algorytmiczny i matematyczny jest dość dobrze rozwinięty. 2.2.4. Analiza kodu programu (inspekcje) W wielu sytuacjach testowanie zachowania systemu jako całości jest niemożliwe - poszczególne sekcje kodu programu mogą nigdy nie zostać wykonane, podczas gdy zostaną objęte wymaganiami. Przykładem takich sekcji kodu są procedury obsługi wyjątków. Jeżeli np. dwa moduły prześlą do siebie wartości liczbowe, a funkcje walidacji wartości działają w obu modułach, to funkcja sprawdzania modułu odbiorczego nigdy nie zostanie aktywowana, ponieważ wszystkie błędne wartości zostaną odcięte w nadajniku. W takim przypadku wykonywana jest ręczna analiza kodu programu pod kątem poprawności, zwana również przeglądami kodu lub inspekcjami. Jeżeli w wyniku inspekcji zostaną zidentyfikowane obszary problemowe, informacja o tym jest przekazywana programistom do korekty wraz z wynikami regularnych testów. 2.3. Środowisko testowe Większość testów prawie każdego złożonego systemu jest zwykle przeprowadzana w: tryb automatyczny. 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 do przeprowadzenia testów konieczne jest stworzenie pewnego rodzaju środowiska, które zapewni uruchomienie i wykonanie testowanego modułu, przekaże mu dane wejściowe oraz zbierze rzeczywiste dane wyjściowe uzyskane w wyniku działania systemu na podane dane wejściowe. Następnie środowisko powinno 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 Oczekiwane dane wyjściowe w trakcie testu Przetwarzanie danych wejściowych Moduł wyników Rzeczywiste odcinki danych wyjściowych 9 Uogólniony schemat środowiska testowego Środowisko testowe można również wykorzystać do oddzielenia poszczególnych modułów systemu od całego systemu. Wyodrębnienie modułów systemu na wczesnych etapach testowania pozwala na dokładniejsze zlokalizowanie problemów, które pojawiają się w ich kodzie programu. Aby wesprzeć działanie modułu w izolacji od systemu, środowisko testowe powinno modelować zachowanie wszystkich modułów, których funkcje lub dane są dostępne dla testowanego modułu. 29
Wysyłanie dobrej pracy do bazy wiedzy jest proste. Skorzystaj z poniższego formularza
Studenci, doktoranci, młodzi naukowcy, którzy wykorzystują bazę wiedzy w swoich studiach i pracy będą Ci bardzo wdzięczni.
Hostowane na http://www.allbest.ru/
abstrakcyjny
Metody weryfikacji i testowania oprogramowania
Wstęp
Ludzie mają tendencję do popełniania błędów. Błędy zawsze były i zawsze będą. W środowisku IT krąży żart, że jeśli program uruchamia się za pierwszym razem i od razu działa, to trzeba poszukać błędu.
Wraz z rozwojem Informatyka, wraz z jego przenikaniem do wszystkich sfer życia, rośnie również liczba błędów w programach. Ponadto wzrost liczby błędów jest nieproporcjonalny do wzrostu liczby programów. Każdego roku szeregi programistów są uzupełniane przez bydlocoderów (a ich nazwa to legion), którzy wykładniczo rozwijają dziedzinę błędów.
Błędy nie są widoczne w każdym obszarze. Na przykład nikt nie przejmuje się błędami i lukami w przeglądarkach takich jak „amigo”. Tak, a straty wynikające z takich błędów są nieznaczne: maksimum, które zwykły użytkownik może stracić, to konta w sieciach społecznościowych, półtora tysiąca przeciętnych zdjęć z wakacji i kolekcja porno.
Są jednak obszary, w których błędy programistyczne mogą prowadzić do najbardziej niefortunnych konsekwencji. Jednym z pierwszych przypadków, jakie udało mi się znaleźć, jest statek kosmiczny Mariner 1, który został zniszczony 22 lipca 1962 r., 293 sekundy po wystrzeleniu, z powodu błędu w programie komputera pokładowego. Dobrze, że wtedy nie było zgonów.
A co się stanie, jeśli komputer pokładowy Boeinga-747 z 400 pasażerami na pokładzie wrzuci wyjątek?
To dla takich obszarów, które można nazwać „poważnymi”, wynaleziono metody weryfikacji i testowania.
W części literatury zagranicznej identyfikowane są procesy weryfikacji i testowania, a w niektórych miejscach testowanie uznawane jest za jedną z metod weryfikacji. Wykonam tę pracę zgodnie z moim najlepszym zrozumieniem, osobno rozważę procesy weryfikacji i testowania. Również, uczciwie, poruszę temat walidacji oprogramowania.
1. Definicje
Koło życia(LC) oprogramowanie. Termin ten odnosi się do przedziału czasowego od pomysłu stworzenia oprogramowania o funkcjonalności niezbędnej do rozwiązania określonych problemów, aż do całkowitego zaprzestania użytkowania Ostatnia wersja ten program.
Artefakty cykl życia oprogramowania (SW). Obejmuje to różnorodne materiały informacyjne związane z tworzeniem oprogramowania. Są to warunki odniesienia, opis architektury, kod źródłowy, dokumentacja użytkownika i inne dokumenty. Materiały, które zostały użyte podczas tworzenia, ale nie zostały nagrane w przystępnej formie (na przykład komentarze w kodzie i nadużycia programistów na czacie) nie są artefaktami.
2. Weryfikacja
Weryfikacja sprawdza zgodność niektórych artefaktów powstałych w trakcie tworzenia i utrzymania oprogramowania z innymi wcześniej utworzonymi lub używanymi jako dane wejściowe, a także zgodność tych artefaktów i procesów ich tworzenia z regułami i standardami. W szczególności weryfikacja sprawdza zgodność pomiędzy normami norm, opisem wymagań (warunkami odniesienia) dla oprogramowania, rozwiązaniami projektowymi, kodem źródłowym, dokumentacją użytkownika oraz samym funkcjonowaniem oprogramowania. Ponadto sprawdza się, czy wymagania rozwiązania projektowe, dokumentacja i kod są opracowywane zgodnie z normami i standardami przyjętymi w danym kraju, branży i organizacji przy tworzeniu oprogramowania, a także aby podczas ich tworzenia wszystkie operacje określone w standardach zostały wykonane w wymaganej kolejności. Błędy i defekty wykryte podczas weryfikacji to rozbieżności lub sprzeczności pomiędzy kilkoma wymienionymi dokumentami, pomiędzy dokumentami a faktycznym działaniem programu, pomiędzy normami norm a faktycznymi procesami tworzenia i utrzymania oprogramowania. Jednocześnie decyzja, który dokument ma zostać poprawiony (być może oba) to osobne zadanie.
Powyższe jest oficjalną definicją weryfikacji. W rzeczywistości wszystko jest znacznie prostsze: weryfikacja określa czy robimy program dobrze?.
Dlatego głównymi metodami weryfikacji są badanie i inspekcja.
weryfikacja wiedzy programowej
3. Walidacja
Proces walidacji sprawdza zgodność wszelkich artefaktów stworzonych lub wykorzystywanych podczas rozwoju i utrzymania oprogramowania z potrzebami i wymaganiami użytkowników i klientów tego oprogramowania, z uwzględnieniem przepisów prawa Tematyka oraz ograniczenia kontekstu, w którym używane jest oprogramowanie.
I znowu, za wieloma słowami kryje się bardzo proste zadanie: podczas procesu walidacji sprawdzane jest, czy określona funkcjonalność programu jest potrzebna tym użytkownikom/klientom. Czy oprogramowanie spełnia życzenia klientów i użytkowników końcowych.
4. Testowanie
Testowanie to proces wykrywania błędów w oprogramowaniu poprzez wykonanie kodu systemu oprogramowania na danych testowych, zbieranie charakterystyk wydajnościowych w dynamice wykonania w określonym środowisku operacyjnym, identyfikowanie różnych błędów, defektów, awarii i usterek spowodowanych przez nieregularne i anormalne sytuacje lub nieprawidłowe zakończenie oprogramowania.
Historycznie pierwszym typem testowania było debugowanie.
Debugowanie to sprawdzenie opisu obiektu programu w języku programowania w celu wykrycia w nim błędów, a następnie ich wyeliminowania. Błędy są wykrywane przez kompilator podczas kontroli składni. Po debugowaniu przeprowadzana jest weryfikacja w celu sprawdzenia poprawności kodu oraz walidacja w celu sprawdzenia, czy produkt spełnia określone wymagania.
1. Metody badań statycznych
Metody statyczne są stosowane przy przeprowadzaniu przeglądów i przeglądów specyfikacji komponentów bez ich implementacji. Technika analizy statycznej polega na metodycznym przeglądaniu i analizowaniu struktury programów oraz udowadnianiu ich poprawności. Analiza statyczna ma na celu analizę dokumentów opracowanych na wszystkich etapach cyklu życia i polega na inspekcji kodu źródłowego oraz kompleksowej kontroli programu.
Inspekcja oprogramowania to statyczne sprawdzenie zgodności programu z określonymi specyfikacjami, przeprowadzane poprzez analizę różnych reprezentacji wyników projektowania (dokumentacji, wymagań, specyfikacji, diagramów lub kodu źródłowego programu) na procesach cyklu życia. Przeglądy i inspekcje wyników projektowania i ich zgodności z wymaganiami klienta zapewniają więcej wysoka jakość stworzył systemy oprogramowania.
2. Dynamiczne metody testowania
Metoda czarnej skrzynki. Podczas korzystania z tej metody wykorzystywane są informacje o rozwiązywanym problemie, ale nic o strukturze programu nie jest znane. Celem testowania zgodnie z tą zasadą jest zidentyfikowanie maksymalnej liczby błędów w jednym teście przy użyciu małego podzbioru możliwych danych wejściowych.
Metody testowe według tej zasady służą do testowania funkcji zaimplementowanych w programie poprzez sprawdzenie rozbieżności między rzeczywistym zachowaniem funkcji a zachowaniem oczekiwanym, z uwzględnieniem specyfikacji wymagań. Podczas przygotowań do tego testu budowane są tabele warunków, wykresy przyczynowo-skutkowe 1 oraz obszary awarii. Ponadto przygotowywane są zestawy testów, które uwzględniają parametry i warunki środowiskowe, które wpływają na zachowanie funkcji.
Metoda białego pudełka.
Metoda ta pozwala na eksplorację wewnętrznej struktury programu, a wykrycie wszystkich błędów w programie jest kryterium wyczerpującego testowania tras przepływu sterowania, wśród których brane są pod uwagę:
Kryterium pokrycia operatora - zestaw testów zbiorczych musi zapewnić, że każdy operator zostanie zaliczony przynajmniej raz;
Kryterium testowania gałęzi (aka pokrycie decyzji lub pokrycie przejścia) — zestaw testów w agregacie musi zapewniać, że każda gałąź lub wyjście zostanie zaliczone przynajmniej raz.
3. Testy funkcjonalne
Celem testów funkcjonalnych jest wykrycie niezgodności między rzeczywistym zachowaniem zaimplementowanych funkcji a zachowaniem oczekiwanym zgodnie ze specyfikacją i wymaganiami początkowymi. Testy funkcjonalne powinny obejmować wszystkie zaimplementowane funkcje z uwzględnieniem najbardziej prawdopodobnych rodzajów błędów. Scenariusze testowe łączące poszczególne testy nastawione są na sprawdzenie jakości rozwiązywania problemów funkcjonalnych.
Testy funkcjonalne tworzone są według specyfikacji funkcji, informacji projektowych oraz tekstu w języku programowania i służą do określenia kompletności realizacji zadań funkcjonalnych oraz ich zgodności z wymaganiami początkowymi.
Zadania testowania funkcjonalnego obejmują:
Identyfikacja zbioru wymagań funkcjonalnych;
Identyfikacja funkcji zewnętrznych i konstruowanie sekwencji funkcji zgodnie z ich wykorzystaniem w systemie oprogramowania;
Identyfikacja zbioru danych wejściowych każdej funkcji i określenie obszarów ich zmiany;
Budowa zestawów testowych i scenariuszy do testowania funkcji;
Identyfikacja i prezentacja wszystkich wymagań funkcjonalnych za pomocą przypadków testowych i testowania błędów w programie oraz podczas interakcji ze środowiskiem.
Testy tworzone na podstawie informacji projektowych są powiązane ze strukturami danych, algorytmami, interfejsami pomiędzy poszczególnymi komponentami i służą do testowania komponentów i ich interfejsów. Głównym celem jest zapewnienie kompletności i spójności zaimplementowanych funkcji oraz interfejsów między nimi.
5. Typy błędów ANSI/IEEE-7 29 -8 3
Błąd (błąd) - stan programu, w którym powstają nieprawidłowe wyniki, których przyczyną są wady (wady) w wypowiedziach programu lub w proces technologiczny jego rozwój, co prowadzi do błędnych interpretacji informacje ogólne, co prowadzi do niewłaściwego rozwiązania.
Wada (błąd) w programie – konsekwencja błędów programisty na dowolnym etapie rozwoju, które mogą być zawarte w oryginale lub specyfikacji projektu, tekstach kodów programu, dokumentacji operacyjnej itp. Podczas wykonywania programu może zostać wykryty defekt lub awaria.
Awaria (awaria) to odstępstwo programu od funkcjonowania lub niemożność wykonywania przez program funkcji określonych przez wymagania i ograniczenia, które jest traktowane jako zdarzenie, które przyczynia się do przejścia programu w stan niesprawności z powodu błędów , ukryte w nim wady lub awarie w funkcjonującym środowisku. Awaria może wynikać z następujących przyczyn:
Błędna specyfikacja lub pominięte wymaganie, co oznacza, że specyfikacja nie odzwierciedla dokładnie zamierzeń użytkownika;
Specyfikacja może zawierać wymaganie, którego nie można spełnić na danym sprzęcie i oprogramowaniu;
Projekt programu może zawierać błędy (np. baza danych jest projektowana bez zabezpieczeń przed nieautoryzowanym dostępem użytkownika, ale ochrona jest wymagana);
Program może być niepoprawny, tj. wykonuje nietypowy algorytm lub nie jest w pełni zaimplementowany.
Wniosek
Rosyjskie GOST związane z weryfikacją i testowaniem oprogramowania to tłumaczenia „burżuazyjnych” standardów, takich jak ISO 12207, ANSI/IEEE-729-83 i innych (jest ich wiele). Problem polega na tym, że te międzynarodowe standardy w różny sposób traktują kwestie testowania i weryfikacji. Nie znaczy to, że całkowicie sobie zaprzeczają, ale mogą powodować dezorientację.
Wszystkie te standardy zostały sformułowane w latach 80. ubiegłego wieku dla amerykańskiego przemysłu kosmicznego. W kolejnych latach były poprawiane i wznawiane, ale rozbieżności i sprzeczności w dokumentach pozostały.
Wniosek: strukturę metod weryfikacji, walidacji i testowania należy postrzegać jako warunkową.
Bibliografia
1. Darmowa encyklopedia wikipedia.org
2. Kulyamin V.V. Metody weryfikacji oprogramowania M.: Institute for System Programming, 2008
3. Lavrishcheva E., Petrukhin V. Wykład „Metody sprawdzania i testowania programów i systemów”: NOU „INTUIT” http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130
Hostowane na Allbest.ru
...Podobne dokumenty
Cykl życia oprogramowania to proces ciągły, który zaczyna się od decyzji o potrzebie stworzenia oprogramowania, a kończy się całkowitym wycofaniem go z eksploatacji. Podejście Rileya, Lehmana i Boehma do definicji cyklu życia oprogramowania.
streszczenie, dodane 1.11.2009
Pojęcie technologii tworzenia programów. Podstawy projektowania oprogramowania. Modele cyklu życia, które powstały historycznie podczas opracowywania teorii projektowania oprogramowania. Modele spiralne (spiralne), kaskadowe i iteracyjne.
prezentacja, dodana 11.05.2015
Historia rozwoju i rodzaje testowania oprogramowania. Instalacja, regresja, konfiguracja, integracja, lokalizacja, testowanie jednostkowe. Metody redukcji złożoności testów jednostkowych tworzonej aplikacji.
praca semestralna, dodana 16.12.2015
Nierozstrzygalność problemu testowania oprogramowania. Rodzaje i poziomy testowania. Strategie testowania w górę i w dół. Metody „białej” i „czarnej” skrzynki. Testowanie automatyczne i ręczne. Rozwój poprzez testowanie.
praca semestralna, dodano 22.03.2015 r.
Wymagania dotyczące technologii projektowania oprogramowania (SW). Kompozycja i opis etapów pełnego cyklu życia oprogramowania. Klasyfikacja modeli cyklu życia oprogramowania, ich cechy. Metodologie tworzenia oprogramowania, ekstremalne techniki programowania.
prezentacja, dodana 19.09.2016
Historia testowania oprogramowania, główne cele i cechy jego realizacji. Rodzaje i rodzaje badań, poziomy jego automatyzacji. Wykorzystanie i badania niezbędne technologie. Pełny cykl prowadzenie całego systemu monitoringu.
praca dyplomowa, dodana 05.03.2018
Główne międzynarodowe standardy w tej dziedzinie Technologie informacyjne. Międzynarodowy standard ISO/IEC 9126 Jakość i cykl życia. Charakterystyka wewnętrznych i zewnętrznych atrybutów jakości. Analiza funkcjonalności oprogramowania.
raport, dodano 13.06.2017
Cele i zadania inżynierii oprogramowania. Pojęcie oprogramowania. Sześć zasad efektywne wykorzystanie oprogramowanie. Rodzaje oprogramowania: ogólnosystemowe, sieciowe i stosowane. Zasady budowy oprogramowania.
praca semestralna, dodano 29.06.2010 r.
Ogólna charakterystyka głównych modeli cyklu życia: kaskadowy, przyrostowy, spiralny. Etap w ramach procesu wytwarzania oprogramowania, ograniczony do określonego przedziału czasowego i kończący się wydaniem konkretnego produktu.
prezentacja, dodano 27.12.2013
Informatyzacja Rosji. Rynek narzędzia programowe. Główne zadania standaryzacji, certyfikacji i licencjonowania w zakresie informatyzacji. Zbiór inżynierskich metod i narzędzi do tworzenia oprogramowania. Cykl życia oprogramowania.
Weryfikacja i walidacja odnosi się do procesów weryfikacji i przeglądu, które sprawdzają, czy oprogramowanie jest zgodne ze specyfikacją i wymaganiami klienta. Weryfikacja i walidacja 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 atestacja to nie to samo, choć łatwo je pomylić. Krótko mówiąc, różnicę między nimi można zdefiniować w następujący sposób:
Weryfikacja odpowiada na pytanie, czy system jest prawidłowo zaprojektowany;
Certyfikacja odpowiada na pytanie, czy system działa poprawnie.
Zgodnie z tymi definicjami weryfikacja polega na sprawdzeniu zgodności oprogramowania ze specyfikacją systemu, w szczególności z wymaganiami funkcjonalnymi i niefunkcjonalnymi. Certyfikacja jest procesem bardziej ogólnym. Podczas walidacji musisz upewnić się, że oprogramowanie spełnia oczekiwania klienta. Walidacja przeprowadzana jest po weryfikacji w celu określenia na ile system spełnia nie tylko specyfikację, ale również oczekiwania klienta.
Jak wspomniano wcześniej, walidacja wymagań systemowych jest bardzo ważna na wczesnych etapach tworzenia oprogramowania. W wymaganiach często występują błędy i pominięcia; w takich przypadkach finalny produkt prawdopodobnie nie spełni oczekiwań klienta. Ale oczywiście walidacja wymagań nie może ujawnić wszystkich problemów w specyfikacji wymagań. Czasami luki i błędy w wymaganiach są wykrywane dopiero po zakończeniu wdrożenia systemu.
Procesy weryfikacji i walidacji wykorzystują dwie główne techniki sprawdzania i analizowania systemów.
1. Inspekcja oprogramowania. Analiza i weryfikacja różnych reprezentacji systemu, takich jak dokumentacja specyfikacji wymagań, diagramy architektoniczne czy kod źródłowy programu. Kontrola odbywa się na wszystkich etapach procesu tworzenia oprogramowania. Równolegle z inspekcją można przeprowadzić automatyczną analizę kodu źródłowego programów i powiązanych dokumentów. Inspekcja i automatyczna analiza to statyczne metody weryfikacji i walidacji, ponieważ nie wymagają systemu wykonywalnego.
2. Testowanie oprogramowania. Uruchamianie kodu wykonywalnego z danymi testowymi i sprawdzanie danych wyjściowych i wydajności oprogramowania w celu sprawdzenia, czy system działa poprawnie. Testowanie jest dynamiczną metodą weryfikacji i walidacji, ponieważ jest stosowane do działającego systemu.
Na ryc. Rysunek 20.1 przedstawia miejsce kontroli i testowania w procesie tworzenia oprogramowania. Strzałki wskazują etapy procesu rozwoju, na których można zastosować te metody. Zgodnie z tym schematem inspekcja może być wykonywana na wszystkich etapach procesu rozwoju systemu, a testowanie - podczas tworzenia prototypu lub programu wykonywalnego.
Metody inspekcji obejmują: inspekcję programu, automatyczną analizę kodu źródłowego oraz weryfikację formalną. Jednak metody statyczne mogą jedynie sprawdzić zgodność programów ze specyfikacją, nie można ich użyć do sprawdzenia poprawności działania systemu. Ponadto niefunkcjonalne cechy, takie jak wydajność i niezawodność, nie mogą być testowane metodami statycznymi. Dlatego w celu oceny charakterystyk niefunkcjonalnych przeprowadza się testowanie systemu.
Ryż. 20.1. Weryfikacja i atestacja statyczna i dynamiczna
Pomimo powszechnego stosowania inspekcji oprogramowania, testowanie jest nadal dominującą metodą weryfikacji i certyfikacji. Testowanie to weryfikacja działania programów z danymi zbliżonymi do rzeczywistych, które będą przetwarzane podczas działania systemu. Obecność w programie defektów i niezgodności z wymaganiami jest wykrywana poprzez badanie danych wyjściowych i identyfikowanie wśród nich anomalii. Testowanie odbywa się na etapie wdrożenia systemu (w celu sprawdzenia, czy system spełnia oczekiwania programistów) oraz po zakończeniu jego wdrożenia.
Na różnych etapach procesu tworzenia oprogramowania stosowane są różne rodzaje testów.
1. Testowanie wad przeprowadzane w celu wykrycia niezgodności między programem a jego specyfikacją, które wynikają z błędów lub wad w programach. Takie testy mają na celu wykrycie błędów w systemie, a nie symulację jego działania.
2. Testy statystyczne ocenia wydajność i niezawodność programów, a także działanie systemu w różnych trybach pracy. Testy mają na celu naśladowanie rzeczywistego działania systemu z rzeczywistymi danymi wejściowymi. Niezawodność systemu ocenia się na podstawie liczby awarii odnotowanych w pracy programów. Wydajność jest oceniana przez pomiar całkowitego czasu działania i czasu odpowiedzi systemu podczas przetwarzania danych testowych.
główny cel Weryfikacja i kwalifikacja – w celu upewnienia się, że system jest „odpowiedni do celu”. Przydatność systemu oprogramowania do zamierzonego celu nie oznacza, że powinien on być całkowicie wolny od błędów. System powinien być raczej odpowiednio dostosowany do celów, do których został przeznaczony. Wymagany ważność zgodności zależy od przeznaczenia systemu, oczekiwań użytkowników i warunków rynkowych dla oprogramowania.
1. Cel oprogramowania. Poziom niezawodności zgodności zależy od tego, jak krytyczne jest opracowane oprogramowanie według określonych kryteriów. Na przykład poziom ufności dla systemów krytycznych dla bezpieczeństwa powinien być znacznie wyższy niż dla prototypowych systemów oprogramowania opracowywanych w celu zademonstrowania jakiegoś nowego pomysłu.
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, które pojawiają się podczas działania programów, że nie są tym zaskoczeni. Są gotowi tolerować awarie systemu, jeśli korzyści z jego używania przewyższają wady. Jednak od początku lat 90. tolerancja użytkowników na awarie systemów oprogramowania stopniowo spada. W ostatnim czasie tworzenie zawodnych systemów stało się prawie nie do zaakceptowania, dlatego firmy tworzące oprogramowanie muszą zwracać coraz większą uwagę na weryfikację i walidację oprogramowania.
3. Warunki rynkowe oprogramowania. Oceniając system oprogramowania, sprzedawca musi znać konkurujące systemy, cenę, jaką kupujący jest gotów zapłacić za system, oraz oczekiwany czas wprowadzenia tego systemu na rynek. Jeśli firma deweloperska ma kilku konkurentów, konieczne jest określenie daty wejścia systemu na rynek przed zakończeniem pełnego testowania i debugowania, w przeciwnym razie konkurenci mogą być pierwszymi, którzy wejdą na rynek. Jeśli klienci nie chcą kupować oprogramowania po wysokiej cenie, mogą chcieć tolerować więcej awarii systemu. Przy ustalaniu kosztów procesu weryfikacji i kwalifikacji należy uwzględnić wszystkie te czynniki.
Z reguły podczas weryfikacji i atestacji znajdują się błędy w systemie. W systemie wprowadzane są zmiany w celu poprawienia błędów. Ten proces debugowania zwykle zintegrowane z innymi procesami weryfikacji i atestacji. Jednak testowanie (lub ogólniej, weryfikacja i walidacja) oraz debugowanie to różne procesy, które mają różne cele.
1. Weryfikacja i walidacja to proces wykrywania defektów w systemie oprogramowania.
2. Debugowanie - proces lokalizowania defektów (błędów) i ich naprawiania (ryc. 20.2).
Ryż. 20.2. Proces debugowania
Nie ma prostych metod debugowania programów. Doświadczeni debugerzy znajdują błędy, porównując wzorce wyników testów 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. Bardzo ważna jest znajomość procesu tworzenia oprogramowania. Debugery są świadome najczęstszych błędów programistycznych (takich jak zwiększanie licznika). Uwzględnia również błędy typowe dla niektórych języków programowania, na przykład te związane z użyciem wskaźników w języku C.
Lokalizowanie błędów w kodzie programu nie zawsze jest prostym procesem, ponieważ błąd niekoniecznie znajduje się w pobliżu punktu w kodzie programu, w którym nastąpiła awaria. Aby wyizolować błędy, debuger 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 obsługi języka, które są zintegrowane z systemem kompilacji kodu. Zapewniają one specjalne środowisko wykonywania programu, dzięki któremu można uzyskać dostęp do tabeli identyfikatorów, a stamtąd do wartości zmiennych. Użytkownicy często kontrolują wykonywanie programu krok po kroku, przechodząc kolejno od instrukcji do instrukcji. Po wykonaniu każdego zestawienia sprawdzane są wartości zmiennych i identyfikowane są ewentualne błędy.
Błąd znaleziony w programie zostaje poprawiony, po czym konieczne jest ponowne sprawdzenie programu. Aby to zrobić, możesz ponownie sprawdzić program lub powtórzyć poprzedni test. Ponowne testowanie ma na celu upewnienie się, że zmiany wprowadzone w programie nie wprowadzają nowych błędów do systemu, ponieważ w praktyce duży odsetek „naprawek” albo nie kończy się całkowicie, albo wprowadza nowe błędy do programu.
W zasadzie konieczne jest ponowne uruchomienie wszystkich testów podczas ponownego testowania po każdej poprawce, ale w praktyce takie podejście jest zbyt kosztowne. Dlatego podczas planowania procesu testowania określa się zależności pomiędzy częściami systemu i przypisuje testy do każdej części. Następnie możliwe jest prześledzenie elementów programu za pomocą specjalnych przypadków testowych (danych kontrolnych) wybranych dla tych elementów. Jeśli wyniki śledzenia są udokumentowane, to tylko podzbiór całego zestawu danych testowych może być użyty do przetestowania zmienionego elementu programu i jego zależnych komponentów.
Planowanie weryfikacji i atestacji
Weryfikacja i walidacja to kosztowny proces. W przypadku dużych systemów, takich jak systemy czasu rzeczywistego ze złożonymi ograniczeniami niefunkcjonalnymi, połowa budżetu na rozwój systemu jest przeznaczana na proces weryfikacji i walidacji. Dlatego potrzeba starannego zaplanowania tego procesu jest oczywista.
Planowanie weryfikacji i walidacji w ramach rozwoju systemów oprogramowania powinno rozpocząć się jak najwcześniej. Na ryc. Rysunek 20.3 przedstawia model wytwarzania oprogramowania uwzględniający proces planowania testów. W tym miejscu planowanie rozpoczyna się już w fazie specyfikacji i projektowania systemu. Model ten jest czasami określany jako model V (aby zobaczyć V, obróć rysunek 20.3 o 90°). Schemat ten pokazuje również podział procesu weryfikacji i atestacji na kilka etapów, z odpowiednimi badaniami wykonywanymi na każdym etapie.
Ryż. 20.3. Planowanie testów podczas tworzenia i testowania
W procesie planowania weryfikacji i certyfikacji konieczne jest określenie relacji pomiędzy statycznymi i dynamicznymi metodami sprawdzania systemu, określenie standardów i procedur kontroli i testowania oprogramowania, zatwierdzenie mapa technologiczna przeglądy oprogramowania (patrz rozdział 19.2) i opracowanie planu testów oprogramowania. To, czy inspekcja lub testowanie jest ważniejsze, zależy od rodzaju opracowywanego systemu i doświadczenia organizacji. Im bardziej krytyczny system, tym większą uwagę należy zwrócić na statyczne metody weryfikacji.
Plan weryfikacji i walidacji koncentruje się na standardach procesu testowego, a nie na opisie konkretnych testów. Ten plan to nie tylko wskazówki, jest przeznaczony głównie dla profesjonalistów zajmujących się tworzeniem i testowaniem systemów. Plan umożliwia personelowi technicznemu uzyskanie pełnego obrazu testów systemu i zaplanowanie swojej pracy w tym kontekście. Ponadto plan dostarcza informacji menedżerom, którzy są odpowiedzialni za zapewnienie zespołowi testowemu całego niezbędnego sprzętu i oprogramowania.
Plan testów nie jest stałym dokumentem. Należy go regularnie przeglądać, ponieważ testowanie zależy od procesu wdrażania systemu. Na przykład, jeśli implementacja jakiejś części systemu nie zostanie zakończona, to nie ma możliwości przetestowania montażu systemu. Dlatego plan musi być okresowo przeglądany, aby personel testujący mógł być wykorzystany do innych zadań.
Te dwie koncepcje walidacji i weryfikacji są często mylone. Ponadto walidacja wymagań systemowych jest często mylona z walidacją systemu. Proponuję przyjrzeć się temu problemowi.
W artykule rozważyłem dwa podejścia do modelowania obiektowego: jako całość i jako struktura. W obecnym artykule będziemy potrzebować tego podziału.
Załóżmy, że mamy zaprojektowany obiekt funkcjonalny. Niech ten obiekt będzie przez nas traktowany jako część konstrukcji kolejnego Obiektu funkcjonalnego. Niech będzie taki opis budowy Przedmiotu, aby zawierał opis przedmiotu. W takim opisie obiekt posiada opis jako całość, czyli jego interfejsy interakcji z innymi obiektami są opisane w ramach konstrukcji Obiektu. Niech zostanie podany opis obiektu jako struktury. Niech będzie obiekt informacyjny zawierający wymagania dotyczące projektowania opisu obiektu jako struktury. Niech powstanie zasób wiedzy zawierający reguły wnioskowania, na podstawie których z opisu obiektu jako całości uzyskuje się opis obiektu jako struktury. Zasób wiedzy jest tym, czego projektantów uczy się w instytutach - dużo, dużo wiedzy. Pozwalają na podstawie wiedzy o obiekcie zaprojektować jego strukturę.
Więc możesz zacząć. Można argumentować, że jeśli przedmiot jako całość jest poprawnie opisany, jeśli zasób wiedzy jest poprawny i jeśli przestrzegane są zasady wnioskowania, to wynikowy opis konstrukcji przedmiotu będzie poprawny. Czyli na podstawie tego opisu obiekt funkcjonalny odpowiadający prawdziwe warunki operacja. Jakie ryzyko może się pojawić:
1. Wykorzystanie błędnej wiedzy o Przedmiocie. Model Przedmiotu w ludzkich umysłach może nie odpowiadać rzeczywistości. Na przykład nie znali prawdziwego niebezpieczeństwa trzęsień ziemi. W związku z tym wymagania dotyczące obiektu mogą być błędnie sformułowane.
2. Niepełny zapis wiedzy o Przedmiocie - czegoś brakuje, popełniane są błędy. Na przykład wiedzieli o wiatrach, ale zapomnieli o tym wspomnieć. Może to prowadzić do niewystarczająco pełnego opisu wymagań dla obiektu.
3. Niewłaściwy zasób wiedzy. Uczono nas pierwszeństwa masy nad innymi parametrami, ale okazało się, że musimy zwiększyć prędkość.
4. Nieprawidłowe zastosowanie reguł wnioskowania do opisu obiektu. Błędy logiczne, czegoś brakuje w wymaganiach do projektu obiektu, ślad wymagań jest zepsuty.
5. Niepełny zapis uzyskanych wniosków dotyczących projektu systemu. Wszystko zostało wzięte pod uwagę, wszystko zostało obliczone, ale zapomnieli napisać.
6. Utworzony system nie pasuje do opisu.
Oczywiste jest, że wszystkie artefakty projektowe pojawiają się z reguły w pełnej formie dopiero pod koniec projektu, a nawet wtedy nie zawsze. Ale jeśli założymy, że rozwój jest wodospadem, to ryzyko jest takie, jak opisałem. Sprawdzenie każdego ryzyka to specyficzna operacja, której można nadać nazwę. Jeśli ktoś jest zainteresowany, możesz spróbować wymyślić i wyrazić te warunki.
Co to jest weryfikacja? W języku rosyjskim weryfikacja to sprawdzenie zgodności z przepisami. Regulamin ma formę dokumentu. Oznacza to, że powinien istnieć dokument z wymaganiami dotyczącymi dokumentacji. Jeżeli dokumentacja spełnia wymagania tego dokumentu, to przeszła weryfikację.
Co to jest walidacja? W języku rosyjskim walidacja to weryfikacja poprawności wniosków. Oznacza to, że powinien istnieć zasób wiedzy opisujący, jak uzyskać opis projektu na podstawie danych obiektowych. Sprawdzenie poprawności zastosowania tych wniosków jest walidacją. Walidacja to między innymi sprawdzenie opisu pod kątem spójności, kompletności i zrozumiałości.
Walidacja wymagań jest często mylona z walidacją produktu opartego na tych wymaganiach. Nie warto tego robić.
