WikiDer > Testen (Software)

Testen (software)

Es zu testen von Software bestimmt, inwieweit die Software die Anforderungen erfüllt. Es ist wichtig zu wissen, was getestet wird (die Testobjekt), die Forderungen, (die Testbasis), wann und wie getestet wird (Methode).

Definitionen

'Testen' kann definiert werden als:

  • Eine Sammlung von Aktivitäten, die durchgeführt werden, um ein oder mehrere Merkmale eines Produkts, Prozesses oder einer Dienstleistung nach einem festgelegten Verfahren festzulegen [ISO/IEC, 1991]
  • Ein Prozess, der Einblicke in die Qualität der Software und die damit verbundenen Risiken bietet und dazu berät
  • Der methodische Prozess zum Aufzeigen von Diskrepanzen zwischen dem tatsächlichen Betrieb und dem erwarteten Betrieb eines Systems oder Produkts.
  • Die Tätigkeit, in der die Qualität des gesamten Systems oder Produkts überprüft wird.
  • Der Prozess, mit dem die korrekte Funktionsweise eines Systems oder Produkts nachgewiesen wird.
  • Tätigkeiten wie Messen, Forschen, Testen, Bewerten mit Kaliber eines oder mehrerer Merkmale eines Produkts oder einer Dienstleistung und Vergleich der Ergebnisse mit den gestellten Anforderungen, um festzustellen, ob diese Bedingung erfüllt ist. (Definition gemäß der Norm ISO 8402.)

Tore

Software wird von Softwareentwicklern für eine bestimmte Anwendung entwickelt. Dies scheint an sich einfach, aber aufgrund der Komplexität von Software und der Umgebung, in der Software funktioniert, ist es praktisch unmöglich, fehlerfreie Software zu erstellen. Das macht das Testen von Software so wichtig.

Von dem Lieferant, Produzent, da der Zweck des Tests darin besteht, es zu liefern Beweis dass die Entwicklungs- und Programmierarbeiten ordnungsgemäß durchgeführt wurden, damit die Rechnung abgegeben und bezahlt werden können.

Von dem Klient, Kunde, Benutzer es gibt mehrere ziele.

  • Erstens wollen sie wissen, ob der Lieferant die Vereinbarungen eingehalten hat.
  • Außerdem wollen sie die Risiken bei der Nutzung der Software einschätzen können. Sie wollen wissen, ob die Benutzer bereit und in der Lage sind, mit dem System zu arbeiten.
  • Sie wollen auch Fehler finden, und zwar so schnell wie möglich, denn je später Fehler gefunden werden, desto teurer wird ihre Behebung.
  • Wir wollen auch Fehler vermeiden, zum Beispiel mit statische Prüfung.

Das Testen kostet Zeit und Geld, daher ist es notwendig, sich Gedanken darüber zu machen, was getestet wird und wie umfangreich dies geschieht. Der Umfang der Prüfung hängt daher von der Budget und die zu bewertenden Risiken. Im Idealfall findet kein Testen statt, weil das am billigsten ist, aber oft trauen sich die Leute nicht, weil sie gewisse Risiken nicht eingehen wollen. Tests geben Einblick in diese Risiken. Daher muss eine implizite oder explizite Risikobewertung vorgenommen werden. Testkosten zwischen 10 und 30 % des gesamten Projektbudgets. Optional kann man zum Beispiel Testpunktanalyse einen Kostenvoranschlag machen.

Software wird vor dem operativen Einsatz getestet, nicht um alle Fehler zu beseitigen, sondern um das Risiko von Problemen während der Nutzung auf einem akzeptablen Niveau zu halten. Wenn sie überhaupt lauffähig wäre, wäre die Erstellung einer fehlerfreien Software mit einem unverhältnismäßig hohen Test- und Kostenaufwand verbunden.

Die Einführung des Systems hat vielfältige Folgen für die Umwelt. Es ist wichtig, diese Folgen richtig einschätzen zu können. Es geht um die Konsequenzen auf Kommerziell, Organisatorisches, Mitarbeiter, Verwaltung, Finanziell und Technisch Bereich.

Qualitätsattribute

