Artikel zwei von zwei, der unseren Weg zum Erfolg bei automa­tisierten Tests untersucht.

Im ersten Artikel beleuchteten wir bereits die Hintergründe und die Zielsetzung, Testautomatisierung für Kartenlesegeräte zu entwickeln. Im Folgenden nehmen wir Sie auf unsere Reise dorthin mit.

Methode eins: Virtualisierung

Um den Testprozess zu automatisieren haben wir zunächst überlegt, das Zahlungsterminal zu virtualisieren. Ein EFT/POS-Kartenlesegerät besteht aus einer Reihe von Hardwarekomponenten, die zusammenarbeiten, um Zahlungen zu ermöglichen.

Eine vereinfachte Darstellung des Aufbaus eines Zahlungsterminals ist in Abbildung 1 unten zu sehen. Die wichtigsten Komponenten, die sich auf die Prüfung auswirken, sind das Pin Entry Device (PED) und das Secure Model, das das PED steuert.

Um das Testen zu automatisieren, müssen alle Eingaben in das Terminal automatisiert und die Ausgaben verifiziert werden. Ziel war es, ein virtuelles Set-up der Zahlungsanwendung zu entwickeln und eine Simulation hinter der Hardware-Abstraktionsschicht durchzuführen.

Während dies in der Theorie das Ziel war, gab es in der Praxis erhebliche Herausforderungen:

• Kartenlesegeräte waren schwer zu simulieren: aufgrund der Logik in ihren Chips und der von den Kartenherausgebern implementierten Sicherheitsmaßnahmen wären diese in der virtuellen Umgebung nur schwer zu duplizieren.
  
  
• Das Sicherheitsmodell war schwer zu simulieren: Als Blackbox, die die gesamte Sicherheit handhabt, wäre es eine Herausforderung dieses zu implementieren.
  
  
• Es werden keine echten End-to-End-Tests durchgeführt: Wenn man ein Hardware-Produkt testet, kann nicht alles virtualisiert werden. Speicherverwaltung, Dateisperren und verwandte Funktionen sind nur einige Beispiele.

Method zwei: Robotik

Angesichts der Einschränkungen, die sich aus der Virtualisierung ergeben, haben wir uns mit der Robotik beschäftigt. Unsere Reise führte uns durch verschiedene Typen und Phasen:

1. Ein kostengünstiger, einarmiger Roboter: Während es mit diesem Typ einfach war, eine einfache kontaktlose Transaktion zu automatisieren, erwies sich das Gleiche für eine kontaktbasierte Transaktion als schwieriger. Es gelang uns zwar, das Einstecken von physischen Karten zu automatisieren, aber es war nicht möglich, eine Methode zum Drücken der Tasten zu finden.
   
   
2. Andere hochwertige Roboter: Einige waren recht kostspielig, und es war nicht abzusehen, wie viele wir ausprobieren müssten, bis wir einen finden würden der die von uns benötigten Aufgaben erfüllen konnte.
   
   
3. Unseren eigenen Roboter bauen: Wir wollten etwas, das weniger vielseitig und zuverlässiger ist. Unsere Nachforschungen brachten uns zum 3D-Druck. Mit dieser Technologie konnten wir Fingerdrucktasten und einen flexibleren Kartenarm herstellen. Das funktionierte großartig, bis auf eine Einschränkung: Der Roboter konnte nur eine Karte auf einmal testen.

Testen mit mehreren Karten

Karten verschiedener Marken verhalten sich aufgrund der auf ihren Chips enthaltenen Anwendungen und Profile unterschiedlich. Daher war es wichtig verschiedene Karten zu testen, damit die Kunden mit ihrer bevorzugten Karte einkaufen können.

Da der Roboter nicht mehrere Karten aufnehmen konnte, entwickelten wir eine andere Hardware (siehe Abbildung 2) die es uns ermöglichen würde, mehrere Karten einzugeben und eine einzige Karte auszugeben. Wir haben einen Kartenmultiplexer entwickelt, der bis zu 16 Karten aufnehmen kann, die auf eine Kartensonde übertragen werden können. Der Multiplexer ist auf 16 Multiplexer stapelbar, d. h. er kann bis zu 256 Karten aufnehmen.  

