Testowanie białe pudło

Test użyteczności

A) Testowanie obciążenia

Test wydajności

Testy funkcjonalności

Testowanie oprogramowanie

Testowanie to proces wykonywania programu (lub jego części) z zamiarem (lub celem) znalezienia błędów.

Istnieje kilka kryteriów, według których zwyczajowo klasyfikuje się rodzaje testów. Zwykle rozróżnia się następujące znaki:

I) Zgodnie z przedmiotem badania:

(określenie lub zbieranie wskaźników wydajności i czasu odpowiedzi systemu lub urządzenia programowo-sprzętowego lub urządzenia w odpowiedzi na żądanie zewnętrzne w celu ustalenia zgodności z wymaganiami dla tego systemu)

b) Testy obciążeniowe

(ocenia niezawodność i stabilność systemu w warunkach przekroczenia granic normalnej eksploatacji.)

c) Badanie stabilności

4) Testowanie interfejsu użytkownika

5) Testy bezpieczeństwa

6) Testowanie lokalizacji

7) Testowanie zgodności

II) Poprzez znajomość systemu:

1) Testowanie czarnej skrzynki

(testowany jest obiekt, którego struktura wewnętrzna jest nieznana)

(sprawdzana jest wewnętrzna struktura programu, dane testowe uzyskuje się poprzez analizę logiki programu)

III) Według stopnia automatyzacji:

1) Testowanie ręczne

2) Zautomatyzowane testowanie

3) Testy półautomatyczne

IV) W ​​zależności od stopnia izolacji komponentów:

1) Testowanie komponentów (jednostek)

2) Testowanie integracji

3) Testowanie systemu

V) Do czasu testowania:

1) Testy alfa- zamknięty proces testowania programu przez pełnoetatowych programistów lub testerów. Produkt alfa jest najczęściej ukończony w 50%, jest kod programu, ale brakuje znacznej części projektu.

2) Testy beta- intensywne użytkowanie gotowa wersja programy w celu określenia maksymalnej liczby błędów w swojej pracy w celu ich późniejszej eliminacji przed ostatecznym wejściem na rynek, do masowego konsumenta. W testowanie zaangażowani są wolontariusze spośród zwykłych przyszłych użytkowników.

Weryfikacja oprogramowania jest pojęciem bardziej ogólnym niż testowanie. Celem weryfikacji jest uzyskanie pewności, że weryfikowany obiekt (wymagania lub kod programu) spełnia wymagania, jest zaimplementowany bez niezamierzonych funkcji oraz spełnia specyfikacje i normy projektowe ( ISO 9000-2000). 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.

Sankt Petersburg

Państwowy Uniwersytet Elektrotechniczny

Departament MOEM

przez dyscyplinę

„Proces rozwoju oprogramowania”

„Weryfikacja oprogramowania”

Petersburg

Cel weryfikacji………………………………………………………………………… str. 3

Uwagi wstępne……………………………………………………………………….. str. 3

Cele specjalne i ogólne………………………………………….. str. 4

Oczekiwana praktyka według celów……………………………………… str. 4

SG1 Przygotowanie do weryfikacji………………………………………………………..... str. 4

SG2 Przeprowadzanie egzaminów (ocena koleżeńska)………………………… str. 7

SG3 Wdrożenie Weryfikacji………………………………………………..... str. 9

Załącznik 1. Przegląd narzędzi automatyzacji procesu weryfikacji……….. str. 11

Załącznik 2. Główny nowoczesne podejścia do weryfikacji…………….. str. 12

Wykaz wykorzystanej literatury……………………………………………….. str. 14

Zintegrowany model doskonałości i dojrzałości

Weryfikacja (poziom dojrzałości 3)

Cel

Celem weryfikacji jest: zapewnienie, że wybrane oprogramowanie pośrednie lub produkt końcowy spełnia określone wymagania.

1. nuty wodne

Weryfikacja oprogramowania jest weryfikacja gotowego produktu lub jego wersji pośrednich aby spełnić pierwotne wymagania. Oznacza to nie tylko testowanie samego programu, ale także audyt projektu, dokumentacji użytkownika i technicznej itp.

Celem weryfikacji systemu oprogramowania jest identyfikacja i raportowanie błędów, które mogą wystąpić na etapach cyklu życia. Główne zadania weryfikacji:

określenie zgodności wymagań wysokiego poziomu z wymaganiami systemowymi;

uwzględnienie wymagań wysokopoziomowych w architekturze systemu;

zgodność z architekturą i wymaganiami dla niej w kodzie źródłowym;

określenie zgodności kodu wykonywalnego z wymaganiami dla systemu;

