model testowy to logiczna struktura opisująca funkcjonalność systemu i/lub zachowanie użytkownika, według której generowane są przypadki testowe. Budowanie modelu testowego rozpoczyna się od zbudowania konstrukcji, a następnie zatwierdzona konstrukcja jest wypełniana przypadkami testowymi.

Modele są zwykle budowane w oparciu o wymagania i/lub oczekiwane zachowanie systemu. Budowanie modelu testowego i zarządzanie nim jest odpowiednie dla dużych systemów o złożonej logice biznesowej i jest trudne do zastosowania w projektach wykorzystujących metodyki zwinne, ponieważ koszt utrzymania procesu zarządzania modelem testowym i zapewnienia jakości będzie zbyt wysoki.

Zarządzanie modelem testowym to proces, który kontroluje pokrycie modelu testowego, jakość scenariuszy opisujących model testowy oraz jego aktualizację.

Zarządzanie modelem testowym jest procesem ciągłym przez cały czas koło życia produkt.

Pokrycie modelu testowego

Aby kontrolować pokrycie wszystkich wymagań, można użyć macierzy śledzenia, które określają pokrycie wymagań według scenariuszy testowych (patrz przykład).
Zanim zostaną opisane przypadki testowe, struktura modelu testowego musi zostać zatwierdzona z klientem.

Jakość skryptu

Do zarządzania jakością scenariuszy niezbędna jest kontrola nie tylko poziomu opisu przypadków testowych, ale także ich jakości.

Przed przystąpieniem do opisu przypadków testowych należy zdefiniować wymagania dla każdego poziomu opisu oraz kryteria jakości opisu przypadków testowych.

Możliwe poziomy opisu przypadków testowych:

Na 4 poziomie umowę z klientem można zastąpić umową.

Kryteria jakości opisu przypadków testowych mogą być następujące:

• Przypadki testowe muszą być napisane zgodnie z wymaganiami

Testowanie to proces sprawdzania, czy produkt spełnia jego wymagania. Dlatego w części ogólnego opisu przypadku testowego (w systemach śledzenia testów zwykle używa się terminu „Podsumowanie”) konieczne jest odniesienie się do konkretnego wymagania w połączeniu z fragmentami tekstu wymagań. W ten sposób dla wszystkich uczestników projektu będzie jasne, na podstawie tego, co został napisany ten przypadek testowy.

• Użyj szczegółowych warunków wstępnych

Jak zaoszczędzić czas na testach?

Ustaw reguły formatowania dla wszystkich przypadków testowych. Tak więc przypadek testowy będzie łatwy do zrozumienia i odczytania dla każdego uczestnika projektu. Na przykład w projekcie możesz wprowadzić następujące reguły:

• Wszystkie parametry wejściowe powinny być zaznaczone na czerwono.
• Wszystkie skrypty muszą być podświetlone na niebiesko,
• Wszystkie nazwy przycisków, pól, bloków są pisane kursywą i pogrubieniem.
• Podkreślono ważne fragmenty.
• Każdy wykonany krok musi mieć oczekiwany rezultat.
• Każdy krok w przypadkach testowych powinien opisywać tylko jedną akcję i jej oczekiwany wynik. Tych. po otrzymaniu nieudanego przypadku testowego w konkretnym kroku powinno być jednoznacznie jasne, w której akcji wystąpił błąd.
• Oczekiwany wynik musi być jednoznaczny.

Przypadki testowe muszą być jednoznaczne, tj. powinny być zredagowane i sformułowane w taki sposób, aby nie pozwalały na niejednoznaczną interpretację, ale były jasno rozumiane przez wszystkich uczestników.

Jeśli pisanie przypadków testowych zajmuje dużo czasu, może dojść do sytuacji, w której specjalista przestanie widzieć swoje błędy. Aby to zrobić, potrzebujesz spojrzenia z boku - tutaj pomoże recenzja krzyżowa. Ten etap jest zalecany do przeprowadzenia w przypadkach, gdy opracowanie modelu testowego jest rozciągnięte w czasie i trwa długo. Na przykład, gdy opracowanie scenariuszy testowych trwa dłużej niż 1 miesiąc.

Można przeprowadzić proces kontroli jakości skryptu z kontrolą modelu testowego- specjalnie przygotowany szablon.

Aktualizacja modelu testowego

Konieczna jest regularna aktualizacja modelu testowego i samych przypadków testowych pod kątem zgodności z wymaganiami, a także przegląd priorytetów przypadków testowych.

Do aktualizacji możesz zachować „Macierz wymagań”(Matryca śledzenia wymagań): po każdej zmianie w określonym wymaganiu, wybór wszystkich scenariuszy testowych związanych z tym wymaganiem jest wybierany z systemu śledzenia testów i aktualizowany.

Kontrole modelu testowego:

• szyna testowa
• łącze testowe
• Jira+Zephyr
• Menedżer testów firmy Microsoft (MTM)
• przewyższać

Testowanie to proces, który pozwala ocenić jakość wytwarzanego produktu. Wysokiej jakości oprogramowanie musi spełniać wymagania, zarówno funkcjonalne, jak i niefunkcjonalne. PS musi implementować wszystkie wymagane VIs i nie może mieć defektów - różnic między rzeczywistymi właściwościami lub zachowaniem a wymaganymi. Ponadto PS musi mieć właściwości niezawodności (nie może występować zawieszeń, awarii itp.), bezpieczeństwa, zapewniać pożądaną wydajność, być łatwy w użyciu, rozszerzalny itp. Zatem testowanie jest procesem analizy PS , mające na celu identyfikację wad i ocenę właściwości PS.

Cele procesu testowania

Celem testowania jest ocena jakości Produkt oprogramowania poprzez

• Kontrole interakcji komponentów;
• Sprawdzenie poprawności integracji komponentów;
• Sprawdzenie poprawności realizacji wszystkich wymagań i identyfikacja defektów.

Cechy procesu testowania w RUP

