Udostępnij za pośrednictwem

Opracowywanie testów na podstawie modelu

  • Artykuł

Możesz użyć wymagań i modeli architektonicznych, aby ułatwić organizowanie testów systemu i jego składników. Ta praktyka pomaga zapewnić testowanie wymagań, które są ważne dla użytkowników i innych osób biorących udział w projekcie, i pomaga szybko aktualizować testy po zmianie wymagań. Jeśli używasz programu Microsoft Test Manager, możesz również utrzymywać połączenia między modelami i testami.

Aby sprawdzić, które wersje programu Visual Studio obsługują te funkcje, zobacz Obsługa wersji dla narzędzi do architektury i modelowania.

Testowanie systemu i podsystemu

Testowanie systemu, znane również jako testowanie akceptacyjne, oznacza testowanie, czy potrzeby użytkowników są spełnione. Takie testy dotyczą zewnętrznego zachowania systemu zamiast projektu wewnętrznego.

Testy systemowe są bardzo cenne podczas rozszerzania lub przeprojektowania systemu. Ułatwiają one unikanie wprowadzania usterek podczas zmiany kodu.

Jeśli planujesz dowolną zmianę lub rozszerzenie systemu, warto rozpocząć od zestawu testów systemowych uruchamianych w istniejącym systemie. Następnie można rozszerzyć lub dostosować testy, aby przetestować nowe wymagania, wprowadzić zmiany w kodzie i ponownie uruchomić kompletny zestaw testów.

Podczas tworzenia nowego systemu można rozpocząć tworzenie testów zaraz po rozpoczęciu opracowywania. Definiując testy przed opracowaniem każdej funkcji, można przechwycić dyskusje dotyczące wymagań w bardzo konkretny sposób.

Testowanie podsystemu stosuje te same zasady do głównych składników systemu. Każdy składnik jest testowany oddzielnie od innych składników. Testy podsystemu koncentrują się na zachowaniu widocznym w interfejsach użytkownika lub interfejsie API składnika.

Wyprowadzanie testów systemowych z modelu wymagań

Relację między testami systemowym i modelem wymagań można tworzyć i utrzymywać. Aby ustanowić tę relację, należy napisać testy, które odpowiadają głównym elementom modelu wymagań. Program Visual Studio ułatwia utrzymanie tej relacji, umożliwiając tworzenie linków między testami i częściami modelu. Aby uzyskać więcej informacji na temat modeli wymagań, zobacz Wymagania użytkownika modelu.

Pisanie testów dla każdego przypadku użycia

Jeśli używasz programu Microsoft Test Manager, możesz utworzyć grupę testów dla każdego przypadku użycia zdefiniowanego w modelu wymagań. Jeśli na przykład masz przypadek użycia Order a Meal( Zamówienie posiłku), w tym Create Order (Utwórz zamówienie) i Add Item to Order (Dodaj element do zamówienia), możesz utworzyć testy dla całego i bardziej szczegółowego opisu tych przypadków użycia.

Te wytyczne mogą być przydatne:

  • Każdy przypadek użycia powinien mieć kilka testów, dla głównych ścieżek i wyjątkowych wyników.

  • W przypadku opisywania przypadku użycia w modelu wymagań ważniejsze jest zdefiniowanie jego wartości po zakończeniu, czyli cel, który został osiągnięty, niż szczegółowo opisać procedury, które użytkownik wykonuje w celu osiągnięcia celu. Na przykład po zakończeniu zamówienia posiłku może być to, że restauracja przygotowuje posiłek dla klienta i że klient zapłacił. Po zakończeniu jest kryterium weryfikacji testów.

  • Bazuj oddzielne testy na oddzielnych klauzulach pokondycji. Na przykład utwórz oddzielne testy do powiadamiania restauracji o zamówieniu oraz do przyjmowania płatności od klienta. Ta separacja ma następujące zalety:

    • Zmiany w różnych aspektach wymagań często występują niezależnie. Dzięki rozdzieleniu testów na różne aspekty w ten sposób można ułatwić aktualizowanie testów w przypadku zmiany wymagań.

    • Jeśli plan programowania implementuje jeden aspekt przypadku użycia przed innym, możesz włączyć testy oddzielnie w miarę postępu programowania.

  • Podczas projektowania testów należy oddzielić wybór danych testowych od kodu lub skryptu, który określa, czy data postcondition została osiągnięta. Na przykład test prostej funkcji arytmetycznej może być: Input 4; Sprawdź, czy dane wyjściowe to 2. Zamiast tego zaprojektuj skrypt jako: wybierz dane wejściowe; pomnóż dane wyjściowe samodzielnie i sprawdź, czy wynik jest oryginalnym wejściem. Ten styl umożliwia zmianę danych wejściowych testów bez zmieniania głównej treści testu.