określenie środków zastosowanych do rozwiązania powyższych zadań, które są poprawne technicznie i wystarczająco kompletne.

Weryfikacja obejmuje weryfikację wyrobów gotowych oraz weryfikację wyrobów pośrednich pod kątem wszystkich wybranych wymagań, w tym wymagań klienta, wymagań dotyczących wyrobów gotowych oraz wymagań dotyczących poszczególnych jego składników.

Weryfikacja jest z natury procesem przyrostowym (przyrostowym) od momentu jej powstania, poprzez rozwój produktów i całą pracę nad produktami. Weryfikacja rozpoczyna się od weryfikacji wymagań, następnie następuje weryfikacja wszystkich produktów pośrednich na różnych etapach ich rozwoju i wytwarzania, a kończy się weryfikacją produktu końcowego.

Weryfikacja półproduktów na każdym etapie ich rozwoju i wytwarzania znacząco zwiększa prawdopodobieństwo, że produkt końcowy spełni wymagania klienta, wymagania dotyczące produktu gotowego oraz wymagania dotyczące jego poszczególnych składników.

Weryfikacja i walidacja procesów to zasadniczo procesy powiązane, mające jednak na celu uzyskanie różnych wyników. Celem walidacji jest wykazanie, że gotowy produkt faktycznie spełnia swoje pierwotne przeznaczenie. Weryfikacja ma na celu upewnienie się, że produkt dokładnie spełnia określone wymagania. Innymi słowy, Weryfikacja zapewnia, że ​​„ robisz to dobrze”, a walidacja polega na tym, że „ robisz właściwą rzecz”.

Weryfikacja powinna zostać wdrożona tak wcześnie, jak to możliwe w odpowiednich procesach (takich jak dostawa, rozwój, eksploatacja lub konserwacja) w celu oceny opłacalności i wydajności. Proces ten może obejmować analizę, weryfikację i testowanie (testowanie).

Proces ten można przeprowadzić z różnym stopniem niezależności wykonawców. Stopień niezależności wykonawców może być rozłożony zarówno na różne podmioty w samej organizacji, jak i podmioty w innej organizacji, o różnym stopniu podziału odpowiedzialności. Ten proces nazywa się procesem niezależna weryfikacja jeśli organizacja wdrażająca jest niezależna od dostawcy, dewelopera, operatora lub opiekunów.

Oceny eksperckie (ekspertyza) są ważnym elementem weryfikacji jako ugruntowanym narzędziem skutecznego usuwania wad. Ważnym wnioskiem z tego jest potrzeba głębszego zrozumienia i zrozumienia działających wersji produktu, a także przepływów pracy wykorzystywanych do identyfikacji możliwych wad i stworzenia możliwości ulepszeń, jeśli to konieczne.

Egzaminy obejmują metodyczne badanie pracy wykonanej przez ekspertów w celu zidentyfikowania wad i innych wymaganych zmian.

Główne metody oceny eksperckiej to:

kontrola

kompleksowa kontrola strukturalna

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żemy stwierdzić, że jeśli przedmiot jako całość jest poprawnie opisany, jeśli zasób wiedzy jest poprawny i jeśli przestrzegane są reguły wnioskowania, to otrzymany 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ć.

zespół składa się z więcej niż dwóch osób nieuchronnie pojawia się pytanie o podział ról, praw i obowiązków w zespole. Konkretny zestaw ról jest determinowany przez wiele czynników – liczbę uczestników rozwoju i ich osobiste preferencje, przyjętą metodologię rozwoju, cechy projektu i inne czynniki. W prawie każdym zespole programistycznym można wyróżnić następujące role. Niektóre z nich mogą być całkowicie nieobecne, podczas gdy pojedyncze osoby mogą pełnić kilka ról naraz, ale ogólny skład niewiele się zmienia.

Klient (wnioskodawca). Rola ta należy do przedstawiciela organizacji, która zamówiła tworzony system. Zazwyczaj wnioskodawca jest ograniczony w interakcji i komunikuje się tylko z kierownikami projektów oraz specjalistą ds. certyfikacji lub wdrożeń. Zwykle klient ma prawo do zmiany wymagań dla produktu (tylko we współpracy z kierownikami), zapoznania się z dokumentacją projektową i certyfikacyjną mającą wpływ na cechy nietechniczne opracowywanego systemu.

Menadżer projektu. Ta rola zapewnia kanał komunikacji między klientem a zespołem projektowym. Product manager zarządza oczekiwaniami klienta oraz opracowuje i utrzymuje kontekst biznesowy dla projektu. Jego praca nie jest bezpośrednio związana ze sprzedażą, skupia się na produkcie, jego zadaniem jest zdefiniowanie i dostarczenie wymagania klienta. Kierownik projektu ma prawo do zmiany wymagań dotyczących produktu i dokumentacji końcowej produktu.

