Definicja testu akceptacyjnego. Opracowanie dokumentacji, produkcja i testowanie prototypów. Zestaw standardów dla systemów zautomatyzowanych

Zazwyczaj testy te są wykonywane przez inny zespół, który ręcznie lub za pomocą innego narzędzia powtarza wiele elementów automatycznych testów akceptacyjnych. Dzieje się tak, ponieważ testy akceptacyjne nie mogą być łatwo uruchamiane w różnych środowiskach lub zespół programistów nie może łatwo zrozumieć, co robią testy, a użyte dane są ukryte w kodzie, co utrudnia ich znalezienie lub zmianę. Ukrywanie intencji testu w kodzie utrudnia zrozumienie, co test próbuje zrobić.

Oznacza to również, że nietechniczni członkowie zespołu nie mogą łatwo przyczynić się do testowania, a osoby techniczne spędzają więcej czasu na zautomatyzowanym kodzie testowym. Kiedy testy wymagają refaktoryzacji, co jest nieuniknione, że oddzielają one intencję od sposobu implementacji, możesz skupić się na refaktoryzacji implementacji testu, a nie na tym, co test ma robić.

Separacja intencji, implementacji i danych

Poniżej schemat ilustrujący ideę rozdzielenia intencji, realizacji i danych. Uwzględniono również środowisko, ponieważ ważne jest, aby zrozumieć, w jakim środowisku będą uruchamiane testy i, jeśli to konieczne, zmienić dane i uruchomić test. Intencję mogą tworzyć nietechniczni członkowie zespołu w języku niezależnym od implementacji. Jest to ważne, ponieważ oznacza, że ​​implementację można refaktoryzować bez konieczności zmiany intencji testu. Odwrotna sytuacja również jest prawdziwa; możliwa jest zmiana intencji testu bez wpływu na implementację, pod warunkiem, że istnieje implementacja, która spełnia wszystkie słowa w akapicie intencji.

Jeśli w najgorszym przypadku zdecydujesz się wyrzucić całą implementację i zacząć od nowa, nadal możesz zachować intencję testu i tym samym nie stracić najważniejszej części testów automatycznych, jaką testują testy. Dane muszą być również rozdzielone na intencje i implementacje, dzięki temu dane mogą być wyspecyfikowane w teście przez abstrakcję, a następnie implementacja jest usuwana. Na przykład test może wskazywać, że „Złoty klient”, ponieważ klient jest zidentyfikowany, nie jest częścią testu, ale jest częścią warstwy danych.

Tworzenie warstwy danych i abstrakcja danych nie są nowymi technikami; są one zwykle używane w kodzie aplikacji i powinny być stosowane w testach automatycznych, ponieważ korzyści nadal mają zastosowanie. W przypadku testowym warstwa danych jest wywoływana w celu pobrania danych ze źródła danych dla odpowiedniego typu klienta.