Wir haben das gleiche Gerät auch für kontaktlose Karten entwickelt.

Ermöglichung der Kalibrierung

Die nächste Herausforderung bestand darin, die unterschiedlichen Formen der Terminals selbst zu berücksichtigen. Unterschiedliche Formen und Tastenplatzierungen erforderten auch hier eine Methode zur Automatisierung.
Wir lösten diese Aufgabe, indem wir für jedes Terminalmodell ein Layout im Testskript abbildeten.

Von einfach bis anspruchsvoll

Wir hatten nun eine vollständig automatisierte Lösung, mit der wir einfache Fälle testen konnten. Der nächste Schritt war das Hinzufügen von mehr Komplexität, um die Testabdeckung zu erhöhen. Wir fügten hinzu:

●       Treiber, die POS-Systeme simulieren

●       Ein Gerät zur Simulation von Magnetstreifenkarten

●       Die Validierung der Terminalanzeige

Auch unsere Software musste weiterentwickelt werden, damit sie problemlos für komplexere Tests eingesetzt werden konnte. Deshalb haben wir unsere Architektur neu gestaltet. Gemeinsam mit einem Partner, der unsere Roboter und Hardware bereits zum Testen seiner Terminals für große Finanzinstitute verwendet, fügten wir eine einfache API hinzu, um unsere Software mit Systemen von Drittanbietern zu verbinden.
  
Jetzt war sie bereit für die Implementierung mit Kundensystemen.

Ermöglichung künftiger Erweiterungen

Mit Blick auf die Zukunft wäre ein wichtiges Element die Möglichkeit, die Testmöglichkeiten auf neue Optionen wie POS-Simulatoren oder Hardware zu erweitern. Daher haben wir die Lösung so entwickelt, dass sie allgemeiner ist und gleichzeitig eine Befehlsvalidierung hinzugefügt wird, um die Sicherheit bei jedem Schritt zu gewährleisten. 

Das Ergebnis war eine Lösung, die aus der Sicht des Testers erweiterbar und einfach zu benutzen war. In dieser Phase begannen wir damit, die meisten unserer manuellen Testfälle in automatisierte Fälle umzuwandeln. Als erstes ließen wir 5000 Testtransaktionen hintereinander auf jedem Terminal laufen. Was wir dabei entdeckten, war überraschend: Keines unserer Terminals bestand den Test, und im Durchschnitt fanden wir bei jedem Modell über 70 Fehler. Es war kein komplexes Testskript erforderlich, und wir haben auch nicht über die Testabdeckung nachgedacht. Mit einem einfachen Testfall konnten wir viele Probleme auf niedriger Ebene entdecken (Speicherlecks, Abstürze von Hardwaretreibern, Probleme mit Dateisperren usw.), die wir vorher nicht hatten erkennen und lösen können. Die Behebung dieser Probleme führte zu einer wesentlich stabileren Anwendung. Dies hat uns einen wichtigen Aspekt der Automatisierung gezeigt: Neben den bekannten Vorteilen der Automatisierung wie Geschwindigkeit, Genauigkeit, Wiederholbarkeit und Skalierbarkeit erwies sich die Möglichkeit, ein Terminal über einen langen Zeitraum ohne Unterbrechung zu testen, als sehr wertvoll. 

Die Reise geht weiter

Mit einem stabilen, automatisch ablaufenden Testsystem bestand die nächste Herausforderung darin, es für Zahlungsterminals freizugeben. Mit einem hohen Schutz und Barrieren für die Installation von Software-Updates wartete unser System auf die nächste Stufe. 

Wir haben den Prozess der kontinuierlichen Integration mit hohen Zielen begonnen und verbessern unsere Lösung kontinuierlich. Die Vorteile unseres Systems überwiegen eindeutig den Aufwand und die Kosten, die in seine Entwicklung geflossen sind. Automatisierung ist sicherlich eine Notwendigkeit. 

Wir testen heute mehr und schneller als je zuvor und sind in der Lage, die Produktqualität zu verbessern. Das sorgt dafür, dass unsere Kunden mit den von uns angebotenen Lösungen zufrieden sind und Vertrauen haben. 

-----------------------------------------

Kontaktieren Sie uns!