Testowanie obiektów i terminów

Opis

Grupuj zestawy testowe i pojedyncze przypadki testowe. Aby zdefiniować plan testu, zobacz Tworzenie planów testów i zestawów testów.

Grupuj przypadki testowe na oddzielne scenariusze testowania w ramach jednego planu testowego. Grupowanie przypadków testowych ułatwia sprawdzenie, które scenariusze zostały ukończone. Podczas tworzenia zestawu testów można określić jeden z trzech typów:

• Zestawy testów statycznych: służy do grupowania przypadków testowych w ramach pojedynczego zestawu testów.
• Pakiety oparte na wymaganiach: wybierz co najmniej jedno wymaganie z zapytania, które łączysz z zestawem testów.
• Zestawy oparte na zapytaniach: wybierz co najmniej jeden przypadek testowy połączony z zestawem testów.

Zdefiniuj kroki używane do testowania kodu lub aplikacji na potrzeby wdrożenia. Zdefiniuj przypadki testowe, aby upewnić się, że kod działa poprawnie, nie zawiera błędów i spełnia wymagania biznesowe i klienta. Można dodawać poszczególne przypadki testowe do planu testu bez tworzenia zestawu testów. Więcej niż jeden zestaw testów lub plan testu może odwoływać się do przypadku testowego. Można skutecznie używać przypadków testowych bez konieczności kopiowania lub klonowania ich dla każdego pakietu lub planu. Istnieją dwa typy przypadków testowych:

• Ręczne: przypadki testowe definiujące różne kroki uruchamiane przy użyciu modułu uruchamiającego testy lub innego obsługiwanego klienta.
• Automatyczne: Przypadki testowe zaprojektowane do uruchamiania w Azure Pipelines.

Użyj polecenia, aby powielić kroki między wieloma przypadkami testowymi. Na przykład logowanie i weryfikowanie kroków logowania do aplikacji to kroki, które można udostępnić w wielu przypadkach testowych. Aby dowiedzieć się, jak to zrobić, zobacz Udostępnianie kroków między przypadkami testowymi.

Służy do określania różnych parametrów do wykonania kroku testu w danym przypadku testowym. Aby dowiedzieć się, jak to zrobić, zobacz Powtarzanie testu przy użyciu różnych danych.

Użycie

Wprowadź opis 255 znaków lub mniej. Tytuł można zawsze modyfikować później.

Przypisz element roboczy do członka zespołu odpowiedzialnego za wykonywanie pracy. Aby uzyskać więcej informacji na temat wyszukiwania i selekcji tożsamości, zobacz Query by assignment or workflow changes (Wykonywanie zapytań według przypisania lub zmian przepływu pracy).

Podczas tworzenia elementu roboczego stan domyślnie ustawiany jest na pierwszy stan zdefiniowany w przepływie pracy. W miarę postępu pracy zaktualizuj ją, aby odzwierciedlała bieżący stan.

Najpierw użyj wartości domyślnej. Zaktualizuj go, gdy zmienisz stan zgodnie z potrzebami. Każdy stan jest skojarzony z przyczyną domyślną.

Wybierz ścieżkę obszaru skojarzona z produktem lub zespołem lub pozostaw ją pustą do momentu przypisania podczas spotkania planistycznego. Aby zmienić listę rozwijaną obszarów, zobacz Definiowanie ścieżek obszaru i przypisywanie do zespołu.

Wybierz przebieg lub iterację, w której chcesz ukończyć pracę, lub pozostaw ją pustą i przypisz ją później podczas spotkania planistycznego. Aby zmienić listę rozwijaną dla iteracji, zobacz Definiowanie ścieżek iteracji i konfigurowanie iteracji zespołowych.

Podaj wystarczającą ilość szczegółów, aby utworzyć wspólną wiedzę na temat zakresu i wysiłków związanych z szacowaniem pomocy technicznej. Skoncentruj się na użytkowniku, tym, co chce osiągnąć, i dlaczego. Nie opisz sposobu opracowywania produktu. Podaj wystarczające szczegóły, aby zespół mógł pisać zadania i przypadki testowe w celu zaimplementowania elementu.