Łączenie testów z przypadkami użycia

Jeśli używasz menedżera testów do projektowania i uruchamiania testów, możesz organizować testy zgodnie z wymaganiami, przypadkiem użycia lub elementami roboczymi scenariusza użytkownika. Możesz połączyć te elementy robocze z przypadkami użycia w modelu. Dzięki temu można szybko śledzić zmiany wymagań w testach i śledzić postęp każdego przypadku użycia.

  1. W Menedżerze testów utwórz wymaganie i utwórz na nim zestaw testów.

    Wymaganym elementem roboczym tworzonym w programie Team Foundation Server. Może to być element roboczy Scenariusz użytkownika, Wymaganie lub Przypadek użycia, w zależności od szablonu procesu używanego przez projekt z programem Team Foundation. Aby uzyskać więcej informacji, zobacz About Agile tools and Agile project management (Informacje o narzędziach Agile i zarządzaniu projektami Agile).

  2. Połącz element roboczy wymagania z co najmniej jednym przypadkiem użycia w modelu.

    Na diagramie przypadku użycia kliknij prawym przyciskiem myszy przypadek użycia, a następnie kliknij polecenie Połącz z elementem roboczym.

  3. Dodaj do zestawu testów, przypadki testowe, które weryfikują przypadki użycia.

    Zazwyczaj każdy scenariusz użytkownika lub element roboczy wymagań będzie łączyć się z kilkoma przypadkami użycia w modelu, a każdy przypadek użycia będzie łączyć się z kilkoma scenariuszami lub wymaganiami użytkownika. Dzieje się tak, ponieważ każdy scenariusz użytkownika lub wymaganie obejmuje zestaw zadań, które tworzą kilka przypadków użycia. Na przykład we wczesnej iteracji projektu możesz opracować podstawową historię użytkownika, w której klient może wybrać elementy z katalogu i dostarczyć je. W późniejszej iteracji może się okazać, że użytkownik płaci podczas realizacji zamówienia, a dostawca otrzymuje pieniądze po wysłaniu towarów. Każda historia dodaje klauzulę do pokondycji przypadku użycia Order Goods.

    Możesz utworzyć oddzielne linki od wymagań do klauzul postcondition, pisząc te klauzule w osobnych komentarzach na diagramie przypadków użycia. Każdy komentarz można połączyć z elementem roboczym wymagań i połączyć komentarz z przypadkiem użycia na diagramie.

Podstawowe testy typów wymagań

Typy, czyli klasy, interfejsy i wyliczenia, modelu wymagań opisują pojęcia i relacje pod względem sposobu, w jaki użytkownicy myślą i komunikują się ze swoją działalnością. Wyklucza on typy, których dotyczy tylko wewnętrzny projekt systemu.

Zaprojektuj testy pod względem tych typów wymagań. Ta praktyka pomaga zapewnić, że podczas omawiania zmian wymagań łatwo jest powiązać zmiany z niezbędnymi zmianami w testach. Umożliwia to omówienie testów i ich zamierzonych wyników bezpośrednio z użytkownikami końcowymi i innymi uczestnikami projektu. Oznacza to, że potrzeby użytkowników mogą być utrzymywane poza procesem programowania i unika niezamierzonego projektowania testów wokół możliwych wad w projekcie.

