Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Testverfahren in dokumentorientierten Entwicklungsumgebungen Pascal Vallet Team4 GmbH Seminarvortrag WS 2009/2010 20.01.2010.

Ähnliche Präsentationen


Präsentation zum Thema: "Testverfahren in dokumentorientierten Entwicklungsumgebungen Pascal Vallet Team4 GmbH Seminarvortrag WS 2009/2010 20.01.2010."—  Präsentation transkript:

1 Testverfahren in dokumentorientierten Entwicklungsumgebungen Pascal Vallet Team4 GmbH Seminarvortrag WS 2009/

2 Inhalt Dokumentorientierte Entwicklung Motivation Exemplarische Testverfahren Fazit Ausblick

3 Dokumentorientierte Entwicklung

4 4 Dokumentorientierte Entwicklung – Das Dokument Ein Dokument besteht aus... Einer eindeutigen ID (UNID), über die es identifiziert wird Feldern, die beliebige Inhalte haben können (Text, Bilder, Dateien,...) Feldern, deren Inhalt nicht angezeigt wird Name: Alter: Bild: Peter Müller 31

5 5 Dokumentorientierte Entwicklung – Das Dokument Mit jedem Feld sind Events verbunden, in denen Code ausgeführt werden kann, z.B. Onchange – Wenn ein Feld geändert wird Querysave – Wenn ein Speichern des Dokuments initialisiert wird Postsave – Wenn das Speichern des Dokuments abgeschlossen ist Name: Alter: Bild: Peter Müller 31 Name - Onchange Lösche Alter Bild - Postsave Sende Bild an

6 6 Dokumentorientierte Entwicklung – Besondere Dokumente Es gibt auch besondere Dokumente, die einen programmatischen Nutzen haben, z.B. Masken – erlauben es, ein Dokument anzusehen oder zu bearbeiten Ansichten – erlauben es, mehrere Dokumente Tabellarisch darzustellen Agenten – erlauben es, programmierten Code auf ausgewählte Dokumente anzuwenden

7 7 Dokumentorientierte Entwicklung – Relationen Nicht in Lotus Notes vorgesehen, jedoch von vielen Firmen benutzt Verbindet Dokumente, wobei die möglichen Ziele eingeschränkt werden können Relationen selbst sind auch Dokumente Über Relationen kann (begrenzt) auf Daten des Zieldokuments zugegriffen werden Name: Alter: Chef: Name: Alter: Chef:

8 Motivation

9 9 Motivation – Problematik mit gebräuchlichen Testverfahren Es gibt bereits zahlreiche Testverfahren, um Programmcode zu testen. => Annahme: Jedes benutzte Codefragment ist bereits erfolgreich getestet. Problem: Trotz funktionierenden Teilprogrammen können Reihenfolge und Interaktion dieser nicht vorhergesagt werden. Ebenfalls kann es passieren, dass Code auf Dokumente angewandt wird, für die er nicht gemacht ist.

10 10 Motivation – Codefragmente Beispiel 1: Unendliche Schleife Obwohl beide Codefragmente terminieren und keinen rekursiven Aufruf enthalten, führt diese Code zu einer Endlosschleife. Anmerkung: Ab Version 6.0 von Lotus Notes wird dieses einfache Problem abgefangen, doch kann die grundlegene Problematik in komplexerer Form immer noch auftreten. FirstName - Onchange Setze LastName auf “Teststring“ LastName - Onchange Setze FirstName auf (LastName + “X“)

11 11 Motivation – Codefragmente Beispiel 2: Prioritätskonflikt Obwohl beide Codefragmente terminieren, kann nicht eindeutig bestimmt werden, was nach einem Fokuswechsel von FirstName nach LastName in Testfeld steht. Anmerkung: Ab Version 8.0 von Lotus Notes wurde deshalb die Funktionsweise von onBlur verändert, es reagiert jetzt nur noch, wenn das anzeigende Fenster den Fokus verliert. FirstName - OnBlur Setze Testfeld auf “Teststring“ LastName - OnFocus Setze Testfeld auf “Hallo“

12 12 Motivation – Codefragmente Beispiel 3: Bearbeiten von Abbrüchen In diesem Fall kann es passieren, dass Testfeld einen Wert zugewiesen bekommt, ohne dass das Dokument gespeichert wurde. FirstName - QuerySave Setze Testfeld auf “Teststring“ LastName - QuerySave Wenn LastName = ““ dann Speichern abbrechen