Testowanie jest procesem iteracyjnym przeprowadzanym we wszystkich fazach cyklu życia. Testowanie zaczyna się od początku etap początkowy identyfikacja wymagań dla przyszłego produktu i ścisła integracja z bieżącymi zadaniami. Dla każdej iteracji określany jest cel testowania i metody jego osiągnięcia. Na koniec każdej iteracji ustalane jest, w jakim stopniu cel ten został osiągnięty, czy potrzebne są dodatkowe testy, czy należy zmienić zasady i narzędzia testowe.

Każda wykryta usterka jest odnotowywana w bazie danych projektu wraz z opisem sytuacji, w której została znaleziona. Analityk ustala, czy jest to wada rzeczywista i czy jest to powtórzenie wcześniej wykrytej wady. Znaleziona wada zostaje przypisana priorytet A wskazujące na znaczenie poprawki. Projektant odpowiedzialny za opracowanie podsystemu, komponentu lub klasy lub inna osoba wyznaczona przez kierownika przystępuje do naprawy wady. Kolejność, w jakiej usuwane są defekty, zależy od ich priorytetów. Tester powtarza testy i jest przekonany (lub nie), że wada została naprawiona.

Programista testowy odpowiedzialny za planowanie, opracowywanie i wdrażanie testów. Tworzy plan i model testów, procedury testowe (patrz poniżej) oraz ocenia wyniki testów.

tester (tester) odpowiedzialny za wykonywanie testów systemowych. Do jego obowiązków należy konfigurowanie i wykonywanie testów, ocena wydajności testów, usuwanie błędów oraz rejestrowanie wykrytych defektów.

Artefakty

Podczas testowania tworzone są następujące dokumenty:

Plan testów– dokument definiujący strategię testowania w każdej iteracji. Zawiera opis celów i zadań testowania w bieżącej iteracji, a także strategii, które zostaną zastosowane. Plan wskazuje, jakie zasoby będą wymagane i zawiera listę testów.

Model testowy jest reprezentacją tego, co i jak będzie testowane. Model zawiera zestaw zadań kontrolnych, metod testowych, scenariuszy testowych i oczekiwanych wyników (przypadków testowych), skryptów testowych oraz opisów interakcji testowych.

• Zadanie kontrolne– zestaw danych testowych, warunków wykonania testów i oczekiwanych wyników.
• Metoda badania– dokument zawierający instrukcje dotyczące przygotowania i wykonywania zadań kontrolnych oraz oceny uzyskanych wyników.
• Skrypt testowy- jest to uproszczony opis testu, w tym początkowe dane, warunki i sekwencje działań oraz oczekiwane wyniki.
• Skrypt testowy to program, który jest wykonywany podczas automatycznego testowania za pomocą narzędzi testowych.
• Opis interakcji testowej to diagram sekwencji lub kooperacji, który odzwierciedla uporządkowany w czasie przepływ komunikatów między komponentami testu a obiektem testu.

Wyniki testu oraz dane uzyskane podczas wykonywania testów.

Model obciążenia służy do modelowania funkcji zewnętrznych wykonywanych przez użytkowników końcowych, zakresu tych funkcji oraz obciążenia generowanego przez te funkcje. Model przeznaczony jest do przeprowadzania testów obciążeniowych i/lub obciążeniowych, które symulują pracę systemu w warunkach rzeczywistych.

Wady- są to opisy faktów niezgodności systemu z wymaganiami stwierdzonymi podczas testów. Są to prośby o zmianę.

Prace testowe prowadzone są w każdej iteracji we wszystkich fazach, ale cele i zadania w różnych fazach projektu są znacząco różne.

Faza wejścia w projekt. W tej fazie przeprowadzane jest przygotowanie do testów. Obejmuje:

• Utwórz plan testów zawierający wymagania testowe i strategie testowe. Można utworzyć jeden plan dla wszystkich typów testów (funkcjonalne, obciążeniowe itp.) lub oddzielne plany dla każdego typu.
• Analiza zakresu badań.
• Sformułowanie kryteriów jakości i zakończenie badań.
• Montaż i przygotowanie do eksploatacji narzędzi badawczych.
• Formułowanie wymagań dla projektu rozwojowego PS, zdeterminowanych potrzebami testowania.

Faza rozwoju. W iteracjach tej fazy rozpoczyna się budowa modelu testowego i powiązanych artefaktów. Ponieważ model VI jest już obecny w tej fazie, można rozpocząć projektowanie scenariuszy testowych. Jednocześnie nie zaleca się wykonywania testów, ponieważ zazwyczaj nie ma jeszcze ukończonych fragmentów PS w tej fazie. Prowadzone są następujące czynności:

• Opracowanie scenariuszy testowych.
• Tworzenie skryptów testowych.
• Opracowanie zadań kontrolnych.
• Rozwój metod badawczych.
• Opracowanie modelu obciążenia pracą.

Faza budowy. W tej fazie pojawiają się gotowe fragmenty systemów i prototypy, które należy przetestować. Jednocześnie w niemal każdej iteracji sprawdzane są wszystkie moduły (zarówno wcześniej opracowane i przetestowane, jak i nowe dodane w bieżącej iteracji). Testy zastosowane w poprzednich iteracjach są również wykorzystywane w kolejnych iteracjach do testowania regresji, czyli do sprawdzenia, czy wcześniej zaimplementowana funkcjonalność systemu została zachowana w nowej iteracji. Prowadzone są następujące czynności:

• Utwórz plan testu dla każdej iteracji.
• Udoskonalenie i dodanie modelu testowego.
• Wykonanie testów.
• Opis wykrytych wad.
• Opis wyników badań.
• Ocena wyników badań.

Na podstawie wyników testów wprowadzane są zmiany w kodzie programu w celu wyeliminowania zidentyfikowanych defektów, po czym testowanie jest powtarzane.