Kierownik programu. Ta rola zarządza komunikacją i relacjami w zespole projektowym, pełni rolę koordynatora, opracowuje i zarządza specyfikacjami funkcjonalnymi, utrzymuje harmonogram projektu i raporty o statusie projektu oraz inicjuje krytyczne decyzje dla projektu.

Testowanie- proces wykonywania programu w celu wykrycia błędu.

dane testowe- wejścia używane do testowania systemu.

Sytuacja testowa (przypadek testowy)- wejścia do testowania systemu i oczekiwane wyjścia w zależności od wejść, jeśli system działa zgodnie ze specyfikacją wymagań.

Dobry przypadek testowy- sytuacja, w której istnieje duże prawdopodobieństwo wykrycia niewykrytego jeszcze błędu.

szczęśliwy test- test wykrywający niewykryty jeszcze błąd.

Błąd- działanie programisty na etapie rozwoju, prowadzące do tego, że oprogramowanie zawiera wewnętrzną wadę, która podczas działania programu może prowadzić do błędnego wyniku.

Odmowa- nieprzewidywalne zachowanie systemu, prowadzące do nieoczekiwanego wyniku, który może być spowodowany wadami w nim zawartymi.

Dlatego w procesie testowania oprogramowania z reguły sprawdzane są następujące elementy.

Weryfikacja i walidacja ( weryfikacja i walidacja-V& v) mają na celu analizę, weryfikację poprawności wykonania i zgodności oprogramowania ze specyfikacją i wymaganiami klienta. Te metody sprawdzania poprawności programów i systemów oznaczają odpowiednio:

• weryfikacja to weryfikacja poprawności utworzenia systemu zgodnie z jego specyfikacją;
• Walidacja to weryfikacja poprawności spełnienia określonych wymagań dla systemu.

Weryfikacja pomaga w wyciągnięciu wniosków o poprawności stworzonego systemu po zakończeniu jego projektowania i rozwoju. Walidacja pozwala na ustalenie wykonalności określonych wymagań i obejmuje szereg działań w celu uzyskania właściwych programów i systemów, a mianowicie:

• planowanie procedur inspekcji i kontroli, rozwiązania projektowe i wymagania;
• zapewnienie poziomu automatyzacji projektowania programów za pomocą środków CASE;
• sprawdzenie poprawności działania programów poprzez testowanie metod na zestawach testów docelowych;
• dostosowanie produktu do środowiska pracy itp.

Walidacja wykonuje te czynności poprzez przegląd i kontrolę specyfikacji i danych wyjściowych projektu na etapach cyklu życia w celu potwierdzenia, że ​​istnieje prawidłowa implementacja wymagań początkowych oraz że spełnione są określone warunki i ograniczenia. Zadania weryfikacji i walidacji obejmują sprawdzenie kompletności, spójności i jednoznaczności specyfikacji wymagań oraz poprawności realizacji funkcji systemu.

Weryfikacja i walidacja podlegają:

• główne elementy systemu;
• interfejsy komponentów (programowe, techniczne i informacyjne) oraz interakcje obiektów (protokoły i komunikaty) zapewniające wdrożenie systemu w środowiskach rozproszonych;
• środki dostępu do bazy danych i plików (transakcje i wiadomości) oraz weryfikacja środków ochrony przed nieuprawnionym dostępem do danych różnych użytkowników;
• dokumentacja oprogramowania i systemu jako całości;
• testy, procedury testowe i dane wejściowe.

Innymi słowy, główne systematyczne metody poprawności programu to:

• weryfikacja Weryfikacja komponentów PS i specyfikacji wymagań;
• Kontrola PS ustalenie zgodności programu z podanymi specyfikacjami;
• testowanie kod wyjściowy PS na danych testowych w określonym środowisku operacyjnym w celu identyfikacji błędów i usterek spowodowanych różnymi wadami, anomaliami, awariami sprzętu lub awariami systemu (patrz rozdział 9).

ISO/IEC 3918-99 i 12207 obejmują procesy weryfikacji i walidacji. Dla nich definiowane są cele, zadania i działania służące weryfikacji poprawności tworzonego produktu (w tym roboczego, półproduktów) na etapach cyklu życia i zgodności z jego wymaganiami.

