ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 1810
Скачиваний: 4
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 66/84
1.8.2011
© International Software Testing Qualifications Board
Vergleichswerkzeuge/Komparatoren
Vergleichswerkzeuge ermitteln die Unterschiede zwischen Dateien, Datenbanken oder Testergebnis-
sen. Testausführungswerkzeuge enthalten typischerweise dynamische Vergleichswerkzeuge. Es be-
steht auch die Möglichkeit, dass ein Vergleich durch ein separates Werkzeug erst nach der Testdurch-
führung ausgeführt wird. Ein Vergleichswerkzeug kann auch ein Testorakel verwenden, insbesondere
wenn der Vergleich automatisiert erfolgt.
Werkzeuge zur Überdeckungsmessung (E)
Diese Werkzeuge messen – mit intrusiven oder nicht-intrusiven Mitteln – den prozentualen Anteil spe-
zifischer Codestrukturtypen (z.B. Anweisungen, Zweige oder Entscheidungen und Module oder Funk-
tionsaufrufe), die durch eine Menge von Tests ausgeführt bzw. durchlaufen wurden.
Sicherheitsprüfwerkzeuge
Diese Werkzeuge dienen der Bewertung der Sicherheitsmerkmale von Software. Dabei wird bewertet,
wie die Software in der Lage ist, die Vertraulichkeit der Daten, deren Integrität, Bestätigung der Echt-
heit, Autorisierung, Verfügbarkeit und Nichtabstreitbarkeit zu schützen. Sicherheitsprüfwerkzeuge sind
meist für eine bestimmte Technologie, Plattform und Zielsetzung ausgelegt.
6.1.7 Werkzeugunterstützung für Performanzmessungen und Testmonitore (K1)
Dynamische Analysewerkzeuge (E)
Dynamische Analysewerkzeuge decken Fehlerzustände auf, wie sie lediglich zur Laufzeit eines Pro-
gramms sichtbar werden, also z.B. Zeitabhängigkeiten und Speicherengpässe. Diese werden typi-
scherweise im Komponenten- und Komponentenintegrationstest sowie im Rahmen der Tests der
Middleware verwendet.
Performanztest-/Lasttest-/Stresstestwerkzeuge
Performanztestwerkzeuge überwachen und protokollieren, wie sich ein System unter verschiedenen
simulierten Benutzungsbedingungen verhält, hinsichtlich Anzahl konkurrierender Nutzer, Hochlauf-
/Anlaufverhalten (ramp-up pattern) sowie Häufigkeit und relativem Anteil von Transaktionen. Die Last
wird durch Erzeugen virtueller Nutzer simuliert, die einen ausgewählten Satz an Transaktionen durch-
führen, verteilt auf verschiedene Testmaschinen, allgemein bekannt als Lastgeneratoren.
Testmonitore
Testmonitore analysieren, verifizieren und zeichnen kontinuierlich die Verwendung von spezifischen
Systemressourcen auf und geben Warnungen zu. möglichen Problemen bei der Erbringung von
Diensten aus.
6.1.8 Werkzeugunterstützung für spezifische Anwendungsbereiche (K1)
Bewertung der Datenqualität
Bei manchen Projekten stehen die Daten im Mittelpunkt, beispielsweise bei Datenkonvertierungs-
bzw. Datenmigrationsprojekten und bei Anwendungen wie Data Warehouses. Die Attribute der Daten
können sowohl hinsichtlich ihrer Kritikalität und ihres Volumens variieren. In einem solchen Kontext
sind Werkzeuge für die Bewertung der Datenqualität erforderlich, um die Datenkonvertierungs- und
die Migrationsvorschriften zu prüfen und zu verifizieren. Damit soll sichergestellt werden, dass die
verarbeiteten Daten korrekt und vollständig sind, und dass sie einem vorab definierten kontextspezifi-
schen Standard entsprechen.
Auch für den Benutzbarkeitstest gibt es Testwerkzeuge.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 67/84
1.8.2011
© International Software Testing Qualifications Board
6.2 Effektive Anwendung von Werkzeugen:
Potenzieller Nutzen und Risiken (K2)
20 Minuten
Begriffe
datengetriebener Test, schlüsselwortgetriebener Test, Skriptsprache
6.2.1 Potenzieller Nutzen und Risiken einer Werkzeugunterstützung für das Testen
(für alle Werkzeuge) (K2)
Einfach ein Werkzeug zu kaufen oder zu mieten, garantiert noch keinen Erfolg mit dem Werkzeug.
Jede Art von Werkzeug kann zusätzlichen Aufwand erfordern, um einen tatsächlichen und nachhalti-
gen Nutzen zu erreichen. Werkzeuge können Chancen und erheblichen potenziellen Nutzen bei der
Unterstützung des Testens bieten. Allerdings birgt der Einsatz auch Risiken, die berücksichtigt werden
müssen.
Potenzieller Nutzen der Verwendung von Testwerkzeugen:
•
weniger sich wiederholende Tätigkeiten (z.B. für Regressionstestläufe, wiederholte Eingaben
der gleichen Testdaten und Prüfungen gegen Programmierkonventionen)
•
bessere Konsistenz und Wiederholbarkeit (die gleichen Tests werden beispielsweise in der
gleichen Reihenfolge mit der gleichen Häufigkeit durch ein Werkzeug ausgeführt und aus An-
forderungen hergeleitet)
•
objektive Bewertung durch eine Werkzeugunterstützung (z.B. statische Messungen, Überde-
ckungsmessungen)
•
vereinfachter Zugriff auf Informationen über durchgeführte Tests (z.B. Statistiken und graphi-
sche Darstellungen über den Testfortschritt, die Fehlerrate und die Performanz)
Risiken der Verwendung von Testwerkzeugen:
•
unrealistische Erwartungen an das Werkzeug (einschließlich Funktionalität und Benutzungs-
freundlichkeit)
•
unterschätzen der Zeit, der Kosten und des Aufwands für die erstmalige Einführung eines
Werkzeugs (einschließlich Training und externe Beratung)
•
unterschätzen der Zeit und des Aufwands, um einen signifikanten und anhaltenden Nutzen
aus der Anwendung eines Werkzeugs ziehen zu können (einschließlich der Notwendigkeit von
Änderungen im Testprozess und der kontinuierlichen Verbesserung in der Art und Weise, wie
das Werkzeug verwendet wird)
•
unterschätzen des erforderlichen Aufwands für die Wartung der durch das Werkzeug erzeug-
ten Ergebnisse
•
blindes Vertrauen in das Werkzeug (Ersatz für einen Testentwurf oder Verwenden automati-
sierter Tests, wo manuelles Testen geeigneter wäre)
•
vernachlässigen der Versionskontrolle von Testgegenständen im Testwerkzeug
•
vernachlässigen der Beziehungen und der Interoperabilitätsproblematik zwischen kritischen
Werkzeugen, wie Anforderungsmanagementwerkzeugen, Versionskontrollwerkzeugen, Feh-
ler- und Abweichungsmanagementwerkzeugen, Fehlerverfolgungswerkzeugen und Werkzeu-
gen unterschiedlicher Hersteller
•
Risiko, dass der Werkzeughersteller den Betrieb einstellt, das Werkzeug vom Markt nimmt,
oder das Werkzeug an einen anderen Hersteller verkauft
•
mangelhafte Leistungen des Herstellers hinsichtlich Kundenunterstützung, Upgrades und Feh-
lerbehebungen
•
Risiko, dass das Projekt zum Erstellen des kostenfreien bzw. Open-Source-Werkzeugs einge-
stellt wird
•
unvorhergesehene Probleme, z.B. dass eine neue Plattform nicht unterstützt werden kann
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 68/84
1.8.2011
© International Software Testing Qualifications Board
6.2.2 Spezielle Betrachtungen zu einigen Werkzeugarten (K1)
Testausführungswerkzeuge
Testausführungswerkzeuge führen Testobjekte aus, indem sie automatisierte Testskripte nutzen.
Testwerkzeuge dieser Art erfordern oft einen erheblichen Aufwand, um einen signifikanten Nutzen zu
erzielen.
Es mag attraktiv scheinen, die Aktionen eines manuellen Testers aufzuzeichnen, aber diese Vorge-
hensweise ist nicht auf eine größere Anzahl von automatisierten Testskripten skalierbar. Ein aufge-
zeichnetes Skript ist eine lineare Repräsentation von spezifischen in das Skript integrierten Daten.
Wenn während der Testdurchführung unerwartete Ereignisse auftreten, können Skripte dieser Art
instabil werden.
Eine datengetriebene Testvorgehensweise (data-driven approach) trennt die Eingaben (die Testdaten)
vom Testfall und legt sie in einem Tabellenblatt ab. Ein generisches Testskript liest die Eingabewerte
bei Testausführung aus dem Tabellenblatt. Damit kann das gleiche Testskript mit unterschiedlichen
Daten durchgeführt werden. Tester, die sich nicht mit der Skriptsprache auskennen, können dennoch
Testdaten für die vordefinierten Testskripte erstellen.
Es gibt weitere Verfahren, die bei den datengetriebenen Verfahren eingesetzt werden. Bei diesen
Verfahren werden, anstatt Datenkombinationen hart codiert in einem Tabellenblatt einzugeben, Daten
in Echtzeit generiert und der Applikation zur Verfügung gestellt. Das geschieht mit Hilfe von Algorith-
men, die auf konfigurierbaren Parametern basieren. Beispielsweise kann ein Werkzeug einen Algo-
rithmus verwenden, der eine zufällige Benutzer-ID erstellt, und damit das Muster wiederholbar wird,
ein sogenanntes „Seed“ einsetzt, das die Zufälligkeit steuert.
In einem schlüsselwortgetriebenen Testansatz (keyword-driven approach) enthält ein Tabellenblatt
zusätzlich zu den Testdaten Schlüsselwörter (auch Aktionswörter genannt), welche die auszuführen-
den Aktionen beschreiben. Auch wenn Tester sich nicht mit einer Skriptsprache auskennen, können
sie so Tests unter Verwendung von Schlüsselwörtern definieren, die sich auf die zu testende Applika-
tion hin anpassen lassen.
Technische Kenntnisse in den Skriptsprachen werden in allen Ansätzen benötigt (entweder von einem
Mitarbeiter in der Rolle des Testers oder durch einen Testautomatisierungsspezialisten).
Unabhängig vom verwendeten skriptbasierten Verfahren müssen die erwarteten Ergebnisse für jeden
Test für einen späteren Vergleich bereits abgelegt sein.
Statische Analysewerkzeuge
Statische Analysewerkzeuge dienen der Analyse des Quellcodes und können die Einhaltung von Pro-
grammierkonventionen erzwingen. Jedoch ist zu berücksichtigen, dass bei Anwendung eines stati-
schen Analysators für existierenden Quellcode eine riesige Menge Meldungen erzeugt werden kön-
nen. Wird ein Compiler mit integriertem statischen Analysator oder mit entsprechenden Compiler-
Optionen verwendet, so wird die Übersetzung in Objektcode durch die erzeugten Warnmeldungen
nicht unterbrochen, jedoch sollten diese Warnmeldungen analysiert werden, um die Wartbarkeit des
Quellcodes zu verbessern. Eine Basisimplementierung eines statischen Analysators sollte deshalb die
Möglichkeit enthalten, einige dieser Analysen bzw. die entsprechenden Regeln zu deaktivieren.
Testmanagementwerkzeuge
Testmanagementwerkzeuge sollten Schnittstellen zu anderen Werkzeugen oder zu einem Standard-
tabellenkalkulationsprogramm (z.B. Excel) enthalten, um nützliche Informationen nach den Bedürfnis-
sen der Organisation aufzubereiten.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 69/84
1.8.2011
© International Software Testing Qualifications Board
6.3 Einführung von Testwerkzeugen in
eine
Organisation (K1)
15 Minuten
Begriffe
keine spezifischen Begriffe
Hintergrund
Die wichtigsten Gesichtspunkte bei der Auswahl eines Werkzeugs für eine Organisation sind:
•
Bewerten der Reife einer Organisation, Analyse der Stärken und Schwächen, Identifikation
von Möglichkeiten für die Verbesserung des Testprozesses, unterstützt durch Testwerkzeuge
•
Evaluation gegen klar spezifizierte Anforderungen und objektive Kriterien (für Nutzen und An-
wendung)
•
Eignungsnachweis (proof-of-concept) durch Nutzen des Werkzeugs während der Evaluie-
rungsphase, um zu verifizieren, ob es mit der zu testenden Software und in der aktuellen Inf-
rastruktur effektiv funktioniert, bzw. um nötige Anpassungen der Infrastruktur zu identifizieren
damit eine effektive Nutzung des Werkzeugs möglich ist
•
Evaluation der Anbieter (einschließlich Trainingsunterstützung, Support und kommerzielle
bzw. vertragliche Aspekte) oder des Dienstleistungsanbieters bei nicht kommerziellen Werk-
zeugen
•
Identifikation der internen Anforderungen für Coaching und Anleitung bei der Anwendung des
Werkzeugs
•
Evaluation des Schulungsbedarfs, die die Testautomatisierungskenntnisse des aktuellen Test-
teams berücksichtigt
•
Schätzen des Kosten/Nutzen-Verhältnisses, basierend auf einem konkreten Business Case
Die Einführung des ausgewählten Werkzeugs in einer Organisation beginnt mit einem Pilotprojekt,
welches folgende Ziele verfolgt:
•
Detailliertes Kennenlernen des Werkzeugs
•
Bewertung, wie das Werkzeug mit den existierenden Werkzeugen und Prozessen zusam-
menpasst, festlegen, was ggf. angepasst werden muss
•
Entscheidung über die Standardisierung des Werkzeugeinsatzes hinsichtlich Nutzung, Ver-
waltung, Speicherung und Wartung des Werkzeugs und der vom Werkzeug erzeug-
ten/verwendeten Ergebnisse (z.B. Namenskonventionen für Dateien und Tests, Neuanlage
von Bibliotheken und die Festlegung von modularen Testsuiten)
•
Bewerten, ob der Nutzen mit vertretbaren Kosten erreicht werden kann
Erfolgsfaktoren der Inbetriebnahme innerhalb einer Organisation sind:
•
Das Werkzeug wird schrittweise in der ganzen Organisation in Betrieb genommen.
•
Adaptierung und Prozessverbesserung harmonieren mit dem Werkzeug.
•
Für neue Anwender werden Trainingsmaßnahmen und Coaching bereitgestellt.
•
Es sind Richtlinien für die Werkzeugbenutzung definiert.
•
Es gibt Verfahren, um Nutzungsdaten über den derzeitigen Gebrauch zu sammeln.
•
Werkzeugverwendung und tatsächlicher Nutzen werden beobachtet.
•
Das Testteam erhält Unterstützung für das Werkzeug.
•
Es wird ein Erfahrungskatalog erstellt, basierend auf den Erfahrungen aller Teams.
Referenzen
6 Linz, 2010
6.2.2 Buwalda, 2001, Fewster, 1999
6.3 Fewster, 1999
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 70/84
1.8.2011
© International Software Testing Qualifications Board
7 Referenzen
7.1
Standards
ISTQB
®
Standard Glossary of Terms used in Software Testing, Version 2.1
ISTQB®/GTB Standard Glossar der Testbegriffe – Englisch - Deutsch und Deutsch - Englisch
Version 2.1
[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process Integration
and Product Improvement, Addison Wesley: Reading, MA
siehe Kapitel 2.1
[IEEE Std 829-1998] IEEE Std 829™ (1998) IEEE Standard for Software Test Documentation
siehe Kapitel 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6
[IEEE 1028] IEEE Std 1028™ (2008) IEEE Standard for Software Reviews and Audits
siehe Kapitel 3.2
[IEEE 12207] IEEE 12207/ISO/IEC 12207-2008, Software Life Cycle Processes
siehe Kapitel 2.1
[ISO 9126] ISO/IEC 9126-1:2001, Software engineering – Product quality
siehe Kapitel 2.3
7.2
Bücher
[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (2nd edition), Van Nostrand Reinhold:
Boston
siehe Kapitel 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6
[Black, 2001] Black, R. (2001) Managing the Testing Process (3rd edition), John Wiley & Sons Inc.:
New York
siehe Kapitel 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6
[Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation, Addison Wesley:
Reading, MA
siehe Kapitel 6.2
[Copeland, 2004] Copeland, L. (2004) A Practitioner’s Guide to Software Test Design, Artech House:
Norwood, MA
siehe Kapitel 2.2, 2.3, 4.2, 4.3, 4.4, 4.6
[Craig, 2002] Craig, Rick D. und Jaskiel, Stefan P. (2002) Systematic Software Testing, Artech House:
Norwood, MA
siehe Kapitel 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4
[Fewster, 1999] Fewster, M. und Graham, D. (1999) Software Test Automation, Addison Wesley:
Reading, MA
siehe Kapitel 6.2, 6.3
[Gilb, 1993]: Gilb, Tom und Graham, Dorothy (1993) Software Inspection, Addison Wesley: Reading,
MA
siehe Kapitel 3.2.2, 3.2.4