Faza rozmieszczenia. W iteracjach tej fazy przeprowadza się testowanie całego PS jako oprogramowania. Prowadzone czynności są podobne do czynności z poprzedniej fazy. Wykrywanie defektów określa potrzebę zmian i ponownego testowania. Proces iteracyjny jest powtarzany aż do spełnienia kryteriów zakończenia testu.

Wyniki testów oceniane są na podstawie metryk testowych, które pozwalają określić jakość testowanego PS oraz samego procesu testowania.

Wsparcie instrumentalne

Ponieważ proces iteracyjnego testowania obejmuje wiele powtórzeń testów, testowanie ręczne staje się nieefektywne i nie pozwala na dokładną ocenę jakości oprogramowania. Dotyczy to zwłaszcza testów obciążeniowych i obciążeniowych, w których konieczne jest symulowanie obciążenia i gromadzenie znacznej ilości danych. Rozwiązaniem jest wykorzystanie narzędzi wspierających automatyzację kompilacji i wykonywania testów.

Podobnie jak proces rozwoju, proces post-testowania oprogramowania również przebiega zgodnie z określoną metodologią. Przez metodologię w tym przypadku rozumiemy różne kombinacje zasad, pomysłów, metod i koncepcji, do których uciekasz się podczas pracy nad projektem.

Obecnie istnieje dość duża liczba różnych podejść do testowania, każde z własnymi punktami początkowymi, czasem wykonania i metodami stosowanymi na każdym etapie. A wybór jednego lub drugiego może być nie lada wyzwaniem. W tym artykule przyjrzymy się różnym podejściom do testowania oprogramowania i omówimy ich główne cechy, które pomogą Ci poruszać się po istniejącej odmianie.

Model wodospadu (liniowy sekwencyjny model cyklu życia oprogramowania)

Model Wodospadu to jeden z najstarszych modeli, który można wykorzystać nie tylko do tworzenia oprogramowania lub testowania, ale także do prawie każdego innego projektu. Jego podstawowa zasada jest sekwencyjną kolejnością wykonywania zadań. Oznacza to, że do kolejnego etapu rozwoju lub testowania możemy przejść dopiero po pomyślnym zakończeniu poprzedniego. Ten model jest odpowiedni dla małych projektów i ma zastosowanie tylko wtedy, gdy wszystkie wymagania są jasno określone. Główne zalety tej metodologii to wydajność ekonomiczna, łatwość obsługi i zarządzania dokumentacją.

Proces testowania oprogramowania rozpoczyna się po zakończeniu procesu rozwoju. Na tym etapie wszystkie niezbędne testy są przenoszone z jednostek do testów systemowych w celu kontroli działania komponentów zarówno pojedynczo, jak i jako całości.

Poza wymienionymi powyżej zaletami, takie podejście do testowania ma również swoje wady. Zawsze istnieje możliwość znalezienia błędów krytycznych w procesie testowania. Może to prowadzić do konieczności całkowitej zmiany jednego z elementów systemu lub nawet całej logiki projektu. Takie zadanie jest jednak niemożliwe w przypadku modelu kaskadowego, gdyż powrót do poprzedniego kroku w tej metodologii jest zabroniony.

Dowiedz się więcej o modelu wodospadu z poprzedniego artykułu..

V-Model (Model weryfikacji i walidacji)

Podobnie jak model wodospadu, model V opiera się na bezpośredniej sekwencji kroków. Główna różnica między tymi dwiema metodologiami polega na tym, że testowanie w tym przypadku jest planowane równolegle z odpowiednim etapem rozwoju. Zgodnie z tą metodologią testowania oprogramowania, proces rozpoczyna się w momencie zdefiniowania wymagań i możliwe jest rozpoczęcie testów statycznych, tj. weryfikacja i przegląd, co pozwala uniknąć ewentualnych defektów oprogramowania na późniejszych etapach. Dla każdego poziomu rozwoju oprogramowania tworzony jest odpowiedni plan testów, który definiuje oczekiwane wyniki oraz kryteria wejścia i wyjścia dla tego produktu.

Schemat tego modelu pokazuje zasadę podziału zadań na dwie części. Te związane z projektowaniem i rozwojem umieszczono po lewej stronie. Zadania związane z testowaniem oprogramowania znajdują się po prawej stronie:

Główne etapy tej metodologii mogą się różnić, ale zazwyczaj obejmują:

• Etap definicje wymagań. Do tego etapu należą testy akceptacyjne. Jego głównym zadaniem jest ocena gotowości systemu do ostatecznego użycia.
• Etap, na którym projekt wysokiego poziomu lub projekt wysokiego poziomu (HDL). Faza ta dotyczy testowania systemów i obejmuje ocenę zgodności z wymaganiami dla systemów zintegrowanych.
• Szczegółowa faza projektowania(Detailed Design) jest równoległy z fazą testów integracyjnych, podczas której testowane są interakcje pomiędzy różnymi komponentami systemu
• Później etap kodowania Rozpoczyna się kolejny ważny krok - testowanie jednostkowe. Bardzo ważne jest, aby upewnić się, że zachowanie poszczególnych części i komponentów oprogramowania jest poprawne i spełnia wymagania.

Jedyną wadą rozważanej metodyki testowania jest brak gotowych rozwiązań, które można by zastosować do pozbycia się defektów oprogramowania wykrytych w fazie testowania.

model przyrostowy

Metodologia ta może być opisana jako wielokaskadowy model testowania oprogramowania. Przepływ pracy podzielony jest na kilka cykli, z których każdy jest również podzielony na moduły. Każda iteracja dodaje do oprogramowania pewną funkcjonalność. Przyrost składa się z trzech cykli:

1. projektowanie i rozwój
2. testowanie
3. realizacja.

W tym modelu możliwe jest jednoczesne tworzenie różnych wersji produktu. Na przykład pierwsza wersja może być w fazie testowania, podczas gdy druga wersja jest w fazie rozwoju. Trzecia wersja może jednocześnie przejść przez fazę projektowania. Ten proces może trwać do końca projektu.