In der internationalen ISO 9126Software-Qualitätsstandard definiert die folgenden Qualitätsmerkmale:

  • Wirksamkeit Bei der Funktionalität geht es darum, ob die Software das tut, was sie soll. Und dies können sowohl beschriebene als auch stillschweigend selbstverständliche Bedürfnisse sein.
  • Verlässlichkeit bezieht sich auf die Fähigkeit des Produkts/Prozesses, das Leistungsniveau unter bestimmten Bedingungen, wie z. B. vielen Benutzern, für einen bestimmten Zeitraum aufrechtzuerhalten.
  • Benutzerfreundlichkeit bezieht sich auf den für die Nutzung erforderlichen Aufwand und auf die individuelle Beurteilung einer solchen Nutzung durch die Nutzer.
  • Flexibilität beinhaltet die Möglichkeit, die Software von einer Umgebung in eine andere zu konvertieren, sowie die Möglichkeit, sie zu modifizieren.
  • Wartbarkeit bezieht sich auf den Aufwand, der erforderlich ist, um Änderungen vorzunehmen.
  • Handhabbarkeit bezieht sich auf die Leichtigkeit, mit der das System in einen betriebsbereiten Zustand gebracht und gehalten werden kann.
  • Sicherheit, geht es um beides Privatsphäre wie über die Fähigkeit, Dinge wie Feuer, Diebstahl und mutwillige Störungen zu überleben.
  • Effizienz bezieht sich auf das Verhältnis zwischen dem Leistungsniveau des Produkts/Prozesses und der Menge der eingesetzten Ressourcen.

Standard- und Testbasis

Ein wichtiger Aspekt beim Testen ist die Bestimmung der Norm. Mit anderen Worten, die Frage: Was ist richtig? Bei Computerprogrammen kann dies in einem oder mehreren Dokumenten festgehalten werden, einschließlich einer technischen oder funktionelles Design, ein Interaktionsdesign oder Design des grafische Benutzeroberfläche. Diese Dokumente bilden zusammen die Testbasis, die Produktmenge, auf der die Erwartungen bzw. das Testdesign basieren Wir sprechen von „Erwartungen“, denn beim Softwaretest wird nicht geprüft, ob die Software richtig oder falsch funktioniert, sondern ob die Ergebnisse dem entsprechen, was in die Testgrundlage wird beschrieben bzw. was „erwartet“ wird.

Zwei Ströme

Im Großen und Ganzen sehen wir beim Testen zwei Trends, die je nach Anwendungsgebiet zum Einsatz kommen:

  1. Das positiv Ansatz, der zeigt, dass das System oder Produkt die wichtigsten Anwendungsanforderungen erfüllt.
  2. Das Negativ Ansatz, der darauf abzielt, nachzuweisen, dass das getestete Produkt oder System Fehler aufweist.

Beispiel: Der funktionale Abnahmetest zielt darauf ab, Fehler zu finden. Anhand der funktionalen Spezifikationen wird getestet, ob das System tut, was es soll, vor allem aber, ob das System nicht tut, was es nicht soll. Der Benutzerakzeptanztest konzentriert sich viel stärker darauf, zu überprüfen, ob der Benutzer mit dem System arbeiten kann und ob das System den Benutzer, für den das System gedacht ist, ausreichend erleichtert. Das ist natürlich diffus. Beim funktionalen Abnahmetest kommt man nicht umhin, zuerst zu prüfen, ob das System so funktioniert, wie es soll, und es werden trotzdem Fehler beim Benutzerabnahmetest auftreten.

Testmethode

Alles kann getestet werden oder es kann ein Stichprobe genommen werden. Letztendlich geht es beim Testen darum, die Risiken zu managen. Es ist sehr schwer, wirklich fehlerfrei zu arbeiten. Ein System muss auch nicht fehlerfrei sein, auch bei Fehlern kann das neue System besser sein als das ersetzte. Es ist auch durchaus möglich, Fehler nachträglich zu beheben. Das Testen kann strukturiert erfolgen, nach einer Methode oder a Versuchsplan. In dem Versuchsplan legt fest, was und wie umfangreich getestet wird. Das wird oft verwendet Testskripte. Es ist auch möglich und sehr beliebt, weniger strukturiert (ad hoc) zu testen, wie zum Beispiel „exploratives Testen“ oder „Fehler erraten“. Dies hat den Vorteil, dass es wenig Vorbereitung erfordert, der Nachteil ist, dass es möglicherweise nicht vollständig getestet wird. Außerdem sind gefundene Fehler möglicherweise nicht reproduzierbar, was es schwieriger macht, sie zu finden und zu beheben.

Bücher, Methoden und Techniken

Für den strukturierten Aufbau von Tests stehen verschiedene Methoden zur Verfügung. Diese Verfahren wiederum verwenden eine Vielzahl von Testtechniken. Mehr oder weniger bekannte Methoden sind:

  • ISTQB ehemals ISEB. Dies ist eine von vielen Ländern anerkannte Standardisierung. Alle EU-Länder, Kanada und Australien haben diesen Standard übernommen. Die Vereinigten Staaten haben ihre eigene Standardisierung, das IEEE.
  • TMAP ist ein Handbuch, das im Auftrag der damaligen Firma IP/Softwarecontrol (der aktuellenthe Sogeti Niederlande), basierend auf den Säulen Technologie, Infrastruktur und Organisation, mit Phasering als mittlerer Säule.
  • Qualitätssicherung durch Abnahmeprüfung von N.P.M. Mors ist eines der ersten Bücher über strukturiertes Testen im niederländischsprachigen Raum.
  • Als Inspirationsquelle für TMap und ISTQB wird oft genannt Barry Böhm. Darin wurde beschrieben, wie wichtig es ist, so früh wie möglich zu testen, basierend auf den Anforderungen und Wünschen der zu liefernden Software.

