Testowanie obiektów i terminów
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Przeczytaj ten artykuł, aby poznać obiekty i terminy używane w testach ręcznych i eksploracyjnych.
Typy elementów roboczych specyficznych dla testów
Aby obsługiwać testowanie ręczne i automatyczne, należy dodawać i grupować trzy główne typy elementów roboczych specyficznych dla testu: Plany testów, Zestawy testów i Przypadki testowe. Aby umożliwić udostępnianie różnych kroków testu i parametrów testu, należy zdefiniować kroki udostępnione i parametry udostępnione. Te obiekty są przechowywane w magazynie danych śledzenia pracy jako określone typy elementów roboczych.
W poniższej tabeli opisano typy elementów roboczych używane do obsługi środowiska testowego usługi Azure DevOps. Połącz elementy robocze specyficzne dla testów przy użyciu typów linków pokazanych na poprzedniej ilustracji.
Typ elementu roboczego
Opis
Plany testów
Są używane do grupowania zestawów testów i poszczególnych przypadków testowych. Aby zdefiniować plan testu, zobacz Tworzenie planów testów i zestawów testów.
Zestaw 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 jedno lub więcej wymagań z zapytania, które następnie są połączone z zestawem testów.
- Zestawy oparte na zapytaniach: wybierz co najmniej jeden przypadek testowy, który jest następnie połączony z pakietem testów.
Napiwek
Pole Typ zestawu testów wskazuje wybrany typ pakietu. Aby dodać zestawy testów, zobacz Tworzenie planów testów i zestawów testów.
Przypadki testowe
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.
- Zautomatyzowane: przypadki testowe przeznaczone do uruchamiania w usłudze Azure Pipeline.
Napiwek
Możesz utworzyć przypadek testowy, który automatycznie łączy się z wymaganiem — scenariusz użytkownika (Agile), element listy prac produktu (Scrum), wymaganie (CMMI) lub problem (Podstawowy) — podczas tworzenia testu na tablicy. Aby uzyskać więcej informacji, zobacz Add, run, and update inline tests (Dodawanie, uruchamianie i aktualizowanie testów wbudowanych).
Kroki udostępnione
Użyj polecenia , aby udostępnić kroki między wieloma przypadkami testowym. Na przykład logowanie się i weryfikowanie kroków logowania do aplikacji to kroki, które można udostępniać w wielu przypadkach testowych. Aby dowiedzieć się, jak to zrobić, zobacz Udostępnianie kroków między przypadkami testowym.
Parametry udostępnione
Służy do określania różnych parametrów do wykonywania testu kroku testu w przypadku testowym. Aby dowiedzieć się, jak to zrobić, zobacz Powtarzanie testu przy użyciu różnych danych.
Wspólne pola dla wszystkich typów elementów roboczych specyficznych dla testu
W większości elementów roboczych są wyświetlane następujące pola i karty. Każda karta służy do śledzenia określonych informacji, takich jak 
historia, 
linki lub 
załączniki. Te trzy karty zawierają historię zmian, widok połączonych elementów roboczych oraz możliwość wyświetlania i dołączania plików.
Jedynym polem wymaganym dla wszystkich typów elementów roboczych jest Tytuł. Po zapisaniu elementu roboczego system przypisuje mu unikatowy identyfikator. Formularz wyróżnia wymagane pole w kolorze żółtym. Aby uzyskać informacje o polach związanych z testami, zobacz Query based on build and test integration fields (Wykonywanie zapytań na podstawie pól integracji kompilacji i testowania). W przypadku wszystkich innych pól zobacz Indeks pola elementu roboczego.
Pole
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. W zależności od kontekstu, w którym pracujesz, menu rozwijane zawiera tylko członków zespołu lub współautorów projektu.
Uwaga
Możesz przypisać pracę tylko jednemu użytkownikowi. Jeśli musisz przypisać pracę do więcej niż jednego użytkownika, dodaj element roboczy dla każdego użytkownika i wyróżnij pracę, którą należy wykonać według tytułu i opisu. Pole Przypisane do akceptuje tylko konta użytkowników, które zostały dodane do projektu lub zespołu.
Po utworzeniu elementu roboczego stan domyślny to pierwszy stan 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 ma zostać ukończona praca, lub pozostaw ją pustą i przypisz ją później podczas spotkania planistycznego. Aby zmienić listę rozwijaną iteracji, zobacz Definiowanie ścieżek iteracji i konfigurowanie iteracji zespołu.
Podaj wystarczającą ilość szczegółów, aby utworzyć wspólne zrozumienie 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.
Wspólne kontrolki dla wszystkich typów elementów roboczych specyficznych dla testów
Kilka kontrolek jest wyświetlanych w kilku elementach roboczych specyficznych dla testu, zgodnie z opisem w poniższej tabeli. Jeśli te kontrolki nie są interesujące, można je ukryć w układzie formularza elementu roboczego zgodnie z opisem w sekcji Dodawanie pól (proces dziedziczenia) i zarządzanie nimi.
Formant
Opis
Wdrożenie
Zapewnia wgląd w to, czy funkcja czy historia użytkownika została wdrożona i na jakim etapie. Uzyskasz wizualny wgląd w stan elementu roboczego, który jest wdrażany w różnych środowiskach wydania, a także szybki dostęp do każdego etapu wydania i uruchamiania. Ta kontrolka jest dostępna w planach testów, zestawach testów i przypadkach testowych.
Opracowywanie zawartości
Rejestruje wszystkie procesy tworzenia oprogramowania Git, które obsługują uzupełnianie elementu roboczego. Zwykle jest on używany do opracowywania usługi Git na podstawie wymagań. Ta kontrolka obsługuje możliwość śledzenia, zapewniając wgląd we wszystkie gałęzie, zatwierdzenia, żądania ściągnięcia i kompilacje związane z elementem roboczym. Ta kontrolka jest dostępna w planach testów, zestawach testów i przypadkach testowych.
Praca powiązana
Kontrolka używana w planach testów, zestawach testów i przypadkach testowych w celu wyświetlania lub łączenia z innymi elementami roboczymi, takimi jak wymagania i błędy, zwykle za pomocą typu linku Powiązane.
Przypadki testowe
Kontrolka używana w krokach udostępnionych i elementach roboczych parametrów udostępnionych w celu wskazania lub połączenia z przypadkami testowymi.
Dostosowywanie typów elementów roboczych specyficznych dla testu
W przypadku procesu dziedziczonego można dostosować plany testów, zestawy testów i przypadki testowe. W przypadku lokalnego procesu XML można dostosować wszystkie typy elementów roboczych specyficznych dla testu. Aby uzyskać więcej informacji, zobacz Dostosowywanie obiektów śledzenia pracy w celu obsługi procesów zespołu.
Uprawnienia wymagane do modyfikowania elementów roboczych
Istnieje wiele uprawnień, które kontrolują wybieranie funkcji do wyświetlania, modyfikowania lub usuwania elementów roboczych. Należą do nich te wymienione w poniższej tabeli.
Uwaga
Uprawnienie Zmień typ elementu roboczego nie ma zastosowania do elementów roboczych specyficznych dla testów. Nawet jeśli wybierzesz tę funkcję z formularza elementu roboczego, zmiana typu elementu roboczego jest niedozwolona.
Uprawnienie
Poziom
Zadanie podrzędne
Wyświetlanie przebiegów testów
Tworzenie przebiegów testów
Usuwanie przebiegów testów
Poziom projektu
Aby wyświetlić, utworzyć lub usunąć przebiegi testów, musisz mieć odpowiednie uprawnienie.
Zarządzanie konfiguracjami testów
Zarządzanie środowiskami testowymi
Poziom projektu
Zarządzanie konfiguracjami testów lub środowiskami testowymi, należy udzielić odpowiednich uprawnień.
Tworzenie definicji tagu
Poziom projektu
Dodaj nowe tagi do elementów roboczych opartych na testach.
Usuwanie i przywracanie elementów roboczych
Poziom projektu
Usuń elementy robocze specyficzne dla testu i przywróć je z Kosza.
Trwałe usuwanie elementów roboczych
Poziom projektu
Trwałe usuwanie elementów roboczych specyficznych dla testów z magazynu danych.
Wyświetlanie elementów roboczych w tym węźle
Edytowanie elementów roboczych w tym węźle
Ścieżka obszaru
Wyświetlanie lub dodawanie lub modyfikowanie planów testów, zestawów testów, przypadków testowych lub innych typów elementów roboczych opartych na testach wymaga odpowiednich uprawnień.
Zarządzanie planami testów
Ścieżka obszaru
Zmodyfikuj właściwości planu testów, takie jak ustawienia przebiegu testu i wyniku testu.
Zarządzanie planami testów
Ścieżka obszaru
Tworzenie i usuwanie zestawów testów; dodawanie i usuwanie przypadków testowych z zestawów testów; zmienianie konfiguracji testów skojarzonych z zestawami testów; i zmodyfikuj hierarchię zestawu testów (przenieś pakiet testów).
Aby uzyskać więcej informacji na temat ustawiania tych uprawnień, zobacz Ustawianie uprawnień i dostępu na potrzeby testowania i zmieniania uprawnień na poziomie projektu.
Eksportowanie, importowanie i zbiorcze aktualizowanie elementów roboczych specyficznych dla testu
Podobnie jak w przypadku innych elementów roboczych, można zbiorczo edytować elementy robocze specyficzne dla testów. Aby uzyskać więcej informacji, zobacz następujące artykuły:
Terminy testowe
W poniższej tabeli opisano kilka terminów używanych w testach ręcznych i eksploracyjnych.
Termin
Definicja
Konfiguracja
Określa unikatowe środowisko używane do testowania aplikacji lub kodu. Aby zdefiniować konfigurację testową, najpierw zdefiniuj zmienne konfiguracji, a następnie zdefiniuj konfigurację testu. Aby uzyskać szczegółowe informacje, zobacz Testowanie różnych konfiguracji.
Zmienna konfiguracji
Określa jeden aspekt środowiska testowego, taki jak system operacyjny, moc obliczeniowa, przeglądarka internetowa lub inne odmiany. Aby uzyskać szczegółowe informacje, zobacz Testowanie różnych konfiguracji.
Wynik
Wynik punktu testowego oznaczony przez testera podczas wykonywania testu. Prawidłowe opcje to:
- Aktywne (nieokreślony)
- Test próbny
- Test niepowodzenia
- Test blokowy
- Nie dotyczy
Aby uzyskać więcej informacji, zobacz Repeat a test with different data (Powtarzanie testu przy użyciu różnych danych). Należy pamiętać, że wyniki testu potoku różnią się w sposób opisany w temacie About pipeline tests (Informacje o testach potoku).
Punkty testowe
Przypadki testowe same w sobie nie są wykonywalne. Po dodaniu przypadku testowego do zestawu testów są generowane punkty testowe. Punkt testu to unikatowa kombinacja przypadku testowego, zestawu testów, konfiguracji i testera. Jeśli na przykład masz przypadek testowy o nazwie Testowanie funkcji logowania i dodasz dwie konfiguracje dla przeglądarek Edge i Chrome , masz dwa punkty testowe. Można wykonać lub uruchomić każdy z tych punktów testowych. Podczas wykonywania generowane są wyniki testów. Za pomocą widoku wyników testu lub historii wykonywania można zobaczyć wszystkie wykonania punktu testowego. Najnowsze wykonanie punktu testowego jest widoczne na karcie Wykonywanie.
Ustawienia przebiegu testowego
Okno dialogowe służące do kojarzenia planów testów z potokami kompilacji lub wydania.
Ustawienia wyników testu
Okno dialogowe służące do wybierania sposobu konfigurowania wyników testów w wielu zestawach w ramach tych samych planów testów.
Identyfikowalność
Możliwość śledzenia wyników testów przy użyciu wymagań i usterek, z którymi są połączone.