Microsoft AZ-400: Strategia testowania i inżynieria jakości — Przewodnik do nauki

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Część Microsoft DevOps Engineer Expert AZ-400 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Strategia testowania i inżynieria jakości w Azure DevOps polegają na budowaniu zaufania do oprogramowania poprzez szybkie, deterministyczne informacje zwrotne w całym cyklu dostarczania, przy jednoczesnym wykorzystaniu natywnych możliwości platformy do egzekwowania bramek jakości i śledzenia. Skuteczne strategie łączą zrównoważoną piramidę testów, wczesną i ciągłą walidację (TDD/BDD), solidną automatyzację w potokach, zdyscyplinowane zarządzanie danymi testowymi oraz zaawansowane techniki, takie jak testy obciążeniowe, chaos engineering, sprawdzanie dostępności i wdrożenia wymuszające określone pokrycie kodu. Azure Test Plans, Azure Pipelines, Azure Load Testing i Azure Chaos Studio dostarczają narzędzi do wdrażania tych praktyk na dużą skalę.

Podstawy strategii testowania

Pragmatyczna piramida testów redukuje ryzyko dzięki szybkim, tanim testom u podstawy i mniejszej liczbie testów o wysokiej wierności na szczycie:

Testy jednostkowe weryfikują izolowaną logikę i powinny dominować w zestawie testów. Należy dążyć do szybkiego wykonania i wysokiego determinizmu. Dla większości produktów należy ustalić docelowe pokrycie kodu testami jednostkowymi na poziomie 70–90% dla krytycznych usług, pamiętając, że pokrycie jest metryką pośrednią, a nie gwarancją jakości.
Testy integracyjne weryfikują kontrakty międzykomponentowe (np. z bazą danych, systemem wiadomości, usługami zewnętrznymi) przy użyciu realistycznych granic i efemerycznych zależności. Uruchamiaj je równolegle, jeśli to możliwe, w skonteneryzowanych lub izolowanych środowiskach (sandbox) i dąż do pokrycia 30–60% krytycznych ścieżek kodu w scenariuszach na poziomie integracji.
Testy end-to-end (E2E) weryfikują ścieżki użytkownika w obrębie całego stosu technologicznego. Powinny być one minimalne i skoncentrowane na najbardziej wartościowych ścieżkach (zazwyczaj 5–15% zestawu testów), aby uniknąć niestabilnych i powolnych informacji zwrotnych.

Praktyki testowania „shift-left” (przesunięcia w lewo) pozwalają wcześniej redukować liczbę defektów:

Test-Driven Development (TDD) wymusza cykle red–green–refactor, wpływa na projektowanie i zwiększa pewność na poziomie jednostkowym. Aby TDD było praktyczne, należy zapewnić inżynierom szybkie, lokalne narzędzia do uruchamiania testów oraz utrzymywać testy jako hermetyczne i deterministyczne.
Behavior-Driven Development (BDD) opisuje intencje za pomocą wspólnego słownictwa, używając języka Gherkin. Zespoły .NET mogą używać SpecFlow; zespoły Java i JavaScript często korzystają z Cucumber. Połącz scenariusze BDD z kryteriami akceptacji w Azure Boards i publikuj ich wyniki w Azure Test Plans w celu zapewnienia śledzenia.

Zarządzanie danymi testowymi eliminuje niedeterminizm:

Dane syntetyczne dostarczają deterministycznych, bezpiecznych pod względem prywatności zestawów danych do testów jednostkowych i integracyjnych. Generuj je za pomocą bibliotek typu „faker” specyficznych dla danego języka oraz wartości początkowych (seed), które umożliwiają odtwarzalność.
Maskowanie danych umożliwia tworzenie realistycznych zestawów danych testowych bez ujawniania informacji osobistych lub wrażliwych. Używaj narzędzi do maskowania baz danych lub potoków danych, które stosują nieodwracalne transformacje. W przypadku Azure SQL Database eksportuj migawki do subskrypcji przejściowej (staging) i zastosuj maskowanie przed użyciem ich w testach.
Równoważność środowisk (environment parity) zapewnia, że wyniki testów są miarodajne. Udostępniaj środowiska testowe za pomocą Infrastructure as Code (ARM/Bicep/Terraform), aby komponenty systemu, konfiguracja i topologia sieci jak najdokładniej odpowiadały środowisku produkcyjnemu. Utrzymuj migracje schematów w synchronizacji między środowiskami.