Oczywiście ta metodologia wymaga jak najszybszego wykrycia maksymalnej możliwej liczby błędów w testowanym oprogramowaniu. Jak również faza wdrożenia, która wymaga potwierdzenia gotowości produktu do dostarczenia użytkownikowi końcowemu. Wszystkie te czynniki znacznie zwiększają wagę wymagań testowych.

W porównaniu do poprzednich metodologii model przyrostowy ma kilka ważnych zalet. Jest bardziej elastyczny, zmiany wymagań prowadzą do niższych kosztów, a proces testowania oprogramowania jest bardziej wydajny, ponieważ testowanie i debugowanie jest znacznie łatwiejsze dzięki zastosowaniu małych iteracji. Warto jednak zauważyć, że całkowity koszt wciąż wyższa niż w przypadku modelu kaskadowego.

model spiralny

Model spiralny to metodologia testowania oprogramowania oparta na podejściu przyrostowym i prototypowaniu. Składa się z czterech etapów:

1. Planowanie
2. Ocena ryzyka
3. Rozwój
4. Gatunek

Natychmiast po zakończeniu pierwszego cyklu rozpoczyna się drugi. Testowanie oprogramowania rozpoczyna się na etapie planowania i trwa do etapu oceny. Główną zaletą modelu spiralnego jest to, że pierwsze wyniki badań pojawiają się natychmiast po wynikach badań w trzecim etapie każdego cyklu, co pomaga zapewnić prawidłową ocenę jakości. Należy jednak pamiętać, że ten model może być dość drogi i nie nadaje się do małych projektów.

Chociaż ten model jest dość stary, nadal jest przydatny zarówno do testowania, jak i programowania. Ponadto, główny cel wiele metodologii testowania oprogramowania, w tym model spiralny, uległo ostatnio zmianie. Wykorzystujemy je nie tylko do wyszukiwania usterek w aplikacjach, ale także do poznawania przyczyn, które je spowodowały. Takie podejście pomaga programistom pracować wydajniej i szybko naprawiać błędy.

Przeczytaj więcej o modelu spiralnym w poprzednim wpisie na blogu..

Zręczny

Metodologia zwinnego tworzenia oprogramowania i testowanie oprogramowania można opisać jako zestaw podejść skoncentrowanych na wykorzystaniu interaktywnego rozwoju, dynamicznego kształtowania wymagań i zapewnienia ich realizacji w wyniku ciągłej interakcji w ramach samoorganizującej się organizacji. Grupa robocza. Większość zwinnych metodologii tworzenia oprogramowania ma na celu zminimalizowanie ryzyka poprzez tworzenie w krótkich iteracjach. Jedną z głównych zasad tej elastycznej strategii jest umiejętność szybkiego reagowania na możliwe zmiany, a nie poleganie na długoterminowym planowaniu.

Dowiedz się więcej o Agile(uwaga - artykuł w języku angielskim).

Programowanie ekstremalne (XP, programowanie ekstremalne)

Programowanie ekstremalne jest jednym z przykładów zwinnego tworzenia oprogramowania. Cechą charakterystyczną tej metodologii jest „programowanie w parach”, czyli sytuacja, w której jeden programista pracuje nad kodem, podczas gdy jego kolega stale przegląda napisany kod. Proces testowania oprogramowania jest dość ważny, ponieważ zaczyna się jeszcze przed napisaniem pierwszej linii kodu. Każdy moduł aplikacji powinien mieć test jednostkowy, aby większość błędów można było naprawić na etapie kodowania. Kolejną cechą wyróżniającą jest to, że test określa kod, a nie odwrotnie. Oznacza to, że określony fragment kodu można uznać za kompletny tylko wtedy, gdy wszystkie testy zakończą się pomyślnie. W przeciwnym razie kod zostanie odrzucony.

Głównymi zaletami tej metodologii są ciągłe testowanie i krótkie wydania, co pomaga zapewnić: wysoka jakość kod.

Scrum

Scrum — część metodyki Agile, iteracyjnej struktury przyrostowej stworzonej do zarządzania procesem tworzenia oprogramowania. Zgodnie z zasadami Scrum, zespół testowy powinien być zaangażowany w następujące kroki:

• Udział w planowaniu Scrum
• Wsparcie dla testów jednostkowych
• Testowanie historyjek użytkownika
• Współpracuj z klientem i właścicielem produktu w celu określenia kryteriów akceptacji
• Zapewnienie zautomatyzowanych testów

Ponadto członkowie QA powinni być obecni na wszystkich codziennych spotkaniach, podobnie jak inni członkowie zespołu, aby omówić, co zostało przetestowane i zrobione wczoraj, co będzie testowane dzisiaj, a także ogólny postęp testów.

Jednocześnie zasady metodyki Agile w Scrum prowadzą do pojawienia się specyficznych cech:

• Oszacowanie nakładu pracy wymaganego dla każdej historyjki użytkownika jest koniecznością
• Tester musi zwracać uwagę na wymagania, ponieważ mogą się one cały czas zmieniać.
• Ryzyko regresji wzrasta wraz z częstymi zmianami kodu.
• Jednoczesne planowanie i wykonywanie testów
• Nieporozumienia między członkami zespołu w przypadku, gdy wymagania klienta nie są do końca jasne

Dowiedz się więcej o metodologii Scrum z poprzedniego artykułu..

Wniosek

Podsumowując, należy zauważyć, że dzisiejsza praktyka stosowania tej lub innej metodologii testowania oprogramowania implikuje podejście wielostronne. Innymi słowy, nie należy oczekiwać, że jakakolwiek metodologia będzie odpowiednia dla wszystkich typów projektów. Wybór jednego z nich zależy od wielu aspektów, takich jak rodzaj projektu, wymagania klienta, terminy i wiele innych. Z perspektywy testowania oprogramowania powszechne jest, że niektóre metodologie rozpoczynają testowanie na wczesnym etapie rozwoju, podczas gdy w przypadku innych zwyczajowo czeka się, aż system zostanie ukończony.

