Tworzenie zapytania na podstawie pól integracji kompilacji i testowania

  • Artykuł

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 WordsIs 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 InIn, , In Group, , Not In GroupWas 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.

Wyświetlanie listy usterek i przypadków testowych, które je testują

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:

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

  1. Nie dostosuj listy wyboru dla tych pól. System akceptuje tylko te wartości na liście.
  2. GLOBALLIST Dodając element do FIELD 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

  1. 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="&lt;None&gt;" />
        </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="&lt;None&gt;" />
        </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="&lt;None&gt;" />
        </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.