Arbeitsplatz
Die Einrichtung und das Benutzen des Arbeitsplatzes ist die Grundvoraussetzung.
Grundsätzlicher Aufbau
Ein Testarbeitsplatz besteht grundsätzlich auf dem oben skizzierten Aufbau:
- Arbeitsplatz
Hieran - am Arbeitsplatzrechner - verrichtet der Tester:in direkt. - Testautomat
Das Automatisierungsprogramm läuft auf einem separaten Rechner, da die Durchführung ja zeitaufwendig ist und die sonstige Arbeit nicht blockieren soll, ggf. kann die Durchführung auch in einem Hintergrundprozess laufen. Die Testdurchführung wird vom Tester angestoßen, mittlerweile aber auch schon im Rahmen eines CI/CD-Prozesses automatisiert nach der Installation angestoßen.
Für die Durchführung greift die Automation auf unterschiedliche Testdaten zu (Requests, Datenbank-Beladungen, etc) zu, nutzt diese zu Vorbereitung des Test oder zum Test selbst. Die Durchführung wird automatisiert in einem Durchführungsverzeichnis gespeichert, in dem so zu jedem Testfall standardisiert Ergebnisse abgelegt werden. - Anwendung
Die Anwendung muss auf alle Fälle unabhängig vom Testen und der Testautomatisierung laufen. In größeren Projekten werden diese von Anwendungsbetreibern zu Verfügung gestellt, immer häufiger durch einen automatisierten Prozess (CI-Pipeline). - Testdatenspeicher
Die Testdaten werden teilweise durch den Tester bestimmt (künstlich erzeugt) und teilweise dem Tester implizit oder explizit bereitgestellt (Anwendungskonfigurationen werden implizit bereitgestellt, in dem sie abgeklärt und als gegeben vorausgesetzt werden, ein zu betestender Datenbestand kann aus der Produktion abgezogen und anonymisiert bereitgestellt werden). Die Testdaten sind bewusst hinterlegt zur Nutzung durch die Testdurchführung. Die Testdaten können in unterschiedlichen Medien gespeichert sein wie Dateiverzeichnisse, Datenbanken, die ggf. durch spezifische Anwendungen verwaltet werden. - Durchführungsverzeichnis
Als unmittelbares Medium zur Dokumentation der Testdurchführung dient ein schlichtes Dateiverzeichnis. Die Dokumentation der Testdurchführung kann auch in einer Datenbank oder einer Anwendung erfolgen, für einen detaillierten Zugriff auf rohe Ergebnisse (z.B. Logs) würde das einen erheblichen Zusatzaufwand bedeuten und: Rohdaten sollte man in einem möglichst rohen Zustand sehen können.
3- 2- oder 1 Rechner-Architektur?
Der 3-Rechner-Aufbau zeichnet sich dadurch aus, dass neben dem Anwendungsserver ein zentraler Testautomat steht, auf den die Arbeitsplatzrechner zugreifen. Die Testanwendung kann dabei (RZ)-betriebsnah bereitgestellt werden und der Zugriff auf die Anwendungsserver nur von einem Rechner eingerichtet und berechnet werden.
Bei einem 2-Rechner-Aufbau mit Trennung Test und Anwendung könnte auch der Anwendungsserver RZ-nah eingerichtet werden. Die Testautomation müsste in jedem Testrechner mit allen Zugriffsberechtigungen und Freischaltungen eingerichtet und aktualisiert werden.
Zur Entwicklung von Tests, Automationen oder Programmen ist ein uneingeschränkte Testmöglichkeit sehr hilfreich - hierzu wäre aber die zu testende Anwendung erforderlich, was ja ein Nadelör sein kann. Gegenüber der
Bei einer 1-Rechner-Aufbau (Testautomation und Anwendung auf dem/den Arbeitsplatzrechnern) müsste zusätzlich die Testanwendungen mit allen Hilfssystemen außerhalb eines RZ-Betriebs eingerichtet werden – das bedarf einer separaten Installationsroutinen unabhängig von einem RZ-Betrieb. Wo eine CI/CD-Pipeline betrieben wird, kann eine solche Installationsroutine evtl. für den Arbeitsplatzrechner oder eine zusätzliche virtuelle Maschine bestehen.
Software-Entwickler führen in der Regel ihren Komponententests direkt auf ihrem Rechner aus, wo sie eine abgespeckte Anwendung betreiben - gute IDEs haben hierzu schon lange die notwendigen Werkzeuge integriert. So prüfen sie Programmänderungen immer wieder direkt auf ihrem Rechner, bevor sie fertig sind. Die allermeisten dieser Prüfungen verschwinden gleich wieder im virtuellen Papierkorb.