Przypadek testowy następnie iteruje po wszystkich wpisach na liście i przeprowadza test na każdym wpisie klienta. Testy systemowe odpowiadają jednemu z poziomów testowania oprogramowania w połączeniu z różnymi testami, takimi jak odzyskiwanie, bezpieczeństwo, odporność, wydajność, łączność, głośność, napięcie, dostępność danych, łatwość obsługi, obsługa, Środowisko, przechowywanie, konfiguracja, instalacja i dokumentacja. Każdy ma inny cel i ma wspólny cel, który pokazuje systematyczną wizję projektu. Testy akceptacyjne to kolejny rodzaj poziomu, który uzupełniany jest poziomami testów oprogramowania, testy te są bardzo fundamentalne, ponieważ to one pozwolą nam uzyskać produkt spełniający wymagane normy, a jednocześnie spełniający wymagania użytkowników zgodnie z wymagania, które stawiali od samego początku. Zmusza to system do przetestowania kluczowego procesu testowania, ponieważ pod względem produktu, liczby błędów i wagi tych błędów jest to etap rozwoju, który jest zwykle podatny na większość błędów. Rysunek 1: Weryfikacja systemów iteracyjnych Testy systemu nie są procesami weryfikacji funkcjonalności systemu lub pełny program, ponieważ byłoby to zbędne w procesie testowania funkcjonalnego. Testy systemowe mają określony cel: porównanie systemu lub programu z jego pierwotnymi celami. W tym celu przedstawiono dwie wartości. Testowanie systemu nie ogranicza się do systemów. Jeśli produktem jest program, testowanie systemu jest próbą wykazania, że ​​program całkowicie nie spełnia swoich celów lub wymagań. Testy systemowe z definicji nie są możliwe, chyba że istnieją pisemne wymagania, które są mierzalne dla produktu. Testowanie systemu to faza badań, w której zapewnia, że ​​każdy komponent lub moduł współdziała z innymi komponentami lub modułami zgodnie z zamierzeniami. Testy systemu mają na celu głębokie wdrożenie systemu, sprawdzenie integracji systemu informatycznego na całym świecie, sprawdzenie poprawności działania interfejsów pomiędzy różnymi podsystemami, które go tworzą oraz z innymi systemami informatycznymi, z którymi się komunikuje. Klasycznym problemem testowania systemu jest „wskazywanie palcem”. Dzieje się tak, gdy wykryty zostanie błąd, a twórca każdego elementu systemu obwinia innych. Zamiast popadać w ten absurd, inżynier oprogramowania powinien przewidzieć: możliwe problemy z interfejsem: ścieżka obsługi błędów projektowych, która sprawdza wszystkie informacje pochodzące z innych elementów systemu. Testowanie i testowanie systemu 6  Zastosuj serię testów symulujących złe dane lub inne możliwe błędy w interfejsie oprogramowania.  Zarejestruj wyniki testu jako dowód w przypadku winy.  Uczestniczyć w planowaniu i opracowywaniu testów systemowych, aby upewnić się, że oprogramowanie zostało prawidłowo przetestowane. W rzeczywistości test systemu obejmuje szereg różnych testów, których głównym celem jest głębokie obliczenie systemu podczas obliczeń. Chociaż każdy test ma inny cel, wszystkie działają, aby upewnić się, że wszystkie elementy systemu zostały odpowiednio zintegrowane i spełniają odpowiednie funkcje. 2 Przegląd systemu testu. Gdy ma być przeprowadzone testowanie, konieczne jest utrzymanie systemów, czyli integralne podejście do tworzenia oprogramowania. Zastosowanie tych pojęć w teście oprogramowania daje zestaw zasad, które posłużą jako podstawa testu: musisz upewnić się, że znasz dokładnie cele testowanego oprogramowania, a także wskaźniki powodzenia. Elementy te znajdują się w dokumentach uzyskanych w fazie zbierania wymagań, a także w specyfikacjach oprogramowania. Informacje te będą potrzebne do przygotowania planu testów i będą stanowić podstawę do rozpoczęcia tworzenia przypadków testowych. Należy określić wejścia i wyjścia zatwierdzonego systemu. Ten aspekt jest niezbędny przy przygotowywaniu przypadków testowych, a także przy tworzeniu procedur testowych, zwłaszcza zorientowanych na przypadki testowe, które pokazują spełnienie celów. Rozważ główny system, na którym działa testowane oprogramowanie. Zwykle jest to środowisko organizacyjne składające się ze sprzętu, oprogramowania i ludzi. Wszystkie te elementy mają ogromny wpływ na system, a szczególnie pomagają w przygotowaniu przypadków testowych niepożądanych sytuacji związanych z nieodpowiednimi danymi, brakiem niezbędne elementy oraz występowanie wyjątków. 3 Przegląd testowania systemu Proces testowania systemu składa się z dwóch faz, które mogą być bardzo od siebie oddzielone w czasie: przygotowanie testu i zastosowanie testu. To pierwsze jest ściśle związane z wymaganiami, więc dzieje się to na wczesnym etapie projektu, a drugie wymaga pełnego systemu lub co najmniej jednej integracji, ponieważ częściowy produkt jest podobno nie wydany, aby móc zastosować testy, więc dzieje się to na zaawansowanych etapach projekt. Dokładna sytuacja z tymi częściami zależy od wybranego modelu. koło życia. Do wykonania drugiej i trzeciej czynności wymagany jest dokument wymagań. Pierwsza faza testowania dostarcza informacji zwrotnych do analizy wymagań, identyfikowania luk, niejasności i innych problemów. Zapewnia również cenne porady dotyczące projektowania i wdrażania systemu, jeśli dopiero go rozwijasz. Faza aplikacji testowej wymaga planu testów i wersji wykonywalnej systemu. W takim przypadku zastosowane zostaną przygotowane przypadki testowe, wyniki zostaną przeanalizowane, a wszelkie usterki zidentyfikowane. Ten drugi krok dostarcza informacji zwrotnej na temat wdrożenia i projektu, pokazując możliwe defekty, które należy naprawić. Dostarcza również informacji, które będą przydatne przy wydawaniu systemu, przyjmowaniu go, ocenie jego niezawodności i utrzymaniu. Rysunek 1 przedstawia proces testowania systemu i jego związek z innymi procesami. Drugi punkt jest ważny, ponieważ czasami test systemu jest mylony z testem interfejsu. Pierwsza sprawdza interakcję wszystkich części, a druga analizuje elementy interfejsu i ewentualnie przetwarzanie powiązanych zdarzeń. Jednak narzędzia, które pomagają testować interfejs, mogą być używane do uruchamiania testów systemu. Powstaje kilka pytań: ile przypadków wystarczy? Jak generować jak najmniej? Jakie wartości są odpowiednie? Testowanie i testowanie systemu 9 1 Plan testów Plan testów jest bardzo ważny dokument podczas testowania oprogramowania. Wyjaśnia cele i podejścia do testowania, plan pracy, procedury operacyjne, niezbędne narzędzia i obowiązki. Testowanie i testowanie systemu 10 Dokument wymagań powinien zawierać listę funkcji, które ma wykonać oprogramowanie, opisując je i określając ich priorytety; powinien również zawierać wymagania niefunkcjonalne, które mogą obejmować aspekty organizacyjne, operacyjne i inne. Dobrze przygotowany dokument wymagań powinien umożliwiać sprawdzenie, czy każde wymaganie jest spełnione. W przypadku cech byłby to opis, a w przypadku wymagań niefunkcjonalnych bardzo precyzyjne specyfikacje, takie jak czas odpowiedzi. Na razie skupimy się na wymaganiach funkcjonalnych, resztę zostawiając w dalszej części. Testy systemowe są ważne ze względu na następujące czynniki:  Jest to system, który jest testowany jako całość w ramach cyklu życia rozwoju systemu.  System jest sprawdzany pod kątem zgodności z jego funkcjonalnością i wymagania techniczne .  System jest testowany w środowisku najbardziej zbliżonym do środowiska produkcyjnego.  Testy systemowe umożliwiają testowanie, walidację i walidację zarówno wymagań biznesowych, jak i architektury aplikacji. 6Rodzaj testów systemowych Testy funkcjonalne  Test integracyjny. - W którym sprzęt testowy ma dostęp do kodu źródłowego systemu. Po znalezieniu problemu zespół integracyjny próbuje znaleźć źródło problemu i określić komponenty, które wymagają debugowania. Testy integracyjne dotyczą głównie znajdowania defektów w systemie.  Dowód dostawy. Oto wersja systemu, którą można dostarczyć użytkownikowi. Tutaj zespół testowy zajmuje się weryfikacją, czy system spełnia jego wymagania i gwarantuje niezawodność systemu. Testy dostawy są zwykle testami czarnoskrzynkowymi, w których sprzęt testowy dotyczy po prostu tego, czy system działa prawidłowo. Komponenty, które można zintegrować, mogą być komponentami komercyjnymi, komponentami wielokrotnego użytku dostosowanymi do konkretnego systemu lub nowo opracowanymi komponentami. W przypadku wielu dużych systemów prawdopodobnie będą używać wszystkich trzech typów komponentów. Test integracji weryfikuje, czy te komponenty rzeczywiście współpracują ze sobą, są prawidłowo wywoływane i przesyłają poprawne dane w określonym czasie przez ich interfejsy. Integracja systemu polega na identyfikowaniu grup komponentów, które zapewniają pewne funkcje systemu i integrowaniu ich poprzez dodawanie kodów do współpracy. Czasami najpierw opracowywany jest szkielet całego systemu i dodawane są komponenty. Nazywa się to postintegracją. To jest integracja w górę. W praktyce dla wielu systemów strategia integracji jest połączeniem obu, dodawania dodatkowych elementów infrastruktury oraz elementów funkcjonalnych. Oba podejścia integracyjne wymagają dodatkowego kodu do modelowania innych komponentów i uruchomienia systemu. Główną trudnością napotykaną podczas testów integracyjnych jest lokalizacja błędów. Między komponentami systemu zachodzą złożone interakcje, a po wykryciu nietypowego wyjścia może być trudno określić, gdzie wystąpił błąd. Aby ułatwić izolowanie błędów, należy zawsze stosować podejście przyrostowe do integracji i testowania systemu. Głównym celem tego procesu jest zwiększenie pewności dostawcy, że system spełnia jego wymagania. Jeśli tak, może być dostarczony jako produkt lub dostarczony do klienta. Aby wykazać, że system spełnia swoje wymagania, należy wykazać, że zapewnia określoną funkcjonalność, wydajność i niezawodność oraz że nie zawodzi w normalnym użytkowaniu. Testy dostarczania są zwykle procesem testowania czarnej skrzynki, w którym testy są wyprowadzane ze specyfikacji systemu. System jest postrzegany jako czarna skrzynka, której zachowanie powinno być określone jedynie poprzez zbadanie odpowiednich wejść i wyjść. Inną nazwą jest testowanie funkcjonalne, ponieważ testera interesuje tylko funkcjonalność, a nie implementacja oprogramowania. Na poniższym rysunku zobaczymy ilustrację modelu systemu, który umożliwia w walidacji czarnej skrzynki. Tester przedstawia dane wejściowe komponentowi lub systemowi i uwzględnia dane wejściowe. W niektórych przypadkach system musi być odporny na błędy; to znaczy, awarie przetwarzania nie powinny prowadzić do awarii systemu jako całości. Systemy testowe i testy akceptacyjne 14 Awaria systemu musi zostać naprawiona w określonym czasie lub spowoduje poważne szkody ekonomiczne. Test odzyskiwania to test systemu, który powoduje awarię oprogramowania na kilka sposobów i sprawdza, czy odzyskiwanie przebiega prawidłowo. Jeśli odzyskiwanie odbywa się automatycznie, należy sprawdzić, czy ponowna inicjalizacja, mechanizmy tworzenia kopii zapasowej systemu, odzyskiwanie danych i ponowne uruchamianie są prawidłowe. Jeżeli regeneracja wymaga interwencji człowieka, należy określić średni czas rekonwalescencji w celu ustalenia, czy mieści się on w dopuszczalnych granicach. Celem jest ustalenie punktów końcowych, w których system zaczyna działać poniżej określonych wymagań. Nie należy tego mylić z testem objętości; wysokie napięcie to maksymalna ilość danych lub aktywności na Krótki czas. Analogią byłaby ocena maszynistki. Test objętości zostanie określony, jeśli maszynistka ma do czynienia z projektem dużego raportu; test warunków skrajnych określi, czy maszynistka może pisać z indeksem 50 słów na minutę. Naruszenie obejmuje szeroki zakres działań:  Haker, który próbuje zalogować się na grę. Test bezpieczeństwa weryfikuje, czy mechanizmy bezpieczeństwa wbudowane w system faktycznie chronią go przed niewłaściwymi włamaniami. „Systemy muszą być testowane pod kątem bezpieczeństwa systemu, aby były odporne na ataki od frontu, ale także na tych, którzy tworzą flanki lub tyły”. Podczas testu bezpieczeństwa każdy, kto go zastosuje, wciela się w rolę osoby, która chce się zalogować. To wszystko jest tego warte! Powinieneś spróbować zdobyć jakiekolwiek hasła środki zewnętrzne; potrafi zaatakować system za pomocą specjalnego oprogramowania zaprojektowanego w celu ominięcia dowolnej chronionej architektury; może nasycić system, odmawiając w ten sposób służby innym; może prowadzić do celowych błędów w systemie, aby spróbować uzyskać dostęp podczas odzyskiwania: możesz przeglądać dane bez ochrony, z myślą o wyszukaniu hasła do systemu. Jeśli zapewni się wystarczającą ilość czasu i zasobów, system w końcu: dobry test dla bezpieczeństwa. Rolą projektanta systemu jest to, aby koszt przerwania był większy niż koszt otrzymanych informacji. Jednak analiza czynników ludzkich pozostaje problemem wysoce subiektywnym. Przypadki testowe mają na celu wykazanie, że te cele pamięci nie zostały znalezione. Często liczba możliwych konfiguracji jest zbyt duża, aby przetestować każdą z nich, ale jeśli to możliwe, należy przetestować program z każdym typem urządzenia sprzętowego oraz z minimalną i maksymalną konfiguracją. Jeśli sam program można skonfigurować tak, aby pomijał składniki lub jeśli może działać na wielu komputerach, należy przetestować każdą konfigurację. Testowanie procedur instalacyjnych jest ważną częścią procesu testowania systemu. Dotyczy to szczególnie systemu instalacja automatyczna zawarte w pakiecie oprogramowania. Nieprawidłowo uruchomiony instalator może uniemożliwić użytkownikowi pomyślne korzystanie z systemu. Pierwsze doświadczenie użytkownika to instalacja aplikacji. Jednym ze sposobów osiągnięcia tego jest wykorzystanie dokumentacji do zdefiniowania widoku poprzednich przypadków testowych systemu. Oznacza to, że gdy chcesz opracować przypadek przeciążenia, powinieneś użyć dokumentacji jako przewodnika do napisania rzeczywistego przypadku testowego. Ponadto dokumentacja użytkownika powinna podlegać przeglądowi, weryfikacji dokładności i jasności. Każdy z przykładów przedstawionych w dokumentacji należy przetestować i dodać do listy rzeczy do zrobienia oraz włączyć do programu. Testowanie i testowanie systemu 17 z punktu widzenia operacyjnego, po zaadoptowaniu systemu w rzeczywistym środowisku i w oparciu o zgodność z określonymi wymaganiami niefunkcjonalnymi. Testy odporności mają na celu przeciwdziałanie programom w nietypowych sytuacjach. Zasadniczo osoba wykonująca test odporności będzie pytać. Jak daleko zajdziesz, zanim się nie powiedzie? Test rezystancji prowadzi system w taki sposób, że wymaga nieprawidłowej ilości, częstotliwości lub ilości zasobów. Na przykład:  Opracowano specjalne testy, które generują 10 przerwań na sekundę, gdy średnia filiżanka wynosi jeden lub dwa.  Częstotliwość wprowadzania danych jest zwiększona o wartość, która pozwoli na odpowiedzi na funkcje wejściowe.  Uruchom przypadki testowe, które wymagają maksymalnej ilości pamięci lub innych zasobów.  Przypadki testowe mają na celu rozwiązywanie problemów z zarządzaniem pamięcią. Tworzone są przypadki testowe, które powodują nadmierne wyszukiwanie dysków. Rysunek jest przykładem testu odporności. Test wydajności jest stosowany na wszystkich etapach procesu testowania. Nawet na poziomie jednostki. Podczas testowania należy ocenić wydajność pojedynczego modułu. Jednak dopiero po pełnej integracji wszystkich elementów systemu można osiągnąć prawdziwą wydajność systemu. Testy wydajności często obejmują testowanie odporności i często wymagają instrukcji oprogramowania i sprzętu. Oznacza to, że często konieczne jest dokładne zmierzenie wykorzystania zasobów. Korzystając z narzędzi zewnętrznych, można regularnie monitorować interwały uruchomień, rejestrowane zdarzenia i stan próbek sprzętu. Testy te są wykonywane po to, aby klient potwierdził, że system jest dla niego ważny. Szczegółowe planowanie tych testów powinno być przeprowadzone na wczesnym etapie rozwoju w celu wykorzystania wyników jako wskaźnika ich ważności: jeśli udokumentowane testy są przeprowadzane w sposób zadowalający klienta, produkt jest uważany za poprawny, a zatem odpowiedni do wprowadzenia do produkcja. 6 Testy akceptacyjne2 są zasadniczo testami funkcjonalnymi całego systemu i mają na celu sprawdzenie, czy: ustalone wymagania . Jego wykonanie jest opcjonalne dla klienta, aw przypadku, gdy nie są one wyraźnie określone, są uwzględniane w testach systemowych. Oznacza to, że testy akceptacyjne często są obowiązkiem użytkownika lub klienta, chociaż każdy zaangażowany w biznes może je wykonać. Testy akceptacyjne wymagają środowiska testowego, które reprezentuje środowisko produkcyjne. Ta faza lub poziom jako punkt wyjścia określa linię bazową akceptacji produktu już ustaloną w środowisku certyfikacji. Testowanie i akceptacja systemu 19 Rysunek – Kontrola akceptacji. 1 Badanie aktualnej sytuacji w testach akceptacyjnych. W ramach testów musimy sprawdzić oprogramowanie, jednym z najważniejszych są testy akceptacyjne. Są to testy, które są opracowywane przez sam zespół programistów w oparciu o wymagania funkcjonalne określone w fazie analizy, aby objąć całe spektrum i być wykonywane przez użytkownika końcowego, ale nie wszyscy, ale nieliczni użytkownicy mają znaczący wynik, który daje ważność i zgodność z dostarczonym im produktem na podstawie pierwotnej umowy. W zależności od złożoności testowanego systemu, niezależnie od tego, czy jest podzielony na moduły itp. wykonanie tych testów odbywa się na różne sposoby. Gdyby aplikacja została podzielona na moduły, byłyby one traktowane jako podsystemy i byłyby na tyle złożone, że można by je obsługiwać inaczej, musiałyby zostać przeprowadzone różne sesje testów akceptacyjnych. 2 Cel testów akceptacyjnych Testy akceptacyjne mają na celu uzyskanie ostatecznej akceptacji klienta przed dostarczeniem produktu do produkcji. Kiedy organizacja przeprowadziła testy systemu i naprawiła większość swoich defektów, system zostanie dostarczony użytkownikowi lub klientowi do zatwierdzenia. Celem testów akceptacyjnych jest sprawdzenie, czy system spełnia oczekiwaną wydajność i umożliwienie użytkownikowi tego systemu określenie jego akceptacji pod względem funkcjonalności i wydajności. Testy akceptacyjne są określane przez użytkownika systemu i przygotowywane przez zespół programistów, chociaż ostateczna realizacja i zatwierdzenie należy do użytkownika. Walidację systemu uzyskuje się poprzez uruchomienie testów czarnoskrzynkowych, które wykazują zgodność i są zawarte w planie testów, który definiuje walidacje, które mają zostać wykonane, oraz powiązane z nimi przypadki testowe. Plan ten ma na celu zapewnienie spełnienia wszystkich wymagań funkcjonalnych określonych przez użytkownika, a także wymagań niefunkcjonalnych dotyczących wydajności, bezpieczeństwa dostępu do systemu, danych i procesów oraz różnych zasobów systemowych, 3 Generacja testów akceptacyjnych. System musi zostać zaakceptowany przez użytkownika. Z tego powodu, na podstawie ustrukturyzowanych specyfikacji systemu, analityk tworzy zestaw przypadków testowych, które muszą przejść satysfakcjonująco. Ponieważ testy akceptacyjne mogą być opracowywane równolegle z czynnościami projektowymi i praktycznymi, normalne jest, że te czynności są inicjowane przez analityka zaraz po zakończeniu czynności z zakresu analizy strukturalnej. 4 Strategie testów akceptacyjnych Gdyby system był przeznaczony na rynek masowy, wówczas nie byłoby praktyczne testowanie go dla indywidualnych użytkowników lub klientów, w niektórych przypadkach nie byłoby to możliwe. W takich przypadkach informacja zwrotna jest wymagana przed wystawieniem produktu na sprzedaż. Często takie systemy mają dwa etapy testów akceptacyjnych. Testy alfa i beta Gdy tworzone jest oprogramowanie dla klienta, przeprowadzana jest seria testów akceptacyjnych, aby umożliwić klientowi przetestowanie wszystkich wymagań. Wykonywane przez klienta w miejscu rozwoju. Oprogramowanie jest używane w naturalny sposób przez programistę jako obserwatora użytkownika, wraz z błędami rejestracji i problemami z użytkowaniem. Testy alfa przeprowadzane są w kontrolowanym środowisku. Pracujesz w kontrolowanym środowisku, a klient zawsze ma eksperta, który pomoże Ci w obsłudze systemu. Deweloper śledzi znalezione błędy i problemy z użytkowaniem. Testy Β-beta są przeprowadzane po teście α-alfa i są rozwijane w środowisku klienta. W takim przypadku klient zostaje sam z produktem i próbuje znaleźć błędy, które informują dewelopera. Wykonują je użytkownicy końcowi oprogramowania na stacjach roboczych klienta. W przeciwieństwie do testu alfa, programista zwykle nie jest obecny. Tak więc test beta to aplikacja oprogramowania na żywo w środowisku, które nie może być kontrolowane przez programistę. Klient rejestruje wszystkie problemy, które pojawiają się podczas testów beta i w regularnych odstępach czasu informuje programistów. 5 Wejścia, wyjścia, zadania i role testu akceptacyjnego. Specyfikacja wymagań wstępnych. Zadania Przygotuj środowisko testowe. Zalecamy posiadanie określonego środowiska testowego do tego typu testów. Instalacja w środowisku testowym. Testowanie i testowanie systemu 22 Określ testy, które należy wykonać. Ewentualne zależności istniejące między testami zostaną ustanowione, a kolejność lub kolejność wykonywania testów zostanie ustalona na podstawie tych zależności. Odbieranie i rejestrowanie wyników. Naprawiono błędy i błędy. Powtarzaj zadanie, aż zaliczysz wszystkie testy. Przygotowanie raportu z testu akceptacyjnego. Przegląd poprawności wykonania i wyników wszystkich przesłanych testów. Stworzenie bazy produkcyjnej. Formalne zamknięcie działalności. Wyniki testów. Zaakceptowany raport akceptacji produktu. Menadżer projektu. Skupienie się na testach akceptacyjnych wiąże się z próbą wzmocnienia opinii, że użytkownik zintegrowany na tym etapie, na wczesnym etapie, pomógłby ulepszyć ten proces w fazie planowania i projektowania testów, z późniejszą poprawą w wielu ilościowych i pożądanych aspektach , takich jak: Poprawa jakości bezpieczeństwa zintegrowanego oprogramowania. Minimalizacja kosztów. Zwiększona wiarygodność wyników projektu. Przy korzystaniu z oprogramowania z mniejszą liczbą błędów następuje wzrost zadowolenia klienta. Poprawia to efektywność procesu rozwoju. 7 Kryteria testów akceptacyjnych. Akceptację oprogramowania uzyskuje się poprzez serię testów, które wykazują, że spełnia ono wymagania. Plan testów opisuje rodzaj testu, który ma być zastosowany, a procedura testowa definiuje konkretne przypadki testowe, zarówno plan, jak i procedura są zaprojektowane tak, aby zapewnić, że spełniają wszystkie wymagania funkcjonalne, że wszystkie cechy behawioralne są osiągnięte, wszystkie wymagania dotyczące wydajności są spełnione, dokumentacja jest poprawny i spełnia wszystkie wymagania dotyczące łatwości użytkowania i innych określone wymagania. 8 Narzędzia do testów akceptacyjnych. Dzięki temu klienci, testerzy i programiści wiedzą, co ma robić ich oprogramowanie i automatycznie porównują to, co faktycznie robi. Umożliwia pisanie testów, które są łatwe do odczytania i łatwe w utrzymaniu. Czynność ta nazywana jest testem końcowym lub testem akceptacyjnym. Wymaga to wprowadzenia danych z testów akceptacyjnych oraz zintegrowanego systemu stworzonego podczas tej czynności. Test zostanie przeprowadzony przez członka lub dział użytkownika, a nawet niezależny dział kontroli jakości. Należy zauważyć, że ważne jest przeprowadzanie działań kontroli jakości w każdym z poprzednich działań analitycznych, projektowych i wdrożeniowych, aby zapewnić, że zostały one przeprowadzone na odpowiednim poziomie jakości. Zapewnia to, że analityk tworzy specyfikacje jakościowe, projektant tworzy projekty wysokiej jakości, a programista tworzy programy do kodowania wysokiej jakości. W informatyce implementacja to specyfikacja techniczna lub algorytmy, takie jak program, komponent oprogramowania lub inny system komputerowy. Wiele implementacji jest dostarczanych zgodnie ze specyfikacją lub standardem. Podsumowujemy dotychczasową pracę autorów, aby uzyskać cele testów, które są punktem wyjścia do opracowania testów automatycznych. W kontekście testowania systemowego na podstawie przypadków użycia, cel testowania można wyrazić jako przypadek użycia. Ten scenariusz będzie składał się z sekwencji kroków bez możliwej alternatywy oraz zestawu wartości testowych, oraz warunki wstępne oraz pokonferencje związane z tym scenariuszem. Aby wygenerować scenariusze testowe, najpierw budowany jest diagram aktywności z sekwencji głównej oraz sekwencji błędów i alternatywnych w przypadku użycia. Na diagramie czynności czynności wykonywane przez system oraz czynności wykonywane przez uczestników są stereotypowe. Następnie przeprowadzana jest analiza ścieżki, a każda ścieżka diagramu aktywności będzie scenariuszem przypadku użycia, a zatem potencjalnym celem testu. 2 Wykonanie testów systemowych. Architektura testowania systemu. Architekturę wykonywania i automatycznej weryfikacji testów systemowych pokazano na rysunku 7. Architektura ta jest podobna do architektury potrzebnej do automatyzacji innych rodzajów testów, takich jak testy jednostkowe. Główna różnica polega na tym, że w teście jednostkowym sam test wywołuje kod wykonywalny, podczas gdy test funkcjonalny systemu testowego i akceptacja testów 27 wymagają pośrednika, który wie, jak manipulować jego zewnętrznym interfejsem. Implementacja przypadków testowych. Test-test to realizacja celu testowania. Ogólne zachowanie przypadku testowego jest wymienione w tabeli Ogólne zachowanie przypadku testowego. Każdy przypadek użycia będzie powiązany z zestawem testów. Ten pakiet będzie zawierał testy dla wszystkich scenariuszy wspomnianego przypadku użycia. Jak widać z celów testu, każdy krok musi być określony, czy jest wykonywany przez aktora, czy przez testowany system. Ta informacja jest bardzo istotna przy kodowaniu metod testowania pakietów. Wszystkie akcje wykonywane przez aktora przekształcają kod kodu testowego w interakcję między przypadkiem testowym a systemem. Testowanie systemu i testy akceptacyjne 29 Metodologia zmiennych operacyjnych i kategorii zostanie zastosowana do określenia wymaganych wartości testowych. Trzy zostały zidentyfikowane różne rodzaje zmienne operacyjne. Każdy typ zostanie zaimplementowany inaczej w przypadkach testowych. Pierwszy typ to te zmienne operacyjne, które wskazują na przekazanie informacji do systemu przez podmiot zewnętrzny. Dla każdej zmiennej tego typu zostanie zdefiniowana nowa klasa, której obiekty będą zawierały różne wartości testowe dla tej zmiennej. Przykład tego typu zmiennej pracy przedstawiono w studium przypadku. Drugi typ składa się z tych zmiennych operacyjnych, które wskazują na wybór między wieloma opcjami dostępnymi dla aktora zewnętrznego. Zamiast tego taki wybór zostanie zaimplementowany bezpośrednio jako część kodu, który implementuje interakcję między aktorem a systemem. Trzeci typ składa się z tych zmiennych operacyjnych, które wskazują stan systemu. Aby zaimplementować metodę konfiguracji przypadków testowych, napisz niezbędny kod, aby poprawnie ustawić wartości zmiennych operacyjnych opisujących stany systemu lub zweryfikować zgodność wartości. Podobnie metoda break musi przywrócić te wartości do ich pierwotnych stanów. Ponadto metoda śledzenia musi w razie potrzeby wykluczyć informacje wprowadzone przez przypadek testowy do systemu podczas wykonywania przypadku testowego. W studium przypadku przedstawiono kilka przykładów zmiennych operacyjnych tego typu. W tym przypadku pierwszą rzeczą do zrobienia jest zastosowanie tego, co zaobserwowano, aby uzyskać zestaw celów testowych z przypadku użycia. Następnie określane są właściwości użytej uprzęży testowej. Na koniec stosujemy to, co widzieliśmy w poprzednie sekcje aby zaimplementować przypadek testowy z celu testowego. Testowany system artefakty zostały zidentyfikowane w dniu język angielski, o ile hiszpański nieobsługiwane przez używane narzędzia. Przypadek użycia w Tabeli 2 opisuje wprowadzenie nowego łącza w systemie. Dodatkowo pokazano również wymóg przechowywania informacji opisujących informacje obsługiwane przez każdy link. Z przypadku użycia i automatycznie wygenerowany zestaw scenariuszy, które będą celem testowania wspomnianego przypadku użycia. Biorąc pod uwagę, że przypadek użycia ma nieograniczoną liczbę pętli z nieskończoną liczbą potencjalnych powtórzeń, kryterium pokrycia wybranym do uzyskania dróg jest kryterium 01, które sprawdza i testuje testy systemu 30, polega na uzyskaniu wszystkich możliwych ścieżek dla powtórzenia żadnego lub jednorazowego każdą z pętli. Wszystkie skrypty uzyskane przy użyciu tego kryterium i przetłumaczone na język hiszpański są wymienione w tabeli. W tym studium przypadku wybraliśmy scenariusz 09, który jest szczegółowo opisany w tabeli 5 dla jego realizacji. Testowanie i testowanie w testowaniu 31 Informacje o tabeli Wymagania dotyczące referencji. Możesz również zastosować metodę podziału kategorii. Sekcje dla każdej z tych zmiennych są wymienione w tabeli. Testowanie i testowanie systemu 32 Zmienne tabelowe zdefiniowane dla przypadku użycia. Testowanie i testowanie w testowaniu 33 Tabela kategorii dla zidentyfikowanych zmiennych. Jak opisano na rysunku 7, test uprzęży ma na celu symulację zachowania użytkownika i oferuje zestaw stwierdzeń do oceny wyniku. To tłumaczenie jest obecnie wykonywane ręcznie i jest pokazane w tabeli. Testowanie i testowanie transceivera 35 Rysunek Implementacja przypadku testowego. Tłumaczenie na kod wykonywalny kroków wykonywanych przez użytkownika w scenariuszu głównym. To znaczy, aby upewnić się, że kategorie istnieją i że nie ma żadnych okoliczności powodujących błąd podczas przywracania kategorii lub wstawiania nowego linku. Implementacja metody break polegała na przywróceniu pierwotnego zestawu linków zapisanych w systemie. 2 Wykonanie testów akceptacyjnych. Testy akceptacyjne działają tylko z obsługą klienta lub przynajmniej pełnomocnikiem klienta do określenia kryteriów. Bez kryteriów akceptacji sterowników trudno jest sprawdzić, czy tworzysz właściwe oprogramowanie. Klient, wraz ze wszystkimi członkami zespołu programistycznego, musi wspólnie zdefiniować system za pomocą serii „skryptów”, które opisują, co system powinien robić i jak powinien to robić. Tworząc testy z jasnymi wymaganiami i kryteriami akceptacji, oprogramowanie z większym prawdopodobieństwem spełni oczekiwania klientów. Oznacza to jednak, że ktoś ręcznie sprawdza, czy wymagania są spełnione, a aplikacja działa zgodnie z oczekiwaniami. W tym miejscu zamiast wymagań w starszym dokumencie pojawiają się automatyczne testy akceptacyjne, wymagania są definiowane jako przykłady i scenariusze, chronione w ramach kontroli źródła za pomocą artefaktów wdrażania i mogą być uruchamiane w dowolnym momencie, aby sprawdzić, czy spełniają wymagania i działają poprawnie. Możesz użyć tego samego podejścia do pisania testów, ale zamiast wpisywać je w oprogramowaniu do zarządzania przypadkami testowymi lub arkuszu kalkulacyjnym, napisz je bezpośrednio w kodzie. Testowanie i testowanie systemu 37 1 Automatyczne testy akceptacyjne. Dlatego pierwszym krokiem we wdrażaniu każdej nowej funkcjonalności jest opisanie swoich oczekiwań testem. Inni nie mają i z czasem zmagają się z kontrolą procesu, zwłaszcza gdy rośnie liczba dowodów i elastyczność testowania zaczyna się pogarszać. Podejście oparte na testach opiera się na tym, które testy powinny kierować tworzeniem oprogramowania. W przemysłowych produktach oprogramowania, gdy stosowane są metody inżynierii wymagań, są one w większości obsługiwane przez język naturalny, co pociąga za sobą dobrze znaną niedogodność niejednoznaczności. Jednak potrzeba walidacji może przewyższać korzyści, jakie może zaoferować bardziej formalna i rygorystyczna specyfikacja wymagań. Klient musi być w stanie przeczytać i zrozumieć wymagania, aby móc się na nie zgodzić. Najpopularniejsze metody definiowania wymagań wymieniono w sekcji Przypadki użycia i historie użytkowników. Zdefiniowanie wymagań jest kluczem do pozyskania klienta. Wymagania - cel osiągnięcia, czyli czego klient oczekuje od oprogramowania. Testowanie i testowanie systemu 38 ról związanych ze specyfikacją wymagań oraz walidacją i testami akceptacyjnymi. Pojęcie wymagań staje się Kontenerem Testów Akceptacyjnych i to właśnie one zajmują centralne miejsce jako specyfikacja każdego wymagania. Rozważ wymóg „Wypłać pieniądze” w kontekście bankomatu. Typowa opisowa specyfikacja może wyglądać następująco: Klient musi mieć możliwość wypłaty gotówki z kasjera w wybranych kwotach. Zawsze otrzymaj pokwitowanie, jeśli w kasie nie ma papieru. W przypadku Klienta Preferencyjnego możesz dokonać wypłaty więcej pieniędzy niż masz na swoim koncie, ale powinieneś być ostrzeżony, że zostaniesz obciążony procentem. Klient powinien mieć możliwość anulowania w dowolnym momencie przed potwierdzeniem wypłaty. Kwoty muszą być w stanie obsłużyć rachunki, które kasjer posiada w danym momencie, a inne kwoty nie mogą być akceptowane. Rysunek – Alternatywne specyfikacje Rysunek 10 przedstawia niektóre alternatywne specyfikacje dla tego wymagania. Ikony odzwierciedlają wygodę każdej specyfikacji. Może być interesujące opracowanie diagramu sekwencji w celu zdefiniowania każdego scenariusza spełnienia wymagania, jednak generalnie nie jest to odpowiednie ze względu na duża liczba wygenerowane diagramy. Bardziej interesujące jest identyfikowanie scenariuszy niż ilustrowanie każdego z nich na diagramie. Opis narracyjny nie jest jednorazowy, przynajmniej dla krótka definicja wymagania, który koncentruje się na zdefiniowaniu powiązanych pojęć. Jednak model użytkowania nie nadaje się do zilustrowania szczegółowej struktury wymagań oprogramowania w środowisku długoterminowej konserwacji, ponieważ przeciętny produkt oprogramowania może mieć tysiące wymagań. Potrzebne są bardziej odpowiednie mechanizmy do wizualizacji i zarządzania wieloma wymaganiami. Szablony są jedną z najczęściej używanych alternatyw do użycia w przypadkach użycia. Szablony są eleganckie i zapewniają poczucie porządku w specyfikacji. Jednak generalnie przynoszą one efekt przeciwny do zamierzonego, ponieważ zwykle zapewniają jeden poziom przetwarzania szczegółów dla wszystkich wymagań. W tych bardzo prostych przypadkach zawierają one rzeczy, które są oczywiste lub nieistotne, aby objąć wszystkie sekcje szablonu. Gdy wymaganie obejmuje wiele skryptów, próba zsyntetyzowania wszystkich skryptów w szablonie zwykle prowadzi do mylących specyfikacji. W ten sposób wymagania działają jak kontenery dla kraju. W zależności od wymagań przydatne mogą być inne dodatkowe formy specyfikacji. Na przykład diagram aktywności, jeśli zachowanie związane z wymaganiem ma symbol algorytmiczny, lub diagram stanu, jeśli zachowanie obejmuje włączanie lub wyłączanie działań zgodnie z asercjami systemu i testami akceptacji systemu. Istotną przesłanką jest pragmatyzm w odniesieniu do specyfikacji, który nie wyklucza dzielenia się alternatywami dla specyfikacji, ale podstawowym kryterium powinna być chęć osiągania zysków i przyczyniania się do utrzymania tej specyfikacji. Z drugiej strony, jeśli chodzi o dążenia do: utrzymanie, szczególnie pod względem spójności, ważne jest, aby nie nadużywać powielania lub powielania specyfikacji w różne środki reprezentacja. Wykres skierowany jest odpowiednią reprezentacją do doprecyzowania poziomu. Ten wykres umożliwia wizualizację relacji dekompozycji i zależności między wymaganiami. Zatem każdy węzeł jest wymaganiem funkcjonalnym lub niefunkcjonalnym. Łuki między węzłami ustanawiają relacje między rodzicami a dziećmi lub relacje zależności „węzły wpływające na węzły”. Zatem w powyższym przykładzie wymaganie „Wypłać pieniądze” może być węzłem struktury wymagań. Zwrot z ilością podaną przez klienta. Brak dostępnych biletów. Nie ma papieru do odbioru. Przekroczono czas komunikacji z systemem centralnym. Powiadomienie o operacjach wewnętrznych kasjera. Upłynął limit czasu na rozpoczęcie działania. Może to być związane z wymaganiem funkcjonalnym lub wymaganiem niefunkcjonalnym. Jest opcjonalny i służy do ustawiania warunków wstępnych przed zastosowaniem kroków testowych. Są to interakcje aktora z systemem. Gdy wykonują wiele akcji, można je umieścić na liście numerowanej. To efekt interakcji aktorów. Każda akcja może spowodować jeden lub więcej wyników. Ważne jest, aby w przypadku komunikatów do użytkownika tekst był uwzględniony jako część oczekiwanych wyników, więc programista ma już te informacje zweryfikowane z klientem. To, jak wskażemy poniżej, ustali zależność między wymaganiami. Warunek Musi być normalnym klientem. Kroki  Spróbuj zwrócić normalnemu klientowi i zażądaj kwoty przekraczającej saldo.  Oczekiwany wynik. Testowanie i odbiór systemu 42  Pojawia się komunikat „Żądana ilość przekracza bieżące saldo, wprowadź ponownie ilość” i powraca do okna wprowadzania ilości. Testy akceptacyjne pomogą potwierdzić, że tworzysz aplikację, której chce klient, podczas gdy automatyzacja tych skryptów pozwala na ciągłe testowanie aplikacji w całym procesie tworzenia i używanie ich jako części zestawu testów regresyjnych, aby upewnić się, że przyszłe zmiany nie zepsują bieżących wymagania. Jednak posiadanie klienta związanego z kompilacją dowodów, zwłaszcza z automatycznym testowaniem, nastręcza szereg potencjalnych problemów. Klienci na ogół nie są techniczni i mają tendencję do dystansowania się od samego tworzenia oprogramowania. Klient może dostarczyć dane i przykłady, a testerzy lub programiści mogą szybko kodować skrypty i wykonywalne specyfikacje. Testy akceptacji interfejsu użytkownika W przykładach testy akceptacji koncentrowały się na logice biznesowej i obiektach domeny, aby sprawdzić, czy logika działała pomyślnie. Ale co z tym, jak użytkownik wchodzi w interakcję z aplikacją? Te testy akceptacyjne powinny być po to, aby przetestować poprawność logiki z punktu widzenia użytkownika, a z punktu widzenia użytkownika jest interfejs użytkownika. Jeśli aplikacja ma dobre odsprzęganie i dobre oddzielenie logiki od kodu interfejsu użytkownika, powinno to ułatwić implementację testów. Jeśli testujesz na tym poziomie, testy nie zmienią się w interfejsie użytkownika. Chociaż testowanie powinno skupiać się wyłącznie na logice, nie oznacza to, że nie należy przechodzić testów akceptacyjnych na całym interfejsie użytkownika. Lubię mieć zestaw testów dymu, które mają na celu podstawowy interfejs użytkownika” szczęśliwa droga”. Koncentrują się na częściach aplikacji, z których użytkownicy najprawdopodobniej będą korzystać, aby jak najlepiej wykorzystać swoje doświadczenie. najmniejsza ilość testowanie. Jeśli spróbujesz wszystko zakryć możliwe sposoby i korzystanie z interfejsu użytkownika, a jeśli interfejs użytkownika się zmieni, będziesz musiał zmienić wszystkie testy. Na przykład, jeśli testujesz interfejs użytkownika dla witryny e-commerce, droga chętnie wybierze przedmiot, doda go do koszyka, sprawdzi i zobaczy potwierdzenie zakupu. Jeśli ten scenariusz się nie powiedzie, naprawdę chcesz się dowiedzieć jak najszybciej. W przypadku niektórych aplikacji, w zależności od złożoności i żywotności, możesz chcieć mieć więcej testów akceptacyjnych w interfejsie użytkownika, aby upewnić się, że masz większe zaufanie do warstwy interfejsu użytkownika. Jednak pomyślne testowanie interfejsu użytkownika to trudne pytanie i nie mam na to miejsca. Testowanie i akceptacja systemów 43 3Inteligentne testy. Po opowiedzeniu historii i skryptów w jasnym i zrozumiałym formacie, następnym krokiem jest zautomatyzowanie historii i skryptów. Dzięki temu mogą działać podczas opracowywania, aby śledzić postępy i wyłapywać błędy regresji. Wnioski i Rekomendacje. Z drugiej strony mamy testy systemowe, które są odpowiedzialne za ocenę działania w całym procesie, w celu wykrycia błędów, które mogą w tym przypadku wystąpić, konieczne jest opracowanie strategii z testami i oddzielenie tworzenia kodu od rozwoju interfejsu, tak aby najlepiej zaimplementować testy systemowe. Wdrożenie tych dwóch testów oprogramowania musi być przeprowadzone z rygorystycznymi testami, które spełniają określone standardy oraz z koordynacją interesariuszy zaangażowanych w rozwój systemu. Testowanie i akceptacja systemu 44 Bibliografia 1. Isabelle Ramos Roman, José Javier Dolado Cosin. Metody zarządzania ilościowego w tworzeniu oprogramowania. Alonso Amo, Loic Martinez Normand. Wprowadzenie do tworzenia oprogramowania. Testowanie systemów i testy akceptacyjne 45 8. -Katedra Języków i Systemów Komputerowych. Strukturalny Analiza systemu. Metody identyfikacji bakterii w laboratorium mikrobiologii.