Niezależnie od tego, czy potrzebujesz pomocy przy tworzeniu oprogramowania, czy testowaniu, dedykowany zespół programistów i inżynierów ds. kontroli jakości jest gotowy do pracy.

Testowanie usług internetowych

Bardzo Najlepszym sposobem ocenić, czy dobrze przetestowaliśmy produkt – przeanalizować pominięte wady. Te, z którymi borykają się nasi użytkownicy, realizatorzy, firmy. Wiele można z nich ocenić: czego nie sprawdziliśmy wystarczająco dokładnie, na jakie obszary produktu należy zwrócić większą uwagę, jaki jest procent pominięć w ogóle i jaka jest dynamika jego zmian. Z tą metryką (chyba najczęściej spotykaną w testach) wszystko jest w porządku, ale… Kiedy wypuściliśmy produkt i dowiedzieliśmy się o pominiętych błędach, może być już za późno: zły artykuł o nas pojawił się na Habré, konkurenci są szybko rozprzestrzenia się krytyka, klienci stracili do nas zaufanie, kierownictwo jest niezadowolone.

Aby temu zapobiec, zwykle staramy się ocenić jakość testów z wyprzedzeniem, przed wydaniem: jak dobrze i dokładnie sprawdzamy produkt? Jakim obszarom brakuje uwagi, gdzie są główne zagrożenia, jaki postęp? Aby odpowiedzieć na wszystkie te pytania, oceniamy pokrycie testami.

Dlaczego oceniać?

Wszelkie metryki oceny to strata czasu. W tej chwili możesz testować, uruchamiać błędy, przygotowywać autotesty. Jaką magiczną korzyść uzyskujemy z metryk pokrycia testów, aby skrócić czas testowania?

1. Znajdowanie słabych obszarów. Oczywiście potrzebujemy tego? nie tylko po to, by się smucić, ale żeby wiedzieć, gdzie potrzebne są ulepszenia. Jakich obszarów funkcjonalnych nie obejmują testy? Czego nie sprawdziliśmy? Gdzie jest największe ryzyko pominięcia błędów?
2. Rzadko uzyskujemy 100% pokrycie wyników oceny. Co poprawić? Gdzie iść? Jaki jest teraz procent? Jak możemy ją zwiększyć dowolnym zadaniem? Jak szybko możemy dojść do 100? Wszystkie te pytania zapewniają przejrzystość i jasność naszego procesu., a odpowiedzi na nie podaje oszacowanie zasięgu.
3. Skupienie uwagi. Załóżmy, że nasz produkt ma około 50 różnych obszarów funkcjonalnych. wychodzić nowa wersja, i zaczynamy testować pierwszy z nich i znajdujemy tam literówki, i przyciski, które przesunęły się o kilka pikseli i inne drobiazgi ... A teraz czas na testy się skończył, a ta funkcjonalność została szczegółowo przetestowana.. A pozostałe 50? Ocena pokrycia pozwala nam ustalać priorytety zadań w oparciu o aktualne realia i terminy.

Jak oceniać?

Przed wdrożeniem jakichkolwiek metryk ważne jest, aby zdecydować, w jaki sposób je wykorzystasz. Zacznij od odpowiedzi dokładnie na to pytanie - najprawdopodobniej od razu zrozumiesz, jak najlepiej to obliczyć. W tym artykule podzielę się tylko kilkoma przykładami i moimi doświadczeniami, jak to zrobić. Nie po to, aby ślepo kopiować rozwiązania - ale po to, by Twoja wyobraźnia mogła polegać na tym doświadczeniu, wymyślając rozwiązanie idealne dla Ciebie.

Ocena pokrycia wymagań przez testy

Załóżmy, że masz w swoim zespole analityków, którzy nie spędzają czasu na próżno. czas pracy. Na podstawie wyników ich pracy powstały wymagania w systemie RMS (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (z dodatkowymi wtyczkami) itp. W tym systemie tworzą wymagania, które odpowiadają wymaganiom dotyczącym wymagań (przepraszam za tautologię). Wymagania te są atomowe, identyfikowalne, specyficzne… Ogólnie rzecz biorąc, idealne warunki do testowania. Co możemy zrobić w takim przypadku? Używając podejścia skryptowego, połącz wymagania i testy. Przeprowadzamy testy w tym samym systemie, nawiązujemy połączenie wymagania-test i w każdej chwili możemy zobaczyć raport, które wymagania mają testy, a które nie, kiedy te testy zostały zdane iz jakim wynikiem.
Dostajemy mapę zasięgu, pokrywamy wszystkie nieujawnione wymagania, wszyscy są zadowoleni i zadowoleni, nie brakuje nam błędów...

Dobra, wróćmy na ziemię. Najprawdopodobniej nie masz szczegółowych wymagań, nie są one atomowe, niektóre wymagania są generalnie stracone i nie ma czasu na udokumentowanie każdego testu, a przynajmniej co drugiego. Można rozpaczać i płakać, można też przyznać, że testowanie jest procesem kompensacyjnym, a im gorzej radzimy sobie z analityką i rozwojem projektu, tym bardziej sami powinniśmy starać się rekompensować problemy innych uczestników procesu. Przeanalizujmy problemy osobno.

Problem: Wymagania nie są atomowe.

Analitycy też czasem grzeszą z sałatką w głowie, a zazwyczaj jest to obarczone problemami z całym projektem. Na przykład tworzysz edytor tekstu i możesz mieć dwa wymagania w swoim systemie (m.in.): „formatowanie html musi być obsługiwane” oraz „przy otwieraniu pliku w nieobsługiwanym formacie wyskakujące okienko z pytaniem musi się pojawić. Ile testów jest wymaganych do podstawowej weryfikacji pierwszego wymagania? A na 2? Najprawdopodobniej różnica w odpowiedziach jest około stukrotna!!! Nie możemy powiedzieć, że jeśli jest co najmniej 1 test na pierwszym wymaganiu, to wystarczy - ale około 2, najprawdopodobniej całkowicie.

Zatem posiadanie testu wymagań nie gwarantuje nam niczego! Co oznaczają w tym przypadku nasze statystyki zasięgu? Prawie nic! Będziemy musieli zdecydować!

1. W takim przypadku można usunąć automatyczne obliczanie pokrycia wymagań przez testy - nadal nie przenosi ono obciążenia semantycznego.
2. Dla każdego wymagania, zaczynając od najwyższego priorytetu, przygotowujemy testy. Przygotowując się, analizujemy jakie testy będą wymagane dla tego wymagania, ile wystarczy? Przeprowadzamy pełną analizę testową i nie odsuwamy na bok „jest jeden test, ale w porządku”.
3. W zależności od używanego systemu eksportujemy/wgrywamy testy na żądanie i… testujemy te testy! Czy to wystarczy? Najlepiej byłoby oczywiście, gdyby takie testy były przeprowadzane z analitykiem i deweloperem tej funkcjonalności. Wydrukuj testy, zamknij kolegów w sali konferencyjnej i nie odpuszczaj, dopóki nie powiedzą „tak, te testy wystarczą” (dzieje się tak tylko za pisemną zgodą, gdy te słowa są wypowiadane w celu wypisania się, nawet bez analizy testów). Podczas rozmowy ustnej twoi koledzy wyleją krytykę, opuszczone testy, niezrozumiane wymagania itp. - to nie zawsze jest przyjemne, ale bardzo przydatne przy testowaniu!)
4. Po sfinalizowaniu testów na żądanie i uzgodnieniu ich kompletności, w systemie można oznaczyć to wymaganie statusem „objęte testami”. Ta informacja będzie oznaczać znacznie więcej niż „jest tu co najmniej 1 test”.