13 13 Motivation – Realisierung der Relationen Da die Relationen kein internes Konzept von Lotus Notes ist, ist die Realisierung dieser meist vereinfacht. Werte, die über Relationen gesetzt werden, werden nicht ständig abgefragt (dies wäre realisierbar, würde aber den Rechenaufwand beträchtlich erhöhen), sondern beim Setzen der Relation gespeichert. Daraus können inkonsistente Daten erwachsen.

14 14 Motivation – Realisierung der Relationen Beispiel 4: Einfache Relation Es gebe eine Relation von Dokumenten, die im Feld „FormName“ den Wert „Mitarbeiter“ stehen haben (im Folgenden einfach Mitarbeiter genannt) zu Dokumenten, die im Feld „FormName“ den Wert „Firma“ enthalten (im Folgenden Firmen). Über diese Relation wird das Gesamtgehalt aller Mitarbeiter der Firma berechnet. FormName: Mitarbeiter Name: Firma: Gehalt: FormName: Firma Name: Löhne:

15 15 Motivation – Realisierung der Relationen Beispiel 4: Einfache Relation Die Sekretärin der Firma Team4 legt nun einen neuen Mitarbeiter an. Bisher zahlte die Firma Team € Lohn. FormName: Mitarbeiter Name: Schmidt Firma: Team4 Gehalt: 100 € FormName: Firma Name: Team4 Löhne: €

16 16 Motivation – Realisierung der Relationen Beispiel 4: Einfache Relation Anhand der Relation wird das Feld Löhne in der Firma aktualisiert. FormName: Mitarbeiter Name: Schmidt Firma: Team4 Gehalt: 100 € FormName: Firma Name: Team4 Löhne: €

17 17 Motivation – Realisierung der Relationen Beispiel 4: Einfache Relation Schmidt hat sich nun bewährt und bekommt eine Gehaltserhöhung. FormName: Mitarbeiter Name: Schmidt Firma: Team4 Gehalt: 150 € FormName: Firma Name: Team4 Löhne: €

18 18 Motivation – Realisierung der Relationen Beispiel 4: Einfache Relation Und ohne spezielle Implementierung wird der Wert im Feld Löhne nicht angepasst! FormName: Mitarbeiter Name: Schmidt Firma: Team4 Gehalt: 150 € FormName: Firma Name: Team4 Löhne: €

19 19 Motivation – Realisierung der Relationen Beispiel 4: Einfache Relation Dieses eigentlich sehr simple Problem erfordert weitreichende Pflege: Die Werte müssen bei Gehaltsänderungen, Entlassungen, Firmenumbenennungen etc. immer aktualisiert werden. Wesentlich komplizierter wird dies, wenn man transitive Relationen benutzt: FormName: Mitarbeiter Name: Schmidt Firma: Team4 FormName: Firma Name: Team4 Konzern: Neureich FormName: Konzern Name: Neureich

20 Exemplarische Testverfahren

21 21 Testverfahren – Randfälle Das Konzept der Randfälle wird auch bei herkömmlichen Tests benutzt. Es ist auch in der dokumentorientierten Entwicklung der meistbenutzte Ansatz, eine Applikation zu testen. Ein Test unter Berücksichtigung der Randfälle erfolgt in drei Schritten: Randfallanalyse Testlauf Auswertung

22 22 Testverfahren – Randfälle Randfallanalyse Testlauf Auswertung Dies ist der aufwändigste und wichtigste Schritt. Er besteht daraus, mögliche Randfälle für die Eingaben in ein Dokument zu finden. Randfälle sind Eingabekonstellationen, die entweder am Rande der möglichen Eingaben liegen (positive Randfälle) oder gerade nicht mehr im Feld möglicher Eingaben (negative Randfälle). Man bekommt durch die Analyse eine Menge an Eingabekonstellationen. Beispiel: Das Feld „Beginn des Termins“ darf Werte zwischen 10:00 und 16:00 (einschließlich) enthalten. Positive Randfälle wären die Werte 10:00 und 16:00, negative Randfälle wären die Werte 9:59 und 16:01.

23 23 Testverfahren – Randfälle Randfallanalyse Testlauf Auswertung Man wendet jede Eingabekonstellation, die man während der Randfallanalyse erarbeitet hat, auf das entsprechende Dokument an. Wenn man annimmt, dass Randfälle pro Feld ermittelt werden, so steigt die Zahl der Randfallkonstellationen im Vergleich zu der Zahl der Felder exponentiell. Daher ist es wichtig, gezielt die interessantesten Randfälle auszuwählen. Der Wert des Testverfahrens hängt von der Auswahl der geeignetsten Randfälle ab. In der Regel ist es am Besten, alle Randfälle zu testen, allerdings ist dies oft aus Zeit- und Kostengründen nicht realisierbar.