Testzeit

Software kann während der Verwaltung, bei kleineren Softwareänderungen oder während der Entwicklung, in einem Projekt, wenn es um größere Veränderungen geht.

Testen während des Managements

Nach Abschluss der projektbezogenen Systementwicklung kommt das System in die Verwaltung, wo auch kleinere Entwicklungen folgen können, die ebenfalls getestet werden müssen. Auch die in Projekten verwendeten Tests können hier durchgeführt werden. Die Änderung wird geprüft und es wird auch geprüft, ob die nicht geänderten Teile noch einwandfrei funktionieren. Dies kann mit einem sogenannten Regressionstest.

Testen in einem Projekt

Das Testen kann zu verschiedenen Zeitpunkten im Projekt durchgeführt werden. Aufgrund der unterschiedlichen Entwicklungsmethoden gibt es auch unterschiedliche Testmöglichkeiten.

  • Vor Beginn des Entwicklungsprozesses können statische Tests an der Dokumentation erfolgen. Dies kann durch verschiedene Überprüfungstechniken unter anderem zur technischen, funktionalen oder grafischen Gestaltung erfolgen.
  • Am Anfang, wenn sich noch nichts geändert hat, kann getestet werden, dies wird als sogenannte Nullmessung bezeichnet. Das ist der Bezugspunkt, mit dem die Testergebnisse anderer Tests verglichen werden können.
  • Während der Entwicklung kann ein statischer Test des Codes erfolgen oder mittels eines Komponenten- oder Unit-Tests überprüft werden, ob einzelne Teile wie erwartet funktionieren.

Die meiste Software wird entwickelt, beginnend mit den Wünschen und Anforderungen der Endbenutzer, über die funktionalen und technischen Beschreibungen bis hin zum endgültigen Code. Das ist es Wasserfall-Modell. Zu jeder Phase gehören unterschiedliche Endprodukte, die als Testgrundlage dienen.

  • Unit-Tests werden von den Programmierern/Entwicklern durchgeführt und basieren auf detaillierten Beschreibungen der Software (für das Wasserfallmodell) oder auf nicht näher spezifizierten Benutzeranforderungen für a RAD Entwicklungsprozess.
  • Das Integrationstest basiert auf den Dokumenten, die die Systemarchitektur beschreiben.
  • Bei der Systemtest Schauen Sie sich die Systemspezifikationen an.
  • Und bei der Benutzerakzeptanztest basiert auf Benutzeranforderungen.

Diese Phasen und ihr Zusammenhang werden in der in . beschrieben V-Modell.

Statisch oder dynamisch

Das Testen kann auch in statische und dynamische Tests unterteilt werden.

Statische Prüfung

Statische Prüfung wird durchgeführt, ohne das System tatsächlich auszuführen und oft, wenn das System noch nicht (vollständig) verfügbar ist. Das nennt man auch Tests erwähnt. Daher werden diese Tests oft zu Beginn der Entwicklung durchgeführt. So kann beispielsweise geprüft werden, ob die Dokumentation (vollständig) vorhanden ist und bestimmte Qualitätsanforderungen erfüllt. Beispiele für statische Prüfungen sind die optische Kontrolle, Syntaxprüfung, Peer-Review, Informelle Überprüfung, formelle Inspektion, technische Überprüfung, statische Codeanalyse.

Dynamisches Testen

Sobald ein System verfügbar ist, kann es laufen und dynamische Tests können durchgeführt werden. Bei der dynamische Prüfung kann in implizites Testen oder explizites Testen unterteilt werden und je nachdem, wie viel der Tester über die interne Struktur der Software weiß; Black-Box-Test oder White-Box-Test.

Implizit dynamisch

Implizites Testen beinhaltet implizites/laterales Testen, ob das Testobjekt eine bestimmte een . erfüllt Anforderung befriedigt. Ein Beispiel sind implizite Leistungstests. Neben beispielsweise einem expliziten Funktionstest kann ein Tester Checkliste um die Leistung des Testobjekts in Bezug auf die Anzahl der Sekunden zum Öffnen eines Bildschirms zu verfolgen.

Explizit dynamisch