Oczywiście taki proces uzgadniania wymaga dużo zasobów i czasu, zwłaszcza na początku, aż do wypracowania praktyki. Dlatego wykonuj na nim tylko wymagania o wysokim priorytecie i nowe ulepszenia. Z czasem zaostrz pozostałe wymagania, a wszyscy będą zadowoleni! Ale… a jeśli w ogóle nie ma wymagań?

Problem: Nie ma żadnych wymagań.

Nie ma ich w projekcie, dyskutuje się o nich ustnie, każdy robi to, co chce/może i jak rozumie. Testujemy to samo. W efekcie otrzymujemy ogromną ilość problemów nie tylko w testowaniu i rozwoju, ale także początkowo niepoprawnej implementacji funkcjonalności – chcieliśmy czegoś zupełnie innego! Tutaj mogę doradzić opcję „zdefiniuj i udokumentuj wymagania samemu”, a nawet stosowałem tę strategię kilka razy w swojej praktyce, ale w 99% przypadków nie ma takich zasobów w zespole testowym - więc chodźmy znacznie mniej zasobożerny sposób:

1. Utwórz listę funkcji. Sami! W formie tabletu google, w formacie PBI w TFS - wybierz dowolny, o ile nie jest to format tekstowy. Nadal musimy zbierać statusy! Na tej liście uwzględniamy wszystkie obszary funkcjonalne produktu i staramy się wybrać jeden ogólny poziom dekompozycji (możesz napisać obiekty oprogramowania, skrypty użytkownika, moduły, strony internetowe, metody API lub formularze ekranowe .. .) - ale nie wszystko na raz ! JEDEN format dekompozycji, dzięki któremu łatwiej i wyraźniej nie przegapisz ważnych rzeczy.
2. Koordynujemy KOMPLETNOŚĆ tej listy z analitykami, programistami, biznesem, w naszym zespole ... Staraj się robić wszystko, aby nie stracić ważnych części produktu! Jak głęboka analiza zależy od Ciebie. W mojej praktyce było tylko kilka produktów, dla których stworzyliśmy ponad 100 stron w tabeli, a były to produkty gigantyczne. Najczęściej 30-50 wierszy jest osiągalnym wynikiem do dalszego starannego przetwarzania. W małym zespole bez oddanych analityków testowych jeszcze elementy fichelisty byłyby zbyt trudne do utrzymania.
3. Następnie przechodzimy przez priorytety i przetwarzamy każdą linię fichelisty, jak w sekcji wymagań opisanej powyżej. Piszemy testy, dyskutujemy, uzgadniamy wystarczalność. Zaznaczamy statusy, dla których funkcji jest wystarczająca liczba testów. Status, postępy i rozbudowę testów uzyskujemy poprzez komunikację z zespołem. Wszyscy są szczęśliwi!

Ale... Co jeśli wymagania są utrzymywane, ale nie w formacie umożliwiającym śledzenie?

Problem: Nie można prześledzić wymagań.

Na projekcie jest ogromna ilość dokumentacji, analitycy piszą z prędkością 400 znaków na minutę, masz specyfikacje, specyfikacje techniczne, instrukcje, referencje (najczęściej dzieje się to na życzenie klienta), a wszystko to działa jak wymagania i wszystko było w projekcie od dłuższego czasu Nie wiesz gdzie szukać jakich informacji?
Powtarzając poprzednią sekcję, pomagając całemu zespołowi posprzątać!

1. Tworzymy listę cech (patrz wyżej), ale bez szczegółowego opisu wymagań.
2. Dla każdej funkcji zbieramy razem linki do specyfikacji technicznych, specyfikacji, instrukcji i innych dokumentów.
3. Kierujemy się priorytetami, przygotowujemy testy i uzgadniamy ich kompletność. Wszystko jest takie samo, tylko dzięki połączeniu wszystkich dokumentów na jednej tabliczce zwiększamy łatwość dostępu do nich, przejrzyste statusy i spójność testów. W końcu wszystko jest super i wszyscy są szczęśliwi!

Ale… Nie na długo… Wygląda na to, że w ostatnim tygodniu analitycy zaktualizowali 4 różne specyfikacje na podstawie życzeń klientów!!!

