Deutsch |
| Term |
Definition |
| A |
|
| Ablauftest |
Ein Anwendungsfall beschreibt die Reihenfolge von Aktionen, die ein System ausführt und die zu einem erkennbaren Ergebnis mit Wert für den Handelnden (Akteur) führt.
|
| Abnahme |
Siehe Abnahmetest. |
| Abnahmekriterien |
Diejenigen Kriterien, die ein System oder eine Komponente erfüllen muß, um eine Abnahme durch den Anwender, Kunden oder eine bevollmächtigte Instanz erfolgreich abschließen zu können. [IEEE 610]
|
| Abnahmetest
( Akzeptanztest ) |
Formales Testen hinsichtlich der Benutzeranforderungen und -bedürfnisse bzw. der Geschäftsprozesse, das durchgeführt wird, um einen Auftraggeber oder eine bevollmächtigte Instanz in die Lage zu versetzen auf der Basis der Abnahmekriterien entscheiden zu können, ob ein System anzunehmen ist oder nicht. [nach IEEE 610]
|
| Abschluss der Testaktivitäten |
Während des Abschlusses der Testaktivitäten werden die gesammelten Daten aus den abgeschlossenen Aktivitäten verwendet um die Erfahrungen und Testmittel zu konsolidieren.
Siehe auch Testprozess. |
| Abstrakter Testfall
|
Ein Testfall ohne konkrete Ein- und Ausgabewerte für alle Eingabedaten und erwarteten Ergebnisse. Logische Operatoren werden verwendet, die konkreten sind noch nicht definiert oder verfügbar.
Siehe auch konkreter Testfall. |
| Abstrakter Testfall |
Siehe logischer Testfall. |
| Abweichung
|
(1) Siehe Vorfall.
(2) Abweichung der Software vom erwarteten Sollverhalten oder Dienst |
| Abweichung |
(1) Unterschied zwischen einem Merkmalswert
oder einem Merkmal zugeordneten Wert
und einem Bezugswert. [DIN 66272]
(2) Abweichung der Software vom erwarteten Sollverhalten oder Dienst.
|
| Abweichung |
Jedes Ereignis, welches während eines Tests auftritt und weiterer Untersuchungen bedarf. [nach IEEE 1008]. |
| Abweichungsbericht
|
Siehe Vorfallsbericht.
|
| Abweichungsbericht |
Ein Dokument, welches jedes Ereignis auflistet, welches während eines Tests auftritt und weiterer Untersuchungen bedarf [nach IEEE 829].
Synonym: Vorfallsbericht. |
| Abweichungsmanagement |
Prozess der Erkennung, Analyse, Bearbeitung und Abschluss eines aufgedeckten Fehlers. Er beinhaltet die Aufzeichnung, Klassifizierung und die Identifikation der betroffenen Auswirkungen. [nach IEEE 1044]
Synnonym: Fehlermanagement
|
| Abweichungsmanagement |
Die Prozessschritte zur Erkennung, Überwachung und der Behebung von Abweichungen. Sie beinhalten die Aufzeichnung, Klassifizierung und Analyse der Ursachen von Abweichungen. [nach IEEE 1044]
Synonym: Fehlermanagement. |
| Abweichungsmanagementwerkzeug |
Ein Werkzeug, welches die Aufzeichnung und Statusverfolgung von Abweichungen während des Testens ermöglicht. Es beinhaltet oft eine Workflowkomponente um die Sammlung, Korrektur und den Fehlernachtest von Vorfällen/Abweichungen verfolgen, steuern und über Berichtsfunktionen darstellen zu können.
Synonym: Fehlermanagementwerkzeug. |
| Abweichungsmanagementwerkzeug |
Ein Werkzeug, welches die Aufzeichnung und Statusverfolgung von Abweichungen während des Testens ermöglicht. Es beinhaltet oft eine Workflowkomponente um die Sammlung, Korrektur und den Fehlernachtest von Vorfällen verfolgen, steuern und über Berichtsfunktionen darstellen zu können.
Synonym: Fehlermanagementwerkzeug. |
| Abweichungsprotokollierung |
Prozess der Erstellung des Abweichungsberichtes
Siehe auch Abweichungsbericht |
| Ad hoc review |
Siehe informelles Review
|
| Ad-hoc Testen
|
Informelles Testen bei dem keine Testvorbereitung stattfindet und keine erkennbare Testentwurfverfahren verwendet werden. Es werden keine erwarteten Ergebnisse vorab spezifiziert und die Testdurchführung erfolgt mehr oder minder willkürlich.
Siehe auch: exploratives Testen
|
| Agiles Testen |
Eine Testvorgehensweise, welche im Umfeld der Anwendung von agilen Methoden wie z.B. Extreme Programming (XP) den Test-First-Programming-Ansatz propagiert.
Siehe auch EXtreme Programming.
Siehe auch test-driven development.
|
| Akzeptanztest |
siehe Abnahmetest (Akzeptanztest) |
| algorithm test [TMap] |
Siehe Zweigtest. |
| Alpha-Test |
Tests beim Hersteller durch potentiellen Kunden/Anwender oder ein unabhängiges Testteam in einer Simulations- oder Nutzungsumgebung, die nicht anderweitig für die Entwicklung der Software genutzt werden.
Anmerkung:
Ein Alpha-Test kann als eine Form des internen Akzeptanztests für Standardsoftware betrachtet werden.
|
| Analysator |
(1) Siehe statischer Analysator.
|
| Analyse der Auswirkungen |
Die Bewertung der Auswirkung einer Änderung über die Ebenen der Entwicklungsdokumentation, Testdokumentation und Komponenten, um eine vorgegebene Änderung der spezifizierten Anforderungen zu implementieren. |
| Analysewerkzeug |
Siehe statischs Analysewerkzeug, dyamisches Analysewerkzeug |
| Analysierbarkeit |
Das Leistungsvermögen/die Fähigkeit eines Software-Produkts Mängel oder Ursachen von Versagen zu diagnostizieren oder änderungsbedürftige Teile zu bestimmen. [ISO 9126] [DIN 66272]
Siehe auch Wartbarkeitstest.
|
| analytische Qualitätssicherung
|
Diagnostische Maßnahmen (z.B. Testen) zur Bestimmung bzw. Bewertung der Qualität eines Produkts.
|
| Anforderung |
(1) Eigenschaft oder Fähigkeit, die von einem Anwender zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird,
(2) Eigenschaft oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen. [nach IEEE 610]
|
| Anforderungs-
analyse |
Eine Phase im Softwarelebenszyklus, in der die Anforderungen eines Software-Produkts (ermittelt,) definiert und dokumentiert werden. [IEEE 610] |
| anforderungsbasierter Test |
Test, der auf den aus den Anforderungen abgeleiteten (Test-)Zielen und Testbedingungen für die Software(-komponente) z.B. Tests, welche die spezifischen Funktionen überprüfen oder aber die nicht-funktionalen Eigenschaften wie Zuverlässigkeit oder Benutzbarkeit untersuchen.
|
| Anforderungsdefinition |
(1) Schriftliche Dokumentation der Anforderungen an ein Enwicklungs(zwischen) produkt.
Typischerweise enthält die Dokumentation funktionale Anforderungen, Performanzanforderungen, Schnittstellenbeschreibungen, Designanforderungen und Entwicklungsstandards. [IEEE 610.12]
(2) Entwicklungsphase (des allgemeinen V-Modells), in der die Anforderungen an das zu erstellende Softwaresystem gesammelt, spezifiziert und verabschiedet werden.
|
| Anforderungsmanagementwerkzeug |
Ein unterstützendes Werkzeug für die Verwaltung, das Änderungsmanagement und die Rückverfolgung von Anforderungen und Dokumente und ihre zugeordnete Attribute (wie z.B. Priorität, Know-How-Träger).
Einige Anforderungsmanagementwerkzeuge ermöglichen Konsistenzprüfungen und die Aufdeckung der Abweichung von vordefinierten Anforderungsregeln.
|
| Angemessenheit |
Die Fähigkeit/das Vermögen eines Softwareprodukts für spezifizierte Aufgaben und Anwenderziele einen geeigneten Satz Funktionen zu liefern. [ISO 9126]
Synonym: Eignung.
Siehe auch Funktionalität.
|
| Annahme |
siehe Abnahme |
| Anomalie |
Jede Unstimmigkeit, die von den Erwartungen basierend auf Anforderungsspezifikationen, Entwurfsspezifikationen, Benutzerdokumentationen, Standards oder sonstigen Erfahrungen abweicht. Anomalien können auch durch Reviews, Testen, Analysen, Kompilierung oder die Benutzung des Software-Produkts oder seiner Dokumentation aufgedeckt werden. [IEEE 1044]
Siehe auch: Fehlfunktion, Defekt, Abweichung, Fehler, Ausfall, Fehlerzustand, Fehlerwirkung, Problem, Mangel, Vorfall.
Anmerkung:
Eine Anomalie kann zu einer Fehlerwirkung führen, muss aber nicht zwingend dazu führen (anomal: unregelmäßig, regelwidrig).
|
| Anpassbarkeit |
Merkmale von Software, die sich auf die Möglichkeit beziehen, sie an verschiedene festgelegte Umgebungen anzupassen, wenn nur Schritte oder Tätigkeiten unternommen oder Mittel eingesetzt werden, die für diesen Zweck für die betrachtete Software vorgesehen sind. ([ISO 9126], [DIN 66272])
Siehe auch Portabilitätstest.
|
| Anweisung |
Syntaktisch definierte Einheit einer Programmiersprache (z.B. Zuweisung an eine Variable), die typischerweise die kleinste, unteilbare ausführbare Einheit darstellt. |
| Anweisungs-
überdeckung
|
(1) Der prozentuale Anteil von allen Anweisungen einer Komponente, welche durch eine Testsequenz ausgeführt wurden.
(2) Kontrollflussbasiertes Testverfahren, das die mindestens einmalige Ausführung aller des Testobjekts fordert.
|
| Anweisungstest
|
Ein White-Box Testverfahren, bei dem die Testfälle entworfen werden, um Anweisungen auszuführen. |
| Anwender-Abnahmetest |
Siehe Abnahmetest. |
| Anwendertest |
Test, bei dem Anwender aus dem operativen Betrieb die Benutzbarkeit einer Komponente oder eines Systems bewerten. |
| Anwendungsfall
|
Ein Anwendungsfall beschreibt eine (durch genau einen Akteur angestoßene) Reihe von erkennbaren Aktionen, die ein System ausführt und die zu einem konkretem Ergebnis mit Wert für den Handelnden (Akteur) führt.
|
| anwendungsfallbasierter Test |
Ein Black-Box-Test(entwurfs-)Verfahren, bei dem Testfälle so entworfen werden, dass Anwendungsfall-Szenarien durchgeführt werden. |
| anwendungsprofil-orientierter Test |
Statistischer Test unter Verwendung eines Modells von Systemoperationen und ihrer typischen Nutzung [Musa]. |
| Application Programming Interface (API) |
(1) Softwareschicht, d.h. Schnittstelle, zwischen zwei Programmen, mit der ein Programm gegen Änderungen im Verarbeitungsmodus des anderen Programms abgeschirmt wird.
(2) Das Application Programming Interface ist eine dokumentierte Software-Schnittstelle, mit deren Hilfe ein Programm die Funktionen eines anderen Programms nutzen kann. |
| Arbeitsergebnis
|
Jedes Ergebnis einer Arbeit, welches an jemand anderen übergeben wird. |
| arc testing |
Siehe Zweigtest. |
| Assessment |
Bewertung eines Entwicklungs- und Wartungsprozesses gegen ein Referenzmodell (Siehe auch SPICE).
|
| atomare (Teil) Bedingung |
(1) Boolescher Ausdruck, der keinen Booleschen Operator enthält. Beispiel: "A > B" ist eine atomare Bedingung, aber "A AND B" nicht. [BS 7925-1-1998]
(2) Eine Bedingung, die keine booleschen Operatoren wie AND, OR oder NOT, sondern höchstens Relationssymbole wie ">" oder "=" enthält.
|
| Attraktivität |
Die Eigenschaft eines Softwareprodukts, für den Benutzer attraktiv zu sein. [ISO 9126]
Siehe auch Benutzbarkeitstest. |
| Audit |
Eine unabhängige Bewertung von Software-Produkten und -prozessen um die Konformität mit Standards, Richtlinien, Spezifikationen, und/oder Prozeduren basierend auf objektiven Kriterien zu bestimmen, einschließlich der Dokumente, welche
(1) die Gestaltung oder den Inhalt der zu erstellenden Produkte festlegen,
(2) den Prozess der Erstellung der Produkte beschreiben
(3) und spezifizieren wie die Übereinstimmung mit den Standards und Richtlinien nachgewiesen bzw. gemessen werden kann. (nach [IEEE 1028])
|
| Audit Trail |
Ein Pfad bei dem der Prozess-Output als Startpunkt verwendet wird und durch den Prozess bis zum Beginn/Input (z.B. Daten) zurückverfolgt wird. Dies erleichtert die Überprüfung von Ergebnissen und erlaubt die Durchführung eines Prozess Audits. [nach TMap]
|
| Ausfall |
1. Aussetzen der Ausführung einer festgelegten Aufgabe eines Systems aufgrund einer in ihm selbst liegenden Ursache und im Rahmen
der zulässigen Beanspruchung.
2. Unvermögen eines Systems, eine verlangte Funktion auszuführen.
|
| Ausfallrate |
Verhältnis zwischen Anzahl der aufgedeckten Fehlerwirkungen einer best. Kategorie gegen eine vorgegebene Maßeinheit und definiertem Testaufwand (z.B. Anzahl der Fehlerwirkungen für ein Zeitintervall, Fehlerwirkungen für eine Anzahl von Transaktionen, Fehlerwirkungen für eine Anzahl von Rechnerläufen). [nach IEEE 610]
|
| ausführbare Anweisung |
Eine Anweisung, die durch Kompilation in Objektcode übersetzt wurde und während die Ausführung zur Laufzeit Aktionen auf den Daten ausführen kann. |
| ausführbarer Pfad
|
Ein Pfad für den eine Menge von Eingabewerten und Vorbedingungen existiert, die den Pfad zur Ausführung bringen.
|
| Ausgabe |
Eine Variable, die durch eine Komponente geschrieben wird (und innerhalb oder ausserhalb einer Komponente gespeichert wird). |
| Ausgabewert |
Eine Instanz einer Ausgabe.
Siehe auch Ausgabe. |
| Ausgabewertebereich |
Die Menge der Werte aus der gültige Ausgabewerte ausgewählt werden können.
Siehe auch Bereich. |
| ausgeführt |
Ein Strukturelement wird als ausgeführt bezeichnet, wenn Eingabewerte die Ausführung eines solchen Strukturelements (z.B. Anweisung, Entscheidung, ...) bewirken. |
| Ausnahme-
behandlung
|
Verhalten einer Komponente oder eines Systems als Antwort auf fehlerhafte Eingaben durch einen Anwender oder eine andere Komponente/System oder einen anderen internen Ausfall.
|
| Aussprungspunkt |
Die letzte ausführbare Anweisung innerhalb einer Komponente. |
| Austauschbarkeit |
Das Vermögen/die Fähigkeit eines Softwareprodukts an Stelle einer anderen spezifizierten Software zum selben Zweck in der gleichen Umgebung genutzt zu werden. [ISO 9126]
Siehe auch Übertragbarkeit.
|
| Auswertung (von Tests) |
Siehe Testauswertung.
|
| Automat |
siehe endlicher Automat |
| Automatisierte Testmittel |
Testmittel, z.B. in einer Skriptsprache formulierte Anweisungen, welche im automatisierten Testen eingesetzt werden. |
| Automatisierung |
Siehe Testautomatisierung. |
| Automatisierung der Testdurchführung |
Die Verwendung einer Software z.B. ein Mitschnittwerkzeug, um die Ausführung von Tests zu steuern, den Vergleich mit den tatsächlichen mit dem erwarteten Verhalten durchzuführen. |
| Änderung |
Um- oder Neuformulierung eines freigegebenen Entwicklungs(zwischen)produkts (Dokument, Quellcode).
|
| Änderungsauftrag |
Auftrag bzw. Genehmigung, eine bestimmte Änderung an einem Enwicklungs(zwischen)produkt vorzunehmen. |
| Änderungsausschuss |
Siehe Konfigurationsausschuss. |
| Änderungskontrolle |
Siehe Konfigurationskontrolle. |
| Äquivalenzklasse |
(1) Siehe Äquivalenzklassenbildung.
(2) Eine Menge (oder Bereich) von Werten, bei der jeder Wert
- als Eingabe für ein Testobjekt - gleichartiges Sollverhalten zeigt (Äquivalenzklasse von Eingabewerten), bzw.
- als Ergebnis eines Testlaufs gleichartiges Sollverhalten aufzeigt (Äquivalenzklasse von Ausgabewerten).
Sowohl gültige als auch ungültige Werte werden betrachtet.
|
| Äquivalenzklassenbildung
|
Zerlegung von Ein- oder Ausgabedaten eines Programms in eine endliche Menge von Klassen, deren Elemente jeweils ein identisches funktionales Verhalten zeigen. Die Zerlegung basiert auf der zugrunde liegenden Spezifikation.
|
| Äquivalenzklassenbildung |
Eine Black-Box-Methode zum Entwurf von Testfällen, die Repräsentanten von Äquivalenzklassen ausführen. Testfälle werden derart ausgewählt, dass alle Wertebereiche mindestens einmal abgedeckt werden.
|
| Äquivalenzklassentest
|
Eine Testfallentwurfsverfahren bei der Testfälle zur Ausführung von Repräsentanten von Äquivalenzklassen entworfen werden.
|
| Äquivalenzklassentesten
|
Siehe Äquivalenzklassentest. |
| Äquivalenzklassenüberdeckung |
Der prozentuale Anteil der Äquivalenzklassen, die durch eine ausgeführte Testsuite überdeckt werden.
|
| äußerer Fehler |
Siehe Fehlerwirkung.
|
| B |
|
| Back-to-back-Test |
Test, bei dem zwei oder mehr Varianten einer Komponente oder eines Systems mit gleichen Eingaben ausgeführt werden und deren Ergebnisse dann verglichen werden. Im Fall von Abweichungen wird die Ursache analysiert. [IEEE 610]
|
| Baseline |
siehe Referenzkonfiguration |
| Basis-Testfallmenge |
Eine aus der internen Struktur oder Spezifikation abgeleitete Menge von Basistestfällen, durch welche ein 100% Überdeckungsgrad (z.B. C1-Überdeckung) erreicht werden kann. |
| Basisblock |
Eine Folge von einer oder mehreren aufeinanderfolgenden Anweisungen, welche keine Verzweigungen enthalten.
Anmerkung: Ein Knoten in einem Kontrollflussgraphen repräsentiert einen Basisblock. |
| Basispfad |
Jeder beliebige Pfad eines gerichteten stark zusammenhängenden Graphen kann als Linearkombination der Basispfade dargestellt werden. |
| Basispfad Methode |
Kontrollflussbezogenes Testverfahren bei dem alle Basispfade durchlaufen werden. |
| bebugging |
Siehe Fehlereinpflanzung. [Abbott] |
| Bedingung (logische)
|
Eine logischer Ausdruck, welcher entweder als 'wahr' oder 'falsch' bewertet werden kann, z.B. A>B.
Siehe auch Testbedingung.
|
| Bedingungs-
überdeckung
|
Der prozentuale Anteil der (atomaren) Teilbedingungen, welche durch eine Gruppe von Testfällen ausgeführt worden sind. 100% (einfache) Bedingungsüberdeckung bedeutet, dass jede (atomare) Teilbedingung in jeder Entscheidung mindestens einmal mit den Werten True und False ausgeführt wurde.
|
| Bedingungs- /Entscheidungsüberdeckung
|
Der prozentuale Anteil von allen prozentualen Bedingungs- und Entscheidungsausgängen, welche durch eine Testsuite ausgeführt wurden. 100% Bedingungs-/Entscheidungsüberdeckung schliessen sowohl 100% Bedingungsüberdeckung als auch 100% Entscheidungsüberdeckung mit ein.
|
| Bedingungs-/Entscheidungstest
|
Ein White-Box-Testverfahren, in dem die Testfälle im Hinblick auf Bedingungsergebnisse und Entscheidungsausgänge entworfen werden.
|
| Bedingungsergebnis |
Die Auswertung einer Bedingung zu WAHR oder FALSCH. |
| Bedingungstest |
Ein White-Box-Testentwurfs-Verfahren, bei dem Testfälle so entworfen werden, dass die Bedingungsergebnisse zur Ausführung kommen, die unabhängig voneinander ein Entscheidungsergebnis beeinflussen.
|
| Bedingungstest (einfacher)
|
Ein White-Box-Testentwurfs-Verfahren, bei dem Testfälle so entworfen werden, dass Entscheidungsausgänge zur Ausführung kommen. |
| Bedingungsüberdeckung (definierte) |
Der prozentuale Anteil von all den einfachen Bedingungsergebnissen, die unabhängig einen Entscheidungsausgang beeinflussen, der durch eine Testsuite überdeckt wurde. 100% "condition determination coverage" schliesst 100% Entscheidungsüberdeckung ein.
|
| Benchmarktest
|
(1) Ein Standard gegen den Messungen oder Vergleiche gemacht werden können.
(2) Test, der verwendet werden kann um Komponenten oder Systeme gegeneinander oder gegen einen Standard wie in (1) zu vergleichen. [nach IEEE 610]
|
| Benutzbarkeit |
Fähigkeit eines Softwareprodukts unter spezifizierten Bedingungen für einen Anwender verständlich, erlernbar, anwendbar und attraktiv zu sein [ISO 9126].
Siehe auch Benutzbarkeit. |
| Benutzbarkeitstest |
Testen um das Ausmaß zu bestimmen, inwieweit ein Softwareprodukt unter spezifizierten Bedingungen für einen Anwender verständlich, erlernbar, anwendbar und attraktiv ist. [nach ISO 9126]. |
| Best Practice |
Eine überlegene Methode oder innovative Vorgehensweise, welcher zu einer gesteigerten Leistungsfähigkeit einer Organisation unter gegebenen Bedingungen beiträgt; üblicherweise herrscht bei vergleichbaren Unternehmen Einigkeit darüber, was jeweils "Best Practice" ist.
|
| Bestanden
/Nicht-Bestanden
-Kriterien |
Regeln, die dazu dienen um für ein Testobjekt entscheiden zu können, ob ein Test bestanden oder nicht bestanden wurde. [IEEE 829] |
| bestanden |
Ein Test wird als bestanden bezeichnet, wenn die aktuellen mit den erwarteten Ergebnissen übereinstimmen. |
| Bestätigungstest |
Siehe Fehlernachtest. |
| Beta-Test |
Test oder testweiser Betrieb eines Softwareprodukts durch repräsentative Kunden/Anwender in der Einsatzumgebung des Kunden/Anwenders. Mittels eines Beta-Tests wird eine Art externer Akzeptanztest durchgeführt, um vor der endgültigen Freigabe eine Rückmeldung vom Markt einzuholen und das Interesse der potenziellen Kunden für das Softwareprodukt zu erzeugen; häufig durchgeführt, wenn die Zahl der möglichen Anwendungsumgebungen sehr groß ist.
Anmerkung:
Beta Tests kommt als eine Form externen Akzeptanztest zum Einsatz, um Feedback vom Markt zu erhalten.
|
| Betriebstest |
Test, der durchgeführt wird, um eine Komponente oder System in einer operativen Umgebung (Arbeits- bzw. Produktivumgebung) zu bewerten. [IEEE 610] |
| Bewertungskriterien für die Performanz |
Siehe Leistungs-Indikator. |
| Big-Bang Integration(stest) |
Als einen Test eines Big-Bang integrierten Systems wird ein Vorgehen im Rahmen eines Integrationtests bezeichnet, in dem verschiedene Software- und Hardwareelemente in einem (grossen) Schritt zu einer Komponente oder einem Gesamtsystem integriert werden, anstatt sie schrittweise zu integrieren.
Siehe auch Integrationstest.
|
| Black-Box-(Testentwurfs-) Verfahren |
Nachvollziehbares Verfahren zur Herleitung und Auswahl von Testfällen basierend auf einer Analyse der funktionalen oder nichtfunktionalen Spezifikation einer Komponente oder Systems ohne Berücksichtigung der internen Struktur. |
| Black-Box-Test |
Funktionaler oder nichtfunktionaler Test ohne Nutzung von Informationen über Interna eines Systems oder einer Komponente.
Siehe auch funktionale Testentswurfverfahren, anforderungsbasierter Test.
|
| Black-Box-Verfahren |
Siehe Black-Box-Testentwurfs-Verfahren.
|
| blockierter Test(fall) |
Zur Durchführung eingeplanter Testfall, der nicht ausgeführt werden kann, weil die Voraussetzungen für seine Ausführung nicht hergestellt werden können.
|
| Bottom-Up Integration(stest)
|
Der Test beginnt mit den elementaren Komponenten des Systems, die keine weiteren Komponenten aufrufen (außer Funktionen des Betriebssystems). Größere Teilsysteme werden sukkessive aus getesteten Komponenten zusammengesetzt, mit anschliessenden Test dieser Integration.
Siehe auch Integrationstest. |
| Boundary-Interior-Pfadüberdeckung |
Kontrollflussbasiertes, dynamisches Testverfahren, das nur die Überdeckung der Pfade fordert, die maximal eine Wiederholung einer Schleife beinhalten. |
| branch condition |
Siehe Bedingung. |
| branch condition combination coverage |
Siehe Mehrfach-Bedingungsüberdeckung. |
| branch condition combination testing |
Siehe Mehrfach-Bedingungsüberdeckungstest. |
| BS |
British Standards |
| BS 7925 |
British Standards: "Software Testing" |
| C |
|
| Capability Maturity Model (CMM) |
Ein fünfstufigen Rahmenwerk, welches Schlüsselelemente einer effektiven Softwareentwicklung und -wartung beschreibt. Das CMM-Modell deckt Best-Practice-Ansätze für die Planung, das Engineering und das Managen einer Software-Entwicklung und -wartung ab. [CMM]
Siehe auch Capability Maturity Model Integration (CMMI).
|
| Capability Maturity Model Integration (CMMI) |
Ein Rahmenwerk, welches Schlüsselelemente einer effektiven Softwareentwicklung und -wartung beschreibt. CMMI deckt Best-Practice-Ansätze für die Planung, das Engineering und das Management einer Software-Entwicklung und -wartung ab. CMMI wurde als Nachfolger von CMM konzipiert. [CMMI]
Siehe auch Capability Maturity Model (CMM).
|
| Capture / Replay Werkzeug |
Siehe Mitschnittwerkzeug. |
| capture/playback tool |
Siehe Mitschnittwerkzeug |
| CASE |
Akronym für Computer Aided Software Engineering. |
| CAST |
Akronym für Computer Aided Software Testing.
Siehe auch Testautomatisierung. |
| CCB |
Change Control Board; Instanz oder Gremium, dessen Aufgabe u. a. die Durchführung des Fehlermanagement ist. Entscheidet über Änderungsanforderungen, priorisiert und verfolgt diese. |
| Change Request |
siehe Änderungsanforderung |
| Chow´s Überdeckungsmetrik |
Siehe auch N-Switch Überdeckung. [Chow] |
| Code |
Gesamtmenge aller Programmanweisungen einer Software.
Siehe auch Anweisung. |
| codebasierter Test |
Siehe White-Box-(Testentwurfs-) Verfahren, struktureller Test. |
| Codeüberdeckung |
Kriterium (für den geforderten Umfang der Testfällene) durch das ermittelt wird, welche Strukturelemente (Anweisungen, Verzweigungen, ... ) einer Software durch eine Testsuite ausgeführt (überdeckt) wurden oder welche nicht.
Synnonym: Codeabdeckung
Siehe auch Anweisungs- und Bedingungsüberdeckung.
|
| Compiler |
Übersetzungsprogramm, das den Quelltext einer Programmiersprache in Maschienensprache umwandelt (nach Informationsarchiv http://www.informationsarchiv.net/) |
| condition combination coverage
|
Siehe Mehrfach-Bedingungsüberdeckung.
|
| condition combination testing
|
Siehe Mehrfach-Bedingungsüberdeckungstest. |
| COTS |
Akronym für Commercial Off-The-Shelf software.
Siehe Standard-Software. |
| CUS |
Customer Supplier (Process Area of SPICE) |
| D |
|
| Daily-Build |
Eine Entwicklungsaktivität, wobei ein System vollständig (i.d.R. über Nacht) neu übersetzt und gebunden wird, so das danach sichergestellt ist, daß das System konsistent ist (einschließlich seiner letzten Änderungen). |
| Datenbankintegritätstest |
Test der Methoden und Prozesse, die verwendet werden die Datenbank zu managen und auf sie zuzugreifen um sicherzustellen, dass die Methoden, Prozesse und Integritätsregeln wie erwartet funktionieren und während durch den Zugriff auf die Datenbank, Daten nicht korrupt werden oder unerwartet gelöscht, geändert oder neuangelegt werden. |
| Datenbereichsbezogener Test |
siehe Blackbox-Test, Ein- und Ausgabebereich ist Basis zur Testdatenerzeugung |
| Datendefinition
|
Eine ausführbare Anweisung, wobei einer Variablen ein Wert zugewiesen wird.
|
| Datenfluss
|
Eine abstrakte Darstellung einer Folge von Änderungen des Zustands eines Datenobjekts, wobei die Zustände des Objekts sind: Definition/Neuanlage, Verwendung oder "Zurücksetzung". [Beizer]
|
| Datenflussanalyse |
Statisches Analyseverfahren, das auf der Definition und Verwendung
von Variablen basiert und fehlerhafte Zugriffssequenzen auf die Variablen
des Testobjekts nachweist. |
| Datenflussanomalie |
Unbeabsichtigte oder nicht erwartete Folge von Operationen auf einer Variablen.
Anmerkung:
Folgende Datenflussanomalien werden unterschieden:
UR-Anomalie: Referenzierung einer undefinierten Variablen,
DD-Anomalie: zweimal aufeinanderfolgendes Schreiben auf eine Variable ohne zwischenzeitliche Referenzierung,
DU-Anomalie: Schreiben (definieren) einer Variablen mit späterer Undefinition, ohne dass die Variable zwischendurch referenziert wird. |
| Datenflussanomalieanalyse |
(1) Statisches Analyseverfahren zur Aufdeckung von fehlerhaften Zugriffssequenzen auf die Variablen des Testobjekts.
(2) Analyse, ob Datenvariablen richtig verwendet werden oder nicht. |
| datenflussbasierter Test |
1. Ein White-Box-Testverfahren, bei dem Testfälle entworfen werden, um Paare von Definition und Verwendung von Variablen auszuführen.
2. White-Box-Testverfahren, bei dem die Testfälle mittels Datenflussanalyse hergeleitet werden und die Vollständigkeit der Prüfung (Überdeckungsgrad) anhand der Datenflussüberdeckung bewertet wird. |
| Datenflussgraph |
Erweiterter Kontrollflussgraph, der Informationen über die Art der Variablenbenutzung enthält. |
| Datenflussüberdeckung |
Der prozentuale Anteil der Definitions-/Verwendungspaare, welche durch eine Gruppe / Menge von Testfällen ausgeführt werden.
|
| datengetriebene Tests
|
Ein skriptbasiertes Verfahren, bei dem die Testeingaben und erwarteten Ergebnisse in einer Tabelle (z.B. Excel) gespeichert werden, so dass über ein parametrisierbares Skript die vorbereiteten Tests ausgeführt werden können. Datengetriebene Tests werden oft unterstützend beim Einsatz von Testausführungswerkzeugen, wie Mitschnittwerkzeugen, verwendet. [nach Fewster und Graham]
Siehe auch Schlüsselwort-getriebener Test.
|
| Datenintegritätstest |
Siehe Datenbankintegritätstest. |
| DB |
Datenbank |
| Dead Code |
siehe tote Programmanweisung |
| Debugger |
Siehe Debugging-Werkzeug.
|
| Debugging |
Tätigkeit des Lokalisierens, Analysierens und Entfernens von Fehlerursachen in der Software. |
| Debugging-Werkzeug |
Ein Entwicklerwerkzeug, welches benutzt wird um Fehler zu reproduzieren und Zustände von Programmen und ihre korrespondierenden Defekte zu untersuchen. Mittels eines Debuggers kann der Entwickler ein Programm Schritt für Schritt ausführen, ein Programm an einer beliebigen Stelle anhalten und den Wert von Variablen setzen bzw. den aktuellen Wert anzeigen lassen.
|
| Defekt
/ Fehlerzustand |
(1) Inkorrektes Teilprogramm, inkorrekte Anweisung oder Datendefinition, die Ursache für einen äußeren Fehler ist.
(2) Zustand eines (Software)produkts oder einer seiner Komponenten, der unter spezifischen Bedingungen (z.B. bei einer hohen Belastung) eine geforderte Funktion des Produkts beeinträchtigen kann bzw. zu einer Fehlerwirkung führt (z.B. inkorrekte Anweisung oder Datendefinition).
Anmerkung:
Ein Fehlerzustand, der zur Laufzeit auftritt, kann einen Ausfall/Mangel einer Komponente oder Systems verursachen.
|
| Defekt (fault) |
siehe Fehlerzustand |
| Definition-Verwendungspaar
|
Die Zuordnung einer Definition einer Variablen zu einer Verwendung dieser Variablen. Variablenverwendungen können Berechnungen sein (z.B. Muliplikation) oder steuern die Ausführung von Pfaden ("prädikative" Verwendung).
|
| DIN |
Deutsche Industrie Norm |
| DIN 25424 |
DIN Standard: "Fehlerbaumanalyse" |
| DIN 66272 |
DIN Standard: "Informationstechnik - Bewerten von Softwareprodukten - Qualitätsmerkmale und Leitfaden zu ihrer Verwendung"; Identisch mit ISO/IEC 9126 |
| DO178b |
RTCA Document RTCA/DO-178B: "Software Considerations in Airborne Systems and Equipment Certification" |
| Dokumentationstest
|
Test der Qualität der Dokumentation, z.B. Benutzerhandbuch oder Installationshandbuch.
|
| Dummy |
Ein spezielles Programmteil, dessen Funktionalität normalerweise darauf beschränkt ist, das das echte Programmteil während des Tests zu ersetzen.
|
| DV |
Datenverarbeitung |
| dynamische Analyse |
Prozess der Bewertung des Verhaltens, z.B. Speichereffizienz, CPU-Nutzung eines Systems oder einer Komponente während der Nutzung. [nach IEEE 610]
|
| dynamischer Test
|
(1) Tests, die die Ausführung der Software einer Komponente oder eines Systems beinhalten.
(2) Prüfung des Testobjekts durch Ausführung auf einem Rechner.
|
| dynamischer Vergleich
|
Vergleich der tatsächlichen mit den erwarteten Ergebnissen, ausgeführt zur Laufzeit, z.B. durch ein Testausführungswerkzeug. |
| Dynamisches Analysewerkzeug |
Eine Werkzeug, welches Informationen zur Ausführungszeit über den Programmcode bereitstellt. Diese Werkzeuge werden im allgemeinen genutzt um undefinierte Zeiger zu identifizieren, Zeigerberechnungen zu prüfen und die Speicherzuteilung, -verwendung und -freigabe zu überwachen und Speicherengpässe zu kennzeichnen. |
| E |
|
| Effizienz
|
(1) Die Fähigkeit/das Vermögen eines Software-Produkts, eine angemessene Leistung zu erbringen, bezogen auf den Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen [ISO 9126 / DIN 66272]
(2) Eine Menge von Merkmalen (z.B. Verarbeitungsgeschwindigkeit, Antwortzeit), die sich auf das Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel (Speicher u.a.) unter festgelegten Bedingungen (in der Regel in Abhängigkeit steigender Last) beziehen.
|
| Effizienz(-messung) |
Messung der Verarbeitungsgeschwindigkeit bzw. Antwortzeit und des Ressourcenverbrauchs (Speicher u.a.) des Testobjekts für bestimmte Anwendungsfälle, in der Regel in Abhängigkeit von steigender Last. |
| Effizienztest
|
Test, um die Effizienz eines Software-Produkts zu ermitteln. |
| einfache Bedingungs-
überdeckung |
1. Siehe Bedingungsüberdeckung.
2. Kontrollflussbasiertes White-Box-Testverfahren, das die Überdeckung
der atomaren Teilbedingungen einer Entscheidung mit wahr und falsch fordert.
|
| Eingabe |
Eine Variable, die durch eine Komponente eingelesen wird (und innerhalb oder ausserhalb einer Komponente gespeichert wird). |
| Eingabewert |
Eine Instanz einer Eingabe.
Siehe auch Eingabe.
|
| Eingabewertebereich |
Die Menge der Werte aus der gültige Eingabewerte ausgewählt werden können.
Siehe auch Bereich.
|
| Eingangsbedingung |
Die Menge der generischen und spezifischen Bedingungen, die es ermöglichen den Prozess mit definierten Aufgaben fortzusetzen; z.B. eine Testphase. Der Sinn von Eintrittskriterien besteht darin, vor der Durchführung einer Aktivität zunächst die Erfüllung der Voraussetzungen herzustellen, um eine Ressourcenverschwendung zu vermeiden und das Verhalten des Testobjekt unter spezifischen Bedingungen zu prüfen. [Gilb und Graham]
Synnonym: Eintrittskriterium, Vorbedingung |
| eingefrorene Testbasis |
Ein grundlegendes Testdokument, welches nur durch einen formalen Änderungsprozess angepasst werden darf.
Siehe auch Bezugskonfiguration. |
| Einsprungspunkt |
Die erste ausführbare Anweisung innerhalb einer Komponente. |
| Einzug (von Software) |
Außerbetriebnahme bzw. Stilllegung eines Systems |
| elementarer Vergleichstest |
Ein Black-Box-Testentwurfs-Verfahren bei dem Testfälle entworfen werden, um Kombinationen von Eingaben nach dem Konzept der modizierten Entscheidungs-/Bedingungsüberdeckung auszuführen. [TMap]
|
| Emulator
|
Ein Baustein, Computerprogramm oder System, welcher die gleichen Eingaben akzeptiert und die gleichen Ausgaben wie ein gegebenes System erzeugt [IEEE 610].
Siehe auch Simulator.
|
| Endekriterium |
Siehe Ausgangsbedingung. |
| endlicher Automat |
(1) Ein Berechnungsmodell bestehend aus einer festgelegten Anzahl Status und Statusübergängen, gegebenenfalls mit begleitenden Maßnahmen. [IEEE 610]
(2) Ein endlicher Automat besteht aus einer endlichen Anzahl interner Zustände. Zwischen den Zuständen gibt es Zustandsübergänge, die in Abhängigkeit von Eingaben oder Ereignissen durchlaufen werden. Eine Ausgabe oder Aktion kann bei jedem Zustandsübergang erfolgen oder in einem Zustand. Ein endlicher Automat hat einen Anfangszustand und kann einen Endzustand besitzen.
|
| ENG |
Engineering (Process Area of SPICE) |
| Entscheidung
|
Eine Stelle in einem Programm an dem der Kontrollfluss in zwei oder mehrere alternative Wege verzweigen kann. Ein Knoten mit zwei oder mehreren Kanten in unterschiedliche Zweige.
|
| Entscheidungs-
überdeckung |
Der prozentuale Anteil der Entscheidungsergebnisse, die durch eine Gruppe von Testfällen geprüft wurden. 100% Entscheidungüberdeckung beinhaltet 100% Anweisungsüberdeckung.
Äquivalent mit Zweigüberdeckung.
|
| Entscheidungsausgang |
Das Ergebnis einer Entscheidung, die bestimmt, welcher Weg im Kontrollfluss eingeschlagen wird.
|
| Entscheidungstabelle |
Eine Tabelle, die zum Entwurf von Testfällen verwendet werden kann. Sie zeigt die Kombinationen von Eingabewerten und/oder Auslösern (Ursachen) in Verbindung mit den verbundenen Ausgabewerten und/oder Maßnahmen (Wirkungen). [Veenendaal]
|
| Entscheidungstabellentest |
Ein Black-Box-Entwurfsverfahren bei dem Testfälle im Hinblick auf die Ausführung von Kombinationen aus Eingaben und/oder Stimuli (Ursachen) entworfen werden, welche in einer Entscheidungstabelle dargestellt werden. [Veenendaal]
Siehe auch Entscheidungstabelle.
|
| Entscheidungsüberdeckungstest
|
Ein White-Box Testverfahren, bei dem Testfälle entworfen werden, um Entscheidungsausgänge auszuführen.
|
| Entwicklungsprozess |
Siehe Softwareentwicklungsmodell. |
| Entwicklungstest
|
Formeller oder informeller Test, der während der Entwicklung einer Komponente/eines Systems durchgeführt wird; gewöhnlich durch Entwickler in der Entwicklungsumgebung. [nach IEEE 610]
Siehe auch Komponententest.
|
| Entwurfsbasierter Test
|
Eine Vorgehensweise, bei der Testfälle auf der Basis der Architektur und/oder dem detaillierten Entwurf einer Komponente oder eines Systems (z.B. Test der Schnittstellen zwischen Komponenenten und Systemen) entworfen werden.
|
| Erfahrungsbasierte Verfahren |
Black-Box-Verfahren zur Ermittlung von Testfällen auf der Basis der Kenntnisse und Erfahrungen des Testers ohne Anwendung von Methodiken. [nach Spillner/Linz: Basiswissen Softwaretest]
Synonym: intuitive Testfallermittlung
Siehe auch error guessing |
| erfolgreich bestandener Test |
Siehe bestanden. |
| Ergebnis |
Die Konsequenzen der Ausführung eines Tests. Dies beinhaltet die Ausgaben am Bildschirm, Änderungen an Daten, Berichte und versendete Meldungen.
Siehe auch tatsächliches Ergebnis, erwartetes Ergebnis.
|
| Erlernbarkeit |
Das Vermögen/die Fähigkeit eines Software-Produkts einem Anwender das Erlernen der Anwendung zu ermöglichen. [ISO 9126]
Siehe auch Benutzbarkeit.
|
| error guessing
|
(1) Ein Testentwurfsverfahren, bei dem die Erfahrung und das Wissen der Tester genutzt werden, um vorherzusagen, welche Fehlerzustände in einer Komponente oder einem System aufgrund der Fehlhandlungen vorkommen, und um Testfälle so abzuleiten, dass diese Fehler aufgedeckt werden..
(2) Methode und Herleitung oder Auswahl der Testfälle, gestützt auf Erfahrung und Wissen des Testers.
Synonyme: intuitive Testfallermittlung,
Fehlererwartungsmethode
Siehe auch Erfahrungsbasierte Verfahren.
|
| erschöpfender Test |
Testvorgehensweise, bei dem die Testsuite alle Kombinationen von Eingabewerten und Vorbedingungen umfasst.
Synonym: vollständiger Test. |
| erwartetes Ergebnis |
Das Verhalten eines Systems oder einer Komponenten unter festgelegten Bedingungen, das durch die Spezifikation oder durch eine andere Quelle festgelegt ist.
Siehe auch Testorakel.
|
| Erwartungswert |
Siehe erwartetes Ergebnis.
|
| exploratives Testen |
Ein informelles Testverfahren, bei dem der Tester den Entwurf der Tests aktiv steuert, indem er testet und die Informationen, die er während des Tests erhält zum Entwurf neuer besserer Tests verwendet. [nach Bach]
Siehe auch Adhoc Testen.
|
| EXtreme Programming |
Agiler Entwicklungsprozess, in dem u. a. test-first-programming propagiert wird.
Siehe auch Test-First Programming.
|
| F |
|
| fault density
|
Siehe Fehlerdichte. |
| Fehler |
(1) Siehe Fehlerzustand.
(2) Nichterfüllung einer festgelegten Anforderung.
(3) Oberbegriff für Fehlhandlung, Fehlerzustand, Fehlerwirkung. |
| Fehler |
Ein Fehler ist die Abweichung zwischen dem berechneten, beobachteten oder gemessenen Wert oder einem Zustand der Betrachtungseinheit und dem ensprechenden spezifizierten oder theoretischen Wert.
|
| Fehler aufdeckender Testfall |
Testfall, der bei Ausführung ein Istverhalten des Testobjekts erzeugt, das von dem geforderten Sollverhalten abweicht. |
| Fehler(zustand) |
Zustand eines (Software)produkts oder einer seiner Komponenten, der unter spezifischen Bedingungen (z.B. bei einer hohen Belastung) eine geforderte Funktion des Produkts beeinträchtigen kann bzw. zu einer Fehlerwirkung führt; z.B. inkorrekte Anweisung oder Datendefinition. Ein Defekt, der zur Laufzeit auftritt, kann einen Ausfall/Mangel einer Komponente oder Systems verursachen.
|
| Fehler-Möglichkeits -und-Einflussanalyse (FMEA)
|
Eine systematische Vorgehensweise für die Risikoidentifikation und für die Analyse von möglichen Fehler(aus)wirkungen und für ihre Vermeidung.
|
| Fehleranalyse |
Die Fehlerursache feststellen (im Testobjekt oder im Testfall). |
| Fehlerauswirkung |
Das physikalische oder funktionale Erscheinungsbild eines Fehlers. Zum Beispiel kann eine Fehlerwirkung zu einer langsamen Ausführung, zu inkorrekten Ausgaben und oder zu einem Abbruch der Ausführung führen. [IEEE 610]
|
| Fehlerbaumanalyse
|
(1) Eine Methode, welche verwendet wird die Ursache von Fehlern bzw. Defekten zu analysieren.
(2) Erstellen eines Fehlerbaums zu einem vorgegebenenen unerwünschten Ereignis /DIN 25424/.
|
| Fehlerbericht |
Ein Dokument, das über jede Fehlfunktion einer Komponente oder eines Systems berichet, die dazu führen kann, dass es seine geforderte Funktion erbringt.
|
| Fehlerdatenbank |
(1) Liste aller bekannten Ausfälle oder Mängel in einem System oder einer Komponente und ihr Behebungsstatus.
(2) Enthält aktuelle, vollständige Information über alle aufgedeckten Fehlerwirkungen.
Siehe Abweichungsmanagementwerkzeug. |
| Fehlerdichte
|
Die Anzahl der Fehler, die in einem Software-Produkt identifiziert wurden dividiert durch die Größe des Software-Produkts (ausgedrückt durch Standardkenngröße wie z. B. Anzahl Zeilen und Funktionspunkte).
|
| Fehlereinpflanzung
|
Als Fehlereinpflanzung bezeichnet man das (beabsichtigte) Hinzufügen von bekannten Fehlern zu einer Komponente oder einem System, um aus der Rate der aufgedeckten bekannten Fehler, eine Abschätzung über die verbliebenen Fehler machen zu können. [IEEE 610] |
| Fehlererwartungsmethode |
Dynamisches Testverfahren, das Erfahrung und Intuition des Testers ausnutzt, um Testfälle herzuleiten. |
| Fehlerfindungsrate
|
Die Anzahl der Fehler, die innerhalb eines Testzeitraums gefunden wurden, dividiert durch die Gesamtzahl der Fehler, die innerhalb des Testzeitraums und danach gefunden wurden.
Synnonym: Fehleraufdeckungsrate.
|
| Fehlerfindungssrate |
Anzahl der Fehler, die innerhalb eines Testzeitraums oder in einer Teststufe gefunden werden, dividiert durch die Gesamtzahl der Fehlerzustände, die bis zu einem (zukünftigen) definierten Bezugszeitpunkt (z. B. bis 6 Monate nach Inbebetriebnahme) gefunden werden.
|
| Fehlerklasse |
Einteilung der aufgedeckten Fehlerwirkungen nach Schwere der Fehlerwirkung aus Sicht des Anwenders (z.B. Grad der Behinderung des Produkteinsatzes). |
| Fehlerkorrektur |
Siehe Debugging.
|
| Fehlermanagementwerkzeug |
Siehe Abweichungsmanagementwerkzeug. |
| Fehlermaskierung |
(1) Ein Umstand bei der ein Fehlerzustand die Aufdeckung eines anderen verhindert. [nach IEEE 610]
(2) Ein vorhandener Fehlerzustand wird durch einen oder mehrere andere Fehlerzustände in anderen Teilen des Testobjekts kompensiert, so dass dieser Fehlerzustand keine Fehlerwirkung hervorruft.
|
| Fehlermeldung |
Beschreibung eines Fehlers in der Form, dass er reproduziert und vom Entwickler behoben werden kann. Die Details einer Fehlermeldung sind u.a. in [IEE 829] definiert. |
| Fehlernachtest
|
Wiederholung aller Testfälle, die vor der Fehlerkorrektur eine Fehlerwirkung erzeugt haben; dient der Überprüfung, ob die Korrektur des ursächlichen Fehlerzustands erfolgreich war.
Siehe auch Regressionstest.
|
| Fehlerpriorität |
Festlegung der Dringlichkeit von Korrekturmaßnahmen unter Berücksichtigung der Fehlerklasse, des erforderlichen Korrekturaufwands und der Auswirkungen auf den gesamten Entwicklungs- und Testprozess. |
| Fehlerprotokollierung |
Erfassen von Fehlermeldungen - üblicherweise in einem Abweichungsmanagementwerkzeug.
Siehe Abweichungsmanagementwerkzeug. |
| Fehlersensitiver Testfall |
Eingabedaten werden so kombiniert, dass ein Fehler bei der Verarbeitung eines Eingabedatums auch beim Ausgabedatum beobachtbar ist. |
| Fehlerstatus |
Während der Fehlerverfolgung kann ein festgestellter Fehler je nach Bearbeitungsstand verschiedene Status besitzen (z.B. "offen", "in Bearbeitung", "zu testen", "erledigt" usw.).
Anmerkung: Der Statuswechsel ist nicht optional. |
| Fehlersymptom |
Abweichung zwischen dem erwarteten oder spezifiziertem Testergebnis und dem tatsächlichem Testergebnis.
|
| Fehlertoleranz
|
(1) Die Fähigkeit/das Vermögen eines Software-Produkts ein spezifiziertes Leistungsniveau auch bei Fehlfunktionen oder trotz Fehleingaben (z. B. falsche Bedienung) aufrecht zu erhalten. [ISO 9126]
Siehe auch Zuverlässigkeit.
|
| Fehlertoleranz |
Die Fähigkeit/das Vermögen eines Systems oder einer Komponente sein spezifiziertes Leistungsniveau trotz Fehleingaben beizubehalten. [nach IEEE 610]
Siehe auch Robustheit. |
| Fehlerverfolgungswerkzeug |
Siehe Abweichungmanagementwerkzeug.
|
| Fehlerwirkung |
(1) Tatsächliche Abweichung der Komponente/eines Systems von der erwarteten Auslieferung, dem Dienst oder dem Ergebnis. [nach Fenton]
(2) Wirkung eines Fehlerzustands, die bei der Ausführung des Testobjekts nach »außen« in Erscheinung tritt.
(3) Abweichung zwischen (spezifiziertem) Sollwert und (beobachtetem) Istwert (bzw. Soll- und Istverhalten).
|
| Fehlfunktion |
Siehe Fehlerwirkung.
|
| Fehlhandlung |
Die menschliche Handlung, die zu einem falschen Ergebnis führt. [nach IEEE 610]
|
| Feldtest
|
(1) Siehe Beta-Test
(2) Erprobung einer Vorabversion eines Softwareprodukts durch einen (repräsentativ) ausgewählten Kundenkreis mit dem Ziel, Einflüsse aus nicht vollständig bekannten oder nicht spezifizierten Einsatzumgebungen zu erkennen und/oder die Marktakzeptanz zu prüfen.
|
| Feldversuch |
siehe Feldtest |
| Finiter Automat (finite state machine) |
siehe Endlicher Automat |
| Formale Verifikation |
Mathematisch formaler Beweis der Korrektheit eines Programm(teil)s., vgl. Verifikation |
| formales Review |
Eine Reviewtechnik, welches durch ein dokumentiertes Vorgehen und Anforderungen charakterisiert ist, z.B. eine Inspektion.
|
| Freigabemitteilung |
Ein Dokument, welches die Testobjekte, ihre Konfiguration, aktuellen Status und andere Informationen im Rahmen der Übergabe von der Entwicklung in den Test zu Beginn der Testdurchführung identifiziert. [nach IEEE 829] |
| funktionale Anforderung |
Anforderung, die ein funktionales Verhalten spezifiziert, das ein System oder eine Systemkomponente erbringen muss. [IEEE 610]
Siehe auch Funktionalität. |
| Funktionale Integration
|
Eine Vorgehensweise zur Integration, bei dem Komponenten oder Systeme mit der Absicht kombiniert werden, eine Basisfunktionalität früh bereit zu stellen.
Siehe auch Integrationstest. |
| funktionaler Test |
(1) Testen basierend auf der Analyse der funktionalen Spezifikation einer Komponente oder eines Systems.
(2) Prüfung funktionaler Anforderungen.
(3) Dynamischer Test, bei dem die Testfälle unter Verwendung der funktionalen Spezifikation des Testobjekts hergeleitet werden und die Vollständigkeit der Prüfung (Überdeckungsgrad) anhand der funktionalen Spezifikation bewertet wird.
Siehe auch Black-Box-Test. |
| Funktionales Testentwurfsverfahren
|
Dokumentiertes Vorgehen basierend auf der Analyse der fachlichen Spezifikation um Testfälle abzuleiten und auszuwählen. Dies geschieht ohne Bezugnahme auf die interne Struktur des Testobjekts.
Synnonyme: Black-Box -Testentwurfsverfahren, Black-Box-Testverfahren, Black-Box-Test
siehe auch anforderungsbasierter Test.
|
| Funktionalität |
(1) Die Fähigkeit/das Vermögen eines Softwareprodukts beim Einsatz unter spezifizierten Bedingungen Funktionen zu liefern, die festgelegte und vorausgesetzte Erfordernisse erfüllen. [nach ISO 9126/ DIN 66272]
(2) Spezifiziert das Verhalten, das das System erbringen muss; beschreibt »was« das System leisten soll. Umsetzung ist Voraussetzung dafür, damit das System überhaupt einsetzbar ist.
Merkmale der Funktionalität nach ISO 9126/ DIN 66272 sind: Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit.
|
| Funktionalitätstest |
Testen zur Bestimmung der Funktionalität eines Software-Produkts. |
| Funktionspunktanalyse (FPA) |
Eine Methode, die darauf abzielt den Umfang der Funktionalität eines Informationssystems zu messen. Die Messung ist unabhängig von der Technologie. Die Messung kann als Basis zur Messung der Produktivität verwendet werden, zur Schätzung der benötigten Ressourcen und zur Projektsteuerung. |
| G |
|
| geschäfts-
prozess-
basierter Test |
Testverfahren, bei dem die Testfälle auf Grundlage von Beschreibungen und/oder der Kenntnis von Geschäftsprozessen hergeleitet und ausgewählt werden. |
| Geschäftsprozess |
1. Synonym mit Anwendungsfall
2. Geschäftsprozesse beschreiben aus einer Whitebox-Sicht heraus Abläufe in der betriebswirtschaftlichen Wertschöpfungskette aus Innensicht.
Anmerkung: Diese beiden Bedeutungen sind je nach Quelle widersprüchlich. In der zweiten Bedeutung ist eine deutliche Abgrenzung zu Anwendungsfällen enthalten, die dann das System aus Aktoren-Sicht als Blackbox betrachten.
|
| Glass-Box-Test
|
Siehe White-Box-Test.
|
| Grenzwert |
Ein Ein- und Ausgabewert, der am Rand eines Bereichs liegt oder das kleinste Inkrement zu einer Seite des Bereichs darstellt; z.B. der kleinste und größte Wert eines Bereichs.
|
| Grenzwertanalyse |
(1) Eine Black-Box-Testentwurfs-Verfahren, bei der die Testfälle unter Nutzung von Grenzwerten entworfen werden.
(2) Fehlerorientiertes Testverfahren, verlangt die Wahl von Testfällen, die auf bzw. knapp inner- und /oder außerhalb der Randbereiche der Äquivalenzklassen liegen.
Siehe auch Grenzwert.
|
| Grenzwerttest |
Siehe Grenzwertanalyse. |
| Grenzwertüberdeckung
|
Der prozentuale Anteil der Grenzwerte, die durch eine Testsuite ausgeführt werden.
|
| Grundursache |
Ein zugrundeliegender Faktor, der eine Nichtkonformität verursacht und möglichst durch eine Prozessverbesserung permanent eliminiert werden sollte.
|
| GUI-Test |
1. Test von Anwendungen mit einer grafischen Bedienoberfläche, POC/POO ist dabei die Oberfläche
2. Test der Bedienelemente eines Programms mit grafischer Oberfläche |
| Gutachter |
Siehe Prüfer |
| H |
|
| Halstead Metrik |
Metriken zur Bewertung der textuellen Komplexität von Programmen, die auf der Anzahl der Operatoren und Operanden sowie auf der Anzahl von Operatoren- und Operandenaufrufe basiert. |
| Heuristische Evaluation
|
Eine (statische) Bewertung der Benutzbarkeit einer Benutzerschnittstelle, um ihre Übereinstimmung mit anerkannten (heuristischen) Grundsätzen der Ergonomie zu beurteilen.
|
| Horizontale Rückverfolgbarkeit
|
Die Verfolgung von Anforderungen über eine Teststufe über die Ebenen der Testdokumentation (z.B. Testkonzept, Testentwurfsspezifikation, Testfallspezifikation, Testvorgehensspezifikation oder Testskripte). |
| HW |
Hardware |
| I |
|
| IEC |
International Electrotechnical Commission |
| IEEE |
Institute of Electrical and Electronic Engineers |
| IEEE 1008 |
IEEE Standard; "IEEE Standard for Software Unit Testing" |
| IEEE 1012 |
IEEE Standard: "IEEE Standard for Software Verification and Validation" |
| IEEE 1028 |
IEEE Standard: "IEEE Standard for Software Reviews" |
| IEEE 1044 |
IEEE Standard: "IEEE Standard Classification for Software Anomalies" |
| IEEE 1219 |
IEEE Standard: "IEEE Standard for Software Maintenance" |
| IEEE 610 |
IEEE Standard: "IEEE Standard Glossary of Software Engineering Terminology" |
| IEEE 829 |
IEEE Standard: "IEEE Standard for Software Test Documentation" |
| implementationsorientierter Test |
siehe struktureller Test |
| Individualsoftware |
Software, welche für einen einzelnen oder eine Gruppe von Kunden entwickelt wird. Das Gegenstück ist Standard-Software.
|
| informelles Review |
Review ohne festgelegten formalen (dokumentierten) Ablauf. |
| Inkrementeller Test |
Test, wobei die Komponenten oder Systeme integriert werden und einzelnen oder in Gruppen getestet werden, bis alle Komponenten oder Systeme integriert und getestet sind.
|
| Inkrementelles Entwicklungsmodell |
In größeren Projekten folgt die Entwicklung einem inkrementellen Lebenszyklusmodell, wobei jede Lieferung einen Teil der gesamten Anforderungen des Projekts abdeckt. Die Anforderungen werden priorisiert und mit dem nächsten Release ausgeliefert. In einigen, aber nicht in allen Fällen, wird jedes Release mittels eines "Mini-V-Modell" mit den Phasen Entwurf, Implementierung und Test abgewickelt.
|
| Inspektion |
Eine Reviewart, die auf einer Sichtprüfung von Dokumenten beruht, um Mängel zu finden, z.B. Nichteinhaltung von Entwicklungsstandards, Nicht-Konformität gegenüber zugrundeliegenden Dokumenten, usw. . Es ist die formalste Reviewtechnik und sie folgt deshalb einem dokumentierten Vorgehen. [nach IEEE 610, IEEE 1028]
|
| Installationsanleitung |
Als Installationsanleitung bezeichnet man auf einem geeignetem Medium mitgelieferte Instruktionen, die durch den Installationsprozess führen. Dies kann eine textuelle Beschreibung oder eine ausführbare Installationsprozedur oder eine ähnliche Prozessbeschreibung sein. |
| Installationstest |
Test der Installierbarkeit eines Softwareprodukts.
Siehe auch Portabilitätstest. |
| Installationswizard |
Als Installationswizard bezeichnet man auf einem geeigneten Medium ausgelieferte Software, die durch den Installationsprozess führt. Normalerweise wird damit die Installation ausgeführt. Während der Installation können Optionen gesetzt werden und über den Abschluss der Installation werden Rückmeldungen über das Ergebnis ausgegeben. |
| Installierbarkeit |
Die Fähigkeit eines Software-Produkts in einer spezifizierten Umgebung installierbar zu sein. [ISO 9126]
Siehe auch Übertragbarkeit.
|
| Instrumentierer |
Ein Softwarewerkzeug, welches für die Instrumentierung verwendet wird. |
| Instrumentierung |
(Werkzeuggestütztes) Einfügen von Protokoll- oder Zählanweisungen
in den Quell- und/oder Objektcode eines Testobjekts, um während der Ausführung Informationen über das Programmverhalten zu sammeln, um z.B. die Überdeckung zu messen.
|
| intake test |
Eine spezielle Ausprägung eines smoke test, um entscheiden zu können, ob eine Komponente oder ein System die notwendige Testreife hat.
Eine intake test wird typischerweise zu Beginn einer Testauführung durchgeführt.
Siehe auch Smoketest. |
| Integration |
(1) Der Prozess der Verknüpfung von Komponenten zu grösseren Gruppen.
(2) Verbinden von Software- und/oder Hardware-Komponenten zu größeren Baugruppen oder zum Gesamtsystem. |
| Integrationstest |
Test mit dem Ziel, Fehlerwirkungen in den Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten zu finden.
Siehe auch Komponentenintegrationstest, Systemintegrationstest. |
| Integrationstest ("im Großen") |
Siehe Systemintegrationstest. |
| Integrationstest ("im Kleinen") |
Siehe Komponentenintegrationstest. |
| Interoperabilität |
Das Vermögen/die Fähigkeit einer Software mit einer oder mehreren spezifizierten Komponenten zusammenzuwirken. [nach ISO 9126]
Siehe auch Funktionalität.
|
| Interoperabilitätstest |
Die Durchführung eines Tests zur Bestimmung der Interoperabilität eines Software-Produkts.
Siehe auch funktionales Testen, Interoperabilität. |
| invalid testing
|
Test unter Verwendung von Eingabewerten, die durch eine Komponente oder ein System zurückgewiesen werden sollten.
Siehe auch Fehlertoleranz. |
| IPD |
Integrated Product Development |
| ISO |
International Standardization Organization.
|
| ISO 12207 |
ISO Standard: "Informationstechnik - Prozesse im Lebenszyklus von Software" |
| ISO 14598 |
ISO Standard: "Informationstechnik - Bewertung von Softwareprodukten" |
| ISO 15504 |
ISO Standard: "Software engineering - Process assessment" |
| ISO 2382 |
ISO Standard: "Informationstechnik - Begriffe" |
| ISO 9000:2000 |
ISO Standard: "Qualitätsmanagementsysteme - Grundlagen und Begriffe" |
| ISO 9001 |
ISO Standard: "Qualitätssicherungssysteme; Modell zur Darlegung der Qualitätssicherung in Design/Entwicklung, Produktion, Montage und Kundendienst" |
| ISO(IEC) 9126 |
ISO Standard: "Software-Engineering - Qualität von Software-Produkten" |
| Isolationstest |
Test von einzelnen Komponenten ohne Einbeziehung von aufgerufenen oder aufrufenden Komponenten. Falls notwendig, werden aufgerufene und aufrufende Komponenten durch Treiber und Platzhalter simuliert.
|
| Istverhalten
|
Im Test beobachtetes/erzeugtes Verhalten einer Komponente oder eines Systems unter spezifizierten Bedingungen.
Synonym: Istergebnis
|
| IT |
Informations-Technologie |
| Iteratives Entwicklungsmodell |
Ein Lebenszyklusmodell in der Entwicklung, bei dem das Projekt in eine größere Anzahl von Iterationen aufgeteilt wird. Eine Iteration ist ein vollständiger Entwicklungszyklus, durch welchen ein ausführbares (internes oder externes) Produkt erzeugt wird; wobei dieses eine Teilmenge des Endprodukts der Entwicklung, welche von Iteration zu Iteration bis zum Endprodukt hin wächst. |
| K |
|
| Kick-Off |
Im Kick-Off eines Reviews versorgt der Moderator die am Review beteiligten Personen mit den notwendigen Unterlagen. Dies kann mit Hilfe einer schriftlichen Einladung erfolgen, oder optional auch in einer Vorbesprechung. Die Vorbesprechung informiert über Ziele sowie den genauen Ablauf des Reviews.
Ggf. wird das Erreichen d. Eingangsbedingungen geprüft. |
| Klassentest |
Test einer oder mehrerer Klassen eines objektorientierten Softwaresystems.
Siehe auch Komponententest. |
| Klassifikationsbaummethode
|
Ein Black-Box-Testentwurfsverfahren, bei dem die mittels eines Klassifikationsbaums dargestellten Testfälle derart entworfen werden, das Kombinationen der Repräsentanten von Eingabe- und/oder Ausgabebereichen ausgeführt werden. [Grochtmann]
|
| Koexistenz
|
Das Vermögen/die Fähigkeit eines Software-Produkts mit anderer Software in einer (gemeinsamen) Umgebung die gemeinsamen Ressourcen zu teilen. [ISO 9126]
Siehe auch Portabilitätstest. |
| Kombinationsregeln |
Regeln zur Kombination der möglichen Eingabedaten bei datenbereichsbezogenen Testverfahren. |
| Kommerzielle Standard-Software |
Siehe Standard-Software. |
| Kompabilitätstest |
Siehe Interoperabilitätstest. |
| Komparator |
Werkzeug zum automatischen Vergleich der Soll- und Istergebnisse. |
| Komplexität |
Schwierigkeitsgrad mit dem der Entwurf und/oder die interne Struktur einer Komponente oder eines Systems zu verstehen, zu warten und zu prüfen ist.
Siehe auch zyklomatische Komplexität.
|
| Komponente |
Kleinste Softwareeinheit, die für sich getestet werden kann.
|
| Komponentenintegrationstest |
Test wird durchgeführt mit dem Ziel Fehler in den Schnittstellen und dem Zusammenwirken der integrierten Komponenten aufzudecken.
|
| Komponentenspezifikation |
Die Beschreibung der Funktion einer Komponente spezifiziert in Form von Ausgabewerten für spezifizierte Eingabewerte unter spezifizierten Bedingungen, und geforderten nicht-funktionalen Verhalten (z.B. Ressourcenmanagement).
|
| Komponententest |
Test einer (einzelnen) Komponente. [nach IEEE 610]
|
| Komponententestrahmen-Werkzeug |
Testrahmen werden auch als Komponententestrahmen bezeichnet, wenn sie einen besonderen Fokus auf den Komponententest haben. Diese Art von Werkzeugen unterstützt den Selbsttest einer Kompo-nente parallel zur Erzeugung des Objektcodes. [Nach ISTQB_FL_Syllabus_2005-D-RELEASED] |
| Konfiguration |
Die Anordnung eines Computersystems bzw. Komponente wie sie durch Anzahl, Beschaffenheit und Verbindungen seiner Bestandteile definiert ist.
|
| Konfigurationsaudit |
Eine Funktion, um den Inhalt von Bibliotheken hinsichtlich der Konfigurationsobjekte, z.B. auf Übereinstimmung mit Standards, zu überprüfen. [IEEE 610] |
| Konfigurationsausschuss |
Eine Gruppe von Personen, welche für die Bewertung und Freigabe/Nichtfreigabe von vorgeschlagenen Änderungen an freigegebenen Konfigurationsobjekten und für die Sicherstellung der freigegebenen Änderungen verantwortlich ist. |
| Konfigurationsbuchführung |
Ein Element des Konfigurationsmanagements, bestehend aus der Aufzeichnung und Berichterstattung um eine Konfiguration effektiv zu managen. Diese Information enthält eine Liste einer freigegebenen Konfigurationsidentifizierung, der Status der vorgeschlagenen Änderungen an der Konfiguration, und den Umsetzungsstatus der freigegebenen Änderungen. [IEEE 610] |
| Konfigurationsidentifikation
|
Bestandteil des Konfigurationsmanagements, bestehend aus der Festlegung der Konfigurationselemente eines Systems und der Aufzeichnung ihrer funktionalen und physikalischen Eigenschaften in einer technischen Dokumentation. [IEEE 610]
|
| Konfigurationskontrolle
|
Bestandteil des Konfigurationsmanagements, bestehend aus der Bewertung, Koordination, Freigabe oder Nicht-Freigabe der Implementierung von Änderungen an den Konfigurationselementen nach der Etablierung der Identifikation der Konfiguration. [IEEE 610]
|
| Konfigurationsmanagement |
(1) Ein Wissenszweig, der technische und administrative Ausrichtung und Überwachung anwendet, zur: Identifizierung und Dokumentation der fachlichen und physikalischen Merkmale eines Konfigurationselements, Überwachung, Aufzeichnung und Berichten von Änderungen solcher Merkmale, sowie Berichten von Änderungsprozess und Umsetzungsstatus und Verifizierung der Übereinstimmung mit spezifizierten Anforderungen. [IEEE 610]
(2) Aktivitäten zur Verwaltung der Konfigurationen.
|
| Konfigurationsmanagementwerkzeug |
Werkzeug zur Unterstützung des Konfigurationsmanagements.
Siehe auch Konfigurationsmanagement. |
| Konfigurationsobjekt |
(1) Eine Zusammenstellung von Hardware, Software oder beidem, welches für Konfigurationsmanagement bestimmt ist und als atomarer Baustein im Konfigurationsmanagementprozess betrachtet werden kann. [IEEE 610]
(2) Softwareobjekt oder Testumgebung, die der Konfigurationsverwaltung unterliegt.
|
| Konfigurationstest
|
Siehe Portabilitätstest.
|
| Konformität |
(1) Die Erfüllung festgelegter Forderungen.
(2) Merkmale von Software, die bewirken, dass die Software anwendungsspezifische Normen oder Vereinbarungen zur Übertragbarkeit erfüllt. [DIN 66272]
|
| Konformitätstest |
Testen mit dem Ziel, die Ordnungsmässigkeit einer Komponente oder eines Systems zu bestimmen.
|
| Konformitätstest |
Siehe Test auf Ordnungsgemässigkeit. |
| konkreter Testfall |
(1) Siehe physischer Testfall
(2) Testfall mit konkreten Werten für die Testdaten.
Siehe auch logischer Testfall. |
| Konsistenz
|
Der Grad der Uniformität, Standardisierung und das Nicht-Vorhandensein von Widersprüchen zwischen den Dokumenten und Teilen eines Systems oder Komponente. [IEEE 610]
|
| konstruktive (Software) Qualitätssicherung |
Einsatz von Methoden, Werkzeugen, Richtlinien usw., die dazu beitragen, dass
- der Erstellungsprozess und/oder das zu erstellende Produkt a priori bestimmte Eigenschaften besitzt,
- Fehlhandlungen vermieden oder verringert werden.
Anmerkung: Maßnahmen der konstruktiven Software-Qualitätssicherung werden insbesondere in den frühen Phasen angewendet. Durch einen systematischen Entwicklungsprozess können viele Fehler vermieden werden. |
| Kontrollfluss |
Eine abstrakte Repräsentation von allen möglichen Reihenfolgen von Ereignissen (Pfaden) während der Ausführung einer Komponente oder Systems.
|
| Kontrollflussanomalie |
Statisch feststellbare Unstimmigkeit beim Ablauf des Testobjekts (z.B. nicht erreichbare Anweisungen). |
| kontrollflussbasierter Test |
Dynamischer Test, bei dem die Testfälle unter Berücksichtigung des Kontrollflusses des Testobjekts hergeleitet werden und die Vollständigkeit der Prüfung (Überdeckungsgrad) anhand des Kontrollflussgraphen bewertet wird.
Siehe auch White-Box Test. |
| Kontrollflussgraph |
(1) Eine Sequenz von Ereignissen (Pfaden) der Ausführung in einer Komponente oder einem System.
(2) Graphische Darstellung aller möglichen alternativen Kontrollflusspfade in einer Komponente.
(3) Ein gerichteter Graph G = (N, E, nstart, nfinal). N ist die endliche Menge der Knoten. E ist die Menge der gerichteten Kanten. »nstart« ist der Startknoten. »nfinal« ist der Endknoten. Kontrollflussgraphen dienen zur Darstellung der Kontrollstruktur von Komponenten.
|
| Kontrollflusspfad
|
Siehe Pfad.
|
| Konvertierungstest
|
Test von Software, die verwendet wird, um Daten von einem vorhandenen Sytsem zur Verwendung in einem das alte System ersetzendes System zu konvertieren.
|
| Korrektheit
|
Der Grad der Übereinstimmung der Software mit seiner Spezifikation. [IEEE 610]
|
| Kundenakzeptanztest |
Akzeptenztest durch repräsentative Kunden/Anwender in der Einsatzumgebung des Kunden/Anwenders um vor der endgültigen Freigabe eine Rückmeldung vom Markt einzuholen und um das Interesse des potentiellen Kunden zu erzeugen. |
| kundenindividuelle Software |
Siehe Individualsoftware.
|
| L |
|
| Lasttest |
Messung des Systemverhaltens in Abhängigkeit steigender Systemlast (z.B. Anzahl parallele Benutzer, Anzahl Transaktionen), um zu bestimmen, welche Last durch ein System oder eine Komponente bewältigt werden kann.
Siehe auch Stresstest. |
| Lasttestwerkzeug |
Ein Werkzeug für Messung der Performanz besteht i.w. aus zwei Komponenten:
Lastgenerierung und Performanzmessung (für die generierte Last).
Durch Generierung der Last wird entweder eine hohe Anzahl von Benutzern oder ein hohes Datenvolumen simuliert. Zur Laufzeit werden die Antwortzeiten für die ausgewählten Transaktionen aufgezeichnet. Lasttestwerkzeuge erzeugen i.d.R. Berichte basierend auf Testprotokollen und graphischen Darstellungen der Last gegen die Antwortzeiten.
Siehe auch Mitschnittwerkzeug.
|
| LCSAJ |
LCSAJ (Linear Code Sequence and Jump) enthalten drei Bestandteile (identifiziert durch eine Zeilenzahl in der Auflistung des Quellcode):
- der Start einer linearen Folge von ausführbaren Anweisungen,
- das Ende der linearen Folge von Anweisungen
- und das Sprungziel, zu dem der Kontrollfluss am Ende der linearen Folge von Anweisungen verzweigt.
|
| LCSAJ Überdeckung |
Der prozentuale Anteil der LCSAJs einer Komponente, welche durch eine Testsuite ausgeführt wurden. 100% LCSAJ Überdeckung schliesst 100% Entscheidungsüberdeckung ein. |
| LCSAJ Test
(-verfahren) |
Dynamischer Test, bei dem die Testfälle unter Berücksichtigung der LCASJ des Testobjekts hergeleitet werden. |
| Leistungsindikator |
Ein Maß auf einer höheren Abstraktionsstufe um die Effizienz und/oder Effektivität einer Entwicklung zu messen; z.B. Fehleraufdeckungsrate (DDP) im Bereich Testen. [CMMI] |
| Leiter einer Inspektion |
Siehe Moderator. |
| Linear Code Sequence and Jump (LCSAJ)-Verfahren |
siehe LCSAJ-Test |
| Lines Of Code |
Metrik, die die Anzahl der Zeilen im Quelltext mit oder ohne Kommentarzeilen misst. |
| logik-getriebener Test |
Siehe White-Box Test. |
| Logik-Überdeckungstest |
Siehe White-Box-Test. [Myers]
|
| logischer Testfall |
(1) Siehe abstrakter Testfall.
(2) Testfall ohne Angabe von konkreten Werten für Eingaben und Ausgaben; es werden meist Wertebereiche (Äquivalenzklassen) für die Eingaben (und Ausgaben) angegeben.
|
| M |
|
| MAN |
Management (Process Area of SPICE) |
| Managementreview |
(1) Eine systematische Bewertung des Software-Beschaffungs-, Lieferungs-, Entwicklungs- /Wartungsprozesses und Betreibens von Software durchgeführt durch oder im Auftrag des Managements, das den Fortschritt überwacht, den Status des Vorhabens und Zeitplans bestimmt und Anforderungen und Budget bestätigt. Es kann auch die Effektivität und Zweckmäßigkeit des Management-Ansatzes bewerten. [nach IEEE 610, IEEE 1028]
(2) Review, bei dem Projektpläne und Entwicklungsprozesse als solches analysiert werden.
|
| Mangel |
(1) Nichterfüllung einer Anforderung in Bezug auf einen beabsichtigten oder festgelegten Gebrauch [ISO 9000:2000]
(2) Ein Mangel liegt vor, wenn eine gestellte Anforderung oder berechtigte Erwartung nicht angemessen erfüllt wird.
|
| Maskierte Fehler |
siehe Fehlermaskierung |
| Massentest |
Siehe Volumentest. |
| Mastertestplan |
Ein Testplan, welcher typischerweise mehrere Teststufen adressiert.
See also test plan. |
| Maß |
Die Anzahl oder Kategorie, die einem Attribut einer Einheit durch die Durchführung einer Messung zugeordnet wird. [ISO 14598] |
| McCabe Metrik |
Metrik zur Bewertung der strukturellen Komplexität von Programmen, deren Berechnung auf dem Kontrollflussgraphen basiert. Berechnet die zyklomatische Zahl. |
| Mehrfach-Bedingung |
Siehe zusammengesetzte Bedingung. |
| Mehrfach-Bedingungsüberdeckung
|
Der prozentuale Anteil von Kombinationen der atomaren Teilbedingungen, die durch eine Gruppe von Testfällen ausgeführt wurden. 100% Mehrfach-Bedingungsüberdeckung schliesst die minimale Mehrfach-Bedingungsüberdeckung und damit die Entscheidungsüberdeckung ein.
|
| Mehrfach-Bedingungsüberdeckungstest |
Kontrollflussbasiertes, dynamisches Testverfahren, das die Überdeckung der atomaren Teilbedingungen einer Entscheidung mit »wahr« und »falsch« in allen Kombinationen fordert. |
| Meilenstein |
Markiert einen Zeitpunkt im Softwareentwicklungsprojekt
(-prozess), zu dem ein bestimmtes Arbeitsergebnis fertig gestellt sein soll.
|
| Merkmal |
Ein Attribut einer Komponente oder eines Systems, spezifiziert oder abgeleitet aus der Anforderungsspezifikation (z.B. Zuverlässigkeit, Benutzbarkeit oder Entwurfsrestriktionen) [nach IEEE 1008]. |
| Mess-Skala |
Eine Skala, die den Typ der Datenanalyse, der auf ihr ausgeführt kann, einschränkt.
|
| Messung |
Der Prozess eine Zahl oder Kategorie einer Einheit zuzuweisen um ein Attribut einer Einheit zu beschreiben. [ISO 14598] |
| Metrik |
(1) Eine Messskala und eine Methode die für Messungen verwendet wird. [ISO 14598]
(2) Größe zur Messung einer bestimmten Eigenschaft eines Programms oder einer Komponente. Die Durchführung der Messung ist Aufgabe der statischen Analyse. |
| Migration |
(1) Umzug einer Software von einer Umgebung in eine andere (z.B: von einer Test- in die Produktionsumgebung)
(2) Datenmigration: Überpielen von Test- oder produktiven Daten von einem System in ein anderes (z.B. vom Altsystem in ein neu entwickeltes System |
| Migrationstest |
Siehe Konvertierungstest. |
| minimale Mehrfach-Bedingungsüberdeckung
|
Kontrollflussbasiertes, dynamisches White-Box-Testverfahren, das die Überdeckung der atomaren Teilbedingungen einer Entscheidung mit »wahr« und »falsch« fordert, wobei nur alle die Kombinationen zu berücksichtigen sind, die eine Änderung des Wahrheitswertes der Gesamtbedingung bewirken.
Anmerkung:
Minimale Mehrfach-Bedingungsüberdeckung schließt die modifizierte Bedingungs-/Entscheidungsüberdeckung ein.
Hinweis zu sehr ähnlichem Verfahren [RTC-DO 178B] :
vgl. modifizierte Bedingungs-
/Entscheidungsüberdeckung |
| mistake |
Siehe Fehler. |
| Mitschnittwerkzeug |
Ein Werkzeug zur Unterstützung der Testausführung, wobei Eingaben des Benutzers während der manuellen Testdurchführung zur Erzeugung von ausführbaren wiederholbaren Testskripten verwendet werden. Solche Testwerkzeuge werden i.d.R. zur Unterstützung von Regressionstests genutzt.
|
| Mock |
Enthält mehr Funktionalität als ein Dummy, das Einstellen von gewünschten Reaktionen ist möglich.
Siehe auch Dummy. |
| Modellierungs-
werkzeug |
Ein Modellierungswerkzeug ist ein Werkzeug zur Darstellung und Optimierung von Geschäftsprozessen unter Verwendung vorgegebener Methoden.
|
| Moderator |
Leiter und Hauptverantwortlicher einer Reviewsitzung oder einer Inspektion. |
| Modifikation |
Siehe Änderung |
| Modifizierbarkeit
|
Das Vermögen/ die Fähigkeit eines Softwareprodukts die Durchführung spezifizierter Änderungen zu ermöglichen [ISO 9126]
Siehe auch Wartbarkeit.
|
| modifizierte Bedingungs-
/Entscheidungsüberdeckung |
Kontrollflussbasiertes, dynamisches Testverfahren, das Tests fordert, die für jede atomare Teilbedingung von Entscheidungen zeigen, dass diese Teilbedingung (unabhängig von den anderen) den Entscheidungsausgang (wahr oder falsch) beeinflusst.
Anmerkung:
Modifizierte Bedingungs-/Entscheidungsüberdeckung schließt die Entscheidungsüberdeckung ein.
|
| modifizierter Bedingungs-/Entscheidungstest |
|
| modifizierter Mehrfach-Bedingungsüberdeckungstest |
|
| Modul |
Siehe Komponente.
|
| Modultest |
(1) Siehe Komponententest.
(2) Test eines einzelnen Moduls eines modularisierten Softwaresystems.
|
| Monitor |
Ein Softwarewerkzeug oder Hardwareeinheit, die gleichzeitig mit dem zu testenden System bzw. der Komponente arbeitet und dessen Betrieb überwacht, aufzeichnet und/oder analysiert oder verifiziert. [nach IEEE 610]
|
| Mutationstest |
Siehe Back-to-Back-Test. |
| N |
|
| N-Switch Überdeckung |
Der prozentuale Anteil der Folgen von (N+1)-Übergängen, die durch eine Testsuite ausgeführt wurden. [Chow] |
| N-Switch-Test |
Eine Ausprägung des zustandsbasierten Testens, in welchen Testfälle entworfen werden, um gültige Folgen von (N+1)-Zustandsübergängen ausführen.
Siehe auch zustandsbezogener Test. |
| Nachbedingung |
Zustand des Testobjekts (und/oder der Umgebung), in dem sich das Testobjekt (oder die Umgebung) nach Ausführung eines Testfalls oder einer Testsequenz befindet. |
| Nachtest |
Wiederholung eines Tests oder einer Test-Teilmenge an einer Korrektur des Testobjektes zur Verifikation der Fehlerkorrektur. Auch Re-Test. Nicht zu Verwechseln mit Regressionstest. |
| Nebenläufigkeitstest
|
Test, um festzustellen, wie das Auftreten von zwei oder mehreren Aktivitäten innerhalb des gleichen Zeitintervalls durch die Komponente oder das System gehandhabt wird. Dies wird entweder durch verschänkte oder durch gleichzeitige Ausführung der Aktivitäten erreicht. [nach IEEE 610]
|
| negatives Testen |
(Funktionaler) Testfall mit Eingabewerten, die laut Spezifikation des Testobjekts unzulässig sind. Das Testobjekt soll robust reagieren, z.B. indem es die Werte abweist und eine entsprechende Ausnahmebehandlung durchführt. |
| nicht erreichbarer Code |
Code, der nicht erreicht werden kann und deshalb nicht ausgeführt werden kann. |
| nicht funktionale Anforderung |
Beschreibt Attribute des Systemverhaltens, also wie gut bzw. mit welcher Qualität das System seine Funktion erbringen soll. Umsetzung beeinflusst stark, wie zufrieden der Kunde bzw. Anwender mit dem Produkt ist. [ISO 9126]
Merkmale aus Nutzersicht sind nach [ISO 9126]: Zuverlässigkeit, Benutzbarkeit, Effizienz. Aus der Sicht der Entwicklung und Wartung sind relevant: Änderbarkeit und Übertragbarkeit.
Siehe auch Qualitätsziel. |
| nicht funktionaler Test |
(1) Test der Eigenschaften eines System, die nicht direkt mit der Funktionalität in Verbindung stehen; z.B. Zuverlässigkeit, Effizienz, Benutzbarkeit, Änderbarkeit und Übertragbarkeit.
(2) Prüfung der nicht funktionalen Anforderungen. |
| nicht-ausführbarer Pfad |
Ein Pfad, der durch keine Menge von Eingabewerten ausgeführt werden kann.
|
| Nicht-bestanden
/ durchgefallen |
Ein Test wird als nicht-bestanden angesehen, wenn das aktuelle Verhalten nicht mit dem erwarteten Verhalten übereinstimmt. |
| nicht-bestandener Test |
Siehe durchgefallen. |
| nicht-funktionales Testverfahren |
Eine Vorgehen, welches Testfälle für das nicht-funktionale Testen basierend auf einer Analyse der Spezifikation einer Komponente oder eines Systems ohne Berücksichtigung der internen Struktur herleitet oder auswählt.
Siehe auch Black-Box Testentwurfs-Verfahrren.
|
| Nichtkonformität |
Nichterfüllung einer spezifizierten Anforderung. [ISO 9000] |
| O |
|
| Objektorientierter Test |
Dynamischer, funktionaler Test, bei dem die speziellen Anforderungen eines objektorientierten Softwaresystems berücksichtigt werden. |
| Operabilität |
Die Fähigkeit/das Vermögen eines Software-Produkts, die es dem Anwender ermöglicht mit dem Produkt zu arbeiten. [ISO 9126].
Siehe auch Benutzbarkeit. |
| operationale (Abnahme-) Tests |
Beim operationalen Test (orientiert an Nutzungsprofilen) kann das Hauptziel sein, ein System hinsichtlich Ausprägungen wie Zuverlässigkeit oder Verfügbarkeit zu bewerten. [Nach ISTQB_FL_Syllabus_2005-D-RELEASED] |
| Orakel |
Siehe Testorakel. |
| Ordnungsmäßigkeit |
Das Vermögen/die Fähigkeit eines Softwareprodukts anwendungsspezifische Normen oder Vereinbarungen oder gesetzliche Bestimmungen und ähnliche Vorschriften zu erfüllen. [ISO 9126], [DIN 66272]
Synonym: Konformität.
|
| ORG |
Organisation (Process Area of SPICE) |
| P |
|
| PA |
Process Area (siehe SPICE) |
| Paarweises Programmieren |
Eine Vorgehensweise zur Softwareentwicklung, bei der die Codezeilen einer Komponente durch zwei Programmierer gemeinsam |
