Analiza testów i podstawy testowania
Zespół redakcyjny
⚡ Inteligentne podsumowanie
Analiza testów, zwana również podstawą testów, to ustrukturyzowany przegląd wymagań, dokumentów projektowych i innych artefaktów wykorzystywanych do wyprowadzenia warunków testowalnych. W tym artykule wyjaśniono źródła, krok po kroku przebieg pracy oraz umiejscowienie analizy testów w modelu V.
Analiza testów – znana również jako podstawa testów – znajduje się na samym początku cyklu życia testów. Każdy warunek testowy i przypadek testowy ostatecznie tracWracamy do tego. Poniższe sekcje definiują termin, wyjaśniają jego źródła, opisują przepływ pracy analizy i umieszczają go w modelu V.
Czym jest analiza testów?
Analiza testów W testowaniu oprogramowania proces polega na przeglądaniu danych wejściowych wykorzystywanych do wyprowadzenia warunków testowych i przypadków testowych. Dane wejściowe — specyfikacje, wymagania, dokumenty projektowe, historie użytkowników i podobne produkty — są zbiorczo nazywane artefakty testoweCelem analizy testów jest wykazanietracCele testu t są na tyle jasne, że każdy z nich można przekształcić w jednoznaczny warunek testowy. Ponieważ analizowany materiał stanowi podstawę, z której wywodzą się wszystkie testy, nazywa się go również Podstawa testu.
Typowe źródła, z których testerzy czerpią informacje testowe, obejmują:
- SRS — Specyfikacja wymagań oprogramowania
- BRS — Specyfikacja wymagań biznesowych
- Dokumenty projektu funkcjonalnego
- Historie użytkowników, kryteria akceptacji i modele szkieletowe
Testerzy mogą również generować warunki testowe, badając bezpośrednio testowaną aplikację lub korzystając z wcześniejszych doświadczeń, ale większość przypadki testowe pochodzą z artefaktów testowych w celu utrzymania traczdolność.
👉 Zapisz się na bezpłatny projekt testowania oprogramowania na żywo
Dlaczego Test Basis jest ważny?
Podstawa testów (Test Basis) jest najważniejszym czynnikiem decydującym o tym, czy zestaw testów wykryje rzeczywiste defekty, czy też będzie ścigał te pozorne. Traktowanie jej jako opcjonalnej jest najczęstszą przyczyną przedostawania się błędów do produkcji. Solidna analiza testów przynosi cztery konkretne korzyści:
- Traczdolność: Każdy przypadek testowy można powiązać ze szczegółowym wymaganiem, co przyspiesza analizę wpływu zmian i ułatwia przeglądy audytowe.
- Przejrzystość zasięgu: Revobserwowanie luk w bazach danych — nieokreślonych stanów błędów, brakujących przypadków brzegowych, niezdefiniowanych progów niefunkcjonalnych — zanim staną się one incydentami produkcyjnymi.
- Współpraca interesariuszy: Gdy zespół testujący wywodzi warunki z tych samych dokumentów, na podstawie których pracuje zespół programistów, obie strony mają wspólną definicję „ukończenia”.
- Wczesne wykrywanie usterek: Wiele defektów w wymaganiach (niejednoznaczności, sprzeczności, brakujące kryteria akceptacji) jest wykrywanych już w trakcie analizy testów, na długo przed napisaniem jakiegokolwiek kodu — jest to zdecydowanie najtańszy sposób na ich naprawienie.
Typowe źródła podstaw testowych
Różne artefakty wpływają na różne poziomy testów. Skorzystaj z poniższej tabeli jako szybkiego odniesienia przy podejmowaniu decyzji, z którego dokumentu skorzystać podczas pisania przypadków testowych.
| Artefakt źródłowy | Najlepiej nadaje się do | Co byłeśtract |
|---|---|---|
| Specyfikacja wymagań biznesowych (BRS) | Akceptacja i testowanie systemu | Kompleksowe zasady biznesowe, ograniczenia regulacyjne, kryteria sukcesu |
| Specyfikacja wymagań oprogramowania (SRS) | Testowanie systemu | Wymagania funkcjonalne i niefunkcjonalne z mierzalnymi progami |
| Dokumentacja projektowa funkcjonalna/techniczna | Testy integracyjne | Interfejsy modułów, przepływ danych, specyfikacje obsługi błędów |
| Historie użytkowników i kryteria akceptacji | Testowanie sprinterskie Agile | Oczekiwania behawioralne w formie „Given–When–Then” |
| Modele szkieletowe i makiety interfejsu użytkownika | Testowanie interfejsu użytkownika / użyteczności | Układ, nawigacja, reguły walidacji danych wejściowych |
| Aplikacja testowana (eksploracyjna) | Testowanie eksploracyjne i regresyjne | Nieudokumentowane zachowania, rzeczywiste przepływy pracy, przypadki brzegowe |
Jak krok po kroku przeprowadzić analizę testów
Skuteczna analiza testów odbywa się zgodnie z powtarzalnym pięcioetapowym procesem, niezależnie od rozmiaru projektu lub metodologii.
- Zbierz i zinwentaryzuj bazę testową. Zbierz wszystkie artefakty opisujące zamierzone zachowanie — SRS, BRS, dokumenty projektowe, historie użytkowników, makiety. Zanotuj, który dokument zawiera każde wymaganie, aby… traczdolność pozostaje nienaruszona.
- Revwidok na testowalność. Przeczytaj każdy artefakt, mając na uwadze trzy pytania: Czy to stwierdzenie jest mierzalne? Czy jest jednoznaczne? Czy jest kompletne? Oznacz każde wymaganie, które nie przejdzie któregoś z tych sprawdzeń i zwróć je autorowi przed rozpoczęciem testów.
- Określ warunki testowe. Dla każdego testowalnego stwierdzenia wypisz warunki wymagające weryfikacji (ścieżki dodatnie, ścieżki ujemne, wartości brzegowe, obsługa błędów, bezpieczeństwo, wydajność). Warunek testowy totrac„co” — na przykład, „system odrzuca zamówienia o zerowej ilości” — odmienne od konkretnego „jak” przypadku testowego.
- Ustal priorytety i warunki grupowe. Klasyfikuj każdy stan chorobowy według ryzyka i częstotliwości użytkowania. Stany wysokiego ryzyka i wysokiej częstotliwości występowania wymagają szczegółowego omówienia; stany niskiego ryzyka można łączyć lub losowo wybierać. W tym miejscu decydujesz również, które stany chorobowe nadają się do automatyzacji.
- Konwersja warunków na przypadki testowe. Każdy priorytetowy warunek staje się jednym lub kilkoma przypadki testowe z warunkami wstępnymi, krokami, danymi testowymi i oczekiwanymi wynikami. Utrzymuj wymagania tracmacierz możliwości łącząca każdy przypadek testowy z jego pierwotnym wymaganiem.
Postępowanie zgodnie z tą sekwencją czynności pozwala uniknąć najczęstszych błędów w analizie testów: pisania przypadków testowych bez jasnej podstawy, pomijania negatywnych scenariuszy i tworzenia testów, których nie można powiązać z wymaganiami podczas selekcji defektów.
Analiza testów w modelu V
Model V łączy każdą czynność programistyczną z odpowiadającą jej czynnością testową. Analiza testów odbywa się na każdym poziomie, z wykorzystaniem dowolnego dokumentu dostępnego w danym momencie cyklu życia.
Rysunek 1: Analiza testów w fazach Model V.
Studium przypadku: Wyprowadzanie przypadków testowych z wymagań klienta
Rozważmy scenariusz, w którym klient wysyła następujące, jednowierszowe wymaganie.
Client requirement: Add search functionality to an eCommerce Store
Nawet jeśli aplikacja nie została jeszcze zbudowana, tester może już wyprowadzić kilka warunków testowych, analizując, co implikuje dane wymaganie – zarówno zachowanie zgodne z zasadą „happy path”, jak i tryby awarii, których klient nie określił wprost. Oto kilka przykładów:
- Sprawdź wynik wyszukiwania, jeśli nie wprowadzono żadnego słowa kluczowego.
- Sprawdź wynik wyszukiwania, jeśli nie znaleziono produktu pasującego do wprowadzonego słowa kluczowego.
- Sprawdź wynik wyszukiwania, jeśli dla danego słowa kluczowego istnieje kilka produktów pasujących do niego.
- Sprawdź zachowanie w przypadku znaków specjalnych, spacji na początku/końcu i bardzo długich danych wejściowych.
- Sprawdź, czy rozróżniana jest wielkość liter i czy zachowanie dopasowania częściowego jest poprawne.
- Sprawdź czas reakcji wyszukiwarki przy oczekiwanym obciążeniu użytkownika.
Tester bierze wymaganie klienta (podstawę testów), analizuje je i przekształca w warunki testowe. Ten schemat powtarza się w każdej fazie modelu V — plany testów i przypadki testowe są tworzone z wykorzystaniem dowolnego dokumentu dostępnego w danym momencie cyklu życia.
Wideo: Wyjaśnienie analizy testów
Jeśli film się nie załaduje, obejrzyj go bezpośrednio na YouTube.