Problem: Wymagania zmieniają się cały czas.

Oczywiście fajnie byłoby przetestować jakiś stały system, ale nasze produkty są zazwyczaj na żywo. Klient o coś poprosił, coś zmieniło się w prawodawstwie poza naszym produktem, a gdzieś analitycy znaleźli błąd w analizie sprzed roku... Wymagania żyją własnym życiem! Co robić?

1. Załóżmy, że zebrałeś już linki do TK i specyfikacji w formie listy funkcji, PBI, wymagań, notatek Wiki itp. Załóżmy, że masz już testy spełniające te wymagania. A teraz wymagania się zmieniają! Może to oznaczać zmianę w RMS, zadanie w TMS (systemie zarządzania zadaniami) lub list w poczcie. Tak czy inaczej prowadzi to do tego samego wyniku: Twoje testy są nieaktualne! Lub mogą być nieistotne. Oznacza to, że wymagają aktualizacji (pokrycie testami) stara wersja produkt jakoś nie jest uważany za bardzo, prawda?)
2. Na liście funkcji, w RMS, w TMS (Test Management System - testrails, sitechco, itp.) testy muszą być natychmiast i bezbłędnie oznaczone jako nieistotne! W HP QC lub MS TFS można to zrobić automatycznie podczas aktualizacji wymagań, a na tablecie google lub wiki będziesz musiał odłożyć długopisy. Ale powinieneś od razu zobaczyć: testy są nieistotne! Oznacza to, że czekamy na pełną ponowną ścieżkę: aktualizację, ponowne uruchomienie analizy testów, przepisanie testów, uzgodnienie zmian, a dopiero potem ponowne oznaczenie funkcji/wymagania jako „objętej testami”.

W tym przypadku uzyskujemy wszystkie korzyści z oceny pokrycia testowego, a nawet dynamiki! Wszyscy są szczęśliwi!!! Ale…
Ale tak bardzo skoncentrowałeś się na pracy z wymaganiami, że teraz nie masz wystarczająco dużo czasu na testowanie lub dokumentowanie testów. Moim zdaniem (a jest miejsce na religijny spór!) wymagania są ważniejsze niż testy i tak jest lepiej! Przynajmniej są w porządku, cały zespół wie, a programiści robią dokładnie to, co jest potrzebne. ALE NIE MA CZASU NA DOKUMENTOWANIE TESTÓW!

Problem: Za mało czasu na udokumentowanie testów.

W rzeczywistości źródłem tego problemu może być nie tylko brak czasu, ale także dość świadomy wybór, aby ich nie dokumentować (nie lubimy tego, unikamy efektu pestycydów, zbyt często zmieniamy produkt itp.). Ale jak w tym przypadku ocenić pokrycie testami?

1. Nadal potrzebujesz wymagań jako pełnych wymagań lub jako listy funkcji, więc jedna z powyższych sekcji, w zależności od pracy analityków nad projektem, nadal będzie potrzebna. Masz listę wymagań/funkcji?
2. Opisujemy i ustnie uzgadniamy krótką strategię testowania, bez dokumentowania konkretnych testów! Strategia ta może być określona w kolumnie tabeli, na stronie wiki lub w wymaganiu w RMS i ponownie musi zostać uzgodniona. W ramach tej strategii przeglądy będą prowadzone na różne sposoby, ale będziesz wiedział: kiedy jest ostatni raz przetestowane iz jaką strategią? A to też nie jest złe! I wszyscy będą szczęśliwi.

Ale… Co jeszcze „ale”? Który???

Powiedzmy, że obejdziemy wszystko i oby wysokiej jakości produkty były z nami!

| Planowanie lekcji na rok szkolny | Główne etapy modelowania

Lekcja 2
Główne etapy modelowania

Studiując ten temat, dowiesz się:

Czym jest modelowanie;
- co może służyć jako prototyp do modelowania;
- jakie jest miejsce modelowania w działalności człowieka;
- jakie są główne etapy modelowania;
- czym jest model komputerowy;
Co to jest eksperyment komputerowy.

eksperyment komputerowy

Aby ożywić nowe rozwiązania projektowe, wprowadzić do produkcji nowe rozwiązania techniczne lub przetestować nowe pomysły, potrzebny jest eksperyment. Eksperyment to eksperyment przeprowadzany na obiekcie lub modelu. Polega na wykonaniu pewnych czynności i ustaleniu, jak na te czynności zareaguje próbka eksperymentalna.

W szkole przeprowadzasz eksperymenty na lekcjach biologii, chemii, fizyki, geografii.

Eksperymenty są przeprowadzane podczas testowania nowych próbek produktów w przedsiębiorstwach. Zazwyczaj do tego celu wykorzystuje się specjalnie stworzoną instalację, która umożliwia przeprowadzenie eksperymentu w warunkach laboratoryjnych lub sam prawdziwy produkt poddawany jest różnego rodzaju testom (eksperyment pełnoskalowy). Aby zbadać na przykład właściwości użytkowe jednostki lub zespołu, umieszcza się go w termostacie, zamraża w specjalnych komorach, testuje na stojakach wibracyjnych, upuszcza itp. Dobrze, jeśli jest to nowy zegarek lub odkurzacz - strata podczas niszczenia nie jest duża. A jeśli to samolot lub rakieta?

Eksperymenty laboratoryjne i pełnoskalowe wymagają dużych nakładów materiałowych i czasu, ale ich znaczenie jest jednak bardzo duże.

Z rozwojem technologia komputerowa pojawiła się nowa unikalna metoda badawcza - eksperyment komputerowy. W wielu przypadkach komputerowe badania symulacyjne przyszły z pomocą, a czasem nawet zastąpić próbki eksperymentalne i stanowiska badawcze. Etap przeprowadzania eksperymentu komputerowego obejmuje dwa etapy: sporządzenie planu eksperymentu oraz przeprowadzenie badania.

Plan eksperymentu

