Testdaten: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „Auf Testdaten gibt es eine allgemeine und eine etwas konkretere Sicht. Wenn man es mal ganz oberflächlich durch die Brille des operativ arbeitenden Testers be…“) |
|||
| Zeile 1: | Zeile 1: | ||
| − | + | == Was sind Testdaten == | |
| + | Wenn man es mal ganz oberflächlich durch die Brille des operativ arbeitenden Testers betrachtet, dann sind Testdaten die Daten, die er im System benötigt um seinen Test durchzuführen. Wenn das [[System under Test (SUT)]] ein Taschenrechner ist, dann benötigt der Tester keine Testdaten um beispielsweise alle zugesicherten Eigenschaften zur Addition zu überprüfen. Wenn die zu testende zugesicherte Eigenschaft aber die Memory-Funktion des Taschenrechners betrifft, dann müssen im Memory ggf. Daten enthalten sein um den Test durchzuführen. Vermutlich würde der Tester in diesem Falle einfach das Einbuchen der erforderlichen Daten in das Memory des Taschenrechners als ersten Prozessschritt zum Bestandteil des Testfalles machen. Werden die Systeme größer und komplizierter steigt in der Regel der Bedarf an Testdaten und auch der Aufwand um diese zu erzeugen.<br /> | ||
<br /> | <br /> | ||
Stellen Sie sich ein System mit Kontakt- und Adressdaten einer fiktiven Firma vor. Das Systeme unterscheidet zwischen Interessenten (Kontakte, die noch nichts bei der Firma gekauft haben) und Kunden (Kontakte, die mindestens einen Kauf erfolgreich getätigt haben). Wenn es sich bei dem System um ein ordentliches [https://de.wikipedia.org/wiki/Enterprise-Resource-Planning ERP] handelt, dann wird es nicht einfach ein Schalter am Kontakt geben, wo der Tester bei der Erstellung seiner Testdaten zwischen Interessent und Kunde umschalten kann. In der Regel wird es viel mehr so sein, dass der Verkaufs-Prozess mit einer Bestellung, einem Rechnungsausgang und einer Eingangszahlung durchlaufen werden muss, damit der Kontakt vom System als "Kunde" ausgewiesen wird.<br /> | Stellen Sie sich ein System mit Kontakt- und Adressdaten einer fiktiven Firma vor. Das Systeme unterscheidet zwischen Interessenten (Kontakte, die noch nichts bei der Firma gekauft haben) und Kunden (Kontakte, die mindestens einen Kauf erfolgreich getätigt haben). Wenn es sich bei dem System um ein ordentliches [https://de.wikipedia.org/wiki/Enterprise-Resource-Planning ERP] handelt, dann wird es nicht einfach ein Schalter am Kontakt geben, wo der Tester bei der Erstellung seiner Testdaten zwischen Interessent und Kunde umschalten kann. In der Regel wird es viel mehr so sein, dass der Verkaufs-Prozess mit einer Bestellung, einem Rechnungsausgang und einer Eingangszahlung durchlaufen werden muss, damit der Kontakt vom System als "Kunde" ausgewiesen wird.<br /> | ||
| Zeile 5: | Zeile 6: | ||
'''Merke: Oft sind Daten im System das Ergebnis eines Prozesses, nicht einer direkten Erfassung. Benötigt der Tester bestimmte Datenkonstellationen für seinen Test, muss er ggf. einen umfangreichen Prozess durchlaufen.'''<br /> | '''Merke: Oft sind Daten im System das Ergebnis eines Prozesses, nicht einer direkten Erfassung. Benötigt der Tester bestimmte Datenkonstellationen für seinen Test, muss er ggf. einen umfangreichen Prozess durchlaufen.'''<br /> | ||
<br /> | <br /> | ||
| − | Oft sind Prozesse abhängig | + | Oft sind Prozesse abhängig von einem Zeitlauf. Wenn die fiktive Firma beispielweise zugesicherte Eigenschaften des automatischen Mahnlaufes testen möchte, dann gibt es da sicher auch Testfälle, die überprüfen, ob offene Posten nach 30 Tagen automatisch angemahnt werden. Offensichtlich braucht man für einen solchen Test Kunden mit offenen Posten, die vor 30 Tagen gebucht wurden. Würde der Tester diese Testdaten selbst anlegen müssen, würde der Prozess also - neben dem tatsächlichen Aufwand - auch noch 30 Tage Laufzeit in Anspruch nehmen.<br /> |
<br /> | <br /> | ||
| − | '''Merke: Es gibt eine Vielzahl von Einflussgrößen, die bestimmen | + | '''Merke: Es gibt eine Vielzahl von Einflussgrößen, die bestimmen ob des Erstellen von Testdaten durch den Tester im Verlauf der Testdurchführung überhaupt möglich ist. Zu diesen Einflussgrößen gehört die kleinstmögliche Prozesslaufzeit, Zugriffsbarrieren, [[Oberflächenrestriktionen]], etc.'''<br /> |
<br /> | <br /> | ||
| + | == Woher kommen Testdaten == | ||
| + | === Testdatenerstellung als Teil der Testausführung === | ||
| + | === Testdaten auf Bestellung === | ||
| + | === Testdaten aus der Produktion === | ||
| + | ==== Ohne Verfremdung ==== | ||
| + | ==== Mit Verfremdung ==== | ||
| + | === Testdaten aus einem Testdatengenerator === | ||
Version vom 30. August 2016, 10:32 Uhr
Inhaltsverzeichnis
Was sind Testdaten
Wenn man es mal ganz oberflächlich durch die Brille des operativ arbeitenden Testers betrachtet, dann sind Testdaten die Daten, die er im System benötigt um seinen Test durchzuführen. Wenn das System under Test (SUT) ein Taschenrechner ist, dann benötigt der Tester keine Testdaten um beispielsweise alle zugesicherten Eigenschaften zur Addition zu überprüfen. Wenn die zu testende zugesicherte Eigenschaft aber die Memory-Funktion des Taschenrechners betrifft, dann müssen im Memory ggf. Daten enthalten sein um den Test durchzuführen. Vermutlich würde der Tester in diesem Falle einfach das Einbuchen der erforderlichen Daten in das Memory des Taschenrechners als ersten Prozessschritt zum Bestandteil des Testfalles machen. Werden die Systeme größer und komplizierter steigt in der Regel der Bedarf an Testdaten und auch der Aufwand um diese zu erzeugen.
Stellen Sie sich ein System mit Kontakt- und Adressdaten einer fiktiven Firma vor. Das Systeme unterscheidet zwischen Interessenten (Kontakte, die noch nichts bei der Firma gekauft haben) und Kunden (Kontakte, die mindestens einen Kauf erfolgreich getätigt haben). Wenn es sich bei dem System um ein ordentliches ERP handelt, dann wird es nicht einfach ein Schalter am Kontakt geben, wo der Tester bei der Erstellung seiner Testdaten zwischen Interessent und Kunde umschalten kann. In der Regel wird es viel mehr so sein, dass der Verkaufs-Prozess mit einer Bestellung, einem Rechnungsausgang und einer Eingangszahlung durchlaufen werden muss, damit der Kontakt vom System als "Kunde" ausgewiesen wird.
Merke: Oft sind Daten im System das Ergebnis eines Prozesses, nicht einer direkten Erfassung. Benötigt der Tester bestimmte Datenkonstellationen für seinen Test, muss er ggf. einen umfangreichen Prozess durchlaufen.
Oft sind Prozesse abhängig von einem Zeitlauf. Wenn die fiktive Firma beispielweise zugesicherte Eigenschaften des automatischen Mahnlaufes testen möchte, dann gibt es da sicher auch Testfälle, die überprüfen, ob offene Posten nach 30 Tagen automatisch angemahnt werden. Offensichtlich braucht man für einen solchen Test Kunden mit offenen Posten, die vor 30 Tagen gebucht wurden. Würde der Tester diese Testdaten selbst anlegen müssen, würde der Prozess also - neben dem tatsächlichen Aufwand - auch noch 30 Tage Laufzeit in Anspruch nehmen.
Merke: Es gibt eine Vielzahl von Einflussgrößen, die bestimmen ob des Erstellen von Testdaten durch den Tester im Verlauf der Testdurchführung überhaupt möglich ist. Zu diesen Einflussgrößen gehört die kleinstmögliche Prozesslaufzeit, Zugriffsbarrieren, Oberflächenrestriktionen, etc.