Głównym zadaniem procesów weryfikacji i walidacji jest: sprawdź i potwierdź czy finalne oprogramowanie jest dostosowane do celu i spełnia wymagania klienta. Procesy te pozwalają na identyfikację błędów w produktach pracy etapów cyklu życia, bez znajdowania przyczyn ich wystąpienia, a także na ustalenie poprawności oprogramowania w stosunku do jego specyfikacji.

Procesy te są ze sobą powiązane i określa je jeden termin – „weryfikacja i walidacja” (V&V 7).

Weryfikacja odbywa się:

• weryfikacja poprawności tłumaczenia poszczególnych komponentów na kod wyjściowy, a także opisów interfejsów poprzez śledzenie relacji komponentów zgodnie z określonymi wymaganiami klienta;
• analizę poprawności dostępu do plików lub bazy danych z uwzględnieniem procedur przyjętych w narzędziach systemowych służących do manipulacji danymi i przekazywania wyników;
• weryfikacja środków ochrony komponentów pod kątem zgodności z wymaganiami klienta oraz ich śledzenie.

Po sprawdzeniu poszczególnych elementów systemu następuje ich integracja oraz weryfikacja i walidacja zintegrowanego systemu. System jest testowany na wielu zestawach testów w celu określenia, czy zestawy testów są odpowiednie i wystarczające do ukończenia testu i ustalenia poprawności systemu.

Pomysł stworzenia międzynarodowego projektu weryfikacji formalnej został zaproponowany przez T. Hoare, był omawiany na sympozjum dotyczącym zweryfikowanego oprogramowania w lutym 2005 roku w Kalifornii. Następnie w październiku tego samego roku na konferencji IFIP w Zurychu przyjęto na okres 15 lat międzynarodowy projekt opracowania „holistycznego zautomatyzowanego zestawu narzędzi do sprawdzania poprawności PS”.

Sformułował następujące główne zadania:

• opracowanie jednolitej teorii budowy i analizy programów;
• budowanie kompleksowego zintegrowanego zestawu narzędzi weryfikacyjnych dla wszystkich etapów produkcji, w tym opracowywanie specyfikacji i ich weryfikacja, generowanie przypadków testowych, udoskonalanie, analiza i weryfikacja programów;
• stworzenie repozytorium specyfikacji formalnych i zweryfikowanych obiektów oprogramowania, różne rodzaje i typy.

Projekt ten zakłada, że ​​weryfikacja obejmie wszystkie aspekty tworzenia i sprawdzania poprawności oprogramowania i stanie się panaceum na wszelkie kłopoty związane z ciągłym występowaniem błędów w tworzonych programach.

W praktyce przetestowano wiele formalnych metod dowodzenia i weryfikacji określonych programów. Gotowe wielka robota międzynarodowy komitet ISO/IEC w ramach Norma ISO/ IEC 12207:2002 w sprawie standaryzacji procesów weryfikacji i walidacji oprogramowania. Obiecujące jest sprawdzenie poprawności metodami formalnymi różnych obiektów programowania.

Repozytorium jest repozytorium programów, specyfikacji i narzędzi używanych w rozwoju i testowaniu, ocenie gotowych komponentów, narzędzi i półfabrykatów metod. Ma następujące ogólne zadania:

• gromadzenie zweryfikowanych specyfikacji, metod sprawdzania, obiektów programu i implementacji kodu dla złożonych aplikacji;
• kumulacja różnych metod weryfikacji, ich projektowanie w formie odpowiedniej do wyszukiwania i wyboru zrealizowanej idei teoretycznej do dalszego zastosowania;
• opracowanie standardowych formularzy do ustalania i wymiany specyfikacji formalnych różnych obiektów programistycznych, a także narzędzi i gotowych systemów;
• opracowanie mechanizmów interoperacyjności i interakcji w celu przenoszenia gotowych zweryfikowanych produktów z repozytorium do nowych środowisk rozproszonych i sieciowych w celu tworzenia nowych PS.

Ten projekt ma powstać w ciągu 50 lat. Wcześniejsze projekty stawiały sobie podobne cele: poprawa jakości oprogramowania, sformalizowanie modeli usług, zmniejszenie złożoności poprzez wykorzystanie PIC, stworzenie narzędzi debugowania do wizualnego diagnozowania błędów i ich eliminacji itp. Jednak fundamentalna zmiana w programowaniu nie nastąpiła również w sensie wizualne debugowanie lub osiągnięcie Wysoka jakość NA. Proces rozwoju trwa.

Nowy międzynarodowy projekt weryfikacji oprogramowania wymaga od jego uczestników nie tylko wiedzy aspekty teoretyczne specyfikacje programu, ale także wysoko wykwalifikowani programiści do jego wdrożenia w nadchodzących latach.