Wykrywanie i zarządzanie niestabilnymi testami (flaky tests) chroni pętle informacji zwrotnej:

Przyczyny obejmują problemy z synchronizacją (timing races), zależności zewnętrzne, powiązanie z kolejnością testów i rywalizację o zasoby. Użyj zadania Visual Studio Test w Azure Pipelines z włączoną opcją rerunFailedTests, aby zredukować przejściowy szum informacyjny podczas badania problemu.
Umieszczaj niedeterministyczne testy w kwarantannie, aby utrzymać zielone potoki, oznaczając je i izolując w osobnym zestawie, który jest uruchamiany i raportuje wyniki, ale nie powoduje niepowodzenia kompilacji. Śledź dług związany z kwarantanną za pomocą elementów roboczych w Azure Boards.
Analiza przyczyn źródłowych wymaga instrumentacji. Zbieraj logi, metryki czasowe i szczegóły środowiska podczas uruchomień; odtwarzaj problem lokalnie z tymi samymi wartościami początkowymi (seed) i zależnościami; eliminuj poleganie na niemockowanych zegarach systemowych, sieci i systemie plików; i naprawiaj niedeterminizm u źródła.

Możliwości Azure DevOps i testowania w Azure

Azure Test Plans zapewnia pełnoprawne testowanie manualne i eksploracyjne, a także identyfikowalność:

Przypadki testowe definiują kroki, oczekiwane rezultaty i parametry; współdzielone kroki i sparametryzowane przypadki testowe redukują duplikację. Zestawy oparte na wymaganiach (requirement-based suites) przypisują przypadki do elementów Product Backlogu lub historyjek użytkownika, podczas gdy zestawy statyczne i oparte na zapytaniach grupują testy do wykonania.
Uruchomienia testów (test runs) przypisują zestawy i konfiguracje do testerów, rejestrują wyniki i czasy trwania oraz zbierają dane diagnostyczne. Szczegółowe zgłaszanie błędów obejmuje zrzuty ekranu, wideo, dane środowiskowe i logi akcji.
Testowanie eksploracyjne wykorzystuje rozszerzenie przeglądarki Test & Feedback do przechwytywania kart eksploracji, notatek z sesji i artefaktów podczas eksploracji ad-hoc. Połącz znaleziska z elementami pracy (work items) i analizuj pokrycie wymagań oraz sesji testowych.

Testowanie zautomatyzowane integruje się bezpośrednio z potokami (pipelines):

Użyj zadania Visual Studio Test (VsTest), aby uruchamiać testy MSTest, NUnit i xUnit oraz publikować wyniki w formacie TRX. W przypadku .NET powszechne jest użycie polecenia dotnet test z odpowiednim loggerem (trx, junit).
Dla Javy uruchamiaj testy JUnit za pomocą Maven lub Gradle i publikuj wyniki w formacie JUnit XML za pomocą zadania Publish Test Results. Dla JavaScriptu skonfiguruj narzędzia uruchomieniowe (Jest, Mocha) tak, aby generowały wyniki w formacie JUnit XML.
Zadanie Publish Test Results konsoliduje wyniki i trendy z wielu uruchomień. Standaryzuj formaty wyników (TRX lub JUnit XML), aby ujednolicić raportowanie i umożliwić analitykę niestabilnych testów.
Powiąż zautomatyzowane uruchomienia testów z Azure Test Plans, mapując przypadki testowe na zautomatyzowane metody testowe, co zapewnia pełną identyfikowalność od wymagania, przez wykonanie, aż po defekt.

Pokrycie kodu (code coverage) to mierzalna bariera jakościowa:

Zbieraj dane o pokryciu za pomocą Coverlet (dla .NET), JaCoCo (dla Javy) lub Cobertura/lcov (dla JavaScriptu). Konwertuj je do formatów rozumianych przez Azure DevOps i publikuj za pomocą zadania Publish Code Coverage Results, aby uwidocznić trendy i różnice.
Wymuszaj minimalne progi na etapie budowania. W przypadku .NET użyj przełączników progowych Coverlet, aby zakończyć budowanie niepowodzeniem, jeśli pokrycie linii lub gałęzi spadnie poniżej ustalonej polityki. Alternatywnie, użyj rozszerzenia Build Quality Checks, aby wymuszać polityki oparte na pokryciu i trendach.
Wdrożenia bramkowane pokryciem kodu (coverage-gated deployments) zapobiegają przejściu do kolejnego etapu, gdy spada jakość. W YAML, zakończ etap jakości niepowodzeniem, jeśli pokrycie jest poniżej celu; w przypadku klasycznych wydań (classic releases) użyj bramek (gates), które wywołują Azure Function lub sprawdzanie REST w celu walidacji zmierzonego pokrycia przed promocją.

Wydajność, Chaos i Odporność

Testy obciążeniowe i wydajnościowe weryfikują wymagania niefunkcjonalne wcześnie i w sposób ciągły:

Azure Load Testing organizuje obciążenie na dużą skalę w oparciu o JMeter, jednocześnie korelując telemetrię backendu z Application Insights. Importuj plany testów JMX, ustawiaj kryteria zaliczenia/niezaliczenia (np. latencja p95, wskaźnik błędów) i prezentuj wyniki w potokach. Użyj bramki Azure Monitor lub kontroli środowiska, aby zablokować przejście do kolejnego etapu, gdy wskaźniki bazowe nie są spełnione.
Apache JMeter pozostaje wszechstronnym wyborem do testów obciążeniowych na poziomie protokołu. Utrzymuj grupy wątków (thread groups) i asercje sparametryzowane na potrzeby CI. Przechowuj pliki JMX i zbiory danych CSV razem z kodem, wersjonując je wraz ze scenariuszami.
k6 umożliwia przyjazne dla deweloperów testy obciążeniowe jako kod. Uruchamiaj k6 w Azure Pipelines za pomocą kontenera lub środowiska Node, przechwytuj wyniki i eksportuj je do formatu JUnit lub JSON w celu publikacji. Używaj wyrażeń progowych w skryptach k6, aby deterministycznie kończyć uruchomienia niepowodzeniem.
Zarządzanie linią bazową jest kluczowe. Śledź trendy latencji, przepustowości i wykorzystania zasobów dla każdego środowiska. Ustalaj cele poziomu usług (SLO) i upewnij się, że testy są uruchamiane przy reprezentatywnych wolumenach danych i konfiguracjach.

Inżynieria chaosu (chaos engineering) weryfikuje odporność na awarie:

Azure Chaos Studio wstrzykuje błędy w zasobach Azure z kontrolowanym promieniem rażenia i zabezpieczeniami. Typy eksperymentów obejmują obciążenie procesora/pamięci na maszynach wirtualnych, opóźnienie sieciowe/czarną dziurę, zabijanie procesów i dławienie usług (throttling).
Uruchamiaj eksperymenty najpierw w środowiskach przedprodukcyjnych i instrumentuj je za pomocą Application Insights oraz Azure Monitor, aby przechwytywać tryby awarii, budżety błędów i zachowanie automatycznego odzyskiwania.
Walidacja odporności łączy chaos z sondami kondycji (health probes) i transakcjami syntetycznymi, aby upewnić się, że krytyczne ścieżki użytkownika pozostają dostępne lub ulegają łagodnej degradacji. Promuj wdrożenie do następnego etapu tylko wtedy, gdy hipotezy dotyczące odporności zostaną potwierdzone, a alerty zadziałają zgodnie z projektem.

Dostępność, Zgodność i Ład

Dostępność i zgodność to fundamentalne aspekty jakości:

Zapewnij zgodność z WCAG 2.1 AA jako minimum dla publicznie dostępnych aplikacji i interfejsów. Przekładaj wymagania na kryteria akceptacji w Azure Boards i Azure Test Plans, tworząc dedykowane przypadki testowe dostępności.
Automatyzuj kontrole za pomocą axe-core zintegrowanego z frameworkami do testów UI, takimi jak Playwright, Cypress czy Selenium. Przerywaj buildy w przypadku wykrycia krytycznych naruszeń i publikuj raporty dostępności jako artefakty pipeline’u.
Uzupełniaj automatyzację o audyty manualne (nawigacja za pomocą klawiatury, obsługa czytników ekranu, kontrast kolorów w dynamicznych kontekstach) i rejestruj wyniki podczas sesji eksploracyjnych za pomocą rozszerzenia Test & Feedback.
Zarządzanie zgodnością i jakością w Azure Pipelines wykorzystuje kontrole środowiska i bramki (gates). W celu weryfikacji wydajności i dostępności, przed wdrożeniem odpytuj Azure Monitor lub Azure Load Testing o wartości bazowe. Aby kontrolować pokrycie kodu lub dostępność, wywołaj funkcję lub REST API, które przeanalizuje opublikowane raporty i zwróci wynik pass/fail. W ten sposób jakość niefunkcjonalna staje się warunkiem wstępnym wydania, a nie kwestią drugorzędną.

Publikowanie wyników testów i analityka zamykają pętlę informacji zwrotnej:

Standaryzuj formaty wyników i raporty pokrycia, aby zasilać Test Analytics, śledzić trendy wskaźników zdawalności i automatycznie wykrywać niestabilne testy (flaky tests).
Używaj polityk kompilacji (build policies) i zabezpieczeń gałęzi (branch protections), aby wymagać pomyślnego przejścia testów i odpowiedniego pokrycia kodu przed scaleniem. Utrzymuj szybki feedback; zrównoleglaj etapy testowe, dziel duże zestawy testów (sharding) i buforuj zależności, aby skrócić czas cyklu.

Praktyczny Scenariusz Problemu

Firma Adobe modernizuje platformę do przetwarzania dokumentów, przekształcając ją w mikroserwisy na platformie Azure. Kierownictwo techniczne wymaga szybszego tempa wydań bez regresji, weryfikowalnych poziomów bazowych wydajności, odporności na regionalne awarie sieci oraz zgodności z WCAG 2.1 AA. Obecne pipeline’y borykają się z niestabilnymi testami E2E i niespójnymi danymi testowymi.

Ustanów piramidę testów i praktyki “shift-left”

Zastosuj TDD dla kluczowych bibliotek i usług, aby stworzyć dużą, deterministyczną bazę testów jednostkowych, używając NUnit i xUnit dla komponentów .NET oraz JUnit dla Javy. Zastosuj BDD z SpecFlow i Cucumber, aby uchwycić międzyzespołowe kryteria akceptacji jako wykonywalne specyfikacje. Zapewnia to szybki feedback i wspólne zrozumienie.

Zautomatyzuj testy i publikuj wyniki w Azure Pipelines

Użyj VsTest dla .NET oraz Maven/Gradle dla Javy do uruchamiania testów jednostkowych i integracyjnych. Publikuj wyniki za pomocą zadania Publish Test Results i pokrycie kodu za pomocą Publish Code Coverage Results, aby scentralizować raportowanie i umożliwić analizę niestabilnych testów. Wbudowane zadania zapewniają ścisłą integrację z Azure DevOps i ograniczają potrzebę tworzenia niestandardowych narzędzi.

Wymuszaj progi pokrycia kodu i stosuj bramki na wdrożeniach

Skonfiguruj progi dla Coverlet i JaCoCo, aby przerywać buildy, jeśli pokrycie spadnie poniżej 80% dla linii i 60% dla gałęzi kodu w krytycznych usługach. Dodaj kontrolę wydania (release check), która wywołuje Azure Function w celu odczytania najnowszego artefaktu pokrycia i zwrócenia wyniku pass/fail, co zapobiega wdrożeniu, gdy pokrycie jest poniżej polityki. To formalizuje bramki jakości bez interwencji człowieka.

