Ta tabela, umożliwia użytkownikowi selekcje przypadków testowych przed ich wyświetleniem. Znaczone pola będą pokazane w wygenerowanym dokumencie. W celu zmiany wyświetlanych informacji, zaznacz lub odznacz wybrane pola, następnie kliknij przycisk Filtruj, w dalszej kolejności na drzewie, w dolnej części okna zaznacz odpowiedni poziom szczegółów zawartych w dokumencie.
Nagłówek dokumentu: Użytkownik ma możliwość przefiltrowania nagłówków dokumentu. Nagłówek powinien zawierać informacje takie jak: wprowadzenie, zakres, odnośniki do dokumentów, metodologie testów, ograniczenia testów.
Budowa przypadków testowych: Użytkownik może przefiltrować informacje wchodzące w skład budowy głównej części przypadku testowego. W skład budowy przypadku testowego wchodzą: Cel przypadku testowego, kroki i oczekiwane rezultaty, autor przypadku, pola niestandardowe, powiązane słowa kluczowe i wymagania.
Podsumowanie testu: Użytkownik ma możliwość przefiltrowania samego celu testu poprzez tytuł przypadku testowego, ale nie zostaną w ten sposób wyłączone pozostałe informacje z budowy głównej części przypadku testowego. Podsumowanie testu zostało tylko częściowo oddzielone od budowy przypadku testowego, tak aby była możliwość wyświetlania przypadków tylko w formie tytułu i celu testu (bez wyświetlania kroków). Jeśli użytkownik wyświetli tylko główną część testu, będzie w nim zawarty cel testu .
Spis treści: Opcja ta tworzy listę wszystkich tytułów przypadków testowych z wewnętrznymi linkami w postaci hipertekstu (niezależne fragmenty tekstu połączone hiperlinkami).
Format wyjściowy: Istnieją dwie możliwości: HTML i MS Word. Przeglądarki odwołują sie do komponentu MS Word w drugiej kolejności.
"; // testPlan.html $TLS_hlp_testPlan = "Plan testu jest systemowym podejściem do testowania oprogramowania. Możesz ułożyć testowanie poszczególnych struktur produktów pod względem czasu i osiągniętych rezultatów.
Fragment ten jest tym gdzie użytkownik, może przeprowadzić przypadki testowe (opisać rezultaty testu) i wydrukować strukture przypadku testowego jako plan testu. Fragment ten umożliwia użytkownikowi śledzenie rezultatów przeprowadzanych przez niego przypadków testowych.
Ten fragment, który jest dostępny tylko dla zarzadzających projektem, pozwala użytkownikowi na administrowanie planem testu.
Administrowanie planem testu zawiera tworzenie/edytowanie/usuwanie planów,
dodawanie/edytowanie/usuwanie/aktualizacje przypadków testowych w planie testu, tworzenie struktur tak samo jak określenie, kto może obejrzeć który plan.
Użytkownicy z pozwoleniem zarzącającego projektem mogą także określić wagę/ryzyko i przynależność
struktury przypadku testowego (kategorie) oraz tworzenie kroków przypadku testowego.
Uwaga: Jest możliwe, że użytkownicy mogą nie widzieć listy dropdown zawierającej wszystkie plany testów. W takiej systuacji wszystkie linki (za wyjątkiem tych, które zostałe aktywowane przez zarządzajacego projektem) będą nie aktywne. Jeżeli jesteś w takiej sytuacji skontaktuj się z zarządzajacym projektem lub administratorem w celu udostępnienia odpowiednich praw do projektu lub stworzenia planu test dla ciebie.
"; // custom_fields.html $TLS_hlp_customFields = "Klika faktów odnośnie wprowadzania pól niestandardowych:
Definicja pola niestandardowe składa się z poszczególnych właściwości:
Przeprowadzanie przypadku testowego. Samo przeprowadzanie przypadku testowego jest w niewielkim stopniu powiązane od rezultatu przypadku testowego (poprawny, niepoprawny, wstrzymany) w przeciwieństwie do wyznaczonego elementu budowy.
Można stworzyć dostęp do systemu śledzenie błędu. Użytkownik może bezpośrednio dodawać zgłoszenia o nowych błędach i wyszukiwać zgłoszenia o starych.
"; //bug_add.html $TLS_hlp_btsIntegration = "(tylko jeżeli jest skonfigurowane) TestLink ma bardzo proste powiądzenie z systemem śledzenia błędu Bug Tracking Systems (BTS), jednakże Test Link nie może stworzyć zgłoszenia o błędzie oraz nie może uzyskać informacji o ID zgłoszonego błędu. Powiązanie jest zrobione poprzez linki do strony BTS odwołujących się do poszczególnych funkcji:
Lewe okienko zawiera opcje zarządzania przypisanymi przypadkami testowymi" . "Plan testu i tabela z ustawieniami oraz filtrem. Filtry, które są udostepniane użytkownikowi " . "w celu ulepszenia oferowanego zestawu " . "Ustaw swój filtr, przycisnij 'Zatwierdź' i zaznacz odpowiedni przypadek testowy " . "z menu drzewa .
Użytkownicy muszą wybrać strukture, która będzie powiązana z wynikami testu. " .
"struktury są podstawowym komponentem dla bieżącego planu testu. Każdy przypadek testowy " .
"może być przeprowadzony więcej niż jeden raz jeżeli to wynika, z jego struktury. Jednakże liczy się tylko ostatni wynik.
Struktura może być tworzona poprzez zarzadzajacego projektem przez strone umożliwiającą utworzenie nowej struktury.
Użytkownicy mogą filtrować przypadek testowy poprez indywidualny numer ID. Numer ID jest nadawany automatycznie w czasie tworzenia przypadku testowego. Pusty pasek filtra oznacza, że test nie jest obowiązujący.
Użytkownicy moga filtrować przypadek testowy w zależności od jego wagi. Waga testu składa się z kilku zmiennych" . "to jak test jest pilny wynika z bieżacego planu testu. Na przykład pryioryet 'WYSOKI' przypadku testowego" . "Na przykład pryioryet 'WYSOKI' " . " jest wyznaczony w przypadkach gdy pilność lub ważność oznaczona jako 'WYSOKA', a drugi czynnik oznaczony przynajmniej 'ŚREDNI'.
Użytkownicy mogą filtrować przypadki testowe poprzez rezultaty. Rezultaty są wynikem z wykonania określonej struktury przypadku testowego. Przypadki testowe moga być (poprawne, niepoprawne, zablokowane, nieprzeprowadzone)." . "Ten filtr jest domyślnie wyłączony.
Użytkownicy mogą filtrować przypadek testowy pod wględem komu zostały przypisane. Check-box przewiduje także opcję " . "\" nieprzpisane\" testy, które w rezultatach są umieszczane jako dodatkowe.
"; /* 'Najczęstsze wyniki' według ustawień domyślnych ta opcja jest odznaczona check-boxem, wówczas drzewko będzie ułożone
zgodnie ze strukturą wybraną z listy dropdown box. W takiej sytuacji drzewko będzie ułożone
ze względu status przypadku testowego.
Przykład: Użytkownik, zaznaczył strukture 2 z listy dropdown box i jednocześnie zaznaczy checkbox opcje
'Najczęstsze wyniki'. Wszystkie przypadki testowe są wyświetlane uwzględniając ich status w strukturze 2.
Więc, jeżeli przypadek testowy 1 będzie określony jako poprawny w strukturze 2 będzie zaznaczony na zielono.
Jeżeli użytkownik zdecyduje się zaznaczyć 'najbardziej bieżące' poprzez checkbox drzewko będzie
oznaczone kolorem takim jakim oznaczone są najcześciej przypadki testowe.
Przykład: Użytkownik zaznaczył strukture 2 z dropdown box i zaznaczył poprzez checkbox opcje
'najbardziej bierzące' przypadki testowe. Wtedy zostaną pokazane wszystkie przypadki testowe ze statusem
'najbardziej bierzące'. Więc, jeżeli przypadek testowy 1 jest poprawny w strukturze 3, wtedy jeżeli użytkownik zaznaczy przypadek w strukturze 2
, to przypadek będzie oznaczony na zielono.
Jest analizowany cały zestaw przypadków testowych powiązanych do planu testu i lista najnowszych przypadków testowych (w zakresie bieżącego zestawu planu testu).
"; // requirementsCoverage.html $TLS_hlp_requirementsCoverage = "Własność systemu, która pozwala na dokumentacje pokrycia wymagań systemu lub użytkownika, przez przypadki testowe. . Zarzadzane poprzez link \"Wymagania\" w głównym oknie.
Wymagania są zebrane w 'Zestawach wymagań' dokumencie powiązanym z
projektem testu.
TestLink nie obejmuje jednocześnie zestawu wymagań,
a także wymagań samych w sobie. Więc, wersja dokumentu powinna być dodana po
specyfikacji Tytuł.
Użytkownik może dodać prosty opis notatki do szkicu pola.
Przypisana liczba wymagań służy do oceny pokrycia wymagań,w przypadku kiedy nie wszystkie wymagania są dodane (zaimportowane). Wartość 0 oznacza bieżącą liczbę wymagań używaną w celu określenia metryki.
Przykład SRS zawiera 200 wymagań ale tylko 50 jest dodane do TestLink. Pokrycie testu jest 25% (jeżeli wszystkie te wymagania będą dodane).
Kliknij na tytule w celu stworzenia specyfikacji wymagań. Możesz tworzyć, edytować, usuwać lub importować zestaw wymagań dla dokumentu. Każde z wymagań ma tytuł, szkicu i status. Status powinien być \"Normalny\" lub \"Nietestowalny\". Nie testowalne wymagania nie są włączane do metryki. Ten parametr powinien być użyty dla niezastosowanych cech i żle zaprojektowanych wymagań.
Możesz stworzyć nowy przypadek testowy. Możesz stworzyć nowe przypadeki testowe dla wymagań poprzez użycie wielo wątkowej akcji z zaznaczonymi wymaganiami w oknie specyfikacji. Te przypadki testowe są stworzone w schemacie testu z nazwą określoną w definicji (default is: $tlCfg->req_cfg->default_testsuite_name = \" Zestaw testowy stworzony według wymagań - Auto\";). Tytuł i szkic są kopiowane do tych przypadków testowych.
"; // planAddTC_m1.tpl $TLS_hlp_planAddTC = "