W przypadku testów ręcznych ta praktyka polega na przestrzeganiu słownictwa modelu wymagań w skryptach testowych. W przypadku testów automatycznych ta praktyka polega na korzystaniu z diagramów klas wymagań jako podstawy dla kodu testowego oraz tworzenia funkcji metod dostępu i aktualizatora w celu połączenia modelu wymagań z kodem.

Na przykład model wymagań może zawierać typy Menu, Element menu, Kolejność i skojarzenia między nimi. Ten model reprezentuje informacje przechowywane i obsługiwane przez system zamawiania posiłku, ale nie reprezentuje złożoności jego implementacji. W systemie roboczym może istnieć kilka różnych realizacji każdego typu, w bazach danych, w interfejsach użytkownika i w interfejsach API. W systemie rozproszonym może istnieć kilka wariantów każdego wystąpienia przechowywanego w różnych częściach systemu w tym samym czasie.

Aby przetestować przypadek użycia, taki jak Dodawanie elementu do zamówienia, metoda testowa może zawierać kod podobny do następującego:

Order order = ... ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = ...; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);

Zwróć uwagę, że ta metoda testowa używa klas modelu wymagań. Skojarzenia i atrybuty są realizowane jako właściwości platformy .NET.

Aby wykonać tę pracę, właściwości klas muszą być zdefiniowane jako funkcje lub metody dostępu tylko do odczytu, które uzyskują dostęp do systemu w celu pobrania informacji o bieżącym stanie. Metody, które symulują przypadki użycia, takie jak AddItemToOrder, muszą napędzać system za pośrednictwem interfejsu API lub za pośrednictwem warstwy poniżej interfejsu użytkownika. Konstruktory obiektów testowych, takich jak Order i MenuItem, muszą również napędzać system, aby utworzyć odpowiednie elementy wewnątrz systemu.

Wiele metod dostępu i aktualizacji będzie już dostępnych za pośrednictwem normalnego interfejsu API aplikacji. Jednak niektóre dodatkowe funkcje mogą być konieczne w celu włączenia testów. Te dodatkowe metody dostępu i aktualizatory są czasami znane jako "instrumentacja testowa". Ponieważ są one zależne od wewnętrznego projektu systemu, jest to odpowiedzialność deweloperów systemu za ich dostarczanie, podczas gdy testerzy piszą kod testów pod względem modelu wymagań.

Podczas pisania testów automatycznych można użyć testów ogólnych do opakowania metod dostępu i aktualizacji.

Testy reguł biznesowych

Niektóre wymagania nie są bezpośrednio związane z żadnym przypadkiem użycia. Na przykład firma DinnerNow umożliwia klientom wybór spośród wielu menu, ale wymaga, aby w każdym zamówieniu wszystkie wybrane pozycje pochodziły z jednego menu. Ta reguła biznesowa może być wyrażona jako niezmienna zależność między zamówieniami, menu i elementami w modelu klasy wymagań.

Niezmienna reguła tego rodzaju rządzi nie tylko wszystkimi zdefiniowanymi obecnie przypadkami użycia, ale także innymi przypadkami użycia, które zostaną zdefiniowane później. Dlatego warto napisać go oddzielnie od dowolnego przypadku użycia i przetestować go oddzielnie od przypadków użycia.

Wyprowadzanie testów podsystemu z modeli

W projekcie wysokiego poziomu dużego systemu można zidentyfikować składniki lub podsystemy. Reprezentują one części, które można zaprojektować oddzielnie lub znajdują się na różnych komputerach lub są modułami wielokrotnego użytku, które można ponownie połączyć na wiele sposobów.

Dla każdego głównego składnika można zastosować te same zasady, które są używane dla kompletnego systemu. W dużym projekcie każdy składnik może mieć własny model wymagań. W mniejszych projektach można utworzyć model architektoniczny lub projekt wysokiego poziomu, aby pokazać główne składniki i ich interakcje. Aby uzyskać więcej informacji, zobacz Modelowanie architektury aplikacji.