Zaimplementuj zarządzanie danymi testowymi dla determinizmu

Generuj syntetyczne zbiory danych dla testów jednostkowych i integracyjnych za pomocą bibliotek typu “faker”. Dla testów systemowych klonuj zamaskowane kopie baz danych Azure SQL za pomocą zautomatyzowanego pipeline’u wykorzystującego Data Factory do stosowania nieodwracalnego maskowania. Prowizjonuj środowiska za pomocą Bicep, aby zapewnić ich zgodność (parity). Eliminuje to ryzyko naruszenia prywatności i niestabilność testów związaną z danymi.

Ograniczaj i eliminuj niestabilne testy

Włącz opcję rerunFailedTests w VsTest, aby złagodzić przejściowe błędy, i oznaczaj niestabilne specyfikacje znacznikiem kwarantanny, który wyklucza je z zestawu blokującego wydanie, ale nadal je uruchamia i raportuje. Twórz elementy pracy w Azure Boards dla każdego testu objętego kwarantanną. Analizuj przyczyny źródłowe, zbierając logi czasowe i sieciowe oraz usuwając niedeterministyczne oczekiwania. Utrzymuje to niezawodność pipeline’ów, jednocześnie prowadząc do trwałych napraw.

Weryfikuj wydajność za pomocą Azure Load Testing i k6

Modeluj kluczowe ścieżki użytkownika jako plany JMeter i uruchamiaj je w Azure Load Testing po wdrożeniu na środowisko przejściowe (staging), z kryteriami pass/fail opartymi na opóźnieniu p95 i wskaźnikach błędów. Dla testów na poziomie API wykonywanych przez deweloperów, uruchamiaj skrypty k6 w CI z wbudowanymi progami. Dodaj bramkę Azure Monitor, aby zablokować wdrożenie na produkcję, jeśli poziomy bazowe na stagingu nie są spełnione. Narzędzia te zapewniają skalowalne, mierzalne egzekwowanie wydajności, zgodne z koncepcją bramek w Q&A.

Udowodnij odporność za pomocą Azure Chaos Studio

Projektuj eksperymenty, które wstrzykują opóźnienia sieciowe i obciążenie CPU na wybrane mikroserwisy na środowisku staging, podczas gdy Application Insights śledzi budżety błędów i czas odzyskiwania. Wymagaj, aby wszystkie eksperymenty odpornościowe spełniały SLO przed promocją do następnego etapu. Mechanizmy kontroli w Chaos Studio są zgodne z potrzebą Adobe w zakresie kontrolowanego promienia rażenia (blast radius) i audytowalnych eksperymentów.

Zapewnij dostępność i zgodność

Zintegruj axe-core z testami UI w Playwright, aby automatycznie wykrywać naruszenia WCAG 2.1 AA na kluczowych ekranach. Publikuj raporty naruszeń jako artefakty buildu i przerywaj proces w przypadku krytycznych problemów. Planuj eksploracyjne sesje dostępności z użyciem Azure Test Plans i rozszerzenia Test & Feedback w celu manualnej weryfikacji. Łączy to zautomatyzowane pokrycie z weryfikacją skoncentrowaną na człowieku.

Zapewnij identyfikowalność i analitykę

Łącz zautomatyzowane testy z Azure Test Plans tam, gdzie to stosowne, dopasowuj zestawy testów do wymagań i używaj Test Analytics do śledzenia trendów wskaźników zdawalności, identyfikowania niestabilnych testów i skupiania działań naprawczych. Umożliwia to kierownictwu szybki wgląd w trendy jakości i gotowość do wydania.

Każdy z tych wyborów kładzie nacisk na natywne usługi Azure DevOps i Azure w celu zapewnienia najlepszej integracji, ładu poprzez kontrole środowiska i bramki oraz zrównoważonej strategii testowania, która optymalizuje szybkość informacji zwrotnej, niezawodność i zgodność.

← Bezpieczeństwo · Wszystkie domeny · Monitorowanie →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →