Viele Behörden und Unternehmen, die mit raumbezogenen Informationen arbeiten, bauen heute Geoportale als wesentlichen Bestandteil von Geodateninfrastrukturen (GDI) auf. Beispiele für etablierte Portale sind z.B. das Geoportal-Bund in Deutschland oder das Geoportal der österreichischen Länder geoland.at. Auch wenn einige GI-Unternehmen heute “GDI-Frameworks”, “-Toolkits” oder “-Suiten” anbieten, so sind individuell passende Softwarelösungen nicht “von der Stange” erhältlich.
Die Ursache dafür liegt im Wesentlichen darin begründet, dass Geoportale nicht “auf der grünen Wiese” entstehen, sondern in bestehende Umgebungen, z.B. eGovernment-Infrastrukturen, mit vielfältigen Rahmenbedingungen integriert werden müssen. Weiterhin befinden sich entsprechende Softwarelösungen nicht im massenhaften Einsatz, sondern werden eher projektspezifisch (weiter)entwickelt. Der Betreiber eines aufzubauenden Geoportals kann daher nicht blind darauf vertrauen, stabile Standardsoftware zu erhalten. Vielmehr wird die Notwendigkeit bestehen, die Software in Zusammenarbeit mit dem Anbieter zu testen und damit zu qualifizieren. Die Kosten für diese Bewertung in Form von Tests können durchaus ca. 30% der Gesamtkosten von Softwareprojekten betragen, in Einzelfällen auch darüber hinaus. Vor diesem Hintergrund erläutert dieser Beitrag, welche Softwaretests im Zusammenhang mit Geoportalen relevant sind und wie diese durchgeführt werden können.
Unter einem Geoportal wird im engeren Sinne eine Website verstanden, die den Zugriff auf verteilte (Basis-)Dienste (Karten-, Daten- und Katalogdienste) bündelt. Dazu stellen Geoportale diverse Clients (insbesondere Kartenviewer), Administrationstools sowie wiederum Dienste bereit. Mit letzteren ist es möglich, am Portal angeschlossene Basisdienste für externe Anwendungen in aufbereiteter Form bereitzustellen und auf diese Weise Portale zu vernetzen.
Weiterhin ergibt sich der Mehrwert für den Benutzer der genannten Clients im Wesentlichen daraus, dass die Antworten der Basis-Dienste aggregiert werden. Insbesondere wenn, wie heute üblich, die Clients browserbasiert sind, muss das Portal beispielsweise Karten aus verschiedenen Web Map Services gemeinsam darstellen oder Koordinatentransformationen, die von den Basisdiensten nicht angeboten werden, ausführen. Weiterhin muss das Portal in der Lage sein, die Antworten von Basis-Diensten zu Service-Ketten zusammenzufassen (z.B. Anzeige einer Karte zu einem geografischen Ort).
Während des ganzen Lebenszyklus von Softwareapplikationen spielen Tests und Prüfungen eine wesentliche Rolle. Bereits bei der Entwicklung wird die Applikationen Unit-, Komponenten- und Integrationstests unterzogen. Zur Überprüfung der umgesetzten Anforderungen und Spezifikationen werden später System– und Abnahmetests durchgeführt, während des Einsatzes der Software wird die Qualität durch Regressions- und Retests im Bereich der Wartung (Updates, Patches) sichergestellt. Hinter all den Testvarianten stecken verschiedenste Methodiken, Prozesse und Werkzeuge, um unterschiedliche Qualitätskriterien einer Software zu prüfen, so z.B. die Funktionalität, die Effizienz oder die Benutzbarkeit (Usability) der Applikation.
Etablierte Normen und Standards, Regelwerke und Prozesse helfen hier, strukturiert und methodisch Testprojekte durchzuführen und die Qualität der Software sicherzustellen. Als Basis kann hierfür z.B. das International Software Testing Qualifications Board (ISTQB) dienen, das mit der Zertifizierungreihe zum “Certified Tester” den Testern und Testmanagern Werkzeuge, Testprozesse und eine gemeinsame Begriffsdefinition vermittelt
Der im Folgenden vorgestellte Ansatz bezieht sich auf die Ebene des System- bzw. Abnahmetests, da bei diesen Testarten besonders die fachlichen Anforderungen im Vordergrund stehen. Nichtsdestotrotz sind weitere vor- bzw. nachgelagerte Teststufen sehr wichtig zur Sicherstellung der Qualität eines Geoportals.
Für den strukturierten und effizienten Ablauf des Testprojekts ist es nötig, zum einen das Testprojekt im gesamten Softwareentwicklungs- bzw. Abnahmeprozess zu positionieren, zum anderen einen Testprozess innerhalb des Testprojekts zu etablieren. Für die vorliegende Situation bietet sich der Testprozess in Anlehnung an ISTQB an. Die einzelnen Phasen des Testprojektes werden im Folgenden erläutert.
Wie auch für Testprojekte im Allgemeinen, müssen auch für den Test eines webbasierten Geoportals zu Beginn des Testprojekts die technischen und organisatorischen Rahmenbedinungen für die Testaktivitäten geschaffen werden. Ein essentieller Teil hierbei ist die Erstellung eines Testkonzepts. Der Standard ANSI/IEEE 829 bietet hier eine umfassende Struktur, um das Testprojekt zu planen und transparent darstellen zu können. Somit besteht für alle Beteiligten eine Basis, auf der das Testprojekt aufbaut. In einem Testkonzept werden folgende Festlegungen getroffen:
Zusätzlich zum Testkonzept wird ein Testcontrolling aufgesetzt, welches ständig den aktuellen Status aus dem Testbetrieb liefert. Hierbei können schon während der Testfallspezfikationsphase Aussagen getroffen werden, wie viele Testfälle noch zu beschreiben sind. Während der Testdurchführung liefert das Controlling einen Überblick über die durchgeführten und noch offenen Testfälle, die Testfallabdeckung und gefundene Fehler. Zusätzlich ist die Etablierung eines Fehlermangements nötig, um eine nachvollziehbare Dokumentation der Fehler zu ermöglichen und zu vermeiden, dass Fehler “verloren” gehen.
Die Informationen aus dem Testcontrolling und dem Fehlermanagement lassen sich für Zwischen- und Statusberichte aufbereiten. Somit ist eine ständige Transparenz des Tests gegeben und Probleme können frühzeitig identifiziert werden.
Als nächster Schritt müssen von den Testern die Anforderungsdokumente analysiert und daraus Testfälle abgeleitet und spezifiziert werden.
Hierbei kommen die im Testkonzept definierten Methoden zur Testfallermittlung und Testfallminimierung zum Einsatz. Die Testfälle werden in einem Testfallmanagementwerkzeug dokumentiert. Die Dokumentation der Testszenarien und Testfälle beinhaltet mindestens:
Bei der Analyse der Anforderungen muss zwischen den verschiedenen, zu testenden Qualitätskriterien unterschieden werden, für welche Testfälle spezifiziert werden. Für ein webbasiertes Geoportal sind hier einige Kriterien relevant, die typisch für Internetanwendungen sind, unter anderem:
Der Test der Funktionalität beantwortet in erster Linie die Frage: “Bietet das entwickelte und bereitgestellte Geoportal jene Funktionalitäten vollständig und korrekt, die in den Anforderungen definiert sind?” Gerade bei einem Geoportal ergeben sich hier neben etwaigen Standardfunktionen als Testobjekte auch sehr komplexe Funktionalitäten, z.B. im Zusammenhang mit Koordinatentransformationen. Im Folgenden sind einige für Geoportale typische Testobjekte beispielhaft aufgelistet:
Auf welche Besonderheiten in diesen verschiedenen Testobjekten zu achten ist, wird im zweiten Teil dieses Artikels näher beschrieben.
Der Test der Usability dient zur Bewertung der Bedien- und Benutzbarkeit des Geoportals und kann unter anderem folgende Themen behandeln:
Der Test der Effizienz untersucht das Geoportal auf sein Verhalten unter Last und Überlast, z.B. bei vielen gleichzeitigen Zugriffen auf das Portal. Gerade Internetapplikationen sind hier aufgrund der Masse an potentiellen Nutzern genau zu prüfen. Auch hier ist wichtig, Vorgaben in den Anforderungen zu definieren, z.B. mit wie vielen Benutzern zeitgleich bzw. über eine Zeitspanne zu rechnen ist und wie schnell das Geoportal auf Anfragen in bestimmten Lastzuständen reagieren muss. Auch die Regeneration des Systems nach Überlast ist hier ein möglicher Testaspekt.
Zu beachten ist bei diesen Tests, dass Faktoren in die Ergebnisse einwirken, die nicht beeinflusst werden können, so z.B. bei Einbindung von WMS-Diensten anderer Anbieter.
Für die Tests der Effizienz stehen gerade für Internetanwendungen eine Vielzahl von unterstützenden Werkzeugen aus dem kommerziellen und dem Open-Source-Bereich zu Verfügung, die sowohl bei der Lastgenerierung, als auch bei der Auswertung der Daten hilfreich sind.
Das Thema Sicherheit ist gerade bei Internetanwendungen außerordentlich wichtig und sehr oft in den Schlagzeilen. Das System und vor allem die Daten müssen vor unbefugten Zugriffen und Veränderungen geschützt sein. Ein Benutzer darf nur jeweils jene Daten sehen, für die er berechtigt ist. Der Aspekt Sicherheit ist sehr umfassend und bedarf einem hohen technischen Verständnis. So können Probleme bei der Infrastruktur (z.B. der Firewall, dem Netzwerk oder dem Web- bzw. Datenbankserver) oder neu entdeckte Sicherheitslöcher in Applikationen das Geoportal angreifbar machen. Für Sicherheitstests werden meist Spezialisten herangezogen, die auch die technischen Hintergründe verstehen. Darüber hinaus ist es sehr wichtig, Sicherheitstests in gewissen Abständen zu wiederholen, da durch Updates, Konfigurationsänderungen aber auch neu entdeckte Sicherheitslöcher neue Risiken entstehen können.
Neben den genannten technischen Aspekten ist die Sicherheit aus der Sicht der Anwendung zu betrachten. Die Frage dabei ist: Erhält jeder Nutzer über das Geoportal nur die Inhalte, zu deren Nutzung er berechtigt ist?
Voraussetzung für eine entsprechende Testdurchführung ist die Einteilung der Nutzer und deren Zuweisung zu Rechten. In den eigentlichen Tests ist zunächst zu überprüfen, ob der Nutzer korrekt authentifiziert wird. Im Anschluss an die Authentifizierung erfolgt durch das Geoportal die Zuordnung der Nutzer zu ihren Rechten (Autorisierung). Bei Web Map Services können sich die Rechte neben den Layern z.B. auf Maßstabsbereiche, die räumliche Ausdehnung oder die Abfrage von Sachdaten (GetFeatureInfo Request) beziehen, bei Web Feature Services dagegen auf die Feature Types sowie deren Attribute.
Die korrekte Umsetzung dieser Zugriffsrechte ist generell auf zwei Levels zu überprüfen: Zum einen bezüglich der Beschreibung der Portal-Dienste. Auf Schnittstellenebene müssen dabei die Capabilities der Dienste bereits entsprechend den Nutzerberechtigungen gefiltert sein, d.h. es sind z.B. nur die Layer in den Capabilities des WMS enthalten, welche der Benutzer sehen darf. Clientseitig werden – um beim vorigen Beispiel zu bleiben – nur die entsprechenden Ebenen zur Auswahl angezeigt. Dieser Sicherheitslevel entspricht dem Konzept der sogenannten client based security.
Der zweite Testlevel bezieht sich auf konkrete Anfragen an die Portaldienste unter Umgehung der Portal-Clients, also auf Schnittstellenebene. Nicht autorisierte Anfragen an Dienste sind dabei durch das Geoportal zu blockieren und mit einer entsprechenden Meldung zu beantworten.
Als Vorbereitung auf die Testdurchführung wird im Zuge der Analyse der Anforderungen und der Testfallerstellung auch der Bedarf an Testdaten identifiziert. Diese Testdaten müssen vor der Testdurchführung zur Verfügung stehen. Hierfür wird es notwendig sein, Testdaten manuell oder automatisch zu erstellen bzw. bestehende Testdaten zu verändern, wobei der automatischen Generierung der Vorzug zu geben ist. Eine weitere Möglichkeit zur Bereitstellung von Testdaten ist der Abzug von bestehenden System und ggf. der Anonymisierung dieser Daten.
Die Testdaten werden zu den Testfällen nachvollziehbar abgelegt, um eine Wiederholbarkeit der Testfälle zu ermöglichen.
Nach Vorbereitung der Testinfrastruktur und der Vorbereitung der Testfälle, werden diese von den Testern durchgeführt. Während der Testphase werden sowohl die funktionalen Tests, als auch die Effizenz-, Usability- und Sicherheitstests durchgeführt. Hierbei ist bei einem Geoportal darauf zu achten, dass alle benötigten externen Dienste während der Tests zur Verfügung stehen.
Pro Testfall werden bei der Durchführung folgende Informationen protokolliert:
Wenn ein Fehler gefunden wird, muss ein Eintrag im Fehlermanagement erstellt werden. Zusätzlich zur genauen Fehlerbeschreibung und den Metadaten, wie z.B. Version des Geoportals in welchem der Fehler aufgetreteten ist, wird der Fehler auch mit einer Fehlerklasse versehen, welche die Schwere des Fehlers beschreibt. Die Fehlerklassen sind im Testkonzept dokumentiert.
Sofern in der zu testenden Version gefundene Fehler behoben wurden, wird ein Fehlerretest und ein Regressionstest durchgeführt.
Zum Testende werden die protokollierten Testergebnisse ausgewertet, gegen die Abnahme- bzw. Testendekriterien geprüft und in einem finalen Testbericht abschließend bewertet. Ergebnis des Testberichts ist eine Empfehlung, ob das Geoportal in Einsatz gehen kann bzw. abgenommen werden kann.
Für den Fall, dass so eine Empfehlung nicht gegeben werden kann, müssen die Gründe hierfür detailliert aufgelistet werden.
Eine wichtige Aktivität zu Ende des Testprojekts ist die Analyse und der kritische Rückblick auf den gesamten Test, um die Erfahrungen und Erkenntnisse im Zuge der Testprozessverbesserung und in weitere Testprojekte einfließen zu lassen.
Abschließend werden die zum Test verwendeten Komponenten, Treiber, Testdaten, etc. archiviert, um den Test ggf. wiederholen bzw. nachvollziehen zu können.
In dieser Teil folgt die Beschreibung ausgewählter Tests und Testideen zur Funktionalität der Geoportalclients sowie zu Diensten und Schnittstellen.
Durch die Komplexität eines Geoportals kommt der Funktionalität der Dienste, Schnittstellen und Clients eine besondere Bedeutung zu. Dadurch bedarf es auch einer intensiven Auseinandersetzung mit den geforderten Funktionalitäten und den dahinter liegenden Normen und Standards. Im Folgenden wird nun auf diesen Teil eines Testprojekts detaillierter eingegangen.
Die Architektur des Geoportals basiert auf einer losen Kopplung zwischen den Basisdiensten und dem Geoportal einerseits sowie den Portaldiensten und externen Anwendungen andererseits. Dies setzt voraus, dass durch die jeweiligen Komponenten definierte Schnittstellen unterstützt werden. Im Falle von Geo-Diensten sind diese Schnittstellen durch das Open Geospatial Consortium (OGC) als Implementation Specifications beschrieben und ggf. durch Profile weiter spezifiziert. Die Einhaltung dieser Spezifikationen ist für Portalkomponenten, die der externen Kommunikation dienen, essentiell und spielt daher bei den Tests eine herausgehobene Rolle.
Das Mittel der Wahl für die Tests auf Einhaltung der OGC-Spezifikationen ist das durch das OGC angebotene und mittlerweile vollständig überarbeitete CITE-Programm (Conformance & Interoperability Test & Evaluation). Hier sind u.a. Tests zu verschiedenen Diensten, wie Web Map Services (WMS), Web Feature Services (WFS) und Catalog Services (CSW) möglich. Die entsprechenden Informationen zur Vorgehensweise und zu den Nutzungsbedingungen findet man auf der CITE-Homepage.
Aus der Sicht eines Portals gibt es allerdings einige Besonderheiten, welche den Einsatz von CITE-Tests einschränken. Als erstes wäre hier zu nennen, dass der CITE-Server vollen Zugriff auf die zu testenden Dienste haben muss. In Entwicklungsumgebungen oder in abgesicherten Netzen kann dies problematisch sein. Weiterhin setzt das CITE-Szenario das Einbinden von durch das OGC bereitgestellten Testdaten in die zu testenden Dienste voraus. Portaldienste greifen jedoch i.d.R. nicht auf eigene Daten, sondern kaskadierend auf externe Dienste zu. Insofern sind die meisten CITE-Tests für Portaldienste nicht anwendbar. Nicht durch das CITE-Programm abgedeckt sind die Tests der Clientkomponenten. Außerdem sind Tests zu Profilen sowie Tests auf Erfüllung der funktionalen Anforderungen, welche speziell auf die Bedingungen im jeweiligen Geoportal zugeschnitten sind, mit CITE nicht durchführbar. Insofern müssen eigene Testideen, wo möglich in Anlehnung an CITE, definiert werden.
Der Kartendienst ist der am häufigsten genutzte Dienst eines Geoportales und daher von zentraler Bedeutung.
Die Tests basieren hier auf den drei WMS-Schnittstellen GetCapabilities, GetMap und GetFeatureInfo. Bis auf wenige Ausnahmen sind dabei alle Schnittstellentests durch direkten Aufruf der Schnittstelle z.B. über die Eingabe als Browser-URL durchzuführen, um eventuelle Fehler in den WMS Clients auszuschließen. Die Antwort des Dienstes wird dann mit dem erwarteten Ergebnis verglichen. Auf den konkreten Aufbau der entsprechenden Requests soll dabei hier nicht eingegangen werden.
Bezüglich der GetCapabilities-Schnittstelle sind beispielsweise folgende Testideen sinnvoll:
Das GetMap-Interface ist bei Kartendiensten die zentrale Schnittstelle. Die Tests für eine korrekte Funktionsweise sind sehr umfangreich. Aus diesem Grunde wird auch hier nur auf einige wesentliche Testideen eingegangen:
In aller Regel sind in den Capabilities aus sicherheits-, performancetechnischen und/oder Marketing-Überlegungen heraus Maßstabsbereiche (ScaleHints) für einzelne oder alle Layer angegeben. In diesem Fall sollten Tests zu deren Einhaltung folgen. Hierbei ist einiger manueller Rechenaufwand erforderlich, um von Hand inhaltlich richtige GetMap-Requests zu generieren. Allerdings können die berechneten Bounding Boxes in anderen Testfällen wiederverwendet werden.
Ein weiterer Testkomplex bezieht sich auf die Darstellung der Layer. Hierbei sind u.a. folgende Testideen zu definieren:
Sollen im Geoportal SLD-fähige Dienste eingebunden werden können, so beziehen sich zusätzliche Tests darauf, ob die entsprechenden SLD-Parameter (z.B. SLD=) an diese Dienste “durchgereicht” werden und die Ergebniskarte im gewünschten Style gerendert wurde.
Bei den Tests der GetFeatureInfo-Schnittstelle sollte zunächst überprüft werden, ob zu jedem Layer, welcher in den Capabilities des Dienstes mit dem Attribut queryable=“1” gekennzeichnet wurde, die Sachdatenabfrage möglich ist. Analog zur GetMap-Schnittstelle sollen weiterhin alle angegebenen Ausgabeformate zur Informationsdarstellung erzeugt werden können. Wird der entsprechende Parameter (INFO_FORMAT) dagegen weggelassen, muss die Ausgabe trotzdem in einem der in den Capabilities angegebenen Formate erfolgen.
Zusätzlich sollte für jede Schnittstelle getestet werden, ob diese sowohl nur mit den obligatorischen als auch zusätzlich mit optionalen Parametern fehlerfrei funktioniert und ob auch ohne anbieterabhängige (vendor specific) Parameter ein gültiges Ergebnis geliefert wird.
Datendiensten kommt in Geoportalen die Aufgabe zu, Anfragen nach geographischen Objekten wie Orten, Adressen oder Regionen zu beantworten (Gazetteer Service) und/oder Raster- bzw. Vektordaten abzugeben (Web Coverage Service bzw. Web Feature Service). Für Gazetteer Services liegt bisher kein OGC-Standard vor; das entsprechende Papier hat derzeit den Status eines Best Practice Dokuments.
Dabei wird ein Gazetteer Service als Anwendungsprofil eines WFS behandelt. Soll der Gazetteer Service eines Geoportales standardisierte Schnittstellen nutzen, kommt daher nur der Einsatz eines WFS in Frage. Für die Nutzung und Weiterverarbeitung der Ergebnisse ist neben der Schnittstellen-Konformität des Dienstes insbesondere die Frage von Interesse, ob korrekte Resultate geliefert werden. In diesem Sinne wurden die folgenden Testideen ausgewählt, wobei sich hier nur auf die derzeit am häufigsten implementierte Version 1.0.0 eines Basic WFS bezogen wird.
Im Zusammenhang mit der GetCapabilities-Schnittstelle eines WFS ergeben sich unter anderem folgende Fragen:
Bezüglich des DescribeFeatureType-Interfaces ist zunächst zu prüfen, ob der Server Response ein gültiges GML-Schema liefert und ob auch ohne Angabe des Parameters TYPENAME alle FeatureTypes des WFS beschrieben werden.
Aus inhaltlicher Sicht ist beim Test der DescribeFeatureType-Schnittstelle ein besonderes Augenmerk darauf zu legen, dass nur die Attribute der Features beschrieben werden, welche über den Dienst auch “öffentlich gemacht” werden sollen.
Bezogen auf die GetFeature-Schnittstelle ist dann entsprechend zu testen, ob tatsächlich nur die Daten für diese Attribute ausgegeben werden. Dazu ist im GetFeature Request der Parameter PROPERTYNAME mit dem Wert * zu versehen und in einem zweiten Test vollständig wegzulassen. Weiterhin sollten mindestens noch folgende Testideen herangezogen werden:
Der letzte Test ist relativ aufwändig, da Filter Encoding-Anfragen zum einen sehr komplex sein können und zum anderen anhand der vorhandenen Daten sinnvolle Abfragen erstellt werden müssen, deren Ergebnis dann zu kontrollieren ist. Man sollte sich darüber im Klaren sein, dass insbesondere diese Tests nur Stichproben darstellen.
Außerdem sollte für alle Operationen eines WFS jeweils geprüft werden, dass sowohl die HTTP-Request-Methoden GET als auch POST unterstützt werden. Während Abfragen mittels GET-Methode über die Eingabe als Browser-URL durchgeführt werden können, ist dies bei POST nicht möglich. Hier hilft z.B. eine eigens entwickelte Webseite oder Applikation mit einem Eingabeformular, welches über die POST-Methode an den Server geschickt wird (setzt im Fall der Webseite Speicherrechte auf einem Webserver voraus).
Koordinatentransformationen sind in Geoportalen an verschiedenen Stellen erforderlich. Hier wird zunächst auf serverseitige Transformationen fokussiert, clientseitige Transformationen werden an anderer Stelle behandelt.
Die entsprechende Funktionalität wird meist nicht als OGC Web Service nach außen bereitgestellt, sondern lediglich intern genutzt. Insofern zielen die notwendigen Tests auf die Ergebnisse der Transformation und nicht auf Schnittstellen ab.
Am wichtigsten sind Koordinatentransformationen im Zusammenhang mit der Transformation der Kartenbilder bei WMS-Requests. Durch Portalkomponenten sind Transformationen dann zu realisieren, wenn clientseitig SRS angefordert werden, die durch die Basisdienste nicht unterstützt werden.
Die Transformationsroutine des Portal-WMS kann mittels eines separaten Referenzdatensatzes getestet werden. Als Testdatum empfiehlt sich z.B. ein Rechteck, das in etwa die Größe des geographischen Bereiches hat, für welchen die Transformation getestet werden soll.
Dieses Rechteck wird in unterschiedlichen Layern in den interessierenden SRS abgelegt, wobei seine (Soll-)Koordinaten jeweils manuell berechnet werden. Der im Browser abgesetzte GetMap Request fordert Karten in den verschiedenen SRS ab, wobei der jeweils nicht zu transformierende Layer als Referenz dient. Alternativ und schneller zu realisieren kann als Referenz auch die Bounding Box verwendet werden.
Bietet das Geoportal Funktionalitäten zur Geo-Suche (z.B. Orte, Adressen u.ä.) sowie zur Visualisierung der Suchergebnisse an, so ist eine Koordinatentransformation erforderlich, wenn das SRS der Karte mit dem der Suchergebnisse nicht übereinstimmt. Läuft die Suche über einen WFS, so erfolgt die Koordinatentransformation entweder durch einen entsprechenden Koordinatentransformationsdienst (bis WFS Version 1.0.0 zwingend) oder durch den WFS selbst (ab Version 1.1.0, wobei auch hier intern ein Transformationsdienst angesprochen werden kann). Auch hier wird dabei der Koordinatentransformationsdienst nur innerhalb des Geoportals zur Umrechnung einzelner (GML-) Features im angeforderten SRS genutzt und nicht als Dienst nach außen angeboten. In diesem Fall brauchen nicht die Schnittstellen des Dienstes, sondern nur das korrekte Ergebnis der Transformation getestet werden. Dies ist naturgemäß gegeben, wenn sich Karte und visualisierte GML-Features korrekt überlagern.
Bei der Interpretation der Testergebnisse ist zu beachten, dass Koordinatentransformationen unterschiedliche geometrische Genauigkeiten aufweisen. Um Fehler bei der Transformation identifizieren zu können ist es daher notwendig, das Genauigkeitspotential der jeweiligen Transformationsmethode und –parameter zu kennen: Bei Umrechnungen zwischen Gauß-Krüger-Streifen (z.B. EPSG-Codes 31466 bis 31469) wird das Ellipsoid nicht gewechselt und es kommen strenge Formeln zur Anwendung. Hier ist auch die Genauigkeit entsprechend hoch. Bei Transformationen jedoch, bei denen ein Datumsübergang erforderlich ist, so z.B. von Gauß-Krüger-Koordinaten auf dem Bessel-Ellipsoid zu UTM-Koordinaten auf dem Ellipsoid GRS80 (EPSG-Codes für Deutschland: 25832 und 25833) erfolgt die Umrechnung nicht streng, sondern über Transformationsparameter. Dabei gibt es für Deutschland eine Reihe verschiedener Parametersätze, welche sich durch die Genauigkeit, bezogen auf ein (geographisches) Verwendungsgebiet, unterscheiden. Entsprechend können Koordinatenunterschiede von wenigen Metern auftreten, wenn Soll- und Ist-Koordinaten über verschiedene Parametersätze berechnet wurden.
Zu den Administrationsmöglichkeiten des Geoportals zählen unter anderem die Konfiguration der Zugriffsrechte auf die verschiedenen Daten, Dienste und Funktionen, aber auch die Einbindung und Anordnung verschiedenster Dienste, Ebenen und Fachdaten in die Portalclients.
Während bei Geo-Services die Funktionalität durch Standardisierung im Wesentlichen festgeschrieben ist, kann sich diese bei den Clients auf Grund unterschiedlicher Anforderungen und Implementierungen zwischen den verschiedenen Geoportalen stark unterscheiden. Aus diesem Grunde kann hier nur auf ausgewählte Testobjekte mit entsprechenden Testideen eingegangen werden.
Kartenclients können je nach ihrer Ausprägung und ihrer Verwendung eine unterschiedliche Fülle an Funktionalitäten anbieten. Dies kann auch abhängig von der verwendeten Technologie sein, so wird ein Java- oder AJAX-basierender Client mehr Möglichkeiten bieten als ein HTML-Client, der vielleicht nicht einmal Javascript verwendet.
Folgende typische Funktionen von Kartenclients könnten als Testideen herangezogen werden:
Koordinatentransformationen werden für Clientkomponenten ebenfalls benötigt:
Die Transformation der Koordinaten der Bounding Box wird im einfachsten Fall mittels der Koordinatenanzeige des Kartenclients überprüft. Ist dies nicht implementiert, kann ggf. mit Hilfe von Tools zur Analyse des Netzwerkprotokolls der über das HTTP-Protokoll ein- und ausgehende Datenverkehr am Client und damit die transformierten Koordinaten eingesehen werden.
Die Koordinatenanzeige des Clients kann über einen einfachen Soll-/Ist-Vergleich von Passpunkten überprüft werden.
Mittels dieser Clients werden Anfragen zu geografischen Regionen, Adressen oder Orten an dezentrale Gazetteer Services weitergeleitet und die gefundenen Ergebnisse i.d.R. direkt im Kartenclient des Geoportals visualisiert. Von den Clients wird daher erwartet, dass die entsprechenden Requests richtig formuliert werden. Praktisch wird dies indirekt geprüft, indem die Ergebnisse von Anfragen über den Client mit denen von HTTP-Requests am Service verglichen werden.
Dabei sollte auch getestet werden, ob verschiedene Eingabemöglichkeiten der Suchbegriffe zu korrekten Antworten führen. Dies könnten z.B. sein:
Weitere Testszenarien beziehen sich dann auf die Darstellung der Ergebnisse:
Katalogclients zur Suche nach Daten und Diensten fragen in der Regel mehrere ISO 19115/19119 basierte Metadatenkataloge ab. Voraussetzung ist, dass der Client die Suche über die in den angeschlossenen Katalogservices implementierten Applikationsprofile unterstützt, z.B. das DE-Profil des ISO19115/ISO19119 Anwendungsprofils für OGC Web Catalogue Services (CSW-2.0).
In Analogie zur Adress- und Ortssuche ist auch hier die Trefferliste einer Suchanfrage hinsichtlich Richtigkeit zu überprüfen. Dies kann durchgeführt werden, indem identische Anfragen zum einen über den Metadatensuchclient des Geoportals und zum anderen direkt an die extern angeschlossenen Metadatenkataloge, z.B. über deren Clients oder (besser) als SOAP Requests, gestellt werden. Beide Antworten sind dann zu vergleichen. Verschiedene Eingabevarianten müssen auch hier zu korrekten Ergebnissen führen.
Ein weiterer Testkomplex bezieht sich auf die Darstellung der Suchergebnisse im Client. Hierbei sind Testideen zu entwerfen, welche diese hinsichtlich
überprüfen.
Die rasche Verbreitung von Geoportalen und deren Benutzung auch durch GIS-Laien, Anwendungen in kritischen Bereichen wie innere Sicherheit oder Katastrophenschutz und nicht zuletzt die Besonderheiten der zugrunde liegenden Service-orientierten Architektur sind einige der Aspekte, aus denen spezielle Qualitätsanforderungen an die entsprechenden Softwarelösungen erwachsen. Die zur Sicherstellung dieser Qualitätsansprüche erforderlichen Softwaretests waren Gegenstand dieses zweigeteilten Beitrages. Insbesondere wurde gezeigt, wie allgemeines IT-Test- und GI-Anwendungs-Knowhow bei der Spezifizierung und Durchführung der Tests ineinander greifen und so zum Projekterfolg beitragen.
In Zukunft werden vor allem im Bereich der Testautomatisierung hier weitere Möglichkeiten entstehen, die notwendigen Tests noch effizienter zu gestalten.