24 24 Testverfahren – Randfälle Randfallanalyse Testlauf Auswertung Nachdem alle Testläufe abgeschlossen sind, wird überprüft, ob alle positiven Randfälle zu erfolgreichen, alle negativen Randfälle zu erfolglosen Testläufen, Abstürzen oder zu Fehlermeldungen geführt haben. Falls dies der Fall ist, funktioniert das Dokument und gilt als erfolgreich getestet. Der Test mit Randfällen ist theoretisch immer erfolgreich, jedoch wird er oft nicht vollständig durchgeführt. Außerdem kann es passieren, dass während der Randfallanalyse Randfälle übersehen werden.

25 25 Testverfahren – Randfälle mit Hilfsfeld Wie bereits erwähnt, ist ein Problem des Testens mit Randfällen, dass oft nicht alle gewünschten Randfälle ausprobiert werden können. Um dies zu umgehen, fügt man folgende Codes in das Dokument ein: PruefeKonstellation ist dabei eine Methode, die alle Felder auf korrekte Belegung prüft. PostOpen Setze Hilfsfeld auf “Erfolglos“ PostSave Setze Hilfsfeld auf “Erfolgreich“ Wenn PrüfeKonstellation “wahr“ zurückgibt dann Setze Prüffeld auf “Erfolgreich“

26 26 Testverfahren – Randfälle mit Hilfsfeld Danach erstellt man einen Agenten (ein im Hintergrund laufendes Programm), welcher ein entsprechendes Dokument öffnet, automatisch positive Randfallkonstellationen einträgt, das Dokument speichert und schließt. Nun kann man eine Ansicht erzeugen, die alle Dokumente, die vom Agenten erstellt wurden, anzeigt: Durch Vergleich der letzten beiden Spalten kann man nun einfach feststellen, ob einer der Tests fehlgeschlagen ist. Ein analoges Verfahren für negative Randfälle führt zu einem vollständigen Randfalltest.

27 27 Testverfahren – Relationenanalyse Die Relationenanalyse dient zur Überprüfung der Datenkonsistenz bei Relationen, insbesondere, wenn diese über mehrere Instanzen reichen. Zur Erläuterung dient das Beispiel aus der Motivation, erweitert um ein Feld Lohn: FormName: Mitarbeiter Name: Firma: FormName: Firma Name: Konzern: FormName: Konzern Name: Lohn:

28 28 Testverfahren – Relationenanalyse Als erster Schritt wird ein Konzern erstellt. Dann wird eine Firma erstellt, die diesem Konzern angehört, und zuletzt ein Mitarbeiter, der in dieser Firma arbeitet. FormName: Mitarbeiter Name: Schmidt Firma: Team4 FormName: Firma Name: Team4 Konzern: Neureich FormName: Konzern Name: Neureich Lohn:

29 29 Testverfahren – Relationenanalyse Der Mitarbeiter bekommt nun einen Lohn eingetragen. Korrekterweise sollte dieser Wert nun in Firma und Konzern übernommen werden. Ein Test über eine weitere Instanz ist nicht notwendig, da bereits die Übertragung von der Firma zum Konzern indirekt erfolgt. Wenn die Relation Firma-Konzern ordentlich getestet wurde, gibt es da also keine Probleme. FormName: Mitarbeiter Name: Schmidt Firma: Team4 FormName: Firma Name: Team4 Konzern: Neureich FormName: Konzern Name: Neureich Lohn: 100 € Lohn: 100 € Lohn: 100 €

30 30 Testverfahren – Relationenanalyse Nun passiert die entscheidende Änderung: Der Lohn des Mitarbeiters ändert sich. FormName: Mitarbeiter Name: Schmidt Firma: Team4 FormName: Firma Name: Team4 Konzern: Neureich FormName: Konzern Name: Neureich Lohn: 150 € Lohn: 100 € Lohn: 100 €

31 31 Testverfahren – Relationenanalyse Dies sollte ein Signal an die Firma senden, dass der Lohn sich geändert hat: Hier sollte die Änderung nachvollziehbar sein: FormName: Mitarbeiter Name: Schmidt Firma: Team4 FormName: Firma Name: Team4 Konzern: Neureich FormName: Konzern Name: Neureich Lohn: 150 € Lohn: 150 € Lohn: 100 €

