Ursachen für Rauschen beim Abspielen

Einleitung

Bei jedem Abspielen mit Testimony, selbst bei einem identischen System ohne Änderungen, sind Skriptfehler unvermeidlich. Diese können durch unterschiedliche Umgebungsbedingungen zwischen dem Aufzeichnungs- und dem Abspielsystem, durch Einschränkungen in der breiteren Abspielumgebung (z. B. entscheiden sich einige Unternehmen dafür, MS Office nicht auf den Bot-VMs zu installieren), durch geringfügige Unterschiede bei den Ausführungszeiten oder durch bestimmte Aspekte der Funktionsweise von SAP und Testimony verursacht werden.

Diese Fehler beim Abspielen stellen ein “Rauschen” dar, das die echten Regressionsfehler verdecken kann, nach denen Testimony sucht.

Mit dem Doppelabspielen versuchen wir, dieses Rauschen zu beseitigen, was die Identifizierung echter Regressionsfehler erheblich erleichtert.

Gründe für Probleme beim ersten oder zweiten Abspielen

Selbst wenn Aufzeichnungs- und ein Abspielsystem identisch sind (d.h. vor dem Start des Abspielens wurden keine Release- / Upgrade- / Patching-Änderungen auf dem Zielsystem vorgenommen), sollten Sie aufgrund der grundlegenden Funktionsweise von SAP und Testimony immer mit einigen wenigen Problemen rechnen (Unterschiede zwischen der Ausgabe der Aufzeichnung und der Ausgabe des Abspielens). In diesem Abschnitt werden häufige Gründe für Abspielfehler genannt.

Darüber hinaus werden im Testimony Testers’ Guide unterschiedliche Arten von Problemen erläutert. Einige werden durch Faktoren verursacht, die nicht auf echte Regressionsfehler hindeuten.

Benutzeranmeldungen werden nicht erfasst

Szenario:

• Benutzer1 meldet sich um 09:00 Uhr an
• Aufzeichnung wird um 09:30 Uhr eingeschaltet
• Um 10:00 Uhr legt Benutzer1 den Kundenauftrag 1234 an
• Um 10:30 Uhr meldet sich Benutzer2 an
• Um 11:00 Uhr ändert Benutzer2 den Kundenauftrag 1234
• Um 11:30 Uhr meldet sich Benutzer3 an
• Um 12:00 Uhr zeigt Benutzer3 den Kundenauftrag 1234 an
  

In diesem Szenario hat Testimony die Anmeldung von Benutzer1 nicht erfasst, weil er sich vor dem Einschalten der Aufzeichnung angemeldet hat. Standardmäßig verwirft Testimony alle Aktivitäten für einen Benutzer ohne Anmeldung, so dass die Erstellung des Kundenauftrags 1234 nicht abgespielt wird. Aus diesem Grund werden die Aktivitäten von Benutzer2 und Benutzer3 fehlschlagen, da der Kundenauftrag, auf den sie zuzugreifen möchten, nicht existiert.

Testimony verfügt über eine Option zur Erstellung von Anmeldeskripten für Benutzer, deren tatsächliche Anmeldung nicht erfasst wurde. Wenn diese Option aktiviert ist, werden alle Aktivitäten in der Benutzersitzung (d.h. in dem betreffenden SAPGUI-Fenster), für die keine Anmeldung vorlag, weiterhin verworfen. (Damit wir z.B. nicht versuchen, eine Transaktion aus der Mitte des Bildschirms abzuspielen) In unserem obigen Szenario wäre also der Kundenauftrag 1234 nicht erstellt worden (und damit wären die nachfolgenden Transaktionen fehlgeschlagen), weil Benutzer1 in einer Sitzung gearbeitet hat. Hätte Benutzer1 jedoch nach dem Start der Aufzeichnung eine andere SAPGUI-Sitzung geöffnet und dann 1234 erstellt, hätten die beiden anderen Transaktionen funktioniert.

Dieses Szenario würde zu Fehlern beim ersten Abspielen führen, die aber auch beim zweiten Abspielen auftreten würden und daher durch den nach dem zweiten Abspielen durchgeführten Problemvorschlag herausgefiltert würden, da die Gründe für die Fehler genau dieselben wären. Wir wissen also, dass diese Probleme nicht auf echte Regressionsfehler hindeuten.

Locking

Szenario 1:

• Benutzer1 versucht, den Kundenauftrag 1234 zu ändern
• Einige Sekunden später versucht Benutzer2 ebenfalls, den Kundenauftrag 1234 zu ändern, und erhält die Meldung “Kundenauftrag gesperrt”
• Einige Sekunden später schließt Benutzer1 seine Änderung ab und speichert den Kundenauftrag
• Einige Sekunden später versucht Benutzer2 erneut, den Kundenauftrag zu ändern, diesmal erfolgreich
  

