Rozwój badań z modelu
W Microsoft Visual Studio Ultimate, można użyć wymagania i modeli architektonicznych, aby ułatwić organizowanie testów systemu i jego składników.Praktyka ta pomaga w zapewnieniu, że badanie wymogów, które są ważne dla użytkowników i innych zainteresowanych stron i pomaga szybko aktualizować badania po zmienić wymagania.Jeśli korzystasz z Microsoft Test Manager, można także utrzymać łącza między modelami i badań.
System i testowania podsystemu
Testowanie systemu, znany również jako testowania akceptacji, oznacza sprawdzenie, czy spełnione są wymagania użytkowników.Takie badania niepokoją się o zachowanie widoczne z zewnątrz systemu, zamiast wewnętrznego projektu.
Testy systemu są bardzo przydatne podczas rozszerzania lub zawierała systemu.Ułatwiają one uniknięcia wprowadzenia błędów po zmienić kod.
Plan, każda zmiana lub rozszerzenie systemu, warto uruchomić zestaw testów systemu działających w systemie istniejących.Następnie można rozszerzyć lub dopasować testów do testowania nowych wymagań, wprowadź zmiany do kodu i uruchom ponownie cały zestaw testów.
Podczas opracowywania nowego systemu, można rozpocząć tworzenie testów natychmiast rozpoczyna się rozwoju.Definiując testów przed rozwijać każdej funkcji, można przechwytywać dyskusje wymagania w bardzo specyficzny sposób.
Badania podsystemu stosuje się te same zasady do głównych składników systemu.Każdy składnik jest badana oddzielnie od innych składników.Podsystem testów skupić się na zachowanie widoczne na interfejsy użytkownika lub interfejsu API komponentu.
Aby uzyskać więcej informacji o sposobach uruchamiania testów, zobacz Testowanie aplikacji.
Wynikające z badań systemu z modelu wymagania
Można utworzyć i zarządzać relację między testy systemu i model wymagania.Ustanowienie tej relacji, pisania testów, które odpowiadają głównych elementów modelu wymagania.Visual Studio Ultimatepomaga zachować tej relacji, umożliwiając tworzenie łączy między testami a części modelu.Aby uzyskać więcej informacji na temat modeli wymagania, zobacz Wymagania użytkownika modelowania.
.gif "Dd409381.collapse_all(pl-pl,VS.110).gif")
Pisać testy dla każdego przypadku użycia
Jeśli korzystasz z Microsoft Test Manager, można utworzyć grupy badań dla każdego przypadku użycia, zdefiniowane w modelu wymagania.Na przykład jeśli w przypadku użycia kolejności mączki, która obejmuje tworzenie zamówienia i Dodaj element do zamówienia, można utworzyć badań zarówno ogólny i bardziej szczegółowe tych przypadki użycia.Aby uzyskać więcej informacji na temat przypadków użycia, zobacz Diagramy przypadków użycia UML: wytyczne.
Wytyczne te mogą być pomocne:
Każdy przypadek użycia powinny mieć kilka badań, głównym ścieżki i wyjątkowych wyników.
Możesz opisać przypadek użycia w modelu wymagania, jest bardziej ważne zdefiniowanie jej postcondition, oznacza to, że cel zostanie osiągnięty, niż opisano szczegółowo procedury użytkownika poniżej do osiągnięcia tego celu.Na przykład, może być postcondition zamówienia posiłek, restaurację przygotowuje jedzenie dla klienta i klient zapłacił.Postcondition to kryterium, które należy sprawdzić testy.
Bazowy oddzielne badania oddzielnych klauzul postcondition.Na przykład utworzyć oddzielne badania dla powiadamiania restauracji kolejności i za podejmowanie płatności od nabywcy.Podział ten ma te zalety:
Zmiany w różnych aspektów wymagania często występować niezależnie.Dzieląc testów na różne aspekty w ten sposób, można ułatwić aktualizacji badania po zmienić wymagania.
Jeśli plan rozwoju implementuje jeden z aspektów przypadek użycia przed innym, można włączyć badania oddzielnie w miarę postępu w rozwoju.
Podczas projektowania badań należy oddzielić wybór danych z badań z kodu lub skrypt, który określa, czy osiągnięte zostały postcondition.Na przykład, może być badanie prosta funkcja arytmetyczne: Input 4; Sprawdź, czy dane wyjściowe jest 2.Zamiast tego projektu jako skrypt: Wybierz dane wejściowe; należy pomnożyć wynik przez sam i sprawdź, czy wynik jest oryginalne dane wejściowe.Styl ten umożliwia bez zmiany głównej badania w zależności od nakładów badania.
Łączenie badań przypadkami użycia
Jeśli używasz Test Manager do projektowania i uruchomić testy, można organizować testy mocy wymóg, przypadek użycia lub elementów pracy story użytkownika.Można połączyć te elementy przypadkami użycia modelu pracy.Dzięki temu można szybko śledzenia zmian wymagań do testów i pomaga śledzić postęp każdego przypadku użycia.
Aby połączyć testów w przypadku użycia
W Test Manager, Utwórz wymóg i jako podstawy zestaw testów.Aby dowiedzieć się, jak to zrobić, zobacz Tworzenie testów zaległych elementów, przypadków użycia lub wymagań produktu.
Wymóg, tworzona jest element pracy w Team Foundation Server.Może być Story użytkownika, wymaganie lub przypadek użycia elementu pracy, w zależności od szablonu procesu, który korzysta z projektu z Team Foundation.Aby uzyskać więcej informacji, zobacz Planowanie i śledzenie projektów.
Wymóg elementu pracy można połączyć w jeden lub więcej przypadków użycia modelu.
W diagramie przypadku użycia, kliknij prawym przyciskiem myszy w przypadku użycia, a następnie kliknij przycisk łącze do elementu pracy.Aby uzyskać więcej informacji, zobacz Łączenie elementów modeli i elementów pracy.
Dodać zestaw testów, przypadków testów, które pozwalają sprawdzić przypadków użycia.
Zazwyczaj każdy element pracy użytkownika, jak wątek lub wymóg połączy się z kilku przypadków użycia modelu i każdy przypadek użycia połączy się z kilku wątków użytkownika lub wymagania.Jest tak, ponieważ każdy wątek użytkownika lub wymóg obejmuje zestaw zadań, które rozwijać kilka przypadków użycia.Na przykład w wczesnych iteracji projektu mogą opracowywać story podstawowe użytkownika, w którym klient może wybrać elementy z wykazu i zostały one dostarczone.W iteracji później wątku może być, że użytkownik płaci podczas dopełniania zamówienia i dostawca otrzyma pieniądze po wysyła towary.Każdy wątek dodaje klauzulę do postcondition w przypadku użycia towarów w kolejności.
Od wymagań można tworzyć oddzielne łącza do klauzul postcondition, pisząc tych klauzul w oddzielnych komentarze na diagramie przypadku użycia.Można połączyć każdy komentarz do elementu pracy wymogu i połączyć komentarz na diagramie przypadku użycia.
Podstawowych badań na typy wymagania
Typy, które jest klasy, interfejsy i wyliczeń modelu wymagania opisano koncepcje i relacje z punktu widzenia użytkowników myśleć jak komunikowanie się dotyczące ich działalności.Nie obejmuje on typy danych tylko z projektu wewnętrznego systemu.
Projektowanie testy z tych typów wymagania.Praktyka ta pomaga zapewnienia, że gdy omawiane są zmiany do wymagań jest łatwe dotyczą zmian koniecznych zmian w badaniach.Czyni to przedyskutować testów oraz ich zamierzone wyniki bezpośrednio z użytkowników końcowych i innych zainteresowanych stron.To oznacza, że użytkowników potrzebuje mogą być utrzymywane poza procesu rozwoju i pozwala uniknąć niezamierzonych projekt badań wokół możliwych wad w projekcie.
Dla badań ręczne praktyka ta obejmuje przylegającą do słownika modelu wymagania w zakresie skryptów testu.Dla zautomatyzowanych testów praktyka ta obejmuje przy użyciu diagramów klas wymogów jako podstawa dla kodu testu i tworzenie akcesor i updater funkcji, aby połączyć model wymóg kod.
Na przykład wymagania, który może zawierać model typów Menu, element Menu, zamówienia i związków między nimi.Ten model reprezentuje informacje, które są przechowywane i zajmuje mączki, system zamawiania, ale nie reprezentują złożonością jej wykonania.W systemie pracy może być kilka różnych realizacje każdego typu, w przypadku baz danych w interfejsów użytkownika i interfejsów API.W rozproszonym systemie może być kilka wariantów każde wystąpienie przechowywanych w różnych częściach systemu, w tym samym czasie.
Aby przetestować przypadek użycia, takie jak dodawanie elementu do zamówienia, metoda badania może zawierać kod podobny do tego:
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);
Należy zauważyć, że ta metoda badawcza korzysta z klas modelu wymagania.Stowarzyszenia i atrybuty są realizowane jako.Właściwości netto.
Aby to działało, właściwości klasy musi być określony jako tylko do odczytu, funkcje lub akcesory, do których dostęp do systemu, aby pobrać informacje o bieżącym stanie.Metody, które symulują przypadkami użycia, takie jak AddItemToOrder musi dysków systemu za pośrednictwem interfejsu API lub warstwę pod spodem jego interfejs użytkownika.Konstruktory test obiektów, takich jak zamówienia i MenuItem musi również dysk systemu, aby utworzyć odpowiednie elementy wewnątrz systemu.
Wielu akcesorów i programy instalujące aktualizacje będą już dostępne za pośrednictwem interfejsu API normalnego stosowania.Jednak niektóre funkcje dodatkowe mogą muszą być zapisywane w celu umożliwienia badania.Te dodatkowe akcesorów i programy instalujące aktualizacje są czasami znane jako "oprzyrządowanie do badania".Ponieważ zależą one od wewnętrznego projekt systemu, jest odpowiedzialność deweloperów systemu dostarczenia im, testerów napisać kod badań w modelu wymagania.
Podczas pisania testy automatyczne umożliwia otaczanie akcesorów i programy instalujące aktualizacje rodzajowy testów.Aby uzyskać więcej informacji, zobacz Tworzenie automatycznego testu jest uruchamiany plik wykonywalny za pomocą badań rodzajowy.
Testy na reguły biznesowe
Niektóre wymagania nie są bezpośrednio związane z każdy przypadek użycia jednego.Na przykład, DinnerNow business pozwala wybierać spośród wielu menu, ale wymaga, aby w każdym celu wszystkich wybranych elementów są z jednego Menu.To reguła biznesowa może być wyrażona jako niezależna o skojarzenia między zamówienia, menu i elementy w modelu wymagania klasy.
Niezmienny zasada tego rodzaju reguluje nie tylko wszystkie przypadki użycia, które są aktualnie zdefiniowane, ale także wszelkie inne przypadki użycia, które zostaną określone później.Dlatego jest przydatne, zapisz je oddzielnie od każdy przypadek użycia i przetestować w oddzielnie od przypadków użycia.
Można napisać regułę biznesową niezmienny jako komentarz w diagramie klasy.Aby uzyskać więcej informacji, zobacz Diagramy klas UML: wytyczne.
Badania można połączyć reguły biznesowej, łącząc komentarz do wymogu lub użytkownika wątku elementu, który można połączyć zestaw testów w Test Manager.Aby uzyskać więcej informacji, zobacz Dołączanie przypadków testów, aby elementy modelu.
Wydajność i jakość innych wymagań dotyczących usług można zauważyć w komentarzach, w przypadku użycia, działalności lub diagramy sekwencji.Można połączyć te również do wymogów elementów pracy i ich pakietów testowych.
Diagramy aktywności dla badań i sekwencji
Jeśli wymagania lub architektury modele zawierają sekwencję lub diagramy aktywności, można pisać testy, które należy wykonać diagramy bezpośrednio.
Czasami jest przydatne do projektowania testów, które dynamicznie wybierz różnych ścieżek za pośrednictwem oddziałów i pętle na diagramie.
Spróbuj sprawdzić stan systemu po każdej wiadomości lub działania.Może to wymagać dodatkowych instrumentacji.
Wynikające z badań podsystemu z modeli
W projektowaniu wysokiego szczebla dużej ilości pamięci można zidentyfikować, elementów lub podzespołów.Te reprezentują części, które mogą być oddzielnie zaprojektowane, znajdują się na różnych komputerach lub są w modułach wielokrotnego użytku, które mogą być odtwarzane na wiele sposobów.Aby uzyskać więcej informacji, zobacz Diagramy składników UML: wytyczne.
Można zastosować do każdej głównej części tych samych zasadach jak używać dla kompletny system.W dużym projekcie każdy składnik może mieć własny model wymagania.W mniejszych projektów Aby wyświetlić główne składniki i ich interakcje można utworzyć model architektoniczny lub projektu wysokiego poziomu.Aby uzyskać więcej informacji, zobacz Architektura systemu oprogramowania modelowania.
W obu przypadkach można ustanowić relacji między elementami modelu i badania podsystemu w taki sam sposób jak w przypadku między modelem wymagania i badania systemu.
Izolowanie składników z interfejsów przewidzianych i wymagane
Przydaje się, aby zidentyfikować zależności, które dany składnik ma na innych częściach systemu lub usługi zewnętrzne oraz do reprezentowania tych wymaganych interfejsów.W tym ćwiczeniu zwykle prowadzi do niektórych przeprojektować, który opuszcza składnika znacznie bardziej rozdzielonego i łatwo rozdzielić od pozostałej części projektu.
Zaletą tego rozdzielenie jest, że składnik mogą być wykonywane do testowania, zastępując opublikowali obiektów usługi, które zwykle używa.Są to składniki, które są skonfigurowane dla celów testowania.Składnik opublikowali udostępnia interfejs, który wymaga składnika, odpowiada na kwerendy z danymi symulowane.Składniki opublikowali stanowią część przewodów pełne badanie, które można podłączyć do wszystkich interfejsów składnika.
Korzyści z badania opublikowali jest opracowanie składnika, podczas gdy inne składniki, których będzie używać usługi są wciąż w fazie opracowania.
Zachowania relacji między testami a modelem
W typowym projekcie wykonuje iterację co kilka tygodni Przegląd wymagań odbywa się w pobliżu początku każdej iteracji.Spotkania omówiono funkcje, które mają zostać dostarczone w następnej iteracji.Model wymagania może służyć do pomocy omówienia pojęć, scenariuszy i sekwencji akcji, które zostaną opracowane.Zainteresowane strony business ustalić priorytety, deweloperzy dokonać oszacowań i testerów upewnij się, że oczekiwane zachowanie każdej funkcji jest przechwycone prawidłowo.
Pisania testów jest najbardziej skutecznym sposobem, aby zdefiniować wymóg i jest również efektywnym sposobem zapewnienia, że osoba ma zrozumieć, co jest wymagane.Jednakże należy pisania testów trwa zbyt długo, wykonywane w trakcie warsztatów specyfikacji, tworzenie modeli można zrobić znacznie szybciej.
Z badań punktu widzenia modelu wymagań może być traktowany jako skrótowej dla badań.Dlatego jest ważne, aby zachować relację między testami a modelem podczas trwania projektu.
Dołączanie przypadków testów do elementów modelu
Jeśli Twój program project używa Test Manager, badania można połączyć elementów modelu.Pozwala szybko znaleźć testów, wpływ zmiany w wymogach i pomaga śledzić w zakresie, w jakim zostały zrealizowane wymóg.
Badania można połączyć wszystkie rodzaje elementu.Oto kilka przykładów:
Łącze przypadek użycia do badań, które jego wykonywania.
Zapis klauzul postcondition przypadku użycia lub cel na komentarze, które są połączone w przypadku użycia, a następnie połączyć testów na każdy komentarz.
Pisania reguł niezmienne w komentarzy na diagramach klas lub diagramy aktywności i łączenia ich z badań.
Testy łącze diagram aktywności lub poszczególnych działań.
Zestaw testów połączyć składnik lub podsystem, który sprawdza.
Aby połączyć testów elementu modelu lub relacji
W Test Manager, Utwórz wymóg i jako podstawy zestaw testów.Aby dowiedzieć się, jak to zrobić, zobacz Tworzenie testów zaległych elementów, przypadków użycia lub wymagań produktu.
Wymóg, tworzona jest element pracy w Team Foundation Server.Może być Story użytkownika, wymaganie lub przypadek użycia elementu pracy, w zależności od szablonu procesu, który korzysta z projektu z Team Foundation.Aby uzyskać więcej informacji, zobacz Planowanie i śledzenie projektów.
Element pracy wymogu można połączyć w jeden lub więcej elementów w modelu.
W diagramie modelowania, kliknij prawym przyciskiem myszy element, komentarz lub relacji, a następnie kliknij przycisk łącze do elementu pracy.Aby uzyskać więcej informacji, zobacz Łączenie elementów modeli i elementów pracy.
Dodać zestaw testów, przypadków testów, które pozwalają sprawdzić wymogu, wyrażone w element modelu.
Zobacz też
Koncepcje
Modele projektowania dla projektowania oprogramowania
Wymagania użytkownika modelowania