32 32 Testverfahren – Relationenanalyse Der nun folgende Teil ist das eigentlich Interessante an diesem Test: Die Firma sollte nun ihrerseits den Konzern aktualisieren. FormName: Mitarbeiter Name: Schmidt Firma: Team4 FormName: Firma Name: Team4 Konzern: Neureich FormName: Konzern Name: Neureich Lohn: 150 € Lohn: 150 € Lohn: 150 €

33 33 Testverfahren – Relationenanalyse Dieses Verhalten erscheint zunächst trivial, wodurch es überflüssig wirkt, den Konzern zu überprüfen. Entscheident ist jedoch die Tatsache, dass die Firma den Konzern über die Änderung informiert, ohne selbst vom Eintragenden berührt worden zu sein. Dies bedeutet, dass Firma in der Lage ist, Änderungen anhand der Relation Mitarbeiter-Firma transitiv weiterzugeben – und damit ist diese Relation voll funktional. FormName: Mitarbeiter Name: Schmidt Firma: Team4 FormName: Firma Name: Team4 Konzern: Neureich FormName: Konzern Name: Neureich Lohn: 150 € Lohn: 150 € Lohn: 150 €

34 34 Testverfahren – Programmatische Umsetzung Man kann die Domino-Umgebung auch aus Java ansprechen. Dazu dienen die Bibliotheken des Domingo-Projekts. Wie man sieht, ist das Dokument in diesen Bibliotheken als Klasse verfügbar. Dies gilt analog für Felder, Agenten und andere Lotus-Objekte. Über diese Bibliotheken kann der Code als gewöhnlicher Programmcode getestet werden, womit herkömmliche Testverfahren für fast alle Fälle einsetzbar sind. Analog kann man Programme erstellen, welche die Event-Programmierungen nach Feldnamen o.ä. durchsuchen, was mit einem Agenten wesentlich schwieriger und nicht empfohlen ist. Der volle Umfang der Möglichkeiten dieser Umgebung würde den Rahmen dieses Vortrags sprengen, wird daher nicht weiter ausgeführt.

35 Fazit

36 36 Fazit Die Notwendigkeit eigener Testverfahren unter Lotus Notes (als einzige verbreitete Umgebung von dokumentorientierter Entwicklung) ist offensichtlich. IBM arbeitet derzeit daran, Fehlerquellen aus der Notesentwicklung zu umgehen, indem zum Beispiel die Ausführungsreihenfolge von Events klarer strukturiert wird. Die meisten Firmen, bei denen Lotus Notes produktiv ist, verwenden jedoch alte Systeme und sind nicht zu kostenintensiver Migration bereit. Die vorgestellten Testverfahren sind im Prinzip nur angepasste Verfahren aus der üblichen Code-basierten Softwareentwicklung. In der Tat gibt es kaum spezifische Testverfahren, weswegen viele Programme auch unter schwerwiegenden Fehlern leiden. Dem wird meist durch eine detaillierte Dokumentation und zahlreiches Zufallstesten entgegengewirkt, wobei der Aufwand den Resultaten jedoch nicht gerecht wird. Firmen, die unter Lotus Notes entwickeln, könnten also durch Investitionen in neue Testverfahren viel Arbeitszeit und Geld einsparen, außerdem bestehende Programme optimieren.

37 Ausblick

38 38 Ausblick Die Entwicklung der Testverfahren für Notes steckt noch in den Kinderschuhen. Dennoch gibt es Firmen, welche sich um Programme bemühen, welche die Notes-Datenbanken systematisch nach klassischen Fehlerquellen durchsuchen. Die Trefferquote dieser Programme ist eher gering, verbessert sich jedoch zunehmend. Andere Ansätze gehen dahin, die dokumentorientierte Entwicklung der codebasierten anzupassen. Beispiele hierfür sind das Domingo-Projekt oder die Tatsache, dass die Notes- Entwicklung seitens IBM in eine Eclipse-Umgebung eingebunden wurde. Neue Testverfahren, die den Besonderheiten der dokumentorientierten Entwicklung gerecht werden, sind dagegen auf kurze Sicht nicht zu erwarten, hier sind die entwickelnden Firmen also auf eigene Ideen angewiesen.

39 Fragen?

40 Vielen Dank!


Herunterladen ppt "Testverfahren in dokumentorientierten Entwicklungsumgebungen Pascal Vallet Team4 GmbH Seminarvortrag WS 2009/2010 20.01.2010."

Ähnliche Präsentationen


Google-Anzeigen