Weil die Sperre (Locking) so flüchtig ist (jede Sperre dauert oft nur einige Sekunden oder weniger), kann es vorkommen, dass die Änderungen von Benutzer2 während des Abspielens ausgeführt werden, weil die Sperre bereits abgelaufen ist. In diesem Fall erhält Benutzer2 nicht die Meldung “Kundenauftrag gesperrt”. Dies führt zu einer Fehlermeldung (Different Message) im Skript.

Umgekehrt gilt das gleiche.

Szenario 2:
Benutzer3 ändert Kundenauftrag 1234. Eine Minute später ändert Benutzer4 den Kundenauftrag 1234 erneut. Da Benutzer3 die Änderung beendet hat, gibt es keine Sperre, so dass die Änderung von User4 normal abläuft. Während des Abspielens ist es möglich, dass die Änderung von Benutzer4 ausgeführt wird, während die Änderung von Benutzer3 noch läuft. Dies führt dazu, dass Benutzer4 die Meldung “Kundenauftrag gesperrt” erhält, was zum Scheitern seines Skripts führt.
Da Sperren so flüchtig sind und vom Timing und der Reihenfolge der Aufrufe abhängen, ist es möglich, dass Sperrfehler beim ersten Abspielen auftreten, beim zweiten jedoch nicht; oder umgekehrt. (Wenn beim Abspielen in beiden Fällen ein Sperrfehler auftritt, wird dieser durch die Funktion des Doppelabspielens herausgefiltert)

Zeitplanung / Ablaufplanung

Szenario1 :

• Batch-Job A aktualisiert die Bestände in einem Lager. Er startet um 15:00 Uhr und endet um 16:00 Uhr
• Um 16:30 Uhr erstellt Benutzer1 einen Auftrag, der den Lagerbestand überprüft. Das Material ist in ausreichender Menge vorhanden, so dass der Auftrag angelegt wird. Während des Abspielens ist es möglich, dass die Auftragserstellung von Benutzer1 vor dem Start von Batch-Job A (oder während der Job noch läuft) erfolgt. In diesem Fall ist es daher möglich, dass bei der Überprüfung des Lagerbestands nicht genügend Bestand für die Bestellung vorhanden ist, so dass ein Fehler gemeldet wird und das Skript fehlschlägt.
  

Es ist sehr wahrscheinlich, dass ein Fehler dieser Art, der beim ersten Abspielen gemeldet wird, auch beim zweiten Abspielen gemeldet wird und daher durch das Doppelabspielen herausgefiltert wird. Es ist jedoch immer noch möglich, dass Timing-Probleme nur bei einem der Abspielvorgänge auftreten.

Szenario 2:

• Zwischen 15:00 und 16:00 Uhr wird eine Reihe von 25 Benutzertransaktionen ausgeführt, die jeweils den Status verschiedener Aufträge auf “lieferbereit” aktualisieren
• Um 16:15 Uhr beginnt ein Batch-Job, der die als lieferbereit markierten Aufträge verarbeitet. Für jeden gefundenen Auftrag wird eine Meldung im Auftragsprotokoll ausgegeben.
  

Dieses Szenario kann als die Umkehrung des vorherigen Szenarios betrachtet werden. In diesem Fall verarbeitet ein Batch-Job die Verbuchungen mehrerer Dialogtransaktionen. Beim ersten Abspielen beginnt der Batch-Job, bevor der Auftragsstatus aktualisiert wurde. Dies führt zu einer Meldung “keine Aufträge zu verarbeiten” im Auftragsprotokoll. Da dies in der Aufzeichnung nicht registriert wurde, schlägt der Batch-Job fehl. Wenn beim zweiten Abspielen der Batch-Job erneut gestartet wird, bevor irgendwelche Aufträge aktualisiert wurden, würde dieser Fehler erneut auftreten und durch die Funktion des Doppelabspielens herausgefiltert werden.

Regressionsfehler, die zu anderen Fehlern führen

Bei einem zweiten Abspielen im Szenario “Doppelabspielen” ist es möglich, dass ein echter Regressionsfehler in einem Skript zu Fehlern in in anderen Skripten führt, die keine tatsächlichen Regressionsfehler sind.

Szenario:

• Batch-Job A aktualisiert die Bestände in einem Lager. Er startet um 15:00 Uhr und endet um 16:00 Uhr
• Um 16:30 Uhr erstellt Benutzer1 einen Auftrag, der den Lagerbestand überprüft. Das Material ist in ausreichender Menge vorhanden, also wird der Auftrag angelegt. Dies ist dasselbe Szenario wie oben, aber in diesem Fall wurden bei dem ersten Abspielen sowohl der Batch-Job als auch die Transaktion von Benutzer 1 in der richtigen Reihenfolge ausgeführt und erfolgreich abgeschlossen. Beim zweiten Abspielen wurde jedoch ein Regressionsfehler in Batch-Job A eingeführt, der dazu führt, dass er ohne Aktualisierung der Lagerbestände fehlschlägt. Dies führt dazu, dass die Transaktion von Benutzer1 fehlschlägt, obwohl die Transaktion selbst keinen Regressionsfehler aufweist.