Beim expliziten Testen wird ein Testobjekt sehr direkt auf bestimmte Qualitätseigenschaften getestet. Ein Beispiel ist, dass ein Tester bewusst einen Test zur Leistungsmessung einrichtet, in dem er vorab die durchzuführenden Aktionen und Prüfungen einschließlich der erwarteten Ergebnisse definiert. Der Tester führt dann seinen Test durch, um zu überprüfen, ob das Objekt die definierten Leistungserwartungen erfüllt.

Whitebox-Test

An einer Whitebox-Test die internen Abläufe des Systems oder Produkts sind bekannt. Dieser Vorgang kann (vorübergehend) angepasst werden; B. um Zwischenergebnisse überprüfen zu können. Ein Beispiel hierfür ist das Kompilieren im Debug-Modus. Da die Implementierung bekannt ist, können die Tests speziell dafür gemacht werden. Und weil Zwischenergebnisse vorliegen, lässt sich leichter überprüfen, ob die Operation korrekt ist. Whitebox-Tests werden oft von den Entwicklern selbst verwendet; schließlich kennen sie das Innenleben. Das primäre Ziel ist oft nicht das Prüfen auf Fehler (Verifikation), sondern das Erkennen von Fehlern (Debugging). Ein bekanntes Beispiel dafür ist der Gerätetest, oft in Kombination mit a Testgetriebene EntwicklungAnsatz.

Wenn die internen Abläufe verwendet werden, der Test jedoch an einem echten (kompilierten!) Produkt durchgeführt wird, ist dies a Glassbox-Test, obwohl dieser Begriff oft nicht verwendet wird.

Blackbox-Test

Bei der Blackbox-Test dem Tester ist nichts (oder nur ein kleiner Teil) der Bedienung bekannt. Der Black-Box-Test wird in der Regel nach dem White-Box-Test von Personen durchgeführt, die sich auch nicht entwickelt haben und die wenig oder nichts über den inneren Aufbau wissen (müssen). Ein Beispiel ist a Abnahmeprüfung.

Graybox-Test

Neben der Unterteilung in die Hauptströme, Black-Box- und White-Box-Testing, gibt es noch eine weitere Variante, nämlich den Grey-Box-Test: "Es spielt keine Rolle, ob eine Katze schwarz oder weiß ist, solange sie Mäuse fängt." Beispiele sind: die Stresstest, Regressionstest, Datenkonvertierungstest, Praxistest, Schattentest.

Basierend auf Erfahrung

Ebenfalls üblich sind Tests von Experten, die aufgrund ihrer Erfahrung testen. Dies sind nicht ganz Ad-hoc-Tests, aber sie sind nah dran. Beispiele sind "Fehlerraten" und "Versuchsforschung". Beim Fehlerraten wird systematisch auf häufig auftretende Fehler getestet. Beim explorativen Testen geht man kreuz und quer durch das System. Das hat auch einen Lerneffekt und gibt Sicherheit, wenn keine Fehler gefunden werden. Zuerst werden oft die richtigen Wege beschritten und dann überprüft, ob auch mit Ausnahmen kann das System gut umgehen.

Testbericht

Nach dem Testen kann ein Testbericht sagen, was getestet wurde. Dies ist nützlich, weil Tests wiederverwendbar sind, aber auch, um Doppeltests zu vermeiden. Ein Prüfbericht kann Folgendes enthalten: Checklisten mit einigen von Testbasis wurde getestet. Testfälle und Testskripte mit Berichten über das, was getan wurde. Nachweise, dass die Testfälle durchgeführt wurden, z. B. Bildschirmauszüge. Befundverwaltung, Testabdeckungstools, Automatisierte Tests, testgetriebene Entwicklung Verwaltung und schließlich eine Demonstration, Komplettlösung vom System.

Aushändigen

Am Ende des Testprozesses wird eine Freigabemitteilung an den Auftraggeber mit den Testergebnissen und möglichen Risiken bei der Implementierung erstellt. Die Übergabe der Software inklusive Dokumentation erfolgt an die Geschäftsführung, Testskripte und sonstige Testware werden gesichert, damit sie später für Änderungen oder Nachtests verwendet werden können.

Testen in der Praxis

Das Testen ist arbeitsintensiv, der Arbeitsaufwand kann bis zu 40% des Aufbauaufwandes eines Informationssystems betragen. In der Praxis müssen sich Unternehmen, die Unternehmenssoftware einsetzen, stark auf die Qualität des Anbieters dieser Software verlassen, da die Unternehmen selbst zu klein sind, um sie richtig zu testen. Dies kann insbesondere im Gesundheitswesen mit relativ komplexer Software und begrenzter IKT-Tradition zu problematischen Situationen führen.