W obu przypadkach można ustanowić relację między elementami modelu a testami podsystemu w taki sam sposób, jak między modelem wymagań a testami systemowymi.

Izolowanie składników z udostępnionymi i wymaganymi interfejsami

Warto zidentyfikować wszystkie zależności, które składnik ma w innych częściach systemu lub usług zewnętrznych, i przedstawić je jako wymagane interfejsy. To ćwiczenie zwykle prowadzi do przeprojektowania, które pozostawia składnik znacznie bardziej oddzielony i łatwo rozdziela się z resztą projektu.

Zaletą tego oddzielenia jest to, że składnik można wykonać do testowania, zastępując pozorowane obiekty usług, których zwykle używa. Są to składniki skonfigurowane do celów testowania. Składnik pozorowany udostępnia interfejs, którego wymaga składnik, odpowiadając na zapytania za pomocą symulowanych danych. Pozorne składniki stanowią część kompletnej uprzęży testowej, którą można połączyć ze wszystkimi interfejsami składnika.

Zaletą pozornego testowania jest możliwość opracowywania składnika, podczas gdy inne składniki, których będą one używane, są nadal opracowywane.

Utrzymywanie relacji między testami i modelem

W typowym projekcie, który wykonuje iterację co kilka tygodni, przegląd wymagań odbywa się w pobliżu początku każdej iteracji. Na spotkaniu omówiono funkcje, które mają zostać dostarczone w następnej iteracji. Model wymagań może służyć do omówienia pojęć, scenariuszy i sekwencji akcji, które zostaną opracowane. Uczestnicy projektu biznesowego ustalają priorytety, deweloperzy tworzą szacunki, a testerzy zapewniają prawidłowe przechwycenie oczekiwanego zachowania każdej funkcji.

Pisanie testów to najbardziej skuteczny sposób definiowania wymagania, a także skuteczny sposób zapewnienia, że dana osoba ma jasne zrozumienie tego, co jest wymagane. Jednak pisanie testów trwa zbyt długo podczas warsztatów specyfikacji, tworzenie modeli może być wykonywane znacznie szybciej.

Z punktu widzenia testowania model wymagań może być postrzegany jako skrócony opis testów. Dlatego ważne jest zachowanie relacji między testami i modelem w całym projekcie.

Dołączanie przypadków testowych do elementów modelu

Jeśli projekt używa menedżera testów, możesz połączyć testy z elementami w modelu. Dzięki temu można szybko znaleźć testy, których dotyczy zmiana wymagań, i ułatwia śledzenie zakresu, w jakim spełniono wymaganie.

Testy można połączyć ze wszystkimi rodzajami elementów. Oto kilka przykładów:

  • Połącz przypadek użycia z testami, które go wykonują.

  • Napisz klauzule przypadku użycia po niepokondycji lub celu na komentarze, które są połączone z przypadkiem użycia, a następnie połącz testy z każdym komentarzem.

  • Napisz niezmienne reguły w komentarzach na diagramach klas lub diagramach działań i połącz je z testami.

  • Łączenie testów z diagramem aktywności lub z poszczególnymi działaniami.

  • Połącz zestaw testów ze składnikiem lub podsystemem, który testuje.

  1. W Menedżerze testów utwórz wymaganie i utwórz na nim zestaw testów.

    Wymaganym elementem roboczym tworzonym w programie Team Foundation Server. Może to być element roboczy Scenariusz użytkownika, Wymaganie lub Przypadek użycia, w zależności od szablonu procesu używanego przez projekt z programem Team Foundation. Aby uzyskać więcej informacji, zobacz About Agile tools and Agile project management (Informacje o narzędziach Agile i zarządzaniu projektami Agile).

  2. Połącz element roboczy wymagania z co najmniej jednym elementem w modelu.

    Na diagramie modelowania kliknij prawym przyciskiem myszy element, komentarz lub relację, a następnie kliknij pozycję Połącz z elementem roboczym.

  3. Dodaj do zestawu testów przypadki testowe, które weryfikują wymaganie wyrażone w elemecie modelu.

Powiązana zawartość