Testowanie oprogramowania - dokumentacja

Dokumentacja testowa obejmuje dokumentację artefaktów, które powinny zostać opracowane przed lub w trakcie testowania Oprogramowania.

Dokumentacja do testowania oprogramowania pomaga oszacować wymagany wysiłek testowy, pokrycie testów, śledzenie / śledzenie wymagań itp. W tej sekcji opisano niektóre z powszechnie używanych udokumentowanych artefaktów związanych z testowaniem oprogramowania, takich jak:

Plan testów
Scenariusz testowy
Przypadek testowy
Macierz identyfikowalności

Plan testów

Plan testów określa strategię, która będzie używana do testowania aplikacji, zasoby, które będą używane, środowisko testowe, w którym testy będą wykonywane, a także ograniczenia testowania i harmonogram czynności testowych. Zazwyczaj kierownik zespołu ds. Zapewnienia jakości będzie odpowiedzialny za napisanie planu testów.

Plan testów obejmuje:

Wprowadzenie do dokumentu planu testów
Założenia podczas testowania aplikacji
Lista przypadków testowych wchodzących w skład testowania aplikacji
Lista funkcji do przetestowania
Jakie podejście zastosować podczas testowania oprogramowania
Lista produktów do przetestowania
Zasoby przeznaczone na testowanie aplikacji
Wszelkie ryzyka związane z procesem testowania
Harmonogram zadań i kamieni milowych do osiągnięcia

Scenariusz testowy

Jest to jednowierszowa instrukcja, która informuje, który obszar aplikacji będzie testowany. Scenariusze testowe służą do zapewnienia, że wszystkie przepływy procesów są testowane od początku do końca. Określony obszar aplikacji może mieć od jednego scenariusza testowego do kilkuset scenariuszy, w zależności od wielkości i złożoności aplikacji.

Pojęcia „scenariusz testowy” i „przypadki testowe” są używane zamiennie, jednak scenariusz testowy składa się z kilku kroków, a przypadek testowy - z jednego kroku. Z tej perspektywy scenariusze testowe są przypadkami testowymi, ale zawierają kilka przypadków testowych i sekwencję, w jakiej powinny być wykonywane. Poza tym każdy test jest zależny od wyniku poprzedniego testu.

Przypadek testowy

Przypadki testowe obejmują zestaw kroków, warunków i danych wejściowych, których można używać podczas wykonywania zadań testowych. Głównym celem tego działania jest upewnienie się, czy oprogramowanie przejdzie lub zawodzi pod względem funkcjonalności i innych aspektów. Istnieje wiele rodzajów przypadków testowych, takich jak funkcjonalne, negatywne, błędne, logiczne przypadki testowe, fizyczne przypadki testowe, przypadki testowe interfejsu użytkownika itp.

Ponadto pisane są przypadki testowe, aby śledzić zakres testów oprogramowania. Generalnie nie ma formalnych szablonów, których można by użyć podczas pisania przypadków testowych. Jednak następujące komponenty są zawsze dostępne i zawarte w każdym przypadku testowym -

Identyfikator przypadku testowego
Moduł produktu
Wersja Produktu
Historia zmian
Purpose
Assumptions
Pre-conditions
Steps
Spodziewany rezultat
Rzeczywisty wynik
Post-conditions

Wiele przypadków testowych można wyprowadzić z jednego scenariusza testowego. Ponadto czasami dla jednego oprogramowania napisanych jest wiele przypadków testowych, które są wspólnie określane jako zestawy testów.

Macierz identyfikowalności

Macierz śledzenia (znana również jako macierz śledzenia wymagań - RTM) to tabela używana do śledzenia wymagań podczas cyklu życia oprogramowania. Może być używany do śledzenia w przód (tj. Od wymagań do projektu lub kodowania) lub wstecz (tj. Od kodowania do wymagań). Istnieje wiele szablonów zdefiniowanych przez użytkownika dla RTM.

Każde wymaganie w dokumencie RTM jest powiązane z powiązanym przypadkiem testowym, dzięki czemu testowanie można przeprowadzić zgodnie z wymienionymi wymaganiami. Co więcej, identyfikator błędu jest również dołączony i powiązany z powiązanymi wymaganiami i przypadkiem testowym. Główne cele tej macierzy to -

Upewnij się, że oprogramowanie zostało opracowane zgodnie z wymienionymi wymaganiami.
Pomaga w znalezieniu pierwotnej przyczyny dowolnego błędu.
Pomaga w śledzeniu opracowanych dokumentów na różnych etapach SDLC.