ISTQB Foundation (CTFL v4.0) Probeprüfung #1 — Fragen & Antworten
Alle Fragen dieser Probeprüfung, mit markierter richtiger Antwort und einer schriftlichen Begründung zu jeder Option unten — zum Lesen und Wiederholen, kein zeitlich begrenzter Durchlauf.
Welche der folgenden Aussagen beschreibt den Unterschied zwischen Testen und Debugging am besten?
Testen findet Fehlerwirkungen, die durch Fehlerzustände verursacht werden; Debugging findet, analysiert und entfernt den Fehlerzustand.
Richtig — dynamisches Testen deckt Fehlerwirkungen auf, Debugging diagnostiziert und behebt deren Ursache.
Testen und Debugging sind zwei Bezeichnungen für dieselbe Tätigkeit.
Es sind unterschiedliche Tätigkeiten mit verschiedenen Zielen, oft von verschiedenen Personen ausgeführt.
Debugging beweist, dass die Software frei von Fehlerzuständen ist.
Keine Tätigkeit kann die Abwesenheit von Fehlerzuständen beweisen; das ist ein Testgrundsatz und nicht die Aufgabe des Debuggings.
Testen behebt die Fehlerzustände, die es bei der Ausführung findet.
Das Beheben ist Debugging/Entwicklung, nicht Testen.
Testen dient dem Auffinden von Fehlerwirkungen (Hinweisen auf Fehlerzustände); Debugging ist die Entwicklungstätigkeit, die den zugrunde liegenden Fehlerzustand lokalisiert, analysiert und behebt.
Ein Projektleiter sagt: „Wir testen so lange, bis wir jede mögliche Eingabekombination ausgeführt haben, dann ist das Produkt fehlerfrei.“ Gegen welchen Testgrundsatz verstößt diese Aussage?
Vollständiges Testen ist unmöglich.
Richtig — alles zu testen ist nicht machbar; daher steuern Techniken und Risiko den Aufwand.
Tests nutzen sich ab.
Das „Pestizid-Paradoxon“ betrifft das Nachlassen wiederholter Tests, nicht das vollständige Testen.
Fehlerzustände treten gehäuft auf.
Dieser Grundsatz betrifft die ungleiche Verteilung von Fehlerzuständen, nicht die Machbarkeit vollständigen Testens.
Testen ist kontextabhängig.
Zwar ein Grundsatz, aber nicht der hier verletzte.
Vollständiges Testen (alle Eingabe-/Vorbedingungskombinationen) ist außer in trivialen Fällen unmöglich; stattdessen werden Risiko und Prioritäten genutzt.
Welche ZWEI der folgenden Punkte sind Ziele des Testens? (Wählen Sie zwei.)
Fehlerzustände und Fehlerwirkungen finden.
Ein primäres Ziel des Testens ist das Aufdecken von Fehlerzuständen vor der Freigabe.
Vertrauen in das Qualitätsniveau aufbauen.
Vertrauen zu gewinnen, dass die Qualität ausreicht, ist ein Kernziel des Testens.
Beweisen, dass die Software keine Fehlerzustände enthält.
Unmöglich — Testen kann nur die Anwesenheit, nicht die Abwesenheit von Fehlerzuständen zeigen.
Die gefundenen Fehlerzustände beheben.
Das Beheben ist Debugging/Entwicklung, kein Testziel.
Testen findet Fehlerzustände und schafft Vertrauen in das Qualitätsniveau; es kann die Abwesenheit von Fehlerzuständen nicht beweisen, und Beheben ist kein Testziel.
Ein Entwickler vertippt sich bei einer Formel im Quellcode. Das Programm zeigt später während eines Testlaufs eine falsche Summe an. Was ist die falsche Summe auf dem Bildschirm in ISTQB-Begriffen?
Eine Fehlerwirkung.
Richtig — eine Fehlerwirkung ist das beobachtbare falsche Ergebnis der Ausführung von Code mit einem Fehlerzustand.
Eine Fehlhandlung.
Die Fehlhandlung war das menschliche Vertippen der Formel.
Ein Fehlerzustand.
Der Fehlerzustand ist die fehlerhafte Formel im Code, nicht die angezeigte falsche Summe.
Eine Grundursache.
Die Grundursache ist der zugrunde liegende Grund; die falsche Summe ist die sichtbare Fehlerwirkung.
Fehlhandlung → Fehlerzustand (im Code) → Fehlerwirkung (beobachtetes Fehlverhalten bei Ausführung).
Beim Testen eines großen Systems stellt das Team fest, dass die meisten Fehlerzustände in zwei von zwanzig Modulen konzentriert sind. Welcher Testgrundsatz wird damit veranschaulicht?
Fehlerzustände treten gehäuft auf.
Richtig — die meisten Fehlerzustände konzentrieren sich auf wenige Komponenten.
Testen zeigt die Anwesenheit, nicht die Abwesenheit von Fehlerzuständen.
Als Grundsatz wahr, beschreibt aber keine Konzentration von Fehlerzuständen.
Frühes Testen spart Zeit und Geld.
Betrifft den Zeitpunkt des Testens, nicht die Konzentration.
Das Pestizid-Paradoxon.
Dieser Grundsatz betrifft das Nachlassen der Wirksamkeit über die Zeit, nicht die Häufung.
Häufung von Fehlerzuständen: Eine kleine Anzahl von Modulen enthält meist die meisten Fehlerzustände (verwandt mit dem Pareto-Prinzip).
Ein Produkt hat alle Tests ohne verbleibende Fehlerwirkungen bestanden, doch nach der Freigabe beklagten die Nutzer, dass es ihre Bedürfnisse nicht erfüllt. Welcher Testgrundsatz wird hier deutlich?
Der Trugschluss der Fehlerfreiheit.
Richtig — ein System kann gemäß Spezifikation fehlerfrei sein und dennoch die Nutzerbedürfnisse verfehlen.
Vollständiges Testen ist unmöglich.
Nicht relevant — es geht um die Gebrauchstauglichkeit, nicht um die Testvollständigkeit.
Fehlerzustände treten gehäuft auf.
Betrifft den Ort der Fehlerzustände, nicht die Nutzerbedürfnisse.
Testen ist kontextabhängig.
Wahr, beschreibt aber nicht die Lücke zwischen bestandenen Tests und unerfüllten Bedürfnissen.
Der Trugschluss der Fehlerfreiheit: Fehlerzustände zu finden und zu beheben nützt nichts, wenn das gebaute System die Bedürfnisse und Erwartungen der Nutzer nicht erfüllt.
Warum ist es im Allgemeinen vorteilhaft, Testaktivitäten so früh wie möglich im Softwareentwicklungslebenszyklus einzubinden?
Früh gefundene Fehlerzustände sind meist günstiger zu beheben und teils ganz vermeidbar.
Richtig — die Behebungskosten steigen, je später ein Fehlerzustand gefunden wird.
Es garantiert, dass keine Fehlerzustände in die Produktion gelangen.
Kein Ansatz kann eine fehlerfreie Freigabe garantieren.
Es macht späteres dynamisches Testen überflüssig.
Frühes (oft statisches) Testen ergänzt das spätere dynamische Testen, ersetzt es aber nicht.
Es erlaubt dem Testteam, das Schreiben eines Testkonzepts zu überspringen.
Planung ist unabhängig vom Startzeitpunkt weiterhin nötig.
Frühes Testen (Shift-Left) findet Fehlerzustände, wenn sie billiger und einfacher zu beheben sind, und hilft, Fehlerzustände in späteren Arbeitsergebnissen zu vermeiden.
Welches der folgenden Beispiele ist eine Ursachenanalyse (Root-Cause-Analyse) und nicht nur das Festhalten einer Fehlerwirkung?
Feststellen, dass mehrere Fehlerzustände eine gemeinsame Quelle in einer unklaren Anforderung haben, und den Anforderungs-Review-Prozess verbessern.
Richtig — das adressiert die zugrunde liegende Quelle, um Wiederholungen zu vermeiden.
Die Schritte zur Reproduktion eines Absturzes im Fehlerbericht festhalten.
Das dokumentiert die Fehlerwirkung, analysiert aber nicht deren Ursache.
Den fehlgeschlagenen Test erneut ausführen, um die Fehlerwirkung zu bestätigen.
Das ist eine Bestätigung, keine Ursachenanalyse.
Dem Fehlerzustand einen Schweregrad und eine Priorität zuweisen.
Die Triage klassifiziert den Fehlerzustand, identifiziert aber nicht seine Quelle.
Die Ursachenanalyse blickt über das Symptom hinaus auf die zugrunde liegende Quelle (z. B. Prozess- oder Wissenslücke), um ähnliche Fehlerzustände zu vermeiden.
Zwei unabhängig entwickelte Module werden zusammengeführt, und das Testen konzentriert sich darauf, ob sie über ihre Schnittstelle korrekt Daten austauschen. Welche Teststufe wird durchgeführt?
Integrationstest.
Richtig — er zielt auf Schnittstellen und Interaktionen zwischen integrierten Komponenten.
Komponententest.
Der Komponententest prüft ein einzelnes Modul isoliert.
Systemtest.
Der Systemtest prüft das Verhalten des gesamten, durchgängigen Systems.
Abnahmetest.
Der Abnahmetest stellt die Einsatzbereitschaft für Nutzer/Kunden fest.
Der Integrationstest konzentriert sich auf die Interaktionen und Schnittstellen zwischen Komponenten oder Systemen.
Ein Team misst die Antwortzeit des Systems unter zunehmender Nutzerlast. Welche Testart ist das?
Nichtfunktionales Testen.
Richtig — die Antwortzeit unter Last ist eine Performanz- (nichtfunktionale) Eigenschaft.
Funktionales Testen.
Funktionales Testen prüft, was das System gemäß den funktionalen Anforderungen tut.
White-Box-Testen.
White-Box-Testen basiert auf der inneren Struktur, nicht auf Last/Performanz an sich.
Fehlernachtest (Bestätigungstest).
Der Fehlernachtest wiederholt Tests nach einer Behebung, um zu bestätigen, dass der Fehlerzustand weg ist.
Nichtfunktionales Testen bewertet Eigenschaften wie Performanz, Zuverlässigkeit, Benutzbarkeit und Sicherheit — also wie gut sich das System verhält, nicht was es tut.
Eine Aufsichtsbehörde verlangt vor der Inbetriebnahme den Nachweis, dass eine Bankanwendung verbindliche gesetzliche Standards erfüllt. Welche Form des Abnahmetests ist das?
Regulatorischer Abnahmetest.
Richtig — er liefert den Nachweis der Konformität mit Gesetzen/Vorschriften.
Alphatest.
Der Alphatest ist ein (simuliertes) operatives Testen durch potenzielle Nutzer am Standort des Entwicklers.
Benutzerabnahmetest (UAT).
Der UAT bestätigt die Gebrauchstauglichkeit für Endnutzer, nicht speziell die gesetzliche Konformität.
Betrieblicher Abnahmetest.
Der betriebliche Abnahmetest deckt operative Aspekte wie Backup/Restore und Wartung ab, nicht die gesetzliche Konformität.
Der regulatorische Abnahmetest weist die Konformität mit Vorgaben einer Aufsichtsbehörde nach; der vertragliche Abnahmetest die Konformität mit einem Vertrag.
Welcher der folgenden Punkte ist ein typischer Vorteil, den eine starke Continuous-Integration-(CI-)Pipeline dem Testen bringt?
Schnelles, automatisiertes Feedback, ob eine Änderung bestehende Funktionalität beschädigt hat.
Richtig — CI führt bei jeder Änderung automatisierte Tests aus und deckt Regressionen früh auf.
Es macht jeglichen Testentwurf überflüssig.
Tests müssen weiterhin entworfen werden; CI automatisiert nur deren Ausführung.
Es garantiert 100 % Testüberdeckung.
CI garantiert für sich genommen keine bestimmte Überdeckung.
Es macht den Abnahmetest überflüssig.
Der Abnahmetest bleibt nötig, um die Einsatzbereitschaft festzustellen.
CI ermöglicht schnelles, automatisiertes Feedback: Codeänderungen lösen automatisierten Build und Tests aus, sodass Regressionen rasch erkannt werden.
Welche ZWEI der folgenden sind anerkannte Teststufen im ISTQB-Foundation-Lehrplan? (Wählen Sie zwei.)
Systemtest.
Eine anerkannte Teststufe mit Fokus auf das gesamte System.
Komponententest.
Eine anerkannte Teststufe mit Fokus auf einzelne Komponenten/Einheiten.
Regressionstest.
Der Regressionstest ist eine änderungsbezogene Testart, keine Teststufe.
Performanztest.
Der Performanztest ist eine nichtfunktionale Testart, keine Teststufe.
Die vier Teststufen sind Komponenten-, Integrations-, System- und Abnahmetest. Regression und Fehlernachtest sind änderungsbezogene Testarten, keine Teststufen.
Am Ende jeder Iteration hält ein Team ein Treffen ab, um zu besprechen, was gut und was schlecht lief und was besser gemacht werden könnte, und beschließt konkrete Maßnahmen. Was ist ein anerkannter Nutzen solcher Retrospektiven für das Testen?
Prozessverbesserungen werden erkannt und vereinbart, etwa höhere Testeffektivität und -effizienz oder bessere Qualität der Testmittel.
Richtig — der Wert einer Retrospektive liegt in den vereinbarten Verbesserungsmaßnahmen, die das Testen der nächsten Iteration verbessern.
Sie ersetzen die Testüberwachung und -steuerung während der Iteration.
Eine Retrospektive blickt nach Abschluss der Iteration zurück. Überwachung und Steuerung finden während der Arbeit statt und bleiben notwendig.
Sie sind die Sitzung, in der die in einem Arbeitsergebnis gefundenen Anomalien formal erfasst und klassifiziert werden.
Das gehört zum Review (statischer Test), in dem Anomalien eines bestimmten Arbeitsergebnisses besprochen und mit Status und Schweregrad versehen werden. Eine Retrospektive betrachtet den Prozess, nicht ein Dokument.
Ihr Hauptzweck ist die Entscheidung, ob das Produkt freigegeben werden darf.
Das ist eine Freigabeentscheidung anhand von Endekriterien und Restrisiko. Eine Retrospektive liefert Verbesserungsmaßnahmen, kein Go/No-Go.
Retrospektiven führen zu vereinbarten Prozessverbesserungen, etwa höherer Testeffektivität und -effizienz, besserer Qualität der Testmittel, besserer Zusammenarbeit und Lernen sowie besserem Umgang mit der Testbasis.
Welches ist ein Hauptmerkmal des statischen Testens?
Es untersucht Arbeitsergebnisse, ohne die Software auszuführen.
Richtig — statisches Testen (Reviews, statische Analyse) führt den Code nicht aus.
Es erfordert, dass der Code in der Zielumgebung läuft.
Das beschreibt dynamisches Testen, nicht statisches.
Es kann nur auf Quellcode angewendet werden.
Statisches Testen gilt für Anforderungen, Entwürfe, User Storys u. v. m., nicht nur Code.
Es kann nur Fehlerwirkungen finden, keine Fehlerzustände.
Statisches Testen findet Fehlerzustände direkt; Fehlerwirkungen erfordern Ausführung.
Statisches Testen untersucht Arbeitsergebnisse ohne Codeausführung (Reviews und statische Analyse) und kann sehr früh angewendet werden.
Ein Review folgt einem dokumentierten Verfahren, nutzt Eingangs- und Endekriterien, erfasst Metriken und wird von einem geschulten Moderator geleitet. Welcher Review-Typ ist das?
Inspektion.
Richtig — Inspektionen sind das formellste Review, mit Metriken, Regeln und geschultem Moderator.
Informelles Review.
Informelle Reviews haben keinen formalen Prozess, keine Rollen und keine dokumentierten Ergebnisse.
Walkthrough.
Ein Walkthrough wird meist vom Autor geleitet und ist weniger formell als eine Inspektion.
Ad-hoc-Review.
Ad-hoc ist ein informeller, unstrukturierter Ansatz, nicht der beschriebene formale.
Die Inspektion ist der formellste Review-Typ mit definierten Rollen, Regeln, Metriken und einem Moderator.
Wer ist in einem formalen Review primär für das geprüfte Arbeitsergebnis und für die Behebung der darin gefundenen Fehlerzustände verantwortlich?
Der Autor.
Richtig — der Autor hat das Arbeitsergebnis erstellt und ist für dessen Korrektur verantwortlich.
Der Moderator.
Der Moderator leitet die Review-Sitzung; ihm gehört das Arbeitsergebnis nicht.
Der Protokollant.
Der Protokollant erfasst die genannten Befunde; er behebt das Produkt nicht.
Der Review-Leiter / Manager.
Diese Rollen planen oder entscheiden über das Review, besitzen aber nicht das Arbeitsergebnis.
Der Autor besitzt das Arbeitsergebnis und behebt die Fehlerzustände; der Moderator leitet das Review, der Protokollant erfasst, und die Gutachter finden Probleme.
Welchen der folgenden Fehlerzustände findet ein Werkzeug zur statischen Analyse am ehesten?
Eine Variable, die verwendet wird, bevor ihr ein Wert zugewiesen wurde.
Richtig — solche Datenflussanomalien sind typische Befunde der statischen Analyse.
Eine langsame Antwortzeit, wenn sich 1.000 Nutzer gleichzeitig anmelden.
Das ist ein Laufzeit-Performanzproblem, das Ausführung erfordert, nicht statische Analyse.
Ein Missverständnis des tatsächlichen Geschäftsbedarfs des Kunden.
Das ist ein Anforderungs-/Validierungsproblem, das ein statischer Analysator im Code nicht erkennt.
Ein Speicherleck, das erst nach Stunden Betrieb auftritt.
Es tritt zur Laufzeit über die Zeit auf und erfordert i. d. R. dynamisches Testen.
Die statische Analyse untersucht Code/Struktur ohne Ausführung und findet z. B. nicht definierte Variablen, nicht erreichbaren Code und Verstöße gegen Programmierrichtlinien.
Ein Feld akzeptiert ein ganzzahliges Alter von 18 bis 65 einschließlich. Welche Menge repräsentiert mit Äquivalenzklassenbildung am besten je einen Wert aus den drei Klassen (ungültig-niedrig, gültig, ungültig-hoch)?
10, 40, 80
Richtig — 10 ist ungültig-niedrig, 40 gültig, 80 ungültig-hoch: je ein Wert pro Klasse.
18, 40, 65
Alle drei liegen in der einzigen gültigen Klasse, zwei Klassen bleiben ungetestet.
17, 18, 19
Diese prüfen Grenzwerte (BVA), decken aber nur den unteren Rand ab, nicht alle drei Klassen.
40, 50, 60
Alle drei liegen in der gültigen Klasse; die ungültigen Klassen sind nicht vertreten.
Die Äquivalenzklassenbildung gruppiert gleich zu behandelnde Eingaben; ein Repräsentant je Klasse genügt. Gültig: 18–65; ungültig darunter: <18; ungültig darüber: >65.
Ein Eingabefeld akzeptiert ganze Zahlen von 1 bis 100 einschließlich. Welche Menge enthält bei der Zwei-Werte-Grenzwertanalyse genau die zu testenden Grenzwerte?
0, 1, 100, 101
Richtig — untere Grenze (1) und Außennachbar (0), obere Grenze (100) und Außennachbar (101).
1, 50, 100
50 ist ein Klassenmittelpunkt, keine Grenze; die Außennachbarn 0 und 101 fehlen.
0, 50, 101
Verfehlt die tatsächlichen Grenzen 1 und 100.
1, 2, 99, 100
Das sind die inneren Nachbarn der Drei-Werte-Methode; die Zwei-Werte-Methode nutzt 0 und 101.
Die Zwei-Werte-Grenzwertanalyse testet jeden Grenzwert und seinen nächsten Nachbarn knapp außerhalb des Bereichs. Für 1–100 sind das 0, 1, 100, 101.
Betrachten Sie die folgende Entscheidungstabelle für einen Checkout. Ein Kunde ist KEIN registrierter Kunde, gibt aber eine Bestellung mit einer Summe von 150 $ auf. Welche Aktion(en) gelten laut Tabelle?
Weder Gratisversand noch Rabatt (Regel 3).
Richtig — Regel 3 hat F (nicht registriert) und T (Bestellung >= 100) und zeigt für beide Aktionen '-'.
Gratisversand und 5 % Rabatt (Regel 1).
Regel 1 verlangt einen registrierten Kunden (T); dieser ist es nicht.
Nur 5 % Rabatt (Regel 2).
Regel 2 verlangt registriert = T und Bestellung < 100; beide Bedingungen weichen hier ab.
Nur Gratisversand.
Gratisversand gilt nur unter Regel 1, die einen registrierten Kunden voraussetzt.
Nicht registriert = F und Bestellung >= 100 = T entspricht Regel 3 (F, T), die weder 'Free shipping' noch '5% discount' auslöst.
Das System befindet sich gemäß dem folgenden Zustandsübergangsdiagramm im Zustand S1 (Awaiting PIN). Welche Ereignisfolge bringt das System in den Zustand S3 (Account locked)?
Drei aufeinanderfolgende falsche PIN-Eingaben.
Richtig — das Diagramm sperrt das Konto bei der 3. falschen PIN.
Eine falsche PIN-Eingabe.
Eine einzelne falsche PIN führt zurück zu S1; sie sperrt das Konto nicht.
Eine korrekte PIN-Eingabe.
Eine korrekte PIN führt zu S2 (Access granted), nicht zu S3.
Zwei falsche PIN-Eingaben gefolgt von einer korrekten PIN.
Nach zwei Fehlversuchen ist das System weiterhin bei S1; eine korrekte PIN führt dann zu S2.
Von S1 führt eine korrekte PIN zu S2; die ersten beiden falschen PINs führen zurück zu S1; die dritte aufeinanderfolgende falsche PIN löst den Übergang zu S3 (gesperrt) aus.
Wie viele Testfälle sind für den folgenden Kontrollflussgraphen nötig, um vollständige Zweigüberdeckung (Entscheidungsüberdeckung) zu erreichen, wenn jede Entscheidung mindestens einmal in beide Richtungen ausgeführt wird?
2
Richtig — zwei Pfade können beide Ausgänge der Verzweigung an Knoten 2 und beide der Schleifenentscheidung an Knoten 5 abdecken.
1
Ein einzelner Pfad kann nicht beide Seiten der Verzweigung und der Schleifenentscheidung nehmen.
4
Zweigüberdeckung erfordert nicht jede Kombination der Entscheidungsausgänge; 4 ist mehr als nötig.
6
Das ist zu viel; die Zweigüberdeckung ist hier mit weit weniger als sechs Tests erreichbar.
Es gibt zwei Entscheidungen: die Verzweigung an Knoten 2 (zu 3 oder 4) und die Schleifenentscheidung an Knoten 5 (zurück zu 2 oder weiter zu 6). Zwei gut gewählte Pfade decken beide Ausgänge jeder Entscheidung ab.
Was erfordert das Erreichen der „0-Switch-Überdeckung“ (auch Chows 0-Switch) beim Zustandsübergangstest?
Jeder gültige einzelne Übergang wird mindestens einmal ausgeführt.
Richtig — die 0-Switch-Überdeckung deckt alle einzelnen gültigen Übergänge ab.
Jedes gültige Paar aufeinanderfolgender Übergänge wird ausgeführt.
Das definiert die 1-Switch-Überdeckung, nicht 0-Switch.
Jeder ungültige Übergang wird versucht.
Das Testen ungültiger Übergänge ist ein separates Anliegen, nicht das Maß der 0-Switch-Überdeckung.
Jeder Zustand wird mindestens einmal besucht, unabhängig von Übergängen.
Zustände zu besuchen genügt nicht; 0-Switch betrifft die Abdeckung der Übergänge selbst.
Die 0-Switch-Überdeckung erfordert, jeden gültigen einzelnen Übergang einmal auszuführen; die 1-Switch-Überdeckung jedes gültige Paar aufeinanderfolgender Übergänge.
Welche Situation ist der stärkste Kandidat für den Entscheidungstabellentest?
Die Ausgabe hängt von mehreren Bedingungen ab, die unterschiedlich kombiniert werden können.
Richtig — Entscheidungstabellen erfassen systematisch Bedingungskombinationen und die resultierenden Aktionen.
Eine einzelne numerische Eingabe ist an den Rändern ihres gültigen Bereichs zu prüfen.
Das ist die Grenzwertanalyse, keine Entscheidungstabelle.
Das System wechselt je nach Ereignissen über die Zeit zwischen Modi.
Das deutet auf den Zustandsübergangstest hin.
Es gibt keine Anforderungen, nur einen laufenden Build zum Erkunden.
Das deutet auf exploratives Testen, eine erfahrungsbasierte Technik.
Entscheidungstabellen eignen sich, wenn das Verhalten von Kombinationen von Bedingungen abhängt, damit wichtige Kombinationen nicht übersehen werden.
Der Anwendungsfalltest leitet Testfälle primär woraus ab?
Aus dem Basisablauf und den Alternativ-/Ausnahmeabläufen der Nutzer-System-Interaktionen.
Richtig — Anwendungsfälle beschreiben diese Abläufe, die zur Grundlage der Testfälle werden.
Aus dem internen Kontrollflussgraphen des Codes.
Das ist White-Box- (strukturbasiertes) Testen, kein Anwendungsfalltest.
Aus den Grenzen jedes numerischen Eingabefelds.
Das beschreibt die Grenzwertanalyse.
Aus der Intuition des Testers über wahrscheinliche Fehlerzustände.
Das ist die intuitive Testfallermittlung (Error Guessing), eine erfahrungsbasierte Technik.
Der Anwendungsfalltest leitet Tests aus den Interaktionen zwischen Akteuren und System ab und deckt den Standardablauf (Basisablauf) sowie Alternativ-/Ausnahmeabläufe ab.
Welche Aussage beschreibt die Beziehung zwischen Äquivalenzklassenbildung und Grenzwertanalyse korrekt?
Die Grenzwertanalyse baut auf der Äquivalenzklassenbildung auf, indem sie die Ränder der Klassen testet.
Richtig — die GWA verfeinert die ÄKB, indem sie die Grenzen zwischen Klassen anvisiert.
Sie sind völlig unabhängige Techniken.
Sie sind eng verwandt; die GWA erweitert die ÄKB.
Die Äquivalenzklassenbildung ist White-Box und die GWA Black-Box.
Beide sind Black-Box- (spezifikationsbasierte) Techniken.
Die Grenzwertanalyse macht die Äquivalenzklassenbildung überflüssig.
Die GWA ergänzt die ÄKB; beide werden meist gemeinsam genutzt.
Die Grenzwertanalyse ist eine Erweiterung der Äquivalenzklassenbildung, die sich auf die Ränder (Grenzen) der Klassen konzentriert, wo Fehlerzustände häufig auftreten.
Ein Webformular akzeptiert das Alter eines Nutzers als Ganzzahl. Der gültige Bereich ist 18 bis 65 einschließlich; Werte außerhalb müssen abgelehnt werden. Welche Menge an Alterswerten wählt man mit der Zwei-Wert-Grenzwertanalyse (je Grenze der Grenzwert und der unmittelbar außerhalb liegende Nachbarwert), um beide Grenzen zu prüfen?
17, 18, 65 und 66
Prüft jede Grenze (18, 65) und ihren äußeren Nachbarwert (17, 66) – genau wie es die Zwei-Wert-BVA verlangt.
18 und 65
Nur die Grenzwerte; die äußeren Nachbarwerte der Zwei-Wert-BVA fehlen.
17, 18, 19, 64, 65 und 66
Das ist die Drei-Wert-BVA, die zusätzlich den inneren Nachbarwert (19, 64) prüft.
0, 18, 65 und 100
0 und 100 sind willkürliche Werte, nicht die von der BVA geforderten Nachbarwerte.
Die Zwei-Wert-BVA prüft je Grenze den Grenzwert und den unmittelbar außerhalb liegenden Wert: untere Grenze 18 → 17 und 18; obere Grenze 65 → 65 und 66.
Wie viele Testfälle sind für dieselbe Routine (ein einzelnes IF ohne ELSE, gefolgt von einer Schlussanweisung) mindestens nötig, um 100% Zweig-/Entscheidungsüberdeckung zu erreichen?
2
Ein Test nimmt den wahren Zweig, der andere das falsche Ergebnis.
1
Ein Test deckt nur eines der beiden Entscheidungsergebnisse ab.
3
Zwei Fälle genügen für eine einzelne binäre Entscheidung.
4
Überschätzt; es gibt nur zwei Ergebnisse.
Ein Test für IF-wahr und einer für IF-falsch = 2.
Welches ist das beste Beispiel für ein Endekriterium (Definition of Done) einer Teststufe?
Alle geplanten Tests wurden ausgeführt und es bleiben keine schwerwiegenden Fehlerzustände offen.
Richtig — das definiert die Bedingungen, unter denen das Testen als abgeschlossen gelten kann.
Die Testumgebung ist verfügbar und die Testdaten sind vorbereitet.
Das ist ein Eingangskriterium (Vorbedingung zum Start), kein Endekriterium.
Die Anforderungen wurden als Baseline festgeschrieben.
Ebenfalls ein Eingangskriterium / Vorbedingung, kein Endekriterium.
Die Tester wurden dem Projekt zugewiesen.
Das ist eine Ressourcen-/Planungsfrage, kein Abschlusskriterium.
Endekriterien legen fest, wann das Testen als hinreichend abgeschlossen gilt, z. B. geplante Überdeckung erreicht und keine offenen schwerwiegenden Fehlerzustände.
Was ist der Hauptzweck der Testüberwachung und -steuerung?
Informationen über den Testfortschritt sammeln und bei Bedarf Korrekturmaßnahmen ergreifen.
Richtig — die Überwachung misst den Fortschritt, die Steuerung lenkt ihn auf die Ziele zu.
Die detaillierten Testfälle entwerfen.
Der Testentwurf ist eine eigene Testaktivität, nicht Überwachung und Steuerung.
Die beim Testen gefundenen Fehlerzustände beheben.
Das Beheben ist Debugging/Entwicklung.
Die Testumgebung einrichten.
Das Einrichten der Umgebung gehört zur Testrealisierung, nicht zur Überwachung und Steuerung.
Die Testüberwachung sammelt Informationen über den Testfortschritt; die Teststeuerung nutzt diese, um Korrekturmaßnahmen zum Erreichen der Testziele zu ergreifen.
Beim risikobasierten Testen wird das Risikoniveau eines Elements üblicherweise anhand welcher zwei Faktoren bewertet?
Die Eintrittswahrscheinlichkeit des Problems und sein Schadensausmaß, falls es eintritt.
Richtig — Risikoniveau = Eintrittswahrscheinlichkeit x Schadensausmaß.
Die Anzahl der Testfälle und die Anzahl der Tester.
Das sind Aufwands-/Ressourcengrößen, nicht die Definition von Risiko.
Die Codegröße und die verwendete Programmiersprache.
Sie können den Aufwand beeinflussen, definieren aber nicht das Risikoniveau.
Die Kosten der Werkzeuge und der Testumgebung.
Kosten sind Budgetfragen, nicht die zwei Risikofaktoren.
Das Risikoniveau ist eine Kombination aus der Eintrittswahrscheinlichkeit eines Problems und dem Schadensausmaß, falls es eintritt.
Welches der folgenden ist ein Beispiel für ein Projektrisiko (im Gegensatz zu einem Produktrisiko)?
Schlüsseltester verlassen das Team, bevor die Testphase abgeschlossen ist.
Richtig — ein Personal-/Managementproblem ist ein Projektrisiko.
Die Zahlungsberechnung liefert falsche Beträge.
Ein Fehlerzustand im Produktverhalten ist ein Produktrisiko.
Das System ist unter Spitzenlast zu langsam.
Ein Qualitätsmerkmal des Produkts (Performanz) ist ein Produktrisiko.
Die Benutzeroberfläche ist schwer zu bedienen.
Ein Benutzbarkeitsproblem des Produkts ist ein Produktrisiko.
Projektrisiken betreffen das Management und die Durchführung des Projekts (z. B. Personal, Zeitplan, Lieferant). Produktrisiken betreffen die Qualität des Produkts selbst.
Welche Information ist in einem guten Fehlerbericht wesentlich, um Entwicklern die Reproduktion des Problems zu ermöglichen?
Klare Reproduktionsschritte mit Soll- und Ist-Ergebnis.
Richtig — Reproduktionsschritte plus Soll-/Ist-Ergebnis sind zentral für die Diagnose des Fehlerzustands.
Die Meinung des Testers über den Entwickler, der den Code geschrieben hat.
Fehlerberichte sollten sachlich und objektiv sein, nicht persönlich.
Eine Garantie, dass der Fehlerzustand vor der Freigabe behoben wird.
Ein Bericht kann keine Behebung garantieren; das ist eine Triage-/Managemententscheidung.
Die Gesamtzahl der Testfälle im Projekt.
Projektweite Zahlen helfen nicht, einen bestimmten Fehlerzustand zu reproduzieren.
Ein nützlicher Fehlerbericht enthält Reproduktionsschritte, Soll-/Ist-Ergebnisse, Umgebung sowie Schweregrad/Priorität, damit das Problem reproduziert und triagiert werden kann.
Ein Team bittet mehrere erfahrene Tester, den Testaufwand unabhängig zu schätzen, und einigt sich dann über mehrere Runden auf eine Konsensschätzung. Welcher Schätzansatz ist das?
Ein expertenbasierter Ansatz (z. B. Wideband Delphi).
Richtig — durch Diskussion zusammengeführte Expertenschätzungen sind expertenbasiert.
Ein metrikbasierter Ansatz mit historischen Daten.
Metrikbasierte Schätzung nutzt vergangene Projektdaten, keine Expertenkonsensrunden.
Grenzwertanalyse.
Die GWA ist eine Testentwurfstechnik, kein Schätzansatz.
Risikobasierte Priorisierung.
Nach Risiko zu priorisieren ist keine Technik zur Aufwandsschätzung.
Das ist ein expertenbasierter Schätzansatz; die iterative Form (erst anonym, dann diskutieren) ist als Wideband Delphi bekannt.
Welche der folgenden ist eine typische Metrik in einem Testfortschrittsbericht (Statusbericht)?
Anzahl der ausgeführten, bestandenen, fehlgeschlagenen und blockierten Testfälle.
Richtig — der Ausführungsstatus ist eine Standardmetrik des Testfortschritts.
Die persönlichen Gehälter des Entwicklungsteams.
Gehälter sind keine Testfortschrittsmetrik.
Die Marke der Laptops, die die Tester verwenden.
Für die Testfortschrittsberichterstattung irrelevant.
Das Marketingbudget für die Produkteinführung.
Eine Geschäfts-/Marketinggröße, keine Testmetrik.
Testfortschrittsberichte enthalten häufig den Ausführungsstatus der Testfälle (bestanden/fehlgeschlagen/blockiert), Fehlerzahlen und -trends sowie die erreichte Überdeckung.
Bei der Testschätzung nutzt ein Team die Drei-Punkt-Methode (PERT). Für eine Testaktivität schätzt es optimistisch = 4 Tage, wahrscheinlich = 9 Tage und pessimistisch = 20 Tage. Wie hoch ist der Schätzwert nach E = (O + 4M + P) / 6?
10 Tage
(4 + 36 + 20) / 6 = 60 / 6 = 10.
9 Tage
9 ist der wahrscheinliche Wert, nicht der gewichtete PERT-Schätzwert.
11 Tage
11 ist der einfache Mittelwert (4+9+20)/3, nicht der gewichtete PERT-Wert.
12 Tage
Passt nicht zur Formel; der korrekte gewichtete Schätzwert ist 10.
E = (4 + 4×9 + 20) / 6 = (4 + 36 + 20) / 6 = 60 / 6 = 10 Tage.
Vier Produktrisiken sind 1-5 bewertet: R1 L=2 I=3; R2 L=4 I=5; R3 L=3 I=3; R4 L=5 I=2. Wenn Risikostufe = Wahrscheinlichkeit x Auswirkung, welches sollte ZUERST getestet werden?
R2 (Risikostufe 20)
4*5 = 20 ist der höchste der vier.
R4 (Risikostufe 10)
5*2 = 10 ist niedriger als die 20 von R2.
R3 (Risikostufe 9)
3*3 = 9 ist niedriger als die 20 von R2.
R1 (Risikostufe 6)
2*3 = 6 ist der niedrigste.
R2 hat das höchste Produkt (20).
Ein Werkzeug, das Fehlerzustände erfasst, mit Anforderungen verknüpft und ihren Status über den Lebenszyklus verfolgt, gehört zu welcher Kategorie?
Testmanagement-/Fehlerverwaltungswerkzeuge.
Richtig — das Verfolgen von Fehlerzuständen und die Nachverfolgbarkeit sind Funktionen eines Testmanagement-Werkzeugs.
Performanztest-Werkzeuge.
Performanzwerkzeuge erzeugen Last und messen die Antwort, sie verfolgen keine Fehlerzustände.
Werkzeuge zur statischen Analyse.
Die statische Analyse untersucht Code ohne Ausführung; sie verwaltet keine Fehlerzustände.
Werkzeuge zur Testdatenaufbereitung.
Diese erzeugen oder maskieren Testdaten, sie verfolgen keine Fehlerzustände.
Testmanagement-Werkzeuge (einschließlich Fehler-/Incident-Management) unterstützen das Management des Testens, die Nachverfolgbarkeit und die Berichterstattung.
Welches der folgenden ist ein realistisches Risiko der Einführung von Testautomatisierung und kein Vorteil?
Der Aufwand zur Pflege der automatisierten Tests kann unterschätzt werden.
Richtig — die Wartung automatisierter Skripte ist ein häufig unterschätzter Kosten-/Risikofaktor.
Automatisierte Regressionstests können häufiger und konsistenter laufen.
Das ist ein Vorteil der Automatisierung, kein Risiko.
Wiederholende Tests können schneller als von Hand ausgeführt werden.
Das ist ein Vorteil, kein Risiko.
Für dieselben Eingaben werden objektive, wiederholbare Ergebnisse erzeugt.
Wiederholbarkeit ist ein Vorteil der Automatisierung, kein Risiko.
Automatisierung hat Kosten und Risiken: Der Wartungsaufwand kann unterschätzt werden, es kann zu Überabhängigkeit vom Werkzeug und zu unrealistischen Erwartungen kommen. Vorteile sind u. a. Wiederholbarkeit und schnellere Regressionsläufe.