Plan eksperymentu powinien jasno odzwierciedlać kolejność pracy z modelem. Pierwszym krokiem w takim planie jest zawsze przetestowanie modelu.

Testowanie to proces sprawdzania poprawności zbudowanego modelu.

Test - zbiór danych początkowych pozwalający określić poprawność konstrukcji modelu.

Aby mieć pewność co do poprawności uzyskanych wyników modelowania należy: ♦ sprawdzić opracowany algorytm budowy modelu; ♦ upewnić się, że skonstruowany model poprawnie odzwierciedla właściwości oryginału, które zostały uwzględnione w symulacji.

Do sprawdzenia poprawności algorytmu budowy modelu wykorzystuje się testowy zbiór danych początkowych, dla których wynik końcowy jest z góry znany lub z góry określony w inny sposób.

Na przykład, jeśli używasz formuł obliczeniowych w modelowaniu, musisz wybrać kilka opcji dla danych początkowych i obliczyć je „ręcznie”. To są pozycje testowe. Kiedy model jest budowany, testujesz z tymi samymi danymi wejściowymi i porównujesz wyniki symulacji z wnioskami uzyskanymi w wyniku obliczeń. Jeśli wyniki się zgadzają, to algorytm jest opracowany poprawnie, jeśli nie, należy poszukać i wyeliminować przyczynę ich rozbieżności. Dane testowe mogą w ogóle nie odzwierciedlać rzeczywistej sytuacji i mogą nie zawierać treści semantycznej. Jednak wyniki uzyskane w procesie testowania mogą skłaniać do zastanowienia się nad zmianą pierwotnego modelu informacyjnego lub znakowego, przede wszystkim w tej części, w której ułożona jest treść semantyczna.

Aby mieć pewność, że zbudowany model odzwierciedla właściwości oryginału, które zostały uwzględnione w symulacji, należy wybrać przykład testowy z rzeczywistymi danymi źródłowymi.

Przeprowadzać badanie

Po testach, gdy masz pewność co do poprawności zbudowanego modelu, możesz przejść bezpośrednio do badania.

Plan powinien zawierać eksperyment lub serię eksperymentów, które spełniają cele symulacji. Każdemu eksperymentowi musi towarzyszyć zrozumienie wyników, które służy jako podstawa do analizy wyników modelowania i podejmowania decyzji.

Schemat przygotowania i przeprowadzenia eksperymentu komputerowego pokazano na rysunku 11.7.

Ryż. 11.7. Schemat eksperymentu komputerowego

Analiza wyników symulacji

Ostatecznym celem modelowania jest podjęcie decyzji, która powinna zostać opracowana na podstawie kompleksowej analizy wyników symulacji. Ten etap jest decydujący - albo kontynuujesz naukę, albo kończysz. Rysunek 11.2 pokazuje, że faza analizy wyników nie może istnieć autonomicznie. Uzyskane wnioski często przyczyniają się do dodatkowej serii eksperymentów, a czasem do zmiany problemu.

Wyniki testów i eksperymentów stanowią podstawę do opracowania rozwiązania. Jeśli wyniki nie odpowiadają celom zadania, oznacza to, że popełniono błędy na poprzednich etapach. Może to być albo błędne sformułowanie problemu, albo zbyt uproszczona konstrukcja modelu informacyjnego, albo nieudany wybór metody lub środowiska modelowania, albo naruszenie metod technologicznych przy budowie modelu. Jeśli takie błędy zostaną zidentyfikowane, to model wymaga korekty, czyli powrotu do jednego z poprzednich etapów. Proces powtarza się, aż wyniki eksperymentu spełnią cele symulacji.

Najważniejszą rzeczą do zapamiętania jest to, że wykryty błąd jest również wynikiem. Jak mówi przysłowie, uczysz się na swoich błędach. Pisał o tym także wielki rosyjski poeta A. S. Puszkin:

Och, ile mamy wspaniałych odkryć
Przygotuj ducha oświecenia
I doświadczenie, syn trudnych błędów,
I geniusz, przyjaciel paradoksów,
I przypadek, bóg jest wynalazcą...

Pytania i zadania kontrolne

1. Jakie są dwa główne typy stwierdzenia problemu modelowania.

2. W znanej „Księdze problemów” G. Ostera pojawia się następujący problem:

Zła wiedźma, pracując niestrudzenie, zamienia 30 księżniczek w gąsienice dziennie. Ile dni zajmie jej przekształcenie 810 księżniczek w gąsienice? Ile księżniczek dziennie musiałoby zostać zamienionych w gąsienice, aby wykonać zadanie w 15 dni?
Jakie pytanie można przypisać rodzajowi „co się stanie, jeśli…”, a które – rodzajowi „jak to zrobić, że…”?

3. Wymień najbardziej znane cele modelowania.

4. Sformalizuj żartobliwy problem z „Księgi problemów” G. Ostera:

Z dwóch budek oddalonych od siebie o 27 km wyskoczyły na siebie jednocześnie dwa zadziorne psy. Pierwszy biegnie z prędkością 4 km/h, a drugi – 5 km/h.
Jak długo rozpocznie się walka?

5. Wymień jak najwięcej cech obiektu „para butów”. Skomponuj model informacyjny obiektu do różnych celów:
■ wybór obuwia do wędrówek;
■ wybór odpowiedniego pudełka na buty;
■ zakup kremu do pielęgnacji obuwia.

6. Jakie cechy nastolatka są kluczowe dla rekomendacji wyboru zawodu?

7. Dlaczego komputer jest szeroko stosowany w symulacji?

8. Nazwij znane Ci narzędzia modelowania komputerowego.

9. Czym jest eksperyment komputerowy? Daj przykład.

10. Co to jest testowanie modelu?

11. Jakie błędy napotykamy w procesie modelowania? Co należy zrobić, gdy zostanie znaleziony błąd?

12. Jak wygląda analiza wyników symulacji? Jakie wnioski są zwykle wyciągane?