Opis

Zapewnia wgląd w to, czy funkcja czy historia użytkownika jest wdrażana i na jakim etapie. Uzyskasz wizualny wgląd w stan elementu roboczego, który jest wdrażany w różnych środowiskach wdrożeniowych, a także szybki dostęp do każdego etapu wydania oraz każdego uruchomienia. Dostęp do tej kontroli można uzyskać z poziomu planów testów, zestawów testów i przypadków testowych.

Rejestruje wszystkie procesy tworzenia oprogramowania Git, które obsługują uzupełnianie elementu roboczego. Zazwyczaj używa się go do kierowania rozwojem Git na podstawie wymagania. To narzędzie kontrolne wspiera śledzenie, zapewniając wgląd we wszystkie gałęzie, commity, żądania ściągnięcia i kompilacje związane z elementem roboczym. Dostęp do tej kontroli można uzyskać z poziomu planów testów, zestawów testów i przypadków testowych.

Użyj tej kontrolki w planach testów, zestawach testów i przypadkach testowych, aby wyświetlić lub połączyć inne elementy robocze, takie jak wymagania i usterki, zwykle za pomocą powiązanego typu linku.

Użyj tej kontrolki w Udostępnionych krokach oraz w elementach roboczych Udostępnione parametry, aby wskazać lub połączyć je z przypadkami testowymi.

Przypadki testowe same w sobie nie są wykonywalne. Podczas dodawania przypadku testowego do zestawu testów są generowane punkty testowe. Punkt testowy to unikatowa kombinacja przypadku testowego, zestawu testów, konfiguracji i testera.

Na przykład przypadek testowy o nazwie Test funkcji logowania z dwiema konfiguracjami (Microsoft Edge i Chrome) generuje dwa punkty testowe. Każdy punkt testowy można uruchomić niezależnie, a każde wykonanie daje wynik testu. Wszystkie wykonania punktu testowego można wyświetlić w historii wykonywania. Karta Wykonywanie zawiera najnowszy wynik dla każdego punktu testowego.

Zarejestrowany wynik pojedynczego wykonania przypadku testowego w ramach przebiegu testu. Każdy wynik testu przechwytuje, czy test zakończył się powodzeniem, niepowodzeniem, czy miał inny wynik, wraz z danymi diagnostycznymi i załącznikami. Aby uzyskać szczegółowe informacje, zobacz Przeglądanie przebiegów testów.

Logiczne grupowanie wyników testów utworzonych po wykonaniu co najmniej jednego przypadku testowego. System tworzy przebieg testu podczas uruchamiania przypadków testowych na podstawie planu testowego lub potoku danych. Każdy przebieg testu przechwytuje wyniki, czas trwania, środowisko i dane diagnostyczne. Aby uzyskać szczegółowe informacje, zobacz Przeglądanie przebiegów testów.

Okno dialogowe służące do kojarzenia planów testów z pipeline'ami kompilacji lub wydań.

Okno dialogowe służące do wybierania sposobu konfigurowania wyników testów w wielu zestawach w ramach tych samych planów testów.

Pojedyncza akcja w przypadku testowym składająca się z akcji (co robi tester) i oczekiwanego wyniku (oczekiwanego zachowania). Podczas wykonywania każdy krok testu jest oznaczony jako zaliczony lub niezaliczony. Kroki testowe mogą odwoływać się do udostępnionych kroków i dołączać załączniki. Aby uzyskać szczegółowe informacje, zobacz Tworzenie przypadków testowych.

Możliwość śledzenia wyników testów w powiązaniu z wymaganiami i usterkami, z którymi są związane.

Podejście testowe, w którym osoby biorące udział w projekcie biznesowym lub użytkownicy końcowi sprawdzają, czy dostarczane funkcje spełniają wymagania klientów. W Azure Test Plans można przypisywać testerów do zestawów testów, wysyłać zaproszenia e-mail i śledzić postęp na wykresach. Użytkownicy z dostępem Stakeholder mogą uczestniczyć. Aby uzyskać szczegółowe informacje, zobacz Testowanie akceptacyjne użytkowników.