Tworzenie zapytania na podstawie pól integracji kompilacji i testowania
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Pola elementów roboczych, które obsługują integrację kompilacji i testowania, obsługują następujące akcje:
- Kojarzenie usterek z kompilacjami, w których zostały znalezione lub naprawione
- Wykonywanie zapytań o błędy skojarzone z kompilacją
- Oznaczanie przypadków testowych jako ręcznych lub automatycznych i przechowywanie informacji w celu obsługi zautomatyzowanych przypadków testowych
- W przypadku przypadków testowych i kroków udostępnionych zdefiniuj kroki akcji i weryfikacji oraz dane używane do uruchamiania testów.
Obsługiwane operatory i makra
Większość pól integracji kompilacji i testowania ma typ danych String, PlainText lub HTML. Klauzule zapytania określające pole tekstowe lub pole tekstu sformatowanego mogą używać operatorów i makr wymienionych w poniższej tabeli.
Typ danych
Obsługiwane operatory i makra
Tekst sformatowany (HTML) i
Ciągi tekstowe wielowierszowe (PlainText)
Contains Words
, , Does Not Contain Words
Is Empty
, , Is Not Empty
.
Operatory Is Empty
i Is Not Empty
są obsługiwane w przypadku usługi Azure DevOps Server 2019 RC2 i nowszych wersji.
Pojedynczy tekst (ciąg)
= , <> , > , < , >= , <= , =[Field], <>[Field], >[Field], <[Field], >=[Field], <=[Field]
, Contains
, , Does Not Contain
, Not In
In
, , In Group
, , Not In Group
Was Ever
Makra: [Any]
, prawidłowe z polem Typ elementu roboczego i @Project
, prawidłowe w polu Projekt zespołowy. System automatycznie domyślnie filtruje na podstawie bieżącego projektu. Aby uzyskać więcej informacji, zobacz Wykonywanie zapytań między projektami.
Przydatne filtry
Filtruj dla
Uwzględnij te klauzule zapytania
Zautomatyzowane przypadki testowe
Work Item Type = Test Case
And Automation Status = Automated
Zestawy testów oparte na zapytaniach
Work Item Type = Test Suite
And Test Suite Type = Query Based
Zestawy testów oparte na wymaganiach
Work Item Type = Test Suite
And Test Suite Type = Requirement Based
Wyświetlanie listy usterek i przypadków testowych, które je testują
Otwórz nowe zapytanie, ustaw typ zapytania na Elementy robocze i linki bezpośrednie. Filtruj pod kątem usterek na najwyższym poziomie i dodaj filtr Dla przypadków testowych w filtrze połączonych elementów roboczych.
Uwaga
Nie można utworzyć zapytania, które pokazuje hierarchiczny widok planów testów, zestawów testów i przypadków testowych. Te elementy nie są połączone razem przy użyciu typów łączy nadrzędny-podrzędny. Hierarchię można wyświetlić na stronie Test Test Test Plans (Plany testów).>
Kompilowanie i testowanie pól danych
W poniższej tabeli opisano pola zdefiniowane w co najmniej jednej testowej sieci WIT. Aby uzyskać informacje o typach danych i atrybutach pól, zobacz Pola i atrybuty elementu roboczego.
Aby dostosować pole lub listę wyboru, zobacz Dodawanie lub modyfikowanie pola w celu obsługi zapytań, raportów i przepływu pracy.
Nazwa pola
Opis
Typ elementu roboczego
Stan automatyzacji 1
Stan przypadku testowego. Można określić następujące wartości:
- Zautomatyzowane
- Nieautomazowane
- Rozmyślny
Aby uruchomić testy automatyczne, zobacz Uruchamianie testów automatycznych z planów testów.
Nazwa odwołania=Microsoft.VSTS.TCM.AutomationStatus, Typ danych=Ciąg
Przypadek testowy
Znaleziono w 2
Numer kompilacji produktu, znany również jako poprawka, w której znaleziono usterkę.
Nazwa odwołania=Microsoft.VSTS.Build.FoundIn, Typ danych=Ciąg
Uwaga
Możesz również użyć typu linku Znalezione w kompilacji , aby połączyć element roboczy z kompilacją. Ten typ linku jest dostępny w usłudze Azure DevOps i działa tylko z bieżącymi procesami kompilacji (a nie kompilacjami XAML).
Usterka
Kompilacja integracji 2
Numer kompilacji produktu, który zawiera kod lub naprawia usterkę.
Nazwa odwołania=Microsoft.VSTS.Build.IntegrationBuild, Typ danych=Ciąg
Uwaga
Możesz również użyć typu linku Zintegrowane w kompilacji , aby połączyć element roboczy z kompilacją. Ten typ linku jest dostępny w usłudze Azure DevOps i działa tylko z bieżącymi procesami kompilacji (a nie kompilacjami XAML).
wszystkie
Problem
Wskazuje, że kroki udostępnione są skojarzone z oczekiwanym wynikiem. Dozwolone wartości to Tak i Nie. Nazwa odwołania=Microsoft.VSTS.Common.Issue, Typ danych=Ciąg
Kroki udostępnione
Parametry
Zawiera parametry do użycia podczas uruchamiania testu ręcznego.
Microsoft.VSTS.TCM.Parameters, Typ danych=HTML
Parametry udostępnione, kroki udostępnione, przypadek testowy
Kroki
Czynności i kroki weryfikacji wymagane do uruchomienia testu. Microsoft.VSTS.TCM.Steps, Data type=HTML
Kroki udostępnione, przypadek testowy
Informacje o systemie
Informacje o konfiguracji oprogramowania i systemu, które są istotne dla testu.
Microsoft.VSTS.TCM.SystemInfo, Typ danych=HTML
Usterka, odpowiedź na opinie
Kroki odtwarzania (lub kroki do odtworzenia)
Kroki wymagane do odtworzenia nieoczekiwanego zachowania. Przechwyć wystarczającą ilość informacji, aby inni członkowie zespołu mogli zrozumieć pełny wpływ problemu i ustalić, czy usterka została usunięta. Obejmuje to akcje podjęte w celu znalezienia lub odtworzenia usterki i oczekiwanego zachowania. Nazwa odwołania=Microsoft.VSTS.TCM.ReproSteps, Typ danych=HTML
Usterka
Test Suite Type 1 (Typ zestawu testów 1)
Kategoria zestawu testów. Dozwolone wartości to:
- Na podstawie zapytań: użyj polecenia , aby zgrupować razem przypadki testowe, które mają określoną charakterystykę — na przykład wszystkie testy, które mają priorytet =1. Pakiet automatycznie uwzględnia każdy przypadek testowy zwracany przez zdefiniowane zapytanie.
- Na podstawie wymagań: służy do grupowania przypadków testowych zaprojektowanych do śledzenia stanu testowego elementów listy prac. Każdy przypadek testowy dodany do zestawu testów opartych na wymaganiach jest automatycznie połączony z elementem listy prac.
- Statyczne: służy do grupowania przypadków testowych z dowolnymi cechami lub zestawami testów.
Aby uzyskać więcej informacji, zobacz Tworzenie planu testu.
Nazwa odwołania=Microsoft.VSTS.TCM.TestSuiteType, Typ danych=Ciąg
Zestaw testów
Uwaga
- Nie dostosuj listy wyboru dla tych pól. System akceptuje tylko te wartości na liście.
GLOBALLIST
Dodając element doFIELD
definicji, możesz podać menu rozwijane kompilacji, które użytkownicy mogą wybrać. Aby dowiedzieć się, jak to zrobić, zobacz Kompilacje i globalna lista auto-population w dalszej części tego artykułu.
Inne pola
Następujące pola nie są wyświetlane w formularzach elementów roboczych, ale te pola są śledzone w przypadku przypadków testowych lub zestawów testów. Niektóre z tych pól umożliwiają filtrowanie zapytań i tworzenie raportów. (Żadne z tych pól nie są dodawane do magazynu danych ani indeksowane).
Nazwa pola
Opis
Typ elementu roboczego
Magazyn testów automatycznych
Zestaw zawierający test, który automatyzuje przypadek testowy.
Nazwa odwołania=Microsoft.VSTS.TCM.AutomatedTestStorage, Typ danych=Ciąg
Przypadek testowy
Typ testu zautomatyzowanego
Typ testu, który automatyzuje przypadek testowy.
Nazwa odwołania=Microsoft.VSTS.TCM.AutomatedTestType, Typ danych=Ciąg
Przypadek testowy
AutomatedTestId
Identyfikator testu, który automatyzuje przypadek testowy.
Nazwa odwołania=Microsoft.VSTS.TCM.AutomatedTestId, Typ danych=Ciąg
Przypadek testowy
AutomatedTestName
Nazwa testu używanego do automatyzacji przypadku testowego.
Nazwa odwołania=Microsoft.VSTS.TCM.AutomatedTestName, Typ danych=Ciąg
Przypadek testowy
LocalDataSource
Lokalne źródło danych, które obsługuje test.
Nazwa odwołania=Microsoft.VSTS.TCM.LocalDataSource, Typ danych=HTML
Przypadek testowy
Tekst zapytania
Pole używane do przechwytywania zapytania zdefiniowanego dla typu pakietu opartego na zapytaniach.
Nazwa odwołania=Microsoft.VSTS.TCM.QueryText, Typ danych=Zwykły tekst
Zestaw testów
Inspekcja pakietu testów
Śledzi inne operacje uruchamiane podczas modyfikowania zestawu testów, na przykład: dodawanie testów do zestawu testów lub zmienianie konfiguracji. To pole można wyświetlić za pomocą karty Historia lub oddzielnego zapytania. Istnieje połączony widok historii, w tym zmiany wykonywane w polu elementów roboczych i zmiany wynikające z powiązanych artefaktów, takich jak punkty testów i konfiguracje.
Nazwa odwołania=Microsoft.VSTS.TCM.TestSuiteAudit, Typ danych=Zwykły tekst
Zestaw testów
Typ zestawu testów o identyfikatorze 1
Przypisana przez system wartość odpowiadająca kategorii zestawu testów i dotyczy tylko zestawów testów. Przypisane wartości to:
1 (statyczne)
2 (oparte na zapytaniach)
3 (Oparte na wymaganiach)
Nazwa odwołania=Microsoft.VSTS.TCM.TestSuiteTypeId, Typ danych=Integer
Zestaw testów
Uwaga
- Nie dostosuj listy wyboru dla tych pól. System akceptuje tylko te wartości na liście.
Pola integrujące się z kompilacją Team Foundation
Team Foundation Build to lokalny system kompilacji, którego można używać z usługami Azure DevOps Server i TFS. Proces kompilacji można skonfigurować przy użyciu kompilacji Team Foundation, a kompilacja Team Foundation Build może generować elementy robocze, gdy kompilacja zakończy się niepowodzeniem. Może również dodawać informacje o kompilacji do elementów roboczych, które zostały rozwiązane w określonej kompilacji. Aby to działało, kompilacja Team Foundation wymaga dodania następujących dwóch pól do definicji typu elementu roboczego: Found In i Integration Build.
Znalezione w polach kompilacji i Zintegrowane w kompilacji są definiowane dla błędów w procesach domyślnych. Te pola kojarzą błędy z kompilacjami, w których zostały znalezione lub naprawione.
Poniższy fragment kodu umożliwia dodanie tych pól do definicji funkcji WIT.
<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
<HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
<SUGGESTEDVALUES>
<LISTITEM value="<None>" />
</SUGGESTEDVALUES>
</FIELD>
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
<HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
<SUGGESTEDVALUES>
<LISTITEM value="<None>" />
</SUGGESTEDVALUES>
</FIELD>
Gdy pole Znalezione w znajduje się w definicji funkcji WIT, kompilacja team foundation tworzy element roboczy, gdy kompilacja kończy się niepowodzeniem, i ustawia pole Found In (Znalezione w) na numer kompilacji, która zakończyła się niepowodzeniem. Jeśli brakuje pola Znalezione w, kompilacja team foundation nie tworzy elementu roboczego dla kompilacji zakończonej niepowodzeniem, a wszystko inne działa zgodnie z oczekiwaniami.
Gdy pole Kompilacja integracji znajduje się w definicji funkcji WIT, kompilacja team foundation identyfikuje elementy robocze, które zostały rozwiązane z każdą kompilacją, a następnie aktualizuje te elementy robocze, aby ustawić numer kompilacji, w którym zostały one rozpoznane w polu Kompilacja integracji. Jeśli brakuje pola Kompilacja integracji, kompilacja team foundation nie przechowuje numeru kompilacji w elementach roboczych, a wszystko inne działa zgodnie z oczekiwaniami.
Kompilacje i autopopulation listy globalnej
Podczas pierwszej kolejki kompilacji dla projektu przy użyciu kompilacji Team Foundation Build program TFS automatycznie dodaje listę globalną z etykietą Build — ProjectName. Za każdym razem, gdy kompilacja jest uruchamiana, lista LISTITEM jest dodawana do tej listy globalnej o nazwie kompilacji.
Dodając element GLOBALLIST do definicji FIELD, możesz udostępnić menu rozwijane kompilacji, które użytkownicy mogą wybrać. Na przykład:
<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
<HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
<SUGGESTEDVALUES>
<LISTITEM value="<None>" />
</SUGGESTEDVALUES>
<SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
<GLOBALLIST name="Builds - TeamProjectName" />
</SUGGESTEDVALUES>
</FIELD>
Pola integrujące się z planami testów
W przypadku planów testów można zautomatyzować tworzenie usterki lub innego typu elementu roboczego, gdy test zakończy się niepowodzeniem. Aby uzyskać więcej informacji, zobacz Dodawanie wyników do istniejących usterek za pomocą testowania eksploracyjnego.
Po utworzeniu elementu roboczego w ten sposób informacje o systemie i kroki odtwarzania usterki są przechwytywane w polach Informacje o systemie i Kroki odtwarzania.
Możesz dodać te pola do typów elementów roboczych tworzonych do śledzenia wad przy użyciu następującego fragmentu kodu.
<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" />
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML" />
Pola integrujące się z Kontrola wersji serwera Team Foundation
Jedna z funkcji dostępnych w kontroli wersji programu Team Foundation (TFVC) umożliwia kojarzenie lub rozwiązywanie elementów roboczych podczas ewidencjonowania kodu. Być może podczas wprowadzania zmiany kodu pracujesz nad określonym elementem roboczym i możesz ustawić to skojarzenie z poziomu okna ewidencjonowanie kontroli źródła po zakończeniu pracy nad kodem.
Możliwość kontrolowania wersji programu Team Foundation do rozpoznawania elementu roboczego wymaga, aby elementy robocze zawierały określoną akcję. Następnie system kontroli źródła wysyła zapytanie do śledzenia elementów roboczych, aby określić, czy element roboczy obsługuje akcję, a jeśli obsługuje to działanie, wysyła również zapytania dotyczące stanów źródłowych i docelowych przejścia. Jeśli akcja zostanie znaleziona, system kontroli źródła może przenieść element roboczy zgodnie z ustawionym przejściem po zaewidencjonowaniu kodu.
Uwaga
W przypadku korzystania z akcji Checkin należy ustawić odpowiednie wartości z i na stany, aby odzwierciedlić żądany stan.
Aby uzyskać więcej informacji na temat akcji, zobacz Automatyzowanie przypisań pól na podstawie stanu, przejścia lub przyczyny.