software testing terms complete glossary
Aby uniknąć niejasności w różnych terminach testowania oprogramowania, załączam plik glosariusz testowania oprogramowania tutaj.
Wszystkie terminy testowania oprogramowania są zawarte w tym glosariuszu. Jeśli uważasz, że znasz definicję któregokolwiek terminu lepiej niż wspomniano tutaj, możesz użyć tego Formularz kontaktowy aby przesłać mi definicje. Podczas recenzji uwzględnię je na tej liście glosariuszy.
Aby poznać podstawowe definicje testowania oprogramowania i zapewniania jakości, jest to najlepszy słownik opracowany przez Erik van Veenendaal . Również dla każdej definicji w nawiasach znajduje się odniesienie do IEEE lub ISO.
DO
kryteria przyjęcia: Kryteria wyjścia, które musi spełniać komponent lub system, aby taki byłzaakceptowane przez użytkownika, klienta lub inny upoważniony podmiot. (IEEE 610)
testy akceptacyjne: Formalne testy pod kątem potrzeb użytkownika, wymagań i procesów biznesowych przeprowadzane w celu ustalenia, czy system spełnia kryteria akceptacji i umożliwienia użytkownikowi, klientom lub innemu upoważnionemu podmiotowi określenia, czy zaakceptować system, czy nie. (Po IEEE 610)
testy dostępności: Testowanie w celu określenia łatwości, z jaką niepełnosprawni użytkownicy mogą korzystać z komponentu lub systemu. (Gerrard)
precyzja: Zdolność oprogramowania do zapewniania właściwych lub uzgodnionych wyników lub efektów z wymaganym stopniem precyzji. (ISO 9126) Zobacz także testowanie funkcjonalności.
aktualny rezultat: Zachowanie powstałe / obserwowane podczas testowania komponentu lub systemu.
testowanie ad hoc: Testy przeprowadzane nieformalnie; nie ma formalnego przygotowania testów, nie stosuje się uznanej techniki projektowania testów, nie ma żadnych oczekiwań co do wyników, a losowość kieruje działaniami związanymi z wykonywaniem testów.
zdolność adaptacji: Zdolność oprogramowania do dostosowywania się do różnych określonych środowisk bez stosowania działań lub środków innych niż przewidziane w tym celu dla rozważanego oprogramowania. (ISO 9126) Zobacz także testowanie przenośności.
testy zwinne: Praktyka testowania projektu z wykorzystaniem zwinnych metodologii, takich jak programowanie ekstremalne (XP), traktowanie programowania jako klienta testowania i podkreślanie paradygmatu projektowania najpierw testowego.
testy alfa: Symulowane lub rzeczywiste testy operacyjne przez potencjalnych użytkowników / klientów lub niezależny zespół testowy w witrynie programistów, ale poza organizacją programistyczną. Testy alfa są często stosowane jako forma wewnętrznych testów akceptacyjnych.
analizowalność: Zdolność oprogramowania do zdiagnozowania braków lub przyczyn awarii oprogramowania lub identyfikacji części, które mają zostać zmodyfikowane. (ISO 9126) Patrz także testowanie konserwacji.
anomalia: Wszelkie warunki, które odbiegają od oczekiwań opartych na specyfikacjach wymagań, dokumentach projektowych, dokumentach użytkownika, standardach itp. Lub na podstawie czyjejś percepcji lub doświadczenia. Podczas przeglądania, testowania, analizy, kompilacji lub korzystania z oprogramowania lub stosownej dokumentacji można wykryć anomalie, ale nie ograniczając się do nich. (IEEE 1044) Zobacz także: defekt, odchylenie, błąd, usterka, awaria, incydent, problem.
atrakcyjność: Zdolność oprogramowania do bycia atrakcyjnym dla użytkownika. (ISO 9126)
rewizja: Niezależna ocena oprogramowania lub procesów w celu ustalenia zgodności ze standardami, wytycznymi, specyfikacjami i / lub procedurami w oparciu o obiektywne kryteria, w tym dokumenty określające:
(1) formę lub zawartość produktów, które mają być wytworzone
(2) proces wytwarzania produktów
(3) sposób mierzenia zgodności z normami lub wytycznymi. (IEEE 1028)
ścieżka audytu: Ścieżka, za pomocą której można prześledzić pierwotne dane wejściowe do procesu (np. Dane) w procesie, przyjmując dane wyjściowe procesu jako punkt początkowy. Ułatwia to analizę defektów i umożliwia przeprowadzenie audytu procesu. (Po TMap)
zautomatyzowane oprogramowanie testowe: Oprogramowanie testowe używane w testowaniu automatycznym, takie jak skrypty narzędzi.
dostępność: Stopień, w jakim komponent lub system jest sprawny i dostępny, gdy jest wymagany do użycia. Często wyrażane w procentach. (IEEE 610)
b
testowanie wstecz: Testowanie, w którym dwa lub więcej wariantów komponentu lub systemu jest wykonywanych z tymi samymi danymi wejściowymi, wyniki są porównywane i analizowane w przypadku rozbieżności. (IEEE 610)
linia bazowa: Specyfikacja lub oprogramowanie, które zostało formalnie przejrzane lub uzgodnione, a następnie służy jako podstawa do dalszego rozwoju i które można zmienić tylko poprzez formalny proces kontroli zmian. (Po IEEE 610)
blok podstawowy: Sekwencja co najmniej jednej kolejnej instrukcji wykonywalnej, która nie zawiera rozgałęzień.
podstawowy zestaw testowy: Zestaw przypadków testowych pochodzących z wewnętrznej struktury lub specyfikacji w celu zapewnienia osiągnięcia 100% określonego kryterium pokrycia.
zachowanie: Reakcja komponentu lub systemu na zbiór wartości wejściowych i warunków wstępnych.
test porównawczy: (1) Norma, względem której można dokonywać pomiarów lub porównań. (2) Test, który jest używany do porównania komponentów lub systemów między sobą lub z normą jak w (1). (Po IEEE 610)
oprogramowanie na zamówienie: Oprogramowanie opracowane specjalnie dla określonej grupy użytkowników lub klientów. Przeciwieństwem jest gotowe oprogramowanie.
najlepsze praktyki: Doskonała metoda lub innowacyjna praktyka, która przyczynia się do poprawy wyników organizacji w danym kontekście, zwykle uznawana za „najlepszą” przez inne organizacje partnerskie.
testowanie beta: Testowanie operacyjne przez potencjalnych i / lub istniejących użytkowników / klientów w zewnętrznej lokalizacji, która nie jest w inny sposób zaangażowana w programistów, w celu ustalenia, czy komponent lub system spełnia potrzeby użytkownika / klienta i pasuje do procesów biznesowych. Testy beta są często wykorzystywane jako forma zewnętrznych testów akceptacyjnych w celu uzyskania informacji zwrotnej z rynku.
testy wielkiego wybuchu: Typ testów integracyjnych, w których elementy oprogramowania, elementy sprzętowe lub oba są łączone jednocześnie w komponent lub cały system, a nie etapami. (Po IEEE 610) Zobacz także testowanie integracji.
testowanie czarnoskrzynkowe: Testowanie funkcjonalne lub niefunkcjonalne bez odniesienia do wewnętrznej struktury komponentu lub systemu.
techniki projektowania testów czarnoskrzynkowych: Udokumentowana procedura wyprowadzania i wybierania przypadków testowych na podstawie analizy specyfikacji, funkcjonalnej lub niefunkcjonalnej, komponentu lub systemu bez odniesienia do jego struktury wewnętrznej.
zablokowany przypadek testowy: Przypadek testowy, którego nie można wykonać, ponieważ warunki wstępne jego wykonania nie są spełnione.
testy oddolne: Przyrostowe podejście do testowania integracyjnego, w którym najpierw testowane są komponenty najniższego poziomu, a następnie używane do ułatwienia testowania komponentów wyższego poziomu. Ten proces jest powtarzany do momentu przetestowania komponentu na szczycie hierarchii. Zobacz także testowanie integracji.
wartość graniczna: Wartość wejściowa lub wartość wyjściowa, która znajduje się na krawędzi podziału równoważności lub w najmniejszej przyrostowej odległości po dowolnej stronie krawędzi, na przykład minimalna lub maksymalna wartość zakresu.
analiza wartości brzegowych: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe są projektowane na podstawie wartości granicznych.
pokrycie wartości granicznych: Procent wartości granicznych, które zostały sprawdzone przez zestaw testów.
gałąź: Podstawowy blok, który można wybrać do wykonania na podstawie konstrukcji programu, w której dostępna jest jedna z dwóch lub więcej alternatywnych ścieżek programu, np. sprawa, skok, przejdź do, jeśli to- w przeciwnym razie.
zasięg oddziału: Procent gałęzi, które zostały wykonane przez zestaw testów. 100% pokrycie oddziałów oznacza zarówno 100% pokrycie decyzji, jak i 100% pokrycie instrukcji.
testowanie gałęzi: Technika projektowania testów typu white box, w której przypadki testowe są przeznaczone do wykonywania gałęzi.
testowanie oparte na procesach biznesowych: Podejście do testowania, w którym przypadki testowe są projektowane na podstawie opisów i / lub znajomości procesów biznesowych.
do
Model dojrzałości zdolności (CMM): Pięciopoziomowe ramy, które opisują kluczowe elementy skutecznego procesu tworzenia oprogramowania. Model dojrzałości zdolności obejmuje praktyki planowania, projektowania i zarządzania tworzeniem i utrzymaniem oprogramowania. (CMM)
Integracja modelu dojrzałości zdolności (CMMI): Struktura opisująca kluczowe elementy skutecznego procesu rozwoju i utrzymania produktu. Integracja modelu dojrzałości zdolności obejmuje praktyki planowania, inżynierii i zarządzania rozwojem i konserwacją produktu. CMMI jest wyznaczonym następcą CMM. (CMMI)
narzędzie do przechwytywania / odtwarzania: Rodzaj narzędzia do wykonywania testów, w którym dane wejściowe są rejestrowane podczas testowania ręcznego w celu generowania automatycznych skryptów testowych, które można wykonać później (tj. Odtworzyć). Narzędzia te są często używane do obsługi automatycznych testów regresyjnych.
WALIZKA: Skrót oznaczający inżynierię oprogramowania wspomaganą komputerowo.
ODLEW: Skrót oznaczający testowanie oprogramowania wspomaganego komputerowo. Zobacz także automatyzacja testów.
wykres przyczynowo-skutkowy: Graficzne przedstawienie danych wejściowych i / lub bodźców (przyczyn) z powiązanymi z nimi wynikami (efektami), które można wykorzystać do projektowania przypadków testowych.
wykresy przyczynowo-skutkowe: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe są projektowane na podstawie wykresów przyczynowo-skutkowych. (BS 7925/2)
orzecznictwo: Proces potwierdzania, że komponent, system lub osoba spełnia określone wymagania, np. zdając egzamin.
zmienność: Zdolność oprogramowania do wprowadzania określonych modyfikacji. (ISO 9126) Patrz także łatwość konserwacji.
metoda drzewa klasyfikacyjnego: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe, opisane za pomocą drzewa klasyfikacyjnego, są przeznaczone do wykonywania kombinacji przedstawicieli domen wejściowych i / lub wyjściowych. (Grochtmann)
Pokrycie kodu: Metoda analizy określająca, które części oprogramowania zostały wykonane (objęte) przez zestaw testów, a które nie, np. zakres oświadczenia, zakres decyzji lub zakres warunków.
współistnienie: Zdolność oprogramowania do współistnienia z innym niezależnym oprogramowaniem we wspólnym środowisku korzystającym ze wspólnych zasobów. (ISO 9126) Patrz testowanie przenośności.
złożoność: Stopień, w jakim komponent lub system ma projekt i / lub strukturę wewnętrzną, która jest trudna do zrozumienia, utrzymania i weryfikacji. Zobacz także złożoność cyklomatyczna.
spełnienie: Zdolność oprogramowania do przestrzegania standardów, konwencji lub przepisów prawnych i podobnych przepisów. (ISO 9126)
Testy zgodności : Proces testowania mający na celu określenie zgodności komponentu lub systemu.
składnik: Minimalny element oprogramowania, który można przetestować oddzielnie.
testowanie integracji komponentów: Testy przeprowadzane w celu ujawnienia usterek w interfejsach i interakcji między zintegrowanymi komponentami.
specyfikacja komponentu: Opis funkcji komponentu pod względem jego wartości wyjściowych dla określonych wartości wejściowych w określonych warunkach i wymaganego zachowania niefunkcjonalnego (np. Wykorzystanie zasobów).
testowanie komponentów: Testowanie poszczególnych komponentów oprogramowania. (Po IEEE 610)
warunek złożony: Dwa lub więcej pojedynczych warunków połączonych za pomocą operatora logicznego (AND, OR lub XOR), np. „A> B ORAZ C> 1000”.
testowanie współbieżności: Testowanie mające na celu określenie, w jaki sposób wystąpienie dwóch lub więcej czynności w tym samym przedziale czasu, osiągnięte albo przez przeplatanie czynności, albo przez jednoczesne wykonanie, jest obsługiwane przez komponent lub system. (Po IEEE 610)
stan: schorzenie: Wyrażenie logiczne, które można ocenić jako Prawda lub Fałsz, np. A> B. Zobacz także warunek testu.
pokrycie stanu: Procent wyników warunków, które zostały sprawdzone przez zestaw testów. Stuprocentowe pokrycie warunków wymaga, aby każdy warunek w każdej instrukcji decyzji był testowany jako Prawda i Fałsz.
zakres określenia stanu: Procent wszystkich wyników pojedynczego warunku, które niezależnie wpływają na wynik decyzji, które zostały sprawdzone przez zestaw przypadków testowych. 100% pokrycie warunku oznacza 100% pokrycie warunku decyzji.
badanie stanu: Technika projektowania testów białoskrzynkowych, w której przypadki testowe są zaprojektowane do wykonywania pojedynczych wyników warunkowych, które niezależnie wpływają na wynik decyzji.
testowanie stanu: Technika projektowania testów białej skrzynki, w której przypadki testowe są projektowane w celu wykonania warunków.
warunek wynik: Ocena warunku jako Prawda lub Fałsz.
konfiguracja: Skład komponentu lub systemu określony przez liczbę, charakter i wzajemne połączenia jego części składowych.
audyt konfiguracji: Funkcja sprawdzania zawartości bibliotek elementów konfiguracyjnych, np. zgodności z normami. (IEEE 610)
kontrola konfiguracji: Element zarządzania konfiguracją, na który składa się ocena, koordynacja, zatwierdzenie lub odrzucenie oraz wprowadzenie zmian w elementach konfiguracji po formalnym ustaleniu identyfikacji ich konfiguracji. (IEEE
610)
identyfikacja konfiguracji: Element zarządzania konfiguracją, polegający na doborze elementów konfiguracji systemu i zapisaniu ich cech funkcjonalno-fizycznych w dokumentacji technicznej. (IEEE 610)
element konfiguracji: Agregacja sprzętu, oprogramowania lub obu, która jest przeznaczona do zarządzania konfiguracją i traktowana jako pojedyncza jednostka w procesie zarządzania konfiguracją. (IEEE 610)
Zarządzanie konfiguracją: Dyscyplina stosująca techniczne i administracyjne kierownictwo i nadzór w celu: zidentyfikowania i udokumentowania funkcjonalnych i fizycznych charakterystyk elementu konfiguracji, kontroli zmian tych charakterystyk, rejestrowania i raportowania stanu przetwarzania i wdrażania zmian oraz weryfikacji zgodności z określonymi wymaganiami. (IEEE 610)
konsystencja: Stopień jednolitości, standaryzacji i braku sprzeczności między dokumentami lub częściami komponentu lub systemu. (IEEE 610)
kontrola przepływu: Abstrakcyjna reprezentacja wszystkich możliwych sekwencji zdarzeń (ścieżek) w wykonaniu przez komponent lub system.
testy konwersji: Testowanie oprogramowania służącego do konwersji danych z istniejących systemów do wykorzystania w systemach zastępczych.
ŁÓŻECZKA: Skrót od komercyjnego oprogramowania gotowego do spożycia.
pokrycie: Stopień, wyrażony w procentach, w jakim określony element pokrycia został przetestowany przez zestaw testów.
analiza pokrycia: Pomiar osiągniętego pokrycia dla określonego elementu pokrycia podczas wykonywania testów z odniesieniem do wcześniej określonych kryteriów w celu określenia, czy wymagane jest dodatkowe testowanie, a jeśli tak, to które przypadki testowe są potrzebne.
pozycja pokrycia: Podmiot lub właściwość wykorzystana jako podstawa pokrycia testów, np. równoważności partycji lub instrukcji kodu.
narzędzie pokrycia: Narzędzie, które dostarcza obiektywnych miar jakie elementy konstrukcyjne, np. instrukcje, gałęzie zostały przetestowane przez zestaw testów.
złożoność cykliczna: Liczba niezależnych ścieżek w programie. Złożoność cyklomatyczna jest definiowana jako: L - N + 2P, gdzie -L = liczba krawędzi / linków na wykresie -N = liczba węzłów w grafie - P = liczba odłączonych części grafu (np. Graf wywołujący i podprogram). (Po McCabe)
re
definicja danych: Instrukcja wykonywalna, w której zmiennej przypisano wartość.
testy oparte na danych: Technika skryptowa, która przechowuje testowe dane wejściowe i oczekiwane wyniki w tabeli lub arkuszu kalkulacyjnym, dzięki czemu jeden skrypt sterujący może wykonać wszystkie testy w tabeli. Testowanie oparte na danych jest często wykorzystywane do obsługi narzędzi do wykonywania testów, takich jak narzędzia do przechwytywania / odtwarzania. (Fewster i Graham) Zobacz także testowanie oparte na słowach kluczowych.
przepływ danych: Abstrakcyjna reprezentacja sekwencji i możliwych zmian stanu obiektów danych, gdzie stan obiektu jest dowolny:tworzenie, użytkowanie lub niszczenie. (Beizer)
analiza przepływu danych: Forma analizy statycznej oparta na definicji i wykorzystaniu zmiennych.
pokrycie przepływu danych: Procent par definicja-użycie, które zostały sprawdzone przez zestaw przypadków testowych.
test przepływu danych: Technika projektowania testów białej skrzynki, w której przypadki testowe są przeznaczone do wykonywania definicji i używania par zmiennych.
debugowanie: Proces wyszukiwania, analizy i usuwania przyczyn awarii oprogramowania.
narzędzie do debugowania: Narzędzie używane przez programistów do odtwarzania błędów, badania stanu programów i znajdowania odpowiednich usterek. Debugery umożliwiają programistom wykonywanie programów krok po kroku, zatrzymywanie programu przy dowolnej instrukcji programu oraz ustawianie i sprawdzanie zmiennych programu.
decyzja: Punkt programu, w którym przepływ sterowania ma dwie lub więcej alternatywnych tras. Węzeł z dwoma lub więcej linkami do oddzielnych gałęzi.
zakres warunku decyzji: Procent wszystkich wyników warunku i wyników decyzji, które zostały sprawdzone przez zestaw testów. 100% pokrycie warunku decyzji oznacza zarówno 100% pokrycie warunku, jak i 100% pokrycie decyzji.
testowanie warunków decyzji: Technika projektowania testów białoskrzynkowych, w której przypadki testowe są projektowane w celu wykonania warunków i decyzji.
zakres decyzji: Procent wyników decyzji, które zostały sprawdzone przez zestaw testów. 100% pokrycie decyzji oznacza zarówno 100% pokrycie oddziałów, jak i 100% pokrycie instrukcji.
tabela decyzyjna: Tabela przedstawiająca kombinacje danych wejściowych i / lub bodźców (przyczyn) z powiązanymi z nimi wynikami i / lub działaniami (efektami), które można wykorzystać do projektowania przypadków testowych.
testowanie tablic decyzyjnych: Techniki projektowania testów czarnoskrzynkowych, w których przypadki testowe są zaprojektowane do wykonywania kombinacji danych wejściowych i / lub bodźców (przyczyn) przedstawionych w tabeli decyzyjnej. (Veenendaal)
testowanie decyzji: Technika projektowania testów białoskrzynkowych, w której przypadki testowe są zaprojektowane do wykonywania decyzji.
wynik decyzji: Wynik decyzji (która w związku z tym określa branże, które należy podjąć).
wada: Wada w komponencie lub systemie, która może spowodować, że komponent lub system nie będzie spełniał swojej wymaganej funkcji, np. niepoprawne stwierdzenie lub definicja danych. Usterka napotkana podczas wykonywania może spowodować awarię komponentu lub systemu.
gęstość defektów: Liczba usterek zidentyfikowanych w komponencie lub systemie podzielona przez rozmiar komponentu lub systemu (wyrażona za pomocą standardowych terminów pomiarowych, np. Linii kodu, liczby klas lub punktów funkcyjnych).
Procent wykrycia defektów (DDP): liczba defektów wykrytych w fazie testowej podzielona przez liczbę usterek wykrytych w tej fazie testowej i wszelkie inne środki później.
raport wady: Dokument zgłaszający jakąkolwiek usterkę w komponencie lub systemie, która może spowodować, że komponent lub system nie będzie spełniał swojej wymaganej funkcji. (Po IEEE 829)
zarządzanie defektami: Proces rozpoznawania, badania, podejmowania działań i usuwania wad. Polega na rejestrowaniu defektów, klasyfikowaniu ich i określaniu skutków. (Po IEEE 1044)
maskowanie defektów: Sytuacja, w której jedna wada uniemożliwia wykrycie innej. (Po IEEE 610)
para definicja-zastosowanie: Skojarzenie definicji zmiennej z użyciem tej zmiennej. Zmienne zastosowania obejmują obliczenia (np. Mnożenie) lub kierowanie wykonaniem ścieżki (użycie „predykatu”).
dostarczalny: Każdy produkt (dzieło), który musi zostać dostarczony komuś innemu niż jego autor.
testy projektowe: Podejście do testowania, w którym przypadki testowe są projektowane w oparciu o architekturę i / lub szczegółowy projekt komponentu lub systemu (np. Testy interfejsów między komponentami lub systemami).
sprawdzenie biurka: Testowanie oprogramowania lub specyfikacji poprzez ręczną symulację jego wykonania.
testy rozwojowe: Formalne lub nieformalne testy przeprowadzane podczas wdrażania komponentu lub systemu, zwykle w środowisku programistycznym przez programistów. (Po IEEE 610)
testowanie dokumentacji: Badanie jakości dokumentacji, np. instrukcja obsługi lub instrukcja instalacji.
domena: Zestaw, z którego można wybrać prawidłowe wartości wejściowe i / lub wyjściowe.
kierowca: Komponent oprogramowania lub narzędzie testowe, które zastępuje komponent odpowiedzialny za sterowanie i / lub wywoływanie komponentu lub systemu. (Po TMap)
analiza dynamiczna: Proces oceny zachowań, np. wydajność pamięci, użycie procesora systemu lub komponentu podczas wykonywania. (Po IEEE 610)
dynamiczne porównanie: Porównanie rzeczywistych i oczekiwanych wyników, wykonywanych w trakcie wykonywania oprogramowania, na przykład za pomocą narzędzia do wykonywania testów.
testy dynamiczne: Testowanie, które obejmuje wykonanie oprogramowania komponentu lub systemu.
JEST
wydajność: Zdolność oprogramowania do zapewnienia odpowiedniej wydajności w stosunku do ilości zasobów używanych w określonych warunkach. (ISO 9126)
testy wydajności: Proces testowania mający na celu określenie wydajności oprogramowania.
podstawowe testy porównawcze: Techniki projektowania testów czarnoskrzynkowych, w których przypadki testowe są projektowane do wykonywania kombinacji danych wejściowych przy użyciu koncepcji pokrycia określania warunków. (TMap)
emulator: Urządzenie, program komputerowy lub system, który przyjmuje te same dane wejściowe i wytwarza te same wyjścia, co dany system. (IEEE 610) Zobacz także symulator.
kryteria wejścia: zbiór ogólnych i szczegółowych warunków umożliwiających kontynuację procesu w ramach określonego zadania, np. faza testowa. Celem kryteriów wejściowych jest zapobieżenie rozpoczęciu zadania, które wymagałoby więcej (zmarnowanego) wysiłku w porównaniu z wysiłkiem potrzebnym do usunięcia kryteriów, które nie powiodły się. (Gilb i Graham)
Punkt wejścia: Pierwsza instrukcja wykonywalna w komponencie.
podział równoważności: Część domeny wejściowej lub wyjściowej, dla której zakłada się, że zachowanie komponentu lub systemu jest takie samo, na podstawie specyfikacji.
pokrycie podziału równoważności: Procent partycji równoważności, które zostały sprawdzone przez zestaw testów.
podział równoważności: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe są zaprojektowane do wykonywania przedstawicieli z partycji równoważności. Zasadniczo przypadki testowe są zaprojektowane tak, aby przynajmniej raz pokryć każdą partycję.
błąd: Czynność ludzka, która prowadzi do nieprawidłowego wyniku. (Po IEEE 610)
zgadywanie błędów: Technika projektowania testów, w której doświadczenie testera jest wykorzystywane do przewidywania, jakie defekty mogą występować w testowanym komponencie lub systemie w wyniku popełnionych błędów, oraz do projektowania testów specjalnie w celu ich ujawnienia.
wysiew błędów: Proces celowego dodawania znanych usterek do tych, które już znajdują się w komponencie lub systemie, w celu monitorowania szybkości wykrywania i usuwania oraz szacowania liczby pozostałych usterek. (IEEE 610)
tolerancja błędu: Zdolność systemu lub komponentu do kontynuowania normalnej pracy pomimo obecności błędnych danych wejściowych. (Według IEEE 610).
Obsługa wyjątków: Zachowanie komponentu lub systemu w odpowiedzi na błędne dane wejściowe ze strony użytkownika lub innego komponentu lub systemu, lub na awarię wewnętrzną.
instrukcja wykonywalna: Instrukcja, która po skompilowaniu jest tłumaczona na kod wynikowy i która zostanie wykonana proceduralnie, gdy program jest uruchomiony i może wykonać akcję na danych.
ćwiczone: Mówi się, że element programu jest wykonywany przez przypadek testowy, gdy wartość wejściowa powoduje wykonanie tego elementu, takiego jak instrukcja, decyzja lub inny element strukturalny.
wyczerpujące testy: Podejście testowe, w którym zestaw testów obejmuje wszystkie kombinacje wartości wejściowych i warunków wstępnych.
kryteria wyjścia: Zbiór ogólnych i szczegółowych warunków, uzgodnionych z interesariuszami, umożliwiających oficjalne zakończenie procesu. Kryteria zakończenia mają na celu zapobieżenie uznaniu zadania za zakończone, gdy nadal istnieją zaległe części zadania, które nie zostały ukończone. Kryteria zakończenia są używane przez testowanie do raportowania i planowania, kiedy zakończyć testowanie. (Według Gilba i Grahama)
punkt wyjścia: Ostatnia instrukcja wykonywalna w komponencie.
Spodziewany wynik: Zachowanie przewidywane przez specyfikację lub inne źródło komponentu lub systemu w określonych warunkach.
testy eksploracyjne: Testowanie, w którym tester aktywnie kontroluje projekt testów w trakcie ich wykonywania i wykorzystuje informacje uzyskane podczas testowania do projektowania nowych, lepszych testów. (Kawaler)
fa
zawieść: Test uważa się za nieudany, jeśli jego rzeczywisty wynik nie jest zgodny z oczekiwanym wynikiem.
niepowodzenie: Rzeczywiste odchylenie komponentu lub systemu od oczekiwanej dostawy, usługi lub wyniku. (Po Fenton)
Tryb awaryjny: Fizyczna lub funkcjonalna manifestacja awarii. Na przykład system w trybie awaryjnym może charakteryzować się powolną pracą, nieprawidłowymi wyjściami lub całkowitym zakończeniem wykonywania.
Analiza trybów awarii i skutków (FMEA): Systematyczne podejście do identyfikacji i analizy ryzyka polegające na identyfikacji możliwych rodzajów awarii i próbach zapobiegania ich wystąpieniu.
współczynnik awaryjności: Stosunek liczby awarii danej kategorii do danej jednostki miary, np. awarie na jednostkę czasu, awarie na liczbę transakcji, awarie na liczbę uruchomień komputera. (IEEE 610)
tolerancja błędów: Zdolność oprogramowania do utrzymania określonego poziomu wydajności w przypadku błędów oprogramowania (defektów) lub naruszenia określonego interfejsu. (ISO 9126) Zobacz także niezawodność.
analiza drzewa błędów: Metoda stosowana do analizy przyczyn usterek (defektów).
wykonalna ścieżka: Ścieżka, dla której istnieje zestaw wartości wejściowych i warunków wstępnych, które powodują jej wykonanie.
funkcja: Atrybut komponentu lub systemu określony lub implikowany w dokumentacji wymagań (na przykład niezawodność, użyteczność lub ograniczenia projektowe). (Po IEEE 1008)
maszyna skończona: Model obliczeniowy składający się ze skończonej liczby stanów i przejść między tymi stanami, ewentualnie z towarzyszącymi im działaniami. (IEEE 610)
przegląd formalny: Przegląd charakteryzujący się udokumentowanymi procedurami i wymaganiami, np. kontrola.
zamrożona podstawa testu: Dokument będący podstawą testów, który można zmienić jedynie poprzez formalny proces kontroli zmian. Zobacz także baseline.
Analiza punktów funkcyjnych (FPA): Metoda mająca na celu pomiar wielkości funkcjonalności systemu informatycznego. Pomiar jest niezależny od technologii. Pomiar ten może służyć jako podstawa do pomiaru produktywności, oszacowania potrzebnych zasobów i kontroli projektu.
integracja funkcjonalna: Podejście integracyjne, które łączy komponenty lub systemy w celu wczesnego uzyskania podstawowej funkcjonalności. Zobacz także testowanie integracji.
Wymagania funkcjonalne: Wymaganie określające funkcję, którą musi spełniać komponent lub system. (IEEE 610)
technika projektowania testów funkcjonalnych: Udokumentowana procedura wyprowadzania i wybierania przypadków testowych na podstawie analizy specyfikacji funkcjonalności komponentu lub systemu bez odniesienia do jego struktury wewnętrznej. Zobacz także technikę projektowania testów czarnoskrzynkowych.
testy funkcjonalności: Testowanie oparte na analizie specyfikacji funkcjonalności komponentu lub systemu. Zobacz także testy czarnoskrzynkowe.
funkcjonalność: Zdolność oprogramowania do zapewniania funkcji, które spełniają określone i domniemane potrzeby, gdy oprogramowanie jest używane w określonych warunkach. (ISO 9126)
testowanie funkcjonalności: Proces testowania mający na celu określenie funkcjonalności oprogramowania.
sol
testowanie szklanych pudełek: Zobacz testy białoskrzynkowe.
H.
ocena heurystyczna: Technika statycznego testu użyteczności w celu określenia zgodności interfejsu użytkownika z uznanymi zasadami użyteczności (tzw. „Heurystyka”).
przypadek testowy wysokiego poziomu: Przypadek testowy bez konkretnych (na poziomie implementacji) wartości danych wejściowych i oczekiwanych wyników.
identyfikowalność pozioma: Śledzenie wymagań dla poziomu testów poprzez warstwy dokumentacji testowej (np. Plan testów, specyfikacja projektu testów, specyfikacja przypadku testowego i specyfikacja procedury testowej).
ja
analiza wpływu: Ocena zmiany warstw dokumentacji deweloperskiej, dokumentacji testowej i komponentów w celu wdrożenia danej zmiany do określonych wymagań.
przyrostowy model rozwoju: Cykl rozwojowy, w którym projekt jest podzielony na serię przyrostów, z których każdy zapewnia część funkcjonalności w ogólnych wymaganiach projektu. Wymagania są uszeregowane pod względem ważności i dostarczane w kolejności priorytetów z odpowiednim przyrostem. W niektórych (ale nie we wszystkich) wersjach tego modelu cyklu życia każdy podprojekt jest zgodny z „mini-modelem V” z własną fazą projektowania, kodowania i testowania.
testowanie przyrostowe: Testowanie, w którym komponenty lub systemy są integrowane i testowane pojedynczo lub kilka na raz, aż wszystkie komponenty lub systemy zostaną zintegrowane i przetestowane.
incydent: Każde zdarzenie występujące podczas testowania, które wymaga zbadania. (Po IEEE 1008)
zarządzanie incydentami: Proces rozpoznawania, badania, podejmowania działań i usuwania incydentów. Polega na rejestrowaniu incydentów, klasyfikowaniu ich i określaniu skutków. (Po IEEE 1044)
narzędzie do zarządzania incydentami: Narzędzie ułatwiające rejestrowanie i śledzenie statusu incydentów wykrytych podczas testów. Często dysponują urządzeniami zorientowanymi na przepływ pracy, które umożliwiają śledzenie i kontrolowanie alokacji, korygowania i ponownego testowania incydentów oraz zapewniają funkcje raportowania.
raport powypadkowy: Dokument informujący o każdym zdarzeniu, które ma miejsce podczas testowania, które wymaga zbadania. (Po IEEE 829)
niezależność: Rozdzielenie obowiązków, co zachęca do wykonywania obiektywnych testów. (Po DO-178b)
niewykonalna ścieżka: Ścieżka, której nie można wykonać za pomocą żadnego zestawu możliwych wartości wejściowych.
nieformalna recenzja: Przegląd nieoparty na formalnej (udokumentowanej) procedurze.
Wejście: Zmienna (przechowywana w składniku lub poza nim) odczytywana przez komponent.
domena wejściowa: Zestaw, z którego można wybrać prawidłowe wartości wejściowe. Zobacz także dziedzina.
wartość wejściowa: Instancja wejścia. Zobacz także wejście.
kontrola: Rodzaj przeglądu polegający na wizualnym badaniu dokumentów w celu wykrycia wad, np. naruszenia standardów programistycznych i niezgodności z dokumentacją wyższego poziomu. Najbardziej formalna technika przeglądu, dlatego zawsze oparta na udokumentowanej procedurze. (Po IEEE 610, IEEE 1028)
możliwość instalacji: Zdolność oprogramowania do zainstalowania w określonym środowisku (ISO 9126). Zobacz także przenośność.
testowanie instalacji: Proces testowania możliwości instalacji oprogramowania. Zobacz także testowanie przenośności.
instrukcja instalacji: Dostarczone instrukcje na dowolnym odpowiednim nośniku, które prowadzą instalatora przez proces instalacji. Może to być instrukcja obsługi, procedura krok po kroku, kreator instalacji lub inny podobny opis procesu.
Kreator instalacji: Dostarczone oprogramowanie na dowolnym odpowiednim nośniku, które prowadzi instalatora przez proces instalacji. Zwykle uruchamia proces instalacji, dostarcza informacji zwrotnych na temat wyników instalacji i monituje o opcje.
oprzyrządowanie: Wstawienie dodatkowego kodu do programu w celu zebrania informacji o zachowaniu programu podczas wykonywania.
instrumenty: Narzędzie programowe służące do wykonywania oprzyrządowania.
test spożycia: Specjalny przypadek testu zadymienia w celu podjęcia decyzji, czy komponent lub system jest gotowy do szczegółowych i dalszych testów. Test wstępny jest zwykle przeprowadzany na początku fazy wykonywania testu.
integracja: Proces łączenia komponentów lub systemów w większe zespoły.
testy integracyjne: Testy przeprowadzane w celu ujawnienia defektów interfejsów i interakcji między zintegrowanymi komponentami lub systemami. Zobacz także testowanie integracji komponentów, testowanie integracji systemów.
testowanie interfejsu: Typ testu integracyjnego, który dotyczy testowania interfejsów między komponentami lub systemami.
interoperacyjność: Zdolność oprogramowania do interakcji z jednym lub większą liczbą określonych składników lub systemów. (Po ISO 9126) Zobacz także funkcjonalność.
testowanie interoperacyjności: Proces testowania mający na celu określenie współdziałania oprogramowania. Zobacz także testowanie funkcjonalności.
nieprawidłowe testy: Testowanie przy użyciu wartości wejściowych, które powinny zostać odrzucone przez komponent lub system. Zobacz także tolerancję błędów.
testy izolacji: Testowanie poszczególnych komponentów w izolacji od otaczających komponentów, w razie potrzeby symulując otaczające komponenty za pomocą odgałęzień i sterowników.
DO
testowanie oparte na słowach kluczowych: Technika skryptowa, w której pliki danych zawierają nie tylko dane testowe i oczekiwane wyniki, ale także słowa kluczowe związane z testowaną aplikacją. Słowa kluczowe są interpretowane przez specjalne skrypty pomocnicze, które są wywoływane przez skrypt sterujący do testu. Zobacz także testy oparte na danych.
L
LCSAJ: Liniowa sekwencja kodu i skok, składająca się z następujących trzech elementów (zwykle identyfikowanych przez numery wierszy w liście kodu źródłowego): początek liniowej sekwencji instrukcji wykonywalnych, koniec sekwencji liniowej i wiersz docelowy, do którego przepływ jest przenoszony na końcu sekwencji liniowej.
Zasięg LCSAJ: Procent LCSAJ składnika, który został sprawdzony przez zestaw testów. 100% pokrycia LCSAJ oznacza 100% pokrycie decyzji.
Testy LCSAJ: Technika projektowania testów typu white box, w której przypadki testowe są przeznaczone do wykonywania testów LCSAJ.
zdolność uczenia się: Zdolność oprogramowania do umożliwienia użytkownikowi poznania jego zastosowania. (ISO 9126) Zobacz także użyteczność.
test obciążenia: Typ testu związany z pomiarem zachowania komponentu lub układu przy rosnącym obciążeniu, np. liczba równoległych użytkowników i / lub liczba transakcji w celu określenia, jakie obciążenie może obsłużyć komponent lub system.
przypadek testowy niskiego poziomu: Przypadek testowy z konkretnymi (poziom wdrożenia) wartościami danych wejściowych i oczekiwanymi wynikami.
M
konserwacja: Modyfikacja oprogramowania po dostawie w celu usunięcia usterek, poprawy wydajności lub innych atrybutów lub dostosowania produktu do zmodyfikowanego środowiska. (IEEE 1219)
testy konserwacyjne: Testowanie zmian w systemie operacyjnym lub wpływu zmienionego środowiska na system operacyjny.
konserwowalność: Łatwość, z jaką oprogramowanie może być modyfikowane w celu skorygowania defektów, modyfikowane w celu spełnienia nowych wymagań, modyfikowane w celu ułatwienia przyszłej konserwacji lub przystosowane do zmienionego środowiska. (ISO 9126)
testy konserwacyjne: Proces testowania mający na celu określenie możliwości utrzymania produktu oprogramowania.
przegląd zarządzania: Systematyczna ocena procesu zakupu, dostawy, rozwoju, eksploatacji lub konserwacji oprogramowania, wykonywana przez kierownictwo lub w jego imieniu, która monitoruje postępy, określa stan planów i harmonogramów, potwierdza wymagania i alokację ich spadkobierców systemu lub ocenia skuteczność podejść do zarządzania osiągnięcie przydatności do celu. (Po IEEE 610, IEEE 1028)
dojrzałość: (1) Zdolność organizacji do skuteczności i wydajności jej procesów i praktyk pracy. Zobacz także: Model dojrzałości zdolności, Model dojrzałości testów. (2) Zdolność oprogramowania do unikania awarii w wyniku defektów oprogramowania. (ISO 9126) Zobacz także niezawodność.
pomiar: Liczba lub kategoria przypisana do atrybutu podmiotu poprzez wykonanie pomiaru (ISO 14598).
pomiary: Proces przypisywania liczby lub kategorii do podmiotu w celu opisania atrybutu tego podmiotu. (ISO 14598)
skala pomiaru: Skala, która ogranicza rodzaj analizy danych, którą można na niej przeprowadzić. (ISO 14598)
wyciek pamięci: Defekt w logice dynamicznej alokacji magazynu programu, który powoduje, że nie może odzyskać pamięci po zakończeniu jej używania, co ostatecznie powoduje awarię programu z powodu braku pamięci.
metryczny: Skala pomiaru i metoda zastosowana do pomiaru. (ISO 14598)
kamień milowy: Punkt w czasie w projekcie, w którym zdefiniowano (pośrednie) produkty iwyniki powinny być gotowe.
moderator: Lider i główna osoba odpowiedzialna za inspekcję lub inny proces przeglądu.
monitor: Narzędzie programowe lub urządzenie sprzętowe, które działa równolegle z testowanym komponentem lub systemem i nadzoruje, rejestruje i / lub analizuje zachowanie komponentu lub systemu. (Po IEEE 610)
pokrycie wielu stanów: Procent kombinacji wszystkich pojedynczych warunkówwyniki w ramach jednej instrukcji, które zostały sprawdzone przez zestaw testów. 100% wielokrotnośćpokrycie warunku oznacza 100% pokrycie warunku.
wielokrotne testy stanu: Technika projektowania testów białoskrzynkowych, w której przypadki testowe są zaprojektowane do wykonywania kombinacji wyników pojedynczego warunku (w ramach jednej instrukcji).
analiza mutacji: Metoda określania dokładności zestawu testów poprzez pomiar stopnia, w jakim zestaw testów może odróżnić program od jego niewielkich wariantów (mutantów).
N
Zasięg przełącznika N: Procent sekwencji przejść N + 1, które zostały sprawdzone przez zestaw testów. (Chow)
Testowanie przełącznika N: Forma testowania przejść między stanami, w której przypadki testowe są zaprojektowane tak, aby wykonać wszystkie prawidłowe sekwencje przejść N + 1. (Chow) Zobacz także testowanie przejść między stanami.
negatywne testy: Testy mające na celu wykazanie, że komponent lub system nie działa. Testowanie negatywne jest związane z nastawieniem testerów, a nie z konkretnym podejściem do testów lub techniką projektowania testów. (Po Beizer).
Niezgodność: Niespełnienie określonego wymagania. (ISO 9000)
wymaganie niefunkcjonalne: Wymóg, który nie dotyczy funkcjonalności, ale takich atrybutów, jak niezawodność, wydajność, użyteczność, łatwość konserwacji i przenośność.
testy niefunkcjonalne: Testowanie atrybutów komponentu lub systemu niezwiązanych z funkcjonalnością, np. niezawodność, wydajność, użyteczność, łatwość konserwacji i przenośność.
techniki projektowania testów niefunkcjonalnych: Metody stosowane do projektowania lub wyboru testów do testów niefunkcjonalnych.
LUB
gotowe oprogramowanie: Oprogramowanie opracowane na rynek ogólny, tj. Dla dużej liczby klientów, i które jest dostarczane wielu klientom w identycznym formacie.
funkcjonalność: Zdolność oprogramowania do obsługi i kontrolowania go przez użytkownika. (ISO 9126) Zobacz także użyteczność.
środowisko operacyjne: Sprzęt i oprogramowanie zainstalowane w witrynach użytkowników lub klientów, w których będzie używany testowany komponent lub system. Oprogramowanie może obejmować systemy operacyjne, systemy zarządzania bazami danych i inne aplikacje.
testowanie profilu operacyjnego: Testy statystyczne z wykorzystaniem modelu operacji systemowych (zadania krótkotrwałe) i prawdopodobieństwa ich typowego wykorzystania. (Musa)
testy operacyjne: Testy przeprowadzone w celu oceny komponentu lub systemu w jego środowisku operacyjnym. (IEEE 610)
wynik: Zmienna (przechowywana w komponencie lub na zewnątrz), która jest zapisywana przez komponent.
domena wyjściowa: Zestaw, z którego można wybrać prawidłowe wartości wyjściowe. Zobacz także domain.
wartość wyjściowa: Wystąpienie wyniku. Zobacz także wyjście.
P.
programowanie w parach: Podejście do tworzenia oprogramowania, w którym linie kodu (produkcja i / lub test) komponentu są pisane przez dwóch programistów siedzących przy jednym komputerze. To pośrednio oznacza, że wykonywane są bieżące przeglądy kodu w czasie rzeczywistym.
testowanie par: Dwóch testerów pracuje razem, aby znaleźć usterki. Zazwyczaj dzielą jeden komputer i kontrolują go podczas testów.
Przechodzić: Test uważa się za zaliczony, jeśli jego rzeczywisty wynik jest zgodny z oczekiwanym wynikiem.
kryteria zaliczenia / niezaliczenia: Reguły decyzyjne używane do określenia, czy testowany element (funkcja) lub funkcja przeszły pomyślnie, czy nie przeszły testu. (IEEE 829)
ścieżka: Sekwencja wydarzeń, np. wykonywalne instrukcje składnika lub systemu od punktu wejścia do punktu wyjścia.
pokrycie trasy: Procent ścieżek, które zostały przetestowane przez zestaw testów. 100% pokrycie ścieżki oznacza 100% pokrycie LCSAJ.
uczulające na ścieżkę: Wybór zestawu wartości wejściowych wymuszających wykonanie danej ścieżki.
testowanie ścieżki: Technika projektowania testów typu white box, w której przypadki testowe są przeznaczone do wykonywania ścieżek.
wydajność: Stopień, w jakim system lub komponent spełnia wyznaczone funkcje w ramach określonych ograniczeń dotyczących czasu przetwarzania i przepustowości. (Po IEEE 610) Zobacz efektywność.
wskaźnik wydajności: Wysokopoziomowy miernik skuteczności i / lub wydajności stosowany do kierowania i kontrolowania stopniowego rozwoju, np. Procent wykrycia defektów (DDP) do testowania. (CMMI)
test wydajności: Proces testowania mający na celu określenie wydajności oprogramowania. Zobacz testy wydajności.
narzędzie do testowania wydajności: Narzędzie wspierające testowanie wydajności, które zwykle ma dwa główne udogodnienia: generowanie obciążenia i testowy pomiar transakcji. Generowanie obciążenia może symulować wielu użytkowników lub duże ilości danych wejściowych. Podczas realizacji z wybranych transakcji pobierane są pomiary czasu odpowiedzi, które są rejestrowane. Narzędzia do testowania wydajności zwykle dostarczają raporty oparte na dziennikach testów i wykresach obciążenia względem czasów odpowiedzi.
plan testów fazowych: Plan testów, który zazwyczaj dotyczy jednego poziomu testów.
ruchliwość: Łatwość, z jaką oprogramowanie może być przenoszone z jednego środowiska sprzętowego lub oprogramowania do innego. (ISO 9126)
testowanie przenośności: Proces testowania mający na celu określenie przenośności oprogramowania.
warunek końcowy: Warunki środowiskowe i stanowe, które muszą być spełnione po wykonaniu testu lub procedury testowej.
porównanie porealizacyjne: Porównanie rzeczywistych i oczekiwanych wyników, wykonanych po zakończeniu działania oprogramowania.
warunek wstępny: Warunki środowiskowe i stanowe, które muszą zostać spełnione, zanim komponent lub system będzie mógł zostać wykonany za pomocą określonego testu lub procedury testowej.
Priorytet: Poziom ważności (biznesowej) przypisanej do towaru, np. wada.
test cyklu procesu: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe są przeznaczone do wykonywania procedur i procesów biznesowych. (TMap)
proces: Zestaw powiązanych ze sobą działań, które przekształcają dane wejściowe w produkty. (ISO 12207)
projekt: Projekt to unikalny zestaw skoordynowanych i kontrolowanych działań, których daty rozpoczęcia i zakończenia są realizowane w celu dostosowania się do określonych wymagań, w tym ograniczeń czasowych, kosztowych i zasobów. (ISO 9000)
plan testów projektu: Plan testów, który zazwyczaj obejmuje wiele poziomów testów.
pseudolosowe: Szereg, który wydaje się losowy, ale w rzeczywistości jest generowany zgodnie z jakąś wcześniej ustaloną sekwencją.
Q
jakość: Stopień, w jakim komponent, system lub proces spełnia określone wymagania i / lub potrzeby i oczekiwania użytkownika / klienta. (Po IEEE 610)
Zapewnienie jakości: Część zarządzania jakością koncentruje się na zapewnieniu pewności, że wymagania jakościowe zostaną spełnione. (ISO 9000)
atrybut jakości: Cecha lub cecha, która wpływa na jakość produktu. (IEEE 610)
zarządzanie jakością: Skoordynowane działania mające na celu kierowanie i kontrolowanie organizacji w zakresie jakości. Kierowanie i kontrola w odniesieniu do jakości ogólnie obejmuje ustanowienie polityki jakości i celów jakościowych, planowanie jakości, kontrolę jakości, zapewnienie jakości i poprawę jakości. (ISO 9000)
R
testy losowe: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe są wybierane, prawdopodobnie przy użyciu algorytmu generowania pseudolosowego, w celu dopasowania do profilu operacyjnego. Technika ta może być używana do testowania atrybutów niefunkcjonalnych, takich jak niezawodność i wydajność.
odzyskiwalność: Zdolność oprogramowania do przywrócenia określonego poziomu wydajności i odzyskania danych, na które ma bezpośredni wpływ w przypadku awarii. (ISO 9126) Zobacz także niezawodność.
testy odzysku: Proces testowania mający na celu określenie możliwości odzyskania oprogramowania. Zobacz także testy niezawodności.
testy regresji: Testowanie wcześniej przetestowanego programu po modyfikacji w celu upewnienia się, że w wyniku wprowadzonych zmian nie zostały wprowadzone lub odkryte defekty w niezmienionych obszarach oprogramowania. Jest wykonywany w przypadku zmiany oprogramowania lub jego środowiska.
Informacje o wersji: Dokument identyfikujący pozycje testów, ich konfigurację, aktualny stan i inne informacje o dostarczeniu dostarczone przez programistów do testowania i ewentualnie innych interesariuszy na początku fazy wykonywania testów. (Po IEEE 829)
niezawodność: Zdolność oprogramowania do wykonywania wymaganych funkcji w określonych warunkach przez określony czas lub określoną liczbę operacji. (ISO 9126)
testy niezawodności: Proces testowania mający na celu określenie niezawodności oprogramowania.
wymienność: Możliwość użycia oprogramowania zamiast innego określonego oprogramowania do tego samego celu w tym samym środowisku. (ISO 9126) Zobacz także przenośność.
wymaganie: Warunek lub zdolność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia celu, który musi być spełniony lub posiadany przez system lub komponent systemu, aby spełnić warunki umowy, normy, specyfikacji lub innego formalnie narzuconego dokumentu. (Po IEEE 610)
testowanie oparte na wymaganiach: Podejście do testowania, w którym przypadki testowe są projektowane w oparciu o cele testów i warunki testowe wyprowadzone z wymagań, np. testy, które wykonują określone funkcje lub sondują atrybuty niefunkcjonalne, takie jak niezawodność lub użyteczność.
narzędzie do zarządzania wymaganiami: Narzędzie, które wspiera rejestrowanie wymagań, atrybutów wymagań (np. Priorytet, wiedza odpowiedzialna) i adnotacje oraz ułatwia identyfikowalność poprzez warstwy wymagań i zarządzanie zmianami wymagań. Niektóre narzędzia do zarządzania wymaganiami zapewniają również narzędzia do analizy statycznej, takiej jak sprawdzanie spójności i naruszenia wstępnie zdefiniowanych reguł wymagań.
faza wymagań: Okres w cyklu życia oprogramowania, podczas którego wymagania dotyczące oprogramowania są definiowane i dokumentowane. (IEEE 610)
utylizacja zasobów: Zdolność oprogramowania do wykorzystywania odpowiednich ilości i typów zasobów, na przykład ilości pamięci głównej i dodatkowej używanej przez program oraz rozmiarów wymaganych plików tymczasowych lub przepełnienia, gdy oprogramowanie wykonuje swoją funkcję w określonych warunkach. (Po ISO 9126) Zobacz także efektywność.
testowanie wykorzystania zasobów: Proces testowania mający na celu określenie wykorzystania zasobów oprogramowania.
wynik: Konsekwencja / wynik wykonania testu. Obejmuje wyjścia na ekrany, zmiany danych, raporty i wysłane komunikaty komunikacyjne. Zobacz także rzeczywisty wynik, oczekiwany wynik.
kryteria wznowienia: Czynności testowe, które należy powtórzyć w przypadku wznowienia testów po zawieszeniu. (Po IEEE 829)
ponowne testowanie: Testowanie, które uruchamia przypadki testowe, które zakończyły się niepowodzeniem podczas ostatniego uruchomienia, w celu zweryfikowania sukcesu działań naprawczych.
przejrzeć: Ocena stanu produktu lub projektu w celu ustalenia rozbieżności w stosunku do planowanych wyników i zalecenia ulepszeń. Przykłady obejmują przegląd kierownictwa, przegląd nieformalny, przegląd techniczny, inspekcję i instruktaż. (Po IEEE 1028)
recenzent: Osoba zaangażowana w przegląd, która powinna zidentyfikować i opisać anomalie w badanym produkcie lub projekcie. Recenzentów można wybrać, aby reprezentowali różne punkty widzenia i role w procesie przeglądu.
ryzyko: Czynnik, który może spowodować w przyszłości negatywne konsekwencje; zwykle wyrażane jako wpływ i prawdopodobieństwo.
ocena ryzyka: Proces oceny zidentyfikowanych ryzyk w celu oszacowania ich wpływu i prawdopodobieństwa wystąpienia (prawdopodobieństwa).
testowanie oparte na ryzyku: Testowanie ukierunkowane na badanie i dostarczanie informacji o ryzyku produktowym. (Według Gerrarda)
kontrola ryzyka: Proces, w ramach którego podejmowane są decyzje i wdrażane są środki ochronne w celu zmniejszenia lub utrzymania ryzyka na określonych poziomach.
identyfikacja ryzyka: Proces identyfikacji zagrożeń przy użyciu technik takich jak burza mózgów, listy kontrolne i historia niepowodzeń.
zarządzanie ryzykiem: Systematyczne stosowanie procedur i praktyk do zadań związanych z identyfikacją, analizą, ustalaniem priorytetów i kontrolowaniem ryzyka.
krzepkość: Stopień, w jakim komponent lub system może działać poprawnie w obecności nieprawidłowych danych wejściowych lub stresujących warunków środowiskowych. (IEEE 610) Patrz także tolerancja błędów, tolerancja błędów.
główna przyczyna: Podstawowy czynnik, który spowodował niezgodność i prawdopodobnie powinien zostać trwale wyeliminowany poprzez usprawnienie procesu.
S
bezpieczeństwo: Zdolność oprogramowania do osiągania akceptowalnych poziomów ryzyka szkody dla ludzi, biznesu, oprogramowania, mienia lub środowiska w określonym kontekście użytkowania. (ISO 9126)
testy bezpieczeństwa: Proces testowania mający na celu określenie bezpieczeństwa oprogramowania.
skalowalność: Możliwość aktualizacji oprogramowania w celu dostosowania do zwiększonych obciążeń. (Według Gerrarda)
testy skalowalności: Testowanie w celu określenia skalowalności oprogramowania.
skryba: Osoba, która musi odnotować każdą wymienioną wadę i wszelkie sugestie dotyczące poprawy podczas spotkania przeglądowego, na formularzu logowania. Skryba musi upewnić się, że formularz logowania jest czytelny i zrozumiały.
język skryptowy: Język programowania, w którym napisane są wykonywalne skrypty testowe, używany przez narzędzie do wykonywania testów (np. Narzędzie do przechwytywania / odtwarzania).
bezpieczeństwo: Atrybuty oprogramowania, które mają wpływ na jego zdolność do zapobiegania nieautoryzowanemu dostępowi, przypadkowemu lub celowemu, do programów i danych. (ISO 9126)
testy bezpieczeństwa: Testowanie w celu określenia bezpieczeństwa oprogramowania.
surowość: Stopień wpływu, jaki wada ma na rozwój lub działanie komponentu lub systemu. (Po IEEE 610)
symulacja: Reprezentacja wybranych cech behawioralnych jednego systemu fizycznego lub abstrakcyjnego przez inny system. (ISO 2382/1)
symulator: Urządzenie, program komputerowy lub system używany podczas testowania, który zachowuje się lub działa jak dany system, gdy jest wyposażony w zestaw kontrolowanych wejść. (Po IEEE 610, DO178b) Zobacz także emulator.
Test dymu: Podzbiór wszystkich zdefiniowanych / planowanych przypadków testowych, które obejmują główną funkcjonalność komponentu lub systemu, w celu ustalenia, czy działają najważniejsze funkcje programu, ale bez zawracania sobie głowy drobniejszymi szczegółami. Codzienne testy kompilacji i dymu należą do najlepszych praktyk w branży. Zobacz także test spożycia.
jakość oprogramowania: Całość funkcjonalności i cech oprogramowania, które mają wpływ na jego zdolność do zaspokojenia określonych lub dorozumianych potrzeb. (Po ISO 9126)
specyfikacja: Dokument określający, najlepiej w sposób kompletny, precyzyjny i możliwy do zweryfikowania, wymagania, projekt, zachowanie lub inne cechy komponentu lub systemu, a często również procedury określania, czy te przepisy zostały spełnione. (Po IEEE 610)
technika projektowania testów oparta na specyfikacji: Zobacz technikę projektowania testów czarnoskrzynkowych.
określone dane wejściowe: Dane wejściowe, dla których specyfikacja przewiduje wynik.
stabilność: Zdolność oprogramowania do unikania nieoczekiwanych skutków modyfikacji oprogramowania. (ISO 9126) Patrz także łatwość konserwacji.
schemat stanu: Diagram przedstawiający stany, które komponent lub system może przyjąć, i pokazuje zdarzenia lub okoliczności, które powodują i / lub wynikają ze zmiany z jednego stanu na inny. (IEEE 610)
tabela stanów: Siatka pokazująca wynikowe przejścia dla każdego stanu w połączeniu z każdym możliwym zdarzeniem, pokazująca zarówno prawidłowe, jak i nieprawidłowe przejścia.
zmiana stanu: Przejście między dwoma stanami komponentu lub systemu.
testowanie przejść między stanami: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe są zaprojektowane do wykonywania prawidłowych i nieprawidłowych przejść między stanami. Zobacz także testowanie przełączników N.
komunikat: Jednostka w języku programowania, która jest zazwyczaj najmniejszą niepodzielną jednostką wykonania.
zakres oświadczenia: Procent instrukcji wykonywalnych, które zostały sprawdzone przez zestaw testów.
testowanie instrukcji: Technika projektowania testów typu white box, w której przypadki testowe są zaprojektowane do wykonywania instrukcji.
analiza statyczna: Analiza artefaktów oprogramowania, np. wymagań lub kodu, wykonywane bez wykonywania tych artefaktów oprogramowania.
analizator statyczny: Narzędzie, które przeprowadza analizę statyczną.
statyczna analiza kodu: Analiza kodu źródłowego programu przeprowadzona bez wykonywania tego oprogramowania.
analizator kodu statycznego: Narzędzie, które przeprowadza statyczną analizę kodu. Narzędzie sprawdza kod źródłowy pod kątem pewnych właściwości, takich jak zgodność ze standardami kodowania, metryki jakości lub anomalie przepływu danych.
badania statyczne: Testowanie komponentu lub systemu na poziomie specyfikacji lub wdrożenia bez wykonywania tego oprogramowania, np. przeglądy lub statyczna analiza kodu.
testy statystyczne: Technika projektowania testów, w której model rozkładu statystycznego danych wejściowych jest używany do konstruowania reprezentatywnych przypadków testowych. Zobacz także testowanie profilu operacyjnego.
rozliczanie statusu: Element zarządzania konfiguracją polegający na rejestrowaniu i raportowaniu informacji potrzebnych do efektywnego zarządzania konfiguracją. Informacje te obejmują wykaz zatwierdzonych identyfikatorów konfiguracji, status proponowanych zmian w konfiguracji oraz stan wdrożenia zatwierdzonych zmian. (IEEE 610)
Test naprężeń: Testy przeprowadzone w celu oceny systemu lub komponentu na poziomie lub poza granicami określonych wymagań. (IEEE 610)
pokrycie strukturalne: Miary pokrycia oparte na wewnętrznej strukturze komponentu.
technika projektowania testów strukturalnych: Zobacz technikę projektowania testów typu white box.
kikut: Szkieletowa lub specjalnego przeznaczenia implementacja komponentu oprogramowania, używana do tworzenia lub testowania komponentu, który wywołuje lub jest w inny sposób od niej zależny. Zastępuje wywołany komponent. (Po IEEE 610)
podścieżka: Sekwencja instrukcji wykonywalnych w komponencie.
kryteria zawieszenia: Kryteria używane do (tymczasowego) zatrzymania wszystkich lub części czynności testowych na pozycjach testowych. (Po IEEE 829)
stosowność: Zdolność oprogramowania do zapewniania odpowiedniego zestawu funkcji do określonych zadań i celów użytkownika. (ISO 9126) Zobacz także funkcjonalność.
Inwentaryzacja pomiaru użyteczności oprogramowania (SUMI): Technika testowania użyteczności oparta na kwestionariuszu do oceny użyteczności, np. satysfakcja użytkownika komponentu lub systemu. (Veenendaal)
testowanie składni: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe są projektowane w oparciu o definicję domeny wejściowej i / lub domeny wyjściowej.
system: Zbiór komponentów zorganizowanych w celu wykonania określonej funkcji lub zestawu funkcji. (IEEE 610)
testy integracji systemów: Testowanie integracji systemów i pakietów; testowanie interfejsów do organizacji zewnętrznych (np. Electronic Data Interchange, Internet).
testowanie systemu: Proces testowania zintegrowanego systemu w celu sprawdzenia, czy spełnia on określone wymagania. (Hetzel)
T
Przegląd techniczny: Dyskusja w grupie rówieśniczej skupiająca się na osiągnięciu konsensusu co do technicznego podejścia, jakie należy przyjąć. Recenzja techniczna jest również nazywana recenzją. (Gilb i Graham, IEEE 1028)
przetestuj swoją witrynę w różnych przeglądarkach
podejście testowe: Wdrożenie strategii testów dla konkretnego projektu. Zwykle obejmuje decyzje podjęte na podstawie celu projektu (testowego) i przeprowadzonej oceny ryzyka, punkty początkowe dotyczące procesu testowania, zastosowane techniki projektowania testów, kryteria zakończenia i typy testów do wykonania.
automatyzacja testów: Wykorzystanie oprogramowania do wykonywania lub wspomagania czynności testowych, np. zarządzanie testami, projektowanie testów, wykonywanie testów i sprawdzanie wyników.
podstawa testu: Wszystkie dokumenty, z których można wywnioskować wymagania komponentu lub systemu. Dokumentacja, na której oparte są przypadki testowe. Jeżeli dokument można zmienić tylko w drodze formalnej procedury zmiany, wówczas podstawa testu nazywana jest zamrożoną podstawą testu. (Po TMap)
przypadek testowy: Zestaw wartości wejściowych, warunków wstępnych wykonania, oczekiwanych wyników i warunków końcowych wykonania, opracowanych dla określonego celu lub warunku testu, takich jak ćwiczenie określonej ścieżki programu lub weryfikacja zgodności z określonym wymaganiem. (Po IEEE 610)
specyfikacja przypadku testowego: Dokument określający zestaw przypadków testowych (cel, dane wejściowe, działania testowe, oczekiwane wyniki i warunki wstępne wykonania) dla elementu testowego. (Po IEEE 829)
karta testowa: Zestawienie celów testu i ewentualnie pomysłów na test. Karty testów są między innymi używane w testowaniu eksploracyjnym. Zobacz także testy eksploracyjne.
test porównawczy: Narzędzie testowe do automatycznego porównywania testów.
porównanie testów: Proces identyfikowania różnic między rzeczywistymi wynikami uzyskanymi przez testowany komponent lub system a oczekiwanymi wynikami testu. Porównanie testów można przeprowadzić podczas wykonywania testów (porównanie dynamiczne) lub po ich wykonaniu.
stan testu: Przedmiot lub zdarzenie komponentu lub systemu, które można zweryfikować za pomocą co najmniej jednego przypadku testowego, np. funkcja, transakcja, atrybut jakości lub element strukturalny.
dane testowe: Dane, które istnieją (na przykład w bazie danych) przed wykonaniem testu i mają wpływ na testowany komponent lub system lub mają na nie wpływ.
narzędzie do przygotowywania danych testowych: Rodzaj narzędzia testowego, które umożliwia wybieranie danych z istniejących baz danych lub tworzenie, generowanie, manipulowanie i edytowanie w celu wykorzystania w testowaniu.
specyfikacja projektu testu: Dokument określający warunki testowe (elementy pokrycia) dla elementu testowego, szczegółowe podejście testowe oraz identyfikujący powiązane przypadki testowe wysokiego poziomu. (Po IEEE 829)
narzędzie do projektowania testów: Narzędzie wspierające czynności projektowania testów poprzez generowanie danych wejściowych do testów ze specyfikacji, która może być przechowywana w repozytorium narzędzi CASE, np. narzędzie do zarządzania wymaganiami lub z określonych warunków testowych przechowywanych w samym narzędziu.
technika projektowania testów: Metoda używana do wyprowadzania lub wybierania przypadków testowych.
Środowisko testowe: Środowisko zawierające sprzęt, oprzyrządowanie, symulatory, narzędzia programowe i inne elementy pomocnicze potrzebne do przeprowadzenia testu. (Po IEEE 610)
raport oceny testu: Dokument utworzony na koniec procesu testowania, podsumowujący wszystkie czynności testowe i wyniki. Zawiera również ocenę procesu testowania i wyciągnięte wnioski.
wykonanie testu: Proces przeprowadzania testu przez testowany komponent lub system, prowadzący do uzyskania rzeczywistych wyników.
automatyzacja wykonywania testów: Korzystanie z oprogramowania, np. narzędzia do przechwytywania / odtwarzania, służące do kontrolowania wykonywania testów, porównywania wyników rzeczywistych z oczekiwanymi, określania warunków wstępnych testów oraz innych funkcji kontroli testów i raportowania.
faza wykonania testu: Okres czasu w cyklu życia wytwarzania oprogramowania, podczas którego komponenty produktu programowego są wykonywane, a produkt programowy jest oceniany w celu ustalenia, czy wymagania zostały spełnione. (IEEE 610)
harmonogram wykonania testów: Schemat wykonywania procedur testowych. Procedury testowe są zawarte w harmonogramie wykonywania testów w ich kontekście oraz w kolejności, w jakiej mają być wykonywane.
technika wykonania testów: Metoda zastosowana do wykonania rzeczywistego testu,ręcznie lub automatycznie.
narzędzie do wykonywania testów: Rodzaj narzędzia testowego, które jest w stanie wykonać inne oprogramowanie za pomocą automatycznego skryptu testowego, np. przechwytywanie / odtwarzanie. (Fewster i Graham)
wiązka testowa: Środowisko testowe składające się z kodów pośredniczących i sterowników potrzebnych do przeprowadzenia testu.
infrastruktura testowa: Artefakty organizacyjne potrzebne do przeprowadzania testów, obejmujące środowiska testowe, narzędzia testowe, środowisko biurowe i procedury.
obiekt testowy: Indywidualny element do przetestowania. Zwykle jest jeden obiekt testowy i wiele elementów testowych. Zobacz także obiekt testowy.
poziom testu: Grupa czynności testowych, które są wspólnie organizowane i zarządzane. Poziom testu jest powiązany z obowiązkami w projekcie. Przykłady poziomów testów to test modułowy, test integracyjny, test systemowy i test akceptacyjny. (Po TMap)
dziennik testów: Chronologiczny zapis istotnych szczegółów dotyczących wykonywania testów. (IEEE 829)
logowanie testowe: Proces rejestrowania informacji o wykonanych testach w dzienniku testów.
kierownik testów: Osoba odpowiedzialna za testowanie i ocenę obiektu testowego. Osoba, która kieruje, kontroluje, administruje, planuje i reguluje ocenę obiektu testowego.
zarządzanie testami: Planowanie, szacowanie, monitorowanie i kontrola czynności testowych, zazwyczaj wykonywane przez kierownika testów.
Model dojrzałości testowej (TMM): Pięciopoziomowy framework do doskonalenia procesu testowego, powiązany z modelem dojrzałości zdolności (CMM), który opisuje kluczowe elementy efektywnego procesu testowego.
Udoskonalenie procesu testowego (TPI): Ciągłe ramy doskonalenia procesów testowych, które opisują kluczowe elementy efektywnego procesu testowego, szczególnie ukierunkowane na testowanie systemowe i testy akceptacyjne.
obiekt testowy: Testowany komponent lub system. Zobacz także element testowy.
cel testu: Powód lub cel zaprojektowania i wykonania testu.
test wyrocznia: Źródło określające oczekiwane wyniki w celu porównania ich z rzeczywistym wynikiem testowanego oprogramowania. Wyrocznia może być istniejącym systemem (dla punktu odniesienia), instrukcją obsługi lub specjalistyczną wiedzą danej osoby, ale nie powinna być kodem. (Po Adrion)
wskaźnik wykonania testu: Miara, ogólnie wysoki poziom, wskazująca, w jakim stopniu została spełniona określona wartość docelowa lub kryterium. Często związane z celami doskonalenia procesu testowego, np. Procent wykrycia defektów (DDP).
faza testowa: Odrębny zestaw czynności testowych zebranych w zarządzalnej fazie projektu, np. czynności wykonawcze na poziomie testów. (Według Gerrarda)
plan testów: Dokument opisujący zakres, podejście, zasoby i harmonogram planowanych czynności testowych. Identyfikuje między innymi elementy testów, cechy, które mają być testowane, zadania testowe, kto wykona każde zadanie, stopień niezależności testera, środowisko testowe, techniki projektowania testów i techniki pomiaru testów, które mają być użyte, oraz uzasadnienie ich wyboru. oraz wszelkie ryzyka wymagające planowania awaryjnego. Jest to zapis procesu planowania testów (po IEEE 829)
planowanie testów: Czynność polegająca na tworzeniu lub aktualizowaniu planu testów.
zasady testów: Dokument wysokiego poziomu opisujący zasady, podejście i główne cele organizacji dotyczące testowania.
Analiza punktów testowych (TPA): Metoda szacowania testów oparta na wzorze oparta na analizie punktów funkcyjnych. (TMap)
Procedura testowa: Zobacz specyfikację procedury testowej.
specyfikacja procedury testowej: Dokument określający sekwencję działań w celu wykonania testu. Znany również jako skrypt testowy lub ręczny skrypt testowy. (Po IEEE 829)
proces testowy: Podstawowy proces testowy obejmuje planowanie, specyfikację, wykonanie, rejestrowanie i sprawdzanie ukończenia. (BS 7925/2)
powtarzalność testu: Atrybut testu wskazujący, czy te same wyniki są generowane za każdym razem, gdy test jest wykonywany.
testowe uruchomienie: Wykonanie testu na określonej wersji obiektu testowego.
skrypt testowy: Powszechnie używane w odniesieniu do specyfikacji procedury testowej, zwłaszcza zautomatyzowanej.
specyfikacja testu: Dokument składający się ze specyfikacji projektu testów, specyfikacji przypadku testowego i / lub specyfikacji procedury testowej.
strategia testów: Dokument wysokiego poziomu określający poziomy testów do wykonania oraz testowanie w ramach tych poziomów dla programu (jednego lub więcej projektów).
zestaw testów: Zestaw kilku przypadków testowych dla testowanego komponentu lub systemu, w których stan po jednym teście jest często używany jako warunek wstępny dla następnego.
raport podsumowujący test: Dokument podsumowujący czynności testowe i wyniki. Zawiera również ocenę odpowiednich pozycji testowych pod kątem kryteriów zakończenia.(Po IEEE 829)
cel testowy: Zestaw kryteriów zakończenia.
narzędzie testowe: Oprogramowanie obsługujące jedną lub więcej czynności testowych, takich jak planowanie i kontrola, specyfikacja, tworzenie początkowych plików i danych, wykonywanie testów i analiza testów. (TMap) Zobacz także CAST.
typ testu: Grupa czynności testowych, których celem jest przetestowanie komponentu lub systemu pod kątem jednego lub większej liczby powiązanych ze sobą atrybutów jakości. Typ testu koncentruje się na określonym celu testu, tj. Teście niezawodności, teście użyteczności, teście regresji itp. I może mieć miejsce na jednym lub kilku poziomach testów lub fazach testów. (Po TMap)
testowalność: Zdolność oprogramowania do testowania zmodyfikowanego oprogramowania. (ISO 9126) Patrz także łatwość konserwacji.
przegląd testowalności: Szczegółowe sprawdzenie podstawy testów w celu ustalenia, czy podstawa testów jest na odpowiednim poziomie jakości, aby działać jako dokument wejściowy dla procesu testowego. (Po TMap)
testowalne wymagania: Stopień, w jakim wymaganie jest określone w kategoriach, które pozwalają na tworzenie projektów testów (a następnie przypadków testowych) i wykonywanie testów w celu określenia, czy wymagania zostały spełnione. (Po IEEE 610)
próbnik: Wykwalifikowany technicznie specjalista, który jest zaangażowany w testowanie komponentu lub systemu.
testowanie: Proces składający się ze wszystkich działań w cyklu życia, zarówno statycznych, jak i dynamicznych, związanych z planowaniem, przygotowaniem i oceną oprogramowania i powiązanych produktów pracy w celu ustalenia, czy spełniają one określone wymagania, wykazania, że są one odpowiednie do celu oraz wykrycia wad.
testware: Artefakty powstałe podczas procesu testowego wymagane do planowania, projektowania i wykonywania testów, takie jak dokumentacja, skrypty, dane wejściowe, oczekiwane wyniki, procedury konfiguracji i czyszczenia, pliki, bazy danych, środowisko oraz wszelkie dodatkowe oprogramowanie lub narzędzia używane w testowanie. (Po Fewsterze i Grahamie)
testowanie wątków: Wersja testowania integracji komponentów, w której stopniowa integracja komponentów następuje po wdrożeniu podzbiorów wymagań, w przeciwieństwie do integracji komponentów według poziomów hierarchii.
identyfikowalność: Możliwość identyfikacji powiązanych elementów w dokumentacji i oprogramowaniu, takich jakwymagania wraz z powiązanymi testami. Zobacz także identyfikowalność poziomą, identyfikowalność pionową.
testowanie odgórne: Przyrostowe podejście do testowania integracji, w którym najpierw testowany jest komponent znajdujący się na szczycie hierarchii komponentów, a komponenty niższego poziomu są symulowane przez kody pośredniczące. Przetestowane komponenty są następnie używane do testowania komponentów niższego poziomu. Proces powtarza się do czasu przetestowania komponentów najniższego poziomu.
U
wyrozumiałość: Zdolność oprogramowania do umożliwienia użytkownikowi zrozumienia, czy oprogramowanie jest odpowiednie i jak może być używane do określonych zadań i warunków użytkowania. (ISO 9126) Zobacz także użyteczność.
nieosiągalny kod: Kod, do którego nie można dotrzeć, a zatem nie można go wykonać.
użyteczność: Zdolność oprogramowania do zrozumienia, nauczenia się, używania i atrakcyjnego dla użytkownika, gdy jest używane w określonych warunkach. (ISO 9126)
test użyteczności: Testowanie w celu określenia stopnia, w jakim oprogramowanie jest zrozumiałe, łatwe do nauczenia, łatwe w obsłudze i atrakcyjne dla użytkowników w określonych warunkach. (Po ISO 9126)
testy przypadków użycia: Technika projektowania testów czarnoskrzynkowych, w której przypadki testowe są przeznaczone do wykonywania scenariuszy użytkownika.
test użytkownika: Test, w którym prawdziwi użytkownicy są zaangażowani w ocenę użyteczności komponentu lub systemu.
V
Model V: Struktura opisująca cykl życia oprogramowania, od specyfikacji wymagań do utrzymania. Model V ilustruje, jak czynności testowe można zintegrować z każdą fazą cyklu życia oprogramowania.
uprawomocnienie: Potwierdzenie poprzez badanie i poprzez dostarczenie obiektywnych dowodów, że wymagania dotyczące określonego zamierzonego zastosowania lub zastosowania zostały spełnione. (ISO 9000)
zmienna: Element pamięci w komputerze, do którego program ma dostęp poprzez odniesienie się do niego za pomocą nazwy.
weryfikacja: Potwierdzenie poprzez badanie i dostarczenie obiektywnych dowodów, że określone wymagania zostały spełnione. (ISO 9000)
identyfikowalność pionowa: Śledzenie wymagań przez warstwy dokumentacji programistycznej do komponentów.
testowanie objętości: Testy, w których system jest narażony na duże ilości danych. Zobacz także testowanie wykorzystania zasobów.
W
opis przejścia: Prezentacja krok po kroku przez autora dokumentu w celu zebrania informacji i ustalenia wspólnego rozumienia jego treści. (Freedman i W.einberg, IEEE 1028)
technika projektowania testów białej skrzynki: Udokumentowana procedura wyprowadzania i wybierania przypadków testowych na podstawie analizy wewnętrznej struktury komponentu lub systemu.
testy białoskrzynkowe: Testowanie oparte na analizie wewnętrznej struktury komponentu lub systemu.
Szerokopasmowe Delphi: Technika szacowania testów oparta na ekspertyzie, której celem jest dokonanie dokładnej oceny przy użyciu zbiorowej mądrości członków zespołu.
Skontaktuj się ze mną jeśli chcesz dodać więcej definicji w tym glosariuszu.
Źródła: http://www.istqb.org/downloads/glossary-1.0.pdf
rekomendowane lektury
- Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
- Asystent testowania oprogramowania
- Kurs testowania oprogramowania: Do którego Instytutu Testowania Oprogramowania mam dołączyć?
- Wybór testowania oprogramowania jako swojej kariery
- Testowanie oprogramowania Praca pisarz treści technicznych Freelancer
- Przewodnik po outsourcingu QA: Testowanie oprogramowania Firmy outsourcingowe
- Kilka interesujących pytań do rozmowy kwalifikacyjnej dotyczącej testowania oprogramowania
- Opinie i recenzje dotyczące kursu testowania oprogramowania